Satlyt 轨道 AI 获得 800 万美元融资，但真正考验在于连接卫星

在创始人 Rama Afullo 未能在 Google 和 SpaceX 内部推销这一构想后，Satlyt 为其轨道 AI 平台筹集了 800 万美元。这轮种子融资为 Satlyt 带来新资金，用于在第三方航天器上部署软件，并在将数据传回地球前完成处理。不过，该公司尚未证明其最具雄心的设想：汇集由不同运营商拥有的卫星计算资源。

这一差异使 Satlyt 与那些设计专用轨道数据中心的公司区分开来。SpaceX、Google、Starcloud 和 Axiom Space 正在推进新的天基计算基础设施。Satlyt 则希望为已计划进入轨道的硬件提供一层共享软件。

短期机会不像轨道超大规模云那样引人注目，但也更容易测试。卫星在运行中会产生图像、遥测数据和系统日志，同时通信窗口有限。在星上处理这些信息，可以减少下行链路流量，并让运营商更快获得有价值的结果。

因此，Satlyt 轨道 AI 代表了两项风险程度不同的押注。第一项是运营商将为实用的星上推理付费。第二项是独立航天器最终能够像一个分布式云一样协同运行。融资同时支持这两种设想，但目前只有第一项已经进入轨道。

Satlyt 轨道 AI 从演示走向客户工作负载

这笔新融资使 Satlyt 从一个实验性软件项目，转变为对卫星运营商是否会将星上计算作为托管服务购买的检验。

Satlyt 于 2026 年 10 月 1 日宣布完成种子融资。Non Sibi Ventures 领投本轮，TLCOM、Antler、Slauson & Co.、Launch Africa Ventures、Enza Capital、Askya Investment Partners、Demos、BAG Collective、Gaingels、Axian Investment 以及现有投资者参与投资。

该公司表示，将利用这笔资金扩充工程和客户交付团队。它还计划在由其他公司提供和运营的航天器上部署软件。官方融资公告将此描述为迈向太空虚拟 AI 数据中心的路径。

Satlyt 联合创始人兼 CEO Afullo 此前曾在 Google 的云业务部门工作。他后来于 2024 年短暂加入 SpaceX 的 Starlink 团队。他告诉 TechCrunch，这两家公司都拒绝了他提出的分布式轨道计算内部方案。

这一拒绝如今构成了报道的核心反转。Google 和 SpaceX 此后都已投入资源发展轨道计算，而 Afullo 正在独立推进软件层。Satlyt 总部位于加州森尼韦尔和内罗毕，其管理团队全部由肯尼亚裔美国人组成。

Satlyt 不计划制造或发射自有卫星星座。相反，它会在具备可用处理硬件的航天器上安装软件。该公司希望管理应用程序、分配计算资源，并最终协调不同卫星之间的工作负载。

Afullo 将这一角色比作 VMware 或 Snowflake 在地球上提供的抽象层。卫星制造商将掌控实体机器，而 Satlyt 将帮助应用开发者使用这些机器，无需管理每一项硬件细节。

这一类比很有启发性，但仍属于愿景。地面云平台依靠稳定网络、标准化服务器和可替换组件运行。卫星则在处理器、功率预算、轨道、无线电设备、热限制和任务优先级上各不相同。

Satlyt 已完成两次演示任务。其最新计划部署涉及一艘由印度 TakeMe2Space 制造的航天器。应用包括由 NASA 支持的研究、太空监测初创公司 Stellerian 的图像处理工作负载，以及 TakeMe2Space 的托管演示。

NASA 项目来自一项由 NASA Glenn Research Center 和 University of Houston 参与的小型企业技术转让项目。Satlyt 提供部署和运行软件，而主机提供方则提供卫星和计算平台。

这些都是有意义的客户和研究信号。但它们尚不足以证明 Satlyt 能将一项任务分布到多艘航天器上。根据公司公告，目前的部署是在一颗卫星上运行两个应用程序。

这一边界很重要，因为“轨道数据中心”这一说法可能让人以为其容量远超当今硬件所能提供的水平。Satlyt 初期提供的是边缘计算，也就是在采集数据的传感器附近处理数据。多卫星云是下一项里程碑，而非当前产品。

为什么在下传前处理数据很重要

Satlyt 的直接价值在于决定哪些数据无需传回地球。

一颗卫星所采集的信息，可能多于其能够快速传输的信息。地面联络通常只在特定窗口内进行，通信容量还必须在载荷数据、健康信息、软件更新和运行指令之间共享。

这一限制造成了筛选难题。一颗对地观测卫星可能拍摄了一张大型图像，而客户只需要检测到的目标、位置或变化。一艘发生故障的航天器可能生成大量日志，而控制人员主要需要的是最可能的原因。

星上推理可在传输前减少这些内容。模型可以检查图像、分类事件、总结故障，或优先处理最有价值的观测结果。航天器随后发送结果和选定的支持数据，而非每一个原始字节。

Satlyt 已利用 Google DeepMind 的 Gemma 开放模型系列测试这种方法。根据一项Gemma 案例研究，该公司部署了量化后的 Gemma 3 模型，用于在本地分析系统日志、软件错误和堆栈跟踪。

量化会降低模型使用的数值精度，从而减少内存和计算需求。这能让 AI 工作负载在卫星级硬件上具备可行性，因为每一瓦功率和每一个字节都必须与任务关键系统竞争。

Satlyt 在基准测试中向图像处理管线引入了常见的软件故障。在两项代表性测试中，模型将诊断数据负载从 1,319 字节降至 469 字节，以及从 1,318 字节降至 464 字节。

相应降幅分别为 64.4% 和 64.8%。该模型在两种情况下的文本生成速度分别为每秒 22.71 和 25.48 个 token。案例研究称，它还生成了根本原因描述和建议的应对措施。

这些示例表明，轨道 AI 无需依赖巨型数据中心也能创造价值。即使是小型模型，也能将一个运行问题压缩为一条简短信息。控制人员能获得可用诊断，同时占用更少的下行链路容量。

同样的逻辑也适用于图像。野火监测载荷可在传输选定图像前识别可能的火情活动。海事传感器可优先处理符合任务标准的探测结果。监视应用可标记一个目标，而无需等待完整的地面处理。

然而，本地筛选也带来了新的责任。如果模型丢弃信息、错误分类观测结果，或给出不正确的诊断，运营商可能失去地面所需的证据。因此，任务设计者必须明确何时保留原始数据，以及何时可让 AI 输出影响运行决策。

Satlyt 表示，运营商将保留指挥权。这种分离至关重要。总结日志的模型与自主改变航天器配置的模型，所带来的风险截然不同。

该公司也在 Nvidia Jetson 硬件上测试更新版本的 Gemma 模型。其公开的地面测试结果清楚说明了限制。其中一种配置在总可用内存为 8 GB 的系统上使用了约 4 GB 峰值内存。活跃推理将处理器功耗提升至约 11 瓦，并使其温度升高数摄氏度。

这些测量结果并不能证明其在每一艘航天器上的表现。它们为将模型与处理器、电力系统和热设计相匹配提供了务实的起点。

对客户而言，相关问题并非语言模型能否在轨运行，而是星上处理是否能节省足够的通信时间、控制人员工作量或任务容量，以证明集成和验证工作是值得的。

在分布式太空计算成熟之前，这正是 Satlyt 可以切入的市场。即使更广泛的轨道云需要更长时间才能建成，每个有用的应用也能独立发挥价值。

软件层挑战专用数据中心路线

Satlyt 押注于：在现有航天器上部署共享软件，将比专为计算打造的星座更快触达客户。

Starcloud 代表了更偏重硬件的路线。它正在建造搭载高性能处理器的航天器，并最终提供大规模轨道计算能力。Axiom Space 正在开发与地面基础设施连接的轨道数据中心节点。Lonestar Data Holdings 则专注于离地存储和韧性。

Google 的 Project Suncatcher 和 SpaceX 的轨道计算计划，让规模更大的组织也加入这一领域。这些公司可以结合硬件工程、网络、发射关系和 AI 基础设施。它们的参与验证了这一赛道，同时也提高了竞争门槛。

Satlyt 在这一技术栈中采取了不同定位。它无需在销售一个有用的应用程序前，为整个星座提供融资。它可以在客户或合作伙伴原已计划发射的卫星上部署软件。

这种做法降低了一类资本风险，但也使 Satlyt 依赖于其无法控制的硬件。每个合作伙伴都可能使用不同的处理器、运行环境、通信系统、安全模型或调度策略。

Afullo 曾将这种差异描述为：大型轨道基础设施提供商类似 iPhone，而 Satlyt 类似 Android。他的公司希望支持一个覆盖众多制造商的开放环境，而非一支由单一主体垂直控制的星座。

这一比喻指出了机会，也揭示了困难。Android 的成功得益于智能手机制造商采用了共同的处理器架构、接口和开发者预期。商业卫星市场仍然碎片化得多。

航天器的主要任务也将优先于第三方计算工作。运营商不会仅仅因为闲置处理能力具有潜在商业价值，就牺牲成像、导航、通信或安全任务。

因此，Satlyt 必须围绕不断变化的功率、热量、通信和任务限制来调度应用程序。它需要隔离控制机制，确保一个客户的软件不会中断另一项应用，或访问受保护的数据。

如果该公司的平台能始终如一地处理这些差异，它可能会变得很有价值。开发者只需封装一次应用程序，而 Satlyt 则会为多艘航天器适配部署和运行。运营商可以从原本闲置的计算能力中获得额外收入。

Afullo 将这一主张描述为把卫星变成可创收的托管服务。这句话比“数据中心”更准确地概括了当下的商业模式。

Non Sibi Ventures似乎也认识到了这一更为聚焦的切入点。合伙人Kent Lucas告诉TechCrunch，Satlyt无需依靠庞大的轨道数据中心才能取得成功。仅卫星数量的增长，就可能为其软件创造市场。

这一观点让融资不必过度依赖于太空AI最激进的预测。随着轨道硬件逐步提升能力，Satlyt可以销售诊断、图像处理和应用托管服务。

专用计算航天器仍具备优势。其发电、热管理系统、处理器和通信链路都可围绕高要求的AI工作负载进行设计。而通用型宿主卫星可能仅能提供闲置容量。

这两种模式也可能趋于融合。专用轨道数据中心可能需要能够跨节点调度工作负载的软件。Satlyt可能成为这些星座的供应商，而硬件提供商也可能在内部开发竞争性软件。

SpaceX构成了最强的战略压力，因为它控制着发射、卫星、通信链路以及不断扩大的AI业务。它能够优化整个系统，并为自身基础设施保留更有利的经济条件。

Satlyt的防御优势在于中立性。不愿加入垂直整合式网络的运营商，可能更青睐独立的软件层。然而，只有当该软件能跨足够多的硬件运行、并吸引足够多的应用时，中立性才有意义。

这轮800万美元融资为验证这一主张争取了时间，但并未赋予Satlyt与其希望连接的企业相当的资源。

跨卫星计算是尚未验证的一步

在一艘航天器上运行一个模型是一项工程成就，但在不断移动的卫星之间协调云计算，则是另一个量级的系统问题。

Satlyt预计明年将在两颗不同卫星之间尝试构建共享计算系统。若成功，公司将更接近其核心承诺：将彼此独立的航天器视为统一管理平台中的资源。

分布式任务需要的不只是两颗处理器执行软件。节点还需要交换数据、发现可用容量、相互认证、从中断连接中恢复，并在某颗卫星不可用时保留结果。

轨道网络的动态性尤为突出。卫星相对于地面站和彼此快速移动。一条可用链路可能沿着可预测的路径出现、消失并再次出现，而大气条件或硬件故障则会带来更难预测的变化。

一项关于LEO故障模式的研究综述指出，卫星移动性、有限的计算能力、能源预算、辐射和网络退化，都是重要的软件挑战。轨道安全机动也可能改变调度器所依赖的网络假设。

这种环境使传统云计算的预期难以维持。地面应用可以假定附近服务器持续可达，且故障硬件最终会被更换。卫星工作负载则必须预期连接中断，并在漫长的恢复周期中运行。

首次双卫星测试无需解决所有问题，但必须厘清Satlyt所说的共享计算究竟意味着什么。将一次计算拆分到多艘航天器之间，比通过同一仪表盘调度两个独立任务更能证明能力。

测试还应揭示平台如何处理状态。如果任务完成前连接中断，软件必须知道应暂停、重启、迁移，还是等待下一个通信窗口。重复执行可能浪费稀缺电力，而状态丢失则可能使结果失效。

安全性又增加了一层复杂性。来自不同运营商的卫星可能遵循不同的信任策略和国家义务。客户需要确信，一个应用无法查看另一项任务的数据，或发出未经授权的指令。

更新同样需要谨慎。发射后部署的软件带来灵活性，但每一项新工作负载都会扩大攻击面。运营商将要求签名软件包、严格权限、资源限制、审计记录，以及可靠的回滚流程。

数据治理可能使跨境运营更加复杂。一颗卫星可以在多个司法辖区上空收集信息，并通过由多个组织拥有的基础设施传输。Satlyt需要围绕存储、处理和传输建立可执行的控制机制。

然后是性能问题。如果跨航天器分割应用所消耗的能量或带宽，超过本地处理所节省的资源，其价值就十分有限。Satlyt必须识别能够容忍间歇性链路、且可被高效拆分的工作负载。

图像筛选、模型推理和事件检测可能符合这一特征。大型模型训练需要处理器之间频繁通信，因此在松散连接的卫星间实现难度大得多。近期的平台更适合边缘工作负载，而非地面式AI集群。

这一差异避免了夸大的类比。Satlyt如今并非在轨道上重建超大规模数据中心。它正在测试软件层能否将分散的计算机转化为有用的共享服务。

每一次在陌生硬件上的成功部署，都会强化公司的主张。仅在一家合作伙伴的航天器上运行的平台，更像是定制集成；能够在多种处理器、任务和运营商环境中稳定运行的平台，才开始像基础设施。

因此，硬件多样性与卫星数量同样重要。同一运营商旗下两艘几乎相同的航天器可提供重要的工程测试；由不同所有者运营的两种不同平台，则能更好地验证Satlyt的商业逻辑。

在结果公布前，分布式云仍只是一项计划。该公司现有的机载AI工作支持这一方向，但并不能独立验证完整架构。

辐射、维修与经济性仍然决定边界

Satlyt可以通过软件抽象硬件差异，却无法抽象掉轨道环境的物理约束。

辐射可能损坏内存、破坏处理器，并造成间歇性错误。热管理十分困难，因为热量无法通过普通空气对流从设备中散出。电力则会随轨道条件、航天器姿态、电池容量和任务活动而变化。

高性能处理器会加剧这些限制。GPU可以快速完成推理任务，但也会消耗电力并产生热量。卫星设计者必须在计算性能与航天器既有载荷和通信需求之间取得平衡。

维修是另一项根本性差异。地面运营商可以更换故障的加速器、网卡、电源或存储设备。绝大多数卫星硬件则必须一直工作到任务结束。

接受轨道可靠性风险采访的专家强调，高能粒子可能损坏GPU。冗余处理器是一种应对方式，但冗余会增加质量和成本。

Satlyt以软件为先的方案避免了直接拥有这些硬件故障，但无法避免依赖受影响的设备。平台必须检测故障、隔离异常节点、迁移符合条件的工作负载，并向客户说明容量下降情况。

发射经济性同样重要。Satlyt可以利用任务中已有的计算设备，从而减少专用发射的需求。然而，增加处理器、屏蔽层、存储和电力系统，仍会改变航天器设计和成本。

公司还需要足够的供给来创建市场。少数卫星上的闲置算力或许可支持演示和专用应用，但可靠的托管服务需要在有价值的轨道和通信窗口中持续提供容量。

需求同样不能想当然。卫星运营商已经使用成熟的飞行软件和地面处理流程。只有当第三方轨道AI在不带来不可接受的安全或认证负担的前提下改善任务经济性时，他们才会采用它。

Satlyt表示，其诊断工具可通过减少下行链路使用和控制人员工作量，为运营商节省可观成本。这些节省仍是公司估算，而非经审计的客户结果。

更有力的证据将来自可测量的载荷缩减和已完成的轨道部署。未来案例研究应将这些技术指标与客户成果联系起来，包括更快决策、更低通信使用量、更少人工调查或新增收入。

本轮融资为Satlyt收集这些证据提供了空间，也提高了预期。投资者最终将需要看到可重复的部署、付费客户，以及考虑集成支持成本后的利润率。

集成可能成为隐藏成本。支持多种航天器类型听起来颇具吸引力，但为每个宿主进行定制工程可能耗费时间并降低软件利润率。Satlyt必须证明，其通用平台的扩张速度快于任务专属工作。

大型竞争者可能从两方面挤压这一模式。卫星制造商可以加入自己的应用层，而轨道数据中心运营商可以将软件与专用容量捆绑。云计算公司则可将现有开发者平台扩展至合作伙伴航天器。

Satlyt仍有机会，因为尚无单一标准控制轨道计算。早期部署可以影响接口、安全实践和采购预期。公司在Sunnyvale和Nairobi的布局，也可能帮助其连接美国资本与新兴的非洲太空项目。

其与Kenya Space Agency及Angola的GGPEN签署的谅解备忘录提供了区域关系，但并不保证商业采用。农业、气候监测和环境管理领域的地球观测，提供了相关应用场景；在这些场景中，更快的本地分析可能具有重要意义。

风险不在于轨道AI毫无用途，而在于最有价值的工作负载可能仍分散于专业任务之中，导致对广泛平台的共同需求不足。

Satlyt必须证明，抽象能够跨越这些差异创造价值。否则，其软件可能仍是一组定制集成，而非Afullo所设想的中立云层。

三个信号将显示Satlyt能否打造轨道云

下一阶段应以运营证据，而非轨道数据中心愿景的规模来评判。

第一个信号，是在TakeMe2Space航天器上成功运行应用。仅仅完成发射并不能验证软件。Satlyt需要证明，研究和影像工作负载能在轨运行、产出有用结果，并保持在宿主的资源限制范围内。

公开的测量数据将增强可信度。相关证据包括处理时间、功耗、内存使用、热影响、下行链路缩减、故障恢复，以及与地面分析相比的准确性。

成功部署将证明Satlyt能够在第三方硬件上支持外部应用。调试期间出现的问题不会终结这一构想，但会显示仍需要多少任务专属工程。

第二个信号是计划中的双卫星计算测试。读者应关注Satlyt是否能协调一项工作负载跨不同航天器运行，而不是仅通过同一界面管理独立应用。

所有权与硬件配置将很重要。跨不同运营商和计算平台的演示，将支持中立云的论点。局限于匹配系统的测试则可验证编排能力，但互操作性仍未得到解决。

Satlyt 还应说明其如何处理链路中断和部分故障。可信的演示应展示恢复行为、安全边界、资源核算，以及用于保持应用状态的方法。

第三个信号是商业化的重复性。Satlyt 表示，其软件包已为部署到多颗航天器做好准备，但具备部署能力并不等于正在实际使用。重要指标包括付费运营商、持续运行的应用，以及随着时间推移所需定制工作不断减少的部署。

Afullo 已设定长期目标：到本十年末在 20% 的卫星上运行。这个目标雄心勃勃，且仍未得到验证。更近期的进展应通过多样化的主机、客户续约，以及超越演示阶段的工作负载来衡量。

竞争对手的动向将提供更多背景信息。如果卫星制造商采用通用的应用接口，Satlyt 可服务的平台规模将扩大。如果 SpaceX、Google 或 Starcloud 继续保持其系统封闭，那么独立的一层对这些舰队之外的所有参与者而言可能更具价值。

反过来也可能如此。占主导地位的基础设施提供商可能会将调度和应用工具与发射及连接服务捆绑销售，使独立平台更难推广。

Satlyt 的轨道 AI 值得关注，因为它将有用的星载处理能力与更宏大的天基数据中心承诺区分开来。在庞大的计算舰队出现之前，它就能创造客户价值。

该公司如今已具备资金、在轨经验以及明确界定的下一项测试。但它尚未证明，彼此无关的卫星能够作为一个云整体运行。

开发者和卫星运营商应关注这一边界上的结果：该平台能否在航天器之间迁移真实工作负载、从连接丢失中恢复，并带来经济效益？如果 Satlyt 公布这些答案，其“太空版 Android”的比喻将开始更像是一项平台战略。在此之前，它仍是一套由早期部署支持、颇具吸引力的架构，而非一个成熟的轨道云。