谷歌AI基建主管谈Agent重塑数据中心与电力瓶颈

人类历史上规模最大的资本开支建设正在展开。从衡量系统真实性能的"goodput"指标，到光路交换网络、轨道数据中心，再到十年后的算力形态，谷歌AI基础设施负责人Amin Vahdat在近期一次深度对谈中，系统梳理了这场建设背后的技术逻辑与战略取舍。

谷歌今年资本开支预计超过2000亿美元，大部分用于数据中心建设。Vahdat在接受Sequoia Capital合伙人Sonia Huang访谈时表示，长程智能体（long-horizon agent）的崛起正在从根本上改变数据中心的设计逻辑，不仅推高了对加速器的需求，也让CPU、网络与存储的需求同步"暴涨"。他同时透露，谷歌必须大约每六个月将服务侧token生成能力翻一倍，而这一增长的主要来源并非硬件本身，而是软件与模型优化的持续叠加。

对投资者而言，Vahdat的判断具有直接参考价值：电力是AI基础设施扩张的最根本瓶颈，而非芯片或制造产能；软件优化对容量提升的贡献"很可能不少于硬件"；TPU路线图上，推理与训练芯片已于今年首次分拆为独立产品线，折射出推理市场的快速膨胀。

不是FLOPS，是Goodput：真实故障条件下的问责逻辑

Vahdat将FLOPS定性为"虚荣指标"，认为它只反映单颗芯片的理论上限，而实际工作负载性能取决于数千乃至数万颗加速器、CPU、网络和存储如何协同运作。

"在10万加速器规模上，总会有东西在坏，一直如此，"他说。一旦同步工作负载中任何一个组件失败，整个系统可能需要回滚至上一个检查点重新计算，这部分"无效工功"正是goodput与throughput之间的差值所在。他将其类比为在纸上解题：每次因错误回到第一步，过程本身虽然消耗了计算资源，但并不算作有效交付。

故障原因则呈现出典型的长尾分布。Vahdat坦言，"如果存在某个最常见故障原因，我们早就把它找出来修掉了"，问题来源涵盖网络互连、硬件本身、编译器缺陷、运行时错误乃至操作系统问题，每引入一代新产品都会带来新的故障模式。

Agent时代重塑数据中心架构：CPU与存储需求同步爆发

Vahdat将长程智能体的兴起视为过去一年内影响数据中心设计的最大结构性变量。

在传统人机交互模式下，用户读取模型响应、思考、再次输入，中间存在数秒乃至数十秒的"人类节拍"，这天然限制了请求频率。而在智能体场景中，模型无需等待人类，响应延迟可从秒级压缩至毫秒级，请求密度呈数量级提升。

同时，智能体在推理和编排环节大量依赖CPU：解析上一步响应、判断下一步行动、从本地DRAM、远端内存、SSD或HDD中抓取上下文——这些操作均运行于CPU而非加速器之上。"加速计算需求在上升，但CPU、网络、存储等传统数据中心组件的需求也在暴涨，"Vahdat说。

这直接引发了数据中心布局的两难：若在GPU/TPU机架旁配置大量CPU机架，将破坏针对加速器的专用化设计；若将两类机架分置于不同建筑，则楼间网络将引入数百微秒的排队延迟，并显著拉升可靠性与成本压力。

TPU首度拆分推理与训练：芯片专用化的边界在哪里

谷歌今年发布的TPU第8代首次分拆为两颗独立芯片：8i用于推理，8t用于训练。Vahdat将这一决策定性为对推理市场规模预判的直接结果。

在此前的单芯片策略下，一颗芯片需同时兼顾推理与训练，两类工作负载均无法得到极致优化。随着推理在总算力需求中的占比预计升至50%乃至更高，专门化的边际收益开始超过专用化带来的灵活性损失。

不过，Vahdat强调，这次拆分设置了一个关键安全阀：8i和8t均保留了执行对方工作负载的能力，只是非专长方向性能有所折损。"如果8i完全不能做训练，我们就必须提前精准预测六年生命周期内两类负载各自的需求量，"他解释道，这将带来难以承受的预测风险。

在更宏观的专用化哲学上，Vahdat描述了一条从通用GPU到Transformer原语固化，乃至"将特定模型架构烧入硅片"的连续谱系，并表示已有公司开始探索最后一步。谷歌目前的判断是：Transformer所依赖的矩阵乘法、softmax等线性代数原语已基本固化于硬件，进一步专用化到具体模型层是"非常非常有趣的方向"，但尚未落地。

光路交换：从MEMS反射镜到毫秒级故障切换

谷歌约15年前率先将波分复用（WDM）引入数据中心，随后叠加了光路交换（optical circuit switching）技术——后者在纯光域内完成数据路由，绕过了传统电分组交换逐包查表的电域处理环节。

Vahdat介绍，谷歌最初采用MEMS微机电开关，通过在三维空间内精确控制微型反射镜的角度，将任意输入光纤端口的光信号导向指定输出端口，实现可编程的光域路由。这一技术最初服务于两个目标：在高频通信的计算集群与存储集群之间建立光域捷径；以及在无需人工移动光纤的前提下，通过软件控制器动态重构网络拓扑以实现扩缩容。

在TPU集群中，光路交换还具备关键的容错价值：当某个TPU机架发生故障时，系统可在毫秒级内将光路重新指向备用机架，无需任何物理操作，直接压缩goodput损失。

Vahdat透露，轨道数据中心场景下，组件间将真正转向自由空间激光通信——这也是他在地面场景中回避该方案的原因（衰减损耗与大规模三维对准难度过高），但在太空环境中上述限制大幅弱化。

电力是根本瓶颈：与公用事业共同规划多年，吉瓦级需求重塑供电模式

被问及AI基础设施扩张的最大约束，Vahdat的回答直接而明确："电力是我们面临的最fundamental约束。其他所有问题我们似乎都知道如何在一段时间内解决；电力则是长期binding问题。"

谷歌的首选模式是与公用事业并网，而非自建独立电源。原因在于统计复用效应：若完全自给，达到99.99%以上可靠性意味着需建设两倍装机容量；而通过与公用事业的长期协同，在更大基数上平滑需求波动，双方均可降低冗余成本。谷歌承诺自行承担因其接入所需新增的输电线路和变电站建设费用，以避免将成本转嫁至其他用户。

但供需错配现实存在。Vahdat举例：若某年需要1吉瓦，而公用事业当年只能提供700兆瓦，谷歌可能临时自建太阳能+储能以填补缺口，并在最热月份将本地发电回馈电网。

关于单体数据中心的最优规模，他坦承这是"大量争论的来源"，且高度依赖选址：训练集群偏向吉瓦级集中部署以最小化网络延迟；而服务集群需分布全球贴近用户，单体规模更小，且因需混合配置存储与计算，专用化程度相应降低。

DeepMind协同设计：在芯片"飞行途中"拦截架构

Vahdat将与DeepMind的协作描述为"深度合作伙伴关系"，并以"在芯片架构飞行途中做修改"来形容其紧密程度。

谷歌同时推进五至六代TPU：已量产、调试上线、即将tape-out、设计中、概念阶段，构成一条横跨数年的并行流水线。不同阶段对应不同深度的协同窗口：对已量产芯片，重点在于共同最大化goodput；对即将tape-out的芯片，若DeepMind提出能带来重大收益的模型优化，双方可以紧急评估是否值得推迟tape-out以纳入硬件修改——"叫停一次tape-out是大事，但如果机会足够大，我们绝对会一起努力"；对设计阶段的芯片，则进行三至四年维度的模型架构趋势共预测，依托仿真基础设施评估不同硬件架构对未来工作负载的适配度。

Vahdat还披露，谷歌目前已在使用Gemini为未来版本的Gemini设计硬件，形成模型辅助芯片设计的自我强化闭环。他和DeepMind的Koray及Demis"每周都会多次交流"。

2036年的超级计算机：单机架多兆瓦，或直接发射入轨

对于十年后算力形态的预判，Vahdat给出了两条并行路径。

在地面形态上，他预计集成度将大幅提升，机架将从外部可见的繁复光纤束演变为"只有一小束光纤从机架里出来"的高度集成单元。单个机架功耗可能达到数兆瓦量级，进场安装仅需接入电、水、光纤三路即可运行——制造与部署将更趋向模块化工厂预制。

在轨道路径上，谷歌已将轨道数据中心列为正式在推进的moonshot项目，核心逻辑在于能源优势：太空中无大气衰减使可用功率天然高出约40%；太阳同步轨道可实现98%至100%的日照覆盖，而地面设施通常仅为28%至35%，叠加后的能量密度优势可达3至4倍，且无碳排放。

主要挑战在于冷却（太空散热反而更难）、可靠性维修（硬件损坏后维修难度远高于地面）以及组件间通信（将被迫采用自由空间激光而非光纤）。Vahdat表示，这些问题"没有根本性showstopper"，并开玩笑称2036年或许真能"把机架发射升空，由空间站机械臂接住，插进正确模块"。

以下为访谈全文：

主持人（索尼娅·黄，Sequoia Capital）：

欢迎 Amin Vahdat 来到节目。非常感谢你今天加入我们。我也很期待今天的对谈。今天的主题让我非常兴奋，因为我们正处在大规模资本开支建设的历史中心。

阿敏·瓦赫达（Google AI 基础设施负责人/首席技术官）：

能来这里我也很兴奋。今天的话题非常激动人心。

主持人：

你正处在这场人类历史上最大规模的资本开支建设之中。仅 Google 一家，今年预计资本开支就将超过 2000 亿美元，其中大部分用于建设数据中心。而你正是这一切的核心人物：去年年底你被任命为 Google AI 基础设施负责人，正在牵头人类历史上资本密集度最高的建设之一之一。所以我非常期待今天和你一起深入聊这件事。

阿敏：

这确实是行业层面、也包括 Google 在内都非常重大的一年。老实说，我认为我们以前从未见过类似情况；当然，在 Google 没有，我甚至觉得在人类历史上也没有，无论从建设规模还是转型速度来看，都令人难以置信。

主持人：

在深入之前，先给观众快速普及一下：什么是 AI 数据中心？它和非 AI 数据中心有什么不同？

是什么让数据中心成为“AI 数据中心”

阿敏：

这是个很好的问题。AI 数据中心和非 AI 数据中心其实有很多相似之处，并不是截然不同。它们都由混凝土构成，都有一个围合空间；都有电气场、机械场、冷却系统；有成排的电力分配；还有大量网络基础设施，也就是把大量计算设备彼此连接起来；数据中心里也有相当多存储基础设施。

我认为 AI 基础设施最大的区别在于“专门化”。过去建设数据中心时，本质上是在做一个 20、25、30 年期的建筑投资。我们会考虑这座建筑在 20、25、30 年里如何演进。里面可能放服务器，可能放网络、存储，也可能放一些加速器，比如 GPU、TPU 或其他芯片；但规划周期是 25 到 30 年。硬件寿命可能是六年，所以我们必须为许多代硬件做规划。

而 AI 数据中心往往更像是“为特定目的而建造”。换句话说，我们经常把建筑和将要放进其中的硬件做共同设计。比如，我们可能决定不在某栋楼里放太多存储。为什么？因为一个存储机架可能有 10、20、30、40 千瓦功耗；而把它放在 TPU 机架或 GPU 机架旁边，那些机架今天轻松达到数百千瓦，未来几年甚至可能更高。设计一栋楼时，如果要在一排里放 30 个存储机架，和只放一两个 AI 机架，是非常不同的设计。你可以从尺寸、功率，以及功率如何在建筑内分配等角度去理解这种差异。

网络也是同理。存储机架所需的网络带宽很小，尤其是机械硬盘存储，相比 AI 机架更是如此。如果你想让数据中心在 30 年周期内完全可互换、完全通用，你很可能会把它建得过大、过度设计。AI 数据中心很可能更加专用的，与硬件共同设计，甚至精细到冷却和配电等环节。也就是说，会有更多共同优化。

主持人：

你们交付了一个很大的 Vera Rubin 集群给我的一家被投公司 Ineffable Intelligence，我看到了它出货时的照片。那真是一个杰作。那简直就是纪念碑，展示了人类能做出什么样的工程。

阿敏：

确实。那只是几个机架，但机架之间的布线、光纤分配真的非常美。美不美见仁见智，但对我、对你，以及不少听众来说，它确实是一件工程之美。我们把这张照片放到社交媒体上，人们非常喜欢 Ineffable Intelligence 正在做的事；那是一个非常出色的团队，也获得了很多关注。不过实际上，大家最喜欢的是光纤照片，尤其是光纤那种分形般的结构。那篇帖子成了我们有史以来最受欢迎的帖子之一。所以我们确实很兴奋。

主持人：

我看到照片时浑身起鸡皮疙瘩。

不是 FLOPS，而是 Goodput：当系统每小时都会出故障时，如何问责

主持人：

在这场大规模建设中，你们如何衡量自己、如何问责？我们在节目开始前聊到，FLOPS 更像是一个虚荣指标，你更偏好另一个指标。能展开讲讲吗？

阿敏：

无论 FLOPS，还是你偏好的其他芯片中心指标，本质上都是“理论值”。也就是说，在某种条件下，对于某颗芯片，这是它能交付的最大 FLOPS。但我们最终真正关心的是：某个工作负载实际交付的性能如何。工作负载的性能很少由单颗芯片决定。它可能取决于 FLOPS、HBM、SRAM 容量等，这些因素都非常重要；但它也可能取决于 2、4、8、16、1000、10000 甚至更多颗芯片如何组合在一起。这里不仅包括加速器，无论 TPU 还是 GPU，还包括给它们喂数据的 CPU，以及把所有设备连接起来的网络。

所以问题是：你运行的工作负载是什么？这个工作负载的性能是多少？一个有意义的度量是 FLOPS 利用率：对于某个特定工作负载，如果你理论上具备某个teraflop/petaflop 能力，你实际交付了其中的多少比例？

这就是 goodput 的一种度量。什么是 goodput？大家熟知 throughput，即“吞吐”。那是理论上可能的吞吐。但现在要考虑其他因素。一个是工作负载本身固有的 slowdown；另一个非常关键的因素是可靠性。

从问责方式上说，如果有一个芯片在同步工作负载中失败，而这些工作负载——无论训练、服务还是 agentic 工作负载——往往都是同步的，也就是说许多组件同时协同工作。假设有 1000、10000、100000 个组件同时工作，并且需要在微秒或毫秒级粒度上协调。只要其中一个失败，就可能让整套系统停下来，因为每个组件都依赖其他组件完成自己的那部分工作，才能共同回答一个很难的问题。

其中一个组件停了，我们现在必须弄清楚发生了什么、哪一个停了。我们在之前某个时间点保存的 checkpoint 是什么？如何恢复这个 checkpoint？如何重启？最坏情况下，我们可能不得不从头开始，那就非常糟糕。某些情况下确实可能发生，尤其在推理侧更常见。重点是：如果失败后你必须回头重做大量计算，如果必须暂停并等待排查故障，这些“工作”都不算真正帮助你得到答案。

就像你在纸上解题：第一步、第二步、第三步、第四步。如果你因为犯错必须回到第一步，你当然仍在“做功”，那是 throughput；但真正重要的是 goodput，也就是你交付答案所花费的总时间。如果有故障、有故障恢复、有任何打断工作的因素，这些都会计入问题之中。

所以我们问责自己的方式是：交付的 goodput，而不是理论 benchmark 吞吐，也不是理论上的“ goodness”。对于一个真实工作负载，在真实故障条件下，实际发生了什么？不幸的是，在 10 万加速器规模下，我要说的是：在那个规模上，总是有东西在坏。一直如此。而且每一颗这样的芯片，都是自然界的奇迹，处于制造能力最前沿。现在这些芯片还不只是一颗芯片，而是由两个、四个、八个甚至更多 chiplet 组成的封装，再加上旁边的 HBM、网络连接，也许还有共封装光学。无可指摘，但确实有很多东西可能失败。而一旦你有 10 万颗这样的设备，总会有东西失败。你必须为此做好准备：近乎实时地检测，近乎实时地恢复。遥测问题非常庞大，就像持续不断地在干草堆里找针；当然是在秒和分钟级别持续在线，而对某些任务，甚至是小时、天、周级别持续在线。

我们问责自己的标准，就是数据中心里真正重要的工作负载交付了多少 goodput。

主持人：

goodput 是 Google 内部术语，还是行业术语？

阿敏：

这是 Google 术语，但我看到行业里越来越多的人也开始采用它。

主持人：

帮我校准一下：在 10 万加速器规模，故障频率大概是多少？每天一次？每小时一次？

阿敏：

在这个规模上，肯定是每天多次，取决于具体配置，甚至可能每小时多次。总会有东西失败。

主持人：

最常见故障原因是什么？

阿敏：

问题就在这里。这确实是个很好的问题。如果存在某个“最常见故障原因”，我们早就把它找出来并修掉了。实际情况是一条不断发现新问题的长尾曲线。每当引入新产品，总会有新问题击中我们。坦率说，很多情况下正因为它处于最前沿，故障可能来自网络相关，可能来自我们如何以超高速度把这些设备连接在一起，也可能来自硬件本身。这些我们会逐项解决。但很多 issue 也可能是软件问题。这也是我们问责自己的另一部分。芯片也许具备某个 FLOPS 能力，但如果有编译器 bug、运行时 bug、模型问题、操作系统问题，那都没关系——它照样会影响系统性能。你可能拥有完全可靠、完美的硬件，但仍会被软件问题拖垮。

每六个月让 token 产能翻倍，以及增益究竟来自哪里

主持人：

从加速器公司——Nvidia 或 TPU 团队——那里，是否存在一个标准参考栈：只要围绕他们的加速器构建这个最优系统，你就没问题？还是说，你们在半导体公司提供的方案之上，还必须自己做很多数据中心设计？

阿敏：

确实存在参考栈。我想说，Nvidia 是一家非常出色的全系统公司；它显然是半导体公司，但又不只是半导体公司。他们提供非常强的参考栈。但据我们观察，大多数客户会利用这个参考栈，同时许多客户也会做专门化。也就是说，他们会发现：对于自己的特定用例，存在一个自然出现的优化机会，或者有某些不同需求必须处理，于是他们会去做。TPU 这边也类似。我们也有参考栈，大多数人会利用它，但很多人也会进一步专门化。

主持人：

明白了。再谈整体容量：你告诉团队，Google 必须大约每六个月把服务能力翻一倍，对吗？

阿敏：

需要澄清一下。这里说的是“有效可用容量”。最终我们看的是服务视角下的 token 生成能力。容量是软件和硬件的结合。硬件可能有某种所谓“固有”FLOPS 水平。我说的并不是必须每六个月把 FLOPS 数量翻倍；那只是路径之一。你确实必须每六个月让硬件生成 token 的能力翻倍。而其中来自软件的部分，很可能不少于来自硬件的部分。也就是说，收益可能来自模型优化，也可能来自运行时优化。实际上，更可能是数十、数百项单独优化不断落地，一次又一次叠加，才让这一切成为可能。但容量提升的速度确实令人难以置信。

主持人：

过去几年里，我们已经看到了几年数据中心建设、模型进步和软件进步。以“每瓦智能”来衡量容量增长，经验上分解一下：多少来自硅片本身，多少来自模型，多少来自其他软件，以及其他大的组成部分？

阿敏：