平台：Linux（Ubuntu 26.04 LTS）/ RTX PRO 4500 Blackwell 32GB / systemd 用户服务
日期：2026-08-19（模型 8-14 发布后 5 天，含 vLLM + llama.cpp 双框架全路径实测）

一、结论

硬件环境下的模型选型铁律

27B dense 模型在本机的最终定案

• vLLM 路线已废弃：32GB 卡跑 NVFP4 显存贴边（22GB 权重 + 811MB MTP head），CUDA graphs 开不了（需额外 800MB），只能 enforce-eager，速度 ~20 t/s
• llama.cpp 路线是唯一稳定选择：256K context + 无 MTP，速度 ~24.5 t/s，零崩溃
• MTP 在 Blackwell sm_120 上是崩溃根源：实测 128K/256K × mmproj 有无全组合，decode 阶段必崩（CUDA launch timed out，ggml-cuda.cu:106），升级到最新 llama.cpp 9731ad3 仍崩

本机现役三服务架构

vllm-qwen-A3B.service      → Qwen3.6-35B-A3B NVFP4 (200K, ~144 t/s)
llama-qwen-27B.service     → Qwen3.8-27B Q5_K_M (256K, ~24.5 t/s)
llama-qwen-27B-uc.service  → Qwen3.8-27B-Uncensored Q5_K_M (256K, ~24.5 t/s)

二、硬件 / 软件环境

三、模型来源

1. 官方原版 Qwen3.8-27B（默认主力）

• 仓库：https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
• 底模：https://huggingface.co/Qwen/Qwen3.8-27B（官方，27.78B dense 混合注意力，64 层 = 48 Gated DeltaNet + 16 full-attn，262144 原生上下文，Apache 2.0）
• 文件：Qwen3.8-27B-Q5_K_M.gguf（19.8GB）+ mmproj-F16.gguf（885MB）

2. 去拒答版 Qwen3.8-27B-Uncensored

• 仓库：https://huggingface.co/JonathanColetti/Qwen3.8-27B-Uncensored-GGUF
• 加工：JonathanColetti 做 abliteration（正交化消解除拒答方向），拒答率 98/100 → 12/100
• 文件：Qwen3.8-27B-Uncensored-Q5_K_M.gguf（19.5GB）+ Qwen3.8-27B-Uncensored-vision-f16.gguf（885MB）

3. vLLM 版本（已废弃）

• 仓库：https://huggingface.co/unsloth/Qwen3.8-27B-NVFP4（22GB）
• 32GB 卡实测上限 100K context，CUDA graphs 不可用

四、vLLM 路线实测（已废弃）

部署参数

vllm serve ~/models/Qwen3.8-27B-NVFP4 \
  --served-model-name qwen3.8-27b \
  --tensor-parallel-size 1 \
  --max-model-len 100000 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --enforce-eager \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --reasoning-parser qwen3 \
  --host 127.0.0.1 --port 8000

失败原因

最终速度

• 吐词速度：~20 tok/s（enforce-eager 模式）
• 对比 llama.cpp：24.5 t/s（无 MTP）→ vLLM 反而更慢

结论

32GB 单卡跑 27B NVFP4 显存贴边，vLLM 的 MTP + CUDA graphs 优势完全发挥不出来。vLLM 适合 MoE 模型（A3B），不适合 dense 模型（27B）。

五、llama.cpp 路线实测（稳定方案）

部署参数

llama-server \
  -m ~/models/Qwen3.8-27B/Qwen3.8-27B-Q5_K_M.gguf \
  --mmproj ~/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias Qwen3.8-27B \
  --host 127.0.0.1 --port 8000 \
  --ctx-size 262144 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --parallel 1 \
  --jinja \
  --no-mmap \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --chat-template-kwargs '{"reasoning_effort":"medium","preserve_thinking":true}' \
  --reasoning-preserve \
  --spec-type none \
  --temp 1.0 --top-k 20 --top-p 0.95

实测结果

显存占用

256K context 的关键

KV cache 全 4bit（--cache-type-k/v q4_0）是 32GB 卡跑 256K 的唯一正解。换成 fp8/fp16 直接放不下。

六、MTP 在 Blackwell 上的崩溃分析

崩溃现象

• CUDA error: the launch timed out and was terminated（ggml-cuda.cu:106）
• 崩溃点随机：366/771/2346/3208/5904 token（非上下文满导致）
• 128K/256K × mmproj 有无全组合实测全部崩溃

已知 Blackwell + MTP 的 bug

1. Issue #24399：mul_mat_q<Q8_0,128> 在 Blackwell 上 shared-memory out-of-range 崩溃
2. CUDA 13.2 乱码：Reddit 警告不要用 CUDA 13.2 编译 llama.cpp
3. MTP × hybrid-GDN crash class (#50021)：RTX 5090 上 NVFP4 和 W4A8 都崩
4. nvcc 编译器 bug：Blackwell SM_120 MMQ kernels at -O3 生成错误机器码

为什么 vLLM 的 MTP 能跑

vLLM 的 MTP 实现路径与 llama.cpp 不同，避开了上述 CUDA kernel bug。但 32GB 卡显存不够，只能 enforce-eager 模式，速度优势被抵消。

七、踩坑与经验

必须知道的

1. --jinja 必须加：3.8 官方 jinja 模板会把空 thinking 块包进输出，破坏多轮 agent 会话
2. 过思考是 3.8 的祖传毛病：用 reasoning_effort=medium 压住，medium 下实际思考量很小
3. 256K 是 32GB 卡的极限：288K 超预算（总显存 30GB 封顶，留 ~4GB 给桌面）
4. 256K vs 128K 速度无差别：速度只与实际上下文长度相关，与档位无关（1K-12K 负载 tg≈37 持平）

MTP 相关

5. Blackwell 上 MTP 必崩：与驱动版本无关（595.91.07 不救 MTP），与 llama.cpp 版本也无关
6. MTP acceptance rate 低：实测仅 45%（社区正常 80%+），Blackwell 上收益有限
7. 关 MTP 正确参数：--spec-type none（新版无 --no-speculative）

下载验证

8. 字节级核验：HF 仓库 ?blobs=true 拿每个文件 size，与本地 stat 对比
9. 别下错版本：同名量化可能差几百万字节（带不带 MTP、带不带 vision）

服务管理

10. 切模型 = 切服务：8000 端口互斥，切换前先停另一个
11. 全部 disabled：按需手动 start，不开机自启

八、接入 Agent 的方式

llama.cpp 自带 /v1/chat/completions，标准 OpenAI 协议。

# 文本测试
curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8-27B","messages":[{"role":"user","content":"Hello"}],"max_tokens":128}'

# 视觉测试（base64 内联）
curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8-27B","max_tokens":500,
       "messages":[{"role":"user","content":[
         {"type":"image_url","image_url":{"url":"data:image/png;base64,..."}},
         {"type":"text","text":"描述这张图"}
       ]}]}'

九、总结

一句话：dense 27B 质量换速度（llama.cpp，24.5 t/s，无 MTP），MoE A3B 速度换质量（vLLM，144 t/s，MTP 稳定），同机器双方案按场景切。

Blackwell sm_120 的现实：

• llama.cpp MTP 有已知崩溃 bug，短期内无法修复
• vLLM MTP 能跑但显存不够，32GB 卡只能 enforce-eager
• 速度最优解是 MoE 模型（A3B）+ vLLM + MTP

如果要速度：用 A3B（144 t/s）
如果要质量：用 27B 无 MTP（24.5 t/s）
如果两个都要：同机器双服务，按需切换