平台：Linux（Ubuntu 26.04 LTS）/ RTX PRO 4500 Blackwell 32GB / systemd 用户服务
日期：2026-08-20（模型 8-14 发布后 6 天；08-19 首测 Q5 档 + 08-20 换装 Q4 新量化源二次实测）

一、结论

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

27B dense 模型在本机的最终定案（2026-08-20）

• 框架：llama.cpp 唯一正解（vLLM 跑 dense 27B 只有 ~20 t/s，已废弃）
• 量化：Q4 档（标准版 Unsloth UD-Q4_K_XL / 免审查版 HauhauCS Q4_K_P，均 17.9GB）
• 投机解码：MTP（draft-mtp n-max 2），短负载 decode 67-68 t/s
• 上下文：200K（204800），K4V4（KV 全 4bit），显存 ~24.9GB / 32GB
• Q5 档已淘汰：Q5_K_M + MTP 在 Blackwell sm_120 必崩（decode kernel 超驱动看门狗）；Q5 无 MTP 仅 24.5 t/s

本机现役双服务

llama-qwen-27B.service     → Qwen3.8-27B 官方底模 + Unsloth UD-Q4_K_XL 量化 (200K, MTP2, ~67 t/s)
llama-qwen-27B-uc.service  → Qwen3.8-27B 免审查版 HauhauCS Q4_K_P (200K, MTP2, ~68 t/s)

二、硬件 / 软件环境

三、模型来源（Q4 换装后）

1. 官方底模 Qwen3.8-27B（默认主力，Unsloth 量化）

• 仓库：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-UD-Q4_K_XL.gguf（17.92GB，Unsloth Dynamic v3.0） + mmproj-F16.gguf（927MB）
• 为什么选 UD：Unsloth Dynamic 按张量重要性动态分配 bit，官方 benchmark 显示 UD-Q4_K_XL 在同 Q4 档质量领先（MMLU 5-shot 接近 Q5_K_M），且体积更小

2. 去拒答版 Qwen3.8-27B-Uncensored（HauhauCS Aggressive）

• 仓库：https://huggingface.co/HauhauCS/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-MTP-GGUF
• 加工：HauhauCS Aggressive 去拒答 profile，0/465 Refusals（直答无前置废话）
• 文件：Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q4_K_P.gguf（17.92GB） + mmproj-...-Aggressive-BF16.gguf（931MB，BF16 投影）
• Q4_K_P 是 K_P 新量化（5.25 BPW，高于 Q4_K_M 的 4.88），精度高一档
• 保留了 Qwen3.8 原生 NextN(MTP) 头（llama-gguf <file> r | grep nextn = 10 个张量）
• 附带 FastMTP-32K sidecar（0.9GB，宣称比原生 MTP 再快 ~35%）——已测试，弃用（见第六节）

3. 历史模型（已删除）

• Q5_K_M（官方 19.8GB / uncensored 19.5GB）：08-19 首测档，Q5+MTP 必崩 → 08-19 夜弃
• Q4_K_M（17.1GB）：08-19 终裁档，57-60 t/s；08-20 被 UD-Q4_K_XL / Q4_K_P 取代（新量化源同体积更高精度 + 更快）
• vLLM NVFP4 版（22GB）：32GB 卡实测上限 100K context，CUDA graphs 不可用，~20 t/s，已废弃

四、vLLM 路线实测（已废弃，保留记录）

部署参数（历史）

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

失败原因

结论

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

五、llama.cpp 路线实测（现役方案）

部署参数（2026-08-20 现役）

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

免审查版差异：-m .../Qwen3.8-27B-Uncensored/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q4_K_P.gguf + --mmproj .../mmproj-...-Aggressive-BF16.gguf + --alias qwen3.8-27B-UC

实测结果（2026-08-20，Q4 档 + MTP n-max 2）

• Q4_K_P 长生成比 UD-Q4_K_XL 快 ~10%（K_P 量化精度更高、解码更顺）
• 免审查实测：0/465 拒绝（官方发布口径），硬提示词直答

显存占用

200K context 的关键

考虑到hermes50%上下文压缩，100K是舒适点。
KV cache 全 4bit（--cache-type-k/v q4_0）+ 全量 offload（-ngl 99）+ --no-mmap 是 32GB 卡跑 200K 的三板斧。换 fp8/fp16 直接放不下。

六、MTP 在 Blackwell 上的崩溃演进史（重点）

阶段一：Q5 档 + MTP 必崩（08-19 实测）

• 现象：CUDA error: the launch timed out and was terminated（ggml-cuda.cu:106）
• 崩溃点随机：366/771/2346/3208/5904 token（非上下文满导致）
• 128K/256K × mmproj 有无全组合实测全部崩溃
• 升级 llama.cpp（70 commits 后）仍崩；驱动 595.91.07 不救
• 根因：decode kernel 单步时长超驱动看门狗（GSP heartbeat → Xid 8，Blackwell 强制）

阶段二：降 Q4 档 + MTP 扫档全过（08-19 夜）

• Q4_K_M（17GB）替代 Q5_K_M（19.8GB）后，MTP 全组合扫档压测零崩（128K 6/6、256K 10/10、长上下文 33K-110K 全过），57-60 t/s
• 推论：单步 kernel 时长与权重体量正相关，Q4 更小越不过看门狗线 → Q4 是 27B 量化安全线

阶段三：实战偶发 Xid 8（08-20 修正认知）

• 实际 agent 长会话仍偶发 2 例 Xid 8：上下文 6 万 / 11 万 token 处，活跃解码中崩溃
• 结论修正：扫档压测通过 ≠ 长期运行稳定；Q4 档是安全线而非保险
• 用户方法论：32GB 卡按 24GB 对待，Q4 档能跑顺为标准

阶段四：Q4 新量化源 + MTP 压测（08-20，现役）

• UD-Q4_K_XL / Q4_K_P 各跑 100K 预填 + 5800 token 长生成：双双零崩（PID 全程未变）
• 短负载 67-68 t/s，比旧 Q4_K_M + MTP（57-60）提速 ~15%

FastMTP-32K sidecar 实测（08-20，弃用）

• 宣称：比原生 MTP 再快 ~35%（文档 TG）
• 实测：--spec-draft-model <sidecar> 加载失败——tensor 'output.weight' has wrong shape; expected 5120, 248320, got 5120, 32768。sidecar 用 d2t draft-vocab trim（输出词表裁剪到 32768），需要 llama.cpp 上游未合入的自编译 patch（作者在 HF 讨论区贴的 qwen35.cpp diff）
• 社区实测：中文场景 FastMTP 接受率仅 ~40%，收益低于英文场景
• 结论：原生 embedded MTP 已 68 t/s，sidecar 弃用

已知 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 生成错误机器码
5. nvidia-open #1080：GSP heartbeat → Xid 8，Blackwell 强制机制

七、踩坑与经验

必须知道的

1. --jinja 必须加：3.8 官方 jinja 模板会把空 thinking 块包进输出，破坏多轮 agent 会话
2. 过思考是 3.8 的祖传毛病：用 reasoning_effort=medium 压住，medium 下实际思考量很小；preserve_thinking 保留跨轮思考连续性
3. 200K 是 32GB 卡的稳定档：288K 超预算；256K 能跑但实战偶发 Xid 8，200K 是最终定案
4. 档位零速度代价：速度只与实际上下文长度相关，与配置档位无关（1K-12K 负载 tg 与 256K 档持平）
5. 量化选型：Q4 档是 27B 安全线（用户方法论：32GB 卡按 24GB 对待）——Q5+MTP 必崩、Q4 扫档全过；同体积下 UD/K_P 新量化比 Q4_K_M 更快

MTP 相关

6. MTP 参数：--spec-type draft-mtp --spec-draft-n-max 2（误写 mtp 启动即失败 unknown type）
7. MTP 收益：Q4 档 ~45% 提速（67 vs 无 MTP 40-41）；acceptance 实测 54-68%（agent 工具调用负载下偏低属正常）
8. 关 MTP 参数：--spec-type none（新版无 --no-speculative）
9. 崩溃模式判别：launch timed out = decode kernel 超看门狗（受 ctx 长度影响）；illegal memory access = 显存不足——两者处理方向完全不同

下载验证

10. 字节级核验：curl -sIL 对比远程 Content-Length vs 本地 stat，diff=0 才过；大文件再跑 SHA256 对照模型卡
11. 别下错版本：同名量化可能差几百万字节（带不带 MTP、带不带 vision）；MTP 提速必须选带 NextN 头的版本（无 noMTP 后缀）

服务管理

12. 切模型 = 切服务：8000 端口互斥，切换前先停另一个（互斥切换脚本承担）
13. 全部 disabled：按需手动 start，不开机自启
14. 测速必带负载条件：中文散文 vs 工具调用 JSON 差一倍是草稿接受率差异；agent 场景报数必须用 agent 真实工作负载

八、接入 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 + Q4 档 + MTP，67-68 t/s 全链路零崩；MoE A3B 用 vLLM + MTP，144 t/s；同机器双方案按场景切。

Blackwell sm_120 的现实（08-20 修正版）：

• llama.cpp MTP 在 Q5 档必崩，但 Q4 档 + MTP 是可行组合（67-68 t/s，长压测零崩）
• 实战长会话仍偶发 Xid 8（6万/11万 token 处）——降 ctx / 关 MTP 是兜底手段，Q4 档是安全线而非保险
• 新量化源（Unsloth UD / HauhauCS K_P）同体积更高精度、更快——换量化源比换框架收益大

如果要速度：用 A3B（144 t/s）
如果要质量 + 免审查：27B Q4_K_P + MTP（68 t/s，0/465 拒绝）
如果要通用主力：27B UD-Q4_K_XL + MTP（67 t/s）
如果长会话偶发崩溃：降 ctx 到 128K 或关 MTP（-30% 速度）换零崩

附：实测数据时间线