上个月交付农田无人机巡检项目模型侧的小目标优化刚做完地面工作站跑着挺稳65.5%的mAP甲方也认可。结果一装到机载的RK3588边缘板上当场傻眼端到端只有12帧画面卡成慢动作别说实时巡检了飞快一点结果都跟不上。当时第一反应是模型太大了要不换回YOLOv26-nano但小目标本来就是难点再换轻量模型漏检率肯定飙上去甲方第一个不答应。没办法只能硬着头皮从推理引擎、预处理、量化、流水线到业务策略全链路挨个抠性能。前后调了两周最终端到端稳跑34帧比最初快了将近3倍而且小目标检测精度几乎没掉甚至因为ROI裁剪少了背景干扰mAP还微涨0.8个点完全满足机载实时巡检的要求。今天把完整的优化过程分享出来都是边缘端实测踩出来的经验每一步都有耗时对比照着做就能看到效果。一、先拆耗时机载端的瓶颈根本不在NPU算力做优化的第一步永远是拆耗时不要上来就盯着模型推理死磕。我当时拿计时器把端到端全链路拆成了五段测完直接推翻了之前的判断环节耗时占比相机取图OpenCV缩放8ms9.6%归一化转CHW转张量15ms18.1%CPU→NPU数据拷贝7ms8.4%模型推理原生PyTorch41ms49.4%后处理NMS12ms14.5%端到端总计83ms100%算下来每秒刚好12帧和实际测试一致。能看到模型推理确实占了大头但预处理拷贝后处理加起来也有34ms占了快三分之一。NPU大部分时间都在等数据喂过来实际利用率只有30%多大量算力都浪费在了等待上。后面的优化也是按照占比从高到低、性价比从高到低的顺序来先啃收益最大的骨头。二、第一优先级切换专用推理引擎性能直接翻倍这是所有优化里性价比最高的一步不用改模型结构转个格式就能带来近乎翻倍的性能提升。边缘板的CPU和NPU和PC完全不是一个逻辑原生PyTorch是为训练设计的有大量冗余开销在ARM架构的边缘芯片上效率极低。必须换成硬件厂商原生的推理框架RK系列用RKNNJetson系列用TensorRT才能把NPU的算力真正跑起来。具体操作步骤导出干净的ONNX模型先从PyTorch导出ONNX固定输入尺寸打开opset12同时做BN合并、常量折叠。机载场景相机分辨率是固定的完全不用开动态shape动态会导致推理时反复调度速度骤降。这里有个坑不要用torch.onnx.export的默认参数一定要指定dynamic_axesNone固定batch和尺寸不然转出来的模型速度会慢30%以上。转换为硬件专用格式开全量优化以RKNN为例转换配置里开启FP16半精度、算子融合、常量折叠、死代码消除。算子融合是核心收益点——把ConvBNReLU这类前后衔接的算子合并成一个中间结果不用来回读写显存能减少大量显存访问开销对小模型的提升尤其明显。实测效果原生PyTorch FP32推理41ms转成RKNN FP16之后推理耗时直接降到22ms几乎翻倍。加上其他环节不变端到端从83ms降到47ms帧率从12涨到21。踩坑提醒不要用太新的算子比如SiLU变种、复杂注意力算子边缘端的推理引擎支持度很差遇到不支持的算子会自动回退到CPU运行速度直接暴跌。遇到不支持的算子优先替换成边缘端友好的等价实现不要硬上。三、第二优先级预处理硬件化砍掉三分之二前置开销很多人优化只盯着模型推理结果预处理全丢给CPU跑缩放、归一化、通道转换十几毫秒就没了还要做一次CPU到NPU的内存拷贝两头都浪费时间。机载端的CPU性能本来就弱640×640的BGR图OpenCV CPU缩放归一化就要23ms比推理本身慢一半。优化方向就是能让硬件做的就不让CPU做能一次做完的就不分多次。三点核心优化硬件缩放替代OpenCVRK3588自带RGA二维图形加速硬件专门做缩放、裁剪、格式转换比CPU快一个数量级。原来CPU resize要8ms用RGA硬件缩放只要1.2ms效果完全一致。预处理算子融合进模型把归一化、BGR转RGB、CHW转换这些操作全部做成算子放到模型最前面输入直接喂原始图像数据所有计算都在NPU上完成。既省掉了CPU计算的时间又减少了一次数据拷贝。锁页内存加速数据传输普通可分页内存NPU读取的时候要先锁定页面再传输开销很大。提前把输入输出内存锁定在物理内存DMA内存NPU可以直接访问数据拷贝时间从7ms降到2ms以内。实测效果预处理数据拷贝总共从22ms降到5ms加上后处理也顺手做了加速置信度前置过滤快速NMS从12ms降到3ms端到端耗时直接压到33ms帧率涨到30。这时候NPU利用率已经能跑到70%以上比最开始翻了一倍还多。踩坑提醒不要小看后处理的开销。8400个检测框挨个算坐标再跑NMSCPU弱一点就要十几毫秒。先按置信度筛掉90%的低分框剩下的再做NMS速度能快好几倍。四、第三优先级INT8量化再提速精度不掉是关键FP16跑到30帧离甲方要求的25帧已经达标了但我们还想留出余量就上了INT8量化。理论上INT8的算力是FP16的两倍速度还能再涨一截。但很多人一量化就翻车尤其是小目标场景量化完mAP掉五六个点小目标直接漏一半。核心问题根本不是量化本身不行是校准集用错了。量化不掉点的核心用真实场景数据做校准很多人图省事直接用COCO的图片或者随机生成的数据做校准出来的量化模型对通用大目标还行对航拍小目标完全不适用浅层的细节特征量化误差极大直接导致小目标漏检。正确做法从真实航拍数据里选150-200张图片做校准集必须覆盖不同高度、不同光照、不同生育期的场景且保证小目标样本占比足够不能全是大目标。校准的时候开启逐层精度分析对小目标相关的浅层通道用更细的量化粒度重点层保留更多精度。量化完用小批量数据微调5-10轮把量化损失的精度补回来大部分。实测效果INT8量化后模型推理耗时从22ms降到13ms端到端总耗时25ms帧率能跑到40。精度方面整体mAP只掉了0.6个点小目标AP从41.8%降到41.2%几乎感知不到完全在可接受范围内。踩坑提醒不要盲目追求量化比也不要默认校准算法就万能。小目标、细纹理的场景一定要自己做专属校准集不然量化完精度崩了都不知道问题出在哪。五、第四优先级三级流水线并行把等待时间彻底藏起来单帧优化到一定程度就要靠架构设计榨干最后一点性能。传统串行流程是取图→预处理→推理→后处理→输出结果总耗时是所有环节相加。但实际上取图和预处理主要用CPURGA推理用NPU后处理用CPU三者硬件是独立的完全可以并行跑。我们做成了三级流水线CPU线程1负责相机取图 硬件预处理处理完送入队列NPU推理线程从队列取帧做推理结果送入后处理队列CPU线程2负责后处理解析 结果输出连续运行的时候三个环节完全并行NPU在推理第N帧的时候CPU同时在预处理第N1帧。平均每帧的吞吐量只取决于最慢的那个环节而不是所有环节相加。实测效果流水线跑起来后稳定帧率维持在34帧左右。因为我们的检测结果需要和无人机飞控联动延迟不能太高队列长度只设了2帧刚好平衡帧率和延迟。如果对延迟要求更低队列可以再加深吞吐量还能再涨一点。踩坑提醒队列不是越深越好。机载实时检测要求结果和当前位置对应队列太深会导致延迟过大飞机都飞过去了检测结果才出来完全没意义。一般设2-3帧的双缓冲就够了。六、彩蛋优化业务策略降本不耗算力也提速度最后这步和算法无关纯业务策略优化不费一点算力效果却往往出人意料。我们做了两个非常实用的优化ROI有效区域裁剪无人机航拍画面里上方是天空两侧是田埂和空地这些区域根本没有检测目标。提前按航线裁剪出中间的农田有效区域再送入模型等效输入分辨率从640×640变成了640×490推理速度再快15%左右。意外收获是少了天空、空地这些背景干扰误检率反而降了整体mAP还微涨了0.8个点。动态跳帧检测无人机正常巡航速度下相邻帧的变化非常小帧帧都跑检测完全没必要。我们设置成每2帧跑一次检测中间帧用光流跟踪补位速度直接翻倍精度损失几乎可以忽略。因为我们34帧已经远超需求就没开这个功能但如果是算力更弱的板子这招能直接救急。七、全流程优化效果总览所有测试均在机载RK3588边缘板上实测输入尺寸640×640模型为带P2头的YOLOv26s小目标优化版优化阶段端到端单帧耗时稳定FPS整体mAP0.5小目标AP0.5原生PyTorch FP3283ms1265.5%41.8%切换RKNN FP16 算子融合47ms2165.4%41.7%硬件预处理 锁页内存 后处理加速33ms3065.5%41.8%INT8量化航拍专属校准集25ms4064.9%41.2%三级流水线 ROI裁剪29ms3465.7%42.0%最终我们选用了「FP16流水线ROI裁剪」的方案34帧完全满足实时要求精度还比原生略高稳定性也更好INT8方案作为备选留给后续算力更紧张的小型无人机使用。八、机载端优化最容易踩的五个坑坑1量化校准集用公开数据小目标直接崩这是最多人踩的坑。拿COCO或者随机图片做校准大目标看着还行小目标精度直接掉五六个点。解决必须用自己业务场景的真实数据做校准小目标占比要足150-200张足够比瞎调量化参数管用得多。坑2预处理全丢CPUNPU全程等数据很多人优化只盯模型推理结果预处理占了三分之一的时间显卡/ NPU一半时间在空转。解决能硬件加速的预处理绝对不用CPU能融合进模型的就不要单独算数据拷贝能少一次是一次。坑3盲目开动态shape速度骤降为了兼容不同分辨率开动态输入结果每次推理都要重新做算子调度速度慢一半还多。解决机载场景相机参数都是固定的直接锁死输入尺寸性能立刻拉满。坑4流水线队列太深延迟失控为了追帧率把队列设到五六帧结果检测结果延迟几百毫秒飞机都飞过目标区了才报警完全没用。解决机载实时场景队列2-3帧足够优先保证低延迟其次才是帧率。坑5一上来就换轻量模型遇到速度不够第一反应就是换nano、换更小的模型精度直接砍一大截。解决先把工程侧的水分挤干净——推理引擎、预处理、量化、流水线这些都做完了还不够再考虑模型轻量化。很多时候工程优化完速度就达标了精度一点不用牺牲。总结机载端的YOLO推理优化从来不是只盯着模型那几十毫秒死磕。从推理引擎切换、预处理硬件化、INT8量化到流水线并行、业务策略优化端到端全链路每个环节抠一点积少成多就能带来几倍的性能提升而且不用牺牲小目标检测精度。做边缘落地永远是性价比优先。能用工程手段解决的就不要动模型结构能用策略优化的就不要牺牲精度。先把现有硬件的潜力榨干才是成本最低的方案。 
长河君 · 2026/10/30 6:52:22 · 阅读 1.2k 无人机机载YOLO推理踩坑：从12帧卡成PPT到34帧实时，小目标精度零损失
上个月交付农田无人机巡检项目模型侧的小目标优化刚做完地面工作站跑着挺稳65.5%的mAP甲方也认可。结果一装到机载的RK3588边缘板上当场傻眼端到端只有12帧画面卡成慢动作别说实时巡检了飞快一点结果都跟不上。当时第一反应是模型太大了要不换回YOLOv26-nano但小目标本来就是难点再换轻量模型漏检率肯定飙上去甲方第一个不答应。没办法只能硬着头皮从推理引擎、预处理、量化、流水线到业务策略全链路挨个抠性能。前后调了两周最终端到端稳跑34帧比最初快了将近3倍而且小目标检测精度几乎没掉甚至因为ROI裁剪少了背景干扰mAP还微涨0.8个点完全满足机载实时巡检的要求。今天把完整的优化过程分享出来都是边缘端实测踩出来的经验每一步都有耗时对比照着做就能看到效果。一、先拆耗时机载端的瓶颈根本不在NPU算力做优化的第一步永远是拆耗时不要上来就盯着模型推理死磕。我当时拿计时器把端到端全链路拆成了五段测完直接推翻了之前的判断环节耗时占比相机取图OpenCV缩放8ms9.6%归一化转CHW转张量15ms18.1%CPU→NPU数据拷贝7ms8.4%模型推理原生PyTorch41ms49.4%后处理NMS12ms14.5%端到端总计83ms100%算下来每秒刚好12帧和实际测试一致。能看到模型推理确实占了大头但预处理拷贝后处理加起来也有34ms占了快三分之一。NPU大部分时间都在等数据喂过来实际利用率只有30%多大量算力都浪费在了等待上。后面的优化也是按照占比从高到低、性价比从高到低的顺序来先啃收益最大的骨头。二、第一优先级切换专用推理引擎性能直接翻倍这是所有优化里性价比最高的一步不用改模型结构转个格式就能带来近乎翻倍的性能提升。边缘板的CPU和NPU和PC完全不是一个逻辑原生PyTorch是为训练设计的有大量冗余开销在ARM架构的边缘芯片上效率极低。必须换成硬件厂商原生的推理框架RK系列用RKNNJetson系列用TensorRT才能把NPU的算力真正跑起来。具体操作步骤导出干净的ONNX模型先从PyTorch导出ONNX固定输入尺寸打开opset12同时做BN合并、常量折叠。机载场景相机分辨率是固定的完全不用开动态shape动态会导致推理时反复调度速度骤降。这里有个坑不要用torch.onnx.export的默认参数一定要指定dynamic_axesNone固定batch和尺寸不然转出来的模型速度会慢30%以上。转换为硬件专用格式开全量优化以RKNN为例转换配置里开启FP16半精度、算子融合、常量折叠、死代码消除。算子融合是核心收益点——把ConvBNReLU这类前后衔接的算子合并成一个中间结果不用来回读写显存能减少大量显存访问开销对小模型的提升尤其明显。实测效果原生PyTorch FP32推理41ms转成RKNN FP16之后推理耗时直接降到22ms几乎翻倍。加上其他环节不变端到端从83ms降到47ms帧率从12涨到21。踩坑提醒不要用太新的算子比如SiLU变种、复杂注意力算子边缘端的推理引擎支持度很差遇到不支持的算子会自动回退到CPU运行速度直接暴跌。遇到不支持的算子优先替换成边缘端友好的等价实现不要硬上。三、第二优先级预处理硬件化砍掉三分之二前置开销很多人优化只盯着模型推理结果预处理全丢给CPU跑缩放、归一化、通道转换十几毫秒就没了还要做一次CPU到NPU的内存拷贝两头都浪费时间。机载端的CPU性能本来就弱640×640的BGR图OpenCV CPU缩放归一化就要23ms比推理本身慢一半。优化方向就是能让硬件做的就不让CPU做能一次做完的就不分多次。三点核心优化硬件缩放替代OpenCVRK3588自带RGA二维图形加速硬件专门做缩放、裁剪、格式转换比CPU快一个数量级。原来CPU resize要8ms用RGA硬件缩放只要1.2ms效果完全一致。预处理算子融合进模型把归一化、BGR转RGB、CHW转换这些操作全部做成算子放到模型最前面输入直接喂原始图像数据所有计算都在NPU上完成。既省掉了CPU计算的时间又减少了一次数据拷贝。锁页内存加速数据传输普通可分页内存NPU读取的时候要先锁定页面再传输开销很大。提前把输入输出内存锁定在物理内存DMA内存NPU可以直接访问数据拷贝时间从7ms降到2ms以内。实测效果预处理数据拷贝总共从22ms降到5ms加上后处理也顺手做了加速置信度前置过滤快速NMS从12ms降到3ms端到端耗时直接压到33ms帧率涨到30。这时候NPU利用率已经能跑到70%以上比最开始翻了一倍还多。踩坑提醒不要小看后处理的开销。8400个检测框挨个算坐标再跑NMSCPU弱一点就要十几毫秒。先按置信度筛掉90%的低分框剩下的再做NMS速度能快好几倍。四、第三优先级INT8量化再提速精度不掉是关键FP16跑到30帧离甲方要求的25帧已经达标了但我们还想留出余量就上了INT8量化。理论上INT8的算力是FP16的两倍速度还能再涨一截。但很多人一量化就翻车尤其是小目标场景量化完mAP掉五六个点小目标直接漏一半。核心问题根本不是量化本身不行是校准集用错了。量化不掉点的核心用真实场景数据做校准很多人图省事直接用COCO的图片或者随机生成的数据做校准出来的量化模型对通用大目标还行对航拍小目标完全不适用浅层的细节特征量化误差极大直接导致小目标漏检。正确做法从真实航拍数据里选150-200张图片做校准集必须覆盖不同高度、不同光照、不同生育期的场景且保证小目标样本占比足够不能全是大目标。校准的时候开启逐层精度分析对小目标相关的浅层通道用更细的量化粒度重点层保留更多精度。量化完用小批量数据微调5-10轮把量化损失的精度补回来大部分。实测效果INT8量化后模型推理耗时从22ms降到13ms端到端总耗时25ms帧率能跑到40。精度方面整体mAP只掉了0.6个点小目标AP从41.8%降到41.2%几乎感知不到完全在可接受范围内。踩坑提醒不要盲目追求量化比也不要默认校准算法就万能。小目标、细纹理的场景一定要自己做专属校准集不然量化完精度崩了都不知道问题出在哪。五、第四优先级三级流水线并行把等待时间彻底藏起来单帧优化到一定程度就要靠架构设计榨干最后一点性能。传统串行流程是取图→预处理→推理→后处理→输出结果总耗时是所有环节相加。但实际上取图和预处理主要用CPURGA推理用NPU后处理用CPU三者硬件是独立的完全可以并行跑。我们做成了三级流水线CPU线程1负责相机取图 硬件预处理处理完送入队列NPU推理线程从队列取帧做推理结果送入后处理队列CPU线程2负责后处理解析 结果输出连续运行的时候三个环节完全并行NPU在推理第N帧的时候CPU同时在预处理第N1帧。平均每帧的吞吐量只取决于最慢的那个环节而不是所有环节相加。实测效果流水线跑起来后稳定帧率维持在34帧左右。因为我们的检测结果需要和无人机飞控联动延迟不能太高队列长度只设了2帧刚好平衡帧率和延迟。如果对延迟要求更低队列可以再加深吞吐量还能再涨一点。踩坑提醒队列不是越深越好。机载实时检测要求结果和当前位置对应队列太深会导致延迟过大飞机都飞过去了检测结果才出来完全没意义。一般设2-3帧的双缓冲就够了。六、彩蛋优化业务策略降本不耗算力也提速度最后这步和算法无关纯业务策略优化不费一点算力效果却往往出人意料。我们做了两个非常实用的优化ROI有效区域裁剪无人机航拍画面里上方是天空两侧是田埂和空地这些区域根本没有检测目标。提前按航线裁剪出中间的农田有效区域再送入模型等效输入分辨率从640×640变成了640×490推理速度再快15%左右。意外收获是少了天空、空地这些背景干扰误检率反而降了整体mAP还微涨了0.8个点。动态跳帧检测无人机正常巡航速度下相邻帧的变化非常小帧帧都跑检测完全没必要。我们设置成每2帧跑一次检测中间帧用光流跟踪补位速度直接翻倍精度损失几乎可以忽略。因为我们34帧已经远超需求就没开这个功能但如果是算力更弱的板子这招能直接救急。七、全流程优化效果总览所有测试均在机载RK3588边缘板上实测输入尺寸640×640模型为带P2头的YOLOv26s小目标优化版优化阶段端到端单帧耗时稳定FPS整体mAP0.5小目标AP0.5原生PyTorch FP3283ms1265.5%41.8%切换RKNN FP16 算子融合47ms2165.4%41.7%硬件预处理 锁页内存 后处理加速33ms3065.5%41.8%INT8量化航拍专属校准集25ms4064.9%41.2%三级流水线 ROI裁剪29ms3465.7%42.0%最终我们选用了「FP16流水线ROI裁剪」的方案34帧完全满足实时要求精度还比原生略高稳定性也更好INT8方案作为备选留给后续算力更紧张的小型无人机使用。八、机载端优化最容易踩的五个坑坑1量化校准集用公开数据小目标直接崩这是最多人踩的坑。拿COCO或者随机图片做校准大目标看着还行小目标精度直接掉五六个点。解决必须用自己业务场景的真实数据做校准小目标占比要足150-200张足够比瞎调量化参数管用得多。坑2预处理全丢CPUNPU全程等数据很多人优化只盯模型推理结果预处理占了三分之一的时间显卡/ NPU一半时间在空转。解决能硬件加速的预处理绝对不用CPU能融合进模型的就不要单独算数据拷贝能少一次是一次。坑3盲目开动态shape速度骤降为了兼容不同分辨率开动态输入结果每次推理都要重新做算子调度速度慢一半还多。解决机载场景相机参数都是固定的直接锁死输入尺寸性能立刻拉满。坑4流水线队列太深延迟失控为了追帧率把队列设到五六帧结果检测结果延迟几百毫秒飞机都飞过目标区了才报警完全没用。解决机载实时场景队列2-3帧足够优先保证低延迟其次才是帧率。坑5一上来就换轻量模型遇到速度不够第一反应就是换nano、换更小的模型精度直接砍一大截。解决先把工程侧的水分挤干净——推理引擎、预处理、量化、流水线这些都做完了还不够再考虑模型轻量化。很多时候工程优化完速度就达标了精度一点不用牺牲。总结机载端的YOLO推理优化从来不是只盯着模型那几十毫秒死磕。从推理引擎切换、预处理硬件化、INT8量化到流水线并行、业务策略优化端到端全链路每个环节抠一点积少成多就能带来几倍的性能提升而且不用牺牲小目标检测精度。做边缘落地永远是性价比优先。能用工程手段解决的就不要动模型结构能用策略优化的就不要牺牲精度。先把现有硬件的潜力榨干才是成本最低的方案。