摘要：谷歌准备把TPU送进轨道，先检验AI硬件能不能在那里可靠工作。阳光更充足，冷却却未必更容易；卫星各自能计算，也不等于它们能组成高效机房。Project Suncatcher值得认真看一眼，因为它把AI算力背后那笔经常被忽略的工程账，摊到了太空里。

太空很冷，把发烫的AI芯片送上去，似乎顺便解决了散热。这个念头很诱人，也恰好错在最关键的一步：真空中没有空气替芯片把热带走。设备可以一边面对漆黑的宇宙，一边因为自身产生的热量而过热。

谷歌准备做的，正是这样一件听上去浪漫、拆开来却很费工夫的事。2026年9月24日，它更新了Project Suncatcher的进展：与Planet合作的原型卫星将搭乘SpaceX的Transporter-18任务，测试TPU在轨道环境中的表现。按这份官方公告，首次试验当时仍在发射准备阶段。

项目名字可以理解成“捕捉阳光”。它的长远想法，是让一群由太阳能供电的卫星承担AI计算。眼前要回答的则朴素得多：硬件上去以后，能不能正常运转，出了什么问题，下一颗卫星应该怎样改。

我赞成用小规模试验检验这种设想。只是评判它时，最好暂时把脑海中漂浮的巨大机房拿开。需要关注的，是一套计算系统换了环境之后，到底省下了什么，又新增了什么。

算力的扩张，先要等电接进来

我们谈AI时，最熟悉的是模型和芯片。模型能回答更复杂的问题，芯片能更快地完成计算，但装满芯片的服务器仍然需要持续供电。电送进设备，经过运算和配套系统，最终有很大一部分变成需要排走的热。机房选址因此绕不开电网、供电设备、冷却设施和建设周期。

国际能源署在2026年的更新报告中估计，全球数据中心用电量将从2025年的485太瓦时，增加到2030年的约950太瓦时；AI相关数据中心的用电增长更快。这里说的是全球数据中心的总量，不能全部算在聊天机器人头上，2030年的数字也仍是预测。

太瓦时不太直观：1太瓦时等于10亿度电。这个量级说明，算力扩张需要真正的电力基础设施配合。不过，全国一年能发出多少电，与某个园区能否按时获得足够容量，是两道题。服务器可以交付，变电设备和接入工程未必同时就绪。把总量够用理解成每个地方都能立即开机，会漏掉选址和交付中的实际难处。

太空的吸引力由此变得容易理解。在合适的轨道上，太阳能电池板有机会长时间接受日照，少受云层和地面昼夜变化影响。谷歌早期方案考虑的是晨昏太阳同步低轨道：可以粗略想象成沿着地球昼夜交界附近运行，让收集阳光这件事尽可能连续。项目研究介绍提出，在适当条件下，太阳能板的发电产出可能达到地面情形的数倍。

关键在“合适的轨道”和“整套系统”。不能随便发射一颗卫星，就默认它永远面对太阳；面板角度、遮挡、电能转换和设备退化仍要计算。多得到的太阳能，也要先扣除平台自身所需的供电与损耗，才能变成留给计算任务的电力。

而且，少用电池与完全不需要储能并不等价。哪怕平均能量充足，负载突然增加、系统切换或出现异常时，供电仍要稳住。机房不能因为今天阳光很好，就允许某个计算瞬间掉电。

搬上去的，是计算任务和一整套配套设施

Suncatcher并不是先在太空发电，再把电传回地面机房。按谷歌公布的研究方案，计算设备本身也上天：太阳能在轨道上转成电，电驱动芯片，数据通过通信链路传进来，处理结果再传出去。

TPU是谷歌面向机器学习计算设计的加速器。它适合高效执行模型中的大量数值运算，但一块TPU并不等于一台可以独立工作的卫星。内存保存数据，供电系统维持电压，控制系统管理任务，通信设备传递信息，热控系统处理废热，这些都得一起工作。

从地面服务器的角度看，问题在于很多原本可以借用的条件消失了。插上电源线的便利、机柜附近的网络、冷却系统和能够进场维修的人，在轨道上都需要换一种实现方式。卫星平台承担的任务，远不止把芯片托住。

这一关系也决定了它会优先适合什么工作。假设一项任务需要不断从地面读取巨大文件，算一小会儿就把同样庞大的结果送回来，通信很可能吃掉原本期待的收益。反过来，数据能够在系统内重复利用、计算时间较长、输出相对精简的任务，才更值得拿来比较。这里是从数据流推导出的任务选择思路，还不是谷歌已经公布的商业产品清单。

因此，“在太空跑过一次AI”和“太空适合承担大规模AI计算”，中间还有很长一段距离。前者证明路径可行，后者要证明整套配套设施值得为它建起来。

没有空气，热量得自己找到出口

地面的风扇之所以管用，是因为它推动空气流过散热器。热先从芯片传到金属结构，再交给流动的空气；液冷则先用液体把热搬走，之后仍要把它交给外部环境。冷却系统的任务，是持续安排热量的去处。

到了真空，外部空气这条路没有了。设备内部仍能通过固体导热，也可以通过热管或流体回路搬运热量，但要把热排向外部空间，主要得靠辐射。散热面板向外发出红外辐射，把能量带走。NASA的小型航天器热控资料解释了这种环境下的传热约束。

可以把热管理解成运货的道路，把散热面理解成出口。把道路拓宽，能减少热在芯片附近堆积；出口本身吞吐不足，热最终还是排不出去。这也是为什么“装一套液冷”并不能独立回答太空机房的散热问题：液体把热搬到了哪里，那里又怎样把它排走，必须接着问。

散热能力与面板面积、表面性质和温度有关。增大面积通常有帮助，却会增加质量、展开机构和结构负担。让散热面更热，也有助于向外辐射能量，但芯片、连接材料和冷却系统都存在温度限制，不能把工作温度无限抬高。

面板朝哪儿同样重要。朝向太阳或受到地球辐射影响时，它也可能吸收外来的热。因此，一颗卫星上的太阳能板想尽量迎向阳光，散热结构却要考虑怎样减少不必要的受热。两个目标要靠布局和姿态协调，不能各画一张漂亮示意图就算完成设计。

谷歌在9月的介绍中提到热管与散热器的组合，并已在热真空环境中做测试。真正的在轨运行，会把供电变化、计算负载和姿态条件放在一起考验。这一步最有价值的数据，未必是某次跑出了多高的性能，而可能是持续工作一段时间之后，温度还能否保持在允许范围内。

这也是我对“太空天然冷却”保持保留的原因。冷的是远处的辐射环境，热的是眼前持续用电的设备；把两者连起来，才是工程师要完成的工作。

芯片没有坏，不代表算出来的东西都对

硬件先要经历发射。机房里的板卡通常不需要跟着火箭承受强振动，连接件、封装和安装结构在这里都要重新接受检验。谷歌已经对原型做了多轴振动测试，但地面试验通过之后，仍需要在实际任务中确认表现。

进了轨道，辐射带来的麻烦更加隐蔽。带电粒子可能在电子元件中留下电荷，使存储状态改变；原本的一个0变成1，就可能成为数据错误。有些影响短暂且可以恢复，有些可能导致更严重的中断甚至损伤。欧洲航天局对空间辐射影响的说明，区分了这些不同后果。

理解测试结果时，需要分清长期累积损伤与单次粒子事件。设备承受了一定累积剂量之后还可以工作，并不等于每次计算都没有错误，更不等于所有配套器件都拥有相同表现。一个总量指标，不能代替完整的可靠性评估。

谷歌先前用质子束测试了Trillium TPU，得到了一些积极结果。这样的结果支持继续做在轨试验，但不会自动给出一份五年稳定运行的保证。轨道、屏蔽条件、器件组合和真实负载，都会改变最终需要面对的情况。

对AI系统来说，能够识别并处理错误尤其重要。如果计算中断，系统能否从保存的状态恢复？如果某个节点退出，其他节点是否可以继续承担任务？如果结果出错，能不能被发现，而不是把一个看似正常的答案交给下游？这些是评估方案时应追问的问题，不能因为模型平时就可能回答不准，就对硬件造成的额外错误放松要求。

地面运维人员可以拔下坏板卡，轨道上的设备通常没有这种随叫随到的维修条件。某个原本只需换件的小故障，有可能变成整颗卫星在剩余寿命里的计算损失。可靠性在这里也会直接进入成本表。

卫星彼此能说话，离组成机房还有一段距离

大模型的计算经常需要许多加速器合作。任务拆开后，各部分要交换数据，有些阶段还要等待其他部分完成。如果计算很快，交换数据却很慢，昂贵的芯片就会花时间等消息。把更多芯片发射上去，并不能自动消除这种等待。

地面集群可以用高速连线把设备连接起来；卫星之间没有固定机架和电缆，谷歌考虑的是激光互联。激光能够传输数据，但要把光准确送进接收端，两颗运动中的卫星必须掌握相对位置，并维持足够稳定的指向。

谷歌的早期研究介绍给出过一个实验室结果：一对收发器实现了每个方向800Gbps的传输。这个数字很有参考价值，但它描述的是台架演示；不能把两个方向相加后写成单向速度，也不能把它当作已经完成的在轨集群性能。未来系统设想需要的链路能力，比单个演示结果还要往前走。

为了让高速光链路更容易实现，卫星距离也进入设计：距离更近，接收端通常更容易获得足够信号；但紧密编队又要求更精细的位置管理。计算、通信和轨道安排开始互相牵制。它们不能由三个团队各自优化完，再简单拼在一起。

这里还有两条不同的“路”。星间链路负责轨道节点之间的数据交换；星地链路负责把地面的数据送进去、把结果带回来。前者做得好，不代表后者的容量、可用时段和任务调度自然解决。普通用户的一次请求，是否值得经过这整套路径，也要看实际服务的延迟要求。

我更愿意把这类系统看成一组需要共同设计的计算设备。它的强项应该来自任务、硬件和通信安排彼此合适，而不是来自“位置在太空”这个标签。

---

阳光不收费，整套服务仍然要算账

在地面建设数据中心，要付电费、设备费、场地和维护成本。移到轨道上，有些支出可能减少，另外一些则变得显眼：卫星制造、发射、展开机构、通信终端、轨道维持、冗余设计和寿命结束后的处置，都需要资源。

谷歌研究中的发射成本分析，讨论过到2030年代中期降至每公斤200美元以下的可能情形。这个价格是远期推演中的条件，不能拿来给眼下的一颗卫星直接报价；论文把发射开支按设备寿命和供电能力摊开，与地面机房的能源支出比较；卫星制造、全部运维和计算硬件的成本，并不会因此自动包含在内。读这种模型时，先看假设比先看结论更有用。

比如，一套硬件花了同样的钱送上天，能可靠工作五年和只能工作一年，分摊到每小时的成本当然不同。即使它没有损坏，如果大部分时间在等待数据、处理温度限制或恢复中断，真正交付的计算量也会减少。用额定性能乘以时间来估算收入，容易把这些空档全部忽略。

衡量成本时，更有意义的分母是“真正完成、结果可信、可以交付的计算任务”。太阳能板产生了多少电、装了多少芯片、链路峰值有多快，都只是影响这个分母的中间因素。它们各自亮眼，仍有可能组合出一套利用率不高的系统。

可以做一个不涉及具体报价的比较：地面方案每天都能稳定完成任务，轨道方案电能更充足，却经常因为通信或热控降低负载。此时只比较两边的电价，得出的判断就可能完全相反。只有把实际任务放进去测试，才能知道哪个环节值得继续投入。

轨道资源也不能看作无限免费的空地。卫星需要避让、协调运行，并安排退役后的处置。欧洲航天局的空间环境报告持续讨论这类运行与碎片问题。对于未来可能扩大规模的计算星座，这些内容应当出现在设计起点，而不是等设备失效以后再补上一章。

所以，现阶段很难认真断言太空算力一定更便宜，或者一定没有经济价值。更合理的态度，是把它当作一条需要用工程数据逐步缩小不确定性的路线。地面的电网、芯片效率和冷却技术也在进步，它要比较的对象不会停在今天。

下一步，值得等待的是哪些结果

把时间线摊开，会更容易读懂后续消息。项目在2025年公布研究设想；2026年9月更新的是首次原型在轨试验的准备情况；2027年的双星任务则计划继续验证光学互联等能力。早期合作说明也可在Planet的项目介绍中查看。这些阶段承担不同任务，不能合并成一个商业数据中心上线日期。

对首次原型，我会优先看真实负载下的温度变化、错误出现的方式，以及恢复之后还能保留多少有效工作。到双星协同时，再看连接能否持续、数据交换是否拖慢计算、故障会不会传到其他节点。等这些问题逐渐有答案，规模和成本的讨论才会有更扎实的基础。

一次试验暴露出温度、连接或恢复机制的问题，也未必意味着它白做了。工程探索最怕的，是一直用理想条件估算完整系统，却迟迟不知道哪项假设最脆弱。原型的用处，就是把这些未知变成能够测量、能够修改的具体问题。

Project Suncatcher目前最值得关注的地方，是它准备让AI硬件真正接受轨道环境的检验。等第一批数据回来，那个“免费阳光”的想法才会开始拥有更完整的账本：每多获得一份能量，要付出多少重量、散热面积、通信能力和维护代价。

如果最终有一类任务在那里算得更稳定、更划算，这条路线就找到了起点。在那之前，一颗卫星能否持续、正确地把任务算完，比一幅宏大的太空机房效果图更能说明问题。

#谷歌# #太空算力# #AI数据中心#