AREX Feed Article
Google Gemma 官方推介 Satlyt 案例，称星上 Gemma 3 1B 让诊断数据载荷减少逾 64%，下一发射目标是 Gemma 4 E2B
北京时间 9 月 12 日凌晨，Google Gemma 的官方 X 账号 @googlegemma 发帖推介 Satlyt 在卫星上运行 AI 的案例。按帖文的说法，Satlyt 正把 Gemma 模型直接部署到卫星上，在本地分析遥测、诊断故障，把原始系统日志整理成紧凑摘要后再传回地球；在星上运行 Gemma 3 1B，能把诊断数据载荷减少 64% 以上。
帖文附上的案例研究链接，指向 Google DeepMind 官网上的 Satlyt 案例研究《How Satlyt is building local AI for space with Gemma》。称，Satlyt 已经把量化版 Gemma 3 1B 部署到一颗卫星上，通过 llama.cpp 运行，用于分析星上图像处理工作负载产生的系统日志、软件错误与堆栈轨迹；下一阶段，公司正在评估在 NVIDIA Jetson Orin Nano 上运行 Gemma 4 E2B，测量本地推理在内存、功耗、热与速度上的开销。
Satlyt 官网使用的卫星渲染图（原图透明背景，已合成黑底）。图源：
两次故障注入：从 1,319 字节到 469 字节
「逾 64%」来自 Satlyt 进行的故障注入基准测试：把常见软件错误人为注入一条图像处理管线，检验模型能否在星上给出可用的诊断。
案例研究列出了两个代表性场景。第一个是内存溢出：遥测快照显示 RAM 利用率达到 99.6%，系统日志记录了一次 OutOfMemoryError——OpenCV 预处理脚本尝试加载一张 12,000×12,000 的图像，申请 144,000,000 字节内存失败。第二个是硬件传感器故障：计算资源读数正常，但系统日志里有 tegra-i2c 控制器在地址 0x36 上无应答的内核告警，一次按计划进行的相机载荷拍摄触发了 OSError: [Errno 121] Remote I/O error。
在这两个场景里，模型把需要下行的诊断数据分别从 1,319 字节压到 469 字节（减少 64.4%）、从 1,318 字节压到 464 字节（减少 64.8%），生成速度为每秒 22.71 与 25.48 个 token。案例研究称，Gemma 结合遥测、系统日志与堆栈轨迹，给出了简洁的根因诊断和处置建议。
轨道窗口里的带宽账
航天器运营者把所有遥测和系统日志都传回地球，往往并不现实：带宽有限，轨道通信窗口短暂。案例研究指出，传统基于规则的解析器缺乏灵活性，难以解释复杂的堆栈轨迹；让模型在星上生成紧凑的诊断摘要和故障排除建议，就不必把大量数据下载到地面再逐条解析。这条路径有两个直接结果：下行的数据量变小，地面人员拿到关键洞察的时间变短。
Satlyt 评估过多个小语言模型，最终选择 Gemma，理由是推理能力与资源占用的组合。案例研究把取舍写得很具体：可行的模型必须能装进受限硬件、不依赖持续的云连接、稳定产出诊断结果，还要给软件栈的其余部分留出余量。
Satlyt 首席技术官 Nelson Kigen Psenjen 在案例研究中说：「我们关注的是让星上 AI 在真实航天器约束下变得可用。有了 Gemma，我们正在评估更小、更高效的模型如何在严格的功耗、热和内存限制内本地分析遥测、系统日志和故障。这一点对航天系统很关键：每一瓦、每一字节、每一秒下行时间都要精打细算。」
Satlyt 官网的控制平面示意图，标注了 SatDash 托管载荷、地面站与下行数据处理。（图源：Satlyt 官网）
下一阶段：Jetson Orin Nano 上的 Gemma 4 E2B
Google 的帖文写明了「下一个发射目标」：在 NVIDIA Jetson Orin Nano 上运行 Gemma 4 E2B，把进一步的推理与视觉能力带到「太空边缘」；案例研究的表述是，Satlyt 正在评估作为其星上 AI 下一阶段的 Gemma 4 E2B，并已经给出地面测试数据。
在 4 位量化（Q4_K_M）配置下，Gemma 4 E2B 在 Jetson Orin Nano 上的峰值内存占用约为 4 GB；设备共有 8 GB 系统内存，其余部分留给传感器采集、通信和遥测处理等机载服务。活跃推理时，处理器的总功耗升至约 11 瓦，比约 4 瓦的基线高出 7～8 瓦，处理器温度上升 3～5°C。太空没有空气对流，散热只能依靠辐射和传导，控制温升对防止硬件退化很关键。地面测试的生成速度为每秒 19.08 个 token，案例研究称这足以支撑近实时的本地诊断流程。
除了量化，Satlyt 还在用剪枝和蒸馏压缩单个星上 AI 工作负载：移除特定任务用不到的模态组件，为软件诊断等任务开发更专用的模型。部分诊断负载的目标是把模型内存占用减少 90% 以上；范围更大的优化，则瞄准把单个受管理的星上 AI 服务的内存占用减少约 85～90%，让更多专用负载能在同一套受限算力里并行运行。
从 26 KB 软件包到 50 次部署计划
Satlyt 此前已公开过 Gemma 在轨运行的进展。公司在 3 月 30 日的一篇博文里记录过两次任务：STL-01 / Genesis Signal 把约 26 KB 的 Python 系统上行到 Rogue Space 的卫星上（链路速率低至每秒约 20 KB），在轨执行遥测接收、压缩存储、早期异常检测和下行优先级排序；STL-02 / Orbital Intelligence 搭载于 Momentus 航天器（经 DPhi Space 任务），部署了基于 Gemma 小模型的 AI 故障排查代理，并做了合成错误注入与自主诊断。
Satlyt 官网的 Shuri Lab 页面另称，Gemma 3 已作为其星上 AI 栈的一部分在太空运行：在轨处理了图像，生成可供下行的加密输出，并诊断了多个注入故障。
Google 方面此前也提到过 Satlyt。8 月 20 日，Google 在一篇庆祝 Gemma 系列下载量突破 10 亿的博文里写道，NASA、Satlyt 和 Starcloud 的团队正把 Gemma 直接跑在轨道上，用于星上图像分析、优化稀缺的下行带宽和路由星间通信。
案例研究称，Satlyt 已经为 2026 年内最多 50 次航天器部署准备好软件包。Satlyt 创始人兼 CEO Rama Afullo 在 9 月 10 日的 LinkedIn 帖文里写道：「我们已经把 Gemma 3 部署到一颗卫星上」，用于在本地分析遥测、系统日志和故障，而不是把所有东西都传回地球。 他在同一帖文里把更大的目标概括成一句话：卫星不应只是收集数据，还应该能在数据产生的地方对它进行推理，也就是 Satlyt 所说的「太空中的虚拟 AI 数据中心」。
数字的出处与留在地面的指令权
这轮发布里的数字，均出自 Google 与 Satlyt 双方自己发布的材料：Google DeepMind 的案例研究、Gemma 官方账号的帖文，以及 Satlyt 高管的 LinkedIn 帖文。案例研究写明，基准测试由 Satlyt 执行；两个场景注入的都是人为制造的软件错误，而非在轨自然发生的故障。
Afullo 在案例研究里还说过：「航天系统是本地 AI 为什么重要的最清晰例子之一。你不能总是指望云连接，也承担不起把每条原始日志、堆栈轨迹或遥测流都下行的成本。Gemma 让我们可以在受限的在轨硬件上直接测试有用的推理，这是迈向更自主太空运营的一大步。」
自主的边界也写在材料里。Satlyt 在 Build with Gemini XPRIZE 的 Devpost 页面上把运营流程写得很细：Gemma 在边缘负责对遥测、日志、堆栈轨迹和软件故障做本地推理，Gemini 在地面担任任务运营代理，负责事件分类、根因分析、修复建议与恢复验证；整个闭环是监视、诊断、建议、批准、修复、验证、报告，其中涉及任务安全、客户政策或任务伙伴约束的行动，由人保留批准权。 案例研究也把同一句限定写进了路线图：从单个诊断流程扩展到更自主的星上分析、异常检测、摘要与多智能体决策支持，同时，航天器运营方保留指令权。
参考链接
- Google Gemma 官方 X 帖文：
- Google DeepMind 案例研究《How Satlyt is building local AI for space with Gemma》：
- Satlyt 博文《From Signal to Intelligence: Satlyt's First Missions in Orbit》（2026 年 3 月 30 日）：
- Satlyt Shuri Lab 页面：
- Google 博文《Inside the Gemmaverse: Celebrating one billion Gemma downloads》（2026 年 8 月 20 日）：
- Rama Afullo LinkedIn 帖文（2026 年 9 月 10 日）：
- Satlyt MissionOps（XPRIZE Devpost 提交页）：
- Satlyt 官网（文中图片素材来源）：