Google AI基础设施负责人Amin Vahdat谈TPU协同设计与goodput
点播放，字幕跟着声音走
Subtitles follow the audio
逐句文字稿
点任意一句，从那里开始听
正在加载字幕…
-
在硬件这块，你也知道，机会就在于你对某个特定工作负载越专门化，它的灵活性就越低，但速度会更快，能效也会更高。
-
所以这就是一门艺术，也是对你到底在为谁设计、那个工作负载能持续多久的一种预判。
-
换句话说，如果它一两个月、三个月之后就没了，那即便这三个月里规模很大，你用来切入的窗口也非常窄。
-
所以它得有一定的持久性。
-
而且你得能准确预判，专门为它优化能换来什么。
-
非常高兴欢迎Amin Vahdat来到节目。
-
Amin，感谢你今天来参加我们的节目。
-
能来这里真的很激动，我非常期待。
-
我对今天的话题特别兴奋，因为我们正处在人类历史上最大规模的资本支出建设之中，而你就身处其中。
-
光是谷歌今年预计的资本支出就超过2000亿美元，其中大部分都投向了数据中心的建设，而你就处在这一切的中心。
-
你在去年年底被任命为谷歌AI基础设施的负责人。
-
所以你正是这场人类历史上资本最密集的建设浪潮之一的领军人物。
-
所以我非常期待今天跟你深入聊聊。
-
今年确实是至关重要的一年。
-
当然，放眼整个行业，包括谷歌在内，说实话我觉得我们从未见过这样的场面，在谷歌肯定没有，但就像你说的，从建设规模和变革速度来看，我觉得在人类历史上都是难以置信的。
-
在进入正题之前，也许先给听众来个速成课。
-
什么是AI数据中心，它和非AI数据中心有什么不同？
-
这是个很好的问题，因为AI数据中心和非AI数据中心其实有很多相似之处，并不是截然不同。
-
我的意思是，它由混凝土构成，对吧，一个外壳。
-
它由电力场区、机械场区、冷却系统组成。
-
你有一排又一排的电力在分配。
-
那里有大量的网络基础设施。
-
换句话说，我们把大量的计算资源互相连接起来。
-
还有相当多的存储基础设施也放在里面。
-
我觉得我们在AI基础设施上看到的巨大区别就是专业化。
-
过去，我们建数据中心的时候，它其实是一项20年、25年、30年的建筑投资。
-
我们会考虑它在20年、25年、30年这段时间里会怎么演变。
-
你可能会往里放服务器。
-
你可能会放网络和存储。
-
你可能会放一些加速器，GPU、TPU，不管是什么，都可能放进去。
-
但这是一个25年、30年的规划周期。
-
所以我们有——而硬件的寿命可能只有六年。
-
所以要规划好多代。
-
而AI数据中心往往更多是专门定制的。
-
换句话说，我们常常是把建筑和可能要放进去的硬件一起协同设计。
-
我们可能会说，你知道吗，其实我们不会往这栋楼里放很多存储。为什么？
-
因为一个存储机架可能有10、20、30、40千瓦的电力。
-
你把它放在一个TP机架或GP机架旁边，那今天轻松就能达到几百千瓦，未来几年人们还在讨论可能达到兆瓦级——设计一栋楼，可能一排能放30个存储机架，而同一排只能放一两个
-
AI机架，那是非常非常不同的设计。你就从尺寸上想想，从电力上想想，以及它怎么分布到整栋楼里，等等。网络也是一样，存储机架需要的网络，很小，尤其是如果里面是硬盘的话，
-
跟AI机架比起来。
-
所以如果你想让它在各方面都能通用，你很可能就会把它做得太大、过度建设，通用性在30年的周期里肯定是要考虑的。
-
而AI数据中心很可能要专用得多，跟硬件协同设计，甚至连冷却和配电等等都要一起考虑。
-
所以协同优化要多得多。
-
你们给我们的一个被投公司Ineffable Intelligence交付了一个大型的vera-rubin集群，我看到了它运出去时的照片。
-
那真是个美的东西。确实是，确实是。
-
我的意思是，这就有点像，你知道，类似于看人类历史上最大的那些建筑工程，你看那个数据中心，就会觉得，哇，那是人类能力的一座丰碑。
-
不，我们拍到了一张很漂亮的照片，而这还只是，你知道，几个机架而已。
-
你知道，它的布线、光纤分布真的很美。
-
我的意思是，美不美因人而异，但对于像我这样的人，可能还有你自己，以及观众里的其他人来说，它确实是个美的东西。
-
我们把这照片发到社交媒体上，大家很喜欢Ineffable，但他们是他们所做的事情的超级粉丝。很棒的团队。
-
那引起了很多关注。
-
好吧，对Ineffable来说是个很棒的机架，但实际上人们就是喜欢看那些照片，那些光纤，还有光纤那种分形的美感。
-
实际上我们发过的最受欢迎的一条帖子之一就是关于那个的。所以是的，绝对是这样。
-
我们真的很兴奋。是的。
-
我看到那张照片时起了鸡皮疙瘩。
-
在这场大规模建设当中，你们怎么衡量自己、怎么对自己问责？
-
我们在节目开始前聊到，flops是个虚荣指标，你更喜欢另一个指标。你能多说说吗？好的。
-
所以我觉得有一点要注意，不管是flops还是你随便挑的别的以芯片为中心的指标，这些理论上都是。
-
换句话说，在某些条件下，不管你手里是什么芯片，这是你能交付的最大flops量。
-
我们最终真正关心的是，工作负载实际交付的性能是多少？
-
这就是我们在看的。
-
所以最终，很少，确实会发生，但实际上相对很少，性能是由单个芯片决定的。
-
是flops，是HBM，是SRAM容量，等等。
-
这些都非常重要，但可能是两个、四个、八个、16个、一千个、一万个这样的芯片组合在一起，不只是加速器，再说一遍，不管是TPU还是GPU，还有可能给它们喂数据的CPU，把它们全部连接在一起的网络。
-
所以你跑的工作负载是什么，那个工作负载的性能是什么？
-
一个有意思的衡量指标是你的flops利用率是多少？
-
比如说，对某个特定的工作负载，如果你理论上有一个teraflop或petaflop的能力来跑你的工作负载，你能交付其中的多大比例？
-
现在，这是一个goodput的衡量。什么是goodput？
-
你可以想想吞吐量，这是个众所周知的术语。
-
那是可能的吞吐量。
-
但现在让我们考虑一些其他的因素。
-
一个是工作负载的减速是多少？
-
再说一遍，这只是工作负载本身固有的，但还有其他方面，真正影响到我们的可靠性。
-
所以就我们如何对自己问责而言，如果我们有一个芯片对同步工作负载失效了，而很多这些工作负载，不管是训练还是服务还是智能体工作负载，它们都是同步的。
-
有很多很多组件在同时协同工作。
-
现在，如果你有，比如说1000个、10000个、100000个这样的组件在同时协同工作，而它们真的需要在微秒或毫秒的粒度上协调，如果其中一个失效了，它可能实际上会让整个事情停下来。
-
因为每个人都指望其他人来完成那部分工作，才能得出一个非常难的问题的答案。
-
其中一个停了，好，现在我们必须弄清楚发生了什么，是哪一个停了，我们在之前某个时间点对这个计算有什么检查点，我们怎么恢复那个检查点，我们怎么重启？
-
最坏的情况，我们得从头重启。
-
那会非常糟糕，但在某些情况下这确实会发生，尤其是在推理这一侧。
-
这里的重点是，如果你现在必须回头重做一堆计算，如果你必须暂停下来、等着弄清楚到底出了什么故障，那所有这些工作都是工作量。
-
它实际上并没有帮你得到答案，对吧？
-
就好比说，你在纸上解一道题。
-
第一步，第二步，第三步，第四步。
-
如果你因为犯了个错误，不得不回到第一步，是的，你仍然在做工作，那是吞吐量。
-
你在做工作，但在给出你的答案这件事上，有效产出是什么？
-
基本上就是你解决这个问题所花的总时间。这才是真正重要的。
-
而如果你遇到故障，如果你要做故障恢复，如果有任何东西在打断你的工作，那都是问题的一部分。
-
所以现在，我们怎么让自己负起责任来？
-
看的是它实际交付的有效产出，不是理论上的基准测试、吞吐量，或者理论上的好，而是针对一个真实的工作负载、在真实的故障条件下，实际发生了什么。
-
而很不幸的现实是，在十万个加速器的规模下。
-
我正想说，在那个规模下，总有东西在出故障，对吧？一直在出。
-
而且这些，每一个，你也知道，这些芯片每一个都是大自然的奇迹。
-
我是说，它们处在人类能制造出来的极限的最前沿，对吧？
-
所以再说一次，对我来说，这太惊人了。
-
而且实际上现在这些芯片不只是一块芯片，它们是由多个芯粒组成的封装，很多时候是两个、四个、八个，甚至更多，对吧？它们组合在一起。
-
然后当然，旁边还有HBM、网络连接，也许还有共封装光学之类的东西，不是说它们不好，很多东西都可能出故障。
-
而现在如果你有十万个这样的东西，总会有东西出故障。
-
你必须为此做好准备，近乎实时地检测到它，近乎实时地从故障中恢复。
-
做这一切，真的就像是，遥测问题是个巨大的问题。
-
这就像大海捞针一样，而且是在几秒、几分钟内持续不断地找，但对某些任务来说，是几小时、几天甚至几周，就是持续在线地找。
-
我们怎么对自己问责，就是看我们为数据中心里真正重要的那些工作负载交付了多少有效产出。
-
这是谷歌的术语，还是行业术语？
-
这是谷歌的术语，但我觉得行业里越来越多的人开始接受这个说法了。
-
然后帮我校准一下，十万个加速器的规模，是说每分钟会出一次故障，还是每天一次？
-
十万个加速器。让我想想。
-
我觉得肯定是一天好几次的规模。
-
而且根据具体配置不同，可能是一小时好几次，总会有东西出故障。
-
那最常见的故障原因是什么？这就是问题所在。其实这是个很好的问题。
-
如果有一个常见的故障原因，我们早就把它搞清楚并修好了。
-
这是一条不断发现的长尾。
-
每当我们推出一个新产品，总会有东西给我们来个措手不及。
-
说实话，很多情况下，还是因为这是最前沿的东西，可能跟网络有关。
-
可能是我们怎么把这些东西以超高速度连接在一起的问题。
-
也可能是跟硬件有关的问题。
-
这些东西我们都能解决。
-
但很多问题可能是软件方面的。
-
所以这就是我们对自己问责的另一个方面。
-
再说一次，芯片可能具备一定水平的FLOPS。
-
但如果你有编译器bug、运行时bug、模型问题，或者别的什么，操作系统问题，那都无所谓，这些都会影响整个系统的性能。
-
所以你可能硬件完美、完全可靠，但软件问题还是可能拖你后腿。
-
加速器厂商，比如NVIDIA或者TPU团队，有没有一个标准参考栈，说这就是围绕我们加速器构建的最优系统，只要你照着这个系统来搭就没问题？
-
或者说，在半导体公司给你的东西之上，你自己的数据中心设计还得做多少？对。
-
所以是有一个参考栈的。
-
而且我想说，NVIDIA是一家非常了不起的全系统公司。
-
我的意思是，他们显然是半导体公司，但他们不只是半导体公司。
-
他们给你的参考栈真的非常非常强。
-
但我想说，我们发现，怎么说呢，我们大多数客户都会用那个参考栈，但也有很多人会做定制化。
-
换句话说，他们可能发现针对自己的特定用例，有优化机会，或者有别的什么需要做的东西，他们就会去做。
-
TPU这边也一样，我们有一个参考栈。
-
但大多数人会直接用那个。
-
不过也有很多人会做定制化。明白了。
-
那我想在整体容量方面，你跟你的团队说过，Google大概每六个月就得把服务容量翻一倍，对吧？
-
嗯，先说清楚，这是从有效可用容量的角度来说的，最终我们看的是从服务角度出发的token生成能力。
-
所以这个容量，我想说它是软件和硬件的结合。
-
硬件可能有一个所谓的固有FLOPS水平。
-
我在这里说的不一定是每六个月就得把FLOPS数量翻一倍，那是一条路。
-
而是你得每六个月把硬件生成token的能力翻一倍。
-
而这其中来自软件的部分，跟来自硬件的部分一样多，甚至更多。
-
换句话说，可能是模型优化带来了这个提升。
-
也可能是某种运行时优化带来的。
-
真正起作用的，很可能是几十上百个单独的优化，一次又一次地落地，才让这一切成为可能。
-
但没错，容量提升的速度确实惊人。
-
我的意思是，我猜我们现在已经有几年数据中心建设的数据了，也有几年模型进步和软件进步的数据了。
-
从经验上看，容量的提升——也许用每瓦智能来衡量——有多少来自芯片本身，多少来自模型，多少来自其他软件，还有多少来自其他大的组成部分？
-
是啊，这是个非常好的问题。
-
我没有精确的拆分数据，但我会说，根据我们的经验，大部分收益来自模型侧的改进，也就是每瓦智能这块。
-
顺便说一句，每瓦智能是个很棒的指标，非常聚焦。
-
对我们来说，我们看的也是每瓦goodput，我们可以回头再聊为什么瓦特必须放在分母上。
-
Goodput完全可以作为每瓦所交付智能的一种衡量。
-
换句话说，goodput是一个跟具体工作负载相关的指标。
-
但我会说，大部分收益往往来自模型这一侧。
-
软件系统，也贡献了不少。为什么？
-
因为它们能真正确保你手上的硬件被有效地利用起来。
-
然后硬件本身，也相当惊人。
-
换句话说，我们现在所处的世界，每年性能提升2倍甚至更多是绝对可能的。
-
所以硬件确实支撑了这一点，而且它可以说是一个免费的乘数——不是真的免费，但上面所有人都能指望它，把它当作一个每年把所有人往上抬的乘数。
-
我很想聊聊TPU项目和协同设计。
-
谷歌十多年前就开始做定制芯片了。
-
这在当时是个反主流的决定。
-
TPU项目是怎么一路演变过来的？变化还挺大的。
-
我是说，这个项目2013年启动的时候，那真的是一个反主流的决定，而且我觉得，现在很难把自己放回到2013年那个时刻，当时的普遍看法是，
-
你知道，所有最聪明、最有见识的人都会说，你不会一上来就为一个单一工作负载去造定制加速器。为什么？因为摩尔定律摆在那儿，性能每18个月还是24个月翻一番，这个红利就在那儿，你可以利用标准编程模型，你所有的C++代码、Java、Python等等，
-
不管是什么，这就是芯片界的“苦涩的教训”。对，没错。
-
芯片界的苦涩教训就是，专用化永远赢不了。但在这个特定的情况下，我们确实有这么一个应用，或者说少数几个应用，能从中获得巨大的收益，而要用通用CPU来支撑它们，需要的量简直难以想象。
-
所以2013年那会儿，这真的就是一场赌博，而且公司内部也有相当一部分人，
-
我得说，他们并不确定这事能不能成。所以这就是一场赌博。
-
结果证明，这是一场极其成功的赌博。
-
第一颗芯片完全是做推理的。
-
第二颗芯片是，嘿，其实我们可以用同样的思路做一颗训练芯片。
-
从那以后，它就被越来越多的使用场景采纳了。
-
大概在第二颗芯片出来的时候，Transformer被发明了。
-
我是说，这是一个非常、非常重大的时刻，它实际上彻底改变了TPU项目的走向。
-
我们当然也发现，推荐系统在TPU上跑得非常非常好。
-
于是广告和相关的使用场景也跟着来了。
-
所以我会说，这种变化和演进，就是范围和影响力的不断扩展。
-
我知道最开始是几个非常有影响力的推理服务应用场景。
-
主要是语言翻译和语音识别，然后扩展到训练，再然后扩展到Transformer、推荐系统，而且随着我猜生成式AI时代的到来，还在继续泛化，走向越来越大、越来越可扩展的系统。
-
你提到Transformer出现的那一刻是个重大时刻。
-
我很好奇想深入了解一下，TPU是某种特定的架构，但它并不是，你知道，专门针对Transformer的。
-
你怎么在一条微妙的界线上拿捏，就是你知道，你希望你的芯片对某个工作负载有多专用？这是个很好的问题。
-
我觉得这归根结底还是取决于适用性。
-
我是说，我觉得是芯片对某个特定工作负载的适用性。
-
换句话说，归根结底，我们每一代都在思考这个问题。我们要不要进一步专用化？
-
我们面临的这个问题，比如说，两年前，稍微多一点，就是到2026年，我们应该做两块芯片还是一块？
-
我们可以做一块芯片，同时既能做推理又能做训练，而且两样都做得相当好。
-
或者我们可以做两块芯片，一块进一步专门针对推理，另一块进一步专门针对训练。
-
这项分析和这项工作促成了今年发布两块芯片，8i用于推理，8T用于训练。
-
而最终我们意识到的是，几年前还不一定是这样，但到26年，我们看到推理和服务真的开始起飞了。
-
所以，拥有一块在服务上明显更快的芯片，而我们预计它在其生命周期内可能占到市场的30%、40%、50%、60%，这对我们来说就开始非常合理了。
-
相对于如果推理，如果我们预测推理只占市场的2%或5%，那么即使那块专用芯片，比如说快2倍，可能也不划算。
-
因为你实际上会去选那块通用芯片，它没有完全优化，但没关系，因为你现在有了统一性等等。
-
所以真的，这归根结底就是一个算计的问题，好吧，你要不要进一步专用化？那个工作负载有多大？
-
那个工作负载预计在两三、四年后会有多大？
-
这对某个特定工作负载来说是不是持续增长？
-
在硬件上，还是像你知道的，存在这样一个机会，就是你越针对某个特定工作负载专用化，它就越不灵活，但硬件就会越快、越省电。
-
所以这就是一门艺术，也是这种预测，你在为什么而设计，以及那个工作负载有多持久？
-
换句话说，如果它一两个月或三个月后就消失了，即使那三个月里它很大，你拦截它的窗口也非常窄。
-
所以，它必须得有一定的持久性。
-
而且你必须能够准确预测，当你为它专用化时，你能得到什么。
-
所以，大致的权衡是，支持一个新程序有一大笔固定成本。是的。
-
而且你基本上得认为，针对那个特定程序的需求会足够大，大到能证明这个成本是合理的。完全正确。
-
而且在某种程度上，比如说我们的8i和8t芯片，这两款芯片都能干另一种工作负载。这一点也很关键。
-
如果8i只能做推理，完全做不了训练，换句话说，它在训练上的性能是零，反过来也一样，如果8t在训练上特别强，但推理性能是零，那也会是一个关键的局限。为什么？
-
因为我们得提前预测，在六年的硬件生命周期里，我们到底需要多少各自的量。
-
在这种情况下就很好，因为两款芯片在各自专精的方向上都更强，但如果你需要的话，如果一边或另一边有富余的产能，两者其实都能干对方的活。
-
取决于你做的专用化程度，你可能会专用化到把自己限制住了，失去了灵活性和可互换性。
-
那如果大致的权衡另一端是Hergram的规模，那在我看来，现代AI市场这么大一部分都是基于transformer的。
-
所以也许就问个有点挑衅性的问题，为什么不干脆把transformer架构烧进芯片里？
-
对，所以我觉得它是基于transformer的，但再往下一层问就是，transformer归根结底是关于向量和矩阵乘法运算的。
-
还有一个softmax，基本上就是一系列线性代数的基本操作。
-
这些我们有，别人也有，大致都固化在硬件里了。
-
全都是基于transformer的，但接下来你的模型架构就是，好吧，你有多少层？你怎么穿过这些层？
-
你怎么在每个维度上跨层？
-
你具体在应用什么形状的矩阵和向量。
-
你可以走得更远，不只专用化到transformer，而是专用化到你的模型。
-
那是下一个层次的专用化。
-
我觉得外面有不少公司正在考虑这件事。
-
我觉得这也是一个非常非常有意思的方向。
-
好，那在现在这个时间点，你们的客户是把TPU和GPU大致看作可互换的等价物，还是有一类特定的问题更适合其中一个？
-
确实有一些问题更适合其中一个，而不是另一个。
-
我的意思是，首先GPU比TPU更通用，这一点很清楚。
-
它们在Google和Google Cloud都是非常出色的产品。
-
我们卖很多GPU。
-
我们内部也在用GPU，但我觉得归根结底还是要看你具体是什么问题。
-
所以我觉得，对我们的客户来说，这两者之间是有重叠的，但客户会去评估自己的工作负载，评估自己的选项。
-
我们在Google喜欢做的是给客户选择权。
-
换句话说，我们想为他们的需求提供正确的解决方案，当然，是给他们提供最符合他们需求的方案。
-
从芯片、网络到软件，支持协同设计的理由是什么？
-
那反对协同设计的理由又是什么？
-
对，协同设计有巨大的优化空间，所以你可以想象，如果你有一个N层的技术栈，而你想随意挑选任何一个组件，比如说你要跨很多云运行，或者跨很多种硬件运行，
-
很多种软件，你可以设计出一些抽象层，基本上就是说我在任何硬件上都能跑，在任何软件上都能跑，在任何网络拓扑上都能跑，你给我多少网络都行，没问题。
-
而且我的系统会完全自适应。
-
很可能就是这样，那你就有了一个很棒的能力，你可以到处迁移。
-
比如有新容量可用了。
-
一夜之间你就跑起来了，因为你的系统就是这么设计的，能够利用任何资源。
-
你完全没有针对任何人的特定基础设施做硬编码或专门化。
-
缺点是，你很可能在性能上损失很多。
-
如果你变得完全可互换，如果你对任何人的硬件、软件、网络、存储、计算等等技术栈都完全灵活适配，
-
那么支持协同设计的理由就是，在每一层之间，如果你想做到完全通用，就会存在很大的阻抗不匹配。
-
所以每一层可能都有10%、20%、2倍的提升空间。
-
你把这些优化机会一层层乘起来，突然之间，你就能在端到端上获得一个巨大的机会，不管你想叫它每瓦智能还是每瓦有效产出，你都能利用起来，甚至一路延伸到供电和电力可用性，
-
软件优化，等等等等。
-
所以，好处是你可以随时随地运行。
-
你没有任何锁定。
-
坏处是，你很可能在性能上损失掉相当大的一部分。
-
所以我的理解是，如果拿OpenAI和Anthropic来说，OpenAI基本上是在一个同构的计算栈上构建的，而Anthropic大致是在一个更加异构的计算栈上构建的。
-
你觉得这是不是部分原因，协同设计是不是部分原因，导致他们最终收敛到了传闻中非常不同的模型架构上？我无法推测。
-
我不想推测OpenAI和Anthropic在做什么。
-
这只是一种可能性。
-
但我认为，在不了解他们具体在做什么细节的情况下，我猜想他们最终走向不同架构可能有很多原因。那谷歌这边呢？
-
我很好奇你们团队和DeepMind之间的工作关系是什么样的，谁在同一个房间里，在模型开发的哪个阶段，你们在协同设计上是怎么一起做决策的？
-
在谷歌最有趣、坦白说也最令人满足的部分之一，就是有机会和DeepMind团队真正肩并肩地合作，共同设计我们的硬件和模型。
-
这里面还有第三个要素。
-
我们还能把这种合作延伸到消费者服务和云上。这个我先放一放，待会儿可以再回来讲。
-
但就DeepMind而言，这确实是一种深度的伙伴关系。
-
让我从过去的例子说起，我可以给你举一些例子，比如他们提出了针对transformer的模型优化，或者他们想做的某些特定数学运算，而我们可能有一颗芯片正在开发中，还没完全做完。
-
然后他们说，天哪，如果我们有硬件支持来做这个，我们的端到端训练或服务可能会快得多、高效得多。
-
那要真正改变我们可能已经在执行中的硬件定义来容纳这个，需要付出什么代价？
-
这就促使我们的工程师和研究人员聚在同一个房间里，密集地讨论几天、一周、两周，然后说，好，是的，我们能做这个。
-
更可能的情况是，我们没法完全做到你想要的，但我们可以做另一件事。
-
然后也许你可以把模型架构往另一个方向调整，这样能达到98%，能满足我们90%的需求。
-
是的，然后我们就可以回头去拦截硬件。
-
或者我们可以说，你知道吗？
-
我们打算把流片推迟一两周，因为哇，为了这种程度的收益，完全值得。
-
同样地，当我们在规划路线图的时候，到了某个时间点，我们在任何时刻基本上都有好几代芯片在推进中。
-
我们有已经在量产中的芯片，这是第一类。
-
我们有正在推进量产的芯片。
-
它们已经从制造商那里回来了，我们正在调试，让它们能正常工作。
-
我们有正在实现阶段的芯片，即将送去流片、交给制造商。
-
我们有处于设计阶段的芯片，然后还有处于概念阶段的芯片。
-
所以这真的是一个五六个阶段、跨越很多很多年的流水线，从量产到还在你脑子里，等等。
-
和DeepMind在量产芯片上的合作非常重要，因为我们可以一起努力，最大化交付的智能和每瓦交付的有效产出。
-
而且我们清楚地知道模型里发生了什么，也清楚地知道硬件里发生了什么，以及中间的一切。
-
我们还能在那些即将流片的芯片上深度协作。为什么呢？
-
因为我们可以拦截，可以修改芯片，真的是在飞行途中修改芯片架构，如果我们跨公司合作的话，这介于困难和不可能之间。
-
不是不可能，但会难得多，对吧？
-
对我们来说，说天哪，我们离这颗芯片完成只有几周或几个月了。
-
现在让我们聚在同一个房间里，肩并肩地搞清楚我们该不该打乱这个计划。
-
这是可能的，但我会说，更难。
-
然后当然，对于那些还在设计中的芯片，我们有很多架构可以一起评估。
-
接着我们可以问DeepMind的同事，你们觉得两三年后模型架构会往哪走？
-
这是我们能做的事情的帕累托前沿。
-
这是模型架构走向的帕累托前沿。
-
我们其实有非常深入且强大的仿真基础设施，可以预测工作负载会怎么映射到不同的硬件架构上。
-
非常深入、非常快速的迭代。
-
真的不是各个团队各干各的。
-
而是在同一栋楼里、很多时候在同一个房间里，每天深度互动。
-
我每周都会跟Cori或者Demis聊好几次，等等。
-
所以这真的是这份工作里特别有意思的一面。太棒了。
-
最终他们的模型也会帮助芯片设计。
-
我们也在用Gemini为未来的Gemini设计硬件。这真的很酷。
-
关于这个合作本身，我想待会儿再回来聊一聊。
-
我猜，是不是还是存在某种不匹配，就是我觉得硬件的周期时间可能就是要比你们DeepMind的人在软件那边打交道的慢一些。
-
而且我猜你们的规划周期要提前得多。那是肯定的。
-
那你们实际上有多大的调整空间呢？是啊，这是个很好的问题。
-
我们是在提前两年、三年、四年、五年规划硬件，毫无疑问。
-
换句话说，我们刚才聊到了我们刚发布的TPU-8i和8t，但你可以想象，9、10，也许还有其他一些，已经在概念执行或者别的什么阶段了。
-
所以它们可能还要好几年才出来。
-
如果你做的是模型架构，默认情况下，你不会去想好几年以后的事。
-
但我觉得这也正是这家公司一起成长起来最棒的地方。
-
换句话说，谷歌的研究、DeepMind，还有Transformer的诞生，所有这些也都是在这些相互重叠的圈子里发生的。
-
所以换句话说，有一整代研究人员已经习惯了能够影响硬件，并且知道硬件是按多年周期来运作的。
-
而且他们也清楚，如果只是一个小小的调整，能给一颗即将流片的芯片带来大概1%、0.5%这样的提升，
-
他们大概不会来找我们，因为他们心里有数，知道这不像软件那样，改一个变更列表，两周后就能上线到生产环境。
-
毕竟叫停一次流片可是件大事。
-
但他们也知道，如果碰上一个大机会，一个真正的好机会，那没错，我们绝对会一起想办法看能不能把它塞进去。
-
所以就像我说的，收益的来源是乘法关系。
-
硬件是能水涨船高、带动一切的，对吧？
-
所以DeepMind团队里有相当一部分人，我们对此非常感激。那是个了不起的团队。
-
但其中相当一部分人想的是，我怎么去影响路线图，因为这实际上是一条流水线。
-
比如我两年前有的一个想法，现在它已经投产了。
-
而且它正在帮助谷歌所有的负载跑得更快。这种感觉真好。完全同意。
-
不过，要预测五年后哪些负载会最普遍、会出现哪些算法上的突破，这看起来像是不可能完成的任务。
-
我倒不觉得这是不可能完成的任务。
-
我理解你会觉得这像是不可能完成的任务，但妙就妙在这里。
-
其实我们正在非常详细地把这些写下来，做这件事特别有意思。
-
令人惊叹的是，TPU架构在中等细节层面上——不是特别高的细节层面，而是中等细节层面——从TPU V1以来其实就没怎么变过。
-
打个比方，就像CPU的指令集架构。
-
你有加载、有存储、有加法、有减法、有分支跳转，可在这段时间里，它上面的软件又做出了什么呢？
-
TPU也是一样，我们有一些基础指令和一些基础原语，当然我们也做了扩展。
-
并不是说指令集完全没变过，但那些原语——在数值特化方面、两个非常非常大的矩阵乘法单元、一个负责向量运算和散射-聚集操作的稀疏核心等等。
-
大概有五六样东西真正定义了一个远程加载存储。其实那也算一个。
-
我们可以通过ICI网络读写远程内存。
-
这些基础一直都在，而且已经延续到了很多代模型、很多代甚至深度神经网络算法和模型结构。好。
-
说到工作负载的转变，过去一年左右最大的变化之一，我觉得真正是从今年年初开始的，就是这个自然年里，长时程智能体的兴起。
-
我猜那是一种和过去几年那种快速往返的大语言模型对话完全不同的工作负载形态。
-
这对数据中心的需求意味着什么？
-
对，我觉得这里面有两个巨大的方面。
-
一个是，它不再是人类跟加速器之间的交互了，不管你怎么称呼它。
-
换句话说，当你在网页浏览器或者手机上敲一个提示词的时候，当然，响应你的提示词会有一大堆计算发生。
-
但等回复回来之后，你得读它。
-
你得琢磨它。
-
然后可能你还会追问一句。
-
那中间就是好几秒的交互时间。
-
而在长时程智能体上，没有人类在回路里，自然也就没有东西去限制请求发给模型的速度。
-
所以这个从几秒、可能几十秒的交互时间，现在变成了也许几毫秒。
-
我一拿到回复，就能解析它，也许还能稍微推理一下，然后就能确定我下一个请求是什么。这是第一个大变化。
-
第二个大变化是，所有这些推理和解析，很可能都会在CPU上发生。
-
然后那个CPU就得考虑，好吧，在我把下一个提示词发回模型之前，我还需要去收集哪些其他状态？
-
换句话说，我从这个回复里学到了一些东西。
-
我要再走一步，但实际上我得去抓一些上下文。
-
也许从我本地的DRAM，也许从另一个CPU上的别人的DRAM，也许从SSD，或者从别处的HDD。
-
所以现在还得进行大量的编排工作。
-
所以设计其实正在发生相当大的变化，对加速器算力的需求在上升，但对CPU、网络和存储，也就是传统数据中心、CPU等等的需求，同时也在暴涨。
-
那你是要在GPU机架旁边放更多CPU了？
-
所以这是GPU、TPU机架。
-
这就是关键问题，回到优化和专用化这个问题上。
-
如果我们开始放很多CPU机架，而且这确实是个问题，放在GPU和TPU旁边，那就意味着我们其实没法完全针对TPU机架相对于CPU机架的密度和网络需求去做专用化。
-
TPU机架会比CPU机架更密集。
-
而CPU机架可能需要更多网络。
-
换句话说，现在我们的建筑设计要变了。
-
另一个选择是保持统一性，把你的TPU或GPU都放在一栋楼里，隔壁那栋楼，但也许把你的CPU放进去，顺便说一下，硬盘可能得放在另一边另一栋楼里，因为它们又有另一套需求。
-
现在你需要这些楼之间相当高水平的网络连接。
-
所以一旦你离开一栋楼，网络复杂性就会大幅上升，从可靠性角度、从成本角度都是如此，延迟大概会上升，但还能接受，不过现在你可能要到几百微秒，各组件之间排队的话可能还更多。
-
所以这些考量确实以相当有意思的方式在变化。你的工作很难。这很好玩。很好玩。是很好玩，对。
-
网络这边发生了什么？我听说谷歌一直处在最新网络技术的最前沿，包括光网络。
-
你能说说光网络现在是什么状况吗？
-
你知道，我们谷歌，这大概是15、16年前，是最早引入所谓波分复用的公司之一，就是可以在数据中心内的一根光纤上放多个信号。
-
我们实际上把它用在了机架之间的所有通信上。
-
同时，我们在引入波分复用的时候，还带来了一项叫光电路交换的技术。
-
光电路交换的本质，跟传统的电分组交换相比，它的做法是完全在光域里传输和搬运数据。
-
这的好处在于，让我先描述一下背后的技术。在分组交换机里，你会拿到一个带报头的分组。
-
你会在电域里看它，弄清楚这个分组要去哪儿。
-
它的报头里可能有个IP地址，说，好，我该把它发到哪儿？
-
你查一下，好，对于那个目的地，你查一张表，我该把它转发到哪个端口？
-
所以基本上，每秒有几十亿、甚至可能上万亿个分组以超高速度涌进来，你就把它们转发出去。
-
光电路交换说的是，我不在电域里碰这些比特。
-
我要做的是，针对一个输入端口，弄清楚该把光送到哪些输出端口。
-
好，现在我有，做这件事有多种方式。
-
我们最开始用的那种叫MEMS。
-
开关，就是微电机，基本上是在三维空间里控制镜片。
-
所以我们现在可以通过编程，拿一个可能让你选，比如28个端口、256个端口的盒子。
-
大概就是这样的数量级，我们可以配置每一个光纤接入的输入端口，把它映射到一个输出端口，然后改变镜片的旋转角度，光 literally 照在这些镜片上，被反射到正确的输出端口。
-
最初，我们做这件事有两个原因，一是为了在机架组之间建立局部性。
-
比如说我有一个计算集群和一个存储集群，它们都是为了，再说一次，为了做搜索。
-
我们知道这两个集群之间会大量通信，所以我们会配置镜片，纯粹用光的方式在这两个集群、机架组之间建立捷径。这是第一个原因。
-
第二个原因是，我们希望能够扩展网络、收缩网络，而不用真的去搬动任何光纤。
-
不深入细节的话，我可以在白板上画出来，光电路交换机让你能够真正重新配置网络的骨干，去扩展或收缩它，不需要任何人做任何事，只需要一个控制器来管理它。
-
现在快进到TPU。
-
TPU有一个环面拓扑结构，把所有TPU直接互相连接起来。
-
我之前讲过吞吐量和有效吞吐量。
-
我们能做的一件事是，如果有一个TPU机架出故障了，我们可以用另一个TPU机架替换它，而不用移动任何光纤。
-
同样，我得比划一下，或者在白板上画出来。
-
但本质上，我们可以说随时都有一个备用机架可用。
-
当一个机架出故障时，我们把光重新导向那个新机架。
-
这可以在毫秒内完成。
-
那你们为什么还要用光纤呢？
-
而不是完全用自由空间。对，这是个很好的问题。
-
衰减损耗和带宽都会大幅下降。
-
而且，在一栋非常大的建筑范围内，没有光纤把所有东西连在一起，要在三维空间里对准所有东西，会很有挑战性，甚至可能根本做不到。
-
我们讨论过这个。
-
我们其实讨论过，而且有过一些非常有意思的讨论。
-
但没错，主要还是靠光纤，不过当它们到达光电路交换机时，本质上光就是直接照在这些微小的芯片上。
-
所以，这是网络的一个大方向。但还有很多。
-
我的意思是，说实话，在网络方面，它的能力和需求在数据中心里都在爆发式增长。所以很酷。看看那整段对话。是的。非常非常酷。
-
甚至就像回到Inethable那张图，全是电缆挡住了所有人的视线。没错。是的。
-
而那些电缆，最终有一些会通到我们数据中心里的光电路交换机。有道理。好的。
-
我想转到谈谈功耗。
-
你一直在讲每瓦有效吞吐量和其他每瓦的单位，这让我觉得每瓦意味着功耗在某种程度上是约束条件，或者说稀缺的约束，或者昂贵的约束，你知道，所以我经常被问到这个问题，
-
我们面临的最大约束是什么，而现实是，并不存在某一个最大的约束。它们全都是约束。
-
它们全都超级难，可能是这样，而且它们还在不断变化，但如果非要我从根本上回答，我会说电力是我们面临的最根本的约束，其他所有东西看起来我们都知道怎么解决，只是个花多长时间解决的问题。
-
电力，对，我觉得你这个说法特别好。
-
这是一个长期存在的硬约束，我们目前还没有一个，我是说，核能，也许核能会带来丰富的清洁能源，那肯定能解决很多问题。
-
但那什么时候能实现，什么时候能规模化实现，还是未知数。
-
那这在实践中是怎么运作的呢？
-
你要建一个新的数据中心。
-
它需要吉瓦级的电力。
-
我想你总不能直接打电话给PG&E说，嘿，请给我送一吉瓦的电过来吧。
-
所以电力供应这件事实际上是什么样的？
-
你们是不是得一路垂直整合，连自己的涡轮机都得自己造？
-
还是说你们怎么解决电力这个瓶颈？
-
对，这又是个大问题，很重要的问题。
-
我们谷歌偏好的模式一直是接入公用事业电网，接入电网。
-
所以这就相当于打电话给你的……
-
哦，所以你不能直接打给PG&E。没错。
-
你非常礼貌地打电话给你中意的公用事业公司，不管你的数据中心在哪儿。
-
当然，你得提前很多很多年通知他们。
-
换句话说，如果谈的是吉瓦级的规模，这不是你能说“嘿，我明天就要一吉瓦，你什么时候开始给我计费”的事。
-
这是我们一起共同规划的事情。
-
对我们来说，这件事我们也非常认真地对待，从确保我们跟这些公用事业公司合作时，铺设这些基础设施的成本——光这个话题我们就能聊很久——我们要承担这些成本，因为按照计费的方式，
-
实际上可能会出现这种情况：公用事业公司为我们扩建产能，结果别人的电价可能就涨上去了。
-
理论上，我们要确保的是，比如说需要新建、升级的输电线路、额外的公用事业变电站等等，这些费用也由我们来出。
-
但所以这是一个很长的规划过程。
-
完全有可能是这样：比如说我们需要一吉瓦，我随便编个日期，2028年，而公用事业公司要到2029年才能给我们一吉瓦。
-
他们能在2028年给我们，比如说，700兆瓦。
-
那现在我们可能就面临一个问题：剩下那300兆瓦怎么办？
-
或者一个答案就是等。
-
另一个答案是，好吧，那我们能不能自己想办法发一部分电？
-
也许是用太阳能电池，或者用电池做备份，等等。会不会用其他来源？
-
然后我们再次跟公用事业公司合作。
-
所以也可能是一种组合：我们自己保留一部分本地发电能力，即使公用事业公司完全上线了，比如说到了吉瓦级，我们实际上还能反过来向电网供电。
-
这样他们需要的时候也能用上。
-
换句话说，一种看待方式就是，一年里可能有那么两周。
-
也许是全年最热的那两周，住宅用电需求巨大。
-
如果我们有本地发电，我们就能把电回馈给电网。
-
所以对我们来说，这真的是要跟公用事业公司合作好多年的事。
-
为什么你更倾向于这样做，而不是说，去跟公用事业公司合作，而不是自己垂直整合？
-
对，主要原因是灵活性，以及双方都能获得提升。
-
一种看待方式就是统计复用，或者你也可以说是大数定律。
-
如果我们需要一吉瓦的电力，假设我们想要达到99.99%以上的可靠性。
-
那可能就意味着我们得建两吉瓦的电力。
-
在那个级别，99.99或者99.999，你就得有一加一的冗余。那成本就上去了。
-
然后还要确保它最好是清洁能源，而且可能就在我们数据中心旁边，这本身也很有挑战。
-
那如果我们跟数据中心合作，同样，也许我们自己能带一部分电过来，在电网不需要那么多电的时候可以送回去，也可以从他们那儿取电。
-
换句话说，通过在一个大得多的基数上利用这种统计复用，其实所有人都赢了。
-
我们赢了，电网赢了，居民也赢了，等等。我们更倾向于这种方式。
-
我的意思是，在极少数极少数情况下，我们也会做，比如说，表后供电。
-
但即便那样，我们也是在假设之后会跟公用事业公司合作的前提下做的，可能是一年之后。
-
我们还是想接入电网。
-
所以还是那句话，这对我们是提升，对电网也是提升。说得通。
-
你们是怎么决定一个数据中心要建多大的？
-
对，这既是门艺术，也是引发重大争论的一个源头。
-
你知道，在某个时候，我记得甚至十多年前、十五年前，谷歌内部有过一场大辩论，我们是不是干脆把所有东西都放进一个数据中心？
-
那时候大概是一吉瓦，那会儿—— simpler times。那时候简单多了。
-
对，不同的时代，大概十到十五年前，我们打算建一个一吉瓦的数据中心。
-
所以那里一个明显的担忧就是单点故障，对吧？
-
如果你从三十年的角度来看，那是个巨大的担忧。
-
但另一方面，如果你说的是今天的训练工作负载，那就是越大越好。
-
因为从网络的角度来看，其实你希望把东西集中在尽可能小的距离内。
-
但话说回来，有两个问题，单点故障，还有就是现在的电力供应。
-
嗯，十到十五年前，一个吉瓦已经很大了，但至少还能想象，现在这个国家或世界上任何地方都不可能。
-
我们不可能把谷歌的全部需求都建在一个地方。
-
这根本不可能。
-
那现在最优的规模是多少呢？
-
这个我们也有模型，有模拟器之类的。
-
但这也取决于，你看，有些地方我们会建在网络边缘，或者建在某个国家里。
-
那可能是几十兆瓦。
-
我们实际上会跟ISP合作，可能是在伊拉克。
-
真的，可能就是在伊拉克。
-
如果是训练集群，那可能就要接近一个吉瓦了。
-
其他一些站点可能是几百兆瓦，等等。有意思。
-
我很想了解你是怎么考虑这个组合的生命周期管理的。
-
我猜最大的、最新的集群是用来训练最新的前沿模型的，然后旧的回收利用，拿来跑推理。
-
这个框架合理吗？
-
你们也会专门搭建推理专用的集群吗？这一切是怎么运作的？
-
你这个框架非常合理，我觉得很有道理。
-
但我想说的是，推理的需求大到我们不能只靠那些不再完全用于训练的旧训练集群来作为推理的基础。
-
而且你想想，某一年我们可能会把训练集群集中到少数几个大站点。
-
把它们之间的网络距离保持得小是有好处的。
-
所以现在不管它们在世界上什么地方，它们很可能，比如说，在同一个大陆上，或者某一年甚至可能在同一个大陆的同一片区域。
-
所以这样一来，你在其他大陆上可能就没有足够的服务容量了，等等。
-
所以那我们就得，好吧，实际上我们就得去世界其他地方建专门的推理设施。
-
所以我觉得你的直觉非常准，但不完全对。
-
换句话说，确实得是这样，好吧，这些是训练集群。
-
是的，它们可能过几年也会被用来做服务。
-
但与此同时我们也得建服务集群。
-
那你的服务集群，跟训练集群不一样吗？
-
比如说，它们更小吗，每兆瓦更便宜吗？
-
其实不一定更便宜，因为做服务更需要把计算、网络和存储放在一起。
-
于是这就导致了没法专门化。
-
因为训练的话，你其实是这种大密度、统一的部署，等等。
-
而做服务的话，你就得把存储、计算和加速器混在一起。
-
而且，这里还有一个很有意思的方面，我们也可以再深入聊聊。
-
但做服务的话，你其实不希望一个地方放太多东西。
-
你希望从全球各地来服务你的工作负载，但现在我们会有一个个单独的模型端点，而且模型其实还可能有不同的变体。
-
所以现在我们就得把这些模型分散到全世界，同时还要考虑就近性。
-
所以它们会更小，而且很可能垂直整合程度更低，在推理这一侧。特别有意思。
-
所以如果你五年前建了一个数据中心，你知道，五年前最先进的加速器跟今天造的比起来差别很大，效率低得多。
-
你真的会回去把那些旧数据中心里的芯片换掉吗？
-
我知道这跟一个一直在争论的话题有关，就是一颗芯片的实际使用寿命到底有多长？对，对。
-
所以，你知道，我公开说过这个话，在我一次比较——我当时很惊讶它引起了这么大的反响，但你知道，我说我们七八年前的TPU现在还是100%的利用率。哇。
-
我觉得我好像看到过这个，但我不知道是你说的。
-
我本来没想让它成为一个有分量的说法，但显然它成了一个有分量的说法。
-
对，所以我们那些老一点的TPU、GPU，但我们那些老一点的TPU利用率还是相当高的。我们确实会替换它们。
-
说到底，问题在于，好吧，它们的折旧年限大概是六年。
-
所以一旦它们完全折旧完，再加上新一代的能效等等，替换和升级它们确实是合理的。
-
不是说我们——我的意思是，我们确实会换芯片，但真正换的其实是整个系统。
-
换句话说，我们是按pod来考虑的，所以一个TPU，比如说一个T pod可能是9600颗芯片，可能是140多，152个机架，等等。
-
那我们就会说，好，我们要把那个pod拔出来，换成一个，不管是TPU 12还是13还是14的pod。
-
它可能不是完美匹配。
-
然后我们就得，换句话说，新pod的占地可能跟旧pod腾出来的空间不是完美匹配。
-
那我们就得把这一点考虑进去，得想办法怎么改造。
-
我们没法提前规划这个，因为我们不知道那么多代之后的TPU会是什么样。
-
所以这又有点靠手艺了，得想办法——而且这其实是挺难的工作——想办法怎么拆掉，然后尽快用新的TPU替换上去。
-
你公开写过关于开放标准的东西。能说两句吗？好。
-
我觉得这就是我们聊过的那个互操作性的问题。
-
所以对我们来说，虽然我们支持垂直整合，我们也让大家能够，你知道，想榨出多少性能就榨出多少性能，但对我们来说，真正重要的是不强制锁定，不强制搞成一个从端到端怎么运作的封闭花园。
-
我举一个例子。
-
在谷歌，我们开发了一个叫Jax的模型开发框架。我们很喜欢它。我们觉得它真的非常非常好。
-
我们在内部大量使用它。
-
我们的很多客户喜欢PyTorch。
-
我们本可以说，嘿，如果你想在TPU上跑，你就得用Jax。它是最好的。
-
我这话有点开玩笑，但也许它是，也许它不是。
-
我们觉得它是最好的，而且这是你唯一的选择，因为它太棒了。
-
或者我们可以说，看，如果你喜欢Jax，我们也喜欢Jax。
-
如果你喜欢Jax，你可以用它。
-
但如果你喜欢PyTorch，我们有Torch TPU，你未经修改的模型等等都能跑。
-
其实纵观历史，我们见过很多很多这样的例子。
-
我用过IP这个例子。
-
为什么互联网协议赢了？
-
其实当年有很多协议在和IP竞争。
-
这是70年代和80年代初的老历史了。为什么IP赢了？
-
因为它是一个开放标准，而且它是那个沙漏的细腰，上面软件层面什么都能跑，下面硬件层面什么都能接。
-
所以开放标准、可互操作，任何人只要带来IP就能插进路由器的端口，成为互联网的一部分。那真是太美了。
-
而正是这一点让互联网爆炸式增长，触达全世界。
-
所以我们真的相信那些开放标准，相信那些接入点。
-
现在如果你想接入一些高度专门化的东西，你可以。
-
如果你觉得你有更好的东西可以接入我们的框架，你完全可以。
-
但我们真的想支持开放标准，最好围绕它也是开源的。
-
它太大了，也太重要了，不可能只靠某一家厂商的封闭方案来建，对吧？对，我们真的相信这一点，而且必须要有选择。
-
这也是为什么，比如说，我们完全支持并且同时拥有TPU、GPU还有其他加速器等等。对。
-
AI让你们团队的日常工作发生了什么变化？
-
它对你职能的改变最大的是哪里？
-
我觉得不管你怎么说，最简单的答案是在软件工程这边，这方面外部已经有很多记录了。
-
所以我觉得在谷歌，在我的团队，我们在软件开发能力上把它用得效果很好，但说实话，还有测试、上线发布，甚至帮助做设计等等。
-
但在硬件这边，可能外部报道少一些，也发生了很大的变化。
-
换句话说，我的硬件工程师们——其实我今天早些时候刚看了数据——也在用AI，用所谓的token数来说，如果你想这么算的话，这不是最好的指标，但它好歹是个指标。
-
我们的硬件工程师用AI的程度跟软件工程师一样多。
-
而且生产力提高了。
-
从设计启动到流片的时间在缩短。
-
点亮调试的时间在缩短。
-
所以换句话说，生产力在显著提升。
-
但还有另外一些可能没那么被预料到的变化，就是我们做数据中心设计的方式也发生了显著改变。
-
换句话说，还有我们怎么评估——你提到过，我们是建一个吉瓦级的楼，还是100兆瓦的园区，或者200兆瓦的园区？
-
过去，这会是非常细致、非常依赖表格、依赖人工的流程。
-
某种程度上现在还是这样，但现在有很多AI参与进来，在规划和开发方面也确实大大简化了这个流程。
-
那些是像推理模型吗，还是？
-
我倒不会说已经是推理模型了。
-
它不是在取代人的判断，而是让把必要的信息汇集到一处变得容易得多，基本上就是把正确的信息摆到做决策的人面前。
-
好，最后我用两个有点天马行空、挺好玩的问题来收尾。好。
-
第一个问题，轨道数据中心。
-
我看到谷歌在相当认真地考虑这件事，这个你不用评论。
-
但人们真的在认真算轨道计算的账，这是不是意味着地球上确实存在一些硬性的、绕不开的约束？
-
你怎么看轨道数据中心？嗯，这是个很令人兴奋的方向。
-
我们其实正在推进这件事，而且我们提到它的时候，还真不是开玩笑，是把它当作我们很兴奋、愿意投入的重大项目之一，一个“登月计划”。
-
这要回到对话前面你提到的那个点，我觉得你说得对，从根本约束来看，能源和能源生产是一个关键的、关键的挑战。
-
所以归根结底，从基本原理上看，在太空里你能多获得大概40%的电力，因为大气层没有衰减之类的。
-
换句话说，就是太阳能容量更多，1.4倍。
-
这是其中一部分。
-
但在太阳同步轨道上，你的太阳能电池能有90%到100%的时间被阳光照到，相比之下地面上大概是28%、30%，也许35%。
-
所以换句话说，就是巨大到不行的电量，显然来自太阳，你拿1.4倍，再乘上每天小时数上的三到四倍，基本上就把电池从等式里拿掉了，于是你就有可能做出一种真正能终结，当然，
-
零碳排放，好处很多，挑战也很多，非常非常多的挑战。
-
所以换句话说，好，那散热呢？
-
你可能天真地以为太空里散热更容易，其实更难。可靠性。
-
我们聊过这些东西有时候会出故障。
-
所以维修变得更难。
-
不是不可能，但在太空里会变得更难。网络。
-
那个小机器人能跟着集群上去吗？没错。
-
所以也许这个模式会是一个很有前景的方向。
-
冗余很可能会是你的好帮手。
-
你关于自由空间光学的那个问题，现在要变成现实了。
-
我们大概不会在这些组件之间拉光纤。
-
所以实际上会是自由空间，我们会让激光对准接收器，并实时校准。
-
这里没有什么拦路虎，没有什么根本性的拦路虎。最后一个问题。
-
这一整段时间里，我脑子里一直有那幅你们建的那个难以言喻的大型超级计算机的画面，所以问题是这样的。
-
十年之后，最前沿的超级计算机会是什么样子？哦，我的天。
-
是啊，十年正好卡在那个边缘上，我真心实意地说，可能有些人正在琢磨2036年的计算机会是什么样。
-
我们也许有少数人会想得那么远，但哇，那里的不确定性锥体实在是太宽太宽了。
-
换句话说，如果你看这些趋势，集成度会变得极其惊人。
-
所以，你知道，我们看到了那些漂亮的光纤，还有我们为ineffable组装起来的VR200机架，我猜它会更加集成化，光纤更少，我不会说2036年完全没有光纤，但我认为大概从机架的角度来看，
-
机架看起来会集成得紧密得多，而光纤的数量，也许会有小小一束光纤从机架里伸出来。
-
然后，换句话说，从模块化制造的角度你可能会有一种看法，这些机架，很可能在2036年，会集中制造。
-
所以不管它们是有72个、144个、288个，还是可能更多，但你知道，576个、1152个，随便挑你喜欢的GPU倍数，既然我们聊到了ineffable那个例子，但TPU也会是一样的，深度集成到一个机架里。
-
一个机架会有好几兆瓦吗？
-
你知道，我们并不确切知道会怎样，但2036年嘛，我们可以尽情想象。
-
单个机架可能会达到好几兆瓦。
-
到那时候你接进水，接进电，接进光纤，对吧？
-
你把那个机架推进去，把那三样东西一插，你就可以开跑了。
-
好吧，那它不会像太空中一个巨大的外星球体那样吧？
-
到2036年，我不会说2036年就直接发射到太空是不可能的。
-
然后也许被某个空间站上的机械臂抓住，再插进正确的模块里。
-
是啊，也许2036年就是这样，想想还挺好玩的。
-
我真的很享受这次对话，这是历史上最激烈、规模最大的资本支出建设。
-
但我也觉得这是一场技术革命，一场美得不得了的革命。是啊。
-
而且我觉得你对这门技术的美、对它的硬性约束、以及怎么把这一切平衡好，都有很深的把握。
-
谷歌交到靠谱的人手里了。
-
谢谢你抽时间来分享你在做的事。真的特别有意思。
-
我们能亲身经历这一切，还能去定义它。所以非常感谢。这是一次很棒的对话。谢谢。谢谢。