Google AI 基础设施负责人谈前沿 AI 的物理与
来自 Training Data · 期号 2026-10-06
摘要
AI 基础设施的瓶颈正在从芯片转向电力、网络和可靠性。 Google AI 基础设施首席技术官 Amin Vahdat 认为，在十万加速器规模下，每小时都会发生多次故障，因此 FLOPS 是虚荣指标，真正该看的是“有效吞吐”（goodput）——工作负载在真实故障中实际完成的有用工作。 TPU 产品线首次拆分为 8i（推理）和 8t（训练），原因是推理与训练对内存带宽和计算密度的需求已经分化。但 TPU 的核心原语自 v1 以来没有变过。 Google 与 DeepMind 在同一间办公室联合设计芯片，在 tape-out 前拦截架构决策。长周期 agent 正在推高对 CPU 和存储的需求，与加速器同步增长。光路交换机可以在毫秒级把光信号重路由到备用机架。 电力是最终约束。Google 宁愿等电网扩容也不自己建千兆瓦电厂。 “有效吞吐比 FLOPS 更值得关注，因为故障是常态，不是异常。”
深读
本期速览 Amin Vahdat 是 Google AI 基础设施首席技术官，负责管理全球最大规模的 AI 算力建设。本期核心判断是：在十万加速器规模下，每小时都会发生多次故障，因此 FLOPS 是虚荣指标，真正该看的是“有效吞吐”（goodput）——工作负载在真实故障中实际完成的有用工作。 节目还深入讨论了 TPU 首次拆分为推理与训练两条产品线的决策逻辑、Google 与 DeepMind 在同一间办公室联合设计芯片的协作模式，以及电力作为最终约束如何影响数据中心的选址与规模。 --- 有效吞吐比 FLOPS 更能衡量真实性能（约 05:42–11:10） Amin Vahdat 认为，FLOPS 是理论最大值，而实际交付给工作负载的性能才是关键。 他解释，单个芯片的性能由 FLOPS、HBM、SRAM 容量共同决定，但更大问题是多芯片协同。当 1,000、10,000、100,000 个加速器以微秒或毫秒级同步协作时，任何一个组件故障都可能让整个系统停摆。故障后需要检测、找到检查点、恢复、重启，最坏情况要从头开始。所有这些额外工作都算“吞吐”，但不是“有效吞吐”。 > "The unfortunate reality is that at 100,000 accelerator scale... something is going to fail." > 意即：「不幸的现实是，在十万加速器规模下，每小时都会发生多次故障。」 主持人追问故障频率，Vahdat 回答：每小时多次，具体取决于配置。 故障原因呈长尾分布，网络、硬件、编译器 bug、运行时 bug、操作系统问题都可能。他特别强调，如果有一个常见原因，“我们早就修好了”。 有效吞吐是 Google 内部术语，但行业正越来越多地采用它。 --- TPU 首次拆分为推理与训练两条产品线（约 17:55–21:34） Vahdat 透露，TPU 8i（推理）和 8t（训练）的分拆决策基于对推理市场规模将占 30–60% 的预测。 他解释，两年前推理市场还很小（2–5%），即使专用芯片快 2 倍也不值得单独开一条产品线。但到 2026 年，推理需求爆发，专用化带来的 30–60% 性能提升足以覆盖固定成本。 关键设计原则：两个芯片都能做对方的工作。8i 可以训练，8t 可以推理，只是效率不如专用场景。这避免了“必须精确预测六年内各需多少”的难题，剩余容量可以灵活调配。 主持人问“为什么不把 transformer 架构直接烧进芯片”，Vahdat 回答：transformer 本质上是向量和矩阵乘法加 softmax，这些线性代数原语已经固化在硬件里。进一步专用化到“你的模型”是下一个方向，已有公司在探索。 --- 与 DeepMind 的联合设计：从概念到 tape-out 的全链条协作（约 26:…