MLX 上更快的 Gemma 4：多 token 预测实现近 90% 提速

Gemma 4 在 Ollama 0.31 中速度大幅提升。在 Apple Silicon 上，针对一个编码智能体基准测试，其生成 token 的平均速度提升了近 90%。该加速默认开启，且不会改变模型的输出：

这一加速来自多 token 预测（MTP）。Gemma 4 内置了一个小巧快速的草稿模型，与主模型并行运行，提前预测接下来的若干 token。主模型随后在单次前向中验证这些预测，并保留它认可的 token。由于草稿模型仅为主模型体积的一小部分，它的预测开销很低；而一旦预测正确，模型就能以一次推理的成本提交多个 token。

代码尤其具有可预测性。代码中充满了闭合括号、重复的标识符以及样板代码，因此草稿模型的预测经常被采纳。这一点对编码智能体最为关键——它们在读取文件、调用工具、推进任务的过程中会持续调用模型。更快的生成速度让这些智能体的响应明显更加敏捷。

困难的部分在于如何稳定地实现这一效果。每一时刻理想的草稿 token 数量都在变化，如果草稿过长，MTP 反而可能比不做推测更慢。Ollama 会在模型运行过程中自动调节这一参数，因此无需任何配置即可获得加速。

我们在 Aider polyglot 基准上进行了实测，该基准让真实的编码智能体完成真实的编程任务。MTP 的收益很大程度上取决于具体负载，合成的基准测试几乎可以给出任何想要的结果。以上数据反映的是实际使用中的预期表现。

生成速度 tokens/s · 数值越高越好

原理

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

草稿长度的自动调节

并不存在一个"最佳"的草稿 token 数量。它取决于模型、量化方式、硬件，以及当前文本的可预测性。在一种设置下表现良好的值，在另一种设置下可能完全不合适。草稿过少会浪费性能；草稿过多则会把时间浪费在验证被拒绝的预测上，MTP 反而会比普通解码更慢。

Ollama 在运行时会动态决定草案长度。生成过程中，它会跟踪提案被接受的频率以及每次验证的耗时，然后选出能让每秒产出 token 数最多的长度。随着文本变化它会持续调整，而当提案不再被接受时，就回到普通的逐 token 解码。因此，一旦推测不再起作用，就不会拖慢生成速度。

引擎中的推测解码

每一轮从草案模型开始。它预测一个 token，再把该 token 反馈回去预测下一个，如此重复，直到凑出一小段提案。然后主模型一次性验证整段提案，在每个位置采样以决定哪些提案被接受。起草、采样、验证以及随后的采样全部在 GPU 上一次性完成，中间不返回 CPU。

被接受的 token 会被保留。被拒绝的 token 处理起来更复杂一些，因为在被拒绝时它们已经写入了缓存——也就是模型为避免重复计算先前 token 而复用的运行状态。撤销这些写入的开销很小：引擎在每次提案前记录一个回滚点，一旦拒绝就回退到上一个被接受的 token。更早的内容不会被改动，也不会被重新计算。

更快的批量验证方式

主要开销在验证，而不是起草。草案模型很小，提出 token 很便宜。验证则是让完整模型一次性处理整批提案，而这个批量的尺寸往往很尴尬，通常只有 2 到 8 个 token。矩阵乘法内核通常是为单个 token（decode）或大批量（prefill）设计的，零星几个草案 token 正好夹在两者之间。

我们为 MLX 贡献了这种场景下的内核，其他模型也能使用，不只是 Ollama 里的 Gemma 4。它把每块权重读取并解压一次，然后在整个批量中复用，而不是为每个 token 重复读取权重。在搭载 nvfp4 的 M5 Max 上，这让 Gemma 4 最大的矩阵乘法速度提升了 2 到 2.5 倍。计算本身完全相同，加速来自消除了冗余工作。

开始使用

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

下载 Ollama

然后用 ollama launch 启动一个由 Gemma 4 驱动的编程 agent：

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

注意：如果之前下载过 Gemma 4，请重新拉取一次以获取带有 MTP 的版本：ollama pull gemma4:12b-mlx。

ollama launch 同样支持 Codex、Droid、OpenCode、Copilot 等工具。

Gemma 4 是首个获得此项性能提升的模型，后续会有更多模型跟进。