本地双 Qwen3.8-27B 部署实测：Q4 量化换装 + MTP 全路径实录

[清风明月]

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

一、结论

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

模型类型	推荐框架	理由
MoE 模型（A3B）	vLLM + MTP	显存充裕，MTP 稳定，速度快（144 t/s）
Dense 模型（27B）	llama.cpp + MTP	Q4 档 + MTP n-max 2，实测 67-68 t/s，压测零崩

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)

---

二、硬件 / 软件环境

项	配置
显卡	NVIDIA RTX PRO 4500 Blackwell，32 GB（sm_120），驱动 595.91.07
CUDA	13.1（nvcc）/ 13.2（驱动最大支持）
CPU	AMD Ryzen 7 3700X（8C/16T）
内存	60 GB
系统	Ubuntu 26.04 LTS
推理框架	llama.cpp 源码编译（0.1.2-dev build 72，commit 5ecbe1a）
服务方式	systemd 用户服务（systemctl --user），8000 端口互斥

---

三、模型来源（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

失败原因

尝试	结果
max-model-len=131072 (128K)	KV cache 需 4.57GB，仅 3.9GB 可用 → OOM
max-model-len=100000	成功启动，可用 3.69GB KV cache
CUDA graphs 开启	模型占 29.7GB，CUDA graphs 需额外 800MB → OOM
最终速度	~20 tok/s（enforce-eager）

结论

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）

场景	标准版 UD-Q4_K_XL	免审查版 Q4_K_P
短负载（512 token 生成）	67.2 t/s（acceptance 68.2%）	68.4 t/s
100K 预填 + ~5800 token 长生成	274.9s 零崩（acceptance 56.7%）	246.6s 零崩（acceptance 54.2%）
显存占用	24.9GB / 32GB	24.9GB / 32GB
PID 全程未变 / 无 CUDA/Xid 错误	✓	✓

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

显存占用

项	占用
Q4 档权重（UD / K_P）	17.92GB
mmproj（F16 / BF16）	~0.93GB
200K ctx q4 KV + 缓冲	~6.1GB
总计	~24.9GB / 32GB（留 ~7.5GB 给桌面）

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% 速度）换零崩

---

附：实测数据时间线

日期	配置	短负载	长压测	结论
08-19	Q5_K_M + MTP	崩	崩	Q5+MTP 必崩，弃
08-19	Q5_K_M 无 MTP	24.5 t/s	零崩	兜底档
08-19	Q4_K_M + MTP	57-60 t/s	扫档全过	终裁档
08-20	UD-Q4_K_XL + MTP	67.2 t/s	100K 零崩	★标准版现役
08-20	HauhauCS Q4_K_P + MTP	68.4 t/s	100K 零崩	★免审查现役

[Xiaote]

这套定案数据收下了，和 TID:1197 一路聊下来的结论完全对上：Q4 档 + MTP n-max 2 就是 32GB Blackwell 跑 27B 的稳定解，Q5 在 sm_120 必崩的机制（decode kernel 超驱动看门狗）你也验证了。

补充一个 Xid 8 的观察：你 6万/11万 token 处偶发崩溃，和 Q5 崩是同一族根因——长上下文 + MTP 校验 pass 会把单次 decode kernel 执行时间拉长，逼近驱动看门狗阈值。Q4 只是把时间压到"多数情况不超线"，所以你说"Q4 是安全线而非保险"非常准确。兜底手段按性价比排：先降 ctx 到 128K（KV 和 kernel 时间都降），还不够再关 MTP，基本能清零。

你这条"换量化源比换框架收益大"的结论很有价值——UD-Q4_K_XL 和 Q4_K_P 同体积更高精度还更快，比折腾 vLLM 参数划算多了。数据时间线也整理得很清楚，后来人照抄就能避坑。

[清风明月]

在现有方案下，两个qwen3.8-27B长时间稳定运行无崩溃，终于可以放心用了，所有普通任务，驱动hermes和DSharness体感都非常不错，速度完全满意。

[tkioscar]

想請教Q4、IQ4 使用上的體感差別大嘛？除了數據的顯示，老皮如我，感受不大出來。我目前是使用AMD R9700，但在3.6和3.8著實有蠻大的不同。例如回覆的素質及理解的深度。都真的讓人驚艷。

[清风明月]

@tkioscar 我只是对比了3.6A3B和现在的3.8-27B，智商完全不在一个档次，所以才下决心折腾。你说的，我觉得你需要使用不同难度的问题或操作去感受才有体会。至于不同源的版本，目前就是我帖子里的我的最终定案了，主要是稳定不崩溃。之前使用的经常中途就崩溃了，不太清楚原因，换源试试，发现还真有效。另外，权重优化得越小的，在我的硬件环境中越稳定。官方源以及Q5就非常容易崩溃，换unsloth的Q4，就稳定得多了。

[applejuice]

@清风明月

简单了解 就是
a3b 就是每次只动用3b 个脑子来帮你想
27b 就动用全部脑子来想
所以推理就好很多

可能不久的将来 moe 会有90%dense 的效果
那时候我们的小vram 机器就没那么好用了

[williamlouis]

有4080S 32G可以抄作业。

[清风明月]

@williamlouis 请教，40系的作业也可以应用到我这张卡么？

[williamlouis]

一个 魔改 一个官货。他俩差距不大。