Gemini跨过十亿门槛，但芯片工程师看到的是另一道坎

上周我在调试一个5G基带的功耗模型，同事发来一条消息：Gemini的端侧推理延迟测试，在骁龙8 Gen 4上只比云端慢30%，但功耗翻了2.5倍。我盯着那个数字看了很久——这不是一个简单的优化问题，而是整个移动计算架构的取舍。Google宣布Gemini即将成为其第十个拥有十亿用户的产品，听起来是产品经理的胜利，但作为在展锐见过基带芯片从投片到量产的工程师，我清楚：十亿用户不是终点，而是算力工程的起点。

短期看，Gemini的十亿用户规模主要依赖云端推理的低延迟部署。Google有TPU v5p和自家定制网络，可以在数据中心里把大模型推理的batch size打满，单token成本压到毫厘级别。但这套逻辑放到手机端就变了味。端侧推理目前只能跑参数量在7B以下的量化模型，而且需要配合NPU的异构调度。我看了Google最近发布的Gemini Nano 2.0技术白皮书，他们用4-bit量化把模型体积压到1.5GB，但在麒麟9010上的实际推理帧率只有12fps，离实时交互还有距离。功耗墙的问题尤其突出：端侧持续跑Gemini，手机温度会在3分钟内超过45度，这还没算同时跑蜂窝基带的发热。如果Gemini要成为真正的十亿用户级产品，短期必须依赖云端+本地混合架构，但这样又绕不开网络延迟和隐私成本。

长期看，Google必须解决两个工程难题。第一个是推理芯片的专用化。目前手机SoC里的NPU普遍是针对小模型设计的，跑Gemini规模的大模型时，计算单元利用率不到40%，大量时间浪费在数据搬运。Google如果真想把Gemini做成十亿用户级别的端侧产品，应该学苹果的Neural Engine，直接在SoC里塞进大模型专用矩阵乘法单元，并且把SRAM容量翻倍。第二个是分布式推理的拓扑优化。十亿用户同时请求，哪怕每个用户只发一条query，数据中心的压力也远超现有搜索引擎。Google正在推的“Cloud TPU Pods”虽然能堆算力，但跨pod的通信开销随模型规模指数增长。我留意到他们最近在I/O上展示的“Gemini Anywhere”框架，试图把部分推理任务下放到边缘节点，但边缘节点的芯片选型还没定论——是继续用TPU变体，还是用Marvell或者博通的定制ASIC，这需要功耗和灵活性的极度权衡。

还有一个被忽视的细节：模型生命周期管理。十亿用户的设备千差万别，从Android Go的入门机到Pixel 9 Pro，GPU算力差异可能超过10倍。Google不能只给一个Gemini版本，必须做动态模型分片。这有点像当年5G基带芯片的多模兼容问题——要同时支持4G/5G/6

原文链接：https://techcrunch.com/2026/07/23/google-closes-in-on-another-billion-user-product-with-gemini/