谷歌把 TPU 送上天：4 颗芯片、1 千瓦电、一次 15 分钟，太空数据中心这笔账怎么算

10 月 30 日，Sundar Pichai 在 X 上发了一条不太像产品发布的帖：谷歌的 Project Suncatcher 原型卫星，在轨跑通了第一次 AI 推理。地面站把一句提示词打上去，星上的 Gemma 4 在 TPU 上算完，卫星飞越挪威斯瓦尔巴地面站时，把一首俳句传了回来。

诗是这样写的：

Blue marble below / Data streams in silent grace / Starlight feeds my core.
（下方是蓝色弹珠，数据无声流淌，星光喂养我的核心。）

谷歌自己给这次测试的定性很克制：非常初步。但这条新闻值得认真看，因为它第一次把「太空数据中心」从 PPT 拽到了参数表上——而参数表才是判断一个技术叙事真假的地方。

一、那条链路到底通了什么

先把时间线摆清楚。

这颗卫星 10 月 1 日搭 SpaceX 的 Transporter-18 拼车任务上天，猎鹰 9 号从加州范登堡起飞。卫星由谷歌和 Planet 合作研制，只有冰箱大小，运行在太阳同步轨道上。轨道选得很巧：让太阳翼几乎不进入阴影，所以不必背一块沉重的电池。

入轨后三周，团队按清单一项项做 commissioning：先给主机和 TPU 托盘上电，再做早期机器学习测试，然后才轮到真正的推理。10 月 30 日那次过境，他们上行第一句 prompt，要求模型写一首关于太空的俳句；卫星飞出地面站视野前，结果已经下行完毕。

更有工程意义的是第二个测试：让模型读取载荷系统的遥测数据，用自然语言报告技术状态。前者证明「能生成文本」，后者证明「能在轨道上读取结构化状态并总结」——这是未来卫星自诊断的雏形。

所以这次验证的不是「AI 很聪明」，而是「发射—供电—计算—下行」这条最短链路是通的。谷歌的说法很老实：一次成功的推理，不等于一套可用的太空数据中心。

二、参数表：1 千瓦能支撑什么样的 AI

把关键数字列出来，判断会清楚很多：

1 千瓦是什么概念？家用吹风机 1 到 2 千瓦；一张高端 GPU 单卡功耗就可能到 700 瓦至 1 千瓦。换句话说，这颗卫星的全部电力，大致只够稳定供一张顶级加速卡，或者让 4 颗 TPU 分时、降频地跑。

这就决定了它的产品形态：不是云服务器，而是间歇性推理节点。这个区别很关键，后面会讲它对普通开发者有什么用。

三、三张表：功率、散热、带宽

任何「把算力搬到某处」的方案，都要过这三关。太空只是把约束推到了极端。这套算法你可以直接套到手机、车机、树莓派、边缘盒子上。

第一张，功率表。

P_总 = n × P_单芯片 + P_通信 + P_热控

按这颗星的量级估：4 颗 TPU 若每颗峰值 200 瓦，就是 800 瓦；通信与热控泵再吃掉 200 瓦，刚好压在 1 千瓦的预算上。所以「4 颗」不是性能指标，是电力预算除出来的结果。

第二张，散热表。

地面机房有风扇、冷水、冷板；真空里没有空气对流，热量只能靠辐射往外扔。辐射散热功率约等于：

P = ε × σ × A × (T⁴ − T_环境⁴)

取发射率 0.9、散热板温度 320 K、深空环境 4 K，代进去大约 535 瓦每平方米。要排掉 1 千瓦，需要接近 2 平方米的双面散热板。散热板又是当前任务里最重的部件之一——重量直接换成发射费，还影响姿态控制。这就是为什么单次只能跑十几分钟：不是芯片不行，是热排不出去。

第三张，带宽表。

单次过境窗口按 10 分钟、有效下行 10 Gbps 估，一次能传 750 GB 左右。传推理结果、日志、遥测，绰绰有余；但一个百亿参数级模型按 FP8 存，权重就有上百 GB，一次窗口勉强够推一次更新。所以太空节点的模型迭代频率，会被地面站窗口卡住。

三张表填完，结论自然出来：太空适合「数据在那边产生、结果才需要回来」的场景，不适合「模型天天换、请求随时来」的通用云。

四、那为什么还要上天

因为账的另一头也在变。

太阳同步晨昏轨道上，同一块太阳能板的发电能力最高能到地面的 8 倍，而且「燃料」免费、不用占地、不抢淡水、环评压力小。谷歌研究论文里给过一个更具体的门槛：如果发射价格在 2030 年代中期降到每公斤 200 美元以下，太空数据中心的发射加运营成本，有望在「每千瓦·年」的口径上和地面机房的能源成本大致打平。

但门槛有多高，看另一个数字就知道：TechCrunch 报道，谷歌估算星舰大约需要 1600 次发射，才可能把成本打到有竞争力的水平。

项目负责人 Travis Beals 的说法更直接：看不出未来五年内太空会比地面便宜，应该需要更长时间；很长一段时间里，两者会共存。卡内基梅隆的 Brandon Lucia 则提醒，把更多计算塞进卫星，意味着更多热量要排进受限空间，而在轨系统的维护成本与复杂度会被放大 10 倍甚至 100 倍——所以必须有足够大的回报。

同一赛道已经有人抢跑：Starcloud 去年 11 月发射了搭载英伟达 H100 的航天器，在太空演示过 Gemini；SpaceX 在提交给 SEC 的文件里说，最早 2028 年开始部署在轨 AI 计算卫星。

五、对普通开发者真正有用的三件事

第一，把「算力会断」当成默认假设。

太空节点一次只能跑十几分钟，逼着系统必须能断点续跑。这个能力在地面的移动端、边缘设备、灾备场景同样值钱。最小实现就三件事：任务分片、状态落盘、结果幂等。

import json, pathlib

CKPT = pathlib.Path("ckpt.json")

def load():
    return json.loads(CKPT.read_text()) if CKPT.exists() else {"done": [], "out": []}

def run(chunks, step):
    st = load()
    for i, c in enumerate(chunks):
        if i in st["done"]:
            continue
        st["out"].append(step(c))
        st["done"].append(i)
        CKPT.write_text(json.dumps(st))   # 每片落盘，进程随时可被杀
    return st["out"]

关键不在代码，在约定：每一步都可重入，结果按 id 幂等写入。这样进程被杀、电断了、网掉了，重跑只补没做完的那部分。

第二，用三张表给任何边缘方案做体检。

不用真的算卫星。你要做一个离线翻译笔、一个车载语音助手、一个工厂质检盒子，同样问三个问题：功耗预算多少瓦？散热面积多少平方厘米？模型多久更新一次、通道有多宽？三个答案里最紧的那个，决定你的模型能有多大。很多人上来就选最大的模型，最后卡在散热上。

第三，小模型加好工程，比大模型加烂工程更能落地。

Gemma 4 能在 1 千瓦的星上跑起来，本身就是「小模型 + 好工程」的证明。量化、蒸馏、稀疏化、控制激活参数，这些手段在太空是生死线，在手机和边缘盒子上是成本线。

六、写在最后

三句话记住这件事。

一首俳句证明不了太空数据中心可行，但它证明了那条链路是通的，剩下的全是「不性感」的工程题。

短期看，这是 10 到 20 年尺度的研究项目，不是明年的风口；真正的机会在散热材料、辐射加固、星间激光、卫星图像在轨处理这些「卖铲子」的环节。

对写代码的人来说，最该抄走的不是「卫星」这个概念，而是它拆问题的方式：先验证供电，再验证推理，再验证遥测，最后才谈互联。任何跳过约束表的宏大叙事，都还停在 PPT 上。