去年手头接了个有点折磨人的活户外监控场景要盯住画面里经常只有十几甚至几个像素大小的运动目标还得24小时连续跑。设备端没有GPU可用散热和功耗卡得死死的最初尝试用纯检测方案做一帧一帧框选结果目标一小就容易漏检漏一下ID就丢完全没有“连续跟踪”的感觉。最后跑通的这套组合是 RV1126B 边缘盒子 YOLOv8 做检测 一套我们内部简称为 DNTR 的微小目标跟踪模块把采集、推理、跟踪、告警、推流全部塞进了一个小盒子里。这个系列我打算分几篇来写第一篇先聊整体架构和选型逻辑把“为什么用这套组合”“数据怎么做”“模型怎么转”“跟踪怎么不丢”这几个核心问题讲透。如果你正在做边缘端的目标检测或跟踪落地尤其是目标尺寸很小、算力又受限的场景这篇应该能帮你省掉不少试错时间。1. 为什么是 RV1126B YOLOv8 DNTR我从场景倒推选型1.1 先把场景需求写清楚项目现场是固定视角的远程监控镜头离目标区很远目标在画面里的实际尺寸经常在10x10像素上下大一点的也就20x30像素。环境还有光照突变、轻微树叶遮挡、同类目标成群出现这些小状况。需求用大白话说就是能把目标识别出来并分个类同时给每个目标一个稳定不变的ID尽量别跟丢、别串号。这种场景对硬件和算法的要求很具体功耗和散热限制严没法上带独立显卡的设备。需要7x24小时运行主板稳定性要够。要有现成的视频输入接口和编码能力最好能直接把摄像头Sensor接进来。算力得够用但不是越高越好高算力往往伴随着高功耗和高成本。不能完全依赖云端断网时本地也要能检测、能跟踪、能报警。把这些写到纸上选择范围其实就缩小到边缘端NPU盒子这一档了。1.2 为什么挑了 RV1126B 而不是其他平台做边缘AI盒子市面上常见选择大概三类一类是带GPU的开发板性能强但功耗和价格直接劝退一类是通用ARM平台但算力和性价比都不太够还有一类是集成NPU的IPC SoC方案RV1126B就属于这一类。我选 RV1126B 有几个实际原因标称6T算力的NPU对INT8模型支持很成熟YOLOv8这种规模的网络跑起来富余。四核A7处理器专门用来跑前后处理、跟踪算法和网络服务虽然不算强但配合NPU各干各的分配得当能跑出不错的综合帧率。芯片自带ISP和视频编解码能力可以直接接摄像头Sensor省掉外置编码器做监控设备非常顺手。整板功耗可以控制在几瓦级别小金属壳就能散热适合量产级的小盒子。我也对比过RK3588这类更高算力的平台性能确实强但板和外围电路的成本上去了对这个场景有点性能过剩。Jetson系列就更不用说了项目预算和功耗都撑不住。如果你也有同样的需求我的建议是先算一笔账实际需要的检测帧率是多少模型量化后多大NMS和后处理占多少CPU再倒推芯片选型别一开始就奔着最高算力去。1.3 为什么YOLOv8配DNTR而不是直接用检测模型纯检测模型只能回答“这一帧有没有目标、目标在哪”回答不了“这个目标和上一帧那个是不是同一个”。要实现跟踪监测需要在检测结果之上再加一个数据关联模块。传统做法里ByteTrack和DeepSORT很常见它们的问题在于极度依赖检测框的连续性和外观特征。小目标恰恰在这两方面都不给力目标太小检测框轻微抖动就会导致IoU很低外观上只有几个像素根本没有足够纹理让Re-ID模型提取有效特征。我们用ByteTrack试过目标一旦在画面里交叉或暂时被遮挡ID切换非常频繁。所以跟踪部分我们最终换成了DNTR。这个模块的核心思路不是逐帧做独立匹配而是用Transformer结构学习相邻帧目标之间动态邻域的匹配关系再结合运动预测和轨迹管理做综合判决。用大白话说检测器先把候选框送进来DNTR负责判断“这一帧离上一帧目标A最近且运动趋势一致的框是不是就是A”即使目标很小、外观几乎没有也能靠位置分布和时序信息把身份稳住。2. 微小目标数据集从“看不见”到“看得清”2.1 微小目标到底有多小算法圈通常把小于32x32像素的目标叫小目标COCO数据集也按这个标准切分。但监控场景里的微小目标往往比这还夸张经常是10个像素以内的“点状目标”截图放大后才能确认那是人还是一辆车。这种尺度下目标占整张图的比例往往不到千分之一普通检测网络很容易在特征提取阶段就把信息丢光。先明确一个原则微小目标检测不能靠单纯加大模型容量硬扛得从数据尺度和网络结构两头下手。数据侧要尽量让目标在训练图像里有足够像素网络侧要有针对小目标的特征输出层。2.2 采集与切片策略把“小目标”先放大我们最初的训练素材来自现场采集的高清视频单帧分辨率很高。如果直接把整帧缩小到训练常用尺寸比如缩到640x640原来就小得可怜的目标会被压缩成1到2个像素连人眼都认不出来。所以训练方案我直接改成了切片训练把原始高清画面切分成若干有重叠的正方形小块再缩放到640或960分辨率。切片时要注意重叠率我推荐50%左右。因为有目标刚好被切在边界上时没有重叠就会导致目标被截断一半模型学到一堆半截目标。重叠切片相当于把切边风险平均分摊到相邻切片里。推理端也可以沿用同一套思路用小图切片推理再加NMS拼回原图也就是SAHI类方法。不过切图推理会比整图推理多消耗好几倍的NPU算力所以实际部署时我没有全程切片只在整图推理置信度偏低或者场景里小目标特别密集时才触发切片重检做个两级策略。2.3 标注规范和增强手段标注微小目标比标注常规目标更考验耐心。我们定的规范是只要目标能被辨认出来且属于任务类别即使只有5x5像素也要把外接框标上不能因为嫌小就跳过。宁可让模型在后期去抑制误检也不能让它连真目标长什么样都没见过。数据增强方面我试过几类手段效果差别很明显Mosaic拼接把多张图拼成一张让不同尺寸的目标混合出现在一起能明显提升目标尺度泛化性。Copy-Paste把切出来的小目标直接粘贴到其他场景图上相当于给目标“加量”对类别像素占比极少的场景特别有效。运动模糊和轻噪声监控场景有风吹草动和轻微抖动加入模糊增强让模型对“拖影”更耐受。亮度与对比度扰动重点模拟早晚光照突变。还有一个常被忽略的点训练分辨率。我最终用了固定960分辨率而不是常见的多尺度训练。原因很直接微小目标本身像素就少多尺度训练时随机缩到320、480会让目标变得不可学。固定高分辨率虽然多耗一点算力和显存但换来的小目标召回收益非常明显。如果你的硬件显存不够至少要把训练分辨率的下限卡住别太低。3. YOLOv8 从训练到 RKNN容易翻车的点都在这一层3.1 训练阶段就要为部署做打算很多人把训练、部署分成两段训练时随便改结构部署时才发现自己把自己坑了。YOLOv8这套网络本身不复杂但在RV1126B的NPU上跑训练阶段就得想清楚两件事要不要加输出头最后导出什么样的ONNX。微小目标建议在常规P3、P4、P5输出层之外增加一个P2输出层对应更大尺寸的特征图专门用来保小目标。代价是多一个输出分支NPU算力消耗会增加帧率会略降。我们最终是加了的因为小目标漏检带来的损失远大于帧率的一点下降。损失权重上我调高了box损失在总损失里的占比适当降低了分类损失的权重。原因是微小目标分类本来就弱与其让它硬猜类别不如先把位置框稳准类别判断可以交给后续帧的多数投票。这个在后续跟踪里能体现很大价值。3.2 导出ONNX最容易被NPU“拒收”的DFLYOLOv8的检测头里有一个叫DFL的模块负责把预测的分布转换成最终的框坐标偏移。问题在于这个模块里包含softmax、加权求和等组合算子直接导出ONNX再转RKNN时很多版本的RKNN工具根本不吃这一套会出现传说中的“算子不支持”报错。我在转第一个版本时就卡在这。解决办法不是去等工具更新而是改模型导出方式导出时把DFL部分留在ONNX之外NPU只输出未经DFL的原始特征真正的DFL计算放到CPU后处理里做。这样做还有个好处后处理自由度更大比如可以针对小目标单独调整DFL的分布温度系数这些都是部署后调优的手段。导出时我还顺手做了几个常规操作固定输入尺寸避免动态shape在NPU上不可用。把输出的坐标预测reshape成4D张量减少后续转模型时对动态维度的解析问题。保持训练时的归一化方式均值/方差和预处理保持一致避免量化后推理结果“飘”。3.3 INT8量化的校准集与敏感层RV1126B的NPU对INT8支持得不错但模型从FP32缩到INT8后微小目标往往是最先“牺牲”的。因为小目标特征本身就微弱量化截断再一压缩还没到NMS就被置信度阈值过滤了。这块我有两个自己的经验第一校准集选图不能偷懒。RKNN量化时需要用校准图片跑一遍统计各层的数据分布。我用的是300张覆盖白天、夜间、逆光、密集目标、单目标等多样场景的图片而不是随机拿几百张训练图凑数。很多精度翻车案例就是校准集太像训练集实际场景分布一变就露馅。第二量化后要会做“抢救”。转完模型后跑一遍全验证集把掉点严重的层找出来。RKNN工具通常能给出每层的量化分析结果配合余弦相似度比较前后tensor差异很快能锁定几个敏感层。对这些层可以单独配置保留更高精度也就是混合量化。别一上来就全模型混合量化NPU速度会下降只处理掉点最凶的少数层性价比最高。注意如果条件允许在训练时就做量化感知训练QAT比事后再用校准集硬调效果好很多。代价是需要多留几轮训练时间但部署阶段会省心不少。3.4 转完模型先别急着接相机RKNN模型出来之后我习惯先在离线视频上做一次基准测试同时跑PyTorch原模型和RKNN量化模型NMS后对比检测框和置信度。这一步能发现两类问题一是量化后哪些目标类别被系统性过滤二是输出结果里有没有与输入完全无关的“鬼框”。鬼框通常是量化截断或算子在NPU上的近似精度不足导致的排查手段就是把可疑输入帧单独抽出来单帧跑RKNN和ONNX逐步缩小范围。CPU后处理也要提前优化好。虽然NPU负责网络推理但DFL、NMS、阈值过滤都在CPU上跑目标一多NMS可能比网络还慢。我后来把NMS改成只对TopK个候选框做计算并按类别分组过滤CPU占用率一下就下来了。4. DNTR 跟踪模块目标只有几个像素时怎么“不丢”4.1 跟踪不是“把检测结果连起来”那么简单如果只是把检测框按IoU最大匹配串起来那叫帧间关联不叫跟踪。微小目标场景下这种关联会频繁断裂。原因很现实目标可能连续两帧因为遮挡或突变光照没被检出目标被树叶盖住3秒后重新出现检测框位置已经跳了一大截多个同类目标离得近时IoU交叉匹配会把ID彻底打乱。DNTR的定位就是解决这些问题。它在检测器之上增加了一个专门的跟踪闭环输入是YOLOv8输出的候选框和置信度输出是带稳定ID的轨迹。术语上大家喜欢叫Tracking-by-Detection但真正决定成败的是内部那几个“兜底机制”。4.2 动态邻域匹配和运动预测DNTR的核心是动态邻域Transformer匹配。简单解释就是对当前帧的每个待匹配目标不需要在全图所有检测框里做暴力匹配而是以上一帧目标位置为基础用运动模型预测出下一个可能出现的位置再在这个邻域范围里让Transformer去学习匹配当前帧的那些候选框。这种局部注意力设计很聪明既能缩小匹配搜索空间降低计算量又天然适合小目标——小目标位置变化相对缓慢运动趋势是比外观更可靠的线索。我印象很深的一个例子高处挂着的一串灯珠类目标外观几乎每帧都在变亮度也在跳但运动轨迹非常平滑DNTR靠纯运动邻域匹配也能长时间保住ID。除了匹配本身目标还配了卡尔曼滤波做轨迹平滑。卡尔曼在这里不是用来预测未来几帧位置这么简单它更大的作用是给匹配打分提供“先验”如果某个候选框和卡尔曼预测位置的马氏距离太远即使IoU较大也可以降低匹配权重防止ID突然跳走。4.3 漏检、遮挡和轨迹管理检测器不可能100%每一帧都检出目标。DNTR的轨迹管理里有一个三态状态机候选态、确认态、丢失态。新目标先进入候选态连续确认几帧才转正。这能有效过滤零星误检。目标暂时消失时进入丢失态轨迹先保留同时用运动模型外推一段时间。如果目标在数帧内重新出现自动接回原ID而不是新建一个ID。微小目标有一个特殊性它可能不是“真的消失”而是小到超过了检测器阈值人眼都看不清。所以丢失状态的保留帧数我特意调得比常规目标更长。代价是目标如果彻底离开画面轨迹会晚一些才被删除需要多维护一段时间的旧轨迹。这个取舍我认为是值得的。如果场景里相机本身有轻微抖动或者监控云台在转动还需要加一个全局运动补偿模块把帧间的背景位移先估计出来再去预测目标位置。否则固定相机假设成立不了卡尔曼预测会系统性偏离。我们项目里镜头几乎不动这个模块用了轻量模式但如果你接云台相机这一步绕不开。5. 端侧全栈联调让检测、跟踪、上报在一个盒子里跑起来5.1 多线程流水线设计把算法都塞进边缘盒子之后最容易出现的坑是“所有事情串行跑”采集等推理推理等跟踪跟踪等显示最后帧率稀碎。正确做法是流水线化按功能拆线程采集线程负责从Sensor或RTSP拉流把帧放入环形缓存。推理线程从缓存取帧做预处理、NPU推理、后处理输出检测结果。跟踪线程拿检测结果跑DNTR维护轨迹列表生成带ID的跟踪结果。输出线程负责画框、叠加标签、推流、发送告警。线程之间用带时间戳的帧队列连接每一级都独立工作。哪怕某一帧推理慢了采集线程也不会被堵死整体帧率会比串行模型稳定很多。我实测下来单看NPU推理速度可能不算惊艳但流水线化之后端到端帧率提升非常明显因为这个场景里CPU和NPU是并行工作的不能让任何一方空转等数据。5.2 零拷贝和内存复用RKNN的Python和C接口都支持零拷贝模式输入输出用共享内存直接映射避免每帧都做一次内存拷贝。这块优化在边缘端很重要1080P甚至4K图像一帧数据量不小高频拷贝下来CPU占用率会吓人。预处理也要省着用。resize和颜色空间转换尽量交给硬件或SIMD做我在RV1126B上用的是硬件RGA做缩放CPU上只做归一化和NHWC到NCHW的排布转换。很多教程模板里写“OpenCV逐个像素改”的方法是灾难实时性根本不够。内存池和对象池也是老生常谈但很容易被忽视。跟踪模块会频繁创建和销毁轨迹对象、匹配矩阵如果每次都用标准容器动态分配长时间跑必然出现碎片和抖动。我这里把所有固定大小的对象做成预分配池运行期内只复用不释放对7x24小时运行的设备非常重要。5.3 监测结果输出画框、推流、告警跟踪监测最终要给用户“看得见”的结果。我们做的输出分三层本地显示、视频流叠加、事件告警。本地显示一般只用于调试接个HDMI或虚拟显示即可。视频流叠加是主要功能在推流前把检测框、跟踪ID、类别、置信度画到帧上同时目标太小时要画外扩框否则用户根本看不清框在哪。告警则在跟踪ID持续出现在某个区域并满足规则时触发通过HTTP或MQTT转发到上层平台同时保存关键帧到本地存储。我还加了一个很实用的小功能短时间录像缓冲。平时只在内存里保留最近10秒视频只有发生告警时才把那10秒连同告警帧一起落盘。这样不会积累海量录像又能保证事件回放有完整上下文。5.4 长时间运行要盯的几个指标新设备拿到手跑通demo不算完真正决定项目成败的是连续运行几天的稳定性。我每天检查的核心指标包括NPU温度是否逼近降频阈值外壳通风是否够。内存占用是否随时间缓慢上涨排查有没有线程或缓冲泄漏。跟踪ID数量有没有异常膨胀轨迹没有被正常回收。推流连接是否断线重连正常。日志是否被大量重复告警刷爆。这些指标建议从一开始就埋点统计不要等客户反馈才去看。边缘设备不像服务器可以随时人工盯所有异常都要能自己暴露、自己恢复。比如加一个简单的看门狗线程定期检查各级队列堆积情况堆到阈值就自动清空并写日志能避免很多“假死”状态。跑完整个流程后我自己最大的体会是YOLOv8和RV1126B之间的适配本质上不是“转个模型就行”而是检测头结构和RKNN工具链之间的反复磨合。一定要提前给工具链适配留出时间不要算到上线前一周才做模型转换。跟踪这块也一样DNTR真正发挥价值的前提是检测端给人靠谱的候选框宁可检测误报多一点也别让漏检毁掉整个跟踪闭环。下一篇我会重点写数据集制作和标注规范包括我们踩过的切片重叠率、清洗误标、极端小目标样本扩增这些具体细节。如果你也在做类似的小目标跟踪欢迎按这个思路先把自己的流程跑通有问题可以一起交流。
去年手头接了个有点折磨人的活户外监控场景要盯住画面里经常只有十几甚至几个像素大小的运动目标还得24小时连续跑。设备端没有GPU可用散热和功耗卡得死死的最初尝试用纯检测方案做一帧一帧框选结果目标一小就容易漏检漏一下ID就丢完全没有“连续跟踪”的感觉。最后跑通的这套组合是 RV1126B 边缘盒子 YOLOv8 做检测 一套我们内部简称为 DNTR 的微小目标跟踪模块把采集、推理、跟踪、告警、推流全部塞进了一个小盒子里。这个系列我打算分几篇来写第一篇先聊整体架构和选型逻辑把“为什么用这套组合”“数据怎么做”“模型怎么转”“跟踪怎么不丢”这几个核心问题讲透。如果你正在做边缘端的目标检测或跟踪落地尤其是目标尺寸很小、算力又受限的场景这篇应该能帮你省掉不少试错时间。1. 为什么是 RV1126B YOLOv8 DNTR我从场景倒推选型1.1 先把场景需求写清楚项目现场是固定视角的远程监控镜头离目标区很远目标在画面里的实际尺寸经常在10x10像素上下大一点的也就20x30像素。环境还有光照突变、轻微树叶遮挡、同类目标成群出现这些小状况。需求用大白话说就是能把目标识别出来并分个类同时给每个目标一个稳定不变的ID尽量别跟丢、别串号。这种场景对硬件和算法的要求很具体功耗和散热限制严没法上带独立显卡的设备。需要7x24小时运行主板稳定性要够。要有现成的视频输入接口和编码能力最好能直接把摄像头Sensor接进来。算力得够用但不是越高越好高算力往往伴随着高功耗和高成本。不能完全依赖云端断网时本地也要能检测、能跟踪、能报警。把这些写到纸上选择范围其实就缩小到边缘端NPU盒子这一档了。1.2 为什么挑了 RV1126B 而不是其他平台做边缘AI盒子市面上常见选择大概三类一类是带GPU的开发板性能强但功耗和价格直接劝退一类是通用ARM平台但算力和性价比都不太够还有一类是集成NPU的IPC SoC方案RV1126B就属于这一类。我选 RV1126B 有几个实际原因标称6T算力的NPU对INT8模型支持很成熟YOLOv8这种规模的网络跑起来富余。四核A7处理器专门用来跑前后处理、跟踪算法和网络服务虽然不算强但配合NPU各干各的分配得当能跑出不错的综合帧率。芯片自带ISP和视频编解码能力可以直接接摄像头Sensor省掉外置编码器做监控设备非常顺手。整板功耗可以控制在几瓦级别小金属壳就能散热适合量产级的小盒子。我也对比过RK3588这类更高算力的平台性能确实强但板和外围电路的成本上去了对这个场景有点性能过剩。Jetson系列就更不用说了项目预算和功耗都撑不住。如果你也有同样的需求我的建议是先算一笔账实际需要的检测帧率是多少模型量化后多大NMS和后处理占多少CPU再倒推芯片选型别一开始就奔着最高算力去。1.3 为什么YOLOv8配DNTR而不是直接用检测模型纯检测模型只能回答“这一帧有没有目标、目标在哪”回答不了“这个目标和上一帧那个是不是同一个”。要实现跟踪监测需要在检测结果之上再加一个数据关联模块。传统做法里ByteTrack和DeepSORT很常见它们的问题在于极度依赖检测框的连续性和外观特征。小目标恰恰在这两方面都不给力目标太小检测框轻微抖动就会导致IoU很低外观上只有几个像素根本没有足够纹理让Re-ID模型提取有效特征。我们用ByteTrack试过目标一旦在画面里交叉或暂时被遮挡ID切换非常频繁。所以跟踪部分我们最终换成了DNTR。这个模块的核心思路不是逐帧做独立匹配而是用Transformer结构学习相邻帧目标之间动态邻域的匹配关系再结合运动预测和轨迹管理做综合判决。用大白话说检测器先把候选框送进来DNTR负责判断“这一帧离上一帧目标A最近且运动趋势一致的框是不是就是A”即使目标很小、外观几乎没有也能靠位置分布和时序信息把身份稳住。2. 微小目标数据集从“看不见”到“看得清”2.1 微小目标到底有多小算法圈通常把小于32x32像素的目标叫小目标COCO数据集也按这个标准切分。但监控场景里的微小目标往往比这还夸张经常是10个像素以内的“点状目标”截图放大后才能确认那是人还是一辆车。这种尺度下目标占整张图的比例往往不到千分之一普通检测网络很容易在特征提取阶段就把信息丢光。先明确一个原则微小目标检测不能靠单纯加大模型容量硬扛得从数据尺度和网络结构两头下手。数据侧要尽量让目标在训练图像里有足够像素网络侧要有针对小目标的特征输出层。2.2 采集与切片策略把“小目标”先放大我们最初的训练素材来自现场采集的高清视频单帧分辨率很高。如果直接把整帧缩小到训练常用尺寸比如缩到640x640原来就小得可怜的目标会被压缩成1到2个像素连人眼都认不出来。所以训练方案我直接改成了切片训练把原始高清画面切分成若干有重叠的正方形小块再缩放到640或960分辨率。切片时要注意重叠率我推荐50%左右。因为有目标刚好被切在边界上时没有重叠就会导致目标被截断一半模型学到一堆半截目标。重叠切片相当于把切边风险平均分摊到相邻切片里。推理端也可以沿用同一套思路用小图切片推理再加NMS拼回原图也就是SAHI类方法。不过切图推理会比整图推理多消耗好几倍的NPU算力所以实际部署时我没有全程切片只在整图推理置信度偏低或者场景里小目标特别密集时才触发切片重检做个两级策略。2.3 标注规范和增强手段标注微小目标比标注常规目标更考验耐心。我们定的规范是只要目标能被辨认出来且属于任务类别即使只有5x5像素也要把外接框标上不能因为嫌小就跳过。宁可让模型在后期去抑制误检也不能让它连真目标长什么样都没见过。数据增强方面我试过几类手段效果差别很明显Mosaic拼接把多张图拼成一张让不同尺寸的目标混合出现在一起能明显提升目标尺度泛化性。Copy-Paste把切出来的小目标直接粘贴到其他场景图上相当于给目标“加量”对类别像素占比极少的场景特别有效。运动模糊和轻噪声监控场景有风吹草动和轻微抖动加入模糊增强让模型对“拖影”更耐受。亮度与对比度扰动重点模拟早晚光照突变。还有一个常被忽略的点训练分辨率。我最终用了固定960分辨率而不是常见的多尺度训练。原因很直接微小目标本身像素就少多尺度训练时随机缩到320、480会让目标变得不可学。固定高分辨率虽然多耗一点算力和显存但换来的小目标召回收益非常明显。如果你的硬件显存不够至少要把训练分辨率的下限卡住别太低。3. YOLOv8 从训练到 RKNN容易翻车的点都在这一层3.1 训练阶段就要为部署做打算很多人把训练、部署分成两段训练时随便改结构部署时才发现自己把自己坑了。YOLOv8这套网络本身不复杂但在RV1126B的NPU上跑训练阶段就得想清楚两件事要不要加输出头最后导出什么样的ONNX。微小目标建议在常规P3、P4、P5输出层之外增加一个P2输出层对应更大尺寸的特征图专门用来保小目标。代价是多一个输出分支NPU算力消耗会增加帧率会略降。我们最终是加了的因为小目标漏检带来的损失远大于帧率的一点下降。损失权重上我调高了box损失在总损失里的占比适当降低了分类损失的权重。原因是微小目标分类本来就弱与其让它硬猜类别不如先把位置框稳准类别判断可以交给后续帧的多数投票。这个在后续跟踪里能体现很大价值。3.2 导出ONNX最容易被NPU“拒收”的DFLYOLOv8的检测头里有一个叫DFL的模块负责把预测的分布转换成最终的框坐标偏移。问题在于这个模块里包含softmax、加权求和等组合算子直接导出ONNX再转RKNN时很多版本的RKNN工具根本不吃这一套会出现传说中的“算子不支持”报错。我在转第一个版本时就卡在这。解决办法不是去等工具更新而是改模型导出方式导出时把DFL部分留在ONNX之外NPU只输出未经DFL的原始特征真正的DFL计算放到CPU后处理里做。这样做还有个好处后处理自由度更大比如可以针对小目标单独调整DFL的分布温度系数这些都是部署后调优的手段。导出时我还顺手做了几个常规操作固定输入尺寸避免动态shape在NPU上不可用。把输出的坐标预测reshape成4D张量减少后续转模型时对动态维度的解析问题。保持训练时的归一化方式均值/方差和预处理保持一致避免量化后推理结果“飘”。3.3 INT8量化的校准集与敏感层RV1126B的NPU对INT8支持得不错但模型从FP32缩到INT8后微小目标往往是最先“牺牲”的。因为小目标特征本身就微弱量化截断再一压缩还没到NMS就被置信度阈值过滤了。这块我有两个自己的经验第一校准集选图不能偷懒。RKNN量化时需要用校准图片跑一遍统计各层的数据分布。我用的是300张覆盖白天、夜间、逆光、密集目标、单目标等多样场景的图片而不是随机拿几百张训练图凑数。很多精度翻车案例就是校准集太像训练集实际场景分布一变就露馅。第二量化后要会做“抢救”。转完模型后跑一遍全验证集把掉点严重的层找出来。RKNN工具通常能给出每层的量化分析结果配合余弦相似度比较前后tensor差异很快能锁定几个敏感层。对这些层可以单独配置保留更高精度也就是混合量化。别一上来就全模型混合量化NPU速度会下降只处理掉点最凶的少数层性价比最高。注意如果条件允许在训练时就做量化感知训练QAT比事后再用校准集硬调效果好很多。代价是需要多留几轮训练时间但部署阶段会省心不少。3.4 转完模型先别急着接相机RKNN模型出来之后我习惯先在离线视频上做一次基准测试同时跑PyTorch原模型和RKNN量化模型NMS后对比检测框和置信度。这一步能发现两类问题一是量化后哪些目标类别被系统性过滤二是输出结果里有没有与输入完全无关的“鬼框”。鬼框通常是量化截断或算子在NPU上的近似精度不足导致的排查手段就是把可疑输入帧单独抽出来单帧跑RKNN和ONNX逐步缩小范围。CPU后处理也要提前优化好。虽然NPU负责网络推理但DFL、NMS、阈值过滤都在CPU上跑目标一多NMS可能比网络还慢。我后来把NMS改成只对TopK个候选框做计算并按类别分组过滤CPU占用率一下就下来了。4. DNTR 跟踪模块目标只有几个像素时怎么“不丢”4.1 跟踪不是“把检测结果连起来”那么简单如果只是把检测框按IoU最大匹配串起来那叫帧间关联不叫跟踪。微小目标场景下这种关联会频繁断裂。原因很现实目标可能连续两帧因为遮挡或突变光照没被检出目标被树叶盖住3秒后重新出现检测框位置已经跳了一大截多个同类目标离得近时IoU交叉匹配会把ID彻底打乱。DNTR的定位就是解决这些问题。它在检测器之上增加了一个专门的跟踪闭环输入是YOLOv8输出的候选框和置信度输出是带稳定ID的轨迹。术语上大家喜欢叫Tracking-by-Detection但真正决定成败的是内部那几个“兜底机制”。4.2 动态邻域匹配和运动预测DNTR的核心是动态邻域Transformer匹配。简单解释就是对当前帧的每个待匹配目标不需要在全图所有检测框里做暴力匹配而是以上一帧目标位置为基础用运动模型预测出下一个可能出现的位置再在这个邻域范围里让Transformer去学习匹配当前帧的那些候选框。这种局部注意力设计很聪明既能缩小匹配搜索空间降低计算量又天然适合小目标——小目标位置变化相对缓慢运动趋势是比外观更可靠的线索。我印象很深的一个例子高处挂着的一串灯珠类目标外观几乎每帧都在变亮度也在跳但运动轨迹非常平滑DNTR靠纯运动邻域匹配也能长时间保住ID。除了匹配本身目标还配了卡尔曼滤波做轨迹平滑。卡尔曼在这里不是用来预测未来几帧位置这么简单它更大的作用是给匹配打分提供“先验”如果某个候选框和卡尔曼预测位置的马氏距离太远即使IoU较大也可以降低匹配权重防止ID突然跳走。4.3 漏检、遮挡和轨迹管理检测器不可能100%每一帧都检出目标。DNTR的轨迹管理里有一个三态状态机候选态、确认态、丢失态。新目标先进入候选态连续确认几帧才转正。这能有效过滤零星误检。目标暂时消失时进入丢失态轨迹先保留同时用运动模型外推一段时间。如果目标在数帧内重新出现自动接回原ID而不是新建一个ID。微小目标有一个特殊性它可能不是“真的消失”而是小到超过了检测器阈值人眼都看不清。所以丢失状态的保留帧数我特意调得比常规目标更长。代价是目标如果彻底离开画面轨迹会晚一些才被删除需要多维护一段时间的旧轨迹。这个取舍我认为是值得的。如果场景里相机本身有轻微抖动或者监控云台在转动还需要加一个全局运动补偿模块把帧间的背景位移先估计出来再去预测目标位置。否则固定相机假设成立不了卡尔曼预测会系统性偏离。我们项目里镜头几乎不动这个模块用了轻量模式但如果你接云台相机这一步绕不开。5. 端侧全栈联调让检测、跟踪、上报在一个盒子里跑起来5.1 多线程流水线设计把算法都塞进边缘盒子之后最容易出现的坑是“所有事情串行跑”采集等推理推理等跟踪跟踪等显示最后帧率稀碎。正确做法是流水线化按功能拆线程采集线程负责从Sensor或RTSP拉流把帧放入环形缓存。推理线程从缓存取帧做预处理、NPU推理、后处理输出检测结果。跟踪线程拿检测结果跑DNTR维护轨迹列表生成带ID的跟踪结果。输出线程负责画框、叠加标签、推流、发送告警。线程之间用带时间戳的帧队列连接每一级都独立工作。哪怕某一帧推理慢了采集线程也不会被堵死整体帧率会比串行模型稳定很多。我实测下来单看NPU推理速度可能不算惊艳但流水线化之后端到端帧率提升非常明显因为这个场景里CPU和NPU是并行工作的不能让任何一方空转等数据。5.2 零拷贝和内存复用RKNN的Python和C接口都支持零拷贝模式输入输出用共享内存直接映射避免每帧都做一次内存拷贝。这块优化在边缘端很重要1080P甚至4K图像一帧数据量不小高频拷贝下来CPU占用率会吓人。预处理也要省着用。resize和颜色空间转换尽量交给硬件或SIMD做我在RV1126B上用的是硬件RGA做缩放CPU上只做归一化和NHWC到NCHW的排布转换。很多教程模板里写“OpenCV逐个像素改”的方法是灾难实时性根本不够。内存池和对象池也是老生常谈但很容易被忽视。跟踪模块会频繁创建和销毁轨迹对象、匹配矩阵如果每次都用标准容器动态分配长时间跑必然出现碎片和抖动。我这里把所有固定大小的对象做成预分配池运行期内只复用不释放对7x24小时运行的设备非常重要。5.3 监测结果输出画框、推流、告警跟踪监测最终要给用户“看得见”的结果。我们做的输出分三层本地显示、视频流叠加、事件告警。本地显示一般只用于调试接个HDMI或虚拟显示即可。视频流叠加是主要功能在推流前把检测框、跟踪ID、类别、置信度画到帧上同时目标太小时要画外扩框否则用户根本看不清框在哪。告警则在跟踪ID持续出现在某个区域并满足规则时触发通过HTTP或MQTT转发到上层平台同时保存关键帧到本地存储。我还加了一个很实用的小功能短时间录像缓冲。平时只在内存里保留最近10秒视频只有发生告警时才把那10秒连同告警帧一起落盘。这样不会积累海量录像又能保证事件回放有完整上下文。5.4 长时间运行要盯的几个指标新设备拿到手跑通demo不算完真正决定项目成败的是连续运行几天的稳定性。我每天检查的核心指标包括NPU温度是否逼近降频阈值外壳通风是否够。内存占用是否随时间缓慢上涨排查有没有线程或缓冲泄漏。跟踪ID数量有没有异常膨胀轨迹没有被正常回收。推流连接是否断线重连正常。日志是否被大量重复告警刷爆。这些指标建议从一开始就埋点统计不要等客户反馈才去看。边缘设备不像服务器可以随时人工盯所有异常都要能自己暴露、自己恢复。比如加一个简单的看门狗线程定期检查各级队列堆积情况堆到阈值就自动清空并写日志能避免很多“假死”状态。跑完整个流程后我自己最大的体会是YOLOv8和RV1126B之间的适配本质上不是“转个模型就行”而是检测头结构和RKNN工具链之间的反复磨合。一定要提前给工具链适配留出时间不要算到上线前一周才做模型转换。跟踪这块也一样DNTR真正发挥价值的前提是检测端给人靠谱的候选框宁可检测误报多一点也别让漏检毁掉整个跟踪闭环。下一篇我会重点写数据集制作和标注规范包括我们踩过的切片重叠率、清洗误标、极端小目标样本扩增这些具体细节。如果你也在做类似的小目标跟踪欢迎按这个思路先把自己的流程跑通有问题可以一起交流。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
