Multi-token prediction（MTP）于 5 月 16 日通过 am17an 提交的 PR #22673 合并进了 llama.cpp。该功能以 beta 形式发布 — 隐藏在 llama-cli 和 llama-server 的 --mtp 标志之后，默认关闭。
合并后 24 小时内发布的一项社区基准测试报告：Qwen 3.6-27B 在单张 RTX 5090 上以 65 词元/秒 解码，相比未启用 MTP 时的 38 词元/秒 — 在 Q4_K_M 下实现 1.71× 加速，在并排提示对比中没有可察觉的质量退化。目前这是仅有的一个数据点；更广泛的构建×模型覆盖还需要数个刷新周期。
MTP 究竟是什么
模型在训练时配备额外的输出头，从同一个共享主干隐藏状态同时预测接下来的 2、3 或 4 个词元。主头随后重新运行，验证候选序列。若推测词元匹配，相当于免费获得这些词元。若不匹配，则对该步骤回退到逐词元解码。
这把 speculative decoding 传统上做的事情 — 在大 target 模型旁运行一个小 draft 模型 — 压缩到一个内置预测头的单一模型中。开销大致相当于每个额外预测位置多一层 transformer，而非完整的第二个网络。显存开销很小；验证失败时的 throughput 代价是主要缺点，但在为 MTP 训练过的模型上命中率足够高，平均解码会明显更快。
这对模型提出的要求
MTP 需要训练时就嵌入的预测头 — 运行时无法事后合成。引用的基准测试使用 Q4_K_M 的 Qwen 3.6-27B；对于检查点不含额外头权重的任何模型，--mtp 标志都是空操作，所以默认开着不会有害。
DeepSeek-V3 论文让 MTP 作为训练时辅助目标被广泛知晓。DeepSeek-V3 论文之后发布的哪些 open-weights 模型在其公开检查点中带着这些头 — 以及向前预测多少个位置 — 我们会在下次数据刷新时按模型逐一归档，直接引用各自的 model card，而不是依据架构传闻。
注意事项
- beta 就是 beta。 PR #22673 本身已经标注了这点；预期会有粗糙之处，在生产中依赖它之前请关注链接的 llama.cpp issue 跟踪器。
- 加速幅度随解码瓶颈而变化。 在 compute 充裕、带宽充足的机器上推测路径有余量；在带宽受限的机器上收益缩水。5090 上的 1.71× 是这个梯度上的一个点 — 不要假设它具有普遍性。
启用方法
5 月 16 日之后从 main 分支构建 llama.cpp，并向 llama-server 或 llama-cli 传递 --mtp。Ollama、LM Studio 和 Jan 的上游支持通常比 llama.cpp main 落后一个发布周期 — 在各运行时的 release notes 中查看首个采纳的构建。
来源
- llama.cpp PR #22673 — MTP 支持（am17an，2026-05-16 合并）
- 社区 Gist：用 MTP 运行 Qwen 3.6（RTX 5090 上 38 → 65 词元/秒，基准测试）
- Multi-token prediction 教程 — DataCamp