NASA 将 Gemma 3 送入轨道:Google IEEE 报道聚焦边缘 AI
- Sophie Larsen

- 46分钟前
- 讀畢需時 15 分鐘
NASA 已完成一项开创性的轨道测试,利用 Google 的 Gemma 3 分析宿主卫星拍摄的图像。这则 Google IEEE 报道之所以重要,在于该模型直接在星上完成分析,无需先将每一张图像传回地球。
NASA 喷气推进实验室开发了名为 NAVI-Orbital 的软件系统,并将其部署在 Loft Orbital 的 YAM-9 卫星上。该系统采用运行于 Nvidia 硬件上的紧凑版 Gemma 3,可描述图像并回答有关图像内容的自然语言问题。
这并不意味着大型轨道数据中心已准备好取代地面计算。它支持的是一个更具体、更务实的观点:卫星可以利用紧凑型通用 AI 模型,判断哪些信息值得占用稀缺的下行传输容量。
这一差异构成了核心张力。传统地球观测系统采集数据后,通常由地面专家在稍后进行处理。NAVI-Orbital 则将解读工作移至更靠近传感器的位置,同时让 AI 与关键飞行控制系统保持隔离。
NASA 将图像解读移至卫星端
关键变化不在于 AI 模型进入了轨道,而在于模型在数据产生地分析了新的图像。
根据该项目的技术预印本,NASA JPL 研究人员于 2026 年 4 月 16 日在轨测试了 NAVI-Orbital。作者称,这是首次在轨演示利用视觉语言模型进行自主多模态推理。
视觉语言模型可同时接收图像与文本,并基于两者的综合含义生成文本。在本次测试中,Gemma 3 检视了 YAM-9 拍摄的图像,并生成对可见特征的描述。
研究人员在法国图卢兹上空和阿根廷沿海进行了实时测试。Gemma 3 描述了拍摄到的场景,并回答了有关城市区域、住宅开发和自然特征的预设问题。
这项实验比运行一个固定的图像检测器要求更高。传统分类器通常在基于标注样本训练后,识别预先设定的一组对象。其类别和输出格式通常也会受到该训练的限制。
NAVI-Orbital 则采用零样本分类。这意味着,该模型在未针对 YAM-9 相机或其特定图像类别进行微调的情况下,尝试完成新的分类任务。
在地面测试中,该系统在一个包含 7,960 张航拍图像的精选基准集上实现了 88.16% 的准确率。研究人员通过该测试,在依赖实时在轨拍摄数据前评估模型表现。
这些轨道图像均为新采集内容,未曾出现在 Gemma 3 的训练数据中。研究人员还在星上处理了未经校正的图像,使测试更接近实际运行流程。
NASA 并未为这项任务专门构建定制基础模型。NAVI-Orbital 使用的是 Google 四十亿参数 Gemma 3 模型的压缩四比特版本。
量化是指用更少的比特存储模型数值的过程,可降低内存和计算需求。这使该模型能够在 Nvidia Jetson AGX Orin 模块的八 GB 内存上运行。
YAM-9 搭载了一个共享计算集群,包含 CPU、GPU 和现场可编程门阵列。这些处理器支持多个托管载荷的工作负载,而非只服务于 NASA 实验。
卫星的太阳能电池板会根据轨道位置提供 150 至 500 瓦的电力。与地面数据中心相比,这一功率范围微乎其微,但足以完成这项边界明确的推理任务。
该实验还使用 LangGraph 协调独立的检测与对话组件。基于图的状态机控制由哪个组件接下来执行,并约束信息在工作流中的流动方式。
这种编排至关重要,因为单靠语言模型并不能构成可靠的航天器应用。外围软件决定模型能看到哪些数据、接收哪些提示,以及哪些操作始终被禁止。
IEEE Spectrum 的轨道测试报道称,Gemma 3 无需进行任务专用的模型修改。研究人员调整的是提示和工作流指令,而不是重新训练底层模型。
这种灵活性解释了 NASA 为何认为该实验不只是又一次图像分类测试。航天器运营方可以用日常语言描述新的目标,而不必为每项观测任务都部署一个新的检测器。
这一结果引出了本文的核心冲突。卫星传统上采集原始测量数据,再传回地球进行解读。NAVI-Orbital 则让航天器在数据传往任何地方之前,先给出有用的初步解读。
为什么 Google IEEE 测试瞄准下行链路瓶颈
NAVI-Orbital 对“采集一切”的模式形成压力,因为卫星产生的图像往往多于其能够快速传输或审阅的数据量。
地球观测卫星能够覆盖广阔区域并采集高细节数据,但它们无法与地面保持无限容量的连接。许多卫星只能在预定过境期间通信,或通过容量有限的中继网络传输数据。
原始图像的传输成本很高,因为每个场景可能包含跨多个光谱通道的数百万像素。传输每一次拍摄结果,还会带来云层、空旷地形、重复观测和与任务即时目标无关的场景。
地面处理还会增加延迟。数据传输后,可能还需要校准、存储、建立索引、分析和审查,才能成为人们可用的预警信息。
NAVI-Orbital 改变了这一顺序。卫星可以先检查图像、生成简短描述,并判断场景是否符合运营方的问题。
Loft Orbital 将其称为语义压缩。系统不是在保留完整图像的同时压缩每一个像素,而是提取含义,并传输一份关于相关内容的简明说明。
Loft Orbital 总经理 Paul Lasserre 在 IEEE 报道中说明了这种规模差异。一段文本回复可能只需几十 KB,而原始图像则可能需要几十或数百 MB。
这并不意味着原始数据变得不再必要。科研用户仍需要原始测量数据来进行验证、定量分析和长期记录。生成的描述无法替代经过校准的传感器数据。
更现实的工作流是利用 AI 进行分流。航天器先发送紧急摘要,随后优先传输相应源图像,供人工复核。
野火检测说明了这种排序为何重要。卫星可能拍到火灾迹象,但通信和处理延迟可能会推迟可用结果的产出。
星载模型可以立即标记烟雾、火情或变化中的地形。它可在下一次可用通信窗口发送紧凑预警,并优先传输支持该预警的图像。
同样的模式也适用于洪水、风暴损害、非法捕捞、作物胁迫和基础设施监测。每种应用都更看重快速识别异常场景,而非立即交付每一项观测数据。
这一模式也改变了运营方分配下行传输容量的方式。卫星可以将更多带宽用于符合任务目标的图像,减少用于可预测或低价值拍摄内容的带宽。
因此,这则 Google IEEE 报道指向的是边缘计算,而不仅仅是太空中的计算。边缘计算是在数据源附近处理数据,适用于延迟、带宽、隐私或连接条件使云端处理不那么合适的场景。
卫星由此成为智能边缘设备。其传感器采集数据,本地处理器提取含义,地面系统则接收经优先排序的结果。
这种设计对那些假定采用集中式处理流程的供应商构成压力。地面云平台依然不可或缺,但其角色将转向验证、聚合、模型开发和更深入的分析。
卫星运营方也面临战略选择。他们可以继续发射与预定义目标绑定的专用模型,或采用具备更强运行保障机制的适应性基础模型。
第二条路径提供了发射后的灵活性。团队可以通过更新提示和工作流配置,将同一模型从城市分类重新定向为野火筛查。
更新提示所需的工作远小于上传替换模型,也可以避免重新训练和打包新分类器所需的时间。
不过,灵活性也带来新的验证工作。工程师必须测试每一项提示是否能在季节变化、相机条件、地点和异常场景下产生可靠行为。
因此,经济问题并非星载 AI 是否能消除地面基础设施,而是更早的筛选能否创造足够的运行价值,以证明计算功耗、工程投入和额外任务风险的合理性。
对于时间敏感型观测,这一理由是可信的。对于档案测绘或高精度科学测量,原始下行数据和地面分析仍然居于核心地位。
紧凑型模型比轨道数据中心更早承担起实用任务
该实验更支持小型、贴近任务的推理,而非将通用 AI 数据中心搬到轨道上的宏大构想。
轨道数据中心的倡导者设想,卫星可搭载 GPU 机架,用于商业模型推理或训练。这类系统希望利用充足的太阳能,同时避开地面电网的限制。
这一愿景面临严峻的工程约束。高性能处理器会产生大量热量,而真空环境无法进行普通的空气冷却。太空系统必须通过散热器排出热量。
辐射也可能损坏电子元件或导致计算出错。维护更加困难,因为技术人员无法轻易更换故障的加速器、电力系统或网络组件。
大型分布式模型还面临另一项障碍。训练和服务前沿系统可能需要众多加速器之间进行高速通信。在分散的航天器之间复制地面数据中心网络,仍是一项重大挑战。
IEEE 报道的一项轨道推理提案设想部署数千颗卫星,每颗卫星均搭载紧凑型 GPU 服务器。其首个原型测试计划于 2027 年进行。
NAVI-Orbital 解决的是另一类问题。数据本就存在于卫星上,因此系统无需仅为在太空中计算而从地球传送大量输入数据。
这种数据本地性改变了经济性。地球观测相机持续在星载处理器旁产生信息。本地推理减少了通信流量,而非通过地面站建立新的往返传输。
其工作负载也受到限制。一个四十亿参数模型偶尔分析卫星图像,所需基础设施远少于为数百万无关用户提示提供服务的前沿模型。
NASA 的设计使用了内存需求为八 GB 的四比特模型。这样的规模可容纳在常用于机器人和其他边缘应用的嵌入式计算模块中。
Google 将 Gemma 3 设计为一个开放权重模型家族,提供 10 亿、40 亿、120 亿和 270 亿参数版本。其 Gemma 3 guide 表示,多模态版本可接收图像和文本输入,并生成文本输出。
该模型家族支持最高达 128,000 个 token 的上下文窗口,并支持 140 多种语言。但这些更广泛的能力并非此次轨道实验的重点。
关键在于可移植性。研究人员可以获取模型权重,压缩 40 亿参数版本,并在自身受限的软件环境中运行它。
开放权重也有助于本地部署。卫星无法依赖持续可用的外部应用程序接口,因为连接并不稳定,而且数据最初就在机上产生。
因此,NAVI-Orbital 更有力地证明了紧凑型模型的价值,而非基于太空的云计算。它表明,在内存、电力和通信都受到严格限制的条件下,AI 仍可完成有用的工作。
由于 Gemma 与规模大得多的语言模型同属广义类别,Google 和 IEEE 的表述很容易被误读。然而,参数数量本身并不能定义实际运行中的价值。
当一个较小的多模态模型部署在独特传感器旁边时,可能创造更大价值。它的目的并非回答所有问题,而是在通信瓶颈出现前解读任务数据。
这一经验也适用于航天器之外。工厂、车辆、机器人、医疗设备和偏远研究站,都面临本地推理与集中式处理之间类似的取舍。
当一个通用模型无需持续连接即可处理多项相关任务时,每种环境都会受益。但它们同样需要控制措施,将模型限制在安全、可审查的输出范围内。
因此,NASA 的演示推进了一种混合架构。紧凑型模型在边缘端处理即时解读工作,而更大型的系统和人类专家则在地面开展更深入的分析。
这两种方式相辅相成,但会争夺任务设计层面的关注。一种需要在轨部署庞大的新基础设施;另一种则为已在收集宝贵数据的航天器增加定向智能能力。
定向方案已率先进入实际运行。它如今提供了一项可量化的好处:在操作人员了解场景内容之前,需要立即传输的无关像素更少。
自然语言控制止步于安全边界
最值得关注的能力仍被刻意限制,因为 Gemma 3 可以分析图像,却无法控制 YAM-9 的飞行系统。
NASA 研究人员将基于提示词的交互描述为相较传统航天器操作的一项重大转变。科学家通常会将目标转换为结构化指令,并通过正式的运行流程进行审查。
NAVI-Orbital 允许科学家用自然语言描述图像分析目标。系统在决定如何对已捕获场景进行分类或讨论时,会纳入该提示词。
这并不意味着让聊天机器人指挥卫星。根据 IEEE 的报道,该实验将 NAVI-Orbital 与航天器的飞行软件隔离开来。
该模型可以读取选定图像并生成文本。它能够决定如何在自身应用内路由分析任务,但无法改变卫星轨道,也不能操作无关系统。
这条边界并非临时附注,而是核心设计。视觉语言模型可能生成不准确的描述、忽略细微特征,或以过度自信的方式表达不确定结论。
文本摘要中的错误或许只会浪费分析人员的时间。若错误涉及推进、姿态控制、通信或电源管理,则可能危及整项任务。
地面基准测试也存在局限。88.16% 的准确率表明其分类性能具有实用价值,但仍意味着相当一部分结果不正确。
经过筛选的航拍图像基准无法覆盖所有在轨条件。云层、薄雾、异常光照、传感器噪声、季节变化和陌生地形,都可能影响模型表现。
两次实际演示提供的证据强于实验室模拟,但仍仅是两次捕获结果。它们无法证明该系统在不同地区、任务类型或长期运行中的持续可靠性。
所报告的零样本表现也带来另一项取舍。不进行微调可让操作人员快速重新定向模型,但专用模型在狭窄且对安全敏感的任务上可能表现更好。
基于语言的界面也可能引入歧义。两位科学家可能以不同方式描述同一目标,而提示词的细微变化也可能改变模型输出。
经过验证的指令序列具有可预测性,因为工程师定义了其语法和允许的结果。自然语言对人类更易使用,但其灵活性使穷尽测试更困难。
因此,周边工作流必须将开放式请求转换为受约束的操作。它应验证提示词、限制可用工具、记录输出,并在产生重要后果的操作前要求确认。
该项目基于图的编排方式支持这一模式。不同智能体分别负责检测和对话,而预定义软件控制其执行顺序和权限。
这更接近受监督的分析助手,而非自主航天器指挥官。随着开发人员扩展该系统,这一区别应始终保持明确。
NASA 曾讨论过一种更长期的设想,即由自然语言 AI 协助宇航员。这类助手可能检索程序,或在航天服限制灵活性的情况下帮助用户与设备交互。
这一愿景仍远超已报告的图像测试。它需要广泛验证、可靠的传感器依据、故障恢复能力,以及关于人类权限的明确规则。
模型的描述还需要可追溯性。操作人员应能将每项结论关联至原始像素,并检查置信度、替代解释和处理历史。
如果摘要成为唯一传输的内容,语义压缩可能掩盖重要背景。模型可能遗漏意外特征,只因为提示词没有要求关注它。
这正是原始图像仍然重要的原因。只要某项警报影响科学、商业或公共安全决策,卫星就应保存源数据,并下传选定的原始图像。
网络安全也带来另一项担忧。提示词更新形成了灵活的控制界面,因此操作人员必须验证指令身份,并防止未经授权的任务下达。
输入还可能包含影响模型行为的异常视觉模式。太空环境并不会消除对抗性风险,尤其是在安全或国防应用中。
这些担忧都不会否定机载多模态推理的价值。它们界定了将演示转化为可靠运营服务所需完成的工作。
可信的近期路径是将 AI 保持在狭窄的分析边界内。它让模型提出优先级建议,同时由经过验证的软件和获得授权的人类保留控制权。
NASA 早期轨道 AI 工作设定了竞争节奏
NAVI-Orbital 属于一项更广泛的转变:从专用机载检测器转向可适应多种观测任务的基础模型。
将 AI 部署得更接近轨道传感器的,并不只有 NASA。各国航天机构、研究机构和卫星公司都已测试用于云检测、灾害监测和图像筛选的机载处理技术。
一个有价值的比较对象是 Prithvi——由 NASA 和 IBM 研究团队开发的地理空间基础模型。不同团队已将其压缩版本部署在 Kanyini 卫星和国际空间站载荷上。
NASA 将 Prithvi 描述为首个部署到轨道上的地理空间基础模型。其 Prithvi demonstration 在两种计算环境中进行了洪水和云层检测。
Prithvi 与 Gemma 3 所处的位置不同。Prithvi 专门基于 Landsat 和 Sentinel-2 观测的地理空间数据进行训练。Gemma 3 则是为更广泛视觉和语言任务设计的通用多模态模型。
这种差异形成了一项重要比较。领域专用基础模型可以编码细致的地球科学模式,而通用视觉语言模型则提供灵活的提示词使用方式和对话式输出。
未来的卫星系统可能会结合两者。通用模型可以理解操作人员的问题,而专用模型则执行定量检测或分割。
其结果将类似一支小型机载分析团队。一个组件负责对话,另一个负责特征检测,而确定性软件负责检查权限并规范输出格式。
Loft Orbital 的角色也表明商业模式正在转变。YAM-9 为多个客户载荷提供处理硬件,使软件实验无需专门建造一颗卫星。
托管式轨道计算降低了研究团队的门槛。开发人员可在共享基础设施上测试模型,而平台提供方则负责航天器运行和通用硬件。
这种方式可能催生可上传分析工作负载的市场。客户将部署受约束的应用程序,处理自身传感器数据或共享观测数据。
云公司已围绕虚拟机和无服务器函数建立了类似市场。轨道平台面临更严格的资源、可靠性和调度限制,但这种服务模式并不陌生。
Nvidia 将从这一方向中受益,因为其 Jetson 模块已支持机器人和边缘推理。当 Gemma 成为无法依赖 Google 云服务环境中的可移植模型时,Google 也将受益。
NASA 则获得了另一种在发射后重新配置任务的方式。科学家可以向现有仪器提出新问题,而无需替换整套机载分析系统。
传统航空航天供应商面临支持更具适应性的软件环境的压力。它们的优势仍在于飞行经验、抗辐射能力、验证能力和长期可靠性。
通用 AI 开发商则面临相反压力。他们必须证明,灵活模型能够在受到严格限制的运行系统内表现得可预测。
竞争并不只是 Google 与另一家模型供应商之间的竞争。它是可适应的软件与固定任务逻辑之间的竞争,而可靠性使任何一方都无法彻底胜出。
对于能够完整定义正确行为的计算和控制任务,固定软件仍然更可取。当传感器解读涉及不断变化的类别和不完整指令时,基础模型才更具吸引力。
Google 和 IEEE 的报道捕捉到了这两种方法开始共存于同一航天器上的时刻。确定性飞行软件维持任务稳定,而通用模型负责不确定的视觉解读。
这种分工很可能定义早期运营采用方式。卫星公司不会仅因模型的图像描述看似令人信服,就将关键控制权交给不受约束的模型。
它们会在错误可恢复、收益可衡量的领域引入 AI。图像分流、自然语言检索和观测优先级排序都符合这一特征。
三项信号将表明轨道 AI 是否已准备就绪
下一阶段必须证明可重复的性能、有价值的带宽节省,以及在脚本化演示之外实现安全扩展的能力。
第一项信号是在大量图像捕获中的持续运行。研究人员需要涵盖不同天气、地形、光照、季节和传感器条件的结果。
更大的运行记录将强化这样一种主张:通用视觉语言模型能够处理超出精选基准范围的图像。若频繁出现自信但错误的结果,则会更有利于专用分类器。
第二个信号是下行链路的改善情况。未来的报告应比较传输字节数、告警延迟、能耗,以及送达分析人员的有效场景数量。
这些指标将揭示语义压缩是否创造了运营价值。只有在能够识别出正确图像、并保留访问支撑数据的能力时,简短摘要才有帮助。
第三个信号是对提示接口的受控扩展。关注运营人员能否在无需重新训练的情况下上传新任务,同时模型仍与关键飞行系统保持隔离。
成功的任务重设将支持 NASA 的说法:自然语言能够减少更新任务分析所需的工作量。若要获得飞行控制权限,则需要高得多的证据标准。
更大的启示已经显现。实用的轨道 AI 并不需要数千块 GPU、漂浮在太空中的云区域,或取代地面计算。
它需要让紧凑型模型匹配那些传输成本高、却又需要快速解读的数据。NASA 对 Gemma 3 的测试在卫星图像中找到了这种匹配。
对开发者而言,实际问题是他们自身的工作负载是否具有相同特征。数据是否产生在远离可靠网络的地方?本地模型能否安全地对其进行压缩和筛减?
对卫星运营商而言,问题则更为严格:机载 AI 能否在确保每一项重要决策都可审查的前提下,节省足够的时间和带宽?
下一次 Google IEEE 更新应根据这些运营结果来评判,而非只是又一个模型被送入太空的新奇性。关注采集数量、下行节省,以及控制边界。


