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这类“基础款”。如果你的模型用了SiLUSwish工具链可能会把它拆分成一堆乘法和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更新时永远准备一个“最小可用权重”作为兜底。这个权重只需要能完成简单的云判和一级告警可能精度不如主模型但它胜在体积小、行为简单、不容易出错。无论后续主模型更新多少次只要这个兜底权重一直在轨哪怕更新出错卫星依然能保持基本任务能力。这个设计可能在很多地面上看起来“过于保守”但在轨运行中它救过我们不止一次。