llama.cpp 原生 MTP 推测解码实测：稠密提速明显，MoE 收益有限

llama.cpp 近期合并了基于模型自带 MTP（Multi-Token Prediction）头的原生推测解码支持，参数 --spec-type draft-mtp 可让推理时直接利用模型自身的多 token 预测头，无需额外外挂 draft 模型。Qwen3.6、DeepSeek、GLM 等已发布自带 MTP 头的模型均可启用此路径。此前在 4 月合并的推测解码 checkpointing（PR #19493）为该特性在混合/循环架构上的稳定运行打下了基础，旧的 rollback 方式在这类架构上并不奏效。

稠密模型：实测提速明显

社区反馈显示，稠密架构从原生 MTP 中获得的加速相当可观。以 Qwen3.6-27B 稠密版为例，常见报告区间在 1.4x 到 2.2x 之间。这类模型每次 decode 步都有完整的 FFN/attention 开销，MTP 多预测几个 token 并由主模型一次性校验，能节省的 wall-clock 时间非常显著。

MoE 模型：收益微弱甚至为零

MoE 架构的表现则明显分化，许多场景下加速收益接近零。背后的逻辑也容易理解：MoE 每一步解码只激活少量参数，decode 步本身已经很轻，留给 MTP 优化的开销空间有限。Gemma 4 上也复现了同样的模式——稠密 31B 拿到明显的 MTP 加速，而其 MoE 变体几乎纹丝不动。

传统 draft / ngram 方案不再可靠

相比之下，老式推测解码（外挂小 draft 模型、ngram 匹配、ngram-cache / ngram-mod 等）在独立基准下表现参差。有用户在单卡 RTX 3090 上对 Qwen3.6-35B-A3B 做了详细测试，发现 ngram-cache、ngram-mod 和经典 draft 模型方案均无净加速，部分配置甚至出现净负收益。如果目标是把 token/s 提上去，目前更值得押注的是模型自带的原生 MTP 头，而不是旧的 draft 技巧。

落地建议

对于本地部署用户：

• 优先确认所用模型是否原生带 MTP 头，否则 --spec-type draft-mtp 无效；
• 稠密模型可作为首选加速手段；
• MoE 模型若主要瓶颈不在 decode 步，可不必强上 MTP；
• 老式 ngram / draft 模型方案建议先小规模验证再上生产。