SpaceX 是 Apple。现在需要有人把 Android 做出来。

五个月内出现的两句话，定义了我们正处在什么时刻。

2026 年 2 月 4 日，Elon Musk 在一场有 John Collison 与 Dwarkesh Patel 参与的访谈中说："36 个月内，甚至可能更接近 30 个月，把 AI 放到太空将成为经济上最有吸引力的选择。五年后，我的预测是，我们每年在太空发射并运行的 AI 算力，将超过地球上累计运行的 AI 算力。"^[1]

2026 年 5 月 5 日，Jensen Huang 在拉斯维加斯 ServiceNow 大会上说，agentic AI 所需的计算量大约是生成式 AI 的 1,000 倍。他的表述很明确：全球每年原本在经典计算基础设施上花费约 3,000-4,000 亿美元，而 AI 的需求倍数意味着接下来的基础设施建设不是增量扩容。"世界需要的 token 生成能力，远不止 7,000 亿美元，"Huang 说，"而且我相当确信，从现在开始，我们会持续生成 token，也会持续投资算力容量。"^[2]

这两句话并不是两个彼此独立的事件。它们说的是同一件事，只是高度不同。Jensen 描述的是地球表面的基础设施需求已经膨胀到难以低成本满足；Musk 描述的是部分解决方案最终可能去哪里。

但两人都没有正面回答随后出现的治理问题：谁来控制这一层基础设施？以什么条件控制？

本文从这个问题开始。

作者说明：本文是观点与分析文章。Musk 关于轨道 AI 的时间线是他的预测，其历史时间表记录并不稳定。Jensen Huang 的 1,000 倍说法来自媒体直接引述；部分报道写作"1,000 percent"（严格说是 10 倍），部分报道写作"1,000 times"（1,000 倍）。无论采用哪一种读法，本文的方向性判断都成立。第六部分的蓝图应被视为参考架构，而非供应商采购建议。

---

这里所说的 Space Android 是什么

先做一个定义。本文使用的 "Space Android" 是一个具体的技术与治理概念，不只是一个修辞比喻。

Space Android 不是：

• 开源火箭
• SpaceX 的廉价复制品
• 某个国家的卫星星座
• 泛泛的在轨 GPU 云
• 消费级卫星互联网替代品

Space Android 是：

• 标准化载荷接口
• 轨道计算运行时
• 面向开发者开放的任务 API
• 跨卫星平台供应商的多硬件兼容性
• 让开发者无需理解卫星工程也能构建应用的生态
• 能被不同地缘区域政府与企业信任的治理层

Apple/Android 的类比之所以成立，恰恰因为 Android 的价值不在硬件，而在抽象层。Android 让任何开发者都可以在不理解底层硅片的情况下构建应用。本文要问的是：轨道计算是否已经出现了等价的抽象层？如果没有，它需要怎样被建造出来？

---

第一部分：SpaceX 是 Apple，而这正是问题所在

行业已经在使用这个类比

2023 年 5 月，DigiTimes 报道称，台湾卫星零部件供应商呼吁建立一个 "Android-like ecosystem"，以对抗 SpaceX 明确被描述为 "Apple-like strategy" 的封闭策略。^[3] 三年后，这个框架几乎已经成为商业航天行业的共识。

这个类比是对的。更少被讨论的是，它对在一些令人不舒服的地方也同样成立。

Apple 的垂直整合之所以有效，是因为 Apple 控制体验。从 iOS 的每个像素到 M 系列芯片的每个纳米，Apple 都尽量自己掌握，因为它相信（而且多数时候是正确地相信）只要关键决策外包，体验就会下降。结果是：用户愿意支付溢价，供应链依赖 Apple 甚于 Apple 依赖供应链，而竞争者永远追赶一个不断移动的目标。

SpaceX 在另一个市场、以另一套底层逻辑完成了同样的事情。数据已经说明问题：在商业发射服务商中，SpaceX 承担了超过 90% 的入轨质量。Falcon 9 的 LEO 单公斤成本约 2,700 美元，而几年前的替代方案通常仍在 10,000 美元以上。^[4] 支撑这一点的是极深的垂直整合：Merlin 与 Raptor 发动机内部研发，航电自研，Starlink 卫星在 Redmond 规模化制造，用户终端从天线阵列到底层芯片都由 SpaceX 团队设计。Falcon 9 助推器从回收再到复飞的纪录已经压到 72 天；如果任何关键子系统依赖外部供应商，这种节奏几乎不可想象。^[5]

Starlink 把闭环补上了。SpaceX 用自己的火箭发射自己的卫星，用自己的硬件服务自己的客户，再用这些收入资助下一代火箭与更多卫星。这不是供应链，而是一个封闭热力学系统。

Apple 类比真正预示的 SpaceX 脆弱性

Apple 的竞争壁垒是生态锁定：iOS、App Store、iCloud、M 系列芯片。切换成本真实且很高。SpaceX 的竞争优势主要是成本领先，而不是生态锁定。如果有竞争者在成本与可靠性上达到相近水平，SpaceX 的市场位置会比 Apple 更可争夺。

轨道计算的拐点会放大锁定风险。当被竞争的基础设施不再只是火箭，而是轨道上的 AI 算力时，SpaceX+xAI 的潜在垂直栈会同时覆盖发射层、轨道硬件层、芯片制造层与 AI 应用层。通用计算历史上从未真正面对过这种基础设施集中度。

企业与政府客户的价值排序不同于消费者：它们要冗余、供应链主权，以及当地缘环境变化时切换供应商的能力。它们不为优雅支付溢价，而为韧性支付溢价。Space Android 的竞争空间就在这里：不是在成本上正面击败 SpaceX 飞轮，而是在开放性与治理可信度上形成替代。

---

第二部分：轨道计算命题

电力问题是真的

Musk 在 2026 年 2 月的说法值得认真分析，不取决于他的时间表是否准确。他的物理判断在方向上是成立的。

在 2026 年 3 月 Austin 的一场活动上，Musk 的核心论点是电力密度："在地球上，你受到电力约束。太空的优势是永远有太阳。"^[6] 太阳同步轨道上的卫星可获得约 1.4 kW/m² 的无遮挡太阳辐照。地面数据中心正在面对真实的电力约束：Jensen Huang 提到，一个 500 MW 数据中心如今需要 30,000 卡车设备，还需要单独配套电站；四大云厂商据报已为 2026 年承诺超过 7,100 亿美元 AI 基础设施 capex。^[7]

电力约束是真的。轨道部署是否以及何时成为经济上可行的解决方案，则仍然存在高度不确定性。

散热问题也是真的

轨道散热不是免费冷却。这个问题必须说清楚。

真空没有大气对流，因此废热只能通过热辐射排出。Stefan-Boltzmann 定律决定了辐射功率与辐射面积、温度、发射率之间的关系。以一个运行 20W GPU 载荷的 12U CubeSat 为例，可用辐射面积大约只有 0.02 平方米。这个数字只是量级估算，真实工程值取决于轨道、姿态、材料、涂层和内部热路径。在典型工作温度下，这会把有效散热能力压到个位数瓦级，形成非常紧的热预算。

要扩展到吉瓦级轨道数据中心，就需要大面积可展开散热器。SpaceX 2026 年 3 月公开的轨道数据中心示意图中，散热阵列的尺度明显大于计算模块本身。^[6] 这不意味着轨道计算不可行，而意味着热工程是时间线与经济性的一阶约束。太阳能优势是真的；热优势只有在大规模散热器部署被解决后才成立。

Musk 的 30 个月判断应如何放置

"你们可以记住我的话，36 个月内，甚至可能更接近 30 个月，把 AI 放到太空将成为经济上最有吸引力的选择，"Musk 在 2026 年 2 月说。^[1] 这是他的预测。他过去关于 Starship、完全自动驾驶、火星殖民和其他项目的时间表，通常会晚 2-5 年。

据报道，Google 内部分析认为，发射成本需要降至约 200 美元/kg，轨道数据中心才可能与地面设施达到经济性平价。^[8] 如果 Starship 按设计推进，其成本轨迹可能在 2028-2030 年接近这一区间。轨道计算不是必然命运，而是第一次值得严肃建模的基础设施情景。这才是合适的置信度。

SpaceX+xAI 的战略背景

包括 Fortune 与 TechCrunch 在内的多家媒体报道称，SpaceX 与 xAI 已在 2026 年 1 月完成正式公司层面的组合，把 SpaceX 的发射与卫星基础设施同 xAI 的 AI 能力放进同一实体。^[9] 在 2026 年 3 月 Austin 活动上，Musk 描述了 Terafab 项目：每年生产 1 TW 处理器，相当于当前所有先进 AI 芯片制造商总产能的 50 倍。

如果这个垂直栈按描述建立起来，即芯片制造、发射、轨道卫星与 AI 应用合并到同一个结构中，它会成为通用计算基础设施史上前所未有的集中。问题不再是 SpaceX 是否赢得了发射竞争。它已经赢了。问题是下一场竞争，也就是轨道计算基础设施，会不会产生同样的结果，还是计算的平台经济会迫使行业形成另一种结构。

---

第三部分：竞争者都在玩错游戏

Rocket Lab 仍在 SpaceX 的框架内竞争

Rocket Lab 的路径很好地说明了大多数 SpaceX 竞争者面对的战略难题。

它从小型发射服务商起步，扩展到航天器制造（Photon 卫星平台）、通过收购进入卫星组件，并正在开发中型运载火箭 Neutron。其 2025 年年报显示收入 6.02 亿美元、订单积压 18.5 亿美元、完成 21 次任务。^[10] 这是扎实执行。

战略难题不在执行质量，而在方向。公平地说，Rocket Lab 的 Photon 平台确实有标准化载荷接口，Rocket Lab 也服务那些需要一体化发射与卫星服务、SpaceX 不愿提供定制整合的客户。这是真实差异化。但垂直整合的逻辑，即为了降低外部依赖而把更多能力内建，仍意味着竞争框架是 SpaceX 定义的。在一个可能永远无法达到 SpaceX 发射节奏的成本结构里，主要在 SpaceX 的框架内竞争，会限制可寻址市场。更有意思的问题是：哪些能力存在于 SpaceX 框架之外？

Blue Origin 是更昂贵的问题

Blue Origin 的 New Glenn 与 SpaceX Falcon 9 覆盖部分重叠但不完全相同的市场，New Glenn 是更重型的火箭。但外界报道的成本差距说明了另一种开发路径：它没有受益于 SpaceX 多年快速商业迭代带来的工程学习。^[11] Blue Origin 对国家安全发射客户有真实作用，因为这些客户不能完全依赖单一供应商。但它不是在构建另一个范式。

Terran Orbital 是警示

Terran Orbital（NYSE: LLAP）曾宣称 85% 内部制造，但持续出现数千万美元级季度亏损，展示了缺乏发射节奏飞轮时，垂直整合的边界。^[12] 如果没有证明其经济性的系统，垂直整合只是昂贵制造。

OneWeb 这个例外证明了规则

OneWeb 的供应链策略，是开放太空架构最重要的实践先例。

它没有选择把生产全部内建，而是通过欧洲与亚洲的区域二级组件制造商建立分布式供应链，在专门设施进行子组件制造，并在专用工厂完成总装。^[13] 结果是：供应商生态具备真实能力，成本结构对单点失败更有韧性，并向组件制造商发出一个市场信号：SpaceX 封闭采购体系之外，也存在规模订单。

台湾卫星零部件行业 2023 年呼吁建立 "Android-like ecosystem"，部分就是对这一点的回应：SpaceX 几乎不向外部买关键组件，因为它内部生产。OneWeb 创造了真正的供应链机会。缺失的是供应链之上的平台层：聚合需求、标准化载荷接口，并让轨道硬件环境变得可被应用开发者使用。

---

第四部分：Space Android 已经开始在计算层成形

真正的问题不是硬件

当人们说 Space Android 时，本能反应通常是想到硬件：标准卫星平台、开源航电、通用机械接口。这些在组件层当然重要，但不是理解平台机会的正确框架。

Android 不是因为它是一套开放手机硬件规范而胜出。Android 胜出，是因为它是一套开放软件平台，让任何硬件厂商都可以制造设备，也让任何开发者都可以在不了解底层芯片的情况下构建应用。价值在抽象层和应用生态，而不在硅片。

在太空中，等价物是计算与应用接口：你能否把软件载荷部署到一个标准化轨道计算环境里，而不需要理解卫星工程？一句话测试就是：能否用一个标准 API 调用，把 container 部署到轨道计算节点？

这正是 Loft Orbital 的 Hub+Cockpit+Hub Compute 架构正在指向的方向。

Loft Orbital：平台候选者

Loft Orbital 的模式值得比现在多得多的分析关注，因为它是商业航天中第一个真正平台原生的业务。

Hub 是标准物理与电气接口，让任何客户载荷都可以接入兼容卫星平台，不需要定制总线级集成。Cockpit 是浏览器化任务控制界面，让载荷运营者不需要拥有专门地面站团队也可以指挥硬件。Hub Compute 于 2025 年 12 月在 YAM-9 上首次在轨演示，是一个多节点异构计算环境，允许多个 AI 应用同时运行在共享轨道平台上。^[14]

Loft 像 AWS，是在抽象方式上像，而不是规模上像。它不开发应用，而是提供别人开发应用的平台。它的合作伙伴，包括做野火检测的 SkyServe、做海事态势感知的 Little Place Labs、做高光谱成像的 Wyvern、做防务 AI 的 Helsing，都是生态参与者，而不是子公司。2025 年 1.7 亿欧元融资说明这个模型不是纯理论，而是已经能获得市场验证。^[15]

但 Loft 还不是 2006 年的 AWS。它更像 2008 年的 Android Open Source Project：架构方向正确，开发者工具仍早，生态还很小，商业经济性需要尚未形成的规模。Android 类比之所以有用，正是因为 Android 早期也处于这种架构正确与商业脆弱并存的阶段。

Kepler Communications：网络层

Kepler 的光学数据中继网络提供星间光通信：高带宽、且中继链路不需要频谱许可。其商业模式不止于中继：Kepler 销售和出租部署在中继卫星上的边缘计算硬件，在关键轨道位置形成分布式计算节点。^[16]

Axiom Space 为计划中的轨道数据中心采购 Kepler 在轨计算载荷，是生态开始运转的第一个具体案例：一个平台公司从基础设施供应商购买计算容量，再部署到服务应用开发者的资产中。三层抽象已经在早期、受约束的规模上出现。^[17]

DARPA Blackjack 蓝图

DARPA 的 Blackjack 项目，是政府层面对开放太空架构在载荷层如何落地的第一套严肃规格：商品化卫星平台加低成本、可互换载荷，单颗成本目标低于 600 万美元。它的任务是一套军事情报星座，由商业可得卫星平台组装，能随着威胁环境变化刷新传感器，并能在数周内补网。^[18]

Blackjack 留下了两个长期产物：一套标准化载荷接口可能如何设计的规格，以及政府客户愿意为开放架构星座付费的证明。Space Development Agency 的 Proliferated Warfighter Space Architecture（PWSA）是其商业规模化实现：多供应商卫星平台采购、标准接口、每一层都有多供应商竞争。PWSA 正在创造商业 Space Android 具备经济可行性的市场条件。

Amazon Leo 的 Kuiper 截止期揭示了什么

Amazon Leo（原 Project Kuiper）值得关注，不是因为它正在建什么，而是因为它承受着什么压力。

Amazon 的 FCC 许可要求其在 2026 年 7 月 30 日前部署至少 1,618 颗卫星，也就是 Amazon Leo 星座的一半。截至 2026 年 4 月，公开追踪数据估计 Amazon Leo 在轨约 239-302 颗卫星。^[19] 这意味着 Amazon 必须在大约三个月内再发射数百颗卫星，否则可能面对 FCC 对其许可的行动；考虑到发射清单约束，这是极其紧的时间线。

这是 LEO 宽带市场里唯一资本充足的 SpaceX 替代者所面对的生死级执行约束。Amazon 的混合路径，包括自研 Prometheus 芯片、AWS 云集成、多发射商采购，在 2026 年仍承受如此巨大压力，恰好说明了在依赖外部发射服务时，想要对抗 SpaceX 闭环成本结构有多难。Amazon Leo 可能成功。但 FCC 截止期压力测试，本身就是一个关于在 SpaceX 飞轮之外建设大规模轨道基础设施有多难的真实数据点。

---

第五部分：Space Android 的经济学

为什么计算不同于通信

据市场研究，围绕星载计算、边缘计算与云计算的广义空间计算市场年规模约 1,080 亿美元，并将以约 15% CAGR 增长至 2035 年 3,000 亿美元左右。^[20] 需要强调的是，这些数字覆盖的是广义 "space computing"，包括传统卫星在板控制和地面侧数据处理，并不等于 Space Android 这种通用轨道计算平台可捕获的收入。Loft/Kepler 式开放平台能拿到的比例很可能更小，市场规模应作为方向性判断使用。

更有意思的是尚不存在的可寻址市场：那些如果有标准化轨道计算平台且成本合理就可行、但今天因为需要 2,000-5,000 万美元和 2-3 年建专用卫星而无法成立的应用。一个开放平台如果把门槛降到 100-300 万美元和 6 个月，就会创造当前无法形成的市场。

AWS 的类比在这里很重要。AWS 2006 年推出时，企业计算市场已经存在。改变的是参与经济学。创业公司可以用每月几百美元部署服务器容量，而不是内部花数百万美元建设。结果不是在既有市场里拿更大份额，而是大量原本因成本底线过高而不存在的应用突然出现。

关键限定是：轨道计算不会复制地面云计算。它的独特价值在于那些"连续全球传感访问 + 低延迟处理"能产生地面下传处理无法实现结果的应用。野火检测，几分钟可能决定响应成败。面向发展中国家海警的海事态势感知，不要求昂贵地面基础设施。超出蜂窝覆盖的自主系统边缘推理。这些是真实场景。至于"用轨道计算在价格上与 AWS 竞争通用 AI 工作负载"，短期不是场景；它依赖尚未实现的 Starship 经济性。

Musk 的自我矛盾

如果太空真的在 30 个月内成为 AI 最具经济吸引力的部署地点，而 SpaceX+xAI 同时控制发射层、轨道硬件层、芯片制造层和 AI 应用层，那么这个实体就控制了全球 AI 经济底层基础设施的垄断入口。

这会给每个政府、hyperscaler 和大型企业制造最强激励：支持替代方案。Amazon 建 Amazon Leo，部分原因就是不希望 Starlink 成为 AWS 客户默认基础设施。法国和英国政府持有 OneWeb/Eutelsat 股份，作为主权对冲。中国正在建立自己的轨道计算栈。这些单独看都不是 Space Android，但合在一起，就是 Space Android 需要围绕其成形的需求信号。

中国对 Android 命题的贡献

中国的轨道计算雄心，既是 Space Android 市场机会的最强证据，也是建错版本会发生什么的最清楚案例。

国星宇航已有 27 颗在轨卫星，其中 21 颗搭载 AI 处理载荷，并提出"星算计划"，目标部署 2,800 颗 AI 推理硬件卫星。^[21] 之江实验室合作项目在 2025 年部署了 12 颗计算卫星，聚合算力 5 POPS，星间激光通信 100 Gbps，并以 1,000 POPS 为目标。^[22]

轨道辰光在 2024 年末由北京研究机构孵化，瞄准晨昏轨道吉瓦级太空数据中心，并获得 12 家银行 577 亿元人民币战略授信意向。正如本站此前分析，这个数字的信号价值大于金融确定性。^[23]

截至目前，这些中国项目公开可见的架构更像垂直管理的国家基础设施，而不是面向开发者的开放平台。这不意味着它会永远如此；轨道辰光也描述过开放接入轨道算力的愿景。但按当前结构，如果中国轨道计算建设仍是封闭国家栈，它更像中国版 Apple，而不是对 Space Android 的贡献。

---

第六部分：Space Android 的参考架构

本节描述的是一套基于当前可用开源组件与商业硬件的实践路线。它应被视为参考架构：方向性指导，而非供应商采购建议。成本估算是粗量级，未包含集成、测试、监管合规、保险、发射部署器费用、载荷安全审查和运营团队等成本；这些都可能显著改变真实任务经济性。

三层架构

• Layer 0：Kernel —— 具备开放接口的标准化卫星硬件。
• Layer 1：OS —— 抽象硬件复杂性、提供标准 API 的软件栈。
• Layer 2：Application Interface —— 面向开发者的工具，让部署不再需要卫星工程专业背景。

Layer 0：Kernel

不要自己造卫星平台。 市场上已经有多个高质量标准化平台：

• GomSpace NanoPower P31u（6U）：丹麦供应商，广泛采用，电气接口规范相对开放。
• EnduroSat 6U/12U：保加利亚供应商，COTS 哲学强，成本较低，载荷连接标准有文档。对非美国运营方而言，可在卫星平台层面降低 ITAR 复杂度。
• ISIS Space CubeSat platforms：荷兰供应商，标准 6U/12U 框架，有大量学术任务 heritage。
• York Space S-class bus：美国供应商，ESPA 级平台，明确面向多载荷任务，有 DARPA Blackjack 背景。

在板计算当前有三类选择：

• Unibap iDPU-15：瑞典产品，抗辐射容忍，基于 NVIDIA Jetson Xavier NX，AI 推理约 21 TOPS。已有多次在轨演示，是目前最成熟的商用太空 GPU 模块之一。
• Mercury Systems VPX：美国产品，受 ITAR 控制，性能最高，面向政府相邻任务，支持加固形态的 NVIDIA A100 级 GPU。
• Kubos Major Tom / NanoAvionics M6P：较低成本通用计算，适合不需要 AI 专用推理芯片的应用。

热工程：一颗 12U 平台如果搭载 iDPU-15 并在太阳同步轨道满载运行，实际热管理需要仔细 duty cycling，并可能需要可展开散热板支持持续高算力负载。热仿真是一阶设计步骤，不是后期补丁。前文 0.02 平方米辐射面积估算只是示意；真实热性能取决于轨道几何、姿态、涂层、材料与内部热路径。没有可信热分析，任何轨道计算部署都不应进入执行。

物理接口：使用 The Aerospace Corporation 的 Slingshot "Handle" specification，即一种被描述为 "space USB" 的载荷连接设计，支持即插即用载荷识别与配置。^[24]

内部通信：使用 SpaceWire（ECSS-E-ST-50-12C） 作为高速内部数据通信标准。这是 ESA 标准，并有可用于 FPGA 实现的 IP core。

粗量级成本：一颗搭载 Unibap iDPU-15 的 12U CubeSat，集成与测试前硬件成本约 30-50 万美元。SpaceX Transporter 到 SSO 的 rideshare 价格为 6,000 美元/kg，12U 发射成本约 5-12 万美元。包含第一年运营的总任务成本可方向性估计为 100-300 万美元，但前述集成、监管、保险和运营成本可能显著推高实际预算。

Layer 1：OS

飞行软件：使用 NASA JPL 的 F'（F Prime），Apache 2.0 许可，GitHub 可用。F Prime 已在多项 NASA 任务上飞行，包括 Mars Helicopter Ingenuity。它提供载荷同平台驱动的隔离、兼容 CCSDS 的命令与遥测框架，以及地面系统接口。

关键架构说明：轨道软件不是地面云软件。辐射导致的 bit flip、存储损坏、高延迟与间歇连接、电力调度约束、确定性故障恢复、安全/使能命令授权、watchdog 架构，以及飞行关键总线隔离，都是地面系统没有的要求。Layer 2 面向开发者的抽象可以看起来 cloud-native，但 Layer 1 的飞行侧实现必须是受约束、可安全边界化、确定性强的运行时，而不是漂浮在轨道上的通用 Kubernetes 集群。Container 隔离与编排在 Layer 2 可以是一种开发者体验抽象；其下必须有更坚固、容错的执行基座，K3s 单独不够。

卫星以太网：使用 The Aerospace Corporation 的 SatCat5，MIT 许可、可部署在 FPGA 上，并已在 Slingshot 1 上进行在轨演示。^[25] SatCat5 可在 SpaceWire 与 UART 链路上传输标准 Ethernet frames，使任何带 Ethernet 接口的设备都能接入卫星内部网络。

容器化：在 iDPU-15 的 Linux 环境中运行 payload 应用 Docker containers，并由 K3s（轻量 Kubernetes）管理。K3s control plane 在地面运行，K3s agents 在轨道计算节点运行。载荷运营者用标准 kubectl 命令部署工作负载。这个模型适用于同飞行关键平台操作隔离的非安全关键载荷应用，不应被用于平台控制或任务关键功能。

地面控制：使用 NASA Ames 的 OpenMCT（Open Mission Control Technologies），Apache 2.0 许可。遥测使用 CCSDS Space Packet Protocol（SPP），文件传输使用 CFDP。

地面站接入按运营复杂度可分三类：

• AWS Ground Station：1.50-3.00 美元/接触分钟，全球分布，直接接入 AWS 计算。适合数据密集型任务。
• Azure Orbital：类似模式，接入 Azure。
• SatNOGS：开源全球网络，非商业用途免费，吞吐有限，但非常适合遥测收集。

Layer 2：Application Interface

Orbital Container Registry（OCR）：使用开源 CNCF 毕业项目 Harbor 构建。增加校验层，检查计算需求、功率包络合规性，以及标准输入/输出接口声明。

Orbital Scheduler：基于 K3s，通过自定义 node labels 标注轨道属性。读取 Celestrak GP element sets 计算节点位置，并据此做工作负载放置。

数据接口标准：地球观测应用使用 Cloud-Optimized GeoTIFF（COG） 作为影像格式，使用 SpatioTemporal Asset Catalog（STAC） 做元数据。非影像传感数据使用标准 JSON schema，包含 UTC 时间戳、传感器类型、地理位置、数据载荷与质量指标。

Ground API：使用 FastAPI（Python 开源），以 OpenAPI 3.0 文档化。认证使用 JWT，授权范围绑定到单个 payload deployment。

商业模式现实检查

这个平台的经济性很难，必须诚实面对。

一颗搭载 iDPU-15 的 12U 卫星，如果以 40% 平均利用率服务多个客户载荷，并按 1 美元/compute-hour 收费，每年计算收入约 87,000 美元。相比之下，每颗卫星年运营成本可能在 20-50 万美元之间，包括地面站接触、人员和轨道运营。这远低于盈亏平衡。若扩展到 20 颗卫星、60% 利用率、1.50 美元/compute-hour，年收入约 240 万美元；在研发摊销和卫星替换成本前，才接近盈亏平衡。

重点不是说这个模型已经被证明可行。相反，这些数字说明它在早期规模并不可行。重点是它需要什么条件才可行：更多卫星带来覆盖连续性，任务价值应用带来更高利用率，以及按任务结果而非算力小时转售来定价。

早期收入必须来自政府演示合同和愿意为任务结果付费的战略客户：野火检测响应能力、海警海事态势感知、灾害响应影像，而不是通用云 GPU 经济学。这个平台达到经济可行性的路径与 AWS 类似：聚合许多早期任务客户的需求，再用规模降低单位基础设施成本。

这就是为什么 Loft Orbital 需要 1.7 亿欧元。它是基础设施业务，在规模形成前单位经济性很难成立。开放标准的论点正在于此：把需求跨多个运营商聚合起来，而不是让每个参与者都建自己的封闭栈，才是达到规模的路径。

最快获得首批客户的三条路径

路径 A：政府环境监测

美国、澳大利亚、加拿大、欧盟的国家森林与灾害响应机构在野火检测、洪水监测上大量购买卫星数据。在轨处理能把活动火点的发现时间从小时缩短到分钟，这有直接运营价值。

关键问题是：应用是否真的需要在轨处理？对活动野火检测，是。对可接受 2-3 小时延迟的农业监测，不是。早期演示任务必须严格选择那些轨道延迟降低能产生明确价值的场景。

目标：同国家森林服务或海警签署技术演示合同。收入：20-50 万美元。合作模式：平台提供基础设施，伙伴提供应用软件（SkyServe 的 STORM 平台是自然候选），客户为任务结果付费。

路径 B：海事态势感知

东南亚、西非和南美的海警与海军，对船舶追踪、非法捕鱼检测、港口监测有显著需求，但缺乏建设专用卫星项目的预算。AIS 数据结合光学影像，如果在轨处理后再下传，可以以合理成本形成有意义监测。

目标客户：菲律宾海警、尼日利亚海事管理局、智利海军。采购路径：国防武官关系与多边开发银行海事安全项目。

路径 C：科研与大学开发者 grants

向高校和初创公司的 AI 研究者提供 1-5 万美元 compute grants，条件是发表结果并开源轨道 AI 模型。公开结果成为案例。潜在资助伙伴包括 ESA Phi-Lab、NASA In-Space Validation of Earth Science Technologies、Airbus Ventures。

---

第七部分：谁应该建？在哪里建？

缺失的组织形式

如果 Space Android 没有被建出来，默认结果就是 SpaceX+xAI 的垂直栈成为轨道 AI 基础设施的事实定义者。这不是消费电子市场份额问题。iPhone 的封闭生态可以接受，因为你可以买 Samsung。如果没有 Space Android，轨道 AI 基础设施就没有 Samsung；只有一个实体控制全球 AI 经济的物理层。

建立中立平台层的实体，需要同时满足几个条件：技术上足够可信，开发者愿意信任其运行时；资本来源之间没有彼此抵消的利益；治理结构能防止单一国家利益长期主导；政治位置能让多个主要地区的政府愿意参与。

这不是美国防务承包商、中国国资关联企业或欧洲国家冠军能单独锚定的公司。它们各自带来错误的政治画像。

地理位置及其真实约束

新加坡是中立轨道平台层较可信的注册地之一。理由是结构性的：法治环境足以让国际交易对手信任，能同时连接东亚与西方资本，物理上连接两侧供应链，并且有长期承载多方竞争利益共用基础设施的经验。

这个判断同本站此前关于主权可部署性的分析相连。解释 Singtel 选择 Mistral AI、新加坡海事连接选择 OneWeb 的同一套结构逻辑，即可信法律框架与不被单一阵营控制的治理，也适用于轨道计算治理。

但"中立性"需要一个直接限定。新加坡是美国安全伙伴，受 ITAR 合规义务约束，也参与会限制其在防务相邻情境下完全中立的信息共享安排。一个注册在新加坡的轨道计算平台，如果服务中国防务客户，或以需要出口许可的方式使用美国受控芯片技术，会面对真实监管限制。这不排除新加坡，而是说明其中立性是部分中立，诚实框架应当如此。

新加坡也不是唯一选项。卢森堡、阿联酋、日本在不同方面也有类似属性。关键是，中立轨道平台层的注册地应因治理质量而被选择，而不是因靠近最大工程人才池而被选择。

什么会证明本文判断错误

Space Android 命题可能在六种情况下失败：

1. Starship 发展停滞，发射成本无法降至 200 美元/kg。轨道计算对多数应用仍不经济，集中度风险也不会真正出现。

2. 地面替代方案解决电力问题。小型模块化核反应堆、海上数据中心或 HVDC 输电满足 AI 电力需求，无需轨道部署。

3. 热管理仍是无法解决的瓶颈。高密度轨道计算需要的可展开散热器系统过于复杂和昂贵，经济性永远无法闭合。

4. SpaceX 开放平台。如果 SpaceX 提供真正的第三方 payload API 与多供应商硬件兼容性，也就是自己成为 Android，那么替代平台需求会显著减弱。

5. 轨道计算客户拒绝把敏感工作负载放到太空。监管、保险与安全顾虑阻止商业和政府客户把任务关键计算部署到他们不能完全控制的基础设施上。

6. 没有实体愿意资助枯燥的平台工作。应用机会永远比基础设施层看起来更容易融资。没人愿意建标准载荷接口与开源轨道运行时，生态也就无法围绕共同标准形成。

其中任何一个都可能足够。投资者和政策制定者如果认真看这个领域，应先判断哪种失败模式最可能发生，并清楚思考什么条件必须成立，才能避免它发生。

---

结论：建造那层枯燥的基础设施

Musk 说 30 个月。Jensen 说 1,000 倍。四大云厂商据报已为 2026 年承诺超过 7,100 亿美元 AI 基础设施 capex。

方向性压力巨大：AI 需求增长速度超过地面基础设施能够经济满足的速度，而随着发射成本下降，轨道计算的物理论点会越来越强。无论时间线是 30 个月还是 10 年，建立开放平台层的结构性激励都是一样的；在 SpaceX+xAI 默认定义标准之前，建立标准的窗口是有限的。

SpaceX+xAI 正在全速推进，并在可见时间线上提出可信的轨道计算技术主张。

Android 对应物的技术组件已经存在。开源工具，包括 F Prime、SatCat5、OpenMCT、CCSDS、Docker、K3s，已经成熟可用。商业硬件供应链，包括 GomSpace、EnduroSat、Unibap、ISIS Space，也已经就位。需求信号则是计算基础设施史上最大的。

缺失的是愿意建平台层、而不是只建应用层的实体。每个投资人都愿意投卫星上的 AI 应用。很少有人愿意投让一千个应用成为可能的载荷接口标准和轨道容器运行时。

这正是 Linux 差点不会发生、Android 差点不会发生、互联网 TCP/IP 栈差点被私有协议替代的同一种动力学。在每个案例中，平台技术都需要学术机构或愿意为了上层应用收益而投资基础设施的公司。

同样的计算适用于这里。

那层枯燥的基础设施，现在仍然可以被建造。

---

本文数据来自下列公开来源、公司披露、监管材料与行业报道。分析代表作者独立观点。