← 返回

2026.10.08 | AC | GOOG | Google Amin Vahdat on AI Infrastructure

原标题：谷歌人工智能基础设施负责人Amin Vahdat：Google AI基础设施战略——从芯片协同到兆瓦级定制化数据中心

#datacenter #asic

AceCamp · 2026-10-08 · article 70567799

摘要

文章来源于2026年10月6日，红杉资本的Sonya Huang对谷歌人工智能基础设施首席技术专家Amin Vahdat的采访。

以下是访谈全文：

Q&A

AI数据中心与传统数据中心的核心区别是什么？

AI数据中心与传统数据中心在基础构成上有很多相似之处，例如都包含混凝土结构、电气站、机械站、冷却系统以及成排的电力分配设施和大量的网络基础设施。然而，两者最主要的区别在于专业化程度。传统数据中心的设计通常着眼于20至30年的长期投资回报，规划时需要考虑多代硬件的更迭，其硬件生命周期可能为6年，因此设计上必须具备高度的通用性，以适应服务器、网络存储或各类加速器（如GPU、TPU）等不同设备的需求。相比之下，AI数据中心通常是为特定目的而构建，其建筑设计往往与内部将要部署的硬件进行协同设计。例如，一个存储机架的功耗可能在10至40千瓦之间，而一个TPU或GPU机架的功耗如今已轻松达到数百千瓦，未来几年甚至可能达到兆瓦级别。因此，一个可以容纳30个存储机架的空间，可能只能容纳一到两个AI机架，这就对建筑的尺寸、电力分配和冷却系统提出了截然不同的设计要求。同样，AI机架所需的网络带宽也远超存储机架。如果试图让一个数据中心在30年内完全通用，可能会导致过度建设和成本高昂。因此，AI数据中心更倾向于与硬件进行深度协同优化，是一种高度定制化的基础设施。

如何衡量AI基础设施建设的有效性，以及为何“goodput”是比“flops”更优越的指标？

衡量AI基础设施有效性的核心在于工作负载的实际交付性能，而非理论峰值性能。像flops（每秒浮点运算次数）这类以芯片为中心的指标，仅仅反映了在理想条件下单个芯片所能达到的理论最大值。然而，实际性能很少由单个芯片决定，而是由数千乃至数万个芯片（无论是TPU还是GPU）、CPU、网络以及它们之间的协同工作共同决定的。因此，我们关注的是特定工作负载的实际运行表现。一个更有效的衡量指标是“goodput”（有效吞吐量），它源于Google内部，并正逐渐被行业所接受。Goodput不仅考虑了理论上的吞吐量，还计入了可靠性等因素对工作负载造成的实际影响。许多AI工作负载（如训练、服务或代理工作流）都是同步的，需要大量组件协同工作。在拥有10万个加速器的大规模集群中，组件故障是持续发生的。任何一个组件的故障都可能导致整个同步任务暂停，系统需要定位故障、恢复到上一个计算检查点并重新启动，最坏情况下甚至需要从头开始。这个过程中，系统虽然仍在进行计算（即产生throughput），但这些用于故障恢复的计算并未对最终产出答案做出贡献。Goodput衡量的正是扣除这些无效工作后，解决问题实际花费的总时间。因此，我们通过交付的goodput来评估自身表现，因为它真实反映了在实际故障条件下，为关键工作负载所提供的真正有效的计算能力。

在一个拥有10万个加速器规模的集群中，故障发生的频率是怎样的，主要原因是什么？

在一个拥有10万个加速器规模的集群中，故障是持续发生的。根据具体的系统配置，故障频率可能达到每天数次，甚至每小时数次。这些加速器芯片本身就是制造业尖端技术的产物，并且通常由多个小芯片封装而成，结构复杂，任何一个环节都可能出现问题。故障的原因呈现出长尾分布的特点，不存在单一的普遍性原因，否则问题早已被定位并修复。网络连接是常见的故障来源之一，因为需要在极高的速度下连接大量设备。硬件本身也可能出现问题。此外，大量的故障源于软件层面，例如编译器错误、运行时漏洞、模型问题或操作系统故障。即使硬件本身完全可靠，软件问题同样会影响整个系统的端到端性能。因此，在如此庞大的规模下，持续地、近乎实时地检测和恢复故障，就像在草堆中不断寻找一根针，是一项巨大的挑战。

在构建AI数据中心时，除了半导体公司提供的参考堆栈外，还需要进行多大程度的自主设计？

半导体公司，例如NVIDIA，不仅提供芯片，还提供非常强大的全系统参考堆栈。大多数客户会直接利用这些参考堆栈。然而，许多客户也会根据其特定的用例进行专业化定制，以寻求优化机会或满足特殊需求。同样，在TPU方面，我们也提供一个参考堆栈，大多数用户会采用它，但同样有许多用户会对其进行专门的调整和优化。

Google内部提出的“每六个月将服务能力翻倍”的目标，具体是指什么？其增长主要来源于哪些方面？

“每六个月将服务能力翻倍”的目标，具体指的是有效可用容量的提升，从服务角度来看，最终衡量的是令牌的生成能力。这并不意味着必须每六个月将硬件的flops数量翻倍，尽管增加硬件是实现路径之一。更关键的是，要将硬件生成令牌的能力每六个月提升一倍。这种能力的提升，软件的贡献与硬件同样重要，甚至更多。增长可能来自于模型优化、运行时优化，或是由数十个乃至数百个持续落地的小型优化共同推动。关于增长来源的经验性分解，虽然没有精确的数据，但大部分收益来自于模型侧的改进，即“每瓦特智能”（intelligence per watt）的提升。软件系统也贡献了相当大的部分，因为它能确保硬件得到有效利用。硬件的进步同样惊人，目前每年实现2倍或更高的性能提升是完全可能的，它为上层的软件和模型优化提供了一个基础性的乘数效应，推动整体性能的提升。

Google的TPU项目是如何演进的？在芯片设计中，如何在通用性与特定工作负载的专用性之间进行权衡？

TPU项目始于2013年，当时是一个反主流的决策，旨在为少数特定应用（主要是语言翻译和语音识别的推理服务）构建定制加速器，以应对通用CPU无法想象的计算需求。第一个芯片专注于推理，第二个芯片则扩展到训练。随后，Transformer架构的出现成为一个关键转折点，极大地改变了TPU项目的发展方向。推荐系统等更多用例也被证明在TPU上运行良好。因此，TPU的演进是一个范围和影响力不断扩大的过程，从最初的几个推理应用，扩展到训练、Transformer模型、推荐系统，并随着生成式A I的兴起，发展为规模更大、可扩展性更强的系统。

在专用性与通用性之间权衡的核心在于对工作负载规模及其持久性的预判。例如，大约两年前，我们面临一个决策：在2026年是推出一款能同时处理推理和训练的通用芯片，还是两款分别针对推理和训练进行优化的专用芯片。我们预测到2026年，推理和服务的市场份额将大幅增长，可能占到30%至60%。因此，为推理设计一款专用芯片变得极具价值。这个决策最终促成了今年（2026年）两款芯片的发布：专为推理优化的8i和专为训练优化的8t。如果当时我们预测推理只占2%或5%的市场，那么即使专用芯片快2倍，开发它的意义也不大，选择一款虽未完全优化但更通用的芯片会是更合理的选择。这种权衡是一种艺术，需要预测特定工作负载的规模、增长趋势以及持久性。硬件的专业化程度越高，其速度和能效就越高，但灵活性也越低。

既然8i和8t芯片分别针对推理和训练进行了优化，它们是否可以执行对方的工作负载？为什么不直接将Transformer架构固化到芯片中？

是的，8i和8t芯片虽然各有专攻，但都具备执行对方工作负载的能力，这是一个关键的设计考量。如果8i只能做推理而完全不能训练，反之亦然，那么我们将面临巨大的风险，因为需要提前数年精确预测每种硬件的需求量。目前的设计提供了灵活性：两款芯片在各自的专业领域表现更佳，但当一种容量有富余时，可以用来处理另一种工作负载。

关于将Transformer架构固化到芯片中，这实际上已经在一定程度上实现了。Transformer模型的核心是向量和矩阵乘法运算以及SoftMax等操作，这些本质上是一系列线性代数原语。我们和其他芯片制造商已经将这些基础计算单元大致上固化到了硬件中。

当前客户是否将TPU和GPU视为功能上大致可互换的等价物，还是说存在某些问题更适合其中一种处理器？

某些问题确实更适合其中一种处理器。GPU比TPU更具通用性，这一点是明确的。Google和Google Cloud都提供GPU产品，销量可观，并且内部也使用GPU。但最终选择取决于具体问题的特性。客户在评估其工作负载和可用选项时，会发现两者存在重叠。Google致力于为客户提供选择，即针对他们的需求提供合适的解决方案，并确保该方案能最好地满足其要求。

从芯片、网络到软件进行协同设计（Co-design）的优劣势分别是什么？

协同设计能带来巨大的优化机会。假设有一个端到端的N层技术栈，如果希望能够任意选择和组合组件，例如跨多个云或多种硬件、软件运行，就需要设计抽象层。这样的系统适应性极强，可以在任何硬件、软件、网络拓扑上运行，当新的计算能力出现时，能够迅速利用，因为系统设计上没有对任何特定基础设施进行硬编码或专门优化。这种方法的优势在于可以随时随地运行，不受供应商锁定。然而，其缺点是，为了实现完全的可替代性和灵活性，可能会牺牲大量性能。相反，协同设计的优势在于，在技术栈的每一层之间都存在巨大的阻抗不匹配（impedance mismatch），如果追求完全的通用性，就会产生性能损失。通过协同设计，每一层都可能带来10%、20%甚至2倍的优化，这些优化机会叠加起来，最终在端到端层面，无论是从每瓦特智能（intelligence per watt）还是每瓦特有效吞吐量（goodput per watt）的角度看，都会产生巨大的综合效益，这种优化甚至可以一直延伸到电力输送和功耗可用性等软件层面。因此，协同设计的弊端是可能失去灵活性，但优势是能够获得显著的性能提升。

OpenAI和Anthropic的模型架构据传有很大差异，这是否部分归因于协同设计，例如OpenAI主要基于同构计算栈，而Anthropic则基于更异构的计算栈？

无法推测OpenAI和Anthropic的具体做法。这是一种可能性，但在不了解其内部细节的情况下，可以想象他们最终采用不同架构的原因可能有很多。

Google内部团队与DeepMind在模型开发和协同设计方面的合作关系是怎样的，具体决策流程如何？

与DeepMind团队在硬件和模型协同设计方面肩并肩的合作，是Google工作中最有趣和最令人满足的部分之一。这种合作关系非常深入。例如，过去DeepMind曾提出模型优化方案，比如针对Transformer或特定数学运算的改进。当时我们可能有一款芯片正在开发中，尚未完成。他们会提出，如果硬件能支持某个新特性，端到端的训练或服务效率将大幅提升，并询问需要做什么来修改正在执行的硬件定义。这会促使双方的工程师和研究人员在几天到两周的时间里进行密集研讨。我们可能会说：“可以做到”，但更常见的情况是：“无法完全满足你的要求，但可以实现另一个方案。”相应地，他们可能会调整模型架构，以达到预期效果的98%，而我们则实现了目标的90%。然后我们可以回头修改硬件设计。有时，我们甚至会为了获得巨大的收益而决定将芯片的“投片”（tape out）时间推迟一到两周。

在规划硬件路线图时，这种合作同样至关重要。任何时候，我们都有多个世代的芯片处于不同阶段：已投产的、从制造商返回正在调试的、即将投片的设计实现阶段的、设计阶段的，以及概念阶段的。这是一个长达数年的五到六阶段的流水线。

这种合作并非团队间的独立工作，而是经常在同一栋楼、同一个房间里进行，保持着深入的日常互动。

硬件的开发周期通常比软件长得多，规划也更为提前，这是否会与DeepMind的软件开发节奏产生“阻抗不匹配”，实际调整空间有多大？

硬件规划确实需要提前两到五年。例如，我们刚发布的TPU 8，可以想象TPU 9、10甚至其他型号已处于概念或执行阶段，可能需要数年才能面世。而模型架构的思考周期默认不会那么长。但Google的优势在于，公司内部的研究人员已经习惯了这种合作模式。从Google Research到DeepMind，再到Transformer的发明，都发生在这些相互交织的团队中。因此，整整一代研究人员已经习惯于影响硬件，并理解硬件的多年度开发周期。他们知道，如果一个微小的调整只能为即将投片的芯片带来0.5%或1%的性能提升，他们可能不会提出，因为中断一次“投片”是件大事。但如果他们发现了一个巨大的机会，我们绝对会共同探讨能否将其纳入设计。硬件的提升能带动所有上层应用，因此DeepMind团队中有相当一部分人正思考如何影响硬件路线图。两年前提出的想法现在已经投产，并帮助Google所有工作负载加速运行，这带来了巨大的成就感。

预测五年后最常见的工作负载和算法突破似乎是一项不可能完成的任务，TPU架构如何应对这种不确定性？

这看起来似乎不可能，但TPU架构在中等细节层面自TPU v1以来并未发生根本性改变。这类似于CPU的指令集架构，虽然上层软件日新月异，但底层的加载、存储、加减法和分支等基本指令保持了稳定。TPU同样拥有一些基本的指令和原语，例如专门用于处理数值计算的超大矩阵乘法单元、管理向量操作和分散-聚集操作的稀疏核心（sparse core）、以及通过ICI网络读写远程内存的远程加载/存储（load/store）等五六个核心功能。虽然指令集有所扩展，但这些基础构建模块的稳健性使其能够支持多代模型、深度神经网络算法乃至模型结构的演进。

从2026年初开始，“长时程智能体”（long horizon agent）的兴起对数据中心的需求意味着什么？

“长时程智能体”的兴起带来了两大显著变化。

首先，交互模式从“人机交互”转变为“机机交互”。在人机交互中，用户输入指令后，需要时间阅读和思考返回结果，两次请求之间有数秒甚至数十秒的间隔，这自然地限制了模型请求的频率。但在长时程智能体中，没有人为干预，交互间隔可能缩短到毫秒级。智能体一收到响应，就能立即解析、推理并发出下一个请求。

其次，大量的推理和解析工作可能在CPU上进行。CPU在向模型发出下一个指令前，需要思考并收集其他状态信息。它可能需要从本地DRAM、其他CPU的DRAM、SSD甚至HDD中抓取上下文。这导致了大规模的协同调度需求。

因此，数据中心的设计正在发生重大变化。对加速计算的需求在增长，同时对CPU、网络和存储等传统数据中心组件的需求也在急剧飙升。

为了应对“长时程智能体”带来的变化，是否意味着需要在GPU/TPU机架旁部署更多的CPU？这在数据中心设计上会带来哪些考量？

这正是关于优化和专业化设计的核心问题。如果在GPU和TPU旁边放置大量CPU机架，我们将无法完全针对TPU机架的密度和网络需求进行专业化设计。TPU机架通常比CPU机架密度更高，网络需求也更大，混合部署将改变整个建筑的设计。另一种选择是保持设计的统一性：将TPU或GPU集中在一栋建筑中，而将CPU和硬盘驱动器等分别放置在旁边的其他建筑里，因为它们各自有不同的环境要求。但这样做需要在建筑之间建立非常高水平的网络连接。一旦网络跨越建筑物，其复杂性、成本和可靠性挑战都会显著增加，延迟也可能上升到数百微秒甚至更高。这些因素都深刻地改变了数据中心的设计考量。

Google在光网络技术方面，特别是光路交换（Optical Circuit Switching）的最新进展和应用是怎样的？

大约15、16年前，Google率先在数据中心内部署了波分复用技术，允许在单根光纤上传输多个信号，用于机架间的所有通信。同时，我们引入了光路交换技术。与传统的电分组交换不同，OCS在纯光域中传输和移动数据。在电交换中，交换机会读取数据包的包头（如IP地址），查询路由表，然后决定将其转发到哪个端口。而在OCS中，我们不接触电信号，而是直接为输入端口的光信号确定要发送到的输出端口。我们最初采用的技术是基于MEMS（微机电系统）的交换机，通过微型电机控制3D空间中的反射镜。我们可以通过编程，将一个拥有例如128或256个端口的交换机中的每个输入光纤映射到一个输出端口，通过改变镜面角度，让光线直接反射到正确的输出端口。

最初采用OCS主要有两个原因：

现在，这项技术也应用于TPU。TPU集群采用环形拓扑（torus topology）直接连接所有TPU。如果一个TPU机架发生故障，我们可以利用OCS在毫秒级内将光路重定向到一个备用机架，而无需移动任何光纤。

既然光路交换技术如此先进，为何不完全采用自由空间光通信，而仍需使用光纤？

主要原因是信号衰减、损耗以及带宽会急剧下降。此外，在一个非常大的建筑物范围内，要在3D空间中精确对准所有光束而不借助光纤进行连接，将极具挑战性，甚至可能无法实现。虽然我们曾讨论过这个想法，但目前主要还是依赖光纤传输，光信号在到达光路交换机时，才会在微小的芯片上通过反射镜进行切换。

在数据中心面临的众多约束中，哪一个是最根本的？

我们面临的约束是多方面的，并且在不断变化，没有单一的绝对约束。但如果必须选择一个，电力是最根本的长期约束。其他问题似乎都有已知的解决方案，只是时间问题，而电力问题，在核能等清洁能源大规模应用之前，仍是一个根本性的长期挑战。

为新的数据中心获取千兆瓦级别的电力供应，实际操作流程是怎样的？Google是倾向于与电力公司合作还是垂直整合自建能源设施？

我们首选的模式是与公用事业公司合作，接入电网。对于千兆瓦级别的电力需求，我们必须提前数年通知电力公司，共同进行规划。例如，如果计划在2028年需要1千兆瓦电力，而电力公司届时只能提供700兆瓦，到2029年才能满足全部需求，我们就需要考虑如何弥补这300兆瓦的缺口。一种方案是等待，另一种是自行解决部分电力供应，可能通过太阳能电池或备用电池等方式。我们还会与电力公司合作，可能在本地保留一些发电能力。当电网满负荷（例如在一年中最热的两周）时，我们甚至可以向电网反向输送电力。

我们倾向于与电力公司合作，主要基于灵活性和双方共赢的考量。这利用了“统计复用”或大数定律的原理。如果我们自建1千兆瓦的电力供应并要求99.999%的可靠性，可能需要建设2千兆瓦的冗余设施，成本高昂，且在数据中心旁建设清洁能源设施也充满挑战。通过与电网合作，利用其更庞大的基数进行统计复用，对我们、电网和居民用户都是有利的。只有在极少数情况下，我们才会采用“电表后”（behind the meter）的自建模式，但即便如此，我们通常也会计划在一年后接入电网。

决定一个数据中心规模大小的依据是什么？

这是一门艺术，也是内部激烈辩论的源头。大约10到15年前，我们曾讨论是否应将所有计算资源集中到一个千兆瓦级的数据中心。当时的主要担忧是单点故障风险。从如今的训练工作负载角度看，规模越大越好，因为从网络角度出发，资源越集中、距离越近越有利。然而，除了单点故障，电力可用性是另一个关键问题。虽然千兆瓦在十几年前是可想象的巨大规模，但如今要在一个地方满足Google的全部电力需求已无可能。因此，最优规模的确定需要依赖模型和模拟器。同时，这也取决于地理位置。在某些网络边缘或特定国家，数据中心规模可能只有几十兆瓦；而一个训练集群的规模可能接近千兆瓦；其他站点则可能是数百兆瓦。

在推理集群的建设上，是否可以主要依赖于那些不再完全用于训练的旧有训练集群？这种框架是否合理，以及公司是否也在建立专门用于推理的集群？

将不再完全用于训练的旧有集群用于推理是一种合理的思路，但仅依赖这种方式是不足够的。推理任务的需求巨大，不能完全依靠旧的训练集群来满足。此外，训练集群的部署策略也带来了限制。例如，在某一年，训练集群可能会集中部署在少数几个大型站点，甚至为了降低网络延迟而集中在同一大洲或大洲的某个特定区域。这种集中化部署会导致在其他大洲出现服务能力不足的问题。因此，必须在全球其他地区建设专门的推理集群。总而言之，虽然旧的训练集群未来可能会被用于推理服务，但公司也必须同步建设专门的推理集群。

推理集群与训练集群在设计和成本上有何不同？

推理集群与训练集群在构成和设计上存在显著差异，单位功耗成本不一定更低。推理服务需要将计算、网络和存储资源紧密协同部署，这限制了其专业化程度，不像训练集群那样可以实现大规模、高密度的统一化部署。因此，推理集群需要混合部署存储、计算和加速器。另一个关键区别在于，推理服务不适合过度集中。为了保证全球用户的访问体验和数据本地化，工作负载需要从全球各地提供服务。这意味着需要将不同的模型端点（包括模型的各种变体）分散部署到世界各地。因此，推理集群的规模通常更小，在基础设施层面的垂直整合程度也可能较低。

对于使用了5年甚至更长时间的旧数据中心和芯片，公司的处理策略是什么？这些芯片的实际使用寿命是多久，是否会进行替换升级？

公司使用了七到八年的TPU芯片，其利用率仍能保持在100%。尽管如此，这些旧芯片最终还是会被替换。芯片的折旧年限大约为6年，一旦完全折旧，考虑到新一代芯片在功耗效率等方面的显著提升，进行替换和升级是符合经济效益的。升级过程并非简单地更换单个芯片，而是以系统为单位进行，通常是替换整个“pod”。例如，一个包含9,600个芯片、由152个机柜组成的TPU 8 pod，会被整体移除，然后替换为新一代的TPU pod（如TPU 12、13或14）。这个过程中存在挑战，因为新旧pod的物理尺寸可能不完全匹配，需要进行改造和适配。由于无法提前预知未来几代TPU的具体形态，这种改造工作需要投入大量精力，以确保在拆除旧设备后能尽快完成新设备的部署和替换。

公司如何看待开放标准在当前技术生态中的作用，以及在实践中是如何支持的？

开放标准和互操作性至关重要，公司致力于避免强制性的技术锁定和“围墙花园”式的封闭系统。尽管公司支持垂直整合以实现极致性能，但最终选择权应交给用户。一个具体的例子是模型开发框架：虽然Google内部开发并广泛使用其认为非常出色的JAX框架，但公司也充分认识到许多客户偏爱PyTorch。因此，公司并未强制要求使用TPU的用户必须采用JAX，而是通过提供torch TPU，让未经修改的PyTorch模型也能在TPU上运行。这背后的理念与互联网协议的成功类似。IP之所以能在上世纪70至80年代众多竞争协议中胜出，正是因为它是一个开放标准，构成了“沙漏模型”的窄腰，允许任何软件在其上运行，任何硬件在其下支持。这种开放性使得任何支持IP的设备都能轻松接入并成为互联网的一部分，从而推动了互联网的爆炸式增长。因此，公司坚信开放标准的力量，并支持围绕其建立开源生态。这种理念也体现在对TPU、GPU及其他加速器的全面支持上，确保整个生态系统的构建不是由任何单一供应商的封闭专有技术栈所主导。

人工智能技术对团队的日常工作，尤其是在硬件工程和数据中心设计方面，产生了哪些具体影响？

人工智能技术对团队工作的影响已超越软件工程领域，深入到硬件工程和数据中心设计等多个方面。在软件开发中，AI工具在提升编码能力、测试部署乃至辅助设计方面都取得了显著成效。而在硬件方面，数据显示，硬件工程师使用AI工具的频率（以token计算量为衡量标准）与软件工程师相当。这带来了生产力的显著提升，具体表现为从设计启动到芯片流片（tape out）的时间以及芯片启动所需的时间都在缩短。此外，在数据中心的设计和规划流程中，AI也带来了深刻变革。过去，评估建设1吉瓦的数据中心还是多个100或200兆瓦的园区这类决策，主要依赖于详细的、由人工驱动的电子表格分析。如今，虽然人类判断依然核心，但AI技术已大量融入，通过整合必要信息并将其清晰地呈现在决策者面前，极大地简化了规划和开发流程。目前AI主要扮演信息整合与辅助决策的角色，而非完全替代人类的推理判断。

轨道数据中心（Orbital Data Centers）这一概念的可行性如何，其背后的主要驱动因素和面临的挑战是什么？

轨道数据中心是一个公司正在积极探索的“登月计划”项目。其核心驱动力在于解决地球上能源生产的根本性制约。在太空中，由于没有大气衰减，太阳能的可用功率比地面高出约40%。更关键的是，在太阳同步轨道上，太阳能电池板能接收到阳光的覆盖率高达98%至100%，而地面上这一比例仅为28%至35%。综合这两个因素，太空中的可用太阳能是地面上的3到4倍，并且几乎可以全天候获取，从而基本消除了对电池储能的依赖。这为实现碳中和的巨大算力提供了可能。然而，挑战同样巨大。首先，太空中的散热比想象中更困难。其次，系统的可靠性和维修问题更为棘手，虽然并非无法解决，但修复工作（例如通过机器人）的难度远超地面。此外，数据传输将依赖自由空间光通信（Free Space Optics），需要激光器与接收器之间进行实时校准，而非传统的物理光纤连接。尽管存在这些挑战，但目前看来没有根本性的技术障碍。

展望未来十年，即到2036年，最前沿的超级计算机会呈现出怎样的形态？

预测2036年的超级计算机形态存在极大的不确定性，但可以预见其集成度将达到前所未有的水平。与当前通过大量光纤连接机柜的模式不同，未来的超级计算机可能会更加集成化。从机架层面看，2036年的机架将是高度集成的单元，可能仅有一小束光纤引出。一种可能的模块化制造模式是，这些机架在工厂集中制造，内部深度集成了数百个（例如576个或更多）GPU或TPU。单个机架的功耗可能达到数兆瓦。届时，数据中心的部署方式可能会变为将这样一个预制好的高密度机架运送到现场，然后只需接入水、电和光纤这三样东西，即可投入运行。至于届时是否会将这样的计算单元直接发射到太空，并通过空间站的机械臂进行部署，这也是一种值得畅想的可能性。