手机跑大模型听起来很酷但真的跑起来之后问题就接踵而来了。我们常用的云端模型可以依赖服务器和数据中心但手机上的模型就没这么强大的后盾。不仅如此它还要顾及电池、内存、发热还有尽量别让用户等太久。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让这个小模块负责提前预测。图 1Frozen 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。图 2MTP 结果图上图展示了 Gemini Nano 在 Pixel 9 不同应用场景中引入 MTP 后的 token generation 效果对比。小结这篇文章可以看作 Google 对端侧大模型推理的一次工程优化记录。它讲的重点并不复杂手机里的大模型生成内容时如果每次只生成一个 token就容易慢如果能提前预测几个 token并且让主模型统一验证就有机会减少推理步数。Frozen MTP 的做法是在 Gemini Nano v3 后面加一个轻量预测模块。主模型保持不动小模块负责提前猜主模型负责检查。猜中了生成更快猜错了丢掉重来。简而言之手机端大模型要变快除了模型本身要轻生成方式也要更省步骤、更省内存。
端侧 AI 的推理加速：手机端大模型怎么提速？
手机跑大模型听起来很酷但真的跑起来之后问题就接踵而来了。我们常用的云端模型可以依赖服务器和数据中心但手机上的模型就没这么强大的后盾。不仅如此它还要顾及电池、内存、发热还有尽量别让用户等太久。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让这个小模块负责提前预测。图 1Frozen 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。图 2MTP 结果图上图展示了 Gemini Nano 在 Pixel 9 不同应用场景中引入 MTP 后的 token generation 效果对比。小结这篇文章可以看作 Google 对端侧大模型推理的一次工程优化记录。它讲的重点并不复杂手机里的大模型生成内容时如果每次只生成一个 token就容易慢如果能提前预测几个 token并且让主模型统一验证就有机会减少推理步数。Frozen MTP 的做法是在 Gemini Nano v3 后面加一个轻量预测模块。主模型保持不动小模块负责提前猜主模型负责检查。猜中了生成更快猜错了丢掉重来。简而言之手机端大模型要变快除了模型本身要轻生成方式也要更省步骤、更省内存。
