今年年初我接了个活儿一台老工业相机配嵌入式板卡要求每秒25帧从画面里把几十种包装箱上的小标签抠出来。我第一版直接上了常规的通用大检测模型PC上精度很漂亮换到目标设备上内存直接爆推理速度也垮了。后来我把目光转向轻量级目标检测方案最后选了NanoDet自己做了数据集、改了训练配置、把模型部署到板卡上整个项目才算真正落地。这篇文章就把从数据集准备、配置调参到部署端的完整过程摊开讲适合正在调研轻量检测方案、准备自己训练模型的工程师参考。1. 轻量级目标检测到底在解决什么问题模型越小限制越多1.1 先搞清楚你的设备瓶颈在哪很多人上来就纠结哪个模型精度高但现实是我得先问你一句你的模型跑在哪块设备上我这次项目的目标设备是一块不到20块钱的嵌入式板卡内存1GB左右没有独立显卡推理只能用CPU或者集成的计算单元。我把通用大检测模型转成端侧格式之后模型文件接近200MB加载就占掉一半内存单帧推理耗时超过两秒。这个结果出来项目组就知道走错方向了我们要的不是最强模型而是在指定功耗、内存、时延预算里精度最高的模型。轻量级目标检测解决的就是这个问题。NanoDet这类方案一般不追求刷榜而是把参数量压在几百万级别、计算量控制在几个GFLOPs左右让模型在手机芯片、嵌入式板卡、树莓派这类环境里跑出实时帧率同时精度尽量接近大模型。我自己的判断标准有三个模型文件大小端侧模型的存储和内存占用必须可控我一般要求不超过20MB。推理时延在目标设备上的单帧耗时最好低于40毫秒才能留出系统其他任务的余量。精度底线项目允许的漏检率和误检率通常比公开数据集mAP更实际。这三条里NanoDet恰好都能满足尤其是部署生态成熟导出ONNX之后转各类端侧引擎都比较顺。1.2 NanoDet都用了哪些关键技术NanoDet不是简单把大模型缩小它的结构设计本身就是围绕轻量来的。它属于anchor-free一阶段检测器不需要预设一堆锚框省掉了不少计算和调参成本。训练采样用的是一种自适应正样本选择策略ATSS它会根据统计信息自动决定哪些位置作为正样本比固定规则更稳。损失函数上NanoDet用了广义焦点损失这一套组合其中质量焦点损失QFL负责让分类分支同时预测目标的类别和框质量分布焦点损失DFL用来更精确地回归边框位置。这两者和GIoU损失配合让模型在轻量结构下也能把边框定得比较准。骨干网络方面NanoDet支持多种轻量骨干比如ShuffleNetV2、MobileNetV2还有后面改进版本里出现的GhostNetV2之类的结构。加上和骨干匹配的特征金字塔结构通常是NAFP这类融合方式以及全卷积检测头整体参数很省。我给它算过一笔账我常用的NanoDet Plus中杯版输入416分辨率参数量大约在500万上下换算下来模型文件只有十几MB在板卡上实测单帧推理可以跑到30毫秒左右。这种量级带给你的是非常大的部署自由度连不带风扇的被动散热设备都能压住。方案类型参数量参考端侧单帧耗时参考适用场景通用大检测模型5000万以上200毫秒以上服务器、桌面GPU中量级检测模型1000万-3000万80-150毫秒中高端手机、带NPU的设备NanoDet这类轻量方案300万-700万20-40毫秒嵌入式板卡、低功耗设备2. 数据集准备轻量模型对数据质量比大模型更敏感2.1 数据格式与目录结构先把标准定下来NanoDet本身基于MMDetection风格的数据管线最常用的数据格式是COCO格式。我第一次训练的时候就是把标注工具导出的XML转成了COCO JSON里面有图片路径、标注框坐标、类别ID这些信息。如果你手头是Pascal VOC格式转成COCO也不难很多数据标注工具都支持直接导出COCO格式。我建议你拿到任何数据集先做一次统一的目录规划datasets/ my_project/ train/ images/ # 训练图片 annotations/ # train标注JSON val/ images/ # 验证图片 annotations/ # val标注JSON图片路径和标注JSON里的路径一定不要用绝对路径否则换一台机器全都要改。我吃过这个亏后来统一改成相对路径配合NanoDet配置里设置的img_path一起用就清爽了。还有一个容易被忽略的点类别ID要从1开始连续编号不要用0。COCO格式里背景默认是0如果你的类别ID直接编成0、1、2训练时模型会把某个真实类别当成背景loss直接异常精度一塌糊涂。2.2 标注质量、类别均衡与数据增强轻量模型因为容量小拟合能力有限对数据质量特别敏感。大模型可能靠强拟合能力把脏数据的影响消化掉NanoDet这种小模型就直接把错误学进去了。我做了个对比实验第一版训练集里有一批二维码标签标注框偏大把一大片背景都包进框里模型学完之后的检测框就普遍比真实目标大一圈。后来我把这批数据重新标了一遍同一个模型验证集mAP直接涨了3个多点边框贴合度也好很多。所以标注的时候注意三点框要紧紧贴着目标边界宁可略紧不要略松。漏标和错标要清理干净每类至少在图片里抽查10%确认。保存之前统一检查类别名和配置里的class_names是否完全一致。类别均衡也很重要。如果你训练集里某个类别只有另一类的五分之一模型大概率会把少数类漏掉。我的做法是先统计每类样本数对少的类别想办法补充数据实在补不到就把多余的重采样让最少的类别达到最多类别的三分之一以上。对于本身就稀缺的类别还可以把该类的图片多复制几份参与训练配合随机增强降低过拟合。数据增强方面NanoDet配置里默认会开Mosaic、随机翻转、随机裁剪这一套。Mosaic把四张图拼成一张等于在扩大训练样本同时增加了目标位置的多样性对小模型友好。我的经验是保持默认开启但如果你数据集里小目标特别多可以适当调低随机裁剪的强度避免把小目标裁掉。3. 配置文件逐项拆解与训练启动NanoDet的yml文件怎么读3.1 一个最小可用的配置示例NanoDet的配置文件是YAML格式训练入口会读取这个文件决定模型结构、数据路径和训练策略。我以自己实际用过的416分辨率配置为例把关键项抽出来看model: arch: name: NanoDetPlus backbone: GhostNetV2-1.0 neck: NAFP-256 head: NanoDetPlusHead-256 data: train: dataset: name: CocoDataset img_path: datasets/my_project/train/images/ ann_path: datasets/my_project/train/annotations/train.json input_size: [416, 416] val: dataset: name: CocoDataset img_path: datasets/my_project/val/images/ ann_path: datasets/my_project/val/annotations/val.json input_size: [416, 416] schedule: total_epochs: 120 lr: 0.02 warmup_iters: 100 warmup_lr: 0.0005 mode: cosine optimizer: type: SGD momentum: 0.9 weight_decay: 0.00005这里最需要留意的是学习率。NanoDet给的学习率通常和batch size挂钩配置里的lr是相对某个batch size设计的。如果你改小batch size学习率也要等比缩小否则梯度更新步长过大训练容易发散。我习惯按新batch size除以原batch size再乘以原lr来估算比如原配置batch size是160、lr是0.14我机器只能跑8的batch那lr大致取0.007左右起步再观察loss变化微调。另外input_size决定了训练分辨率。分辨率越高小目标越容易检出来但端侧速度会变慢。我建议先在416上把流程跑通后面再根据部署速度要求降到320或者上升到640测试不要一上来就上高分辨率。3.2 训练命令与预训练权重的使用配置写好之后训练命令非常简单python tools/train.py --cfg config/my_nanodet.yml --pretrained ./weights/nanodet_plus_m_416.pth这里强烈建议加载预训练权重。NanoDet官方在COCO上训练过的权重已经让模型学会了通用的特征提取能力相当于一个先修过基础课的学生。你加载之后在自己的数据集上微调收敛快精度也比随机初始化高出一大截。我实测同一个数据集带预训练的训练结果比从头训能高4-6个点的mAP而且训练时间缩短一半以上。如果不带预训练也可以训但需要把total_epochs拉长很多并且小心观察loss会不会中途激增。小模型从头训练很容易被数据噪声带偏我不推荐新手这么做。训练过程中NanoDet会周期保存checkpoint默认几百步存一次。我建议你不要只在最后等一个模型把多个checkpoint都留着后面部署对比用。因为训练最后几轮精度可能在小幅波动选一个验证集上最稳的版本比选最后一个版本更靠谱。4. 训练曲线的观察与调参不要被loss下降欺骗4.1 日志里真正要看哪几个数训练开始之后终端里会持续打印loss和各类分支损失常见的是总loss、分类质量损失、分布损失、GIoU损失以及当前学习率。很多人只看总loss但我习惯把几个分支loss拆开看因为总loss下降有时候是某个分支在掩盖另一个分支的问题。我的观察顺序是前几百步loss应该快速下降说明模型开始学习。如果loss下降后突然反弹先看学习率是不是在warmup结束时跳变了。GIoU损失异常高大概率是标注框有问题或者正样本匹配不对。分类质量损失一直压不下来大概率是类别不均衡。除了lossNanoDet还有个eval流程训练中会在验证集上跑mAP。我强烈建议打开这个选项因为它才是真正反映模型好坏的数。有时候loss还在降但mAP已经不动甚至掉了这说明模型开始过拟合训练集此时就该停。4.2 我实测中遇到的两个典型翻车现场第一个是loss变成NaN。我遇到过结论是学习率太大加上batch太小BN层统计不稳定导致的。解决办法是把lr再往小调一个量级同时把batch提高到4以上。还有一个隐藏坑输入图片里存在全黑或者全白的异常图归一化之后可能出现除零之类的问题把这类图片从数据集里清掉就恢复了。第二个是训练集loss很低但验证mAP很差。这个基本是过拟合轻量模型在数据量少的时候特别容易犯。我第二次训练只收集了800张图20个epoch之后训练loss还在降验证mAP却原地踏步。后来加了数据增强强度、提前设置了早停条件、把总epoch从120降到80情况立刻好转。训练曲线还有个经验不要追求loss曲线绝对平滑。小模型训练过程本身就有噪声平滑到完全不波动反而不正常。只要整体趋势下降、验证指标同步上升就让它训着。我见过有人因为曲线抖了一下就反复调参结果把本来没问题的模型调崩了。下表是我常用的几个调参方向现象优先检查项调整建议Loss发散或NaN学习率、batch size、脏数据学利率降一半清理异常图片训练好但验证差过拟合加强数据增强、降epoch、加数据少数类漏检类别数量不均衡补数据、重采样、提高该类别权重小目标不检分辨率不足加大input_size检查随机裁剪强度5. 导出ONNX并部署到端侧轻量检测的最后一公里5.1 ONNX导出的流程与shape问题训练得到checkpoint之后下一步是导出成ONNX模型。NanoDet官方提供了导出脚本基本用法是把配置文件和权重路径填进去python tools/export.py --cfg config/my_nanodet.yml --checkpoint ./weights/best.pth --out_path ./deploy/my_nanodet.onnx导出过程里我踩过一个很重要的坑模型的输入尺寸必须固定或者把动态轴显式声明好。一开始我导出的是动态shape端侧引擎加载没问题但推理框架在每次输入尺寸变化时都会重新做内存分配导致时延抖动很厉害。后来我按部署设备的实际输入分辨率固定shape导出速度稳定了很多。另外一个坑是某些轻量骨干里的算子比如通道变换、特定卷积在ONNX导出时兼容性不好。解决办法是调整opset版本我一般试opset 11到13哪个能顺利过就用哪个。如果导出后模型里出现异常算子先简化一遍再转通常能解决大半问题。导出之后一定在PC上先用ONNX推理验证一遍结果对比PyTorch原模型的输出。两者数值差一点点正常但如果检测结果差很多说明导出环节出了问题不要直接往端侧搬。5.2 端侧推理的加速与精度控制ONNX模型拿到之后针对不同的端侧引擎还需要做转换常见的是转为NCNN、MNN这类格式或者针对特定硬件转成加速模型。转换本身不难难的是精度保持。我项目里做了两步优化。第一步是用推理框架自带的工具做模型优化把可以合并的算子合并掉第二步是尝试量化把FP32模型压到INT8精度目的就是减少内存占用、提高速度。量化之后模型文件能再缩小到原来四分之一左右速度也能提升三四成。但量化带来的精度损失我们必须实测我的经验是多数场景掉1-2个点可以接受如果掉得更多就要检查一下是不是某个层特别敏感。针对敏感的层我会在量化时单独设置跳过保留FP32其他层照常量化。这种混合精度方案最终让模型在板卡上把精度控制在可接受范围内速度也达到了项目要求的25帧以上。部署另一个关键点是加载和推理的多线程管理。端侧设备上经常有多个任务同时跑模型推理不要绑定在主线程里最好单独起一个推理线程并且控制推理频率。我遇到过模型推理和图像采集抢CPU导致掉帧的问题后来在推理线程里加了峰值限制整机才算稳定下来。部署调优本质上是个平衡游戏精度不够就退回FP32或者提高输入分辨率速度不够就降分辨率、开量化、换更轻的骨干。每次只改一个变量记录结果比同时改好几项更容易定位问题。6. 三轮项目后的踩坑复盘跑通只是开始6.1 数据与标注相关的教训汇总把三轮项目做完我最大的体会是轻量目标检测项目里数据问题占掉至少一半的坑。第一轮我没仔细审核数据测试集本身有错标导致模型明明表现不差验证mAP却永久比别人paper低一截。后来我把验证集重新标注了一遍mAP立刻正常了。这个教训以后我固定下来一个规矩验证集必须人工逐张核对哪怕训练集可以糙一点。第二轮问题出在类别名大小写上。配置文件里写的类别名和标注文件里的大小写不一致模型把同一类学成了两个类效果自然差。建议在改配置的时候直接脚本统计一下标注JSON里的类别集合别用肉眼猜。第三轮是摄像头安装角度变化导致的分布偏移。训练数据全是正上方拍摄的部署现场却是斜45度视角模型精度掉了近一半。后来我在训练集里加入各种角度、光照的拍摄数据并给测试集单独建了一个模拟现场角度的子集才把问题按住。6.2 部署与运维层面的几个提醒部署之后还有几个容易被忽略的点我简单列一下模型版本要放到代码仓库里一起管理不要只在板卡上留一个文件名叫model.bin的产物后面想复现就抓瞎了。线上模型要记录好训练配置和数据集的版本最好在配置里加一个版本注释否则出了问题没法回溯。推理结果日志要留足方便现场反馈漏检、误检时排查是模型问题还是输入图像质量问题。如果项目会持续加数据建议保留训练脚本和完整数据管线新数据来了直接重训一版再对比旧模型决定要不要替换上线。这些事看起来都不是核心算法但实际项目里往往就是它们决定方案能跑多久。NanoDet的训练和部署本身并不复杂复杂的是你围绕它构建的数据闭环和验证流程。把这套流程做扎实不管是换数据集、换设备还是换分辨率要求你都能在很短的时间内再产出一个可用模型这才是这次实践里真正沉淀下来的东西。