Gemma 4 发布时未包含 MTP 数据——为什么这很重要

Google 于 2026 年 4 月 3 日发布了 Gemma 4——一系列具有出色基准测试结果、多模态能力和最高 256K 上下文长度的开放权重模型。从数据上看，这是一次令人印象深刻的发布。但在几小时内，社区就发现了一个缺失：多标记预测头已从公开权重中被剥离。

该模型训练时使用了 MTP。Google 自己的 LiteRT 框架包含 MTP 组件。但所有人能从 HuggingFace 下载到的版本？只有标准自回归生成。没有速度提升。没有推测性解码。

这篇文章将解释什么是 MTP、它为何重要，以及这一决定对所有在自有硬件上运行 Gemma 4 的用户意味着什么。

什么是 Gemma 4？

Gemma 4 是 Google DeepMind 最新的开放权重模型系列，基于 Apache 2.0 许可证发布。它有四种规模：

主要能力包括原生多模态支持、函数调用、结构化 JSON 输出，以及基于 140+ 种语言的训练。31B 版本在 LMArena 文本排行榜上排名第三。

在架构层面，Gemma 4 引入了多项创新：交替使用局部滑动窗口和全局注意力层、比例 RoPE（p-RoPE）、逐层嵌入（PLE）、共享 KV 缓存，以及"键等于值"内存优化。

从数据来看，这是一次优秀的发布。问题在于公开权重中缺少了什么。

什么是多标记预测？

标准大语言模型一次生成一个标记。每个标记都需要一次完整的模型前向传播。下一个标记必须等到上一个完成后才能开始。这就是自回归解码，本质上是顺序执行的。

**多标记预测（MTP）**通过为模型添加额外的预测头来改变这一点。模型不再只预测下一个标记，而是在单次前向传播中同时预测 N+1、N+2、N+3 等标记。

其工作原理如下：

1. 训练阶段：额外的轻量级预测头与主模型一同训练。每个头学习预测不同的未来位置（提前 1 步、提前 2 步、提前 3 步等）。
2. 推理阶段：额外的预测头并行生成"草稿"标记。然后主模型在单次前向传播中验证所有草稿标记。
3. 验证：如果草稿标记与主模型本身会生成的结果一致，它们全部被一次性接受——跳过多个顺序解码步骤。如果某个草稿标记有误，生成过程会回退到该位置。

这与推测性解码密切相关，但有一个关键优势：草稿标记来自模型本身，而不需要一个单独的、更小的"草稿模型"。

MTP 能快多少？

加速幅度取决于草稿标记的正确率（“接受率”）。DeepSeek V3 展示了实际效果：

平均接受率 2.4 意味着每次主模型前向传播平均产生 2.4 个标记而非 1 个。输出在数学上与标准解码完全一致——每个标记都经过验证。你以接近两倍的速度获得相同质量的结果。

准备好发展您的业务了吗？

今天开始免费试用，几天内即可看到结果。

申请演示 登录

Gemma 4 发生了什么

一位 HuggingFace 用户（@shadowlilac ）发现 Google 的 LiteRT 包中 Gemma 4 包含 MTP 预测头和多标记预测功能。但在 HuggingFace 上公开发布的权重中完全没有。

MTP 组件被刻意剥离：

• 检查点中没有 MTP 头
• 模型配置中没有 MTP
• 前向传播中没有 MTP

Google 的解释

一位 Google 工程师（@srikanta-221 ）确认这是有意为之：

公开模型仅暴露标准自回归接口，“以确保广泛兼容性。“MTP 头从模型配置、前向传播和检查点中排除。这确保了与 HuggingFace Transformers API 的兼容性，并保持一致的检查点和运行时行为。

Google 将 MTP 定义为"部署时优化"而非核心模型特性。MTP 预测头仅保留在 LiteRT 导出的模型中——即 Google 自己的设备端推理框架。

为什么这是个问题

这个解释经不起推敲：

1. 模型训练时使用了 MTP。 这个能力是存在的。从发布版本中剥离它是一种选择，而非技术限制。

2. 第三方引擎无法实现。 vLLM、llama.cpp、SGLang 和其他推理框架在没有预测头的情况下无法使用基于 MTP 的推测性解码。这些引擎服务于绝大多数开源 LLM 部署。

3. 用户得到的是慢速版本。 没有 MTP，Gemma 4 只能以标准自回归速度运行。性能差距在实践中已经显现：

4. 这造成了生态锁定。 Google 自家的 LiteRT 框架获得了速度优势。其他所有人得到一个更慢的模型。对于一个"开放权重"的 Apache 2.0 发布来说，这是严重的不对等。

推测性解码的工作原理（以及为什么 MTP 更优）

要理解缺失的 MTP 头为何重要，有必要了解 MTP 在推理优化演进中的位置。

方法一：传统推测性解码

一个独立的、更小的"草稿模型"提出标记。主模型并行验证它们。如果草稿正确，每步可接受多个标记。

• 优点：适用于任何模型组合
• 缺点：需要维护和加载第二个模型；草稿模型的质量限制加速效果；额外的内存开销

方法二：MTP（内置预测头）

主模型拥有自己的轻量级预测头来生成草稿标记。无需独立模型。

• 优点：无需额外模型；更紧密的集成意味着更高的接受率；更低的内存开销
• 缺点：仅在预测头包含在发布版本中时才有效

为什么 MTP 更优

MTP 预测头与主模型一同训练。它们共享相同的内部表示，学习模型自身的标记分布。这通常比外部草稿模型产生更高的接受率，意味着每次验证步骤接受更多标记，整体生成更快。

预测头也很小——通常仅增加模型总参数量的 1-3%。与加载一个独立草稿模型相比，内存开销可以忽略不计。

加入我们的新闻通讯

免费获取最新提示、趋势和优惠。

电子邮件地址

订阅

更广泛的影响

这不仅仅关乎 Gemma 4。这一决定为"开放"权重发布的实际开放程度树立了先例。

用户失去了什么：

• 在任何第三方推理引擎上使用基于 MTP 的推测性解码
• 微调或试验 MTP 头的能力
• 与 Google 自有部署工具的性能对等

用户仍然拥有的：

• 基础模型权重（质量确实很好）
• 使用独立草稿模型的传统推测性解码（vLLM issue #38893 正在跟进 Gemma 4 的 Eagle3 支持）
• 标准量化和优化技术

社区反应非常直接。24 小时内的共识是，Gemma 4 的基准测试结果具有竞争力——与 Qwen 3.5 持平或略逊——但产品"尚未完成”。速度、稳定性和工具支持都需要改进。其他问题包括 HuggingFace Transformers 最初缺乏 Gemma 4 架构支持、PEFT 无法处理新的层类型，以及 Mac 用户在加载大模型时遇到崩溃。

你能做什么？

如果你正在评估 Gemma 4 用于部署，以下是一些实用建议：

使用传统推测性解码。 外部草稿模型仍然可以加速 Gemma 4 推理。vLLM 等框架正在专门为 Gemma 4 添加 Eagle3 推测性解码支持。加速效果不及内置 MTP，但总比没有好。

对速度要求高的工作负载考虑替代方案。 Qwen 3.5 在同等硬件上提供明显更高的每秒标记数。如果推理速度是你的首要约束，Qwen 目前提供更好的速度-质量比。

关注社区变通方案。 LiteRT 导出版本包含 MTP 头。研究人员可能会找到方法将它们提取并重新附加到 HuggingFace 权重中，尽管 Google 尚未官方支持这条路径。

提供反馈。 Google 的工程师正在积极关注 HuggingFace 讨论帖。清晰的、技术性的 MTP 头发布请求是有分量的。

结论

Gemma 4 是一个功能强大的模型系列，具有真正的架构创新和出色的基准测试结果。将 MTP 预测头从公开版本中剥离——同时在 Google 自家的 LiteRT 框架中保留——削弱了"开放"权重中"开放"的含义。

MTP 不是一个小优化。它可以在输出质量零损失的情况下实现 1.5–2 倍的推理加速。在模型明显经过 MTP 训练的情况下，从公开权重中剔除它，创造了一个双层体系：Google 工具享有快速推理，其他所有人只能使用慢速推理。

对于开源 AI 社区，信息很明确：检查权重中实际包含了什么，而不仅仅是基准测试。开放许可证并不总是意味着开放的发布。

由 FlowHunt 构建。在我们的博客 上关注开源 AI 的最新动态。