最近把手头一个自训练的目标检测模型真正跑到了手机上从Darknet训练到转成移动端推理格式再到在真机上调帧率整个过程踩了不少坑也积累了一些可复用的经验。项目用的是YOLO-V4和它的轻量版Tiny-YOLO-V4这两个模型在移动端落地时的差别比想象中大得多尤其是自己做数据、自己训练、再压缩部署这条链路很多细节不亲自走一遍根本不知道。这篇文章就把完整过程拆开讲清楚包括训练阶段要注意什么、转换工具怎么选、量化后精度掉了多少、最终帧率怎么拉上去的以及那些文档里不会写的坑。适合正在做嵌入式部署、移动端AI应用或者准备把自己训练的检测模型从PC搬到手机上的开发者参考。1. 项目整体思路与模型选型拆解动手之前先理清了需求要在移动端跑自己训练的模型意味着不能用官方预训练权重而是要用自己的数据集训练出来的检测能力。这个“自己训练”带来的约束比想象中大因为整个技术栈都不是一个单纯的推理问题而是一个闭环问题——训练框架、模型结构、转换工具、推理框架、硬件加速五条线要串起来。任何一环不匹配后面全白做。1.1 为什么选择YOLO-V4和Tiny-YOLO-V4YOLO-V4在这个时间节点仍然是一个很均衡的选择。它在精度和速度之间做得比较稳结构上是CSPDarknet53加SPP和PANet检测头有三个尺度对中小目标的召回率明显好于前面的YOLO-V3。而Tiny-YOLO-V4是它的剪枝版去掉了大部分CSP残差块只保留两个检测尺度卷积核数量和通道数都做了压缩权重文件大概只有YOLO-V4的六分之一。这两个模型放在一起恰好覆盖了移动端两种典型场景Tiny系列满足实时性优先的简单场景完整版满足精度优先但设备性能相对充裕的场景。选择这两个模型而不是最新的一些改进结构还有一层现实考虑Darknet生态和移动端推理框架之间的转换链路已经比较成熟社区里踩过坑的人多遇到问题能找到参考。新结构虽然在指标上更好看但转换工具和算子支持经常跟不上反而耽误进度。这个取舍在工程项目里很常见能用稳定链路解决的问题不急着追新。1.2 移动端跑自训练模型的两个核心约束第一个约束是算力。手机端的CPU和GPU跟桌面显卡不是一个量级YOLO-V4全尺寸模型在PC上轻松跑几十毫秒到了手机端如果不做优化单帧推理可能就要两三秒。Tiny-YOLO-V4虽然计算量小很多但在低端设备上仍然需要合理设置线程数、使用硬件加速接口才能达到可用帧率。第二个约束是模型格式。Darknet训练出来的是weights和cfg文件这个格式不能直接被移动端推理框架加载必须转换成通用格式。转换不是简单的格式替换中间涉及算子映射、权重重排、归一化方式对齐任何一个环节理解不到位转出来的模型要么直接崩要么检测结果完全不对。这个转换链路是整个项目里最考验细节的一环。1.3 项目整体流程设计整个流程被我拆成了四个阶段。第一阶段是数据集整理与训练确认模型在PC端能达到预期的检测效果同时保存好训练过程中的anchors、类别映射这些关键配置第二阶段是格式转换把Darknet模型转成移动端推理框架支持的格式第三阶段是精度验证在手机端跑通推理后用同一批测试图跟PC端结果逐张对比确认转换没有引入不可接受的精度损失第四阶段是性能优化通过量化、线程调度、输入尺寸调整等手段把帧率拉到可用水平。这个顺序不能乱尤其是第二阶段和第三阶段的关系。很多人转换完直接在手机上跑一两个视频觉得“好像能检测”就以为成功了。实际上只有当输出框的坐标、置信度和PC端结果精确一致才能证明转换链路没有出错。我见过转换后置信度普遍偏低但形状还能看的情况这种模型如果直接上线漏检率会很高而且极难排查。所以精度验证这步必须较真。2. 训练阶段的准备工作与关键参数训练自己的YOLO模型数据质量直接决定最终部署效果。移动端部署场景下这个问题会被放大因为量化之后模型表达能力本身有损如果训练数据又脏又乱量化后的模型基本就没法用了。2.1 数据集标注与目录组织我用的标注工具以LabelImg为主输出Pascal VOC格式的XML然后转成Darknet需要的YOLO格式。YOLO格式每个图片对应一个同名txt文件每一行是“类别id x_center y_center width height”四个坐标都是归一化到0到1之间的相对值不是像素值。这个归一化格式在Darknet训练没问题但转换到移动端之后很多后处理代码里对坐标的理解不一样稍后讲推理解码时会细说。数据目录我按Darknet的习惯组织了train.txt和val.txt每个文件里是图片路径。有个细节值得注意如果用了预训练权重做迁移学习训练时cfg文件里的类别数和detector层的filters必须改对。具体来说每个yolo层前面的卷积层filters数等于(类别数5)*3。比如检测5类目标filters就是(55)*330。这个数字错了会直接报维度不匹配的错或者训练过程loss崩掉。2.2 anchors的计算与选择逻辑自己训练还有一个关键参数是anchors。官方权重自带的anchors是针对COCO的80类通用目标直接用在自训练数据集上往往不是最优。Darknet提供了k-means聚类脚本可以基于自己数据集中所有标注框的宽高聚类出最适合当前数据分布的锚点尺寸。聚类的主要坑在于聚类脚本读的是txt标注文件中的像素宽高还是归一化宽高不同版本的脚本处理方式不同算出来的结果可能差出几个数量级。如果发现聚类的anchors跟标注框的实际尺寸对不上先检查这一步。锚点数量和尺寸直接影响小目标召回率在Tiny-YOLO-V4上尤其明显——它的尺度层比完整版少一个锚点分布不合理时小目标基本就检测不到了。2.3 训练超参与收敛监控训练参数上我用了比较常规的配置batch取64subdivisions设为16来模拟小batch训练初始学习率0.001到0.01区间按数据集大小调整使用了cosine annealing作为学习率衰减mosaic和flip等数据增强保持开启。移动端场景下物体尺度变化大数据增强不要关掉这比增加网络层数更管用。训练过程中我会重点看两个指标loss曲线和mAP曲线。Darknet在训练时随时按CtrlC进入交互界面输入命令可以查看当前mAP。不要只盯着lossloss降到很低但mAP不涨的情况多半是训练集和验证集分布差异太大或者锚点没算好。训练完成的标志是mAP在验证集上稳定不再上升而不是loss等于某个固定数值。3. 模型转换链路从Darknet到移动端格式训练完成后拿到的产物是weights文件和cfg文件。在行业里常用NCNN作为移动端推理框架它对Darknet的支持比较完善转换工具也是现成的。接下来要说的转换链路就是以NCNN作为移动端推理框架来走。3.1 转换工具链与基本用法Darknet转NCNN的核心工具是darknet2ncnn。在NCNN的tools目录下有对应的源码编译后会生成darknet2ncnn可执行文件。用法很简单./darknet2ncnn yolov4.cfg yolov4.weights yolov4.param yolov4.bintiny模型同理把配置文件和权重路径换掉就行。输出两个文件param文件描述网络结构bin文件存储权重数据。param是文本格式可以直接打开查看每一层的名称、类型和参数bin是二进制格式正常不会去动它。这里有个常见的坑cfg文件里如果有NCNN尚未支持的层类型转换工具会直接报错中断。YOLO-V4用到的Mish激活函数、SPP模块虽然现在NCNN已经支持但不同版本NCNN支持情况有差异。编译转换工具时注意版本匹配尽量用较新的稳定版本。3.2 转换后的结构校验方法转换成功只是第一步结构正确才是关键。我会打开param文件对照cfg文件检查三件事。第一yolo输出层的输出特征图尺寸是否跟cfg里的width、height和stride对应第二各层之间的blob名称是否按顺序连通第三最后的三个yolo分支是否都保留完整没有在转换过程被丢弃。这些检查看着繁琐但能避免后面在手机上推理时出现维度不匹配的崩溃。还有一种更直观的验证方式就是用NCNN的benchmark工具跑一遍模型看每层的计算耗时和输出shape。某个中间层输出shape跟预期明显不符说明转换过程可能跳层或者合并层时出了问题。把param里的结构打印出来跟Darknet的网络结构图对比基本能锁定问题位置。3.3 INT8量化与校准流程模型跑通之后下一步是量化。NCNN支持fp32、fp16和int8三种精度移动端为了速度优先通常会做int8量化。量化流程分两步先把fp32模型转成fp16再把fp16模型转成int8。注意int8量化需要校准数据。校准数据的准备方法是从训练集里选几百张有代表性的图片用NCNN的量化工具加载fp16模型跑一遍统计每层激活值的分布范围然后根据分布生成量化表。这个量化表就是int8模型能够保持精度的关键。校准集不要只选简单图片要涵盖各种光照、遮挡、目标大小的场景否则量化后模型在复杂场景下会明显掉点。校准完成后会把量化表以二进制文件形式跟模型一起部署。实际推理时NCNN每层都会用这个表做反量化计算把int8计算的结果映射回浮点范围。如果跳过校准直接转int8模型往往输出乱码或者置信度全部归零——这里已经帮大家试过了。4. 移动端推理代码与后处理实现模型转换好只是“模型就绪”真要在手机上出检测框还需要写推理代码和后处理逻辑。这部分工程量大但模式比较固定核心是处理好输入图像、推理、解码和NMS的衔接。4.1 推理引擎初始化与前处理NCNN在Android上推荐用Java层API或C都行。我用C封装了核心推理逻辑通过JNI暴露给上层调用。初始化NCNN时有几个参数要设置线程数、是否使用GPU加速、CPU模式。ncnn::Net net; net.opt.use_vulkan_compute true; net.opt.num_threads 4; int ret net.load_param(yolov4_tiny.param); ret net.load_model(yolov4_tiny.bin);前处理部分NCNN接收的输入数据是浮点数组需要把Android的Bitmap转成RGB数据然后resize到网络输入尺寸。YOLO系列网络的输入尺寸是32的整数倍我统一用的416x416。resize时不要用Bitmap本身的缩放先把Bitmap转成RGB数组再用NCNN的接口做转换这样能避免颜色通道顺序出错。实际踩过坑Android Bitmap默认是RGBA格式如果直接把byte数组传给网络不转成RGB检测框位置正确但类别置信度全乱。4.2 输出解码从特征图到检测框网络输出的原始特征是NCHW布局的浮点数组含义是每个位置预测的边界框参数。以Tiny-YOLO-V4为例两个输出层分别对应13x13和26x26的特征图每个cell有3个锚点每个锚点输出(5类别数)个值其中5对应x、y、w、h和objectness。解码逻辑包含三个关键步骤。第一步把x、y加上网格偏移再乘以stride得到框中心点在原图中的坐标第二步把w、h用exp函数映射并乘以对应锚点尺寸得到框的宽高第三步把classification和objectness相乘得到最终置信度低于阈值的框直接丢弃。解码完成后是NMS非极大值抑制。YOLO-V4输出框数量多如果NMS实现得不好耗时比推理本身还高。一个实用技巧是先用置信度阈值过滤把候选框数量压到几百以内再做NMSNMS的IoU阈值在0.4到0.5之间比较合适。4.3 边界情况处理推理代码里还有个容易出问题的边界情况原图不是正方形。直接用等比例缩放后填充灰色或黑色边这个填充操作会影响检测精度吗实测下来填充本身不会影响精度但填充比例过大会浪费计算量。更优的做法是letterbox到输入尺寸后再推理推理完把框坐标映射回原图时需要减去填充偏移再除以缩放比例。坐标映射这块我建议写一个单元测试用一个已知目标位置测试整条链路PC端Darknet检测的坐标和手机端检测的坐标在几个像素的误差范围内保持一致。这个测试通过之后后续改任何参数都能快速知道有没有改坏东西。5. 性能调优实践对比YOLO-V4与Tiny-YOLO-V4性能是移动端模型最硬的需求。同样一个自训练模型完整版和轻量版在手机上的表现差异非常直观尤其是在中端设备上。这里记录一组实际测试数据也把调优过程中有效的方法列出来。5.1 同机型上两个模型的实际性能对比测试平台是某品牌的旗舰定位手机8核CPU支持GPU加速。模型输入416x416单独测试推理耗时、内存占用和检测精度。Tiny-YOLO-V4在CPU上单帧推理大约80到120毫秒开启GPU加速在40到60毫秒完整版YOLO-V4在CPU上单帧推理要600到900毫秒GPU加速后约200到300毫秒。内存方面Tiny模型占用约80MB完整版约250MB。精度上完整版在自训练数据集上有明显优势小目标尤其突出。指标Tiny-YOLO-V4YOLO-V4参数量约580万约6400万CPU单帧耗时80-120ms600-900msGPU单帧耗时40-60ms200-300ms内存占用约80MB约250MB自测集mAP0.720.86从这个对比能看出这两个模型在移动端面向的场景差异非常明显。如果业务目标是实时视频流检测Tiny版是唯一选择如果允许每帧等待200到300毫秒做离线分析完整版能带来近14个点的精度提升。所以它们不是替代关系而是搭配使用的关系。5.2 量化对性能与精度的实际影响int8量化带来的性能提升是显著的。同一个Tiny模型fp32在CPU上耗时约100毫秒int8可以降到约35毫秒几乎三倍提速。精度损失却在2到3个百分点以内这个可以接受。完整版YOLO-V4在int8量化后也从700毫秒降到约250毫秒但精度损失会稍大大约4到5个百分点这与其网络深度和动态范围分布有关。量化后的精度损失可以通过两点来控制。第一校准集要覆盖典型场景不要跟训练集分布差异过大第二如果某个层量化后输出数值范围异常可以在NCNN的量化工具中手动指定该层的量化策略跳过某些敏感层不量化。敏感层通常是最前面的卷积层和最后的检测头这两个部分对数值精度最敏感。5.3 线程调度与输入尺寸的平衡线程数对NCNN推理耗时影响很明显但不是越多越快。实测4线程比2线程快一倍但8线程只比4线程快了10%到20%有时因为线程切换开销反而变慢。不同手机核心数量不同我在代码里根据设备CPU核心数动态设置线程数核心多于6个时取4少于等于4个时取4的一半。输入尺寸是另一个变量。Tiny模型416x416的耗时如果还嫌高可以降到320x320速度能再提升约30%代价是检测小目标明显变弱。如果业务场景以大目标为主320x320是更优选择。这里给个建议不要直接改网络输入尺寸然后拿着旧权重硬跑应该回到训练阶段用相同的输入尺寸重新finetune一点点这样精度损失可以降低很多。5.4 一个有效的调优顺序实际操作中我习惯按照固定顺序优化先确认模型和代码链路无误再开GPU加速再按需做量化最后调线程和输入尺寸。GPU加速和int8不要同时开因为部分GPU驱动对int8的支持不稳定可能出现偶发崩溃。线程数和输入尺寸属于“最后10%”的优化手段前面的动作做完之后再来抠。6. 常见问题与排查技巧实录移动端跑自训练模型的坑集中在一开始的三天内过了那段时间后面基本是一路顺畅。这里把遇到的典型问题整理成速查表并附上排查思路。6.1 转换与加载阶段高发问题现象可能原因解决方法darknet2ncnn报错说层未支持cfg包含较新的算子转换工具版本太旧升级NCNN到最新版或改cfg替换特殊算子param加载成功bin加载崩溃param和bin版本不匹配权重文件不完整重新转换注意weights文件需下载完整推理结果NaN输入未除以255或模型量化表未匹配检查输入预处理确认量化表加载路径正确输出置信度全部接近0yolo层输出解析维度错误类别数不匹配用netscope输出结构图与param逐层核对转换阶段最花时间的一次排查是cfg里的ReLU和leakyReLU被NCNN合并优化后输出结构发生了变化。表面上看参数没问题但某一层的输出一直对不上。后来用benchmark工具逐层打印输出shape才定位到是合并层后的blob名称不一致导致解析代码拿错了输出层索引。此后我在解析之前都会用代码打印所有输出层的名称和shape跟param文件逐行对齐不再凭记忆写死索引。6.2 推理性能问题的排查思路如果帧率很低而不是加载崩溃问题定位顺序建议从外到内。先确认是否开启了GPU加速不支持的设备上ncnn会自动回退CPU但日志不一定显眼其次确认线程数和模型输入分辨率这两个值对性能影响最大再确认是否完成了量化纯fp32模型在移动端实时性很难保证最后检查功耗和发热长时间高负载运行如果触发系统降频帧率也会断崖式下降。6.3 检测效果不佳的定位方法检测效果不佳分两种。一种是框的位置准但置信度低这类问题指向后处理解析往往别的都对但置信度计算时忘了乘class score或者NMS的IoU阈值太高把相邻的目标误合了。另一种是框偏得离谱这类问题指向坐标映射错误建议检查letterbox填充偏移或解码时stride乘错了比例尺。个最实用的排查技巧在PC上用Darknet自带的detector命令输出一张测试图的检测结果保存坐标在手机端用同一张图推理并保存坐标然后写脚本直接计算两组坐标的欧式距离。如果距离超过几个像素说明转换或后处理有问题。这个离线回归脚本我后来每次调整部署代码都会跑一遍大大缩短了回归测试时间。7. 写在最后的一些实际经验整个项目做下来我最大的体会是移动端跑自训练模型最难的其实不是模型本身而是把训练、转换、推理、调优这条链路完整打通。单独看每一步都有很多现成资料但串起来之后会遇到各种衔接处的隐性坑这些坑单独搜索很难找到准确答案往往要靠自己反复试验和推断。如果给后来者一个建议我会说从Tiny-YOLO-V4起步。它模型小、转换快、排查容易先把整条链路跑通再切换到YOLO-V4做精度对比会轻松很多。上来就直接上完整版遇到问题时变量太多很难定位到底是训练问题、转换问题还是推理代码问题。另外一个珍贵经验是保留一个“版本化”的回归脚本。每次改动部署配置跑一遍同样的测试图片记录帧率和检测结果。这样能清楚知道每次改动带来的是正的还是负的效果比靠记忆判断靠谱太多。移动端部署是一个不断调优的过程有数据支撑才能走得更远。
