谷歌 Project Suncatcher：Trillium TPU 从近地轨道发回首个 AI 回复

谷歌于 10 月 30 日证实，其 Project Suncatcher 原型卫星已完成调试流程，并从近地轨道发回了项目的首个 AI 生成回复：一首三行俳句，由运行在星载 Trillium 张量处理单元上的 Gemma 4 开放模型生成。这份由 Paradigms of Intelligence 高级总监 Travis Beals 发布在Google Research 博客上的公告，标志着谷歌所称的「Hello World」里程碑，证明数据中心级 AI 加速器可以在轨道上执行机器学习负载，并把结果传回地面。

结果本身是：Blue marble below / Data streams in silent grace / Starlight feeds my core（蔚蓝星球在下方 / 数据静静优雅流淌 / 星光滋养我的核心）。以任何计算标准衡量，这都不算什么。俳句是能想到的最小的实用 AI 输出之一。但这个里程碑的意义不在于模型写了什么，而在于写下它的硬件：一颗未经改动的 Trillium TPU，也就是谷歌部署在地面云数据中心的第六代 AI 加速器，在没有任何抗辐射加固的情况下，在太空的辐射和热环境中运行。

Trillium 如何在近地轨道运行，以及这些限制为何重要

Project Suncatcher 的原型卫星于 10 月 1 日搭乘 SpaceX 的 Transporter-18 拼车任务，从范登堡太空军基地发射升空。卫星与 Planet Labs 合作，采用现有卫星平台打造，携带四颗 Trillium 代 TPU 芯片，规格为标准的 Cloud TPU v6e-4 切片，与地面云客户可用的配置相同。卫星的太阳能电池板产生约 1 千瓦电力，这对运行构成了很大限制：一次只能运行一颗 TPU，而且热限制迫使每次过境运行约十五到二十分钟后关机，据项目的技术文档。

没有对流冷却，是区分轨道 AI 算力与地面运行的关键物理约束。在地球上，AI 数据中心依靠强制风冷或液冷从密集的芯片阵列带走热量。在太空真空中，热量只能通过辐射离开表面，经热管把热能传到朝向深空的散热板。谷歌称热管理是项目最关键的工程挑战之一。每次经过地面站窗口（这次测试使用了挪威斯瓦尔巴的 Kongsberg Satellite Services 设施）都会形成约十五分钟的窗口，工程师可以在卫星消失在地平线之前上传提示、在卫星上运行推理并下传回复。在这种架构下，实时对话交互在结构上就不可能，每次推理交换都受轨道力学的限制。

对供电架构的影响同样显著。部署在地球上 Google Cloud 集群中的 Trillium 芯片，运行在能持续为每颗芯片提供数百瓦电力的系统中。原型卫星 1 千瓦的太阳能预算由所有星上系统共享，TPU 只能短暂突发运行。谷歌的长期星座构想设想了大得多的太阳能阵列，但当前原型与生产规模轨道推理之间的工程差距很大。

通过辐射测试对这个领域到底证明了什么

Suncatcher 项目技术上更持久的贡献，可能不是这首俳句本身，而是项目团队发表的《Joule》期刊同行评审论文中的辐射特性结果。

传统太空计算依赖抗辐射 ASIC，这类芯片专门设计用于耐受轨道电离辐射环境，通常比性能前沿落后两到三代工艺，单位成本也高得多。Project Suncatcher 要回答的核心问题是：现代商用现成 AI 芯片能否取代抗辐射定制芯片，不是运行得完美无缺，而是运行得足够好，依靠纠错和恢复程序来处理瞬态故障。

谷歌发射前在加州大学戴维斯分校克罗克核实验室用 67 兆电子伏质子束进行的辐射测试发现，Trillium TPU 经受住了 15 千拉德的总电离剂量，是 650 公里高度近地轨道运行五年任务要求（750 拉德）的 20 倍。芯片的高带宽内存是对辐射最敏感的子系统，只有在超过 2 千拉德时才开始出现异常，仍是五年预算的 2.7 倍。对于单粒子效应（单个高能粒子引起的瞬态比特翻转），在轨道剂量率下，估计的静默数据损坏率约为每三百万次运算一次推理被损坏，对于非关键负载，这一水平可以通过应用层校验和管理。团队还指出，在束流测试期间就检测到一次静默数据损坏事件，这说明纠错码能处理大部分但不是全部的辐射引发错误，正如发射前辐射研究所证实的。

如果卫星计划一年任务中收集的在轨数据证实地面测试结果，就等于有效验证了：地面 AI 基础设施所用的同一套采购、认证和供应链，可以延伸到近地轨道，而无需单独的抗辐射芯片项目。这将消除分隔太空算力与地面算力的主要成本障碍之一。

Starcloud 抢先上轨：谷歌的 TPU 为这场竞赛带来了什么

谷歌的「首次」说法范围划得很谨慎，这种精确很重要。公司把 Suncatcher 的结果描述为「轨道上数据中心级 TPU 的首个 AI 回复」，而不是太空中进行的首次 AI 推理。

Starcloud 前身为 Lumen Orbit，获英伟达支持，于 2025 年 11 月 2 日在 Starcloud-1 演示星上搭载了一颗英伟达 H100 GPU，比谷歌的俳句早了近一年。Starcloud 在那次任务中用莎士比亚全集训练了 Andrej Karpathy 的 nanoGPT，然后在预装的 Gemma 模型上运行了推理。H100 同样是数据中心级芯片，这意味着谷歌「轨道上首款数据中心级 TPU」的说法在产品类别上准确，但并不是更广义的里程碑。

真正重要的竞争区别在于芯片架构。Starcloud 的轨道算力基于英伟达 GPU，未来还将基于英伟达 Vera Rubin Space-1 模块，该模块在 2026 年 3 月的 GTC 上发布，据称太空推理负载的单 GPU AI 算力是 H100 的 25 倍。谷歌的轨道算力基于自研 TPU 芯片，从芯片设计到模型再到卫星实现了 AI 技术栈的垂直整合，这与它在地面 AI 基础设施上的整合优势相同。Planet Labs 既是谷歌 Suncatcher 项目的卫星平台提供商，又作为英伟达太空计算合作伙伴服务于自身的地球成像业务，这家旧金山成像公司因此同时站在轨道 AI 基础设施版图的两边。

Axiom Space 代表第三种路径，它于 2026 年 1 月搭载 Kepler Communications 的 Tranche 1 光中继卫星，发射了两个轨道数据中心节点，专注于安全应用，而不是通用 AI 推理。

研究卫星与轨道数据中心之间目前的技术差距

10 月 30 日的里程碑回答了一个基础问题：Trillium 芯片能否在轨道上存活并产出有意义的结果？但留下了更长的一串问题。

这次测试只涉及推理。谷歌还没有展示在轨训练，而 Starcloud 在 2025 年 11 月就做到了。运行在轨道系统上的 Gemma 4 变体没有披露参数量，也没有公布在轨测试的延迟、吞吐量或 FLOPS 数据。每次过境的交互窗口以分钟计，而不是以小时计。一颗靠 1 千瓦太阳能间歇运行的 TPU，按任何合理定义都不是数据中心。

Suncatcher 路线图的下一个技术里程碑要苛刻得多：2027 年发射两颗搭载 TPU 的卫星，测试航天器之间的自由空间激光链路。星间光通信是未来任何轨道分布式计算集群的架构前提。谷歌的台架演示达到了每秒 1.6 太比特（实验室环境下收发器之间），但在实际轨道运行的指向约束、相对运动和热效应下验证这条链路，还是一个未解决的工程问题。如果不能证明星间链路，拟议中由 81 颗卫星组成的生产星座（在 650 公里太阳同步轨道上，卫星彼此相距约 1 公里）就无法作为分布式计算集群运行。因此，2027 年的双星任务是 Project Suncatcher 长期架构的决定性技术关口。

项目还面临当前原型无意解决的更长期挑战：在已很拥挤的太阳同步轨道层管理 81 颗卫星集群规模的轨道碎片，地面站链路的 FCC 和国际频率协调，以及 TPU 芯片超出辐射耐受余量后卫星更换的经济性。

谷歌的长期押注，以及它真正在问的基础设施问题

Project Suncatcher 起源于谷歌副总裁 Blaise Agüera y Arcas，他的 Paradigms of Intelligence 研究团队研究 AI 基础设施的长期问题。动机很简单：在地球上，AI 训练和推理的主要约束不是芯片性能，而是电力和土地。数据中心在集中的地理区域越来越激烈地争夺电网接入，AI 负载的电力需求预计将占可用供应的越来越大比例。太阳同步轨道上的卫星几乎持续受到太阳照射，效率约为地面太阳能电池板的八倍，没有大气吸收，也没有黑夜周期。

长期构想是一个由 81 颗卫星组成的集群，通过太比特级星间光链路相连，每颗卫星携带数十颗 TPU，合起来能靠太阳能运行拍字节规模的 AI 负载，这与目前运行的任何基础设施都是真正不同的范式。这种范式能否在经济上可行，取决于发射成本曲线继续下降、TPU 芯片在多年轨道任务中证明耐用、星间光链路在轨道条件下达到与地面光纤相当的带宽，以及热管理问题在规模上得到解决。

10 月 30 日从斯瓦尔巴上空传回的俳句没有回答这些问题。它回答的是：谷歌自家的 AI 芯片能否挺过发射、辐射和太空的温度剧变，并存活到产出有用结果。这是第一次在轨道上、用真实硬件而不是实验室模拟给出答案。答案是肯定的，而在一个靠里程碑推进的项目中，这正是必须最先得到的答案。