Qwen3.8-27B 在 8 月 14 日开源，Apache 2.0 协议，可以免费商用。微信这一周本地部署圈最兴奋的，不是跑分提升，而是一个叫 MTP 推测解码的开关：这代 27B 稠密模型的 GGUF 权重里直接内置了 MTP 草稿头，不用额外下载独立草案模型，在 llama.cpp 里加一组参数就能用。今日头条听起来像白送的午餐，但把最近一周四个硬件平台的实测数据摆到一起，我发现这顿午餐是按硬件发牌的。
先看这张分化表：
硬件平台 | 量化 | 不开 MTP | 开 MTP 后 | 倍数 | 甜点 n-max |
|---|---|---|---|---|---|
Strix Halo 128G 统一内存（Vulkan） | UD-Q4_K_XL | 11.8 tok/s | 31.8 tok/s | 2.69 倍 | 5 |
Ryzen AI Max+ 395 128G（Linux Vulkan） | Q4_K_M | 约 12.5 tok/s | 22.1 tok/s | 约 1.8 倍 | 4 |
24G 独显（3090/4090） | Q4_K_M | — | +30%～100% | 1.3～2 倍 | 2（代码可试 3） |
RTX 4070 12G（Windows） | UD-Q3_K_XL | 8.21 tok/s | 负收益 | <1 | 不建议开 |
同一个开关，一边是 11.8 冲到 31.8 tok/s 接近三倍，一边是开了反而更慢。这正应了那句话：MTP 不是一键开挂，参数调错、运行环境不对，不仅没有提速，性能反而倒退。今日头条
为什么分化这么大
别把 MTP 当成纯加速开关，它本质是一场对赌：每一步由草稿头先猜出 N 个 token，主模型一次性批量校验，猜中了一趟输出多个，猜错了白烧算力。所以它对两件事特别敏感：一是显存和内存余量，草稿头和它的 KV 缓存都要额外占地方，统一内存平台没有显存墙，敢把 n-max 开到 4、5，小显存独显本来就捉襟见肘，一开就崩；二是框架和环境适配，这个模型架构代号叫 qwen3_5，是 48 层线性注意力加 16 层全注意力的混合架构，老版本框架会直接报错不认识。今日头条还有一点要提前说清：MTP 只影响生成速度，不会改变预填充速度，长提示词的首字延迟它救不了。今日头条
开开关之前，先把显存账算明白，量化档位按显存对号入座：16G 设备选 UD-Q3_K_XL 约 13.4GB，24G 独显的主力是 UD-Q4_K_XL 约 17.9GB，32～64G 高配上 UD-Q8_K_XL 约 31.5GB，Blackwell 50 系则可以直接跑 NVFP4 约 23.4GB。微信
按硬件决定开关
统一内存、大内存平台（Strix Halo、Ryzen AI Max+ 395）：开，且把 n-max 拉高。
Strix Halo 128G 的实测曲线最有代表性：UD-Q4_K_XL 不开 MTP 基线 11.8 tok/s，n-max=2 冲到 25.9，=3 到 28.2，=4 到 30.4，=5 达到峰值 31.8，再往上 =6 回落到 30.8、=7 只剩 27.2。今日头条接受率从 88.6% 一路降到 71.1%，但甜点仍然落在 5，Q6_K_XL 量化也是同样在 n-max=5 到达 25.2 tok/s 的峰值。
395 这边结论一致：不开 MTP 时 Q4_K_M 只有约 12.5 t/s、Q6_K 只有 9.7 t/s，开启后分别到 22.1 和 17.2 t/s，接近翻倍，关键就是 --spec-type draft-mtp 加 n-max=4。微信
AMD 官方博客在同一台 395 上公布的成绩是 24.5 t/s，脚注点破的关键同样是 MTP=4。微信
还有一个容易误判的参照：NVIDIA DGX Spark（GB10）的实测里，vLLM 开 FP8 加 MTP 约 11 tok/s，llama.cpp 跑 Q4_K_M 是 11.85 tok/s，两边几乎打平。今日头条所以统一内存平台上 MTP 不是 llama.cpp 的专属福利，量化减重也不必然等于加速，别拿台式独显的预期去套一体机。
环境选择也有讲究：同一台 Strix Halo，Linux 的 RADV 开源驱动比 Windows 快 18%～24%，Vulkan 后端在投机验证阶段又比 ROCm 快约 29%，双系统用户建议把推理留在 Linux 侧。微信
24G 独显（3090/4090/5090 24G 档）：开，但 n-max 守在 2。
命令里的 --spec-type draft-mtp 被社区称为整套配置中最重要的参数，内置预测头提前猜、主模型一次校验，实测生成速度提升 30%～100%。今日头条
注意预测深度不是越高越好：模型内置的预测头只有一层，猜得太深会被主模型大量否决，反而拖慢速度，2 是 24G 显卡的最优平衡点，代码场景可以试 3。今日头条
12G 及以下小显存 + Windows：先别开这个开关。
4070 12G 的实测结论很直接：理论上能加速的 MTP，在 12G 小显存 Windows 环境下频繁触发 CUDA graph warmup reset，开销反而增加，速度不升反降，作者的建议是优先跑原生推理，想加速改用普通 draft 模式。微信
这台机器的正确姿势是 UD-Q3_K_XL 约 8.2GB 权重全部 28 层卸载 GPU，生成 8.21 tok/s，这个成绩对日常对话、写脚本已经够用。微信
想在这档显存上尝试加速，建议用普通 draft 模式：–spec-type draft --spec-draft-n-max 3。微信
两套可直接抄的启动参数
24G 独显版，社区在模型发布 24 小时内调出来的完整命令：
```
llama-server -m Qwen3.8-27B-Q4_K_M.gguf -ngl 999 -fa on --jinja -np 1 -t 12 --spec-type draft-mtp --spec-draft-n-max 2 --spec-draft-type-k q8_0 --spec-draft-type-v q8_0 --cache-type-k q8_0 --cache-type-v q8_0 --temp 1.0 --top-p 0.95 --top-k 30 --min-p 0.0 --chat-template-kwargs ‘{“reasoning_effort”:“medium”}’
```
统一内存机版（Linux，395 用 n-max=4，128G Strix Halo 实测可推到 5）：
```
llama-server -m Qwen3.8-27B-UD-Q4_K_XL.gguf -ngl 999 -fa on --jinja -c 32768 --spec-type draft-mtp --spec-draft-n-max 4 -np 1 --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0
```
开启后的实测效果大致是这样，界面里 Q8_0 量化带 MTP 跑出 18.75 t/s：
开开关前还要知道的三件事
第一，版本门槛是硬性的。Qwen3.8 的 MTP 能力要求 llama.cpp 在 b10397 及以上，老版本无法完整支持，近期社区实测普遍已经用到 b10437、b10448。今日头条
第二，KV 缓存量化是另一个顺手的小加速。把 KV 缓存从 f16 切到 q8_0、q4_0，预填充波动在 2% 以内，生成速度能再提 4%～6%。今日头条12G 档则建议压到 q4_0，16k 上下文只占几十兆显存，是必开参数。微信
第三，量化档位本身的影响比 MTP 更大。同硬件下 Q8_0 比 Q5_K_XL 生成慢 27%～29%，稠密模型每个 token 都要读全部权重，文件体积直接决定解码速度。今日头条在 Q4 和 Q8 之间纠结的朋友，先定量化再谈加速。
接下来值得盯的三个信号
一是 Qwen3.8 的 MoE 版本。现阶段社区还没有产出 Qwen3.8 MoE 版本，不少使用者在期待后续 MoE 权重发布。今日头条不过参考此前 Qwen3.6 MoE 的实测，MTP 对 MoE 的收益明显弱于稠密模型，届时别直接套用这次的预期。
二是 50 系 Blackwell 显卡的 NVFP4 路线。新卡可以不使用 GGUF 直接运行 NVFP4 量化，但目前部分推理框架还没有完整适配内置 MTP 模块，需要查看项目更新日志，不能默认开箱即用。今日头条
三是 Windows 小显存的 MTP warmup 重置问题会不会在后续版本修复，12G 卡用户升级前可以留意 llama.cpp 的更新说明。
最后问一句：你在用什么硬件跑 Qwen3.8-27B，开了几档 n-max，测出多少 tok/s？评论区报一下配置和速度，样本多了，这张按硬件算的账才能真正变成选型表。
