去年手头接了个有点折磨人的活：户外监控场景，要盯住画面里经常只有十几甚至几个像素大小的运动目标，还得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“拒收”的DFL
YOLOv8的检测头里有一个叫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真正发挥价值的前提是检测端给人靠谱的候选框，宁可检测误报多一点，也别让漏检毁掉整个跟踪闭环。
下一篇我会重点写数据集制作和标注规范，包括我们踩过的切片重叠率、清洗误标、极端小目标样本扩增这些具体细节。如果你也在做类似的小目标跟踪，欢迎按这个思路先把自己的流程跑通，有问题可以一起交流。
