Accelerating Gemma 4: faster inference with multi-token prediction drafters

原文链接：https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/ 前情解读：/ai-research/news/2026-04-03/deep-gemma-4/ 来源：Google 发布日期：2026-05-05

速查卡

文章背景

Google 在 4 月发 Gemma 4 时，主叙事是 intelligence-per-parameter。那一轮回答的是“同样参数，能不能更聪明”。

这篇 5 月新文回答的是另一个现实问题：

即便模型够聪明，如果推理慢、显存带宽吃不消、消费级设备体验差，开发者还是不会真拿它做默认工作马。

所以这篇文章本质上是 Gemma 4 的“部署后半场”。它不是在卷 benchmark，而是在卷 inference systems。

完整内容还原

1. Google 发了什么

原文核心发布很简单：

• 给 Gemma 4 family 发布 Multi-Token Prediction (MTP) drafters
• 官方说通过 specialized speculative decoding architecture，可实现 最高 3x speedup
• 同时强调 without any degradation in output quality or reasoning logic

也就是说，Google 想卖的不是“便宜一点的草稿模型”，而是“在不牺牲最终答案的前提下，用小模型把大模型的时间浪费削掉”。

2. Google 对瓶颈的判断：不是算不动，而是搬不动

原文最关键的一句是：standard LLM inference is memory-bandwidth bound。

也就是推理慢的主要原因，不是 ALU 不够算，而是：

• 每生成一个 token
• 都要把几十亿参数从 VRAM 搬到 compute units
• 导致 compute 大量闲置
• 尤其在 consumer-grade hardware 上高延迟更明显

这和很多开发者的直觉不一样。很多人以为模型慢是“模型太大”，Google 这里更具体：慢在数据搬运成本，而不是纯算术复杂度。

3. speculative decoding 到底怎么工作

原文的描述可以简化成两层角色：

• target model：真正负责最终正确性的重模型，比如 Gemma 4 31B
• drafter / MTP model：轻量草稿模型，先猜未来几个 token

流程是：

1. drafter 先一次预测多个 future tokens
2. target model 并行验证这些候选 token
3. 如果 target 同意，就整串一起接受
4. 并且 target 还能顺手再多生成一个 token

于是单次 forward pass 不再只产出 1 个 token，而可能产出：

• 一整段被接受的 draft sequence
• 再加 target 自己多给的 1 个 token

这就是为什么吞吐能显著拉升。

4. Google 用的不是普通 speculative decoding，而是 MTP drafter

原文把这个技术归到 MTP（Multi-Token Prediction）drafters。要点不是“用个小模型猜”，而是“这个小模型专门为了多 token 草拟与快速验证配合而设计”。

Google 特别提到几个架构增强：

• draft models 利用 target model activations
• share target 的 KV cache
• 对 E2B / E4B edge models，因 final logit calculation 是瓶颈，做了 efficient clustering technique in the embedder

这三点的含义分别是：

1. drafter 不用从零理解上下文；
2. 已经算过的历史上下文不重复算；
3. 小边缘模型连最后 logits 计算都继续优化，而不是只盯主干网络。

核心技术洞察

1. 为什么共享 KV cache 很重要

自回归推理里，历史 token 的 key/value cache 是最值钱的中间状态之一。

如果 drafter 另起炉灶，每次都重算上下文，它的加速价值会被自己吃掉。Google 这次强调 share its KV cache，本质上是在避免 speculative decoding 变成“两套模型重复干同一份活”。

2. 这是从“模型优化”转向“控制流优化”

MTP 并没有改 Gemma 4 的基础智能，而是在改：

• token 生成节奏
• 草拟与验证分工
• cache 复用
• 批处理策略
• 硬件感知调度

这说明开源模型竞争正在进入系统工程阶段。下一轮胜负可能不再只看模型卡，而要看：谁把 serving path 打磨得更细。

3. 为什么这对 agent 特别重要

原文直接点名：

• coding assistants
• autonomous agents requiring rapid multi-step planning
• responsive mobile applications running on-device

agent 比单轮聊天更吃延迟，因为它要连续做：

• 规划
• 工具调用
• 观察结果
• 再规划

如果每一步都慢，用户体感会指数变差。所以推理提速对 agent 的边际价值，比对一次性问答更大。

文章中给出的工程细节

1. 设备与软件栈

原文说 speedup 测试覆盖：

• LiteRT-LM
• MLX
• Hugging Face Transformers
• vLLM

还在文末给出可以直接上手的平台：

• Hugging Face
• Kaggle
• MLX
• vLLM
• SGLang
• Ollama
• Google AI Edge Gallery（Android / iOS）

这说明 Google 明显在推动 day-1 ecosystem adoption，而不是只给实验代码。

2. 本地与边缘场景

原文提到几类典型收益：

• Improved responsiveness：更适合 near real-time chat、voice、agentic workflows
• Supercharged local development：26B MoE / 31B Dense 在个人电脑和消费级 GPU 上更实用
• Enhanced on-device performance：E2B / E4B 输出更快，也间接更省电
• Zero quality degradation：最终质量仍由主模型兜底

3. 硬件特定观察

这部分虽然短，但很关键。

Google 特别说：

• 26B MoE 在 Apple Silicon 上，batch size = 1 时有 routing challenges
• 但把 batch 调到 4–8，本地可获得 约 2.2x speedup
• 在 NVIDIA A100 上提升 batch size 也能看到类似收益

这说明 Gemma 4 MTP 并不是“固定条件下永远 3x”，而是强依赖：

• 模型结构（Dense vs MoE）
• 硬件平台
• batch size
• runtime 实现

横向对比

批判性分析

局限性

1. 官方没有在正文里给出完整、分设备、分 batch 的细表，更多是方向性结论和案例。
2. “up to 3x” 是上限值，不是普遍值。实际收益显然依赖硬件、模型尺寸、batch 与 runtime。
3. 质量不降的说法更多来自 target verification 逻辑，但不同任务上的 acceptance pattern、延迟波动与尾部行为仍需社区独立验证。
4. 26B MoE 在 Apple Silicon 上 batch=1 有 routing challenge，说明并不是所有本地单请求场景都会自然吃满收益。

独立观察

1. Google 正在把 Gemma 4 从“能跑的开源模型”往“值得拿来当默认本地工作模型”推进。
2. MTP drafter 的真正价值不只是 TPS 更高，而是让 26B/31B 这种体量在个人工作站上更像一个可以忍受的日常工具。
3. 这也是开源模型和闭源 API 的一个新分水岭：闭源模型拼在线效果，开源模型开始拼谁能把本地、离线、边缘部署体验做到更顺手。

对领域的影响

短期内，Gemma 4 的竞争不再只是对标其他开源权重，而是会逼着更多模型提供：

• 官方 speculative decoding 支持
• KV cache 共享优化
• runtime 级 best practices
• 面向 Apple Silicon / 消费级 GPU / edge 的具体调优指南

换句话说，Google 现在不只是发模型，而是在教开发者如何把模型真正跑快。