2026-06-06 — 次浏览

Gemma 4 多词元预测登陆 llama.cpp：自推测解码在本地推理进入主流

llama.cpp 于 2026 年 5 月合并了原生多词元预测（MTP）推测解码（PR #22673），报告在 Qwen3.6-27B 上以约 72% 的草稿接受率达成单流生成约 2.4 倍加速，草稿头从同一个 GGUF 加载并拥有自己的 KV-cache。2026 年 6 月 6 日，后续的 Gemma 4 MTP PR（#23398）被标记为可供审查，将此技术扩展到 Google 的 Gemma 4

推出了什么

llama.cpp 现在原生支持多词元预测（MTP）推测解码。核心基础设施落地于 PR #22673（“llama + spec: MTP Support”），于 2026 年 5 月 4 日开启并于 2026 年 5 月 16 日合并。2026 年 6 月 6 日，后续的 Gemma 4 MTP 工作（PR #23398）被标记为可供审查，将同一套机制扩展到 Google 的 Gemma 4 家族。

对本地用户而言，重点是单流延迟。传统的推测解码通过运行一个独立的小型草稿模型来猜测接下来的几个词元，再由大型模型一次验证，从而加速生成。MTP 将这个想法折叠进模型成品本身：一个轻量级的预测头在每次前向传递中提出数个词元，因此你不必寻找、调整大小并对齐一个独立的草稿模型，就能获得推测解码的加速。

来自合并的数字

在已合并的 Qwen3.6-27B 路径上，PR #22673 报告使用 3 个草稿词元时约 2.4 倍的墙钟加速（83.8 秒对比 201 秒基准），接受率为 72.18%，而使用 2 个草稿词元时约 2.2 倍，接受率为 82.58%。它也在 Qwen3.6-35BA3B MoE 变体上经过验证。此设计从同一个 GGUF 文件加载 MTP 头，因此不需要额外分发任何东西，而且它保有自己的上下文与 KV-cache。

Gemma 4 PR 将此推向不同的血统。它在密集型 31B 模型上报告超过 2 倍，接受率视配置而定约在 43% 到 70% 之间，其中一个范例从约 40 tok/s 提升到约 100 tok/s。Q8 量化的运行落在约 1.74 倍到 1.97 倍。该 PR 涵盖 31B 与 26B-A4B 变体，并排除较小的 E4B 与 E2B。

模型 / PR	草稿词元	接受率	加速
Qwen3.6-27B (PR #22673, merged)	3	~72%	~2.4x
Qwen3.6-27B (PR #22673, merged)	2	~83%	~2.2x
Gemma 4 dense 31B (PR #23398, in review)	varies	~43-70%	over 2x
Gemma 4 31B Q8 (PR #23398, in review)	varies	varies	~1.74-1.97x

一个细微之处：Gemma 的做法不同

有一个值得了解的架构分支。Qwen 风格的路径使用打包在同一份权重内的 MTP 头。相比之下，Gemma 4 提供由 Google 训练的独立 “assistant” / drafter 模型（Gemma4AssistantForCausalLM 类别），对齐到 Gemma 4 自身的输出分布，并加上需要在加载器中自定义映射的新缩放张量。两种方法追求相同的目标，即高接受率，让验证器很少拒绝，但管线与你抓取的文件有所不同。一个独立的 libllama MTP API（PR #18886）仍处于草稿状态，因此即使服务器路径可用，其公开的 C API 尚未定案。

为何对本地设备重要

接受率就是全部的关键，而且它取决于工作负载。可预测的文字，例如代码与结构化输出，会在这些范围的高端被接受；自由形式的散文接受度较低，实现的加速也随之下降。PR 之外的社区报告，对于短而多样的生成，聚集在较接近 1.7 倍到 1.9 倍，这对于交互式聊天而非批次代码补全才是诚实的预期。这个收益是真实的，但它是一次一个流的延迟收益，而非繁忙的多用户服务器的吞吐量收益——在那种情况下连续批处理已经让 GPU 饱和。

实务者注记

如果你在本地运行单一用户的编码助手，这是目前最便宜的加速方式：拉取一个近期的 llama.cpp 构建，使用支持 MTP 的 GGUF（今天用 Qwen3.6，一旦 #23398 落地就用 Gemma 4），并从 2-3 个草稿词元开始。把报告的接受率当作你真正的基准，而非营销的倍数，并依你的提示调整草稿词元数量；在低接受率的散文上使用过多草稿可能会抹去收益。在假设功能已启用之前，先验证你的构建确实暴露了 MTP 服务器标志，因为这个功能很新，且 C API 仍在变动中。

被低估的角度

大家都引用加速倍数，但策略性的转变在于谁拥有草稿模型。有了像 Gemma 4 的 assistant 变体这样分别训练的 drafter，模型供应商便控制了接受质量，这可能悄悄成为一道护城河：对齐到确切输出分布的第一方 drafter，理应胜过任何由社区拼装的通用小型模型。这把一项过去属于社区修补空间的优化集中了起来，并为自托管者带来一个更隐微的问题，亦即供应商是否可能推出一个强大的基础模型搭配一个刻意平庸的 drafter，并将快速路径置于不同的许可或发布节奏之后。