两台闲置 RTX 4090 机器：本地大模型部署与测试教程

公司里居然有两台闲置的 RTX 4090 机器。4090 的 24GB 显存虽然跑不了真正的大型闭源模型，但拿来做本地大模型服务、代码助手、内网 API、模型能力评估，已经很够用了。所以这次的目标很朴素：先别让显卡继续吃灰，把两台机器都用起来。

这篇是一个持续更新的本地大模型部署教程。第一台重点测试机器是 Ubuntu 26.04 LTS，单张 RTX 4090 24GB。目标不是跑一次 demo，而是在本地或者内网里长期提供一个能用的模型服务，支持命令行测试、OpenAI-compatible API，以及后续接入 Open WebUI、Continue、Cline 这类客户端。

顺便说一句，这次 Ubuntu 26.04 LTS 给我的印象很好。以前折腾 NVIDIA 显卡，最怕的就是驱动、内核模块、CUDA 工具链互相打架；但这次系统对 RTX 4090 的支持近乎完美，驱动识别、nvidia-smi、Docker GPU 验证都很顺，全程基本没有为显卡驱动犯愁。

还有一个背景值得单独说明：这次从服务器环境检查、代理安装、Ollama 部署、benchmark 脚本生成、API 测试、模型效果评估，到这篇博客的持续修订，基本都是由 Codex 全程操作完成的。我负责给目标、验收结果和补充判断；Codex 负责执行命令、写脚本、整理日志、更新文章。这篇文章也算是一次“用 AI Agent 部署并评估本地 AI 模型”的实战记录。

先说明当前状态：GPU 服务器 A 已经完成基础环境、代理服务和 Ollama 服务安装；GPU 服务器 B 也已经补上代理服务，作为备用内网入口。llama.cpp 源码编译在 Ubuntu 26.04 LTS + CUDA 工具链上遇到编译器崩溃，暂时先用 Ollama 作为可运行路径。现在已经完成 qwen3:30b、qwen3-coder:30b、deepseek-r1:32b 三个大模型的初轮 token 速率测试，后面会继续补充真实显存占用、不同上下文长度下的稳定性，以及几个模型的效果对比。

实机记录

这次实际部署的机器配置如下：

因为服务器直接访问 GitHub 和模型仓库不稳定，我先安装了一个 Clash.Meta 兼容代理：mihomo v1.19.24。一开始为了安全只监听本机，确认可用后按局域网使用需求改成：

0.0.0.0:7890      # mixed HTTP/SOCKS proxy，局域网机器可用
127.0.0.1:9090    # external controller，只允许本机访问

当前关键配置是：

bind-address: 0.0.0.0
mixed-port: 7890
allow-lan: true
external-controller: 127.0.0.1:9090

订阅地址只在服务器上用于生成 /etc/mihomo/config.yaml，不写进脚本、博客或仓库。局域网客户端可以把 HTTP/SOCKS 代理设置为：

<GPU-A 内网地址>:7890

验证命令：

systemctl status mihomo
systemctl is-enabled mihomo
curl -x http://<GPU-A 内网地址>:7890 -I -L --max-time 30 https://github.com

当前结果是 GitHub 返回 HTTP 200，说明服务器可以通过本机代理访问 GitHub。安装过程中还遇到一个细节：mihomo 首次校验配置时会尝试从 GitHub 下载 geoip.metadb，但当时网络还没走通，所以我先在本地下载 geoip.metadb 和 geosite.dat，再传到服务器的 /etc/mihomo/。

同一套代理服务后来也部署到了另一台内网开发机，也就是 GPU 服务器 B，作为备用代理入口。它的代理端口同样是 7890，systemd 服务同样是 mihomo.service。如果只需要访问 GPU 服务器 A 上的 Ollama，仍然优先使用它自己的内网 API 地址；代理只是解决 GitHub、模型仓库下载和其他外部访问问题。

这台机器的 SSH 入口依赖 frpc。我也把它整理成 systemd 开机自启服务，并把原来的 User=nobody 改成专用系统用户 frpc，避免 systemd 的安全提示。当前 unit 重点如下：

[Unit]
Description=FRP Client Daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=+/usr/local/sbin/frpc-route-mtu.sh
ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.toml
Restart=on-failure
RestartSec=5
User=frpc
Group=frpc

[Install]
WantedBy=multi-user.target

验证结果：

systemctl is-enabled frpc   # enabled
systemctl is-active frpc    # active
journalctl -u frpc -n 20 --no-pager

重启 frpc 时当前 SSH 会短暂断开，这是正常现象，因为 SSH 连接本身就是通过 frp 转发进来的。重连后日志显示 login to server success 和 start proxy success。

公网 frp SSH 入口有时会被服务端直接关闭连接。内网环境下更稳定的方式是直接访问：

ssh <user>@<GPU-A 内网地址>

后续所有 Ollama benchmark 都是在内网直连 GPU 服务器 A 后执行的。

这台机器适合跑什么模型

RTX 4090 的 24GB 显存是一个很微妙、也很实用的区间。它不适合把 70B 级模型用高精度完整塞进显存，但很适合跑 30B 到 35B 级别的 4bit 量化模型。个人开发、中文技术写作、代码辅助、文档总结、轻量知识库问答，基本都落在这个区间。

我准备先按下面的顺序测试：

本文先以 Qwen3.6-35B-A3B GGUF 为主线写部署步骤。模型文件建议优先试 Q4_K_M 或同级 4bit 量化。如果实际显存吃紧，就降到 IQ4_NL、Q3_K_M 一类更小的量化；如果显存还有余量，再考虑更高量化质量。

如果不只看 Qwen，还有几类硬件要求接近、值得一起测的模型：

这里有两个名字容易混淆。

DeepSeek：完整的 DeepSeek-R1 是 671B 级 MoE 模型，单张 RTX 4090 不是它的舒适运行环境。4090 24GB 真正应该测的是 DeepSeek-R1-Distill-Qwen-32B 这类蒸馏模型。

Gemini / Gemma：Gemini 是 Google 的闭源商用模型系列，主要通过 API 使用；本地可下载权重部署的是 Gemma。对这台机器来说，Gemma 3 27B 才是同一硬件档位的候选。

参考入口：

• Qwen3.6-35B-A3B
• Qwen3.6-35B-A3B-GGUF
• Qwen3-Coder-30B-A3B-Instruct
• DeepSeek-R1-Distill-Qwen-32B
• Gemma 3 官方介绍
• Gemma 3 文档
• Mistral-Small-3.2-24B-Instruct
• GLM-4.5 / GLM-4.5-Air 官方说明
• llama.cpp CUDA 构建文档
• Ubuntu Server NVIDIA 驱动安装文档
• NVIDIA Container Toolkit 安装文档

0. 系统前提

下文假设你已经能 SSH 登录这台机器，并且用户有 sudo 权限。

lsb_release -a
uname -a

期望看到 Ubuntu 26.04 LTS。如果机器是刚装好的系统，先更新软件源和基础包：

sudo apt update
sudo apt upgrade -y
sudo apt install -y \
  build-essential \
  cmake \
  git \
  curl \
  wget \
  unzip \
  pkg-config \
  python3 \
  python3-venv \
  python3-pip \
  htop \
  nvtop

nvtop 不是必须，但调模型时很好用。它能直观看到 GPU 使用率、显存占用和进程。

1. 安装并验证 NVIDIA 驱动

Ubuntu 官方推荐用 ubuntu-drivers 选择驱动。先安装工具并查看推荐项：

sudo apt install -y ubuntu-drivers-common
ubuntu-drivers devices

输出里通常会有一项 recommended。不要硬背某个驱动版本号，直接用系统推荐版本更稳：

sudo ubuntu-drivers install
sudo reboot

这一步在 Ubuntu 26.04 LTS 上比预期顺利很多。系统推荐驱动安装后，重启就能直接识别 RTX 4090，没有遇到内核模块加载失败、驱动版本不匹配、nvidia-smi 找不到设备这类常见问题。后面真正花时间的地方反而是模型下载和 llama.cpp 编译链，而不是 NVIDIA 驱动。

重启后检查：

nvidia-smi

至少要确认三件事：

• 能看到 NVIDIA GeForce RTX 4090。
• 能看到驱动版本和 CUDA Version。
• 空闲状态下显存占用不异常。

如果 nvidia-smi 报错，先别继续下载模型。优先排查：

dkms status
lsmod | grep nvidia
journalctl -k | grep -i nvidia | tail -n 80

如果机器启用了 Secure Boot，NVIDIA 内核模块可能加载失败。最省事的做法通常是进 BIOS 关闭 Secure Boot，或者按 Ubuntu 提示给内核模块签名。

2. 准备 Docker GPU 环境

不是所有部署都必须用 Docker，但我建议先配好。以后测试 vLLM、SGLang、Open WebUI 时都会用得上。

先安装 Docker：

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

把当前用户加入 docker 组：

sudo usermod -aG docker "$USER"
newgrp docker

然后安装 NVIDIA Container Toolkit：

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

验证 Docker 能看到 GPU：

docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

这里容器镜像用 Ubuntu 24.04 base 没关系，关键是能通过宿主机驱动访问 GPU。只要容器里也能看到 RTX 4090，后面跑容器化推理服务就有基础了。

3. 准备模型目录

建议把模型放在单独的数据盘或固定目录，不要散落在项目目录里。

sudo mkdir -p /data/models/gguf
sudo chown -R "$USER:$USER" /data/models

安装 Hugging Face 下载工具：

python3 -m venv ~/.venvs/hf
source ~/.venvs/hf/bin/activate
pip install -U pip huggingface_hub

如果访问 Hugging Face 较慢，可以临时设置镜像端点：

export HF_ENDPOINT=https://hf-mirror.com

下载 Qwen3.6 的 GGUF 文件时，先到模型仓库确认实际文件名。下面命令写法保留变量，方便替换：

cd /data/models/gguf

MODEL_REPO="unsloth/Qwen3.6-35B-A3B-GGUF"
MODEL_FILE="Qwen3.6-35B-A3B-Q4_K_M.gguf"

huggingface-cli download "$MODEL_REPO" \
  "$MODEL_FILE" \
  --local-dir /data/models/gguf \
  --local-dir-use-symlinks False

如果仓库里的推荐文件名不是 Q4_K_M，就把 MODEL_FILE 改成实际文件名。下载后确认大小：

ls -lh /data/models/gguf
sha256sum /data/models/gguf/*.gguf | tee /data/models/gguf/SHA256SUMS.txt

24GB 显存下，Q4_K_M 级别文件通常会比较贴近上限。后面启动时上下文不要一开始拉满，先用 8K 验证。

4. 编译 llama.cpp CUDA 版本

llama.cpp 是跑 GGUF 最直接的一条路。先安装 CUDA 编译工具。Ubuntu 仓库里的包如果能满足当前版本，直接用：

sudo apt install -y nvidia-cuda-toolkit
nvcc --version

如果系统仓库的 CUDA 包太旧，或者 nvcc 不存在，再换 NVIDIA 官方 CUDA repository。本文先按 Ubuntu 26.04 LTS 的基础路径写。

拉代码并编译：

mkdir -p ~/src
cd ~/src

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j"$(nproc)"

编译完成后检查二进制：

./build/bin/llama-server --help | head
./build/bin/llama-cli --help | head

如果编译阶段找不到 CUDA，通常是 nvcc 或 CUDA 头文件路径问题。先确认：

which nvcc
nvcc --version
echo "$CUDA_HOME"

有些环境需要显式指定 CUDA 编译器，例如：

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_CUDA_COMPILER=/usr/bin/nvcc \
  -DCMAKE_BUILD_TYPE=Release

本次实机编译结果

这台 Ubuntu 26.04 LTS 机器上，git clone 和 CMake 配置都能成功，CMake 也识别到了 CUDA backend，架构为 89-real。但实际编译没有顺利完成。

第一次使用系统默认 GCC 15 编译：

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j"$(nproc)"

失败现象是 GCC 内部编译器错误和 CUDA 编译阶段段错误，典型日志包括：

internal compiler error: Segmentation fault
Segmentation fault (core dumped)

第二次降到 GCC/G++ 13，并把并发降到 2：

rm -rf build-gcc13
CC=/usr/bin/gcc-13 CXX=/usr/bin/g++-13 \
  cmake -B build-gcc13 -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build-gcc13 --config Release -j2

结果仍然失败，错误集中在 ggml-cpu/ops.cpp 和部分 CUDA template instance 编译阶段。这个现象更像是 Ubuntu 26.04、GCC、新版 CUDA 工具链和当前 llama.cpp 源码组合下的编译链问题，而不是模型或 GPU 本身的问题。

后续可选处理路径：

• 使用 llama.cpp 官方或社区预编译二进制。
• 换到更保守的容器环境，例如 Ubuntu 24.04 + CUDA 12.x + GCC 12/13。
• 固定 llama.cpp 到一个已验证 commit，再逐步升级。
• 先用 Ollama 跑通服务和模型测试，等需要精细控制参数时再回到 llama.cpp。

5. 先用命令行跑通一次

不要一上来就起服务。先用 llama-cli 跑一个短 prompt，确认模型、CUDA、显存三件事都正常。

cd ~/src/llama.cpp

MODEL=/data/models/gguf/Qwen3.6-35B-A3B-Q4_K_M.gguf

./build/bin/llama-cli \
  -m "$MODEL" \
  -ngl 99 \
  -c 8192 \
  -p "请用三句话解释一下，为什么 24GB 显存适合跑 30B 级 4bit 量化模型。"

同时另开一个终端观察：

watch -n 1 nvidia-smi

这里的几个参数含义：

如果报显存不足，先不要怀疑驱动。优先把上下文降下来：

./build/bin/llama-cli \
  -m "$MODEL" \
  -ngl 99 \
  -c 4096 \
  -p "你好，请做一个简单自我介绍。"

如果还是 OOM，再换更小的量化文件。

6. 启动 OpenAI-compatible API

命令行跑通后，再启动 llama-server：

cd ~/src/llama.cpp

MODEL=/data/models/gguf/Qwen3.6-35B-A3B-Q4_K_M.gguf

./build/bin/llama-server \
  -m "$MODEL" \
  -ngl 99 \
  -c 8192 \
  --host 0.0.0.0 \
  --port 8000

本机测试：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-qwen",
    "messages": [
      {
        "role": "user",
        "content": "用三点说明本地部署大模型相比云端 API 的优缺点。"
      }
    ],
    "temperature": 0.7,
    "stream": false
  }'

流式输出也要测：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-qwen",
    "messages": [
      {
        "role": "user",
        "content": "写一段 200 字左右的中文技术博客开头，主题是本地大模型部署。"
      }
    ],
    "temperature": 0.7,
    "stream": true
  }'

如果要给局域网其他机器访问，确认防火墙：

sudo ufw status
sudo ufw allow 8000/tcp

如果只是本机用，就不要开放端口，把 --host 改成 127.0.0.1 更安全。

7. 用 systemd 托管服务

长期使用不要手工开终端挂着。新建一个专用目录放启动脚本：

mkdir -p ~/bin
vim ~/bin/start-local-llm.sh

写入：

#!/usr/bin/env bash
set -euo pipefail

cd "$HOME/src/llama.cpp"

MODEL="/data/models/gguf/Qwen3.6-35B-A3B-Q4_K_M.gguf"

exec "$HOME/src/llama.cpp/build/bin/llama-server" \
  -m "$MODEL" \
  -ngl 99 \
  -c 8192 \
  --host 0.0.0.0 \
  --port 8000

加执行权限：

chmod +x ~/bin/start-local-llm.sh

创建 systemd user service：

mkdir -p ~/.config/systemd/user
vim ~/.config/systemd/user/local-llm.service

写入：

[Unit]
Description=Local LLM server via llama.cpp
After=network-online.target

[Service]
Type=simple
ExecStart=%h/bin/start-local-llm.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

启用并启动：

systemctl --user daemon-reload
systemctl --user enable --now local-llm.service
systemctl --user status local-llm.service

如果希望用户退出 SSH 后服务仍然运行：

sudo loginctl enable-linger "$USER"

查看日志：

journalctl --user -u local-llm.service -f

8. 可选：用 Ollama 快速体验

如果只是想先聊天，不想编译 llama.cpp，Ollama 更省事：

curl -fsSL https://ollama.com/install.sh | sh

这次实机安装时，官方安装脚本下载 ollama-linux-amd64.tgz 返回了 404，所以改用 GitHub Release 的 .tar.zst 包手动安装。因为服务器直连 GitHub 不稳定，安装包先在本地下载，再传到服务器：

curl -L --fail -C - \
  -o ollama-linux-amd64.tar.zst \
  https://github.com/ollama/ollama/releases/download/v0.23.2/ollama-linux-amd64.tar.zst

scp ollama-linux-amd64.tar.zst server:/tmp/

服务器上解压到 /usr/local：

sudo tar --zstd -xf /tmp/ollama-linux-amd64.tar.zst -C /usr/local
sudo mkdir -p /data/models/ollama

创建专用用户：

sudo useradd --system \
  --create-home \
  --home-dir /usr/share/ollama \
  --shell /usr/sbin/nologin \
  --user-group ollama

sudo usermod -a -G render,video ollama
sudo chown -R ollama:ollama /data/models/ollama /usr/share/ollama

/etc/systemd/system/ollama.service：

[Unit]
Description=Ollama Service
After=network-online.target mihomo.service
Wants=network-online.target

[Service]
Type=simple
User=ollama
Group=ollama
ExecStart=/usr/local/bin/ollama serve
Restart=always
RestartSec=3
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/models/ollama"
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="NO_PROXY=127.0.0.1,localhost"

[Install]
WantedBy=multi-user.target

启动：

sudo systemctl daemon-reload
sudo systemctl enable --now ollama

确认服务：

systemctl status ollama
ollama --version
curl http://127.0.0.1:11434/api/version

一开始我只让 Ollama 监听 127.0.0.1:11434。后来为了让局域网里的其他机器可以直接通过 API 调用，把 OLLAMA_HOST 改成：

Environment="OLLAMA_HOST=0.0.0.0:11434"

重启后监听状态：

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -ltnp | grep :11434

当前实测版本是 0.23.2，服务监听 *:11434，模型目录为 /data/models/ollama。局域网客户端可以访问：

curl http://<GPU-A 内网地址>:11434/api/version
curl http://<GPU-A 内网地址>:11434/api/tags

如果 Ollama 官方库里已有目标模型，可以直接：

ollama pull qwen3.6:35b
ollama run qwen3.6:35b

第一次端到端测试可以先拉一个小模型，确认下载、加载、推理、GPU 调用链路都正常：

ollama pull qwen3:0.6b
ollama run qwen3:0.6b "用一句中文说明你已经可以在本机运行。"
ollama ps
nvidia-smi

这台服务器走代理下载模型时速度不稳定，qwen3:0.6b 的 522MB 权重实际下载花了比较久。这个阶段先验证服务可用，正式性能测试再换 30B 级模型。

下载过程中一度速度降到 0.3MB/s 左右，所以我把任务转成后台继续跑，日志放在用户目录：

nohup /usr/local/bin/ollama pull qwen3:0.6b \
  > "$HOME/ollama-pull-qwen3-0.6b.log" 2>&1 < /dev/null &

tail -f "$HOME/ollama-pull-qwen3-0.6b.log"

为了从本地机器验证局域网 API，我在博客项目里放了一个测试脚本：

python3 scripts/test_ollama_lan_api.py \
  --base-url http://<GPU-A 内网地址>:11434 \
  --model qwen3:0.6b

脚本会先测试 /api/version 和 /api/tags。如果模型还没下载完成，会输出 model_not_ready；模型就绪后会继续调用 /api/chat 做一次非流式生成测试。

本次从本地机器调用局域网 API 的结果：

version: 0.23.2
models: qwen3:0.6b
elapsed_seconds: 22.82
response:
我已经通过局域网API被访问。

服务器侧同时能看到模型跑在 GPU 上：

NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:0.6b    7df6b6e09427    4.5 GB    100% GPU     32768      4 minutes from now

小模型验证通过后，继续在服务器后台顺序拉取几个 4090 24GB 适合测试的模型。因为单个模型就有 15GB 到 20GB，当前网络又不稳定，所以不要并发下载。服务器上创建了 ~/pull-ollama-models.sh：

MODELS=(
  "qwen3:30b"
  "qwen3-coder:30b"
  "deepseek-r1:32b"
  "gemma3:27b"
  "mistral-small3.2:24b"
)

启动方式：

nohup ~/pull-ollama-models.sh \
  > ~/ollama-pull-logs/nohup.log 2>&1 < /dev/null &

查看队列进度：

tail -f ~/ollama-pull-logs/pull-queue.log
tail -f ~/ollama-pull-logs/qwen3_30b.log
ollama list
pgrep -af "pull-ollama-models.sh|ollama pull"

当前已经完成下载并能被 /api/tags 列出的模型如下：

模型下载完成后，可以继续用局域网 API 测试脚本逐个跑一遍：

python3 scripts/test_ollama_lan_api.py \
  --base-url http://<GPU-A 内网地址>:11434 \
  --model qwen3:30b

为了更稳定地记录 token 速率，我又写了一个只依赖 Python 标准库的 benchmark 脚本，已经同步到 GPU 服务器 A：

/home/<user>/benchmark_ollama_token_rate.py

脚本会调用 Ollama 的 /api/tags 自动列出本机模型，默认筛选 10B+ 的大模型，然后用 /api/generate 的非流式接口跑固定 prompt。输出 token/s 使用 Ollama 响应中的 eval_count / eval_duration 计算，prompt token/s 使用 prompt_eval_count / prompt_eval_duration 计算。

这次测试命令是：

/home/<user>/benchmark_ollama_token_rate.py \
  --host http://127.0.0.1:11434 \
  --min-params-b 10 \
  --runs 3 \
  --warmup \
  --num-predict 256 \
  --timeout 1800 \
  --output /home/<user>/ollama-token-rate.csv \
  --jsonl /home/<user>/ollama-token-rate.jsonl

这里有两个细节要注意：

• qwen3-coder:30b 在这个短 prompt 下提前结束，实际生成了 212 个 token，不是完整 256 个 token。
• qwen3:30b 和 qwen3-coder:30b 是 MoE 模型，实际激活参数远小于总参数，所以吞吐明显高于 dense 的 deepseek-r1:32b。这不是简单的“Qwen 比 DeepSeek 快 20 倍”，而是模型结构不同。

如果官方库还没有，或者你想用自己下载的 GGUF，可以写一个 Modelfile：

mkdir -p ~/ollama-models/qwen36
cd ~/ollama-models/qwen36
cp /data/models/gguf/Qwen3.6-35B-A3B-Q4_K_M.gguf .

cat > Modelfile <<'EOF'
FROM ./Qwen3.6-35B-A3B-Q4_K_M.gguf

PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF

ollama create qwen36-35b-q4 -f Modelfile
ollama run qwen36-35b-q4

Ollama 的 API 默认在 11434：

curl http://127.0.0.1:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen36-35b-q4",
    "messages": [
      {"role": "user", "content": "写一个 Python 脚本，读取目录下所有 Markdown 文件并统计字数。"}
    ],
    "stream": false
  }'

我个人会把 Ollama 当作快速体验路径，把 llama.cpp server 当作更可控的服务路径。

9. 固定测试问题集

只问“你好”没有意义。每次换模型、换量化、换上下文长度，都应该用同一组问题做对比。

中文写作

请把下面这段说明改写成适合技术博客读者阅读的中文，不要改变技术含义：

我们在 Ubuntu 26.04 LTS 上使用 RTX 4090 部署本地大模型。模型采用 4bit GGUF 量化，推理服务通过 llama.cpp 暴露 OpenAI-compatible API。

观察它是否自然、是否废话多、是否偷换含义。

代码理解

请阅读下面这段 Python 代码，指出潜在问题，并给出最小修改建议：

import requests

def fetch_all(urls):
    result = []
    for url in urls:
        r = requests.get(url)
        result.append(r.json())
    return result

好的回答应该能提到超时、异常处理、状态码、串行请求性能等问题。

运维排障

有一个本地 LLM API 服务，平均响应很快，但偶发 60 秒超时。机器是单张 RTX 4090，Ubuntu 26.04 LTS。请列出排查步骤。

我会看它是否能想到显存碎片、上下文长度、并发排队、CPU 采样瓶颈、磁盘换页、反向代理超时、客户端重试等问题。

代码生成

写一个 Bash 脚本，每 5 秒记录一次 nvidia-smi 的显存占用和 GPU 利用率，输出到 CSV 文件。

这个问题能快速看出模型写脚本的可靠性。

2026-05-12：qwen3-coder:30b 实际问答评估

首轮 token 速率测试后，我选了 qwen3-coder:30b 做实际问答。原因很简单：它在 4090 24GB 上速度和 qwen3:30b 接近，短输出能到 200 tok/s 左右；同时它的输出更干净，没有把思考过程混进最终回答里。qwen3:30b 的吞吐同样很好，但当前通过 Ollama /api/chat 调用时，即使提示“不要输出思考过程”，仍然容易把内部推理文字输出到正文里，所以暂时不作为默认推荐模型。

这次测试不是登录到 GPU 服务器 A 上执行，而是在本地机器直接访问局域网 Ollama API：

curl --noproxy '*' http://<GPU-A 内网地址>:11434/api/version

如果本机环境里配置了 ALL_PROXY、HTTP_PROXY 或 HTTPS_PROXY，访问内网地址时要绕过代理，否则请求可能会被本机代理拦截：

ALL_PROXY= HTTP_PROXY= HTTPS_PROXY= python3 run_local_eval.py

测试问题沿用上面的四类任务，接口使用 http://<GPU-A 内网地址>:11434/api/chat，模型为 qwen3-coder:30b。实测结果如下：

下面按“Prompt / 返回结果 / 观察”的格式记录每一次调用。这样比只看结论更直观，也方便后续换模型、换量化、换推理框架时逐项对比。

请把下面这段说明改写成适合技术博客读者阅读的中文，不要改变技术含义，控制在 180 字以内。不要输出思考过程。

我们在 Ubuntu 26.04 LTS 上使用 RTX 4090 部署本地大模型。模型采用 4bit GGUF 量化，推理服务通过 llama.cpp 暴露 OpenAI-compatible API。

请阅读下面这段 Python 代码，指出潜在问题，并给出最小修改建议。回答要具体，不要泛泛而谈，不要输出思考过程。

import requests

def fetch_all(urls):
    result = []
    for url in urls:
        r = requests.get(url)
        result.append(r.json())
    return result

import requests

def fetch_all(urls):
    result = []
    for url in urls:
        try:
            r = requests.get(url, timeout=10)
            r.raise_for_status()  # 检查状态码
            result.append(r.json())
        except (requests.RequestException, ValueError):  # 捕获请求和JSON解析异常
            continue  # 或者返回None/空值，根据业务需求
    return result

有一个本地 LLM API 服务，平均响应很快，但偶发 60 秒超时。机器是单张 RTX 4090，Ubuntu 26.04 LTS。请按优先级列出排查步骤，最多 10 条，每条说明要检查什么、用什么命令、如何判断。不要输出思考过程。

写一个完整可运行的 Bash 脚本，每 5 秒记录一次 nvidia-smi 的显存占用、GPU 利用率、功耗和温度，输出到 CSV 文件。要求脚本可以用 Ctrl+C 停止，CSV 有表头，优先使用 nvidia-smi --query-gpu。只输出脚本和少量必要说明，不要输出思考过程。

#!/bin/bash

# 检查 nvidia-smi 是否可用
if ! command -v nvidia-smi &> /dev/null; then
    echo "错误: 未找到 nvidia-smi 命令"
    exit 1
fi

# 检查参数
if [ $# -ne 1 ]; then
    echo "用法: $0 <输出文件名>"
    exit 1
fi

OUTPUT_FILE="$1"

# 创建 CSV 文件并写入表头
echo "Timestamp,Memory_Used_MiB,Memory_Total_MiB,Utilization_GPU_Percent,Utilization_Memory_Percent,Power_Draw_Watts,Temperature_GPU_Celsius" > "$OUTPUT_FILE"

# 信号处理函数
cleanup() {
    echo -e "\n停止监控..."
    exit 0
}

# 设置信号处理器
trap cleanup SIGINT SIGTERM

echo "开始监控 GPU 状态，按 Ctrl+C 停止..."
echo "数据已写入: $OUTPUT_FILE"

# 主循环
while true; do
    # 获取 GPU 信息
    nvidia-smi --query-gpu=timestamp,memory.used,memory.total,utilization.gpu,utilization.memory,power.draw,temperature.gpu --format=csv,noheader,nounits | \
    awk -v timestamp="$(date '+%Y-%m-%d %H:%M:%S')" '{
        printf "%s,%s,%s,%s,%s,%s,%s\n", timestamp, $2, $3, $4, $5, $6, $7
    }' >> "$OUTPUT_FILE"

    sleep 5
done

综合看，qwen3-coder:30b 适合作为这台 4090 机器上的默认本地代码 / 技术助手模型。它的优势是响应快、输出干净、代码类任务可用性高；短板是复杂排障回答仍然偏 checklist，需要人根据现场日志继续收敛问题。它可以覆盖日常代码审查、脚本生成、技术文档改写和轻量运维问答，但还不能完全替代更强的云端模型做深层架构推理或长上下文仓库分析。

2026-05-12：qwen3:30b 同题评估

随后我用同一组问题测试了 qwen3:30b。从速度看，它和 qwen3-coder:30b 基本在同一档，生成速度也在 200 tok/s 左右；但实际可用性差很多。即使 system prompt 写了“只输出最终答案，不要输出思考过程”，请求体也加了 "think": false，它仍然把分析过程输出到了正文里，并且四个问题都因为先输出思考过程而触发 done_reason=length 截断。后来我又在用户问题末尾追加 /no_think 做对照，结果仍然泄漏思考过程并被截断。

下面同样按每次调用记录 Prompt 和返回结果。这里的“截断”不是我手工删减，而是 Ollama 返回的 done_reason=length，也就是模型在本次 num_predict 限制内没有来得及输出完整最终答案。因为返回内容很长，而且主要是思考过程，所以这里保留摘要和关键片段，不全文粘贴。

请把下面这段说明改写成适合技术博客读者阅读的中文，不要改变技术含义：

我们在 Ubuntu 26.04 LTS 上使用 RTX 4090 部署本地大模型。模型采用 4bit GGUF 量化，推理服务通过 llama.cpp 暴露 OpenAI-compatible API。

请阅读下面这段 Python 代码，指出潜在问题，并给出最小修改建议：

import requests

def fetch_all(urls):
    result = []
    for url in urls:
        r = requests.get(url)
        result.append(r.json())
    return result

import requests

def fetch_all(urls):
    result = []
    for url in urls:
        r = requests.get(url)
        result.append(r.json())
    return result

import requests

def fetch_all(urls):
    result = []
    for url in urls:
        try:
            r = requests.get(url)
            r.raise_for_status()  # 检查 HTTP 错误
            result.append(r.json())
        except Exception as e:
            result.append(None)  # 或者记录错误
    return result

有一个本地 LLM API 服务，平均响应很快，但偶发 60 秒超时。机器是单张 RTX 4090，Ubuntu 26.04 LTS。请列出排查步骤。最多 10 条，每条包含要执行的命令或要看的指标，以及如何判断。

写一个可以直接运行的 Bash 脚本，每 5 秒记录一次 nvidia-smi 的显存占用和 GPU 利用率，输出到 CSV 文件。要求使用 nvidia-smi --query-gpu，支持 Ctrl+C 正常退出。

nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv,noheader

nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv,noheader | \
awk -F, '{gsub(/[^0-9]/, "", $1); gsub(/[^0-9]/, "", $2); print $1 "," $2}'

while true; do
  timestamp=$(date +"%Y-%m-%d %H:%M:%S")
  data=$(nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv,noheader | awk -F, '{gsub(/[^0-9]/, "", $1); gsub(/[^0-9]/, "", $2); print $1 "," $2}')
  echo "$timestamp,$data" >> gpu_data.csv
  sleep 5
done

我还用相同问题在末尾追加 /no_think 做了一轮对照。结果没有本质改善：四个问题仍然输出思考过程，done_reason 仍然是 length。因此在当前 Ollama 调用方式下，qwen3:30b 更适合做吞吐测试，不适合作为默认交互模型；如果后续能找到稳定关闭 thinking 输出的配置，再重新评估它的实际能力。

10. 记录性能数据

建议建一个简单表格，每次测试都填进去：

这张表先记录输出 token/s，显存峰值后面会用 nvidia-smi 采样补齐。当前测试结束后，nvidia-smi 显示 GPU 上还保留了 Ollama 加载的模型缓存，显存占用约 21555 MiB / 24564 MiB。这个数字不能当作单次推理峰值，只能说明 30B/32B 级 4bit 模型已经接近 4090 24GB 的实用上限。

本轮 benchmark 的 CSV 摘要如下：

model,params_b,parameter_size,size_gib,runs,successful_runs,median_output_tokens_per_second,median_prompt_tokens_per_second,median_wall_seconds,median_load_seconds,generated_tokens,prompt_tokens
deepseek-r1:32b,32.800,32.8B,18.488,3,3,10.490,274.658,24.743,0.065,256,28
qwen3:30b,30.500,30.5B,17.282,3,3,203.895,4902.763,1.368,0.062,256,35
qwen3-coder:30b,30.500,30.5B,17.282,3,3,205.075,5938.249,1.135,0.060,212,33

显存可以用：

nvidia-smi --query-gpu=timestamp,name,memory.used,memory.total,utilization.gpu,power.draw,temperature.gpu \
  --format=csv \
  -l 5 \
  | tee gpu-llm-test.csv

如果要记录接口耗时，可以先用简单脚本：

cat > test_chat_latency.py <<'PY'
import json
import time
import urllib.request

url = "http://127.0.0.1:8000/v1/chat/completions"
payload = {
    "model": "local-qwen",
    "messages": [
        {"role": "user", "content": "请用 300 字说明本地大模型部署的关键注意事项。"}
    ],
    "temperature": 0.7,
    "stream": False,
}

data = json.dumps(payload).encode("utf-8")
req = urllib.request.Request(url, data=data, headers={"Content-Type": "application/json"})

start = time.perf_counter()
with urllib.request.urlopen(req, timeout=300) as resp:
    body = resp.read().decode("utf-8")
elapsed = time.perf_counter() - start

print(f"elapsed={elapsed:.2f}s")
print(body[:1000])
PY

python3 test_chat_latency.py

后续我会把这部分改成更完整的批量测试脚本。

现在这个脚本已经有了一个 Ollama 版本，核心思路是直接读取 Ollama 返回的纳秒级 duration 字段，而不是只用客户端墙钟时间粗略估算。墙钟时间仍然保留，用来发现网络、排队和客户端侧开销。

11. 常见问题

nvidia-smi 正常，但 llama.cpp 没用 GPU

先看启动日志里有没有 CUDA backend。再确认编译时确实带了：

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j"$(nproc)"

如果用的是系统里另一个旧版本 llama-server，也可能出现“你以为自己跑了 CUDA 版，实际跑的是 CPU 版”的情况。用绝对路径启动最稳。

模型能启动，但一问就 OOM

优先降上下文：

-c 4096

再考虑换更小量化。模型权重只是显存的一部分，KV cache 会随着上下文长度和并发继续吃显存。24GB 显存不要一上来追 64K、128K。

下载模型很慢

先用 huggingface-cli download，不要浏览器手工下。国内网络可以临时使用：

export HF_ENDPOINT=https://hf-mirror.com

如果公司或内网有代理，也可以设置：

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890

服务给别人访问时不安全

llama-server 直接暴露在公网并不合适。至少要放在内网，或者前面加 Nginx、鉴权和 HTTPS。最简单的内网反代示例：

server {
    listen 80;
    server_name local-llm.internal;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_read_timeout 300s;
    }
}

如果只是自己用，SSH 端口转发更干净：

ssh -L 8000:127.0.0.1:8000 user@your-server

然后本机访问 http://127.0.0.1:8000。

12. 后续要补的实测结果

接下来我会按下面顺序补数据：

• Ubuntu 26.04 LTS 实机上的驱动版本、CUDA 版本。
• 服务器访问 GitHub 不稳定时的 mihomo 代理安装记录。
• Ollama 0.23.2 systemd 服务安装记录。
• llama.cpp 在当前 Ubuntu 26.04 编译链上的失败日志和绕行方案。
• Ollama 大模型 token 速率 benchmark 脚本与首轮测试结果。
• Qwen3.6-35B-A3B Q4_K_M 在 8K / 16K 上下文下的显存占用。
• llama.cpp server 的 tokens/s、首 token 延迟。
• Ollama 长输出、长上下文和多轮对话体验对比。
• Qwen3-Coder-30B-A3B-Instruct 代码任务测试结果。
• 是否需要切到 SGLang 或 vLLM 做服务化。

先把教程写到这里。下一步会补显存采样、长上下文压力测试、代码任务质量对比，以及最终推荐参数。