Satlyt 获得 800 万美元种子轮融资，开发运行在卫星计算机上的软件。其眼前的商业理由，比太空巨型数据中心更具体，也更容易衡量：在数据产生处附近分析遥测、日志和图像，再利用紧张的下行带宽传回更有价值的信息。
更大的目标，是让计算能够跨不同制造商的航天器移植。Satlyt 已有飞行经验和客户实验，但尚未展示跨不同卫星的分布式云。只有将这些阶段分开，才能理解这笔融资对应的机会与风险。
被内部否决的提案，变成获得融资的软件公司
创始人 Rama Afullo 曾在 Google 云业务工作，2024 年加入 SpaceX 的 Starlink 业务。他向 TechCrunch 表示，两家公司当时都否决了他的轨道计算内部提案。随后他联合创立 Satlyt，在加州桑尼维尔和肯尼亚内罗毕开展业务。
本轮由休斯敦的 Non Sibi Ventures 领投，其合伙人包括前 NASA 宇航员 Bernard Harris。Satlyt 称，软件已参加两次演示飞行；最新披露的部署使用印度 TakeMe2Space 提供的卫星计算硬件。
这次任务包含三类不同工作负载。NASA 付费测试太空云计算协议，轨道监视公司 Stellerian 计划评估图像处理，TakeMe2Space 希望展示承载外部软件的能力。这些是目的不同的客户实验，并不能证明成熟的共享轨道服务已经成立。
Afullo 希望在本十年结束前覆盖 20% 的卫星。Satlyt 还称，2026 年已为最多 50 艘航天器部署准备软件。但目标和准备容量，都不等于实际运行的安装量、付费续约或经独立证实的市场份额。
最清晰的早期结果，是更小的诊断消息
Satlyt 在 Momentus 运营的卫星上，通过 llama.cpp 部署了量化后的十亿参数 Gemma 3 模型。量化通过降低数值精度减少内存与计算需求。Gemma 案例说明介绍了其本地分析遥测、应用日志和软件错误的过程。
在两种故障注入情境中，诊断载荷分别从 1,319 字节降至 469 字节、从 1,318 字节降至 464 字节，缩减 64.4% 和 64.8%。模型生成了简短诊断与建议操作；这两个情境中报告的生成速度均超过每秒 22 个 token。
公司范围更广的测试还考察了推理期间约 11 瓦的处理器功耗，以及 3 至 5 摄氏度的温升。这些是受限条件下的公司测量，不能当作经过独立验证的整支卫星舰队运行画像。诊断载荷变小，也不代表每一种故障都能正确诊断。
实际机制很直接：在通信窗口到来前先概括故障，而非将所有原始日志下传。地面团队可能收到更小、更有用的报告。图像处理也可在传输前剔除被云遮挡的画面，或优先处理可能包含监视目标的图像。
这些属于边缘计算应用，无需先建成庞大的轨道 AI 集群。经济收益取决于任务的带宽合同、人员配置和响应需求。有效证据应把节省的字节数，与更快排障、更高价值图像或更少地面工作联系起来，同时报告准确率、能耗和内存占用。
可移植与垂直整合，解决的是不同问题
Afullo 用轨道版 iPhone 比喻 SpaceX，用 Android 比喻 Satlyt。区别在于跨多种硬件的软件层，与紧密协同的整套系统，而不是两家公司规模相当，也不是 Satlyt 已成为开放行业标准。
SpaceX 控制发射、卫星制造、连接能力及大量运行环境。整合能够简化接口，并协调供电、链路和处理器。客户也可能接受依赖同一家公司的路线图、发射计划或定价，以换取部署和支持更简单。
Satlyt 不计划制造卫星，而是以 VMware 和 Snowflake 比喻其抽象层，希望应用减少对特定物理设备的依赖。更多兼容制造商有望吸引开发者，更多应用又能吸引制造商。眼下，公司必须解决双方都在等待对方的冷启动问题。
Google 的 Project Suncatcher从自有 TPU 硬件与太阳能互联卫星出发。其与 Planet 合作制造的原型用于测试发射、辐射和热环境影响。Google 称，原型已于 2026 年 10 月 1 日进入轨道，搭乘 SpaceX Transporter-18，随后建立联系并开始测试。
共享发射资源，不意味着架构相同。Google 验证专用硬件能否在太空工作，Satlyt 验证外部客户能否使用跨非自有计算机的软件。两者目前未必直接竞争，将来也可能互补。
航天器安全决定共享层的边界
地面服务器通常具有标准接口、可靠网络和现场维修条件。卫星却面对辐射、热循环、间歇链路、轨道运动与严格功耗预算。处理器、操作系统和任务优先级各异，许多卫星也没有为交换大型计算负载而设计的链路。
Google 将设想中的激光链路瞄准难度，比作在数英里外命中一枚不断移动的硬币大小目标。发射部件可能承受 50 至 100 倍重力，辐射可能改变存储数据，真空又无法采用普通气流散热。只有获得可靠遥测和足够操作权限，软件才能围绕这些物理限制调度。
第三方工作负载不能占用导航或主要载荷所需的内存、能源和通信能力。应用隔离、签名更新、访问控制、审计记录和紧急停止权限，都是验收要求，而非可选平台功能。跨运营方管理，也会成为有吸引力的网络攻击目标。
AI 可能误诊故障或错误识别图像，因此向地面人员提出建议，与直接指挥航天器不同。Satlyt 称，在推进异常检测和多智能体决策时，运营方仍保留指挥权；这条边界需要在实际集成中验证。
商业激励可能与技术一样困难。有闲置处理器时间，并不代表承担外部任务责任和收入分配条件就划算。没有通用接口，每次集成都可能变成定制工程，削弱平台赖以成立的可重复软件经济性。
下一步要证明的不只是成功发射
Satlyt 预计明年尝试跨两艘不同航天器的计算。有意义的披露应说明具体平台，并展示协同处理、延迟、资源使用和故障恢复，而不仅是交换消息。两台相同设备可能证明分布式能力，却不能证明广泛互操作。
客户复购与独立航天器制造商加入，将增强商业理由。协议签署、硬件升空、负载实际运行和付费续约，证据强度并不相同。最有价值的运行数据应来自客户或研究伙伴，而不只是内部基准；与此同时，Google 推进星间链路，SpaceX 仍有部署规模优势。
任务报告、测试定义与合同可以归入可搜索的工程文档知识库。Satlyt 已超越纸面提案，但决定性承诺仍待兑现：在混合卫星群中，实现可移植、安全且经济上可重复的计算。能让星上工具升级为轨道平台的是这一点，而不是又一次 Android 比喻。