谷歌AI基建主管谈：Agent重塑基建、光网络突破、终极物理瓶颈和未来10年的算力形态

人类历史上规模最大的资本开支建设正在展开。从衡量系统真实性能的"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 的能力翻倍。而其中来自软件的部分，很可能不少于来自硬件的部分。也就是说，收益可能来自模型优化，也可能来自运行时优化。实际上，更可能是数十、数百项单独优化不断落地，一次又一次叠加，才让这一切成为可能。但容量提升的速度确实令人难以置信。
主持人：
过去几年里，我们已经看到了几年数据中心建设、模型进步和软件进步。以“每瓦智能”来衡量容量增长，经验上分解一下：多少来自硅片本身，多少来自模型，多少来自其他软件，以及其他大的组成部分？
阿敏：
这个问题很好。我没有精确分解数据，但根据我们的经验，大部分收益来自模型侧改进，也就是模型软件系统层面的 intelligence per watt。顺便说，“每瓦智能”是个非常棒指标。我们更准确的说法是“每瓦 goodput”。之后可以再说为什么分母必须是瓦。Goodput 本质上可以是“每瓦交付智能”的度量；goodput 本身是工作负载特定指标。但我认为，大部分增益往往来自模型侧软件系统，其次也来自软件系统其他部分。为什么？因为它们能确保你已有的硬件被有效利用。
硬件本身也确实惊人。换句话说，我们正生活在一个年化 2 倍甚至更高性能改进完全可能的时代。硬件确实能够支撑这一点。如果你想要一个比喻，它像一个“免费乘数”——不是完全免费，但其他所有上层都可以指望它：这是一个逐年把所有人抬升的乘数。
TPU 的赌注：从 2013 年的逆势判断，到首次拆分为 8i 与 8t主持人：
我想聊聊 TPU 项目和协同设计。Google 十多年前就开始做定制芯片，这在当时是个逆势判断。TPU 项目是如何演变的？
阿敏：
变化相当大。项目始于 2013 年，当时确实非常逆势。很难把你重新放回 2013 年的语境：当时的传统智慧是，所有最聪明、最有经验的人都会说，你不该为单一工作负载构建定制加速器。为什么？因为摩尔定律还在，每 18 或 24 个月性能翻倍还在；你可以利用标准编程模型，你的 C++、Java、Python 等等都能用。这有点像芯片领域的“苦涩教训”：专门化永远不会赢。
但在这个特定案例里，我们有一个应用，或者说少数几个应用，会从专门化中极大受益，而要支持它们需要难以想象的海量通用 CPU。所以 2013 年它确实是一个赌注，甚至公司内部也有相当多的人不确定它能否成功。结果证明这是一个巨大成功的赌注。
第一代芯片完全围绕推理。第二代芯片则是：实际上我们可以把同样思路扩展成训练芯片。从那以后，越来越多用例开始使用 TPU。大约第二代芯片推出前后，Transformer 被发明了，那是一个重大时刻，也完全改变了 TPU 项目的方向。我们还发现推荐系统在 TPU 上运行得非常好，于是广告和相关用例也加入了进来。所以这种变化和演进，本质上是范围和影响力的扩展：它从一个极具影响力的一两个推理服务用例开始，主要是语言翻译和语音识别；然后扩展到训练，再到 Transformer、推荐系统；随着生成式 AI 时刻到来，又继续泛化到越来越大、越来越可扩展的系统。
主持人：
你提到 Transformer 的出现是一个重要时刻。我很好奇，TPU 是一种特定架构，但并不是专门针对 Transformer 的。你如何在“芯片对负载该有多专门”这条细线上把握平衡？
阿敏：
这是个很好的问题，核心在于芯片对特定工作负载的适用性。每一代我们都在思考：是否要进一步专门化？比如说大约两年多以前，我们面对的问题是：到 2026 年，我们应该做两颗芯片还是一颗？我们可以做一颗芯片，同时较好地完成推理和训练；也可以做两颗芯片：一颗进一步专门化于推理，另一颗进一步专门化于训练。这个分析和这项工作最终促成今年发布两颗芯片：8i 用于推理，8t 用于训练。
最终我们意识到，几年前情况未必如此，但到 2026 年，我们看到推理和服务真正起飞了。于是一颗在服务上明显更快的芯片开始变得非常有意义。我们曾估计，推理在其生命周期内可能占市场的 30%、40%、50%、60%。相比之下，如果我们预计推理只占市场的 2% 或 5%，即使专门化芯片快 2 倍，也可能没有意义；因为你反而会偏向一颗通用芯片——它虽然没有完全优化，但具备统一性等优势。
所以这确实是一个计算问题：你是否要进一步专门化？这个工作负载有多大？未来两三年、三四年它预计会有多大？这个工作负载是否能支撑硬件层面的持续增长？正如前面所说，机会在于：你对某个工作负载专门化程度越高，灵活性越低，但硬件会越快、越省电。所以这是一门艺术，也是对设计目标的预判：这个工作负载有多持久？如果它一两个月、三个月后就消失了，即使这三个月很大，你 interception 的窗口也非常窄。它必须足够持久，而且你必须能准确预判专门化能带来多少收益。
主持人：
粗略权衡似乎是：支持一个新项目有很高的固定成本。
阿敏：
是的。你必须认为，对这个特定项目会有足够需求来证明成本合理。举个例子，对于 8i 和 8t 两颗芯片，两者其实都能做另一种工作负载，这一点也很关键。假如 8i 只能做推理，完全不能做训练，也就是训练性能为零；反过来，假如 8t 训练极强但推理性能为零，那也会是关键限制。为什么？因为我们就必须提前预测，在这颗硬件约六年生命周期里，各自到底需要多少。现在这样比较好：两颗芯片都更擅长自己的专门负载；但如果某个地方有剩余容量，两者也都能承担对方的工作。取决于专门化程度，你可能会把自己搞得过于专门，从而失去灵活性、可互换性。
主持人：
既然粗略权衡的一端是项目规模，那我问个挑衅点的问题：现代 AI 市场这么多东西都基于 Transformer，为什么不干脆把 Transformer 架构“烧”进芯片里？
阿敏：
Transformer 确实是基础，但下一层问题是：Transformer 本质上围绕向量、矩阵乘法运算，以及 softmax。也就是一系列线性代数原语。我们这些以及其他厂商大致已把这些原语固化进硬件。大家当然都基于 Transformer，但模型架构还有一层：你有多少层？如何在层内前进？如何跨层前进？每个维度上应用什么形状的矩阵和向量？你可以进一步专门化，不只是专门化到 Transformer，而是专门化到你的模型。这是下一层专门化。我知道有一些公司在思考这个方向，我也认为这是一个非常非常有趣的方向。
主持人：
那么现在，你的客户会把 TPU 和 GPU 看作大致可互换的等价物吗？还是说某些问题更适合其中一种？
阿敏：
肯定存在某些问题更适合其中一种。GPU 比 TPU 更通用，这一点很清楚。Google 和 Google Cloud 有非常出色的产品，我们销售大量 GPU，内部也使用 GPU。但真正要看的是你问题的具体情况。我们的客户会在两者重叠的范围内，评估自己的工作负载和可选方案。我们在 Google 喜欢做的是给客户选择权：为他们的需求提供正确解决方案，并尽可能提供最能满足他们需求的方案。
协同设计的支持与反对理由主持人：
从芯片到网络再到软件，协同设计的理由是什么？反对理由又是什么？
阿敏：
协同设计有巨大的优化机会。可以想象，如果你有一个端到端栈，想自由选择任意组件——比如你跨多个云运行，或跨许多硬件、许多软件运行——你可以设计抽象层，声明：我能运行在任何硬件上，运行在任何软件上，运行在任何网络拓扑上，你给我多少网络我都没问题，我的系统会完全自适应。这样你就获得很强能力：新容量一夜之间出现，你就能跑起来，因为系统就是按这种方式设计的，可以立刻利用任何资源。你没有硬编码，也没有对任何特定基础设施做专门化。
缺点是，如果你完全通用，你很可能会把大量性能留在桌上。如果你对任何人的硬件、软件、网络、存储、计算等栈都完全灵活，那么每一层之间都会出现很大的“阻抗失配”，如果你追求完全通用性的话。每层之间可能有 10%、20%、甚至 2 倍差距。你开始把这些优化机会逐级相乘，最后会剩下一个很大的端到端机会——无论你称之为每瓦智能，还是每瓦 goodput——都可以利用，甚至一路下探到配电、电力可用性、软件优化等等。
支持协同设计的一方是：你可以随时随地运行，没有锁定。反对的一方是：你会把显著、甚至很可能是显著数量的性能留在桌上。
主持人：
我的理解是，如果看 OpenAI 和 Anthropic：OpenAI 主要构建在相对同构的计算栈上，而 Anthropic 构建在相对更异构的计算栈上。这是否部分解释了协同设计，也成为传闻中两家模型架构非常不同的原因之一？
阿敏：
我不能、也不想推测 OpenAI 和 Anthropic 在做什么。这是一种可能性。但在不知道他们具体做法的情况下，我会想象，他们最终采用不同架构可能有许多原因。
与 DeepMind 并肩作战：在芯片飞行途中“拦截”架构主持人：
那 Google 呢？我很好奇你的团队与 DeepMind 的工作关系是什么样的：在模型开发的哪个阶段，谁会进入同一个房间？你们如何在协同设计上共同决策？
阿敏：
这是我在 Google 工作最有趣、也最让人欣慰的部分之一：有机会与 DeepMind 团队真正肩并肩地协同设计硬件和模型。还有第三个元素：我们还会把这种协同延伸到消费者服务和云。这个先放一边，之后可以回来谈。就 DeepMind 而言，这真的是深度合作伙伴关系。
举过去的例子：他们提出模型优化，可能是针对 Transformer，或针对某个特定数学运算；而那时我们有一颗芯片正在进行中，还没完成。他们可能会说：“天呐，如果硬件支持这个，我们的端到端训练或服务可能显著更快、更高效。现在要改变我们正在执行中的硬件定义，需要付出什么？”这会促使双方工程师和研究员密集地聚到同一个房间，待几天、一周、两周，讨论：“好，我们可以做到。”更常见的情况是，“我们没法完全做到你想要的，但可以做成另一个版本。”然后也许你也能把模型架构往另一个方向改一点，从而得到你想要的 98%、我们目标的 90%，然后我们再回头去调整硬件。或者说：“你知道吗，我们会把 tape-out 推迟一两周，因为这个收益级别完全值得。”
类似地，当我们规划路线图时，任何时间点上都有许多代芯片在并行推进：一代是已经量产的芯片；一代是正在努力投入量产的芯片，已经从制造商回来，我们在调试、让它工作；一代是处于实现阶段、即将 tape-out 并交给制造商的芯片；一代处于设计阶段；还有一代处于概念阶段。所以从量产到还在脑海里，真的是一条五六个阶段、跨越许多年的流水线。
与 DeepMind 的合作，对已经量产的芯片非常重要，因为我们可以共同最大化“交付智能”或“每瓦交付 goodput”。我们确切知道模型里发生了什么，也知道硬件里发生了什么，以及两者之间的一切。我们也可以深度合作那些即将 tape-out 的芯片。为什么？因为我们可以拦截，并字面意义上在芯片架构“飞行途中”做修改。这如果跨公司边界会很难，甚至不可能；不是说不可能，但难得多。假如离芯片完成只有几周或几个月，再说“天哪，让我们肩并肩坐到同一个房间，看看是否该打乱项目”，这是可能的，但更难。这是我对跨公司边界的判断。
对于那些还在设计阶段的芯片，我们可以一起评估许多架构。我们会问 DeepMind 同事：你们认为两三年后的模型架构会往哪里走？这是我们能做的一组方案，这是模型架构可能演进的一组方向。我们其实有深入且重大的仿真基础设施，可以预测工作负载将如何映射到不同硬件架构上。深度而快速的迭代。团队并不是分开工作的，很多时候就在同一栋楼、同一个房间里，日常深度互动。我和 Koray、Demis 等人每周都会多次交流。所以这确实是工作里非常有趣的一面。
主持人：
太棒了。最终他们的模型也会帮助芯片设计。
阿敏：
我们也在用 Gemini 为未来版本的 Gemini 设计硬件。
主持人：
这真的很酷。之后我想再回头聊合作本身。我猜这里仍存在一个阻抗失配：硬件周期显然比 DeepMind 软件侧面对的周期慢，而你们的规划周期肯定也更靠前。那么你们实际还有多少调整空间？
阿敏：
这是个好问题。毫无疑问，我们会提前两三年、四年、五年规划硬件。刚才聊到我们已经宣布的 TPU 第 8 代，但你可以想象第 9、10 代，也许还有别的，已经处于概念、执行或其他阶段。它们可能还有好几年才出来。而如果你默认在做模型架构工作，通常不会提前好几年思考。
但这也恰恰是公司一起成长起来的伟大之处。Google Research、DeepMind、Transformer 的发明，所有这些也都发生在这些相互重叠的房间里。也就是说，有一整代研究员已经习惯了能够影响硬件，也知道硬件按多年周期运转。他们也知道：如果只是一个能给即将 tape-out 的芯片带来 1% 或 0.5% 收益的小改动，他们大概不会来找我们，因为他们足够了解：这不像软件，你不能提交一个 change list，两周后就上生产。实际上，叫停一次 tape-out 是大事。但他们也知道，如果真有一个非常大的机会，我们绝对会一起努力，看能否把它放进去。所以收益来源是乘性的。硬件会抬升所有船只，对吧？
DeepMind 团队有相当一部分人——我们对此非常感激，那是个令人惊叹的团队——会认真思考如何影响路线图，因为那是一个流水线。你两年前的想法，现在已经在生产里，并帮助 Google 所有工作负载跑得更快，那是一种很好的感觉。
主持人：
完全同意。不过，预测五年后最常见的工作负载、以及会出现什么算法突破，这看起来几乎不可能。
阿敏：
听起来确实不可能。我明白为什么你会觉得不可能。但令人震撼的是——我们其实正在非常详细地写这件事，而且写起来很有意思——TPU 架构在中等细节层面上，自 TPU v1 以来并没有真正改变。不是说在最高层面上没变，而是在中等细节层面上。你可以把它类比为 CPU 的指令集架构：你有 load、store、add、subtract、branch。这么多年软件在上面做了什么？TPU 也一样。我们有一些基本指令和基本原语。当然我们扩展过它，不是说指令集完全没变；但那些原语，比如专门化的数值格式、非常大的矩阵乘法单元、一个管理向量操作和 scatter/gather 操作的 sparse core 等，真正定义它的就是五六件事。还有一个实际是 load remote/store remote：我们可以通过 ICI 网络读写远端内存。这些基础一直在，并且已经扩展到许多代模型、许多代甚至深度神经网络算法和模型结构。
长程智能体改变数据中心形态主持人：
说到工作负载变化，过去一年左右最大的变化之一——我认为其实是从今年日历年年初开始——是长程智能体（long-horizon agent）的崛起。我猜这种工作负载和过去几年那种快速轮转的 LLM 对话形状很不一样。这对数据中心需求意味着什么？
阿敏：
我认为有两个巨大方面。第一，它不再是“人——加速——交互”的模式。换句话说，当你在网页浏览器或手机上输入 prompt 时，当然，响应你的 prompt 会发生大量计算；但当响应返回后，你必须读它、思考它，然后也许才有 follow-up。这中间通常是多秒级的交互时间。现在，在长程智能体中，没有人在环路里，自然不会限速模型收到请求的速度。过去以秒计、也许几十秒计的交互时间，现在可能进入毫秒级：我一拿到响应，就可以解析它、对它做一点推理，并判断下一个请求是什么。
第二个大变化是：所有这些推理和解析大概率发生在 CPU 上。而这个 CPU 接下来必须思考：为了生成下一个 prompt，我还需要收集哪些其他状态？换句话说，我从这个响应中学到了东西，我要采取下一步；但我其实需要去抓取一些上下文，可能来自本地 DRAM，可能来自另一台 CPU 上别人的 DRAM，可能在 SSD 上，也可能在别处的 HDD 上。所以现在还需要进行大量编排。
因此，设计正在发生相当显著的变化：加速计算需求在上升，但 CPU、网络、存储等传统数据中心 CPU 等需求也在暴涨。
主持人：
这意味着你们要在 GPU 机架旁放更多 CPU 吗？是 GPU/TPU 机架吗？
阿敏：
这是关键问题。回到优化和专门化的问题：如果我们开始在 GPU 和 TPU 旁边放很多 CPU 机架——这确实是个问题——那就意味着我们无法完全按 TPU 机架相对于 CPU 机架的密度和网络需求来做专门化。TPU 机架密度会高于 CPU 机架，可能也需要比 CPU 机架更多网络。换句话说，我们的建筑设计会发生变化。
另一个选择是保持均匀性：把 TPU 或 GPU 全放在一栋楼里，隔壁楼放 CPU；也许顺便说，硬盘必须放在另一栋楼，因为硬盘又有另一套要求。现在你需要在这些楼之间建立相当可观水平的网络。一旦离开一栋楼，网络复杂性会从可靠性、成本角度显著上升；延迟大概仍可接受，但现在组件之间可能出现数百微秒，甚至更多排队延迟。所以考虑因素会以非常有趣的方式变化。
主持人：
你的工作很难。
阿敏：
很难，但也很有趣。
光路交换与网络现状主持人：
网络侧发生了什么？我听说 Google 一直站在最新网络技术前沿，包括光网络。能讲讲光网络现状吗？
阿敏：
大约十五六年前，Google 就是最早把波分复用（WDM）引入数据中心的厂商之一。我们可以在单根光纤中放入多个信号，并把它用于机架之间的所有通信。同时，我们还引入了一项与波分复用一起使用的技术，叫光路交换（optical circuit switching）。本质上，光路交换与传统电分组交换相反：它完全在光域内传输和移动数据。
可以这样理解底层技术。在分组交换机里，你会拿到一个带头部的分组，在电域里查看它，根据头部判断它要去哪里；头部可能有 IP 地址，于是你查表：对于这个目的地，该从哪个端口转发？基本上每秒有数十亿、甚至数万亿个分组以超高速通过并被转发。而光路交换说的是：我不在电域里触碰这些比特。我要做的是，对一个输入端口，决定把光送到哪个输出端口。实现方式有多种，我们最初用的是 MEMS 开关：微机电马达在三维空间里控制反射镜。于是我们可编程地控制一个可能有 128 个端口、256 个端口或类似数量的盒子，把进入每根光纤的每个输入端口映射到某个输出端口，然后改变反射镜角度，让光真的照射到这些镜子上，并反射到正确的输出端口。
最初我们做这个有两个原因。第一，是在机架组之间创造局部性。假设我有一个计算集群和一个存储集群，共同支持——打个比方——搜索。我们知道这两个集群会频繁通信，于是配置反射镜，在两者之间 purely optically 创建捷径，连接两个机架集群。第二，我们希望能在不实际移动任何光纤的情况下扩展和收缩网络。这里不展开细节，我可以在白板上画出来。光路交换允许你重构网络 spine，从而扩展或收缩它，而不需要人类做任何事，只需要一个控制器来管理。
快进到 TPU。TPU 有 Taurus 拓扑，把所有 TPU 直接连在一起。前面我聊过吞吐和 goodput。我们能做的一件事是：如果一个 TPU 机架故障，可以用另一个 TPU 机架替换它，而无需移动任何光纤。这里也得挥挥手或画白板；但本质上，我们可以说始终保持有一个备用机架，当一个机架故障时，把光重新指向新机架，这可以在毫秒级完成。
主持人：
那为什么还要光纤？为什么不直接全用自由空间光？
阿敏：
问得好。衰减损耗和带宽会急剧下降。而且在一个非常大的建筑范围内，不靠光纤把所有东西在三维中连接起来，要对准所有光路会非常困难，甚至可能不可能。我们讨论过，也确实有过一些非常有趣的讨论。但是的，主要还是通过光纤；当光进入光路交换后，本质上光会直接照射到这些微小芯片上。这是网络的一个大方向。但还有很多可说，网络在数据中心里的能力和需求 frankly 都在爆发。
主持人：
太酷了。我们完全可以就这个话题单独聊一整期。
阿敏：
是的，非常酷。回到 Ineffable 那张照片，抓住大家眼球的正是那些线缆。而最终其中一些线缆会接入我们数据中心里的光路交换。
电力是约束条件：公用事业、吉瓦，以及数据中心规模主持人：
明白了。我想转向电力。你一直在讲每瓦 goodput、其他各种“每瓦”指标，这让我觉得“每瓦”意味着电力在某种意义上是约束条件、稀缺条件或昂贵条件。
阿敏：
我经常被问：我们面临的最大约束是什么？现实是，并不存在单一的“最大约束”。所有约束都是约束，都超级难，而且会不断变化。但如果必须从根本上回答，我会说电力是我们面临的最 fundamental 约束。其他所有问题似乎我们都知道如何在一段时间内解决；电力则是长期 binding 问题。当然，核能或许会带来丰富清洁能源，到时能解决很多问题；当它何时、以多大规模发生，仍然未知。
主持人：
实践上这是怎么运作的？你要新建一个数据中心，需要 1 吉瓦电力。我想象你不能直接打电话给 PG&E 说：“嘿，请送 1 吉瓦电过来。”配电实际上是什么样？你是否必须一路垂直整合，甚至自己造涡轮机？你们如何解决电力瓶颈？
阿敏：
这又是一个大问题、重要问题。我们在 Google 的首选模式始终是接入公用事业、接入电网。所以确实相当于给你数据中心所在地的“最喜欢的公用事业公司”打电话——当然，要非常礼貌——而且当然要提前很多年通知。换句话说，如果谈的是吉瓦规模，你不能说“我明天就要 1 吉瓦，什么时候开始计费？”这是我们一起多年共同规划的事情。对我们而言，我们也非常重视一点：与这些公用事业合作时，要把基础设施成本覆盖掉。这个话题可以聊很久。由于计费机制，理论上公用事业为我们建设容量，可能会导致其他人费率上升；我们确保的是，比如需要建设/升级的输电线、额外公用事业变电站等，这些费用由我们支付。
所以这是一个长期规划过程。绝对可能出现这种情况：假设我们在一个我随手编的年份 2028 年需要 1 吉瓦，而公用事业能在 2029 年给我们 1 吉瓦，2028 年只能给我们比如 700 兆瓦。这时我们可能就面临如何覆盖那 300 兆瓦的问题。一个答案是等；另一个答案是，研究如何自己产生其中一部分电力，也许是太阳能，也许配电池作为备份，也许来自其他来源。然后我们再次与公用事业合作。也可能是组合方案：我们在本地保留一定的发电能力，即使公用事业后来完全上线，比如达到吉瓦级，我们实际上还能把电回馈电网。也就是说，在他们需要时回馈电网。比如一年中最热的两周，住宅需求巨大；如果我们有本地发电，就可以把电回馈电网。
所以这确实是与公用事业多年合作的过程。为什么你更倾向这样做，而不是自己垂直整合？
主持人：
正是。
阿敏：
主要原因是灵活性和双方 uplift。可以这样看：统计复用，或者大数定律。如果我们需要 1 吉瓦电力，并且希望以 99.99% 以上可靠性获得，可能意味着必须建 2 吉瓦电力。在那个水平——99.99 或 99.999——你必须有 1+1 冗余，这会很贵。而且还要确保它 ideally 是清洁能源，最好就在数据中心旁边，这也很有挑战。现在如果我们与数据中心合作——也许我们自带一部分，可以在他们需要较少时给电网，也可以取用他们的电——通过在大得多的基数上做统计复用，实际上所有人都是赢家：我们赢，电网赢，居民也赢。我们偏好这种方式。极少数情况下我们也会 behind the meter 做，但即便那样，也是在假设我们会与公用事业合作、比如一年后并网的前提下做。所以这对我们是 uplift，对电网也是 uplift。
主持人：
有道理。你如何决定把一个数据中心建多大？
阿敏：
这是一门艺术，也是大量争论的来源。记得十多年、十五年前，Google 内部甚至有场大辩论：要不要把所有东西放进一个数据中心？那时那会是 1 吉瓦，在如今看来算“简单年代”的笑了。
其中一个明显担忧是单点故障。如果你从 30 年视角看，这是巨大担忧。另一方面，如果谈今天的训练工作负载，越大越好；从网络角度看，你确实希望事物尽可能集中在更小距离内。但接着又有两个问题：单点故障，以及电力可用性。吉瓦在 10 或 15 年前很大，但还能想象；而现在，要把 Google 的全部需求建在一个地方，在这个国家或世界上任何地方都不可能。那最优尺寸是多少？我们确实有模型、仿真器等。但这也取决于地点：有些地方我们会在网络边缘，或位于一个国家里，可能只有几十兆瓦；我们甚至与 ISP 合作，可能是在伊拉克。好吧，这不是训练集群。训练集群可能更接近吉瓦级。其他站点可能是几百兆瓦，等等。
训练与服务集群、七岁高龄的 TPU，以及开放标准主持人：
很有意思。我想理解你如何做组合生命周期管理。我猜最大的最新集群用于训练最新前沿模型，然后回收旧设备跑推理。这个框架对吗？你们是否也建设推理专用集群？这一切如何运作？
阿敏：
你的框架非常合理，也确实有意义。但我会说，推理需求大到我们不能只依赖那些不再被训练完全占用的旧训练集群来作为推理基础。再想想，我们可能会在某一年把训练集群集中到少数几个大站点；让它们之间的网络距离保持很小有好处。所以无论它们位于世界何处，在特定年份里，它们可能位于同一大陆，甚至同一大陆的同一区域。于是其他大陆可能就没有足够服务能力。这时我们就必须去建设专门的推理集群，分布到世界各地。所以你的直觉很准，但不完全。确实必须是：这里是训练集群；是的，几年后它们大概率会用于服务；但我们同时也必须建设服务集群。
主持人：
你的服务集群和训练集群不同吗？更小吗？每兆瓦更便宜吗？
阿敏：
不一定更便宜，因为服务更需要把计算、网络和存储放在一起，于是又回到无法完全专门化的问题。训练时可以做大密度、均匀部署等；而服务需要存储、计算和加速器混合。此外，服务还有一个很有意思的方面——可以以后再展开——就是你其实不希望在同一个地方放太多服务负载；你希望从全球各地为用户服务工作负载提供服务。但现在我们拥有单个模型 endpoint，实际上可能是模型的不同变体，于是还必须把这些模型分布到全球，同时考虑 locality。所以服务集群会更小， infant 侧可能垂直整合程度也更低。
主持人：
非常有意思。如果你五年前建了一个数据中心，当时最先进的加速器跟今天相比完全不同，效率低得多。你们真的会回去更换旧数据中心里的芯片吗？我知道这关系到一个持续争论：芯片实际有效寿命到底是多少？
阿敏：
是的。我之前公开说过这句话，而且我有点惊讶它引起这么大反响：我们七八年前的 TPU 仍然保持 100% 利用率。我的本意并不是要发表什么重大声明，但显然它成了有意义的声明。我们较老的 TPU——以及 GPU——但我们的老 TPU 确实仍在被高度使用。最终我们还是会替换它们。问题是：一旦折旧寿命大约六年结束，并且考虑到新一代的能效等，替换升级确实有意义。并不是说我“更换芯片”，而真的是更换系统。换句话说，我们按 pod 思考。比如一个 TPU 8 pod 可能是 9600 颗芯片，约 140 多、152 个机架等。于是我们会说，要把这个 pod 拉出来，换成 TPU 12 或 13 或 14 pod。新 pod 占地未必和旧 pod 空缺完美匹配，所以我们必须考虑这一点，研究如何改造。我们无法提前规划这个，因为我们不知道那么多代 TPU 会是什么样。所以这又是一门艺术，并且要实际做很多艰苦工作，弄清楚如何分解旧系统，然后尽快用新 TPU 替换。
主持人：
你公开写过关于开放标准的文章。能讲讲吗？
阿敏：
我们前面谈过互操作问题。对我们来说，虽然支持垂直整合，也允许你尽情榨取性能，但非常重要的一点是：不强制锁定，不强制端到端的“围墙花园”。举个例子，在 Google，我们开发了一个模型开发框架叫 JAX。我们很喜欢它，认为它非常好，内部大量使用；而我们很多客户喜欢 PyTorch。一种做法是我们说：“嘿，如果你想在 TPU 上跑，就必须用 JAX，因为它最好。”我这是半开玩笑；也许它确实最好，但这不是唯一选择，不能因为它“很好”就只给这个选择。另一种做法是：如果你喜欢 JAX，我们也喜欢 JAX，你可以用；如果你喜欢 PyTorch，我们有 Torch TPU，你未修改的模型等也可以跑。
历史上我们见过很多这样的例子。我用过 IP 的例子：为什么互联网协议赢了？其实在 70 年代和 80 年代初，IP 有很多竞争协议。IP 赢是因为它是开放标准，是沙漏形结构中的“细腰”：任何软件都可以跑在它上面，任何硬件都可以跑在它下面。开放、可互操作；任何带来 IP 的设备都能插进路由器端口，立刻成为互联网一部分。它很美，也让互联网得以在全世界爆炸式增长、扩展。所以我们真的相信这些开放标准，相信插件式接入点。如果你想接入高度专门化的东西，也可以；如果你认为有更好的东西接入我们的框架，你绝对可以。但我们希望真正支持开放标准，理想情况下还有围绕它的开源。这次建设太大、太重要了，不能成为任何一家厂商的封闭专有栈。我们真的相信这一点，必须是选择。这也是为什么，比如我们完全支持并拥有 TPU、GPU、其他加速器等等。
主持人：
AI 如何改变你团队的日常工作？它在哪个层面对你们职能改变最大？
阿敏：
最容易的回答是软件工程侧。这一点外部已经有很多记录。我认为 Google 以及我的团队都在非常有效地用它提升软件开发能力，也 frankly 用于测试发布，甚至帮助设计等。但在硬件侧，也许外部报道较少，也发生了显著变化。换句话说，我的硬件工程师——我今天早些时候刚看了数据——使用 AI 的程度和软件工程师一样多。你可以看 token 数，这不是最好的指标，但仍然是个指标。硬件工程师使用 AI 的量已经和软件工程师相当。生产率也上升了。从设计启动到 tape-out 的时间在缩短；bringup 时间也在缩短。另一个生产率显著上升的地方，也许是较意想不到的变化：数据中心设计方式也显著改变了。也就是我们如何做数据中心设计、如何评估——你刚才提到，我们是建 1 吉瓦单体楼，还是 100 兆瓦园区、200 兆瓦园区？过去这会是非常细致、非常电子表格驱动、由人驱动流程；现在仍在某种程度上如此，但已经有大量 AI 参与，真正精简了规划和开发流程。
主持人：
有意思。是推理模型吗？
阿敏：
还不能完全说是推理模型。它没有取代人类判断，但确实让把必要信息汇集到一处、 basically 把正确信息放到做决策的人面前，变得容易得多。
轨道数据中心与 2036 年的超级计算机主持人：
最后我用两个有点“放飞”但好玩的问题收尾。第一个：轨道数据中心。我看到 Google 对此相当认真。你想让我评论一下。人们认真计算轨道计算这件事本身，是否意味着地球上存在严肃的约束条件？你怎么看轨道数据中心？
阿敏：
这是一个令人兴奋的方向。我们确实在推进，并且毫不调侃地把它称为一个 moonshot，是我们非常乐意投资的大项目之一。回到对话前面你正确提出的部分：从根本约束看，能源和能源生产是关键挑战。根本上说，在太空中，由于没有大气衰减等因素，可用功率大约多 40%。也就是说，仅仅日照容量就是 1.4 倍。这是其一。但在太阳同步轨道上，你的太阳能电池可获得 98% 到 100% 的日照覆盖，而陆地上可能只有 28%、30%，也许 35%。也就是说，能量极其充沛： obviously，你拿到 1.4 倍，再乘上每天日照小时数的 3 到 4 倍，并大体把电池从等式中移除，现在就有可能得到真正可观的东西。当然，它无碳，有很多好处，也有很多挑战。
挑战确实很多。比如冷却：你可能天真地以为太空中冷却更容易，实际上更难。可靠性：我们刚聊过这些设备有时会坏。维修在太空中变得更难——不是不可能，但更难。你刚才关于自由空间光学的 pre question 现在会成真：我们大概不会在这些组件之间拉光纤，所以真的会是自由空间光，激光指向接收器并实时校准。这里没有什么“根本性 showstopper”。
主持人：
最后一个问题。我脑子里一直装着你们为 Ineffable 建的超级计算机画面。所以问题是：十年后，最前沿的超级计算机会是什么样子？
阿敏：
天哪。十年正好处于那个边界上。我要非常诚恳地说：可能有些人已经在想 2036 年的计算机会是什么样。我们可能也有少数人想得那么远。但那里的不确定性锥实在太宽了。看趋势的话，集成度将会非常惊人。我们看到了为 Ineffable 组装的 VR200 机架里漂亮的光纤。我的猜测是，它会更加集成，光纤更少。我不会说 2036 年没有光纤，但我认为从机架视角看，机架会显得更紧密集成，可能只有一小束光纤从机架里出来。然后从模块化制造角度看，2036 年的这些机架很可能会集中制造。无论里面是 72、144、288，还是——既然聊到 Ineffable 案例，可能是 576、1152 个，随便选一个 GPU 的倍数；TPU 也一样——GPU/TPU 都深度集成进机架。一个机架会是多兆瓦吗？我们不知道具体如何，但 2036 年我们可以想象：单个机架可能达到数兆瓦。这时你引入水、引入电、引入光纤，把这个机架推进来，插上这三样东西，就出发去跑了。
主持人：
所以到 2036 年，它不会是一个漂浮在太空中的大异形球体？
阿敏：
我不会说 2036 年不可能把它直接发射到太空，然后由空间站机械臂接住，插进正确模块。也许 2036 年就会那样。
主持人：
想想就开心。我非常享受这场对话。这是历史上最 intense、规模最大的资本开支建设，但我也认为这是一场技术革命，而且是一件美的事物。你对技术之美、约束条件以及如何平衡这一切有非常深刻的把握。Google 交给你很好。谢谢你抽时间分享你们正在做的事。
阿敏：
非常开心。非常感谢。这是一场很棒的对话。我们有机会亲历这一切，并且有机会定义它。谢谢你。