AI上星与太空算力：卫星智能化核心技术路线与工程落地

1. 这波AI上星到底在解决什么问题

太空算力、AI上星、卫星智能化，这三个词最近在圈子里刷屏的频率，几乎超过了当年的“微小卫星星座”。我做了十几年卫星数据地面处理和星载软件，前几年还在埋头优化传输协议，这几年突然发现，所有人的讨论焦点都从“怎么把数据传下来”变成了“怎么在星上先想清楚再传”。这个转变不是谁拍脑袋炒出来的，而是被真实数据逼出来的。

先说组数据。现在一颗普通分辨率的高光谱遥感卫星，单轨观测时间大约十分钟，产生的原始数据量通常在几十GB到几百GB之间。到了新型视频卫星或者雷达成像卫星，数据量更是轻松上TB。可星地链路呢？现在比较常用的X波段数传速率也就是几百Mbps，激光链路未来可能到10Gbps以上，但真正工程落地的还少。更关键的是，卫星对地面站的过站时间只有几分钟到十几分钟，也就是说，七八百GB的数据能在过站时完整传下来的概率很小。以前的标准做法是“先压缩，再盲传，最后地面筛”，于是大量包含有价值的图像被无效的云覆盖数据挤掉了带宽，地面人员辛辛苦苦接收到数据，清洗完能用的不到一成。

这个矛盾在传统单星时代还能忍，毕竟卫星少、用户少、排队传也能凑合。可当低轨星座变成几十颗、几百颗的规模后，再靠地面站“搬运工”模式就彻底顶不住了。于是行业开始把算力搬到星上，让卫星在采集数据的同时，自己先把“值不值得传”这个决策做了。AI上星和卫星智能化，本质上是把原来地面段的数据筛选、信息提取职责，前移到星载端，实现“在轨感知、在轨判断、在轨响应”。

1.1 算力上天，是被数据逼出来的

我最早接触“星上AI”这个概念时，还觉得是噱头。因为传统星载计算机的任务非常单一，无非是姿轨控计算、指令调度、遥测采集，CPU主频几十兆到几百兆赫兹，算力按MIPS算都嫌少。突然说要星上做目标检测，做语义分割，做时间敏感的目标识别，很多人的第一反应是：这不就是把服务器塞进卫星吗？

但实际业务需求已经等不及了。举个例子，我们做了一颗用于森林火点监测的试验卫星，以前是每隔几秒拍一张中波红外图像，全部存下来，等卫星过境后回传数据。地面工作人员经常收到几百张云下没有信息的图，真正能看到的火点信息还在文件深处，处理流程耗时几小时，完全没有“应急”的实效性。后来在星上加了轻量级卷积神经网络，专门做火点候选区域的粗检，只把置信度高的区域裁剪出来下传。结果回传数据量降了一个数量级，火灾预警时间从小时级变成分钟级。

这还只是单类目标检测。如果是做多目标识别、动态目标跟踪、星上自主拼接、星座协同调度，对算力的需求会更复杂。真正推动太空算力。快速落地的，不是概念，而是卫星任务从“定时拍照、地面分析”变成了“想拍就拍、过了不再后悔”的实时感知需求。换句话说，在轨AI不是选修课，而是低轨卫星实现规模化商业价值的必修课。

1.2 太空算力不是把地球的GPU搬上去

身边有不少从互联网大厂转来做卫星的人，上来就想把英伟达的GPU直接装到卫星上，觉得“反正低轨卫星几年就退役，扛不住辐射就换嘛”。这种想法在商业微小卫星上确实有一定市场，但真到工程落地，问题远比想象多。

太空环境首先就和机房完全不一样。真空环境下没有对流散热，一个二三十瓦功耗的GPU模块，在地面服务器里风冷轻松搞定，到了星上就得靠辐射板和导热结构一点一点往外排。卫星平台的功率预算通常只有几百瓦，整星给数据处理单元的份额往往不超过三四十瓦。如果一块GPU峰值功耗就到七八十瓦，基本就没法和其他分系统共存。

更麻烦的是辐射。低轨卫星虽然在范艾伦带下方，但依然会遭遇到高能粒子。单粒子翻转、闩锁、总剂量效应，每一个都能让地面上的“成熟板卡”在轨跑几个月后变成砖头。很多工业级AI芯片的制程特别先进，晶体管密度高，反而更容易受辐射干扰。我见过一块工业级NPU板卡在地面跑了一周没问题，上星后没到三天就开始出现频繁的“算错”现象，最后追查下来，是DDR内存里的位翻转没被纠错机制覆盖。

所以现在卫星智能化实际落地的算力方案，并不是简单把地球上的AI芯片搬上去，而是在功耗、性能、抗辐射、体积、成本之间找平衡点。一段时间里，大家用FPGA做低功耗定点推理，后来出现了专门为边缘设备设计的NPU，再往后，一些耐辐射等级的CPU加AI加速器的组合也开始出现。核心思路始终只有一个：够用就好，别跟跑分较劲。太空里不需要“最强算力”，只需要“在恶劣环境下还能稳定干活的算力”。

2. 卫星智能化的核心技术路线选型

从地面AI工程转到卫星AI，最明显的感受是“技术栈差距很大”。在地面做AI，框架随便选，GPU不够就再加几块。在卫星上做AI，每一步都得权衡：用什么芯片，用什么量化精度，用什么推理框架，裁多少模型层，缓冲区够不够，中断冲突怎么处理，数据回传策略怎么定。

2.1 星载AI芯片的选型思路

芯片选型是整个星上AI方案的第一步，也是决定后面几个月是否“舒服”的关键。目前能拉出来实战的选项主要有三类。

第一类是FPGA。典型代表是Xilinx的宇航级Zynq系列，以及一些抗辐射等级的国产FPGA（国内也有不少宇航级在推）。FPGA的优势是灵活，你可以把卷积层、池化层直接用逻辑资源搭出来，做到极低延迟，也可以在一个芯片里同时承担数传、接口控制等任务。缺点是开发周期长，RTL级别的AI实现难度高，除非直接用Vitis AI这种工具链把模型转成DPU，否则光是适配算子就够喝一壶。

第二类是专用边缘NPU。比如地平线的征程系列、瑞芯微的RK3588，或者寒武纪的一些边缘产品。这些芯片单位功耗算力很高，支持INT8甚至INT4量化，对于很多检测、分类任务来说完全够用，而且工具链相对成熟，PyTorch模型训练完可以直接导出，再做一些算子兼容性调整就能跑。缺点是绝大多数是工业级制程，没有宇航级抗辐射认证，需要额外做抗辐射设计遮挡或者选择商业版但有在轨案例的型号。

第三类是CPU加GPU的小型化方案。英伟达的Jetson系列在早期遥感小卫星任务里有一定应用，但这属于“用软件生态换代空间可靠性”的妥协方案。Jetson的CUDA生态确实太诱人了，很多算法工程师三天就能把模型部署上去。但它在轨寿命和功耗的问题也需要正视。我们早期做过一个技术验证，把Jetson Xavier NX放在一个6U立方星里，热设计极其痛苦，运行一段时间后整个结构件都在发热，最后不得不把推理频率限制在间歇式工作模式。

从我的个人经验看，2024年往后，中等以上算力需求的卫星应用，越来越多会选择FPGA加NPU的组合：FPGA负责接口、协议、前处理，NPU专职做AI推理。这种异构方案既保证实时性和可靠性，又能最大程度降低AI开发难度。如果项目周期紧，直接用一颗支持NPU的SoC做全部处理是最快的路径，前提是必须做充分的耐辐射评估。

2.2 模型压缩与轻量化部署

选完芯片，接下来就是如何把地球上跑得好好的大模型塞进星载的“小脑瓜”里。我在工程里常用四板斧：量化、剪枝、蒸馏、结构搜索。

量化是最立竿见影的。一个FP32的模型转成INT8，模型体积缩到四分之一，推理速度通常能提升两到三倍。星上常用的是INT8和INT16混合精度，极端情况下用INT4，但INT4对检测任务的位置回归头影响比较大，容易出现框偏移，所以目前最推荐的还是INT8为主。量化分为训练后量化和量化感知训练，我强烈建议做后者。训练后量化简单快速，但遇到激活值分布特别不均匀的层时，精度可能掉得很离谱。量化感知训练虽然要在训练代码里加一些伪量化节点，整体训练时间变长，但换来的是在保留95%以上精度的情况下还能跑得动。

剪枝的作用在于把模型里冗余的通道裁掉。卫星上模型解码器部分（也就是Detection Head）往往占的参数大头，而这些参数很多是冗余的。用结构化剪枝把通道数从256减到64，精度只损失不到两个点，推理耗时却能降一半。蒸馏就更直接，用一个大点的教师模型去教一个小学生模型，我们对比过，YOLOv5s用蒸馏后跑出来的效果确实比单独从头训练的小模型稳定，尤其是在边缘目标和小目标上的召回率有改善。

模型部署上，很多工程师第一反应是ONNX加TensorRT。但星载NPU的工具链往往不支持GPU上的所有算子，最后在ONNX转换时疯狂报错。我的建议是：先用目标平台的runtime充分调研算子支持列表再训练模型，而不是等训练完了再转换。一个典型例子是模型里的Transpose算子，在不同排布下转换效率差很大，稍微改改张量排列顺序，就能省掉大量transpose操作，推理延迟立刻改善。

2.3 功耗、散热与可靠性的算力约束

硬件选型只是第一步，热量和可靠性才是决定AI模块能不能长期工作的关键。

散热设计上，最常见的方法是“间歇性推理”。考虑到卫星绕地运行中，很多数据采集和推理任务本来就是突发的，没必要让AI模块满负荷连续工作。把任务分段，在观测前触发推理，做完立刻进入低功耗待机，既满足业务需要，又能把平均功耗压到峰值功耗的三分之一以下。这样散热设计就轻松很多，一块普通的铝制散热板加高发射率涂层就能压住。

可靠性方面，对抗单粒子翻转（SEU）是星上AI系统最核心的挑战之一。常见策略有三层：第一层，硬件上做ECC纠错。目前绝大多数NPU的DDR都支持ECC，但要注意是不是所有内存区域都覆盖了，尤其是权重缓冲区，很多低成本芯片只对部分内存做ECC，权重区恰恰容易“受伤”。第二层，软件上做看门狗和定期重启。AI任务进程不能出现永久卡死，可以通过外部看门狗定时检查推理状态，如果连续超时，就强制重启NPU驱动。第三层，算法上做冗余校验。关键推理结果可以做两次独立推理对比，或者用输出置信度做异常过滤，明显低于逻辑阈值的结果直接丢弃并要求重新采集。

提示：在轨AI系统设计时，一定要把“恢复时间”当作核心指标。不是不希望它出问题，而是要能快速从问题中恢复。一个可靠的星上AI，比一个功能强大但三天两头重启的AI要值钱得多。

3. 从地面Demo到在轨验证：我踩过的坑和实操流程

很多团队会说“我在地面已经把模型跑通了，为什么上星就不行”。我在这个环节上栽过不少跟头，后来总结出一套从地面仿真到在轨验证的完整流程，现在基本按这个节奏走，能规避大部分坑。

3.1 地面仿真环境搭建

首先是数据。星上AI面临的数据分布实际上和地面公开数据集差别很大。一个在ImageNet上训练的模型，直接放到卫星遥感场景，效果会非常难看。所以我们第一步不是搭环境，而是建立一套“回放系统”。把历史卫星下传的原始图像数据、传感器参数、平台姿态信息打包成一个时间序列，在实验室里模拟卫星飞行的场景。

数据回放系统里最关键的是时间同步和噪声注入。很多做AI的同事在看数据时，总喜欢直接拿“干净”的TIF影像训练。但真实星载相机的原始数据是有未校正的坏线、坏点、辐射噪声和条带效应的。我的建议是：至少留出20%的数据集，专门做“脏数据增强”，也就是把传感器噪声、丢包、压缩伪影直接加到训练数据里，否则模型在轨表现会大打折扣。

其次，硬件在环（HIL）仿真非常有必要。把模型部署到目标板卡上后，不急着去对接整星，先放在一个带模拟器的小机柜里，连续跑几天，观察温度、功耗、内存占用和推理结果稳定性。特别是内存泄漏问题，地面短时间测试很难暴露，只有长时间运行才能发现。

我合作过的一个团队，在地面用服务器跑模型精度96%，很得意，直接烧版。结果在HIL环境中只运行了四个小时，内存占用率从30%飙到85%，最后系统卡死。查下来是推理框架在每次调用时都会重新分配一块固定大小的中间缓存，但从未释放，连续调用几千次后内存耗尽。这种问题在服务器上几乎不可能出现，可在星载环境只是时间问题。

3.2 算法移植与算子适配细节

算法从一个训练框架切到另一个推理框架，总会碰上各种“意外”。最典型的几个坑，我这里详细说说。

第一个是Resize算子。很多检测网络里都需要把输入图像Resize到固定尺寸，但不同框架的Resize实现方式不一样，有些是“最近邻”，有些是“双线性”，有些还带着落在半像素的坐标偏移。看起来只是细微差别，可一旦输入图像里有细小目标，坐标一偏，目标就丢了。我们的解决办法是直接在预处理阶段做统一插值，把模型输入尺寸固定下来，不使用runtime自带的动态Resize。

第二个是LeakyReLU和SiLU激活函数的兼容性。很多低端NPU对激活函数做了优化，只支持Relu、Tanh这类“基础款”。如果你的模型用了SiLU（Swish），工具链可能会把它拆分成一堆乘法和Sigmoid的组合，导致推理速度下降。我建议要么换一个对激活函数友好的推理框架，要么直接用ReLU替代SiLU，精度损失会略微，但速度提升很多。

第三个是输出层的后处理。目标检测的NMS（非极大值抑制）在GPU上很容易实现，但在星载CPU上很费时。我们后来把NMS换成更简单的“中心点距离抑制”，或者干脆把TopK减少到前200个候选框，精度影响不大，速度却快了一个量级。记住，在轨AI的主要目标是将数据快速化为情报，不是参加目标检测比赛。

算子适配的经验是：写一个算子覆盖检查脚本，把模型用trace工具过一遍，生成不支持的算子列表，然后逐个替换。最好在模型训练阶段就用目标板的“模型设计指南”来约束网络结构，而不是等部署时再去适配。

3.3 在轨部署与上电联调流程

模型在地面准备完毕，还要经过严格的测试、评审，才能打包成固件上注。上注前，要做成独立的APP格式，与应用代码分开。

在轨部署第一步是与整星联测。我们会先上注一段简单的HelloWorld程序，确认计算单元的基本通信链路正常。第二步，上注AI运行时（Runtime）和模型权重，并检查加载后内存占用情况。第三步，用星上存储里的历史标准图像做一次回放推理，比对地面离线推理结果，看两者输出差异是否在允许范围内。这一步很关键，如果星上回放推理结果与地面不一致，基本可以判定是软错误或者算力板异常。

在轨联调中流程上还要准备几个应急预案。比如模型权重文件上注失败，怎么回滚到上注前的版本；推理任务异常退出，如何自动重启；重启后是否自动继续之前的任务。这些预案看着繁琐，但真实在轨中几乎一定会用到。

有一次我们在轨运行时，模型突然输出一批置信度全部接近1.0的检测结果，把成片的地面建筑都当成目标。排查后发现，是星上光学系统在工作时产生了轻微的温度梯度，导致图像对比度整体偏移。虽然模型有归一化层，但分位数范围变了，很多正常目标被误判。后来在预处理中加入了自适应直方图均衡化，这个问题才消失。所以，上星后一定不要机械照搬地面处理流程，要密切关注星上传感器状态，把输入分布变化作为首要监控项。

4. 常见问题与排查技巧实录

在星上AI落地过程中，很多问题是在地面完全碰不到的。我把这几年在轨测试和实际运行中遇到的高频问题整理成一张“问答表”，方便刚入行的朋友直接查。

4.1 单粒子翻转导致的推理异常

现象是模型偶尔输出一些完全离谱的坐标，或者某次推理结果突然全为0。首先排查是输入数据异常，还是权重被翻转。最简单的方法是保存基准输入和期望输出，每次上电后先跑一遍自检测试，把实际输出与基准输出比对。如果发现偏差，基本能确认是软错误，解决办法是重新初始化模型参数或者重启推理进程。

硬件层面，ECC只能检测部分内存单元，对AI加速器内部的寄存器文件几乎是“裸奔”。如果系统频繁出现单粒子翻转，可以考虑把关键权重做TMR冗余，在NPU外部存两份副本，加载后做交叉校验。当然这会多占一点存储和加载时间，但对于长寿命卫星来说非常值得。

4.2 推理耗时忽快忽慢

在轨AI最让人头疼的其实是“抖动”。明明单次推理平均时间20毫秒，但会出现偶尔一次跑到100毫秒以上。这通常不是AI芯片性能问题，而是算力板上的进程调度和内存带宽竞争。比如星务计算机在同时执行姿态计算、文件存储、遥测打包等任务，这些任务共享同一个DDR控制器和PCIe链路，AI推理被抢占后就会出现毛刺。

工程上我们用的办法是把AI推理任务绑定到一个独占的CPU核上，设置实时优先级，同时把数据读写缓冲区固定在大页内存里，减少页切换。如果这样还是抖动，就把所有任务分成“硬实时”和“软实时”，只保证硬实时任务（姿控、电源保护）的优先级最高，AI任务用软实时调度即可，允许偶尔延迟，但不要长期阻塞。

4.3 在轨模型漂移怎么处理

卫星在轨时间长了，太阳光照角度、地表季节、传感器增益变化，都会让输入数据分布慢慢偏离训练分布，模型精度会肉眼可见地下降。这是非常正常的。解决手段不是“在轨训练”，而是“模型OTA更新”。

我们每隔一段时间会把最新采集的有标注样本通过测控链路回传一小部分到地面，在地面重训模型，然后再生成新的权重文件，进行上注更新。关键点在于，OTA更新不能影响正在运行的业务。实际做法是采用双权重区，模型推理时从A区读取权重，新模型先从测控链路写入B区，全部校验通过后，再通过原子指令切换权重区指针，整个过程对业务无感。卫星智能化不是一次上星就结束，而是持续迭代的过程。

为了减少频繁上注更新的压力，我们还会在星上建立一个“边云协同”的机制：星上只做低延迟的粗筛和报警，地面负责精细分类和模型再训练。两边配合起来，才算一个完整的闭环。

4.4 快速排查清单

这张表不能覆盖所有问题，但能帮你快速定位80%的上星AI故障。最好的预防手段就是在研发阶段就建立“故障注入”测试，比如随机翻转权重位、断点重启、制造内存压力，把所有潜在异常都暴露在地面HIL环境中。

5. 卫星智能化带来的工程链条变化

AI上星不只关系到星载软件和硬件设计，它还会反过来重塑整个卫星工程体系，甚至改变地面系统、运营模式以及行业人才需求。

5.1 对地面系统的影响：从“搬运工”到“运维者”

过去的地面系统更像一个数据搬运工：接收原始数据、存储、分发给用户。随着AI上星，很多原始数据的筛选和初步分析已经在星上完成，地面站收到的将是“更高价值密度”的产品。地面处理系统的主要任务不再做低级的云判和目标准入，而是对星上的结果做交叉验证、精细解译以及快速分发。

这种变化对地面系统的改造要求很高。首先，地面系统必须具备快速接收和解析星上AI产品的能力，不能再按传统整轨数据块处理。其次，地面系统需要建立“在轨模型管理库”，跟踪每颗卫星当前运行的模型版本、精度指标、异常告警状态，为OTA更新提供依据。第三，地面系统处理AI结果的时效性本身就是竞争力。以前一轨数据要处理半小时，现在要求做到分钟级甚至秒级分发，所有流水线都需要优化。

我们团队在改造地面系统时，最大的难点是打破传统的“文件归档”思维。以往所有的数据都要存全量，现在则是重点存储星上AI产品的“决策上下文”，而非全部原始数据。这样做能节省大量存储成本，也让用户在改时间里更快拿到可用信息。

5.2 应用场景：哪些任务真正适合“AI上星”

不是所有任务都适合把AI放上星。我总结出的三个判断标准：第一，任务具有实时性要求，等数据回传再分析就晚了；第二，原始数据量巨大但有效信息稀疏，比如大面积遥感云判、海面船只检测、森林火点监测;第三，任务需要在极端通信环境下自治运行，比如深空探测、极区观测、应急通信恢复等。

目前落地比较成熟的是遥感影像的云检测与目标检测。云检测算是最容易入门的星上AI场景，因为它类别单一、计算简单，一个几兆字节的轻量模型就能实现很高的识别精度。目标检测稍微复杂一点，但如果有足够的业务数据支撑，也能实现高价值目标快速识别。应急通信恢复和星座自主任务规划则是更复杂的智能化应用，需要把AI与卫星平台的控制系统深度耦合起来，算力需求虽然不高，但是对系统的安全性和可靠性要求更高。

在通信卫星上，AI上星还可以用于电磁频谱感知与自适应调节。自动识别干扰信号、优化波束指向，这在干扰频繁的环境下非常有价值。不过这块涉及对不同信号特征的建模和决策策略，计算量反而比图像检测还高，需要在星上做一些更专门的算力模块。

5.3 成本、人才与落地建议

最后聊聊现实的工程落地问题。很多人问“太空算力到底贵不贵”，我这里给个粗算：一个成熟的星载AI处理模块（包含抗辐射设计、接口板、电源转换）在批量生产前的非工程样机成本大概几十万元人民币量级，如果是小批量上星，摊到每颗卫星增加的成本可能在数万到十几万。相比卫星平台本身几千万的总成本，这其实并不夸张。真正贵的是研发人员和软件开发成本，算法工程师、嵌入式工程师、FPGA工程师、系统验证工程师组成一个成熟的“星上AI小团队”，人力投入普遍比传统星载软件团队高50%以上。

给准备入局的团队几条建议。第一，别一开始就追求大而全的通用AI平台，先把一个单一任务做到在轨稳定运行，比如云判、火点检测，做扎实了再扩展。第二，选型芯片时多看看在轨案例，少看宣传算力跑分。第三，一定要在地面建一套足够接近在轨工况的仿真和故障注入环境，这是效率最高的投资。

提示：做卫星智能化项目，最忌讳的是“什么都想放上星”。AI上星不是把地面软件打包上传，而是值得上星的、必须在星上才能解决的任务才放上去。判断标准永远是：它是否在链路带宽、实时性或者可靠性上带来了不可替代的价值。

我在实际项目里体会最深的，是“在轨AI”和“地面AI”完全是两种工程文化。地面AI可以容忍bug，可以频繁热修复，可以随意扩展内存；空间AI则必须在功耗受限、资源受限、环境恶劣的前提下，保证长期稳定运行。这不是把模型压缩一下就完事，而是需要从芯片选型、算法设计、系统架构、在轨运维全链条一起发力。

最后再分享一个小技巧：做星上模型OTA更新时，永远准备一个“最小可用权重”作为兜底。这个权重只需要能完成简单的云判和一级告警，可能精度不如主模型，但它胜在体积小、行为简单、不容易出错。无论后续主模型更新多少次，只要这个兜底权重一直在轨，哪怕更新出错，卫星依然能保持基本任务能力。这个设计可能在很多地面上看起来“过于保守”，但在轨运行中，它救过我们不止一次。