通过多令牌预测，Gemma 4 在 MLX 上运行更快

2026 年 6 月 29 日

Gemma 4 在 Ollama 0.31 中获得了显著的速度提升。在 Apple Silicon 上，它在编码代理基准测试中平均令牌生成速度提高了近 90%。这一加速默认开启，且不会改变模型的输出质量。

速度提升源于多令牌预测（MTP）技术。Gemma 4 配备了一个小巧快速的草稿模型，与主模型并行运行，负责提议接下来的几个令牌。主模型随后在单次验证中检查这些提议，并保留与其一致的令牌。由于草稿模型体积远小于主模型，其提议成本低廉；一旦提议正确，模型就能以生成一个令牌的代价提交多个令牌。

代码文本尤其具有可预测性：包含大量闭合括号、重复标识符和样板代码，因此草稿模型的提议被频繁接受。这对编码代理尤为重要，因为它们需要持续调用模型来读取文件、运行工具和处理任务。更快的生成速度使这些代理的响应更加灵敏。

可靠地实现这一效果是难点。理想的草稿令牌数量随情况变化，草稿过多可能使多令牌预测比不进行推测解码更慢。Ollama 在运行时自动调整这一数量，因而无需用户配置即可获得加速。

我们使用 Aider 多语言基准进行测量，该基准通过真实编程任务运行编码代理。MTP 的收益严重依赖工作负载，合成基准几乎可以展示任何结果。这些数字反映了实际使用中的预期表现。

生成速度

令牌/秒 · 越高越好

开启 MTP 后，Gemma 4 在 Aider 多语言基准上令牌生成速度提升近 90%。 数据基于 M5 Max 上的 Gemma 4 12B（nvfp4）。

工作原理

三项改进协同工作：草稿长度的选择方式、引擎每轮运行的机制，以及 GPU 处理任务的方式。

自动调整草稿长度

并不存在一个普适的最佳草稿令牌数量。它取决于模型、量化方式、硬件以及文本在特定时刻的可预测性。在一套配置上表现良好的值可能在另一套上失效。草稿数量过少会浪费性能；草稿过多则会花费更多时间检查被拒绝的提议，反而得不偿失，最终使 MTP 比普通解码更慢。

Ollama 在运行时确定草稿长度。在生成过程中，它追踪提议被接受的概率以及每次验证所需的时间，然后选择能产生最高令牌速率的长度。随着文本变化，它会持续调整；当提议不再被接受时，它会退回到逐令牌解码模式。因此，当推测解码不再有帮助时，它不会拖慢生成速度。

引擎中的推测解码

每一轮从草稿模型开始。它预测一个令牌，将其反馈以预测下一个，如此重复直到获得一串短提议。主模型随后一次性验证整个提议序列，在每个位置采样以确定哪些提议被接受。整个流程在 GPU 上作为单次传递完成：草稿、采样、验证以及后续采样，中间无需返回 CPU。

接受的令牌被保留。被拒绝的令牌处理起来更复杂，因为在被拒绝时它们已经写入了缓存——模型保存的可重用状态，用于避免重新计算之前的令牌。撤销它们代价很低。引擎在每个提议之前记录一个回滚点，拒绝操作将状态回滚到最后一个被接受的令牌。更早之前的令牌不会被触及或重新计算。

更快的批量验证方式

大部分成本来自验证，而非草稿。草稿模型较小，因此提议令牌成本低。验证需要在整个提议批次上运行完整模型，而批次的规模通常很尴尬——2 到 8 个令牌。矩阵乘法内核通常针对单个令牌（解码）或大批量（预填充）优化，而几个草稿令牌恰好介于两者之间。

我们为 MLX 贡献了一个针对这种情况的内核，其他模型也可以使用，而不仅限于 Ollama 中的 Gemma 4。该内核一次性读取并解包每个权重块，并在整个批次中复用，而不是为每个令牌重复读取权重。在 M5 Max 上使用 nvfp4 时，这使得 Gemma 4 最大的矩阵乘法运算速度提升了 2 到 2.5 倍。计算本身完全相同，加速源于消除了冗余工作。

开始使用

下载 Ollama 0.31 或更高版本的 macOS 版：

下载 Ollama

然后使用 ollama launch 启动由 Gemma 4 驱动的编码代理：

ollama launch claude --model gemma4:12b-mlx

注意：如果您之前下载过 Gemma 4，请使用 ollama pull gemma4:12b-mlx 重新拉取以获得支持 MTP 的版本。

ollama launch 也支持 Codex、Droid、OpenCode、Copilot 等模型。

Gemma 4 是首个获得此性能改进的模型，后续将有更多模型跟进。