MTP 关键在于接受率

Reddit r/LocalLLaMA 新闻
mtp benchmark gemma4 mlx-vlm performance apple-silicon

摘要

一位用户在 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。
查看原文

相似文章

MLX 上新的 Gemma 4 MTP？

Reddit r/LocalLLaMA

Google 发布了用于 Gemma 4 的多 token 预测草稿器，通过推测性解码加速推理，但目前对 MLX 的支持尚未确认或不可用。