手机跑大模型听起来很酷，但真的跑起来之后，问题就接踵而来了。
我们常用的云端模型可以依赖服务器和数据中心，但手机上的模型就没这么强大的后盾。不仅如此，它还要顾及电池、内存、发热，还有尽量别让用户等太久。
Google 最近分享了一篇文章，介绍 Gemini Nano 在 Pixel 设备上的一次推理加速优化：Frozen Multi-Token Prediction。这个方法已经用在 Pixel 9 和 Pixel 10 系列的 Gemini Nano v3 中，服务于 AI 通知摘要（AI Notification Summaries）、文本校对（Proofread） 等端侧 AI 功能。
本文就借这篇文章，简单看看手机端大模型为什么容易慢，Frozen Multi-Token Prediction 大概怎么工作，以及它为什么能让 Gemini Nano 在 Pixel 上生成得更快一些。
大模型为什么会慢
大语言模型生成文字时，通常是一个 token 一个 token 往外吐。
你可以把它理解成一个很谨慎的打字员。每写下一个词，都要看一遍前面的内容，再判断下一个词是什么。这个流程看着很稳，但放到手机上，就很容易变慢。
因为手机的算力、内存和功耗都有限。模型每次只生成一个 token，就意味着要反复调用推理流程，也会更频繁地占用内存带宽。Google 在原文里提到，移动设备有严格的能耗预算和 RAM 限制，而传统自回归生成方式会形成瓶颈，影响体验和电池消耗。
所以，端侧 AI 要提速，一个很自然的方向就是：能不能一次多生成几个 token？
多猜 Token 再统一验证
Google 的 Frozen Multi-Token Prediction 的核心思路，就是先让一个轻量模块提前猜几个后续 token，再交给主模型检查。
这和 speculative decoding 的实现思路有点像。一般来说，生成 N 个 token 需要大模型跑 N 次；speculative decoding 把过程拆成两步：先由更快的小模块生成候选 token，再由主模型并行验证。如果候选内容和主模型判断一致，就可以一次接受多个 token；如果中间不一致，就从分歧处重新生成下一个 Token。
这样一来，模型生成文字就不用永远一步一步地往前挪。只要猜对了，它就可以一次往前推进几个 token。
需要提一下的是，Google 没有为 Gemini Nano 单独放一个很重的 drafter 模型。它在 Gemini Nano v3 的主模型后面接了一个轻量的 MTP head，让这个小模块负责提前预测。
图 1：Frozen MTP 的 zero-copy 架构
MTP Head 复用主模型已经计算出的 hidden states 和 KV cache，生成候选 token 后，再由主模型统一验证。
Frozen Multi-Token Prediction 是什么
这里 Frozen 的意思是，主模型权重被冻结。
Google 拿已经训练好的 Gemini Nano v3，把它的权重固定住，然后接上一个新的 MTP head。训练时，只训练这个新增模块，主模型本身不动。Google 认为，这样 MTP 更像是一个效率优化层，不会影响基础模型原有能力和安全对齐；如果提前预测错了，也会在验证阶段被丢掉，最终输出仍由主模型决定。
这点很适合端侧部署。
因为手机上的模型已经进入正式环境，重新训练和重新适配都很麻烦。Frozen MTP 的做法更像是在原有模型旁边加一个“提前预判器”，主要目标是减少等待时间和资源浪费。
端侧优化，内存也很关键
图 1 里还有一个很关键的细节：zero-copy architecture。
如果单独放一个 drafter 模型，它也要读上下文、维护自己的 KV cache，还要占用额外内存。对手机来说，这些都是成本。
Google 的方案是让 MTP Head 直接利用主模型已经算好的状态，包括 hidden states 和 KV cache。这样一来，小模块不用重新处理完整 prompt，也不用重复维护一份上下文缓存。Google 提到，这种设计可以消除 drafter 的额外 prefill 延迟，并且相比独立 drafter，每个实例最多节省约 130MB 运行内存。
这也是手机端 AI 和云端 AI 很不一样的地方。云端更容易通过堆算力解决问题；手机端要算得快，还要尽量少占内存、少唤醒重处理器、少消耗电量。
优化后的性能
在 Pixel 9 设备上的实验中，MTP drafter 相比参数量接近的独立 drafter，在部分任务上能带来 50% 以上的加速。对于 smart replies 这类结构更可预测的任务，token 接受率最高提升到 55%。在 AI Notification Summaries 和 Proofread 等生产负载中，MTP 平均每次推理可以正确多预测接近 2 个 token。
图 2：MTP 结果图
上图展示了 Gemini Nano 在 Pixel 9 不同应用场景中，引入 MTP 后的 token generation 效果对比。
小结
这篇文章可以看作 Google 对端侧大模型推理的一次工程优化记录。
它讲的重点并不复杂：手机里的大模型生成内容时，如果每次只生成一个 token，就容易慢；如果能提前预测几个 token，并且让主模型统一验证，就有机会减少推理步数。
Frozen MTP 的做法，是在 Gemini Nano v3 后面加一个轻量预测模块。主模型保持不动，小模块负责提前猜，主模型负责检查。猜中了，生成更快；猜错了，丢掉重来。
简而言之，手机端大模型要变快，除了模型本身要轻，生成方式也要更省步骤、更省内存。
