Google 今天为 Gemma 4 发布了 Multi-Token Prediction(MTP)起草器 — 与目标 Gemma 配对、开箱即用做推测解码的预训练轻量起草模型。头条 claim:推理速度最多 3 倍,输出与目标模型逐 token 完全相同。起草器提议一个未来 token 序列;目标并行验证它们。当验证拒绝某个起草 token 时,生成回退到目标在该位置的实际预测,因此质量按位精确保留。要紧的架构细节:起草器共享目标的 KV cache 和激活,这绕过了运行两个独立模型(各自缓存状态)的标准推测解码开销。边缘变体(E2B、E4B)有「embedder 层的高效聚类技术」来解决主导小模型推理的 logit 计算瓶颈。Apache 2.0,权重在 Hugging Face 和 Kaggle 上。
推测解码两年来一直是热门推理优化,但实践中,builder 要么必须训练自己的起草器(显著工作量),要么使用未很好捕获目标分布的通用 small-model 起草器(平庸的接受率)。Google 提供专门为 Gemma 4 调优的预训练起草器关闭了这个差距 — 即插即用 3 倍加速,builder 侧无训练成本。KV-cache 共享是架构上有意义的选择:vLLM 这样的标准推测解码实现把任意 draft model 与目标配对,支付重复的 cache 成本。共享 KV 状态意味着更小的内存占用和更快的验证轮次。与 EAGLE(使用目标的隐藏状态做起草)和 Medusa(向目标添加预测 head)的比较未在发布报道中披露;从描述看,MTP 起草器精神上更接近 EAGLE,但是用单独的轻量起草器权重而不是额外的目标 head。
生态读法:推测解码正成为开源权重模型生产推理的预期基线,在主 checkpoint 旁 ship 预训练起草器的 lab 显著降低了门槛。DeepSeek V3 ship 了内置在模型中的 MTP head。Mistral Medium 3.5 的编程层与此相邻,虽然那边的起草器方法未披露。Google 把起草器做成单独但缓存共享的模块是让 builder 只为现有 Gemma 4 部署 pull 起草器而不是重新加载统一 MTP-enabled checkpoint 的设计选择。对在生产中运行自托管 Gemma 4 的 builder,升级路径是:下载匹配的 MTP 起草器,如果你的推理框架支持 KV-shared 推测解码就插入(vLLM 和 TensorRT-LLM 都支持,带配置),测量你流量上的接受率。接受率决定实际加速 — 3 倍是乐观情况,真实情况依赖工作负载。
实际动作:如果你在生产中为聊天、代码补全或低延迟推理运行 Gemma 4,这是本周要测试的优化。拉取 MTP 起草器,换到你的推理 stack,在你的实际 prompt 上测量延迟和接受率。「无质量损失」claim 通过将输出与非 MTP 目标比较逐 token 可验证 — 在生产请求样本上运行那个 diff 作为你的合理性检查。对 Gemma 4 E2B/E4B 的边缘部署,embedder 层聚类优化专门针对限制移动/边缘硅小模型延迟的 logit 计算瓶颈 — 那是推测解码通常不划算的情况,如果你 ship 端侧 Gemma 4,Google 的修复是要仔细阅读的架构细节。Apache 2.0 许可保持商业路径开放,无需协商摩擦。下一个看点是其他开源权重 lab 是否跟进预训练起草器模块 — 一旦成为 table stakes,从零做推测解码的税在开源生态系统中消失。