Satlyt 轨道 AI 软件走上了 SpaceX 和 Google 拒绝的开放路线

在 SpaceX 和 Google 拒绝创始人 Rama Afullo 提出的轨道分布式计算内部提案后，Satlyt 轨道 AI 软件正进入太空。Satlyt 现已完成 800 万美元种子轮融资，并获得多个卫星任务的载荷席位，以部署其软件。

当 Satlyt 的软件通过 SpaceX 进入轨道、与 Google Project Suncatcher 的硬件并行运行时，这一转变显得格外直观。两家前雇主如今都支持轨道计算战略，但采用的架构不同于 Afullo 所选择的路线。

Satlyt 希望提供一个可跨越多家制造商航天器运行的软件层。SpaceX 则代表相反的路径：由一家公司控制发射、卫星、连接服务、计算硬件以及大部分运行环境。

这种差异比共用一枚火箭这一巧合更重要。它勾勒出一场早期竞争：谁将掌控地球上空的计算层——垂直整合的航天器拥有者，还是连接混合卫星群的独立平台。

Satlyt 轨道 AI 软件已不再只是一个提案

眼下的变化在于，Satlyt 现在拥有融资、飞行经验和真实工作负载，而不再只是一个被内部否决的提案。

Afullo 曾在 Google 的云业务部门任职，随后于 2024 年加入 SpaceX 的 Starlink 业务。他告诉 TechCrunch，自己曾在两家公司内部推介轨道计算，但两家公司当时都拒绝了这一想法。

随后，他联合创办了 Satlyt。该公司在加州桑尼维尔和肯尼亚内罗毕开展业务，正开发让卫星在本地处理数据、并最终能在多颗航天器间共享计算任务的软件。

Satlyt 的 800 万美元种子轮融资由总部位于休斯敦的 Non Sibi Ventures 领投。该投资机构的合伙人包括前 NASA 宇航员 Bernard Harris，其经验帮助该公司评估了这项技术和商业方案。

融资只是这一事件的一部分。Satlyt 表示，其软件已经在两次演示任务中飞行，为公司带来了超出实验室测试范围的受限计算经验。

其最新披露的部署涉及印度公司 TakeMe2Space 制造的硬件，后者正在为卫星开发计算系统。这项任务将三种不同客户的工作负载带上航天器。

NASA 正付费测试太空云计算协议。致力于轨道监视的 Stellerian 计划评估图像处理能力。TakeMe2Space 则希望展示其卫星可托管外部公司的软件。

这些客户代表了三层重要需求：政府机构需要技术验证，商业运营商需要更快的分析能力，航天器制造商需要更灵活的产品。

这种组合为 Satlyt 提供了比单纯软件演示更严苛的测试。其平台必须支持不同的工作负载，同时在单颗航天器的电力、内存、温度和通信限制内运行。

该公司还在 Momentus 运营的一颗卫星上部署了量化后的 Gemma 3 模型。量化会降低模型的数值精度，使其能以更少的内存和算力运行。

根据 Gemma 测试，这个拥有 10 亿参数的模型在本地分析遥测数据、应用日志和软件错误。它通过 llama.cpp 运行，后者是一套为高效模型推理而设计的框架。

在两项故障注入测试中，该系统将诊断载荷分别从 1,319 字节降至 469 字节、从 1,318 字节降至 464 字节，降幅分别为 64.4% 和 64.8%。

该模型还基于现有技术上下文生成了简短诊断和建议操作。这一结果并不能证明航天器可实现可靠的自主运行，但展示了机载 AI 的直接用途。

卫星无需将每一条原始日志都传回地球，而可以在利用有限下行窗口前先汇总错误信息。地面控制人员随后收到的信息更小、更有用。

因此，Satlyt 的进展建立在实际工作负载之上，而不只是遥远的超大型轨道数据中心构想。它从已经飞往轨道的硬件上的软件诊断、遥测分析和图像处理开始。

这也构成了本文的核心张力。SpaceX 和 Google 可以通过严格控制的系统推进轨道计算，而 Satlyt 必须证明共享软件能在其他公司的设备上运行。

短期市场是机载处理，而非巨型太空数据中心

Satlyt 无需建成完整规模的轨道云就能创造价值，但它需要卫星运营商将软件视为一项独立采购决策。

大多数卫星仍高度依赖地面站。它们收集图像、传感器读数、运行数据和错误日志，再在预定通信窗口内传输选定信息。

这种模式形成了瓶颈。航天器产生的数据量可能超过其以经济成本传回地球的能力，尤其是在联络窗口短暂或带宽竞争激烈时。

机载处理将部分决策移到更靠近传感器的位置。卫星可在传输前丢弃不可用图像、优先处理可疑目标、汇总故障，或压缩观测数据。

这一思路类似于地球上的边缘计算。边缘计算在靠近数据源的位置运行分析，减少将所有数据发送至集中式云端的需要。

太空让这种权衡更为严峻。偏远的地面设备可能在数分钟内恢复网络连接，而航天器却可能面临覆盖有限、能源预算严格、辐射环境，以及无法进行实体维修的问题。

这正是 Satlyt 的诊断案例重要的原因。与轨道 AI 集群的愿景相比，将错误报告缩小 60% 以上似乎并不起眼，但它针对的是运营商已经面临的一项成本。

该公司表示，本地分析可减少地面处理工作，并缩短对异常情况的响应时间。具体节省的财务成本将因卫星、任务、人员配置模式和通信合同而异。

图像处理是另一个直接应用场景。地球观测卫星可以在下传前识别被云层遮挡的画面，或优先传输包含目标状况的图像。

太空监视工作负载遵循同样逻辑。卫星可以筛选图像中的潜在目标或异常运动，再优先传输最相关的数据。

这些应用不需要在轨道上建造仓库规模的数据中心。它们需要能够在受限计算机上稳定运行的小型模型，并在严格的资源预算内生成有用结果。

这一差异也吸引了 Satlyt 的领投方。Non Sibi 合伙人 Kent Lucas 告诉 TechCrunch，该公司无需依赖巨型太空数据中心便可成功；仅卫星数量的增长就能扩大其可服务市场。

这一论点有其合理性，但仍依赖多项假设。更多航天器必须配备通用处理器，运营商必须允许第三方软件运行，任务设计人员还必须为 AI 工作负载分配稀缺电力。

Afullo 预计先进处理器将成为卫星的常见配置。他设定了一个雄心勃勃的目标：在本十年末覆盖 20% 的卫星。

这一目标仍是公司愿景，而非独立预测。卫星星座差异很大，许多航天器使用的是为单项经严格验证任务设计的专用计算机。

尽管如此，这一机会仍比广泛的轨道云叙事更容易理解。Satlyt 可以在卫星开始共享最大规模 AI 工作负载之前，先销售有用的机载处理能力。

开发者应将这一阶段视为对软件可移植性的测试。核心问题在于，一个运行层是否能支持不同的处理器、载荷、通信系统和航天器安全要求。

企业买家应聚焦产出而非宣传。减少下行传输量、更快响应异常情况以及更高价值的图像，都是可衡量的收益，即使底层系统从未成为巨型数据中心。

这些实际指标也解释了为何既有航天器企业面临压力。如果客户重视可移植软件，硬件提供商对其卫星上运行应用的控制力就会有所减弱。

SpaceX 在造 iPhone，而 Satlyt 想造 Android

这场主要竞争并非 Satlyt 与 SpaceX 在规模上的较量，而是开放软件层与封闭、垂直整合计算技术栈之间的竞争。

Afullo 用一个熟悉的类比来说明这种区别。如果 SpaceX 成为轨道数据中心的 iPhone，他希望 Satlyt 成为 Android。

这一比较并不完美，但抓住了战略分歧。Apple 将硬件、操作软件、服务和分发整合在一套严格管理的系统中，而 Android 支持来自众多制造商的设备。

SpaceX 已经控制了比多数潜在竞争者更多的实体技术栈。它制造火箭、运营发射基础设施、生产卫星、管理通信星座，并服务连接服务客户。

这种整合可以降低协调成本。工程师能够共同优化硬件和软件，维持一致的接口，并且无需在互不相关的航天器供应商之间协商标准即可快速推进。

但这也会带来依赖性。基于专有轨道平台建设业务的客户，可能会受制于某一家公司的发射计划、技术路线图、价格、接口和访问决策。

Satlyt 押注的是相反的路线。它并不计划制造卫星，其软件旨在跨不同运营商拥有的航天器运行，并将这些计算资源转变为共享服务。

该公司将自身角色与 VMware 和 Snowflake 相比。VMware 将应用程序与特定实体服务器分离，而 Snowflake 则让客户能够在云基础设施上使用托管数据层。

在轨道上，这种抽象难度大得多。地面云服务器使用相对标准化的处理器、网络、电源、存储系统和维护实践。

卫星则是暴露在辐射、热循环、有限能源、间歇性连接和轨道运动中的定制机器。即使只是重启一个失败进程，也可能产生任务级后果。

因此，开放的轨道平台不能只是把同一个软件包安装到不同计算机上。它必须适应硬件差异，同时不能削弱安全控制或干扰航天器的关键功能。

该平台还需要安全的工作调度方式。第三方应用不能消耗导航、通信或主载荷所需的电力、内存或网络容量。

这些挑战强化了垂直整合的理由。SpaceX 可以将其计算硬件、星间链路、运行环境和电力系统设计为一个协调一致的产品。

不过，整合并不能保证客户会偏好封闭系统。卫星制造商和运营商可能希望接入多个发射服务商、处理器、模型和分析供应商。

当多样性增加时，独立软件层的价值便会显现。每新增一颗兼容的航天器，潜在计算资源池便会扩大，而 Satlyt 无需为此出资建设卫星星座。

这与推动地球上软件平台发展的网络效应如出一辙。更庞大的硬件基础会吸引开发者，而更多应用又会让底层平台对硬件厂商更具吸引力。

轨道环境带来了棘手的冷启动问题。Satlyt 需要先有兼容卫星，开发者才愿意投入；但航天器制造商也需要先看到有用的应用，才会向 Satlyt 分配资源。

其早期任务试图通过具体工作负载解决这一问题。NASA 提供验证用例，Stellerian 提供应用，TakeMe2Space 则提供托管硬件。

Google 的路径则提供了另一种对照。Project Suncatcher 设想通过互联卫星搭载 Google Tensor Processing Units，即 TPU，并利用充足的太阳能供电。

该项目的首要步骤聚焦于 Google 自有的计算硬件。其与 Planet 共同打造的原型机旨在测量 TPU 对发射载荷、辐射以及太空热环境的响应。

Google 确认，该原型机已于 2026 年 10 月 1 日随 SpaceX Transporter-18 任务进入轨道。该卫星已建立通信并启动测试计划。

因此，Google 正在测试其专用芯片能否在太空中存活并运行。Satlyt 则在测试软件能否让多样化的轨道计算机为外部客户所用。

两家公司目前并非直接竞争对手。若未来独立平台能够在 Google 设计的处理器或其他专用处理器上运行工作负载，它们的架构甚至可能形成互补。

不过，两者的优先级揭示了不同的控制中心。Google 从其拥有且熟悉的硬件出发。Satlyt 则从跨越其无法控制的硬件实现可移植性出发。

如果轨道计算持续发展，这一区别将塑造利润率、客户选择与开发者接入方式。最终胜者未必拥有最多卫星，但将影响应用如何在卫星之间迁移。

开放式轨道云仍须经受现实考验

Satlyt 最有力的论点是灵活性，但当航天器差异过大，或客户不愿共享资源时，灵活性也可能成为负担。

该公司已展示，小型语言模型可以在受限硬件上处理诊断数据。但这不等同于在卫星之间运营分布式云。

Satlyt 的下一项重大技术目标，是连接两颗不同航天器之间的计算能力。公司预计将在明年尝试进行这一演示。

成功的测试将十分重要，因为分布式计算需要机器之间协同。软件必须拆分任务、传输数据、处理延迟、从中断中恢复，并确认结果仍然正确。

在拥有可靠电力和高速网络的地面数据中心中，这些任务司空见惯。当两台计算机绕地球飞行、且只能在特定轨道条件下通信时，难度就会显著上升。

延迟并非唯一问题。卫星可能采用不同的处理器、操作系统、安全要求、可用电力和任务优先级。

星间链路也可能存在巨大差异。有些航天器配备激光通信，有些使用无线电链路，还有许多从未被设计用于与邻近卫星交换大型计算工作负载。

Google 表示，其计划中的激光连接所需精度，相当于在两个目标均在移动的情况下，从数英里外击中硬币大小的目标。

其测试也说明了硬件挑战。Google 称，发射组件可能承受相当于 50 至 100 倍重力的力，而辐射可能改变电子系统中存储的数据。

热控制同样至关重要。处理器会产生热量，但航天器无法依靠普通气流冷却，因为太空是真空环境。

Satlyt 的软件无法消除这些物理限制。只有当航天器提供准确遥测数据，并给予平台足够的运营控制权时，软件才能围绕这些限制进行调度。

网络安全又构成另一道障碍。管理多颗卫星工作负载的软件可能成为极具价值的攻击目标，因为一次入侵可能影响多个运营商。

客户将要求应用间隔离、签名更新、访问控制、审计记录，以及针对紧急关停的明确权限。这些保护措施会消耗额外计算资源。

AI 输出还带来另一种风险。模型可能错误总结故障，或错误分类图像，尤其是在输入数据与训练和测试数据不同时。

因此，Satlyt 当前的诊断用途看起来比自主控制更安全。模型可以向地面运营人员建议操作，而无需获得改变航天器行为的权限。

该公司表示，随着其向异常检测和多智能体决策扩展，运营商将保留指挥权。辅助与控制之间的实际边界需要经过谨慎验证。

商业激励同样充满不确定性。卫星所有者可能拥有闲置处理器时间，但将其借给外部工作负载可能带来责任风险，而收入却未必足够。

所有者还必须为其主要任务预留容量。地球观测卫星不能因为其他应用消耗电力或占满存储空间，而延迟交付客户图像。

Satlyt 的“Android”战略只有在航天器制造商支持通用接口时才会奏效。若缺乏有意义的标准化，每一次集成都将成为定制化工程项目。

这将削弱独立平台的经济性。软件利润率依赖于将同一产品复制到众多客户，而非为每颗卫星重新构建。

竞争也可能来自拥有硬件的公司。SpaceX、Google、Starcloud 及其他轨道计算企业可以开放开发者接口，同时保持其底层系统的专有性。

托管式封闭平台可能比开放网络更容易采购。当一家供应商能提供更简单的部署、更强的支持和可预测的性能时，客户往往会接受供应商依赖。

因此，Satlyt 尚未证明 Android 模式将占据主导地位。它已经证明，开放路径足够可信，能够获得融资并进入实际飞行任务。

下一阶段必须证明可重复性。一颗卫星上的一个模型可以证明可行性，而不同航天器之间的可移植工作负载，才能支撑其更广泛的平台主张。

三个信号将显示 Satlyt 能否成为轨道平台

下一批证据必须来自跨卫星计算、重复客户以及可量化的运营价值，而非又一次雄心勃勃的类比。

第一个信号是 Satlyt 计划中的双卫星云演示。这是对其核心技术主张最直接的检验。

观察者应关注航天器是否来自不同平台的确认信息。由单一运营商管理的两颗相同卫星可以测试分布式计算，但无法验证广泛互操作性。

该演示还应披露任务如何在两颗卫星之间迁移。相比具备明确延迟、资源使用和恢复行为记录的协同处理，小型消息交换的意义较小。

若成功执行，将增强 Satlyt 关于其可抽象化硬件差异的论据。若出现延迟或演示范围收窄，则表明开放平台仍比其营销表述更早期。

第二个信号是客户复购。NASA、Stellerian 和 TakeMe2Space 为公司提供了有用的初始工作负载，但试点项目并不能证明需求持久。

更有力的迹象是，客户从一次实验扩展到多颗航天器。这将表明，该软件创造的价值足以通过任务审查和预算审批。

另一个重要指标是集成 Satlyt 的独立航天器制造商数量。Android 类比需要多个制造商，而不是在一个合作伙伴的硬件上部署多项任务。

Satlyt 表示，其已为 2026 年多达 50 次航天器部署准备好软件。准备就绪的能力不等同于已激活的部署，因此完成安装比准备容量更重要。

读者应区分已签署协议、已发射系统、活跃工作负载和付费续约。每一步所代表的商业证据水平不同。

第三个信号是运营表现。下行数据量减少是早期指标，但客户还会关注准确率、能耗、内存消耗和响应时间。

Gemma 测试提供了有用的基线。Satlyt 报告称，在两种场景中，诊断载荷大约缩小了 64%，生成速度超过每秒 22 个 token。

其更广泛的测试考察了推理期间约 11 瓦的处理器功耗，以及三至五摄氏度的温升。这些是公司在受限测试条件下提供的测量数据。

未来披露应将这些技术结果与任务成果联系起来。运营人员是否更快解决故障、下传了更有价值的图像，或减少了地面工作负担？

独立确认将比又一次内部基准测试更有分量。来自客户或研究合作伙伴的航天数据，将澄清这些收益是否能在受控测试之外持续存在。

SpaceX 和 Google 不太可能坐等。Google 已在从其轨道 TPU 原型机收集数据，包括辐射和极端温度下的性能。

其下一项计划里程碑涉及测试两颗卫星之间的通信。即便 Google 不提供广泛的商业平台，相关进展也将强化其垂直协调模式。

SpaceX 拥有不同优势：部署规模。它对发射和卫星制造的控制，使其无需等待无关航天器供应商采用通用接口便能持续迭代。

Satlyt 无法匹敌这些资本资源。其机会在于，让市场其余部分更像一个共享计算基础设施那样运作。

这一模式已在其他行业中奏效。当客户需要选择，而没有单一硬件供应商能够控制整个市场时，独立软件就会变得有价值。

不过，太空并非普通的软件市场。可靠性标准、物理限制、国家安全担忧和漫长的采购周期，都会拖慢平台采用速度。

开发者应关注首批任务中涌现的接口。稳定的应用模型将使一次开发、跨多颗航天器部署变得更容易。

卫星采购方应询问谁控制更新、工作负载调度、遥测访问和故障恢复。这些细节决定“开放”是指可移植，还是仅能通过定制化工作实现兼容。

评估证据的团队还需要在任务报告、测试结果、合同和工程决策之间保留严谨记录。可搜索的知识库可以让这些主张与其支撑文档保持关联。

Satlyt 的轨道 AI 软件已达到重要门槛。它现在拥有资本、飞行验证、客户实验，以及一个明确的架构对手。

该公司尚未建成跨不同卫星的轨道云。它也尚未证明，制造商愿意交出足够的控制权，让独立平台实现规模化。

这正是这个故事值得持续关注的原因。被否决的构想已不再只是设想，但其核心承诺仍有待验证。

未来几个月，请关注双卫星测试、重复部署以及任务级性能数据。它们将共同揭示，Satlyt 究竟是在为轨道打造 Android，还是仅为少数航天器开发一款专用工具。