Google 太空数据中心已进入轨道，但规模化仍需 1,800 次 Starship 发射

10 月 1 日，Google 将四枚 AI 芯片送入轨道，标志着其太空数据中心项目走出研究论文阶段。然而，这项实验也暴露出一个更大的矛盾：Google 的经济模型假设 SpaceX 能在十年内完成约 1,800 次 Starship 飞行。

按每次任务运载 200 公吨计算，这意味着每年约需发射 180 次。就在 Google 卫星发射前几天，Starship 才首次进入地球轨道。因此，Google 设想的经济模型要成立，SpaceX 必须先将一枚仍在开发中的火箭转变为工业化运输网络。

这颗小型卫星并不能回答这个问题。它测试的是 Google 的 Tensor Processing Units，即 TPU，能否承受辐射、发射振动和极端温度变化。任务还将评估这些芯片能否在缺少地面数据中心常见空气冷却条件的情况下运行。

Google 将这项更广泛的计划称为 Project Suncatcher。其拟议系统是在低地球轨道部署由太阳能驱动的计算卫星，并通过光链路将它们连接起来。其吸引力在于充足的太阳能，但实际障碍包括发射成本、散热、通信、维护和轨道协调。

SpaceX 既是该计划不可或缺的供应商，也是最棘手的依赖因素。Google 可以自行改进芯片、软件和卫星设计，却无法在没有发射服务商以前所未有的规模实现复用的前提下，创造低成本的轨道运输能力。

Google 太空数据中心从四枚芯片起步，而非轨道云

Google 发射的是一项硬件实验，而不是地面数据中心的可用替代方案。

首艘 Project Suncatcher 航天器名为 MVP，通过 SpaceX 的 Transporter-18 拼车任务从加州发射。据一份轨道任务概览称，Falcon 9 搭载它以及另外 129 个载荷升空。

该卫星由 Google 与地球观测公司 Planet 合作打造。Google 提供了包括四枚 TPU 在内的计算硬件。TPU 是 Google 为机器学习训练和推理开发的定制加速器。

这艘体积约如冰箱大小的航天器可从太阳能板获得约一千瓦电力。与商业 AI 设施的需求相比，这一供电能力微不足道。大型地面系统通常使用数千枚加速器，并配备大规模网络、存储、冷却和电力设备。

MVP 将运行 Gemini 工作负载，以测试硬件在轨道中的表现。据报道，该卫星的处理器每次可运行约 15 分钟，随后必须暂停以释放积聚的热量。这种运行模式使其更像一台科学仪器，而非持续可用的计算服务。

这项任务加快了 Google 原有的时间表。该公司此前曾介绍，计划与 Planet 在 2027 年初开展双卫星学习任务。将芯片整合到现有的 Planet 航天器中，使 Google 能更早收集轨道数据。

Google 表示，卫星将评估发射造成的物理应力，以及太空中的热环境和辐射条件。这些测量结果应能为工程师提供地面模拟无法完全复现的证据。

这一差异很重要，因为“太空数据中心”一词可能让人联想到能运行客户工作负载的成熟设施。MVP 更接近一间紧凑型实验室，其任务是在 Google 投入更大规模的卫星架构前识别故障模式。

不过，这次发射改变了 Project Suncatcher 的状态。该项目现在拥有经受真实轨道环境考验的硬件，而不再仅依赖模拟。这些证据可能确认原有假设、揭示意外故障，或迫使 Google 重新设计系统。

这项测试也恰逢 SpaceX 的重要时刻。Starship 于 9 月 28 日首次进入地球轨道，随后部署了 26 颗 Starlink 卫星。上面级损失了一台发动机并提前返回，但任务仍证明了一项必要能力。

Google 的卫星并未搭乘 Starship，而是由 Falcon 9 执行发射。不过，Falcon 9 不具备 Google 预计完整轨道计算网络所需的载荷经济性和容积能力。

因此，这项小型实验立刻指向一个更大的基础设施问题。四枚芯片可以搭乘一次拼车任务，但承载密集计算系统的数千颗卫星，需要完全不同的发射运营体系。

为什么 Project Suncatcher 需要 Starship 的经济性

Project Suncatcher 的基础是通过重复飞行、复用和巨大的累计载荷规模降低发射价格。

Google 的研究估计，到 2030 年代中期，低地球轨道运输成本可能接近每公斤 200 美元。这一估算基于学习曲线，参考了 SpaceX 的历史发射价格和累计载荷质量。

学习曲线将制造经验与单位成本下降联系起来。Google 的研究人员估计，每当 SpaceX 的累计发射质量翻倍时，其每公斤价格便下降约 20%。

将这一模式延伸至 Starship，会得出该项目最引人注目的数字：SpaceX 需要向轨道额外运送约 37 万公吨载荷，才能维持假定的成本下降轨迹。

按每次任务 200 公吨计算，这相当于约 1,800 次 Starship 发射。若在十年内平均完成，要求便是每年约 180 次任务。早期年份的次数很可能低于这一平均水平，迫使后期运营进一步加速。

这些数字来自 Google 的轨道计算论文。研究人员强调，他们的工作并非完整的经济可行性研究，而是说明要让发射价格不再主导商业论证，需要发生哪些条件。

每公斤 200 美元的门槛之所以重要，是因为 Google 将轨道运输成本与地面数据中心持续产生的能源开支进行比较。在这一发射价格下，高效卫星经寿命调整后的运输成本可能进入地面电力成本的大致区间。

这种比较存在局限。它未包含决定实际服务能否具备竞争力的多项开支：卫星必须经过设计、制造、投保、运营、连接，通过冗余实现维修能力，并最终予以替换。

论文还假设，历史价格改善趋势能够跨越飞行器设计的重大变化而延续。Falcon 9 与 Starship 并不共享相同的生产体系、运营模式或风险特征。根据早期火箭得出的趋势，无法保证 Starship 未来的表现。

Google 的分析承认了这种不确定性。报告称，该估算取决于高频复用、累计运输量、技术执行、市场竞争和监管条件。因此，价格预测是一项有条件的结果，而非正式商业报价。

公司还研究了一条低运量路径。如果载荷增长比核心估计低约 70%，发射价格仍可能降至每公斤约 300 美元。即使未达到完整的 1,800 次发射情景，这一结果也可能改善轨道经济性。

然而，单靠更低的发射价格无法创造需求。SpaceX 需要拥有足够载荷的客户，以填满反复执行的 Starship 任务。轨道计算可能成为这样的客户之一，但前提是低成本发射首先让这些计算系统变得可行。

这形成了一种循环依赖。太空数据中心需要低成本发射能力才能扩大规模；Starship 则需要巨大的发射需求，才能沿着预测的成本曲线下降。

Google 并非只是等待更便宜的火箭。Project Suncatcher 本身可能提供让这些火箭进一步降价所需的一部分载荷。这样的可能性使 Google 与 SpaceX 形成相互依赖的关系，而非传统的供应商合同关系。

因此，发射次数不只是一个吸睛的统计数字。它是将四芯片实验与未来轨道网络经济性连接起来的机制。

Google 与发射频率现实之间的较量

核心对手不是另一家云服务商，而是 SpaceX 的发射雄心与每年 180 次实际运营频率之间的差距。

Starship 的首次入轨飞行是一项重要里程碑，但一次成功入轨与每年运营数百次截然不同。SpaceX 必须安全地重复发射、复用飞行器两个级段、减少翻修工作，并维持多个发射场。

9 月的任务体现了这一差距。Starship 成功部署了载荷，但一台上面级发动机停止工作。SpaceX 还缩短了原计划的飞行，并在约三小时后让飞行器返回。

开发飞行的目的就是暴露问题。一台发动机出现问题并不会否定飞行器或 Google 的研究，但它说明了为何不能仅凭载荷能力推断可靠的发射频率。

每年飞行 180 次，平均下来接近每两天发射一次。这个平均数还必须计入检查、载荷整合、天气延误、监管审批、发射台维护及异常响应所需的时间。

这一数字还假设每次飞行都能运送 200 公吨。实际载荷取决于飞行器构型、目标轨道、回收方案和任务要求。若平均载荷更低，则需要更多次发射才能运送相同的累计质量。

SpaceX 曾描述过远高于此的长期飞行频率。Elon Musk 曾谈及最终让 Starship 每年飞行数千次。这类说法表明了公司的雄心，但并不能证明这一运营体系已经存在。

近期进展确实增强了 Starship 可成为商业运载火箭的可能性。其轨道任务部署了 26 颗 Starlink V3 卫星，助推器则在海岸附近完成模拟着陆。SpaceX 正围绕快速复用而非一次性硬件开发该飞行器。

Starlink 为 SpaceX 提供了内部需求来源。公司可以在改进 Starship 运营的同时发射自有通信卫星。这种垂直整合曾帮助 Falcon 9 积累飞行经验，也可能支撑 Starship 的早期发射频率。

轨道数据中心会提出不同的要求。计算卫星搭载热管理硬件、大型太阳能阵列、光通信设备和昂贵的处理器。它们必须进入精确的轨道编队，而非只是加入宽带星座。

Google 同时也是 SpaceX 的投资者，这使双方部分利益保持一致。但投资并不能消除技术依赖。Google 的时间表仍取决于一套既非其设计、也不受其控制的运输系统。

其他发射服务商最终可能降低这种风险敞口。Blue Origin、Rocket Lab 和未来的重型发射竞争者可能推动价格走低。但目前没有任何一家提供经验证、可匹配 Starship 预期载荷规模与完全复用组合的替代方案。

Falcon 9 依然可靠，适合用于原型验证，但 Google 的模型指出，其运量限制使其不适合大规模部署。这造成了一个尴尬的过渡期：现有火箭可以测试这一想法，而尚未完成的火箭必须让它具备经济性。

最初，1,800 次发射的估算在来源标题和 URL 中被误写为 1,600 次。已发布的更正确认，论文中的数字为 1,800 次。

这一更正很重要，因为它进一步凸显了挑战的规模。额外增加的 200 次发射，按所需的平均发射频率计算，意味着超过一年的工作量。

决定性证据将来自实际运营，而非预测。SpaceX 必须证明更短的周转时间、可重复使用的飞行器、可靠的载荷交付能力，以及不断扩展的发射场容量。在此之前，Google 的成本曲线仍只是一个技术上合理的情景设想。

一个由 81 颗卫星组成的 AI 集群必须像一台计算机一样运行

廉价运输只解决了第一个问题，因为分布式 AI 还需要精确的编队飞行和数据中心级通信。

Google 提议的架构采用由 81 颗卫星组成的集群。一个示例集群将在平均约 650 公里的高度运行，并被限制在半径一公里的范围内。

卫星之间与邻近伙伴保持大约 100 至 200 米的间距。在每艘航天器以轨道速度绕地球飞行时，这种几何布局必须保持稳定。

机器学习工作负载涉及加速器之间的频繁数据交换。训练大型模型要求处理器以低延迟同步数据和中间结果。缓慢或不稳定的连接可能让昂贵的芯片等待信息。

地面数据中心通过光纤和专用交换机解决这一问题。Project Suncatcher 则以自由空间光链路取代这些固定连接，通过精确指向的激光束传输数据。

Google 在短距离实验室路径上演示了单向 800 千兆比特每秒的传输速率。双向容量达到 1.6 太比特每秒。这项测试支持其底层通信概念，但并未复现完整的移动轨道编队。

真实星座必须在卫星改变位置时准确指向多束光束。系统还必须应对振动、温度变化、组件老化、轨道碎片规避，以及集群内部的故障。

Google 提议利用机器学习模型协助预测轨道运动并控制编队。这种方法或许能让相邻卫星保持在通信范围内，但也为本已复杂的物理系统增加了软件保障要求。

地面连接构成另一项限制。星间带宽并不能消除在地球与轨道之间传输输入和输出的需求。大气湍流、云层、光束跟踪和地面站可用性都可能限制光通信。

某些工作负载比其他工作负载更适合这种架构。处理已经在轨道上采集的数据，可以减少传回地球的数据量。卫星图像分析就是一个明显例子，因为原始信息产生在处理器附近。

大规模地面训练任务则面临更严峻的情况。其数据集可能源自地面存储系统。上传这些材料、协调数千个处理器并取回输出，可能抵消充足太阳能带来的部分优势。

推理工作负载或许更容易适应。推理是指运行已训练模型以生成答案、分类或预测。这类任务可能比长期训练运行规模更小，对同步的要求也更低。

Google 的辐射测试支持了这一差异。其研究人员称，Trillium TPU 经受了相当于五年任务周期的电离辐射剂量后，仍未发生永久性故障。不过，高能粒子仍可能造成暂时性的计算错误。

一名研究人员告诉 TechCrunch，典型推理任务大约每百万次操作会遇到一次错误。当数千枚芯片协调一次持续数月的训练运行时，同样的错误率就更令人担忧。

软件可以检测并重做部分错误计算。冗余处理器也可以替代失效的容量。这两种应对方式都会消耗能源、硬件或时间，从而削弱经济可行性。

因此，拟议中的集群并非只是放置在地球上空的一排服务器。它是一台分布式超级计算机，其网络、电力供应、冷却系统和物理布局始终处于运动之中。

从系统层面看，Project Suncatcher 与其说是将传统云区域迁往太空，不如说是围绕轨道力学的约束设计一个全新的计算平台。

冷却与维修可能令商业模式难以成立

最棘手的风险仍然是散热和维护，因为太空提供阳光，却不提供空气、水或技术人员。

太阳能是 Project Suncatcher 最具吸引力之处。Google 表示，处于合适近地轨道的卫星所能接收的太阳能，最高可达地球上相似地点面板所获能量的八倍。

获取阳光可避开一些地面电网限制。新的地面数据中心可能要等待数年，才能获得输电升级、发电协议、许可和地方批准。轨道系统则可在处理器旁直接发电。

但进入芯片的电力最终都会转化为热量。在地球上，设施借助空气、水、制冷剂、泵、冷却塔和热交换器转移这些热量。真空中没有空气可以带走热量。

航天器必须将热量从处理器传导至散热器。这些表面以红外辐射的形式释放能量。所需面积会随产生的热量以及硬件可承受的温度而增长。

Google 的 MVP 突显了这一限制。其四枚芯片只能短暂运行，之后系统便会暂停以进行冷却。从 15 分钟实验扩展到持续的商业运营，需要更大或更高效的热管理硬件。

散热器会增加质量和表面积。更大的质量会提高发射需求，而更大的结构则令部署和避碰更加复杂。当工程师使用防护屏蔽来应对辐射时，也会带来同样的代价。

一项独立的热评估指出，多项轨道计算提案都面临这种权衡。传统 AI 加速器具备所需性能，但其设计目标并非用作抗辐射航天器组件。

为芯片增加屏蔽会增加重量。让它们暴露在外则会提高错误和潜在故障的风险。冗余硬件能够提升可靠性，但将备用处理器送入轨道又会再次增加质量、电力和冷却需求。

维护同样毫不宽容。技术人员会定期在地面设施中更换失效的硬盘、网络设备、电源和加速器板卡。轨道集群无法依赖常规的人类维修访问。

Google 的论文提出，将冗余配置作为最简单的应对措施。这意味着发射超过系统初始需求的容量，然后绕过故障运行。

冗余能够让服务持续运行，但也会改变利用率。备用硬件仍承担制造和发射成本，部分组件可能会一直闲置，直至其他组件发生故障。

卫星寿命带来另一项限制。Google 评估了五年内的辐射暴露。地面设施可以分阶段更换处理器，而一颗卫星可能将计算、电力、冷却和通信封装为一项寿命有限的资产。

快速的 AI 硬件迭代让这种模式更复杂。一颗搭载当前处理器发射的卫星，可能在辐射终结其任务之前很久，就已经不如更新的地面芯片高效。替换它需要再次发射，而不是更换服务器。

旧设备离轨也必须成为系统设计的一部分。只有当失效单元能够安全离开轨道时，81 颗卫星组成的集群才具有可管理性。大规模部署会放大碰撞和碎片风险。

这些问题并不能证明轨道计算不可能实现。它们表明，一次成功的芯片测试为何无法验证商业服务。Google 必须长期测量错误率、持续热性能、电力可用性和组件老化情况。

MVP 任务的价值恰恰在于，失败也能提供信息。现在发现温度限制或辐射模式的成本，低于在部署完整集群后才发现这些问题。

Google 的公开表述依然保持恰当审慎。其 Project Suncatcher 更新将该卫星称为初步测试，并将冷却列为关键研究挑战。

这种克制使该研究计划区别于有关近期轨道云容量的更激进说法。测试提供了证据，但尚未证明持续工作负载、有竞争力的成本或可部署的维护策略。

三个信号将决定太空计算能否扩展

下一步证据必须将一次成功实验与可重复的计算、可复用发射，以及超越单颗卫星的可信路径连接起来。

第一个信号是 MVP 的持续运行数据。Google 需要披露 TPU 的运行频率、热量积累速度，以及辐射如何影响推理准确性。

成功的短时运行将确认传统加速器可以在轨道上工作。具备可预测冷却过程的更长时间运行，则会提供更有力的证据。频繁停机或无法解释的错误将削弱高密度轨道集群的可行性。

读者还应关注 Google 是否会公布 Gemini 推理结果，而不只是硬件健康状况测量。能运行的芯片必不可少，但有用的工作负载性能才是更有意义的里程碑。

第二个信号是 Google 计划中多卫星任务的进展。两艘或更多航天器可以测试单颗卫星无法复现的光链路、协调能力和分布式工作负载。

Google 此前计划在 2027 年初与 Planet 共同发射两颗原型卫星。任何更新后的时间表、设计或任务目标，都将显示 MVP 的经验如何影响该计划。

多卫星演示应揭示连接稳定性、光束跟踪精度，以及轨道运动对工作负载协调的影响。这些测量将开始把 Project Suncatcher 作为一个系统进行测试。

第三个信号是 Starship 的实际发射频率和复用纪录。当 SpaceX 多次使用回收硬件执行飞行、缩短周转时间并扩大载荷运营能力时，Google 的经济模型就会更具可信度。

一次轨道任务无法确立成本曲线。一系列可靠的商业飞行才能提供相关证据。两级火箭的复用比达成另一个孤立的飞行里程碑更重要。

载荷能力也必须从设计目标转变为实际运行性能。Google 的 1,800 次发射计算假设每次飞行可运载 200 公吨。若实际验证的运载能力更低，所需任务数量也会随之变化。

这些信号应被结合起来评估。更好的芯片无法弥补无法负担的运输成本。廉价运输无法带走处理器产生的热量。强大的冷却能力也无法创造分布式训练所需的带宽。

竞争对手将提供有价值的比较。SpaceX 已提出自己的轨道计算网络，而 Starcloud 和其他初创公司正在测试不同架构。它们的结果可以揭示 Google 的集群设计是否异常保守或乐观。

早期商业用途也可能不同于 Google 最宏大的愿景。太空原生处理——包括在传输前分析传感器或图像数据——所需的地面带宽更少，因此是一个更可信的起步市场。

面向地球用户的通用云计算则面临更严格的要求。客户期待可靠访问、可预测的延迟、安全的数据处理、快速的硬件更换，以及明确的服务级别保障。轨道基础设施必须在持续移动中满足这些期望。

最重要的结论并不是 Google 恰好需要 1,800 次发射。这个数字来自一个模型，其假设会随着 Starship、卫星设计和市场的发展而变化。

它的重要性在于揭示了什么：Google 的太空数据中心需要一个工业体系，涵盖火箭、航天器工厂、光学网络、热工程、自主运行和 AI 硬件。

Project Suncatcher 现已开始测试这条链条中的一个环节。这颗卫星能够帮助 Google 判断其芯片是否能承受真实的太空环境，但无法决定 SpaceX 是否能实现每年数百次发射。

这项实验值得关注，因为它将一个推测性的想法转变为可衡量的工程项目。它也让人更难忽视仍需跨越的距离。

关注 Google 从 MVP 中披露的信息、多卫星任务是否按计划推进，以及 Starship 执行可重复使用商业任务的频率。这三个信号将表明轨道 AI 正在成为基础设施，还是仍停留在雄心勃勃的研究项目阶段。