Accelerating Gemini Nano models on Pixel with frozen Multi-Token Prediction

在 Pixel 设备上通过冻结多令牌预测加速 Gemini Nano 模型

2026年6月26日

Eden Cohen，研究产品经理，Michelle Ramanovich，研究主管，Google 平台与设备团队

我们推出了一种方法，将多令牌预测（MTP）重新应用于冻结的生产模型，从而在不使用独立草稿生成器的低效方案下，加速设备端推理过程。

快速链接

• 关键词博客

• 分享 复制链接 ×

如今，借助 Gemini Nano 和 Gemma 等设备端模型，您口袋里的强大大型语言模型（LLM）已成为现实。这项技术使手机上的日常功能成为可能——例如即时总结大量通知或校对重要短信——而无需将您的私人数据发送到设备外。但要使这些功能对日常用户真正实用，它们必须实现非常高的效率。

在移动设备上实现这种速度是一项重大挑战。与资源丰富的服务器环境不同，手机在严格的能耗预算和硬性内存（RAM）限制下运行。此外，标准语言模型以“自回归”方式生成文本——这意味着它们一次只处理和输出一个词（或标记）。这种逐步处理过程会形成瓶颈，未能充分利用手机的处理能力，同时增加内存带宽压力，最终可能降低用户体验并耗尽电池电量。

为克服这一瓶颈，我们宣布推出一种新架构，将多令牌预测（MTP）重新应用于现有的“冻结”Gemini Nano v3 模型。在 EAGLE 框架和自信自适应语言建模（CALM）等先前方法的基础上，我们设计了新的架构组件，以在移动环境中最大化这些效率提升。我们最近的公告强调了通过 MTP 加速 Gemma 4 并向开发者开放。

本文探讨边缘计算的独特、极端限制。该方法已部署在 Pixel 9 和 10 系列设备上，可作为开箱即用的加速方案。对用户而言，这意味着 AI 通知摘要和校对等功能可以显著加快文本生成速度并减少能耗。对开发者而言，这消除了一个主要障碍：无需为每个新任务单独微调内存密集型的草稿生成模型，即可实现高速设备端 AI。

“延迟退出”策略

MTP 建立在推测解码的演变基础上。在传统设置中，生成 N 个标记需要大型模型进行 N 次前向传递。推测解码将此过程分解为两个部分：

• 草稿：一个更小、更快的近似模型（“草稿生成器”）生成候选标记的短序列（例如 3 个标记）。

• 验证：一个大型模型（“验证器”）并行处理这些候选内容。如果候选内容与大型模型预测的结果匹配，它们将被接受。如果不匹配，系统将回滚到第一个分歧点。

然而，这会导致一些效率低下。运行一个独立的“独立”起草模型（例如，128M参数）会争夺有限的RAM。此外，独立起草模型无法感知主模型丰富的内部状态，仅基于文本历史预测下一个标记，而没有主模型已计算出的语义上下文。MTP通过从独立架构转向集成架构来解决这些效率问题。我们不再训练一个单独的小型语言模型来起草标记，而是在主模型的最后几层附加一个轻量级的Transformer头——MTP头。

该架构采用深度退出层进行起草，利用主模型主干已完成的工作。MTP头获取主模型的最终高维激活值（隐藏状态），并利用它们自回归地预测未来标记序列。

冻结主干模型的优势

虽然MTP头通常与主干模型一起进行预训练——例如我们在Gemma 4模型的最新版本中所采用的方式——但在利用已部署的设备端基础模型时，这种方式会受到限制。相反，我们的工作重点是将起草头改造为独立于预训练流程运行。

我们采用一个完全训练好的Gemini Nano v3模型，冻结其权重，并在最后几层附加一个密集的Transformer堆栈——MTP头。我们仅训练这些参数以最小化未来标记的预测误差。通过冻结主干模型，MTP严格作为效率优化方案，确保基础模型的能力和安全对齐不会退化。

由于错误的草稿在验证过程中会被丢弃，最终输出与主模型在比特层面完全一致，使我们能够以完全向后兼容的方式推出效率更新。

零拷贝架构

虽然标准MTP实现通过在主模型和起草模型之间共享静态参数（如嵌入权重）来优化训练效率，但设备端推理面临更严格的瓶颈：动态内存。即使共享权重，如果起草模型独立处理上下文，它仍会因生成和维护自己的键值（KV）缓存而产生“双重内存消耗”。鉴于移动设备内存有限，避免这种冗余至关重要。

为了解决这个问题，我们设计了零拷贝架构，使MTP头能够有效利用主模型的状态。MTP头不维护自己的历史记录，而是被设计为直接跨注意力访问主模型的冻结KV缓存。这使起草模型能够查询主干模型已计算出的“记忆”和上下文，而无需重复存储。

这种设计带来了两方面的效率提升。首先，它消除了起草模型的预填充延迟：通过利用现有缓存，头部无需额外时间处理提示。其次，它减少了运行时内存占用。我们观察到，与独立起草模型相比，每个实例节省了130MB内存，这得益于起草模型的嵌入查找表、预填充点注意力变体和特定应用调参参数的节省。

根据image_width确定适当的宽度

对于移动设备图像，使用默认宽度

通过利用主模型的隐藏状态和KV缓存，MTP头生成的候选标记可由主干模型并行验证，消除冗余预填充延迟，内存使用量最多减少130MB。

解锁更丰富的表示

在我们的实验中发现，MTP草案生成器始终能生成更准确的标记预测，这使得在Pixel 9设备上相比参数量相当的独立草案生成器，根据任务不同可实现50%或更高的加速[aef552]。

这种性能差距源于MTP能够访问更丰富的表示形式。与将主模型视为黑盒的独立草案生成器不同，MTP头部可以直接利用已由主干模型处理过的最终激活值：

• 指令遵循：在需要复杂约束的摘要或重写任务中，MTP显著优于独立微调草案生成器。
• 可预测的文本结构：对于结构可预测性高的任务（如智能回复），MTP头部有效学习了主模型的语法模式，在标记接受率方面最高提升了55%。

实际影响

为在Pixel 9和10设备上部署MTP，我们重新设计了设备端推理堆栈，以处理验证阶段与起草阶段之间的复杂依赖关系。

结果验证了架构选择的有效性。在生产工作负载（如AI通知摘要和校对功能）中，MTP每次推理过程平均能正确预测近两个额外的标记。此外，更少的验证步骤意味着更少唤醒重型处理器的时间，从而降低能耗并延长电池寿命。

Gemini Nano在Pixel 9设备上不同应用场景中，MTP与特定应用的独立微调草案生成器在标记生成方面的性能对比。

未来方向

我们期待在未来的Pixel设备上集成MTP，并探索替代架构——包括并行解码和无需辅助头的范式——以进一步降低起草延迟，并在严格移动约束下提升同时验证的标记数量。

我们也在研究如何更高效地处理语言生成的固有歧义性。虽然标准推测解码假设存在单一最佳未来路径，但我们正在开发允许模型并行探索分支可能性的技术。这旨在即使在不确定上下文中也能最大化接受长序列的概率。此外，我们正在研究验证宽松度：针对特定使用场景放宽草案与验证之间严格的精确标记匹配要求，以进一步提升边缘设备的效率。

致谢

这项工作是我们优化设备端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和Platforms & Devices团队的审阅、宝贵反馈和支持。

• 标签：

• 机器智能

• 移动系统

• 自然语言处理

• 相比MTP更新前的Pixel 9和Pixel 10手机。

其他相关文章

• 2026年6月24日 思维回溯：推理如何释放LLM中的参数化知识 生成式AI · 机器智能 · 自然语言处理

• 2026年6月16日 从像素到规划：用于自然恢复的地球AI 气候与可持续性 · 地球AI · 机器智能 · 开源模型与数据集

• 2026年6月5日 通过Gemini企业代理平台的智能RAG数据管理实现可靠响应 · 机器智能 · 自然语言处理 · Product

×

❮

❯