MTP 关键在于接受率
摘要
一位用户在 M4 Max Studio 上使用 mlx-vlm 对 Gemma 4 进行了 MTP（多令牌预测）基准测试，发现它在代码生成方面表现出色（速度快 1.53 倍，接受率 66%），但对 JSON 输出不利（速度慢 50%，接受率仅 8%），对长篇散文则影响中性，表明当令牌接受率低于 50% 时，MTP 的优势便荡然无存。
所以我对 MTP 相关内容感到非常兴奋，特别是因为 Gemma4 已经成为了我日常使用的工具。我下载了最新的 mlx-vlm 进行了一些测试，结果却让人失望。
| 工作负载 | MTP 关闭 | MTP 开启 | 结果 | 草稿接受率 |
|---|---|---|---|---|
| 代码生成 | 75 tok/s | 114.8 tok/s | 1.53× 更快 | 66% 槽位 |
| 长篇散文 | 75 tok/s | 71.1 tok/s | 0.95×（持平）| 31% 槽位 |
| JSON 输出 | 51.3 tok/s | 25.6 tok/s | **0.50× 更慢** | 8% 槽位 |
- 代码生成是典型的"写一些 Python 函数来做 X"
- 长篇散文是"写一篇 800 字关于唐代纸币的论文"
- JSON 输出是我的核心用例，我给 LLM 一个项目列表，按照某些规则让它们按相似性分组，然后以结构化形式输出。*
所以如果你想用于本地编程，MTP 非常好。如果不是，可能就不太理想。我的回归测试似乎表明，一旦令牌接受率低于 50%，开销就会抵消掉收益。所有测试都在配备 Gemma4-26b-a4b 的 M4 Max Studio 上进行。
*给各位开发者的彩蛋：Gemma 的 JSON 结构指令跟踪能力相当不错，我发现使用结构化输出会让令牌生成速度下降约 20%。所以更快的做法是稍微接受一些"不那么规范"的 JSON，然后在运行时处理它；因此这些都是关闭 json_schema 的情况下测试的，毕竟 mlx-vlm 本身也不支持 spec-decode 的 json_schema。
相似文章
充分发挥MTP的性能
一份通过调整n_max参数来优化MTP（多令牌预测）性能的指南，附带了多种模型（如Gemma-31b和Qwen）在P100和V100 GPU上的基准测试结果。
我在 vLLM 和 llama.cpp 上对 Gemma 4 和 Qwen 3.6 测试了 MTP —— 推理速度提升 3.34 倍，这是我的发现（RTX 6000 PRO）。
使用 vLLM 和 llama.cpp 对 Gemma 4 31B 和 Qwen 3.6 27B 进行的多令牌预测（MTP）基准测试显示，推理速度最高提升 3.34 倍，最优推测令牌数量因模型和引擎而异。
MTP（多令牌预测）：在AMD Strix Halo和Radeon 9700 AI Pro上实现2倍令牌生成加速
MTP（多令牌预测）可以将LLM推理速度提高2倍，尤其适用于编码代理。本视频展示了Qwen 3.6在AMD Strix Halo和双Radeon 9700上的性能提升。
LLaMA.cpp的多令牌预测（MTP）——Gemma 4速度提升40%
llama.cpp中新的多令牌预测（MTP）实现为Gemma 4模型带来了40%的速度提升，已在MacBook Pro M5Max上测试。文章提供了量化GGUF模型和补丁源代码的链接。
MTP+GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 - llama.cpp
一位用户在 llama.cpp 上使用 GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 标志对令牌生成速度进行基准测试，比较启用和未启用 MTP（多令牌预测）时的性能。结果显示，在 RTX5090 上使用 Qwen3.6-27B 模型时，启用 MTP 后速度从 49 tok/s 显著提升至 64 tok/s。