一颗卫星每天产生 TB 级数据，但下行带宽只有几分钟窗口
卫星在轨采集图像、扫描地表、监听信号，但大多数时候，它只能把原始数据囤在星上，等待与地面站建立连接的短暂窗口。通信容量是太空系统最稀缺的资源之一：一颗遥感卫星每天可能产生数 TB 级数据，却只有几分钟到几十分钟的下行时间。运营方不得不在“传什么”上做取舍，大量有价值的信息在等待连接的过程中贬值。
Satlyt 的创始人 Rama Afullo 在 Google 云业务和 SpaceX Starlink 都待过。按照他公开讲述的版本，他在这两家公司内部都提过在轨计算的方案，都被拒绝了。2024 年，他离开 SpaceX，创立 Satlyt，把方向定在了一个更轻的切口上：不造卫星，不发射硬件，只写一层软件，让已经在轨的航天器把计算任务跑起来。
2026 年 10 月，Satlyt 宣布完成 800 万美元种子轮融资，由总部位于休斯顿的 Non Sibi Ventures 领投。这笔钱要解决的问题，不是把数据中心搬上太空，而是先让现有卫星的算力不再闲置。
| 字段 | 内容 |
|---|---|
| 公司 | Satlyt |
| 轮次 | 种子轮 |
| 金额 | 800 万美元 |
| 投资方 | Non Sibi Ventures（领投）、TLCOM、Antler、Slauson & Co.、Launch Africa Ventures、Enza Capital、Askya Investment Partners、Demos、BAG Collective、Gaingels、Axian Investment 等 |
| 总部 | 美国加州森尼韦尔（美国总部）与肯尼亚内罗毕（非洲总部） |
| 创始人 | Rama Afullo（创始人兼 CEO） |
| 官网 | https://satlyt.ai/ |
把 Gemma 塞进卫星，不是为了聊天，是为了少传 60% 的错误日志
Satlyt 的产品逻辑与地面云计算公司相反：它不拥有任何底层硬件。据公司披露，其软件层可以跨不同卫星设计工作，能够通过上行链路安装、改装或预装到卫星上。卫星运营方付费安装这层软件，利用航天器上已有的计算硬件在轨处理数据、运行 AI 应用。
今年早些时候，Satlyt 在 Momentus 运营的一颗航天器上运行了 Google DeepMind 的 Gemma 模型。该模型在星上本地分析系统日志、软件错误与堆栈跟踪，将一次关于星上软件错误的传输体积缩减超过 60%。Afullo 称，这种效率理论上可为每颗卫星每年节省数十万美元。这一数字来自公司口径，尚无独立第三方验证。
这个用例本身值得注意：它不是为了在太空跑大模型推理，而是把 AI 当作星上运维工具。卫星出现异常时，传统做法是把日志打包下传，由地面飞控团队排查。Satlyt 的做法是让模型在星上先读一遍日志，只把压缩后的结论传回地面。从已披露的 60% 传输缩减看，这意味着地面团队拿到的不是完整原始日志，而是经过模型筛选后的信息。但 Gemma 在星上做日志分析时，模型本身的误判率、漏报率，以及哪些错误类型会被压缩掉，来源材料均未披露。
Satlyt 的软件计划于 10 月 1 日随 SpaceX Transporter-18 任务发射，搭载印度卫星计算硬件初创公司 TakeMe2Space 的卫星；截至发稿尚未确认发射结果。据公司披露，这次任务服务三个客户：NASA 付费测试太空云计算协议，太空监视初创公司 Stellerian 测试图像处理负载，TakeMe2Space 自身则展示其卫星可以承载其他公司的软件。计划中的部署将在一颗航天器上运行两个应用：研究软件与商业图像处理应用。研究软件来自 Satlyt 与休斯顿大学合作的 NASA Glenn STTR 项目，方向是延迟容忍网络技术，让航天器系统在太空常见的延迟与中断下仍能通信与交换数据。
“如果 SpaceX 是 iPhone，我们做 Android”——但 Android 也得先有手机
Afullo 给 Satlyt 的定位是横向整合的软件层，类比 VMware、Snowflake 与 Android。他在接受采访时说：“像 SpaceX 这样在做轨道数据中心的公司——如果他们是 iPhone，我们就做 Android，做一个横向整合的开放生态。”
这个类比的信息量在于：Satlyt 不打算与 SpaceX、Google 的 Project Suncatcher、Starcloud 或 Axiom Space 在硬件层面竞争。它要做的是跨卫星设计的软件层，让不同运营方的航天器最终能共享计算资源。但这里有一个关键约束：Android 能成立，是因为手机厂商已经大量存在，且硬件标准化程度足够高。而 Satlyt 面对的现实是，在轨高性能 GPU 数量仍然很少，卫星计算硬件远未标准化，不同运营方的航天器在处理器架构、电源预算、热控能力和操作系统上差异巨大。
从已披露信息看，Satlyt 目前的实际能力聚焦在单颗航天器内部处理。所谓“跨运营方共享计算资源”仍是长期目标。公司预计明年尝试演示跨两颗卫星的共享云，但来源材料没有说明这两颗卫星是否属于不同运营方，也没有披露共享云的技术实现路径。Afullo 希望到本十年末 Satlyt 能运行在 20% 的卫星上，这是创始人个人目标而非公司承诺。这个目标的前提是卫星数量持续增长，且卫星制造商普遍开始在星上部署 GPU 或类似先进处理器。Non Sibi 合伙人 Kent Lucas 的表述更保守：“我们不需要太空数据中心，Rama 就能非常成功，对吧？它只需要由卫星发射数量驱动。”
收入来自三类付费方，但每一类都有不同的验证节奏
Satlyt 的商业模式有三条线。据 Afullo 在 TechCabal 采访中披露：卫星运营方付费安装软件，以更高效利用现有算力；公司与大型航空航天与国防承包商开展付费试点；航天机构通过研发项目付费开发特定技术。NASA 的 STTR 项目属于第三类，Stellerian 和 TakeMe2Space 的部署更接近前两类。
这三类收入的性质差异很大。研发项目是确定性较高的合同收入，但规模有限，且与政府预算周期绑定。卫星运营方的软件授权或服务费，取决于 Satlyt 能否证明其软件在真实在轨环境中持续创造可量化的节省——目前只有一个 Gemma 日志压缩案例，且传输缩减幅度在不同来源中存在冲突：多数来源称超过 60%，The Condia 另称遥测数据最多减少 97%，该口径与 60% 的统计对象不同，需分别核验。航空航天与国防承包商的付费试点，则是最接近商业化的路径，但来源材料没有披露试点名称、金额或进展。
从资本结构看，本轮投资方组合值得拆解。领投方 Non Sibi Ventures 总部在休斯顿，其合伙人 Bernard Harris 曾任 NASA 宇航员超过 20 年，来源称其帮助确立了该机构对这一太空业务的信心。跟投方中既有非洲背景的 Launch Africa Ventures、Enza Capital、Axian Investment，也有硅谷和欧洲的 Antler、TLCOM、Slauson & Co. 等。TLCOM 管理合伙人 Maurizio Caio 在声明中表示，期待帮助公司“建立商业职能，并深化与非洲及其他地区航天机构的合作”。这种组合说明，本轮资本同时押注两件事：一是 Satlyt 作为太空软件层的全球机会，二是其肯尼亚子公司与非洲航天机构的关系网络。Satlyt 的肯尼亚子公司已与肯尼亚航天局、安哥拉 GGPEN 签署谅解备忘录。谅解备忘录本身不构成收入承诺，来源材料没有披露这些备忘录是否包含资金安排、时间表或具体项目范围。
与 Starcloud、Axiom 和 Google Suncatcher 的路线分野
Satlyt 本轮 800 万美元种子轮押注的是一条不持有航天器的路线：它把软件部署在 TakeMe2Space 的卫星上，由后者提供计算平台，Satlyt 提供部署与操作层，商业软件公司提供应用。这与 SpaceX 被报道全力投入轨道数据中心、Google 的 Project Suncatcher 发射首个原型、Starcloud 和 Cowboy Space Company 探索自建航天器形成直接对照。
从已披露信息看，Satlyt 的软件要跑在别人的卫星上，可能无法控制处理器性能、功耗分配和散热条件。如果卫星制造商不预装 GPU，Satlyt 能做的事可能局限于现有处理器能支撑的轻量级推理任务。Afullo 的判断是：“如果你发射卫星却不放 GPU 上去，至少是在给自己找麻烦，对吧？”这句话反映的是他对行业趋势的押注，但趋势何时变成普遍现实，来源材料没有给出时间表。
与 Axiom Space 的比较更能说明问题。Axiom 在建造商业空间站模块，其计算需求是空间站级别的、有人参与的、地面可维护的。Satlyt 面对的是无人卫星、功率受限、辐射环境下不可物理维护的计算场景。两者虽然都被归入“太空计算”，但工程约束完全不同，更多是资本叙事上的归类，而非技术路线上的直接竞争。
800 万美元能买到的，是两次飞行和一次跨星演示的入场券
Satlyt 披露的资金用途是：加速太空虚拟 AI 数据中心开发，扩充工程与客户交付团队，并在其他公司运营的航天器上扩大软件部署。来源材料未披露本轮资金的具体分配比例与烧钱速度，无法评估 800 万美元的覆盖周期。
公司已经完成两次演示任务，第三次计划随 SpaceX Transporter-18 任务发射升空。但需要区分两个里程碑：发射成功与星上成功执行是彼此独立的事件。Space in Africa 的报道明确写道：“发射与成功在轨执行是分开的里程碑；结果将在应用于轨道运行后评估。”这意味着，即使火箭发射顺利，Satlyt 的软件能否在 TakeMe2Space 的卫星上稳定运行 NASA 协议测试和 Stellerian 的图像处理负载，仍需要等待在轨数据。
更关键的验证节点在明年。公司预计明年尝试演示跨两颗卫星的共享云。这是从“单星处理”到“跨星协调”的第一次技术跳跃。从已披露信息看，当前计划中的部署是在一颗航天器上运行两个应用，尚未演示跨多颗航天器协调计算。如果明年的跨星演示成功，Satlyt 的“虚拟 AI 数据中心”叙事将从概念进入可验证阶段；如果失败或推迟，公司仍可退守单星效率提升的生意，但那将是一个更小、更接近传统星上软件供应商的市场。
非洲总部不是叙事装饰，但商业转化路径仍未跑通
Satlyt 的双总部结构——美国加州森尼韦尔与肯尼亚内罗毕——在本轮融资中被反复提及。据 Space in Africa 报道，其领导团队全部为肯尼亚裔美国人，在内罗毕有大量工程人员。Afullo 在 TechCabal 采访中把这件事上升到了数据主权的层面：“如果非洲在太空行业没有重要立足点，我们将与世界其他地区脱节，我们将永远依赖别人提供我们的数据。”
这个叙事有真实的组织基础：内罗毕的工程团队、与肯尼亚航天局和安哥拉 GGPEN 的谅解备忘录、以及非洲背景投资方的参与。但从商业角度看，谅解备忘录到付费合同之间还有相当距离。非洲航天机构的预算规模有限，且多依赖政府拨款和国际合作项目。Satlyt 的非洲布局更可能先通过研发合作和人才供给产生价值，而非直接贡献大额收入。Afullo 自己也承认，公司当前的重点是让卫星更高效，而不是“现在就去替代数据中心”。
最大的风险不是技术，是“跨运营方”三个字
Satlyt 的长期愿景是让不同运营方的航天器组成共享软件层，协调计算资源。这个愿景的成立条件比技术演示更苛刻。首先，卫星运营方是否愿意让第三方软件接入自己的航天器计算资源，涉及安全、遥测数据访问权和故障责任划分。其次，跨运营方共享算力意味着需要解决任务优先级冲突：当两颗卫星的计算资源被协调时，谁的 AI 任务先跑？如果一颗卫星进入安全模式，共享云如何降级？这些运营层面的问题，来源材料完全没有涉及。
从已披露信息看，Satlyt 的延迟容忍网络技术研发，是在为跨星通信做技术准备。NASA Glenn STTR 项目与休斯顿大学的合作方向，是让航天器系统在延迟与中断下仍能通信与交换数据。这是跨星协调计算的基础设施层。但 DTN 技术本身并不新鲜，NASA 和学术界已经研究多年。Satlyt 的增量在于把它与商业卫星软件层结合，但这个结合尚未在轨道上验证。
另一个待验证假设是卫星算力的供给增速。Satlyt 的商业模式依赖卫星制造商预装或改装足够的计算硬件。如果卫星行业继续以低功耗、低成本的嵌入式处理器为主流，Satlyt 的可服务市场将被限制在少数高端卫星上。Afullo 押注 GPU 会成为卫星标配，但这一判断目前只是行业趋势推演，来源材料没有提供卫星 GPU 渗透率的数据。
从本轮投资方的表态看，Non Sibi 的 Kent Lucas 刻意降低了预期门槛：“我们不需要太空数据中心，Rama 就能非常成功。”这句话的潜台词是：即使跨运营方共享云的愿景落空，只要卫星数量增长、单星效率提升的需求存在，Satlyt 仍有生意可做。但这同时也划定了本轮投资的风险边界——投资方在为单星软件层付费，跨星云是期权，而非本轮必须兑现的承诺。
验证边界与可复核指标
本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述，如无另行说明，均是公司、创始人或投资方在现有公开材料中的披露口径；RecodeX未在本次采集材料中找到独立审计或第三方测试结论，因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析，不代表相关结果已经实现。
- 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果；
- 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化；
- 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。
RecodeX 极客视：Satlyt 用 800 万美元买到了一张进入在轨计算牌桌的门票，但真正的赌注不在 Gemma 能压缩多少日志，而在卫星运营商是否愿意把计算资源开放给一个第三方软件层。跨运营方共享算力的愿景，技术上是延迟容忍网络与星上推理的结合，商业上却是对卫星行业封闭生态的一次试探。在 GPU 尚未成为卫星标配、跨星协调尚未演示之前，Satlyt 最扎实的资产或许是它同时站在硅谷与内罗毕的双重位置上——一边是 NASA 的研发合同，一边是非洲航天机构的关系网络。但关系网络要变成收入，中间还隔着从谅解备忘录到付费部署的漫长距离。
信息来源
本文在采集与核验阶段引用了以下公开来源，按站点去重列出；来源内容归原发布方所有，其口径不代表 RecodeX 的核实结论。