未来天玑|太空的“云”不是云： AWS和Azure为什么在轨道上做起了边缘计算

AWS把Snowcone搬上了国际空间站，Azure推动了太空地面站虚拟化，Loft Orbital则造出了一个在轨“应用商店”——星上计算平台正在成为新的太空基础设施。作者 | 老谭2021年，国际空间站上多了一个不起眼的设备——AWS Snowcone，一个手提箱大小的边缘计算节点。它没有传统航天设备那种复杂而昂贵的专用外形。它就是一个在亚马逊仓库里买了就能用的小盒子，外面贴着一张“通过振动和热循环测试才算通过”的标签。但它在400公里轨道上的出现，标志着一个重要的开始：云计算平台第一次进入了太空。从那时到2025年，空间节点上的计算平台发生了巨大变化。AWS、Azure、IBM、Loft Orbital、ESA——几乎每一家重要参与者都在建设自己的星上计算平台。但你必须问一个问题：在太空中，把几块GPU装在卫星上，调通网络，装个操作系统，就叫“太空云”了吗？并不是。在太空的边缘计算和地面的云计算是两回事。地面云的核心是多租户共享无限资源，而太空云的核心是有限的能源、极其有限的带宽、极端环境下的可靠性。它是边缘计算的极端版本。本文沿着“从地面云到太空云”的逻辑展开：为什么云计算巨头要上太空？Loft和Palantir如何设计“星载应用商店”？谁又在重新定义太空中的软件标准？一、云计算巨头的“登天”之旅先讲一个看起来平凡但意义深远的故事。2021年，AWS推出了一个叫AWS Ground Station的服务——租赁地面站的云服务。你不需要自己建地面站，不需要和卫星通信运营商谈判，只需要在AWS控制台里点击几下，就可以安排一次与卫星的通信窗口。2022年，Ground Station集成到了AWS Snow Family——包括放在国际空间站上的Snowcone。完整链路是：卫星拍照→星上Snowcone处理→通过地面站自动回传→进入AWS S3存储→触发Lambda函数处理。换句话说，从“卫星影像”到“分析报告”，客户不需要自己搭建任何一环硬件。这是云计算巨头的核心打法：不造卫星，不运营星座——但控制每一个数据流经的节点。在AWS的蓝图里，卫星只是“传感器”，地面站只是“管道”，真正有价值的是AWS上的数据处理和AI推理。你为AWS Ground Station付费、为S3付费、为Lambda付费——卫星本身只是一笔前期投资。微软Azure Space的路径类似但侧重点不同。Azure的Orbital地面站网络——2024年已在全球部署约20座天线——支持多个商业星座的直接接入。Azure的差异化在于：它与Planet Labs合作，让客户可以在Azure上直接获取、处理和调用Planet的卫星影像，把“遥感数据处理”进一步云服务化。这让卫星运营商面临一个两难：用Azure/AWS的服务，客户获取成本低、速度更快——但你的数据会经过别人的云。不用，你就得自己建地面站、自己维护网络、自己开发处理管线——整体成本会显著更高。这不是AWS在逼你，是规模效应带来的成本优势让“不加入云平台”变成了一个奢侈的选择。二、Loft Orbital：太空中的“应用商店”Loft Orbital可能是星上计算领域最具平台野心的公司之一。它的Cockpit平台本质上就是一个在轨“应用商店”——客户提交容器化应用（Docker镜像），Loft负责把它上传到卫星上运行。这意味着什么？不懂轨道力学、不懂卫星通信的软件开发团队，可以写一个在轨AI应用，像部署到AWS EC2一样部署到一颗真实的卫星上。Loft处理了所有“卫星基础设施”：电源、热控、通信、轨道保持。客户只需要关心自己的应用逻辑。2024年，Loft在Cockpit上运行了40多个客户应用。这些应用覆盖的范围从“在轨AI影像分析”到“遥感模型验证”，再到“空间天气监测”。应用的平均在轨运行时间约3个月——客户以“租用卫星算力”的方式付费。Cockpit的关键突破不在于它的技术有多么前沿——而在于它把“卫星”变成了一个可编程的平台。以前，卫星是“造好了就不能改”的定制硬件。Loft的设计让它变成了“随时可以上传新软件”的通用计算节点。
“我们不是在造一种卫星。我们是在造一个运行卫星软件的操作系统。区别就像造一台手机和设计iOS——前者是硬件，后者是生态。我们的目标是让太空软件开发者不需要理解什么是‘轨道’。”—— Loft Orbital CTO在一次技术分享中的表述
三、Palantir Foundry：太空数据的大脑Palantir的Foundry平台——原本是为金融、医疗、国防客户打造的数据融合与决策系统——正在变成“太空数据的大脑”。Foundry for Space的核心理念是：将来自不同卫星、不同传感器、不同格式的数据整合到一个统一的数字孪生模型中。在这个模型上，AI可以回答诸如“过去24小时中东地区的海上交通流量变化”或“北极冰盖边缘的位移速度是否加速”这样的问题。要回答这些问题，系统必须同时融合光学、SAR、气象和航运跟踪等多类数据，而这些数据又来自不同卫星系统、不同运营机构和不同数据格式。2024年，Palantir获得了英国国防部的1.7亿英镑合同，建立一个名为Combined Joint All-Domain Command and Control（CJADC2）的天基数据融合系统。简而言之：Palantir正在打造一个尽可能整合多源太空数据的“超级大脑”。Palantir的策略和AWS有本质区别：AWS提供“管道”（地面站+存储+算力），而Palantir提供“大脑”（数据融合+决策支持）。前者的竞争壁垒是规模和价格，后者的壁垒是数据集成能力和客户锁定效应——一旦你的业务逻辑在Foundry上跑起来了，迁移成本极高。四、ESA OPS-SAT：开源星上计算的实验场欧洲航天局的OPS-SAT项目，如今已由OPS-SAT VOLT继续推进，走了一条与商业公司完全不同的路：开源。OPS-SAT是一颗专为“软件实验”设计的3U立方星。它的星载计算机是通用的Zynq SoC（FPGA+ARM混合架构），可以运行任何实验者上传的代码。2022年至2024年间，来自全球50多个研究团队的80多项实验在OPS-SAT上运行——包括在轨云检测算法、卫星自主任务规划器、甚至一个围棋AI（作为计算能力基准测试）。OPS-SAT最重要的贡献不是某个具体实验的结果，而是它的“开放实验平台”模式。它证明了：卫星不一定是定制系统——通用计算平台+灵活的操作系统也能满足太空任务要求。OPS-SAT VOLT在此基础上进一步升级：更大的算力（四核ARM+FPGA）、更大的存储（128GB）、更灵活的通信协议（支持自定义调制方式）。ESA的这条路与Loft的商业路线形成了一种有趣的互补——Loft提供了“商业化的应用商店”，ESA提供了“学术化的开放实验平台”。两者的技术方向高度一致：卫星正在变成可编程的计算节点。五、OpenCOSMOS和KubOS：太空操作系统的新物种在硬件和云平台之外，还有一层基础软件正在发生革命性变化：航天器的操作系统。传统的卫星软件（如NASA的cFE/cFS、ESA的RTEMS）是20年前的设计范式——硬实时、静态内存分配、单线程或有限多线程。这使得在轨运行复杂AI应用变得极其困难——不是算力不够，而是软件栈不支持。OpenCOSMOS是一个开源项目，目标是为航天器提供更接近Linux生态的开发环境，让地面开发者能用熟悉的标准工具链编写和部署星上应用。KubOS走得更远：它尝试构建一套完整的“太空微服务架构”，把卫星的导航、通信、电源管理等子系统抽象为API。2024年，KubOS已被约10个商业卫星项目采用——虽然和传统航天软件的存量相比微不足道，但它代表了一个不可逆转的趋势：航天软件正在向地面软件开发范式靠拢。而人工智能是最大的推动力——只有当星上软件具备了类Linux的开发效率，AI的应用迭代才能跟上地面上的速度。· · ·从AWS Snowcone到Loft Cockpit，从Palantir Foundry到OPS-SAT，从OpenCOSMOS到KubOS——这些技术路径看起来各不相同，但它们指向同一件事：卫星正在从一个“专用通信设备”变成一个“通用计算节点”。当每一颗卫星都成为可编程的AI计算节点时，太空中的数据下传量有望大幅下降，天基信息服务的响应时间也可能从小时级进一步压缩到分钟级，卫星运营商将更接近于像管理云服务器群一样管理星座。但这一切的前提是——星上计算平台的标准化、商业化、规模化。而这背后是一笔巨大的经济账。下一篇文章，我们来算这笔账。

▶ 下篇预告：

星上计算的生意经

一个被低估的市场正在浮出水面——它未必是一个“太空云”市场，更像是一个“轨道边缘计算”市场，而两者的定价逻辑并不相同。

本专题系列：❶ 国外在干什么（本篇）→ ❷ 产业逻辑 → ❸ 中国启示

关联系列：

主系列《AI+商业航天》—国外案例/产业逻辑/中国启示子系列《星上AI芯片》—国外案例/产业逻辑/中国启示子系列《AI看地球》—国外案例/产业逻辑/中国启示子系列《AI管星与组网》—国外案例/产业逻辑/中国启示子系列《星上计算与数据平台》— 国外案例 / 产业逻辑 / 中国启示

Email

电话

太空的“云”不是云： AWS和Azure为什么在轨道上做起了边缘计算

最新动态

标签