2026 年 6 月 26 日
Eden Cohen（研究产品经理）与 Michelle Ramanovich（研究经理），Google 平台与设备部门
我们提出了一种方法，将多 Token 预测（Multi-Token Prediction，MTP）改造后应用于已冻结的生产模型，从而加速设备端推理，同时避免独立草稿模型带来的低效问题。
快速链接
Quick links
- 关键词博客
- 分享
拥有强大的大语言模型（LLM）就在口袋里，如今已通过 Gemini Nano 和 Gemma 等设备端模型成为现实
Having powerful Large Language Models (LLMs) right in your pocket is now a reality with on-device models like Gemini Nano and Gemma
这项技术让手机上的日常功能成为可能——例如即时摘要通知洪流，或校对重要短信——所有这些都无需将你的私人数据发送到设备之外。但要让这些功能对日常用户真正有用，它们必须高效运行。
在移动设备上实现这样的速度是一项重大挑战。与庞大的服务器环境不同，手机受到严格的能耗预算和硬性内存（RAM）限制。此外，标准语言模型以“自回归”方式生成文本——这意味着它们一次只处理并输出一个词（或 Token）。这种逐步处理的过程造成了瓶颈，未能充分利用手机的处理能力，同时给内存带宽带来压力，最终可能拖慢用户体验并消耗电池。
为了克服这一瓶颈，我们宣布了一种新架构，将多 Token 预测（MTP）改造后应用于现有的“冻结”Gemini Nano v3 模型。基于 EAGLE 框架和 Confident Adaptive Language Modeling（CALM）等先前方法，我们设计了新的架构组件，专门针对移动环境最大化这些效率提升。我们最近的公告强调了使用 MTP 加速 Gemma 4，并将其提供给开发者。今天的文章则聚焦于边缘计算所面临的独特且极端的约束。该方法最近已部署到 Pixel 9 和 10 系列，作为一种开箱即用的加速方案。对用户而言，这意味着 AI 通知摘要和校对等功能生成文本的速度显著加快，能耗更低。对开发者来说，它消除了一大痛点：无需为每个新任务微调独立的、占用大量内存的草稿模型，即可实现高速设备端 AI。
“晚退出”策略
A "late exit" strategy
MTP 建立在推测解码（speculative decoding）的演进基础之上。在传统设置中，生成 N 个 Token 需要大模型进行 N 次前向传播。推测解码将这一过程解耦为两个部分：
- 草稿（Draft）：一个更小、更快的近似模型（“草稿模型”）生成一短串候选 Token（例如 3 个 Token）。
- 验证（Verify）：一个大模型（“验证模型”）并行处理这些候选 Token。如果候选 Token 与大模型本应预测的结果匹配，则被接受；如果不匹配，系统回滚到第一个分歧点。
然而，这会导致一些低效问题。运行一个独立的“草稿模型”（例如 128M 参数）会争夺有限的内存。此外，独立的草稿模型对主模型的丰富内部状态“视而不见”，仅基于文本历史预测下一个 Token，缺乏主模型已经计算出的语义上下文。MTP 通过从独立架构转向集成架构来解决这些低效问题。我们不是训练一个独立的小语言模型来草拟 Token，而是在主模型的最终层上附加一个轻量级的 Transformer 头，即 MTP 头。
这种架构使用一个深度退出层（deep exit layer）进行草稿生成，利用了主模型主干已经完成的计算工作。MTP 头接收主模型的最终高维激活（隐藏状态），并利用它们自回归地预测未来 Token 序列。
冻结主干的优势
The frozen backbone advantage
虽然 MTP 头通常与主干一起进行预训练——例如在我们最近发布的 Gemma 4 模型中——但在利用已部署的设备端基础模型时，这种做法是不可行的。相反，我们的工作重点是将草稿模型头改造为独立于预训练流程运行。
我们采用一个完全训练好的 Gemini Nano v3 模型，冻结其权重，并在其最终层上附加一个密集的 Transformer 堆栈——即 MTP 头。我们仅训练这些参数，以最小化对未来 Token 的预测误差。通过冻结主干，MTP 严格成为一种效率优化手段，确保基础模型的能力或安全对齐不会退化。
由于不正确的草稿在验证过程中会被丢弃，最终输出与主模型逐位相同，这使得我们能够以完全向后兼容的方式推出效率更新。
零拷贝架构
Zero-copy architecture
虽然标准的 MTP 实现通过在主模型和草稿模型之间共享静态参数（如嵌入权重）来优化训练效率，但设备端推理面临更严格的瓶颈：动态内存。即使共享权重，如果草稿模型独立处理上下文，它也会通过生成和维护自己的键值（KV）缓存而产生“双重负担”。考虑到移动设备内存有限，避免这种冗余至关重要。
为了解决这个问题，我们设计了一种零拷贝架构，其中 MTP 头有效地利用主模型的状态。MTP 头不维护自己的历史记录，而是设计为直接交叉关注主模型的冻结 KV 缓存。这使得草稿模型能够查询主干已经计算出的“记忆”和上下文，而无需重复。
这种设计带来了两方面的效率提升。首先，它消除了草稿模型的预填充延迟：通过利用现有缓存，MTP 头无需额外时间处理提示。其次，它减少了运行时内存占用。与独立草稿模型相比，我们观察到每个实例节省了 130MB 内存，这得益于省去了草稿模型的嵌入查找表、预填充点注意力变体以及特定应用的调优参数。
通过利用主模型的隐藏状态和 KV 缓存，MTP 头生成候选 Token，这些 Token 由主干并行验证，从而消除了冗余的预填充延迟，并将内存使用量减少高达 130MB。
解锁更丰富的表示
Unlocking richer representations
在我们的实验中，我们发现 MTP 草稿模型始终能产生更准确的 Token 预测，与参数数量相当的“独立草稿模型”相比，在 Pixel 9 设备上实现了 50% 或更高的加速，具体取决于任务。
这种性能差距源于 MTP 能够访问更丰富的表示。与将主模型视为黑盒的独立草稿模型不同，MTP 头直接利用更大主干已经处理过的最终激活：
- 指令遵循：在摘要或具有复杂约束的重写等任务中，MTP 显著优于独立微调的草稿模型。
- 可预测的文本结构：对于结构可预测性高的任务（例如智能回复），MTP 头有效地学习了主模型的句法模式，Token 接受率提升了高达 55%。
实际影响
Real-world impact
为了在 Pixel 9 和 10 设备上部署 MTP，我们重新设计了设备端推理堆栈，以处理验证阶段和草稿阶段之间的复杂依赖关系。
结果验证了架构选择的正确性。在生产工作负载中，例如 AI 通知摘要和校对，MTP 每次推理平均能正确预测近两个额外的 Token。此外，更少的验证步骤意味着唤醒重型处理器的时间更短，从而降低了能耗并延长了电池寿命。
Gemini Nano 在 Pixel 9 各种应用中，MTP 与特定应用独立调优草稿模型在 Token 生成方面的影响对比。
未来方向
Future directions
我们期待将 MTP 集成到未来的 Pixel 设备中，并探索替代架构——包括并行解码（parallel decoding）和无辅助头（paradigms without auxiliary heads）的范式——以进一步降低草稿延迟，并在严格的移动设备约束下增加同时验证的 Token 数量。
我们也在研究如何更高效地处理语言生成中固有的歧义性。虽然标准推测解码假设存在单一的最佳未来路径，但我们正在开发允许模型并行探索分支可能性的技术。这旨在即使在不确定的上下文中也能最大化接受长序列的概率。此外，我们正在研究验证宽松度：针对特定用例，放宽草稿与验证之间严格的精确 Token 匹配要求，以在边缘设备上带来进一步的效率提升。
致谢
Acknowledgements
这项工作是我们优化设备端 LLM 效率努力的一部分，参与人员包括 Filippo Galgani、Omri Homburger、Pooja Consul、Matthew Markwell 和 Vivek Kumar。某些元素基于 Google DeepMind 中 Gemini 团队的开发成果：Tal Schuster、Ziwei Ji、Ivan Korotkov 和 Ganesh Jawahar。我们还要特别感谢 Nadav Bar、Utku Evci、Nir Shabat、Joe Zou 以及 Google Research、Google DeepMind 和平台与设备部门的团队提供的审阅、宝贵反馈和支持。
💡 译者注：与 MTP 更新前的 Pixel 9 和 Pixel 10 手机相比。
其他相关文章
Other posts of interest
- 2026 年 6 月 30 日：介绍 TabFM：一种用于表格数据的零样本基础模型
- 2026 年 6 月 24 日：思考以回忆：推理如何解锁 LLM 中的参数化知识
- 2026 年 6 月 16 日：从像素到规划：用于自然恢复的地球 AI