Google Frozen v2：把 Gemini 刻进芯片的豪赌

一场迟到却不得不下的重注

在经历核心人才流失、旗舰模型延期、内部算力告急之后，Google 正悄然推进一项周期长达数年的硬件计划——代号 Frozen v2 的专用服务器芯片。它不面向市场销售，也不兼容通用AI负载，而是为一个目标而生：让 Gemini 模型跑得更快、更省、更稳。

不是加速，是重构

过去几十年，芯片设计遵循冯·诺依曼架构：指令与数据共存于内存，处理器按需取指、解码、执行。这种通用性成就了计算机的普适，也埋下了效率隐患——大模型推理本质是重复密集的张量运算，但通用芯片仍要保留大量冗余控制逻辑和数据通路，导致大量晶体管与带宽被闲置。

GPU、TPU 是第一轮优化：用并行单元应对矩阵乘法，用定制访存路径缓解内存墙。但它们仍需通过软件调度适配不同模型，灵活性背后是性能折损。

Frozen v2 走得更远：它不再‘运行’Gemini，而是‘承载’Gemini。芯片的计算单元排布、存储层级划分、数据流动路径，全部围绕 Gemini 当前架构预先固化。硬件提前知道‘下一步大概率做什么’，从而跳过动态判断、减少搬运、压缩延迟。

刻什么？怎么刻？

一个大模型由两部分构成：架构（信息流动的拓扑规则）与权重（训练所得的数值参数）。Frozen v2 固化的是前者——比如注意力头数、层归一化位置、FFN 扩展比、KV Cache 的组织方式等结构性约定。这些一旦确定，就能直接映射为硬件电路的连接关系与调度逻辑。

但权重仍保留在片外或可重载的片上缓存中。这意味着，当 Gemini 迭代升级时，只要底层架构未发生根本性变更（如从 Transformer 切换到 Mamba），同一颗 Frozen v2 芯片仍可服役。这是对第一代 Frozen 的关键修正：不再追求‘一模一芯’，而追求‘一构多版’。

Jeff Dean 与 Google 的纵深优势

该项目由 Google 首席科学家 Jeff Dean 主导。他不仅是 TensorFlow 的奠基者，更是 TPU 从零落地的核心推手。过去十年，Google 在编译器（XLA）、分布式训练框架（JAX）、硬件抽象层（TPU VM）上的持续投入，已构建起模型与芯片之间罕见的闭环能力。

别人需要协调模型团队、芯片设计公司、云平台三方才能做的事，Google 可以在一个组织内完成定义、验证、部署。这种垂直整合，是 OpenAI 借 Broadcom、Anthropic 依赖外部代工所难以复制的护城河。

为什么必须自研？答案藏在账本里

以 Gemini 3.1 Pro Preview 为例：一次中等负载请求（5000 输入 token + 1000 输出 token）对外标价约 2.2 美分。若日调用量达 1 亿次，单日成本即超 220 万美元，年支出逼近 8 亿美元。

这还只是公开 API 的冰山一角。叠加 Workspace、Search、YouTube、Android 等生态内嵌调用，真实算力消耗远超披露数字。对 Google 而言，降低单位 token 成本，不是技术选项，而是生存刚需。

时间不多，但底牌尚在

Frozen v2 最早 2028 年才可能上线。眼下，Google 仍在权衡：固化程度越高，能效越优，但灵活性越低；保留越多可配置空间，适配性越强，却要牺牲部分极致性能。

这场‘冻结’，本质上是一场战略取舍：用部分架构的确定性，换取芯片级的确定性收益。它不承诺立刻翻盘，但试图锚定未来三年 Gemini 的算力基本盘。

人才会走，版本会延，舆论会变。但当一颗芯片流片成功，它所承载的，就不再只是某个模型的权重，而是 Google 对生成式 AI 底层范式的理解与坚持。