深度｜对话 Google AI 基建负责人：从芯片配比到全球部署，Agent 正在重写数据中心的建设逻辑
当一家公司的 AI 服务能力需要每六个月翻一倍，买更多芯片只是问题的开始。十万颗加速器组成的集群里，故障随时发生；模型几个月就会迭代，硬件却要使用多年；工程师还在优化上一代系统，下一代数据中心的供电和冷却方案就必须提前确定。这正是 Google AI 基础设施负责人 Amin Vahdat 面对的日常。在与红杉资本 S
当一家公司的 AI 服务能力需要每六个月翻一倍，买更多芯片只是问题的开始。十万颗加速器组成的集群里，故障随时发生；模型几个月就会迭代，硬件却要使用多年；工程师还在优化上一代系统，下一代数据中心的供电和冷却方案就必须提前确定。
这正是 Google AI 基础设施负责人 Amin Vahdat 面对的日常。在与红杉资本 Sonya Huang 的这场对话中，他从 TPU 的设计取舍讲到长时程 Agent 如何改变数据中心，也解释了 Google 如何衡量这场建设的实际回报：芯片账面上有多少算力，最终必须落实为真实任务完成了多少、消耗了多少电力，以及故障后损失了多少进度。
贯穿访谈的是一个难题：如何用建设周期长达数年的基础设施，承接仍在快速变化的 AI 需求？ 以下是他的主要观点：
算力的账，要算到任务完成的那一刻。 FLOPS 衡量的是理论计算能力，Google 更关注有效吞吐：扣除故障、等待和重复计算之后，系统究竟完成了多少有效工作。集群越大，快速发现故障并恢复运行，就越决定实际产出。
Token 生成能力每六个月翻倍，至少一半的提升要靠软件。 Vahdat 强调，这一目标指向软硬件共同交付的服务能力。模型、编译器和运行时的持续优化，能够让已经部署的硬件释放更多产能。
专用芯片的成败，取决于能否提前判断需求会持续多久。 专业化能换来更高速度和能效，也会牺牲灵活性。设计者必须判断，一类工作负载几年后是否仍有足够规模，以及优化收益是否值得承担额外成本。
Agent 正在改变数据中心的资源配比。 人阅读和思考的间隔，曾自然限制模型请求的频率。长时程 Agent 可以连续调用模型、执行工具、读取上下文，由此同时推高加速器、CPU、网络和存储的需求，迫使数据中心重新考虑这些资源如何部署。
推理需求已经大到必须单独建设基础设施。 训练集群退役后转做推理，无法满足全部需求。推理服务还需要靠近全球用户，并协调计算、存储和网络，因此有自己独立的选址与设计逻辑。
七八年前的 TPU 仍然满负荷运转。 按照 Vahdat 的说法，Google 部分老一代 TPU 的利用率仍达到 100%。新芯片的效率进步，并不意味着旧硬件立即失去用途；替换决策还要综合折旧、能效和整个系统的改造成本。
电力供应要求提前多年规划，接入电网仍是 Google 的首选。 自建发电设施需要承担昂贵的冗余成本，与公用事业公司协同建设、在必要时补充本地发电，更有利于共享容量、提高可靠性。
垂直整合的性能收益，需要与开放接口并存。 Google 希望通过芯片、网络和软件协同设计提升效率，同时让客户保留框架与硬件选择。Vahdat 的判断是，这场基础设施建设规模太大、影响太深，无法只依赖某一家供应商的封闭技术栈。
专业化是一门预判的艺术——为什么AI数据中心必须"专用"
Sonya Huang：
在硬件领域，正如你所知，有一个机会：你越是针对特定工作负载进行专业化，硬件的灵活性就越低，但速度会更快、能效会更高。所以这是一门艺术，也是一种预判
——
你在为什么而设计，那个工作负载能持续多久。换句话说，如果它一两个月或三个月后就消失了，即使那三个月里规模很大，你的拦截窗口也非常窄。所以它必须有一定的持久性。而且你必须能够准确预判，针对它做专业化能获得多大的收益。非常高兴欢迎
Amin Vahdat
来到节目。
Amin
，感谢你今天的参与。
Amin Vahdat：
真的很兴奋能来到这里，我非常期待。
Sonya Huang：
我对今天的主题非常兴奋，因为我们正处于人类历史上最大规模的资本支出（
capex）建设之中。你就身处其中。仅
Google
今年预计就将在资本支出上投入超过
2000
亿美元，其中大部分用于建设数据中心。你正处在这一切的中心。你在去年年底被任命为
Google AI
基础设施负责人。所以，你是这场人类历史上最资本密集型建设之一的掌舵人，我非常期待和你深入探讨。
Amin Vahdat：
今年确实是重大的一年，当然整个行业包括
Google都是如此。老实说，我认为我们从未见过这样的事情，至少
Google
肯定没有，但正如你所说，从人类历史的角度来看，就建设规模和转型速度而言，真的令人难以置信。
Sonya Huang：
在我们深入之前
，也许先给听众做个速成课。什么是
AI数据中心？
AI
数据中心和非
AI
数据中心有什么区别？
Amin Vahdat：
这是个很好的问题。
AI数据中心和非
AI
数据中心其实有很多相似之处，它们并没有根本性的不同。它由混凝土构成，有外壳，有电力场、机械场、冷却系统，有一排排的电力分配。那里有大量的网络基础设施
——
换句话说，我们把大量计算资源互相连接起来。还有相当数量的存储基础设施。
我认为
AI基础设施最大的不同在于专业化。
过去，我们建数据中心实际上是一个
20年、
25
年、
30
年的建筑投资。我们在考虑它在这个
20
到
30
年期间将如何演进。你可能会把服务器放进去，可能有网络、存储，可能有一些加速器
——GPU
、
TPU
之类的，但那是一个
25
到
30
年的规划周期。而硬件的寿命可能只有六年，所以我们要规划很多代。
AI数据中心往往更加专用化。换句话说，我们经常将建筑与将要放入其中的硬件进行协同设计（
co-design
）。
我们可能会说，实际上我们不会在这个建筑里放很多存储。为什么？因为一个存储机架可能有
10、
20
、
30
、
40
千瓦的功率。你把它放在一个
TPU
机架或
GPU
机架旁边，后者今天很容易达到数百千瓦，未来几年人们谈论的可能是兆瓦级。设计一个建筑，一排可能放
30
个存储机架，而同一排只放一两个
AI
机架
——
这是非常非常不同的设计。就从尺寸、功率以及如何在建筑中分配来看。
网络也是一样。存储机架需要的网络量很小，特别是如果它是硬盘的话，与
AI机架相比。所以，如果你试图让它完全通用化，你可能会建得太大、过度建设。
在一个
30年的周期内追求通用性
——AI
数据中心很可能会更加专用化，与硬件协同设计，甚至到冷却和电力分配的程度。所以是更多的协同优化（
co-optimization
）。
Sonya Huang：
你们给我的投资组合公司
Ineffable Intelligence交付了一个大型
Vera Rubin
集群，我看到了它出厂时的照片。那是一件艺术品。
Amin Vahdat：
是的，就像看人类历史上最大的工程项目一样，你看着那个数据中心，会想，哇，那是人类能力的纪念碑。
Sonya Huang：
我们拍了一张很好的照片，这只是几个机架。它的布线、光纤分布真的很
——
美不在观者眼中，但对于像我、你以及听众中的其他人来说，它确实是一件艺术品。我们把这照片发到社交媒体上，人们很喜欢
Ineffable——
他们是他们所做的事情的忠实粉丝。很棒的团队，获得了很多关注。一个给
Ineffable
的好机架。但实际上，人们就是喜欢看那些光纤的照片，光纤那种分形般的特性。那实际上是我们有史以来最受欢迎的帖子之一。所以我们真的非常兴奋。
Amin Vahdat：
是的，我看到那张照片时起了鸡皮疙瘩。
图片来源：Sequoia Capital
FLOPS是虚荣指标，有效吞吐才是问责标准
Sonya Huang：
在这
场大规模建设中，你们如何衡量并要求自己对结果负责？
——
有效吞吐（
goodput
）而非
FLOPS
：当每小时都有东西出故障时如何问责。我们在节目开始前谈到，
FLOPS
是一个虚荣指标，你更偏好另一个替代指标。你能展开说说吗？
Amin Vahdat：
我想指出的一点是，无论是
FLOPS还是你喜欢的其他以芯片为中心的指标，这些都是理论值。
换句话说，在某些条件下，对于你拥有的任何芯片，这是你能交付的最大
FLOPS。我们最终真正关心的是工作负载所交付的性能。
这才是我们要看的。而且实际上相对很少性能是由单个芯片决定的。
FLOPS、
HBM
、
SRAM
容量等等，这些都非常重要，但关键可能是
2
个、
4
个、
8
个、
16
个、一千个、一万个甚至更多这样的芯片组合在一起，不仅仅是加速器
——
无论是
TPU
还是
GPU——
还有为它们提供数据的
CPU
、连接它们的所有网络。所以你运行的是什么工作负载，那个工作负载的性能是什么？一个有趣的衡量指标是你的
FLOPS
利用率。比如，对于某个特定工作负载，如果你的理论能力是每秒多少太浮点或拍浮点运算，你实际交付了其中的多少比例？这就是有效吞吐（
goodput
）的衡量。
Sonya Huang：
什么是有效
吞吐（
goodput）？
Amin Vahdat：
你可以把吞吐量（
throughput）理解为一个众所周知的术语
——
那是可能的吞吐量。但现在让我们考虑一些其他因素。
一个是工作负载的减速
——
这本身就是工作负载固有的
——
还有其他真正影响可靠性的方面。
就我们如何问责而言，如果有一个芯片在同步工作负载中发生故障
——
许多这类工作负载，无论是训练、推理服务还是智能体工作负载，都是同步的。有许多组件同时协同工作。如果你有一千个、一万个、十万个这样的组件同时工作，它们需要在微秒或毫秒级别进行协调。其中一个失败了，可能会让整个系统停下来，因为每个人都依赖其他人完成自己的那部分工作，才能得出一个非常困难问题的答案。一个停了，现在我们必须弄清楚发生了什么、哪个停了。我们在之前某个时间点有什么检查点（
checkpoint
）？如何恢复那个检查点？如何重启？最坏的情况，我们得从头开始。那会非常糟糕。但在某些情况下确实可能发生，特别是在推理侧。
关键是，如果你现在必须回去重做大量计算，如果你必须暂停等待弄清楚故障原因，所有这些工作都是工作，但它并没有真正帮你得到答案。就好比你在纸上解一道题，第一步、第二步、第三步、第四步。如果你因为犯了错误必须回到第一步，是的，你仍在做工作
——
那是吞吐量，你在做工作
——
但在交付答案方面的有效吞吐是什么？基本上是你解决问题所花的总时间。那才是重要的。如果你有故障、有故障恢复、有任何中断你工作的东西，那都是问题的一部分。
那么我们如何问责？是交付的有效吞吐，不是理论基准吞吐量或理论上的好，而是针对实际工作负载、真实故障条件下实际发生了什么。
不幸的是，在
10万加速器规模下
——
在那个规模下，总有东西在出故障，一直都有。而且每一个芯片都是大自然的奇迹，它们处于可制造性的最前沿。对我来说这很震撼。而且这些芯片不只是单个芯片，它们是由多个芯粒（
chiplet
）组成的封装
——
很多情况下是
2
个、
4
个、
8
个甚至更多芯粒组合在一起。当然还有旁边的
HBM
、网络连接，可能还有共封装光学。不是批评
——
很多东西都可能出故障。如果你有
10
万个，总会有东西出故障。你必须为此做好准备，近实时地检测，近实时地恢复。做所有这些
——
遥测问题非常巨大，就像在干草堆里持续找针，肯定是在秒和分钟级别，但对于某些任务，是小时、天甚至周级别的持续在线。
我们如何问责，就是看我们为数据中心中真正重要的工作负载交付了多少有效吞吐。
Sonya Huang：
有
效吞吐（
goodput）是
Google
的术语还是行业术语？
Amin Vahdat：
是
Google的术语，但我认为行业内越来越多的人开始采用它。
Sonya Huang：
让我校准一
下，
10万加速器规模，我们是说每分钟出一次故障、一天一次
——10
万加速器是怎样的？
Amin Vahdat：
我想在那个规模下，肯定是每天多次，根据具体配置，可能每小时多次，总会有东西出故障。
Sonya Huang：最常见的故障原因是什么？
Amin Vahdat：
问题就在这里，这是个很好的问题。如果有某种常见的故障原因，我们早就发现并修复了。实际上，故障是一个不断浮现的长尾问题。
每当有新产品推出，总会有新的问题打击我们。很多时候，坦白说，因为处在技术的最前沿，问题可能出在网络，可能出在我们如何以超高速连接这些设备，也可能是硬件相关的。这些我们都可以逐步解决。但很多问题其实出在软件上。这也是我们从另一个角度进行问责的方面。芯片或许具备一定的
FLOPS算力，但如果你有编译器
bug
、运行时
bug
、模型问题或操作系统问题等等，那硬件能力就不重要了，
因为这些软件问题都会拖垮整个系统的性能。也就是说，你可能拥有完美且完全可靠的硬件，但软件缺陷会对你造成致命打击。
每六个月翻倍的不是FLOPS，而是token生成能力
Sonya Huang：
是否有标
准的参考栈
——
每六个月将
token
容量翻倍，收益到底来自哪里
——
来自加速器公司如
Nvidia
，还是来自
TPU
团队说
“
这是围绕我们加速器构建的最优系统，只要你按这个系统构建就没问题
”
？还是说在半导体公司给你的东西之上，你们需要做多少自己的数据中心设计？
Amin Vahdat：
是的，确实有一个参考栈。我认为
Nvidia是一家令人惊叹的全系统公司
——
他们显然是一家半导体公司，但又绝不仅限于半导体公司，他们为客户提供了一个极其强大的参考架构。但根据我们的观察，大多数客户虽然会利用这个参考栈，但很多也会在上面做定制化。换句话说，他们会发现针对自身特定的用例存在优化空间，或者需要采取不同的方案，然后他们就会去落地这些修改。同样，在
TPU
侧我们也有一套参考栈。大多数客户会直接使用它，但同样有不少客户会在此基础上进行深度定制。
Sonya Huang：
明白了。那么
在总容量方面，你告诉团队
Google需要大约每六个月将服务容量翻倍，对吗？
Amin Vahdat：
澄清一下，这里指的是从服务角度来看的有效可用容量，也就是
token生成能力。所以，这里的
“
容量
”
是软件与硬件的结合体。硬件确实有其所谓的固有
FLOPS
水平，但我说的并不是每六个月把
FLOPS
数量翻倍（虽然那也是一种路径），而是你必须每六个月将硬件生成
token
的能力翻倍，并且其中至少有一半（甚至更多）的提升将来自软件，而非硬件。换句话说，这可能是通过模型优化来实现，也可能是通过运行时（
runtime
）优化来实现。
实际上，这往往需要依靠数十甚至数百个单独的优化不断落地、持续叠加，才最终让这种翻倍成为可能。
但毋庸置疑，容量提升的速度确实令人难以置信。
Sonya Huang：
我
想我们已经有了几年的数据中心建设、几年的模型进步和软件进步。以每瓦智能（
intelligence per watt）衡量的容量，经验上的分解是怎样的？多少容量增长来自硅本身，多少来自模型，多少来自其他软件和其他大的组成部分？
Amin Vahdat：
这是个很好的问题。
我没有确切的分解数据，但根据我们的经验，以每瓦智能（
intelligence per watt）来衡量，大部分收益来自模型侧的改进。
顺便说一句，每瓦智能是一个极好的指标。我们内部更关注的是每瓦有效吞吐（
goodput per watt），之后可以再聊为什么
“
瓦特
”
必须作为分母
——
有效吞吐能很好地衡量每瓦实际交付的智能，而且它是针对特定工作负载的指标。我会说，相当大一部分收益来自模型侧的软件系统。为什么？因为软件能确保你现有的硬件被最有效地利用起来。然后硬件本身也相当惊人
——
换句话说，
我们现在处于一个每年实现
2倍甚至更高性能提升绝对可能的世界，硬件完全支持这一点。它就像是一个免费的乘数（虽然不是真的免费），在它之上的人都可以依赖这个乘数，每年把所有人的能力向上托举。
2013年的反共识赌注——TPU从推理芯片到训练芯片，再到8i/8t分拆
Sonya Huang：TPU
的赌注：从
2013
年的反共识判断到
8i
和
8t
的拆分
——
我想谈谈
TPU
项目和协同设计。
Google
十多年前就开始构建定制芯片，当时这是一个反共识的判断。
TPU
项目是如何演变的？
Amin Vahdat：
变化非常大。项目在
2013年启动时，确实是一个反共识的判断。很难把自己放回那个时刻
——
当时的主流智慧是，最聪明的人都会告诉你：不要为单一工作负载构建定制加速器。为什么？因为摩尔定律还在，每
18
到
24
个月性能就能翻倍；你可以利用标准编程模型，无论是
C++
、
Java
还是
Python——
这就像芯片界的
“
苦涩教训
”
。那个教训就是：
专业化永远不会赢。
但在当时的情况下，我们有一两个特定的应用将极大受益，且如果不用专用芯片，就需要难以想象的海量通用
CPU来支持。所以
2013
年确实是一场豪赌，公司内部也有不少人不太确定能否成功。但结果证明，这是一次极其成功的赌注。
第一颗芯片完全专注于推理，第二颗芯片则是
——
既然思路走得通，我们不如用它来做训练。
从那时起，它被越来越多的用例采用。而就在第二颗芯片推出前后，
Transformer被发明了。这是一个重大时刻，它彻底改变了
TPU
项目。 当然，我们也发现推荐系统在
TPU
上跑得极好，所以广告及相关业务也随之接入。
所以，
TPU的演进史就是一部范围和影响力的扩张史。它从推理服务的少数几个应用（主要是语言翻译和语音识别）起步，扩展到训练，接着拥抱
Transformer
和推荐系统，并随着生成式
AI
时代的到来继续泛化，最终走向规模越来越大、扩展性越来越强的系统。
Sonya Huang：你提到Transformer是一个重大时刻。我很好奇探讨TPU——它是一种特定架构，但并不是Transformer特定的。你如何在芯片对工作负载的特定性这条细线上把握分寸？
Amin Vahdat：
这是个很好的问题，
归根结底是适用性的问题
——
即芯片对特定工作负载的适用性。每一代芯片我们都在思考：是否需要进一步专业化？
大约两年前，我们面临一个抉择：
2026年到底该出两颗芯片还是一颗？一颗芯片同时兼顾推理和训练且都做得不错，或者干脆拆分成两颗，分别针对推理和训练深度定制。
经过大量分析，最终促成了今年两颗芯片的发布：
8i用于推理，
8t
用于训练。我们最终意识到，虽然几年前未必如此，但到
2026
年，推理和服务的需求将真正起飞。
如果我们预计一颗在服务侧显著更快的专用芯片能吃掉
30%到
60%
的市场，那这个决定就很有意义。
反之，如果预测推理只占市场的
2%或
5%
，哪怕专用芯片快
2
倍可能也不划算。因为这种情况下，你大概率还是会选择那颗
“
不是完全优化、但具备统一性
”
的通用芯片。
所以，这本质上是一个算账的过程：你要进一步专业化吗？那个工作负载到底有多大？几年后预计有多大？它是否有持续的增长潜力？
在硬件领域，你越针对特定工作负载专业化，灵活性就越低，但速度会更快、能效会更高。
所以这是一门艺术，也是一种预判
——
你在为什么而设计，那个工作负载能持续多久？如果它几个月后就消失了，哪怕当下规模很大，你的拦截窗口也太窄了。
因此，它必须具备一定的持久性，且你必须能准确预判专业化能带来的确切收益。
Sonya Huang：
所以大致的权衡是，支持一个新项目有很大的固定成本。是的。你基本上必须认为那个特定项目有足够的需求来证明成本合理。
Amin Vahdat：
正是如此。某种程度上，我们的
8i和
8t
芯片都能兼顾对方的工作，这一点至关重要。试想一下，如果
8i
只能做推理、完全无法训练（即训练性能为零），反之亦然，那么这就成了一个致命缺陷。为什么？
因为硬件的生命周期长达六年，你必须在今天提前准确预测未来六年内推理与训练各自的算力需求占比。
在这个案例中，我们做得很好，因为两颗芯片在各自专业化的方向上性能更强。同时，如果你在某类芯片上有多余容量，它们实际上能互相顶替。
这也揭示了硬件设计的边界：专业化程度越高，你就越可能陷入过度设计，从而丧失灵活性。
Sonya Huang：
如果大致的权衡
是项目规模，那么在我看来，现代
AI市场如此多都是基于
Transformer
的。所以也许问一个挑衅性的问题：为什么不直接把
Transformer
架构烧进芯片里？
Amin Vahdat：
是的，我认为它是基于
Transformer的，但下一个层次的问题是：
Transformer归根结底是由向量与矩阵乘法运算以及
softmax
组成的，所以其底层是一系列本质上的线性代数原语。
我们（以及其他厂商）已经把这些原语大致固化到硬件中了。但这仅仅是第一步。虽然大家都在跑
Transformer，但具体到你的模型架构
——
你有多少层？如何在层间游走？如何跨层连接？对于每一个维度，你所应用的确切矩阵和向量形状是什么？
你可以更进一步，不仅针对
Transformer做专业化，还要针对你具体的模型做专业化
——
这是下一个层次的定制。
我认为目前业界有不少公司正在思考这个方向，我也认为这是一个非常非常有趣的探索方向。
Sonya Huang：
那么在这个时间点，
你的客户是否将
TPU和
GPU
视为大致可互换的等价物，还是某些问题更适合其中一个？
Amin Vahdat：
肯定有一些问题更适合其中一个。
GPU比
TPU
更通用，这是明确的。
Google
和
Google Cloud
有令人难以置信的产品。我们卖很多
GPU
，内部也使用
GPU
。但我认为归根结底取决于你问题的具体细节。
我们的客户
——
两者之间有重叠
——
但客户会评估他们的工作负载和选项。我们在
Google
喜欢做的是给客户选择。
换句话说，我们希望为他们的需求提供正确的解决方案，当然提供最符合他们需求的方案。
性能留在桌上，还是锁定在栈里
Sonya Huang：协同设计的利与弊——从芯片到网络到软件，协同设计的理由是什么，反对协同设计的理由又是什么？
Amin Vahdat：
你可以想象，如果你拥有一个端到端的层栈，且希望能自由挑选任何组件
——
假设你跨多个云、多种硬件和多种软件运行。你可以设计一层抽象层，基本上宣告：
“
我能运行在任何硬件、任何软件、任何网络拓扑上；无论你给我多少网络带宽都没问题，我的系统将完全自适应。
”
这样一来，你获得了一项强大的能力：你可以随处迁移，新容量一旦上线，你立刻就能运行，因为你的系统就是被设计成能够利用任何资源的。你无需硬编码，也无需针对任何特定基础设施进行专业化。
但缺点在于，如果你变得完全通用，你可能就会把大量性能留在桌面上。前提是你对任何人的硬件、软件、网络、存储和计算栈都完全灵活。而协同设计的核心理由在于：如果你试图获得完全通用性，每一层之间都会存在巨大的阻抗不匹配。
每层可能都有
10%、
20%
甚至
2
倍的优化空间。当你把这些优化机会层层相乘，突然间，你就会在端到端层面（无论是每瓦智能、每瓦有效吞吐，还是底层电力输送与软件优化）获得一个巨大的收益。
所以，通用化的优点是随时随地运行、没有锁定；缺点则是你留下了显著的、极大概率是巨大的性能损失。
Sonya Huang：
据我了解，如
果你看
OpenAI和
Anthropic——OpenAI
主要构建在同构计算栈上，
Anthropic
构建在更异构的计算栈上。你认为这是协同设计导致它们收敛到据传非常不同的模型架构的部分原因吗？
Amin Vahdat：
我不能推测。我不想推测
OpenAI和
Anthropic
在做什么。这是一种可能性。但在不了解他们细节的情况下，我想可能有很多原因导致他们最终采用不同的架构。
Sonya Huang：那Google呢？我很好奇你的团队和DeepMind的工作关系——与DeepMind肩并肩：在流片中拦截芯片——是怎样的？在模型开发的哪个阶段谁在房间里，你们如何一起做协同设计决策？
Amin Vahdat：这是我在Google最有趣、也最令人满足的工作之一——有机会真正与DeepMind团队肩并肩合作，共同设计我们的硬件和模型。
这还涉及第三个元素，即将其扩展到消费者服务和云端，我稍后再谈。但就
DeepMind而言，这确实是一种深度的伙伴关系。
我举个例子：他们提出了某项模型优化
——
比如针对
Transformer
或某种特定数学运算。此时我们可能有一颗芯片正在研发中，尚未完工。然后他们说：
“
天哪，如果硬件能支持这个，我们的端到端训练或服务可能会显著更快、更高效，要改变你们正在执行的硬件定义来容纳这个需求，需要付出什么代价？
”
这促使我们的工程师和研究人员在同一个房间里密集工作几天甚至一两周，共同探讨：
“
好的，我们可以做到这个。
”
更常见的情况是，我们无法完全实现你们想要的东西，但我们可以换一种方案，也许你们可以把模型架构往另一个方向调整，从而获得你们想要的
98%
以及我们想要的
90%
。是的，我们可以回头去修改硬件。或者我们也可以说：
“
我们要把流片（
tape-out
）推迟一两周，因为这种级别的收益完全值得。
”
同样，在规划路线图时，我们在任何时间点都有多代芯片在同时推进。我们有正在量产的芯片；有刚从代工厂回来、正在调试以达到工作状态的芯片；有处于实现阶段、即将流片送往代工厂的芯片；有处于设计阶段的芯片；还有处于概念阶段的芯片。所以，这实际上是一个包含五六个阶段、跨越多年的流水线。
与
DeepMind在
“
量产芯片
”
上的合作非常重要，因为我们可以共同最大化交付的智能或每瓦有效吞吐，我们确切知道模型中发生了什么、硬件中发生了什么，以及两者之间的一切。
我们还能在即将流片的芯片上深度合作。因为我们可以
“
拦截
”
，我们可以在飞行中改变芯片架构
——
如果跨公司边界工作，这介于困难和不可能之间。
不是不可能，但会难得多。我们很难在距离芯片完工只剩几周或几个月时，再把大家拉到同一个房间里肩并肩地讨论是否要打乱项目。这虽然可能，但太难了。
当然，对于设计阶段的芯片，我们可以一起评估许多架构。我们可以问
DeepMind的同事：
“
你们认为模型架构在两三年内会走向哪里？
”
这是我们能做的事情范围，也是模型架构的发展方向。我们拥有深厚且重要的仿真基础设施，可以预测工作负载将如何映射到不同的硬件架构，从而实现快速迭代。团队并不是分开工作的，很多时候我们在同一栋楼、同一个房间，保持着深度的日常互动。我每周都会与
Cororey
或
Demis
交谈多次。所以，这确实是工作中非常有趣的一面。
Sonya Huang：
太棒了。最终他们的模型会帮助芯片设计。
Amin Vahdat：
我们正在使用
Gemini为未来的
Gemini
设计硬件。这真的很酷。
Sonya Huang：
我想稍
后回到这个话题。合作本身
——
我想周期时间可能比
DeepMind
的人在软件侧处理的要慢，你们的规划周期肯定要提前得多。那么你们实际上有多少调整空间？
Amin Vahdat：
这是个很好的问题。我们提前两年、三年、四年、五年规划硬件，毫无疑问。换句话说，我们刚才谈到了我们宣布的
TPU 8，但你可以想象
9
、
10
以及其他一些处于概念执行阶段。它们可能还有几年。如果你们做模型架构，默认你不会想几年后的事。但我认为这也是公司共同成长的好处
——Google Research
、
DeepMind
、
Transformer
的发明，所有这些都发生在这些重叠的房间里。
所以有一代研究人员已经习惯了能够影响硬件，知道硬件按多年周期运作。他们也足够了解，如果有一个小调整能为即将流片的芯片带来
1%或
0.5%
的收益，他们可能不会来找我们，因为他们知道这不像软件，你提交一个变更列表两周后就能上生产。停止流片是件大事。但他们也知道，如果有一个真正好的大机会，我们绝对会一起努力看看能否纳入。
所以正如我所说，收益是乘法性的。硬件确实提升所有
tides。
DeepMind团队的很大一部分
——
我们非常感激，了不起的团队
——
很大一部分在思考如何影响路线图，因为这实际上是一个管道。我两年前的想法现在已经投产，正在帮助
Google
所有工作负载跑得更快。那种感觉很好。
Sonya Huang：
完全同意。但预测五年后什么工作负载最常见、什么算法突破会发生，似乎是不可能的任务。
Amin Vahdat：
听起来像不可能的任务。我听到你说这看起来像不可能的任务，但这里有一件很棒的事
——
实际上我们正在非常详细地写这个，做起来很有趣。
令人惊讶的是，
TPU架构在中等细节层面
——
不是超高层面的细节，而是中等层面
——
自
TPU v1
以来并没有真正改变。
就像看
CPU的指令集架构：有加载、有存储、有加法、有减法、有分支。然而在其之上的软件在这段时间里做了什么？
TPU
也是一样。我们有一些基本指令和基本原语。当然我们扩展了它，指令集并非完全没有变化，但原语
——
专门化的数值超大型矩阵乘法单元、管理向量操作和散射
-
聚集（
scatter-gather
）操作的稀疏核心等等。有五六样东西真正定义它
——
加载、远程加载存储，这是另一个，我们可以通过
ICI
网络读写远程内存。
基本面一直在那里，它们已经扩展到许多代模型、许多代甚至深度神经网络算法和模型结构。
CPU、存储与网络需求同步飙升
Sonya Huang：
说到工作负载的转变，
过去一年左右最大的变化之一
——
长时程智能体（
long-horizon agents
）改变了数据中心的形态
——
我认为真正从今年年初开始，是长时程智能体的崛起。我猜那是与过去快速轮次的
LLM
对话非常不同的工作负载形态。这对数据中心需求意味着什么？
Amin Vahdat：
我认为有两个巨大的方面。
第一，不再是人类与加速器交互。
换句话说，当你在网页浏览器或手机上输入提示时，当然响应你的提示会发生大量工作，但当响应回来时，你得阅读、思考，然后可能有后续
——
那是数秒的交互时间。现在在长时程智能体中，没有人类在循环中自然限制请求发往模型的速度。所以交互时间从数秒、可能数十秒，现在可能变成毫秒
——
我一得到响应就可以解析、推理一下，然后弄清楚下一个请求是什么。这是大变化一。
二是所有那些推理和解析可能发生在CPU上。那个CPU然后可能要考虑，在我向下一个模型提示之前，我需要收集什么其他状态？
换句话说，我从这个响应中学到了东西，我要采取下一步，但我实际上需要去获取一些上下文
——
可能来自本地的
DRAM
，可能来自另一个
CPU
上的别人的
DRAM
，可能在
SSD
上，或者在某处的
HDD
上。所以现在必须进行大量的编排（
orchestration
）。所以设计实际上正在显著变化：对加速计算的需求在上升，但对
CPU
、网络和存储
——
传统数据中心
CPU
等
——
的需求也在飙升。
Sonya Huang：
那是否意味
着你在
GPU机架旁边放更多
CPU
？
Amin Vahdat：
这是关键问题，回到优化和专业化的问题。如果我们开始把大量
CPU机架放在
GPU
和
TPU
旁边，那意味着我们实际上不能完全专业化到
TPU
机架相对于
CPU
机架的密度和网络需求。
TPU
机架会比
CPU
机架更密集，可能需要比
CPU
机架更多的网络。所以现在我们的建筑设计要改变。
另一个选择是保持统一性。把你的
TPU或
GPU
都放在一个建筑里，
CPU
放在隔壁建筑，也许硬盘得放在另一边另一个建筑里，因为它们有另一套需求。
现在你需要建筑之间相当显著级别的网络。一旦你离开一个建筑，网络复杂性从可靠性角度、成本角度显著上升，延迟可能上升
——
可能可以接受，但仍然可能达到数百微秒，组件之间排队可能更多。所以考虑因素以非常有趣的方式变化。
Sonya Huang：
你的工作很难，也很有趣。
Amin Vahdat：
很有趣。
光路交换如何在毫秒内把故障机架换掉
Sonya Huang：
网络
方面发生了什么
——
光路交换（
optical circuit switching
）和网络现状
——
我听说
Google
一直处于最新网络技术的前沿，包括光学。你能谈谈光网络的现状吗？
Amin Vahdat：
我们在
Google大约
15
、
16
年前是最早引入所谓波分复用（
WDM
）的，可以在数据中心内单根光纤上放多个信号，我们实际上将其用于所有机架间通信。
同时，我们引入了一项与波分复用配套的技术，叫做光路交换（
optical circuit switching）。
与传统的电分组交换相比，光路交换完全在光域传输和移动数据。让我描述一下底层技术。在分组交换机中，你拿一个有报头的分组，在电域查看，根据报头弄清楚分组要去哪里。它可能有
IP地址说去哪里，你查表，对于那个目的地，查表看从哪些端口转发。基本上每秒数十亿、数千亿甚至数万亿个分组以超高速通过，你转发它们。光路交换说我不在电域碰这些比特。我要做的是为输入端口弄清楚把光送到哪个输出端口。有多种做法，我们最初用的是
MEMS
开关
——
微电子机械，基本上控制
3D
中的镜子。我们可以以编程方式拿一个盒子，可能有
128
端口、
256
端口之类的，配置每个输入端口映射到输出端口，然后改变镜子的旋转，光
literally
照在这些镜子上，反射到正确的输出端口。
最初我们做这个有两个原因：
一是在机架组之间创建局部性。
假设我有一个计算集群和一个存储集群，都支持搜索。我们知道这两个集群会大量通信，所以配置镜子在纯光域为这两个机架集群之间创建捷径。
二是我们想扩展和收缩网络而不实际移动任何光纤。
光路交换机允许你重新配置网络骨干来扩展或收缩，不需要人工做任何事情，只需要一个控制器管理。快进到
TPU。
TPU
有
Torus
拓扑，直接连接所有
TPU
。我之前谈了吞吐量和有效吞吐。
我们可以做的一件事是，如果一个
TPU机架故障，我们可以用另一个
TPU
机架替换而不移动任何光纤。本质上我们始终有一个备用机架，当机架故障时，我们把光重定向到新机架，这可以在毫秒内完成。
Sonya Huang：那为什么还要光纤而不是完全自由空间？
Amin Vahdat：
很好的问题。衰减损耗和带宽会急剧下降。此外，在一个非常大的建筑范围内，没有光纤连接一切的情况下在
3D中瞄准一切，会很有挑战甚至可能不可能。我们谈过这个，有过一些非常有趣的讨论。
但主要是光纤，当它们到达光路交换机时，光
literally 照在这些小芯片上。这是网络的一大方向。网络在能力和需求方面都在爆炸式增长，坦白说在数据中心。
Sonya Huang：
太酷了。我们可以就这个谈一整集。
Amin Vahdat：
是的，非常非常酷。
Sonya Huang：
回到
Ineffable的照片，那些线缆让所有人眼前一亮。
Amin Vahdat：
正是。那些线缆最终有些会接到我们数据中心的关路交换机。
电力是一个长期的约束问题
Sonya Huang：有道理。好，我想转到电力。你一直在谈每瓦有效吞吐和其他单位——电力是约束：公用事业、吉瓦和数据中心规模——每瓦。让我觉得每瓦意味着电力是某种约束、稀缺或昂贵的东西。我经常被问到我们面临的最大约束是什么。现实是没有单一的最大约束。它们都是约束，都非常难。而且它们不断变化。但如果我必须从根本上回答，我会说电力是我们面临的最根本的单一约束。其他一切似乎我们都知道如何解决，只是需要时间。电力——我认为你表述得很好。这是一个长期的约束问题，我们还没有——核能，也许核能会带来丰富的清洁能源，解决很多问题，当它大规模实现时，仍然未知。那么在实践中如何运作？你建一个新数据中心，需要1吉瓦电力。我想你不能 just 打电话给PG&E说，请送1吉瓦电力。那么电力供应实际上是什么样的？你是否必须一直垂直整合到自己做涡轮机？你如何解决电力瓶颈？
Amin Vahdat：
这是一个大问题、重要的问题。我们在
Google的首选模式始终是接入公用事业电网。所以相当于打电话给你最喜欢的公用事业公司
——
数据中心所在地的
——
当然要提前很多年通知。如果是吉瓦级，不是你说
“
嘿，我明天需要
1
吉瓦，你什么时候开始计费
”
的事。这是我们共同规划的事情。对我们来说，我们非常认真地确保与这些公用事业公司合作时，建设基础设施的成本
——
我们可以就这个话题长谈
——
我们承担这些成本，因为根据计费方式，实际上可能因为公用事业公司为我们建设容量，其他人的费率理论上可能上升。
我们确保的是，需要建设或升级的输电线路、额外的公用事业变电站等，我们也为此付费。所以这是一个长期规划过程。
完全可能出现这种情况：我们
2028年需要
1
吉瓦，公用事业公司
2029
年能给我们
1
吉瓦，但
2028
年能给我们
700
兆瓦。那么我们就面临如何覆盖那
300
兆瓦的问题，其中一个答案是这样。另一个答案是，我们自己发电一部分，也许用太阳能电池或电池作为备份等，或者其他来源。然后我们再与公用事业公司合作。
所以也可能是组合：我们保持一些本地发电，即使公用事业公司完全上线到
1吉瓦规模，我们也能在需要时向电网供电。
换句话说，一年中可能有两周
——
最热的两周
——
住宅需求巨大。如果我们有本地发电，我们可以向电网供电。所以这确实是多年来与公用事业公司合作。
Sonya Huang：为什么你偏好这样做，而不是垂直整合自己？
Amin Vahdat：主要原因是灵活性和双方的提升。一种看待方式是统计复用（statistical multiplexing）或大数定律。
如果我们需要
1吉瓦电力，想要
99.99%
以上的可靠性，可能意味着我们必须建设
2
吉瓦电力。在
99.99
或
99.999%
级别，你需要
1+1
冗余，那很昂贵。然后确保理想上是清洁能源、最好就在数据中心旁边，也可能有挑战。如果我们与数据中心合作
——
也许我们自己能带来一部分，在电网需要少时给他们，我们可以取他们的电。通过在一个更大的基础上利用统计复用，实际上每个人都赢：我们赢、电网赢、住宅赢。我们偏好这个。在极少数情况下，我们会在表后（
behind the meter
）做，但即使那样，我们也假设一年后要接入电网。所以这对我们是提升，对电网也是提升。
Sonya Huang：有道理。你如何决定数据中心建多大？
Amin Vahdat：
这是一门艺术，也是重大辩论的来源。
10、
15
年前
Google
有过大辩论：我们是否应该把所有东西放在一个数据中心？当时
1
吉瓦
——
更简单的时代。不同时代，
10
、
15
年前，我们要建
1
吉瓦数据中心。一个明显的担忧是单点故障，从
30
年角度看是巨大担忧。另一方面，今天的训练工作负载越大越好
——
从网络角度，你希望东西集中在尽可能小的距离内。但又有两个问题：单点故障，以及电力可用性。
1
吉瓦在
10
、
15
年前很大但可想象，但世界上任何地方都不可能把
Google
的总需求建在一个地方，不可能。那么最优规模是什么？我们有模型、模拟器等。但这也取决于
——
有些地方我们在网络边缘，或在某个国家可能几十兆瓦。我们实际上与
ISP
合作，可能
literally
在伊拉克。这可能是训练集群。好吧，那可能接近
1
吉瓦。其他站点可能数百兆瓦等等。
Sonya Huang：
有趣。我想了解你如何看待组合生命周期
——
训练
vs
服务集群、七年老的
TPU
和开放标准
——
管理。我猜最大最新的集群用于训练最新前沿模型，然后回收旧东西跑推理。这个框
架公平吗？你们也建推理专用集群吗？这一切如何运作？
Amin Vahdat：
你思考的框架非常合理，我觉得很有道理。
但我要说推理需求如此之大，我们不能只依赖不再完全用于训练的旧训练集群作为推理基础。
而且如果你想想，我们可能在某一年将训练集群集中到少数大型站点，保持它们之间的网络距离小有好处。无论它们在世界哪里，可能在同一大陆甚至同一大陆的同一部分。那么你可能在其他大陆没有足够的服务容量。所以实际上我们必须在世界其他地方建设专用的推理集群。所以你的直觉很对，但不完全。确实必须是：这是训练集群，是的，可能几年后用于服务。但我们也必须建设服务集群。
Sonya Huang：你的服务集群与训练集群不同吗？更小吗？每兆瓦更便宜吗？
Amin Vahdat：
不一定更便宜，因为服务更需要共置计算、网络和存储，这就导致无法专业化。训练你实际上有高密度统一部署等；服务你必须混合存储、计算和加速器。
此外，服务有一个非常有趣的方面
——
你实际上不想在一个地方放太多。你想从全球各地服务你的工作负载，但现在我们有单个模型端点，可能是模型的变体。
我们必须把这些模型分散到世界各地，同时考虑局部性。所以它们会更小，在推理侧可能垂直整合程度更低。
Sonya Huang：非常有趣。如果你五年前建了一个数据中心，五年前最先进的加速器与今天制造的相比效率低得多。你会回去换那些旧数据中心的芯片吗？我知道这与一个持续辩论有关：芯片的实际使用寿命是多少？
Amin Vahdat：
我公开说过这个，我惊讶于它引起了很多关注。我说我们七八年老的
TPU仍然
100%
利用率。我不是故意要让它成为有意义的声明，但显然它是有意义的。我们较老的
TPU——GPU
也是，但较老的
TPU——
看到显著利用率。我们最终会替换它们。折旧寿命大约
6
年，一旦完全折旧，考虑到新代的能效等，替换和升级是有意义的。不是我们换芯片，而是换系统。我们以
pod
为单位思考。一个
TPU 8 pod
可能是
9600
颗芯片，
140
多、
152
个机架等。我们会说，我们要拉出那个
pod
，替换成
TPU 12
或
13
或
14 pod
。新
pod
的
footprint
可能不完全适合旧
pod
的空位，我们得考虑，弄清楚如何改造。
我们无法提前规划，因为我们不知道那么多代
TPU会是什么样。所以这又是一门艺术，实际上是艰苦的工作，弄清楚如何尽快退役并替换新
TPU
。
Sonya Huang：你公开写过开放标准。能谈谈吗？
Amin Vahdat：
我们谈过互操作性问题。
对我们来说，虽然我们支持垂直整合，让你提取尽可能多的性能，但非常重要的是不强制锁定，不强制端到端系统的围墙花园。
举个例子，
Google开发了一个模型开发框架叫
JAX
，我们很喜欢，认为非常好，内部广泛使用。很多客户喜欢
PyTorch
。我们可以说，如果你想在
TPU
上运行，必须用
JAX——
我有点开玩笑，但也许是真的也许不是，我们认为它最好，唯一选择因为它太棒了。或者我们可以说，如果你喜欢
JAX
，我们喜欢
JAX
，你可以用；但如果你喜欢
PyTorch
，我们有
torch TPU
，你未修改的模型可以运行。
我们在历史上见过很多例子。我用
IP的例子
——
为什么互联网协议赢了？实际上
70
年代和
80
年代初有很多竞争协议。
IP为什么赢？因为它是开放标准，是沙漏的窄腰，任何软件可以在上面运行，任何硬件可以在下面运行。开放标准、可互操作，任何带
IP
的人可以插入路由器端口成为互联网的一部分。
很美，这就是互联网爆炸式增长和全球覆盖的原因。我们真的相信开放标准的插入点。如果你想插入高度专业化的东西，可以；如果你认为你有更好的东西插入我们的框架，绝对可以。但我们想真正支持开放标准，理想上是开源的。这个建设太大太重要，不能是任何一家供应商的封闭专有栈。
Sonya Huang：
是的，我们真的相信这一点，必须是选择之一，这也是为什么我们完全支持并有
TPU、
GPU
、其他加速器等等。
Amin Vahdat：
是的。
图片来源：Sequoia Capital
AI如何重塑团队日常？
Sonya Huang：
你的团队日常
工作因
AI如何改变？在哪个环节改变最大？
Amin Vahdat：
最简单的答案是在软件工程侧，外部已经有很多记录。我们在
Google和我的团队在软件开发能力方面大量使用，实际上测试推广甚至帮助设计等。但在硬件侧
——
外部覆盖可能较少
——
也有显著变化。我的硬件工程师
——
我今天刚看了数字
——
在使用
AI
，用
token
数来说，不是最好的指标但仍是指标。我们的硬件工程师使用
AI
和软件工程师一样多。生产力提高了。从设计启动到流片的时间在缩短，
bring-up
时间在缩短。生产力显著提高。但也许不太预期的变化是数据中心设计方式显著改变。
过去评估建
1吉瓦建筑还是
100
兆瓦园区或
200
兆瓦园区，是非常详细、电子表格驱动、人工驱动的过程，某种程度上仍然如此，但现在有很多
AI
参与，真正简化了规划和开发过程。
Sonya Huang：有趣。是推理模型吗？
Amin Vahdat：
我不会说完全是推理模型。
它不是取代人类判断，而是让把必要信息集中在一起容易得多，基本上把正确信息放在做决策的人类面前。
Sonya Huang：
好，我要带
我们进入
——
轨道数据中心和
2036
年的超级计算机
——
两个有点天马行空的趣味问题。第一个，轨道数据中心。我看到
Google
在认真考虑这个，你想让我评论。人们认真计算轨道计算是否意味着地球上有严重的约束？你怎么看轨道数据中心？
Amin Vahdat：
这是一个令人兴奋的方向。我们实际上在推进，我们半开玩笑地称之为
“
登月计划
”
（
moonshot
），是我们兴奋投资的大努力之一。回到对话前面你正确提出的根本约束
——
能源和能源生产是关键挑战。
从根本上说，在太空，由于大气层没有衰减等，可用电力多大约
40%——1.4倍。这是第一部分。但在太阳同步轨道，太阳能电池的阳光覆盖率为
98%
到
100%
，而地面是
28%
、
30%
可能
35%
。
所以巨大的电力，太阳，你取
1.4倍，再取每天小时数的
3
到
4
倍，基本上移除电池，现在你有潜力做真正
——
当然无碳，很多好处，很多挑战。
现在冷却呢？天真地你可能认为太空冷却更容易，实际上更难。可靠性
——
我们谈过这些东西有时会故障，维修变得更难，不是不可能但在太空更难。机器人配合集群
——
也许这个模式是有希望的方向。冗余可能是你的朋友。你之前关于自由空间光学的问题现在会成为现实。我们可能不会在这些组件之间拉光纤，而是自由空间，激光指向接收器并实时校准。这里没有根本障碍。
Sonya Huang：
最后一个问题。我整
个时间脑子里都有
Ineffable大型超级计算机的画面。问题是：
10
年后，最前沿的超级计算机会是什么样？
Amin Vahdat：10
年正好在那个边缘
——
真诚地说，可能有些人在思考
2036
年的计算机会是什么样。我们可能有少数人想那么远，但哇，那里的不确定性锥太宽了。如果你看趋势，集成度将巨大。我们看到了为
Ineffable
组装的漂亮光纤和
Vera Rubin 200
机架。
我猜会更集成，更少光纤
——
我不会说
2036
年没有光纤，但从机架角度看，机架会看起来更加紧密集成，从机架出来的可能是小光纤束。从模块化制造角度，这些机架
2036
年可能集中制造。
无论它们有
72、
144
、
288
或可能更多
——576
，选你喜欢的
GPU
倍数，
Ineffable
案例是
GPU
，
TPU
也一样
——
深度集成到机架中。一个机架会是数兆瓦吗？我们不确定，但
2036
年我们可以想象单个机架可能数兆瓦。然后你带来水、带来电、插入光纤，把机架推入，插上这三样东西，就开跑了。
Sonya Huang：所以2036年不会像太空中的大外星球体？
Amin Vahdat：
我不会说
2036年不可能直接发射到太空，然后可能被空间站的机械臂抓取并插入正确模块。也许
2036
年是这样。想想很有趣。
Sonya Huang：
我真的很享受这次对话。
这是历史上最激烈、最大的资本支出建设，但我也认为这是一场技术革命，是一件美好的事情。你对技术的美、约束以及如何平衡这一切有如此深刻的把握。
Google在好手中。感谢你抽时间分享你们在做的事情。
Amin Vahdat：
非常有趣。我们得以亲历这一切，我们得以定义它。非常感谢。这是一次很棒的对话。谢谢。
Sonya Huang：
谢谢。
原视频：Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI
https://www.youtube.com/watch?v=bGph8GwB3Sk
编译：Ruby Gao
本文由本站编辑组整理与排版，内容基于公开信息核实后归纳发布，与文中提及的产品、公司无隶属关系。我们持续跟踪 AI 领域的模型、产品与行业动态，力求信息准确、表述清晰；文中涉及的名称、价格与功能细节可能随官方调整而变化，请以官方最新说明为准。如发现疏漏或表述有误，欢迎通过站内渠道反馈指正。
