1. 为什么要在RV1106上折腾图像分类模型边缘端跑视觉模型这件事这两年从能不能跑变成了怎么跑得划算。瑞芯微RV1106这颗芯片在低功耗IPC、智能门锁、猫眼、宠物喂食器这类产品里出镜率很高它自带NPU官方标称算力在0.5TOPS这个量级配合内置的ISP和轻量级CPU整颗芯片的定位就是用最低的物料成本完成一路视频的采集、编码和基础AI推理。很多做硬件的朋友拿到开发板第一反应是既然有NPU那我直接把MobileNet、ResNet搬上去不就行了实测下来事情没这么简单。我这段时间陆陆续续在RV1106上跑了几个主流的图像分类模型包括MobileNetV2、ResNet18、EfficientNet-Lite、ShuffleNetV2还有几个专门为边缘设计的轻量网络。整个过程踩了不少坑也积累了一些在官方文档里不太容易找到的经验。这篇文章不打算写成一份官方文档复读机而是想把每个模型在RV1106上的真实表现、转换过程中的取舍、量化带来的精度损失、以及最终怎么选型这些事讲清楚。如果你正在做边缘视觉产品选型或者手头正好有一块RV1106的开发板想跑点东西这篇内容应该能帮你省下不少试错时间。需要先说明的是RV1106的NPU对算子支持是有边界的它不是那种什么模型都能塞进去的通用加速器。它的强项在于卷积、池化、全连接这些常规算子对某些特殊结构比如某些注意力机制、动态shape操作支持有限。所以选模型的第一原则不是哪个精度高而是哪个能被完整转换且量化后精度掉得少。这个思路会贯穿全文。2. RV1106的NPU到底能吃下什么2.1 算力账要算清楚别被标称值忽悠RV1106的NPU算力标称0.5TOPS这个数字是INT8精度下的理论峰值。什么意思呢就是说你的模型必须量化成INT8才能跑到这个算力。如果你拿一个FP32的模型直接往里塞要么转换失败要么回退到CPU上跑那速度就是另一个故事了。我实测过一个FP32的MobileNetV2在RV1106的CPU上跑一张224x224的图单帧推理时间在300ms以上基本没有实用价值。而量化成INT8走NPU同样的模型能压到20ms以内差距是十几倍。所以第一件事上RV1106的模型必须走INT8量化路线。这不是可选项是必选项。量化工具链官方提供的是RKNN-Toolkit2它能把ONNX、TensorFlow、PyTorch等格式的模型转成RKNN格式并在转换过程中完成量化。量化需要一份校准数据集通常准备100到500张和实际场景分布接近的图片就够了。校准集的质量直接决定量化后的精度这一点后面会展开讲。2.2 算子支持清单决定了你的模型能不能转RKNN-Toolkit2在转换时会逐层检查算子支持情况。如果遇到不支持的算子它会报错或者把这一层回退到CPU。回退到CPU的层会成为整个推理流程的瓶颈因为NPU和CPU之间的数据搬运开销很大。我遇到过最典型的情况是某些模型里的HardSwish激活函数在早期版本的Toolkit里不支持导致整个MobileNetV3转出来有一大半层跑在CPU上速度比纯CPU还慢。解决办法有两个一是升级Toolkit版本新版本通常会补充算子支持二是在导出ONNX之前就把不支持的算子替换成等价的受支持算子组合。比如HardSwish可以用ReLU6加一些逐元素运算来近似虽然会损失一点精度但能保证全部跑在NPU上。这个取舍在边缘部署里非常常见能全跑NPU的次优模型往往比部分跑CPU的最优模型更实用。2.3 内存带宽是隐藏的瓶颈RV1106的NPU算力虽然不高但对于轻量模型来说够用。真正容易出问题的是内存带宽。NPU在推理时需要频繁读写特征图如果模型的特征图通道数很大、分辨率很高内存带宽就会成为瓶颈表现为算力利用率上不去。我实测发现当输入分辨率从224x224提升到320x320时某些模型的推理时间增长并不是线性的而是超线性的原因就是特征图变大后带宽压力陡增。所以在RV1106上输入分辨率的选择要克制。224x224对于大多数分类任务已经够用如果非要上320x320建议先测一下带宽是否扛得住。另外模型的通道数也要控制像ResNet那种动辄512、1024通道的结构在RV1106上跑起来带宽压力会很明显。3. 四个主流模型的实测数据与踩坑记录3.1 MobileNetV2最稳的选择但量化有讲究MobileNetV2是我在RV1106上跑得最顺的模型。它的深度可分离卷积结构对NPU友好算子全部受支持转换过程基本没有障碍。我用ImageNet预训练权重输入224x224校准集用了200张来自实际场景的图片量化后Top-1精度从FP32的71.8%掉到70.2%损失1.6个百分点完全可以接受。推理时间稳定在18到22ms之间具体取决于CPU负载。但这里有个坑MobileNetV2的量化对校准集非常敏感。我第一次用随机从网上下的图片做校准精度掉了将近5个百分点。后来换成和实际部署场景一致的图片比如都是室内场景、光照条件接近精度损失就控制在了2个点以内。原因是量化需要统计激活值的动态范围如果校准集和实际输入分布差异大量化参数就会偏导致精度崩塌。所以校准集一定要用真实场景的数据哪怕只有100张也比1000张不相关的图强。另一个经验是MobileNetV2的最后一层全连接之前有个Dropout导出ONNX时记得把它去掉否则转换会报错。这个在训练时有用推理时是多余的。3.2 ResNet18精度高但带宽吃紧ResNet18的精度比MobileNetV2高不少FP32下Top-1能到69.8%这里用的是简化版训练不是完整ImageNet但它在RV1106上的表现就没那么理想了。转换本身没问题残差结构里的Add算子NPU是支持的但推理时间明显更长224x224输入下要35到40ms。原因就是前面说的带宽问题ResNet18的特征图通道数最大到512中间层的特征图尺寸也不小NPU在读写这些数据时带宽压力很大。我试过把ResNet18的输入降到160x160推理时间能压到25ms左右但精度也相应下降。所以ResNet18在RV1106上的定位比较尴尬精度比轻量模型高不了太多速度却慢一截。除非你的任务对精度要求特别苛刻否则不太推荐。如果非要用建议做通道剪枝把每层的通道数砍掉30%到40%再重新微调这样能在精度损失可控的前提下显著降低带宽压力。3.3 EfficientNet-Lite结构优雅但转换有暗坑EfficientNet-Lite是专门为边缘设备设计的去掉了SE模块和Swish激活理论上应该很适合RV1106。实际转换时确实比原版EfficientNet顺利但还是在MBConv结构里的某些逐元素乘法上遇到了问题。具体来说EfficientNet-Lite的MBConv里有一个Multiply操作用于把两个分支的特征图相乘这个操作在早期Toolkit版本里不支持导致转换失败。解决办法是升级到较新的RKNN-Toolkit2版本新版本已经支持了这个算子。升级后转换通过量化后精度损失在2.5个百分点左右推理时间224x224下约28ms。这个成绩介于MobileNetV2和ResNet18之间精度也介于两者之间。EfficientNet-Lite的优点是参数量小模型文件只有几MB适合存储空间紧张的场景。但它的推理时间对输入分辨率更敏感分辨率一上去速度掉得很快所以建议固定在224x224使用。3.4 ShuffleNetV2速度最快但精度是短板ShuffleNetV2的设计目标就是极致轻量它在RV1106上的推理时间是最短的224x224下只要12到15ms。通道混洗操作NPU是支持的转换很顺利。但代价是精度FP32下Top-1只有65%左右量化后掉到63%上下。这个精度对于简单的二分类或者粗粒度分类任务够用比如区分有人和没人、猫和狗但要做细粒度分类就力不从心了。我的建议是如果你的任务类别数少于10类且类间差异明显ShuffleNetV2是性价比最高的选择。但如果类别数超过50类或者类间差异细微比如不同品种的花还是老老实实用MobileNetV2或者EfficientNet-Lite。3.5 四个模型的横向对比模型FP32 Top-1INT8 Top-1推理时间(224x224)模型大小转换难度MobileNetV271.8%70.2%18-22ms14MB低ResNet1869.8%68.5%35-40ms45MB低EfficientNet-Lite72.5%70.0%26-30ms18MB中ShuffleNetV265.0%63.2%12-15ms8MB低这张表里的数据是我在同一个开发板上反复测出来的测试条件统一单帧推理、CPU空闲、室温环境。实际产品中如果CPU还要跑其他任务推理时间会有所波动。从表里能看出来MobileNetV2在精度和速度之间取得了最好的平衡这也是为什么它成了我在RV1106上的默认选择。4. 从训练到部署的完整链路拆解4.1 模型导出ONNX时的三个关键设置不管你用什么框架训练最终都要导出成ONNX再喂给RKNN-Toolkit2。导出时有三个设置必须注意否则后面转换会出各种幺蛾子。第一固定输入shape。RV1106的NPU不支持动态shape所以导出ONNX时要把输入的batch size和分辨率都固定死。比如input_shape [1, 3, 224, 224]不要用None。如果训练时用了动态shape导出前记得改成固定值。第二去掉训练专用的层。Dropout、BatchNorm的训练模式、各种数据增强算子这些在推理时都不需要导出前要切换到eval模式并移除。PyTorch里用model.eval()TensorFlow里用trainingFalse。BatchNorm在eval模式下会使用训练时统计的均值和方差这个行为要确认清楚否则量化时会有偏差。第三算子版本要匹配。ONNX有不同的opset版本RKNN-Toolkit2对opset版本有要求太高或太低都可能出问题。我一般用opset 11或12这两个版本兼容性最好。如果导出时报错说某个算子不支持先试试降opset版本。4.2 校准集制作100张图怎么选校准集的作用是让量化工具统计每一层激活值的分布从而确定量化的缩放因子和零点。校准集选得好量化精度损失就小选得不好精度可能直接崩掉。我的经验是校准集不需要多100到200张就够但必须满足两个条件分布覆盖和场景一致。分布覆盖的意思是校准集里的图片要涵盖实际部署中可能出现的各种情况。比如你的产品是智能门锁那校准集里就要有白天、夜晚、逆光、侧光、有人、没人、不同肤色、不同角度的人脸图片。如果只放白天的图片晚上部署时精度就会掉。场景一致的意思是校准集不能拿网上的通用图片凑数要用实际设备采集的图片。因为不同摄像头的色彩响应、噪声特性都不一样用A摄像头的数据校准B摄像头的模型效果会打折扣。具体操作上我会从实际场景里采集300张左右的图片然后人工筛选出150张覆盖各种情况的作为校准集。筛选标准是不重复、不极端、有代表性。极端图片比如全黑、全白、严重过曝反而会拉偏量化参数要剔除。4.3 量化精度损失的定位方法量化后精度掉了怎么知道是哪一层的问题RKNN-Toolkit2提供了逐层量化的分析工具可以输出每一层的量化误差。我一般会先看整体精度损失如果损失在2个百分点以内基本可以接受如果超过3个点就要逐层排查。排查方法是把量化后的模型和FP32模型在同一个验证集上跑对比每一层的输出差异。差异大的层就是问题层。常见的问题层有两类一是激活值动态范围特别大的层比如某些ReLU之后的输出最大值和最小值差距悬殊量化时分辨率不够二是通道数特别少的层比如深度可分离卷积里的逐通道卷积通道数少导致量化统计不充分。针对第一类问题可以在训练时加入Clipped ReLU把激活值限制在一个合理范围内减小动态范围。针对第二类问题可以考虑把这层保持FP32不量化虽然会牺牲一点速度但能保住精度。RKNN-Toolkit2支持混合量化可以指定某些层不量化。4.4 板端部署的完整流程模型转成RKNN格式后部署到板子上分几步。首先是把RKNN文件推到开发板的文件系统里通常放在/userdata或者/oem分区。然后写一个C或者Python的推理程序调用RKNN的运行时API加载模型、输入数据、执行推理、取回结果。C版本的推理程序性能最好适合最终产品。Python版本适合快速验证但因为有解释器开销速度会慢一些。我一般先用Python版本验证模型能跑通、精度对得上然后再移植到C版本做性能优化。推理程序里有个细节要注意输入数据的预处理要和训练时完全一致。包括归一化的均值方差、通道顺序RGB还是BGR、resize的插值方式。这些细节如果对不上精度会莫名其妙地掉。我踩过一次坑训练时用的是RGB部署时摄像头输出的是BGR忘了转换结果精度掉了十几个点排查了半天才发现是通道顺序的问题。5. 实测中那些文档不会告诉你的坑5.1 开发板供电不足导致NPU降频这个坑很隐蔽。RV1106的NPU在满载运行时功耗会上升如果开发板的供电能力不足电压会被拉低芯片为了保护自己会自动降频表现为推理时间忽快忽慢。我一开始以为是模型的问题后来换了一个供电能力更强的USB口才解决。所以如果你发现推理时间不稳定先检查供电别急着怀疑模型。5.2 温度对推理时间的影响RV1106在长时间连续推理后芯片温度会上升温度高了之后NPU也会降频。我做过一个连续跑一小时的测试前十分钟推理时间稳定在20ms半小时后升到25ms一小时后稳定在28ms左右。所以如果你的产品需要7x24小时运行散热设计要跟上至少加个散热片或者留出足够的空气流通空间。5.3 多线程推理的陷阱RV1106的CPU核心数不多NPU是单核的。如果你开多个线程同时调用NPU推理不但不会加速反而会因为资源竞争导致整体吞吐下降。正确的做法是单线程串行推理或者用一个生产者-消费者队列让NPU推理和前后处理流水线化。我试过开两个线程同时推理结果总吞吐比单线程还低15%左右。5.4 模型文件加载时间不可忽略RKNN模型在第一次加载时需要初始化NPU这个过程大概需要几百毫秒。如果你的应用是间歇性推理比如门锁只在有人靠近时才推理这个加载时间会影响响应速度。解决办法是在程序启动时就加载好模型保持NPU处于就绪状态而不是每次推理都重新加载。6. 选型建议与后续优化方向6.1 什么场景选什么模型经过这一轮实测我的选型建议是这样的如果任务类别少、类间差异大、对速度要求极高选ShuffleNetV2如果追求精度和速度的平衡选MobileNetV2这也是最稳妥的选择如果存储空间紧张且能接受稍慢的速度选EfficientNet-LiteResNet18在RV1106上性价比不高除非你有特殊的精度需求否则不推荐。还有一个维度是输入分辨率。224x224是甜点分辨率再往上速度掉得快再往下精度掉得快。如果实在需要更高分辨率建议先做感兴趣区域裁剪把目标区域裁出来再送进模型而不是直接提高整图分辨率。6.2 量化感知训练能救回多少精度如果你的任务对精度要求很高量化后损失两三个点都不能接受可以考虑量化感知训练QAT。QAT是在训练阶段就模拟量化的效果让模型提前适应量化带来的误差。我试过在MobileNetV2上做QAT量化后精度损失从1.6个点降到了0.5个点效果很明显。但QAT的训练成本更高需要修改训练代码而且不是所有框架都支持得好。如果时间充裕且精度要求苛刻值得一试。6.3 模型剪枝与知识蒸馏的取舍模型剪枝能直接减少参数量和计算量对降低带宽压力很有帮助。但剪枝后需要重新微调否则精度会掉。知识蒸馏是用一个大模型教一个小模型让小模型学到更好的特征表示。这两种方法可以结合使用先剪枝再蒸馏能在保持精度的同时显著压缩模型。不过这些操作都需要额外的训练资源和时间适合有充足开发周期的项目。6.4 后续可以尝试的方向RV1106的NPU还在迭代新版本的Toolkit会支持更多算子。我建议定期关注官方的更新日志看看有没有新增的算子支持或者性能优化。另外混合量化部分层INT8、部分层FP16也是一个值得尝试的方向能在精度和速度之间找到更好的平衡点。还有就是输入管线的优化比如用硬件ISP直接输出模型需要的格式减少CPU的预处理开销这个对整体帧率的提升可能比换模型还明显。我在实际项目里最后落地的是MobileNetV2加224x224输入加INT8量化这套组合在RV1106上跑到了稳定20ms左右的单帧推理精度满足业务需求功耗和散热也都在可控范围内。这套方案不一定适合所有人但作为一个经过验证的基线至少能让你少走一些弯路。