#ai产业链#

Google 的 AI 基建野心：让每一瓦电兑现更多算力

信源：Sequoia Capital《Training Data》｜Sonya Huang 对谈 Google AI 基础设施负责人 Amin Vahdat

当十万颗加速器组成一台超级计算机，故障就成了日常运行的一部分。Amin Vahdat 在访谈中估计，这个规模的系统每天会出现多次故障，某些配置甚至每小时多次。买到芯片只是开始：定位故障、恢复状态、避免大量重算，决定了这些昂贵设备最终能交付多少工作。

这也是理解 Google AI 基建路线的入口。Google 正在把优化范围从芯片一路扩展到模型、网络、机房和供电：让有限的电力与设备，持续完成更多有用计算。随着 Agent 拉长任务链条，这种系统能力的价值还会放大，因为加速器之外的等待、通信与恢复，正在影响整项任务的成本。

Vahdat 用 goodput 描述实际交付的有效工作。在一个需要同步协作的任务中，某个部件出错，其他设备可能被迫等待；恢复后重做的计算虽然消耗时间和电力，却没有增加最终完成的工作。峰值 FLOPS 描述计算上限，goodput 则把这些损耗计入结果。

由此看，网络可靠性、检查点和运行时优化，都直接参与了算力供给。假设一项任务原本频繁中断，改进恢复机制后，同一批设备就能在相同时间里完成更多工作。这种增量不需要多安装一颗加速器，却同样能缓解容量紧张。

访谈里“每六个月翻倍”的说法，也必须放在这个框架下理解。Vahdat 明确说，目标是有效 token 生成能力翻倍，软件与模型优化会承担很大一部分贡献。不能据此推导芯片采购、电力需求或者资本开支每半年翻倍。

对产业判断而言，这意味着需要同时观察任务需求和单位任务资源消耗。优化可以降低一次推理的成本，也可能让原来太贵的任务变得可用。最终硬件需求增长多少，取决于新增使用量能否超过效率提升，单独拿其中一个变量外推都会失真。

Google 为此选择的路径，是让模型和硬件相互改变。

Vahdat 描述了一种具体工作方式：DeepMind 发现某项模型改进可以显著提高效率，但需要芯片支持；硬件团队评估后，可能发现原方案难以实现，于是双方一起调整模型与硬件，保留大部分收益。遇到足够大的机会，甚至会讨论把流片推迟一两周。

这个细节比“全栈自研”四个字更有解释力。模型团队知道哪些计算值得保留、哪些结构可以调整，硬件团队知道数据搬运、执行单元和设计时序的代价。双方共同修改问题，才能减少模型设计完成后再去适配硬件的损耗。Google 的组织优势，体现在它能把这种协作延伸到正在设计、即将流片和已经投产的多代产品。

但专用化有经济边界。芯片要提前数年规划，工作负载必须足够大、持续足够久，才值得为它承担独立研发和部署成本。Vahdat 以 TPU 8i、8t 为例解释训练与推理分化的逻辑，同时强调两者仍能执行对方的工作。这份兼容性很有价值：需求结构预测有偏差时，设备还有重新分配的余地。

因此，合理的专用化要抓住相对稳定的计算原语，并为模型变化保留空间。矩阵、向量运算可以长期受益于硬件优化，某个模型的具体层数与数据流却可能很快改变。设计得越贴近一时的最佳模型，未来调整的成本就越高。Google 的优势能否延续，取决于它在效率与适应性之间做出的判断，而非自研比例本身。

Agent 正在把这道题推向整个数据中心。

聊天产品天然存在人的停顿：用户读完答案、思考，然后再提问。长任务 Agent 可以在得到模型输出后继续调用工具、读取数据、检查结果，再次请求模型。Vahdat 所说的交互间隔缩短，指的是减少这些步骤之间的人为等待，并不意味着模型生成答案本身只需毫秒。

接续这些步骤需要另一类资源。以代码 Agent 为例，模型生成修改方案后，CPU 要运行测试、处理工具返回值，存储系统要提供代码与日志，网络要把结果送回下一轮推理。这里的 CPU 承担程序执行和编排，不能把它误读为大模型的神经网络推理转移到了 CPU。

随着任务并发增加，CPU、内存、存储与网络可能一起承压。加速器即使更快，等待测试、数据或工具结果的时间也不会自动消失。这解释了为什么 Vahdat 观察到，加速计算需求上升的同时，传统数据中心资源的需求也在快速增加。

接下来就出现了建筑层面的取舍。把 CPU、存储和加速器放得近，可以缩短协作路径；但它们的功率密度、散热和网络要求不同，混合部署会牺牲部分机房专用化收益。分别放进不同建筑，每栋楼可以更适配自己的设备，却要增加跨楼网络、时延和可靠性成本。Agent 的软件流程，最终会改变设备摆放和网络设计。

这也解释了推理基础设施为什么不能完全依靠旧训练集群接班。Vahdat 给出两个理由：推理需求本身需要新增容量，而服务用户又要求更分散的地理布局。训练可以集中部署，推理还要考虑用户距离、数据位置以及不同模型的服务需求。未来的扩张因而包含两种形态：高密度训练集群继续做大，混合资源的推理节点同时铺开。

光网络在这个系统中的角色，也超出了提高传输速率。

Vahdat 介绍的光路交换 OCS，通过可控微镜改变光纤端口之间的连接，让系统能够重构通信路径。在他描述的 TPU 集群里，一组机架发生故障后，可以把光路切向备用机架，无须人工重新插拔光纤。这里的毫秒级能力指光路重配置；任务恢复仍涉及故障识别、状态装载和软件协调。

OCS 的价值由此变得具体：它把原本需要物理操作的部分连接调整变成可编程动作，为缩短停机和重新组织计算资源创造条件。Google 早期的 TPU v4 论文已经把动态光互连与可用性、利用率联系起来，这次访谈则从运营角度解释了它为什么重要。

对光通信产业，这提供了一个更完整的需求视角：既要把更多数据送到目的地，也要让昂贵的计算资源更容易组成可用系统。不过，OCS 改变的是光路连接，CPO、NPO 讨论的是光引擎与计算或交换芯片的位置关系，两者解决不同问题。不能把对 OCS 的需求直接换算成某一种光模块封装路线的订单。

所有这些优化最终又回到电力。Vahdat 认为，短期约束会在不同环节迁移，但电力是更根本的长期问题。电网接入与供电扩建需要多年协作，提高每瓦有效产出，可以在新电力到位前扩大既有设施的服务能力。

即便如此，Google 也没有把垂直整合无限延伸。Vahdat 表示，公司优先与公用事业及电网合作，必要时用本地供电补足缺口。其经济逻辑是共享更大系统的调度和冗余能力；完全自供电，则需要独自承担可靠性保障。模型与芯片之间值得深度协同，供电却可能更适合通过外部网络协作。系统优化要求逐层算账。

同样的判断也适用于老设备。Vahdat 提到七八年前的 TPU 仍有很高利用率，但也会因新一代能效优势而被替换。设备忙碌说明它仍有用途，却不能单凭这一点判断继续保留是否最划算。当电力成为稀缺资源，旧设备占用的每一瓦电，都有交给新设备的机会成本。

这场访谈给 AI 基建研究带来的变化，是把注意力移向扩张之后的兑现能力。下一阶段应当追问：集群变大、Agent 任务变长以后，每单位电力完成的有效任务能否继续增加？如果新增计算大部分被等待、搬运和故障恢复消耗，购买更多芯片的收益就会递减。

Google 正在争取的优势，是把这些损耗压低，并把模型变化尽早反馈到下一代系统。对供应链而言，能缩短等待、减少重算、提高资源可调度性的产品，将更有机会从配套部件进入客户的核心采购判断。它们的价值，最终要由整套系统多完成了多少工作来证明。