RV1106边缘端图像分类部署：四大轻量模型量化实测与选型指南

RV1106边缘端图像分类部署：四大轻量模型量化实测与选型指南

发布时间：2026/10/19 1:03:00
RV1106边缘端图像分类部署：四大轻量模型量化实测与选型指南 1. 边缘端图像分类部署的选型困局搞嵌入式AI这几年我最大的感受就是训练模型容易部署模型要命。尤其是在瑞芯微RV1106这种定位轻量级边缘计算的芯片上跑图像分类选哪个模型、怎么量化、精度掉多少、帧率能不能看这些问题不实际跑一遍根本不知道答案。网上大部分资料要么只讲理论要么只贴一个模型的结果缺少横向对比。我前后花了三周时间把MobileNetV2、ResNet18、EfficientNet-Lite、ShuffleNetV2这几个主流图像分类模型在RV1106上完整部署了一遍记录下量化前后的精度变化、推理耗时、内存占用这些关键数据整理成这篇实验分析。RV1106这颗芯片值得单独说一下。它内置了NPU算力标称0.5TOPS左右主打低功耗场景比如智能门锁的人脸识别、工业质检的简单分类、农业场景的病虫害初筛。它的NPU对算子支持有明确限制不是所有模型都能顺利转换。我见过不少人拿着PyTorch训练好的模型直接往RKNN工具链里塞结果转换报错或者精度崩掉最后卡在部署环节。所以这篇文章的目标很明确给正在做RV1106图像分类部署的同行一份可复现的参考把每个模型的转换参数、量化策略、实测数据都摊开讲。适合谁看如果你已经会用PyTorch或TensorFlow训练分类模型但对RKNN工具链不熟或者你正在选型阶段想知道哪个模型在RV1106上性价比最高这篇文章能帮你省掉大量试错时间。如果你完全没接触过模型部署建议先补一下ONNX和量化的基础知识不然有些参数你会看得云里雾里。2. 实验环境与工具链搭建2.1 硬件与软件版本锁定部署实验最怕版本不一致我踩过最大的坑就是RKNN Toolkit版本和板端NPU驱动不匹配导致推理结果完全错乱。所以先把环境固定下来。硬件方面我用的是一块RV1106开发板1GB DDR3内存板载SPI NAND Flash。PC端是一台Ubuntu 20.04的机器32GB内存没有独立显卡也行因为量化校准不需要GPU。板端系统是Buildroot内核版本4.19。软件版本这块必须严格对齐组件版本说明RKNN Toolkit21.5.2PC端模型转换工具RKNN Runtime1.5.2板端推理库Python3.8工具链依赖PyTorch1.10.0模型训练框架ONNX1.12.0中间格式导出NumPy1.21.0数据处理注意RKNN Toolkit2的1.5.x版本对RV1106的支持最稳定1.6.x虽然功能更多但部分算子行为有变化建议新手先用1.5.2跑通流程。安装RKNN Toolkit2的时候官方wheel包对Python版本和系统架构有要求。我试过在Ubuntu 22.04上装依赖冲突搞了半天最后还是退回20.04。安装命令大概是这样pip install rknn_toolkit2-1.5.2-cp38-cp38-linux_x86_64.whl装完之后用python -c from rknn.api import RKNN验证一下没报错就说明环境OK。2.2 模型导出与ONNX中间格式处理四个模型我都是在PyTorch里训练好的数据集用的是自己采集的工业零件缺陷分类数据共8个类别训练集8000张验证集2000张。输入分辨率统一设为224x224方便横向对比。导出ONNX的时候有几个细节要注意。第一torch.onnx.export的opset_version建议设为11或12RV1106的NPU对这两个版本的算子映射支持最好。第二导出时要把模型设为eval()模式否则BatchNorm层的行为会不一致。第三动态轴要固定RV1106不支持动态shape输入。以MobileNetV2为例导出代码大致如下import torch import torchvision.models as models model models.mobilenet_v2(pretrainedFalse, num_classes8) model.load_state_dict(torch.load(mobilenetv2_best.pth)) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, mobilenetv2.onnx, opset_version11, input_names[input], output_names[output], do_constant_foldingTrue )导出完成后我习惯用onnxsim做一次简化把冗余的算子合并掉这样RKNN转换时出错概率会低很多onnxsim mobilenetv2.onnx mobilenetv2_sim.onnxResNet18和ShuffleNetV2的导出流程类似EfficientNet-Lite稍微特殊一点因为它本身有Lite版本的结构我直接用了开源实现导出时注意把Swish激活函数替换成ReLU否则RV1106的NPU不支持。2.3 RKNN模型转换与量化配置这一步是整个部署流程的核心。RKNN Toolkit2的转换脚本我写了一个通用模板四个模型共用只需要改模型路径和输出路径。from rknn.api import RKNN rknn RKNN(verboseTrue) # 配置参数 rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrv1106, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) # 加载ONNX模型 ret rknn.load_onnx(modelmobilenetv2_sim.onnx) if ret ! 0: print(Load ONNX failed) exit(ret) # 构建模型开启量化 ret rknn.build(do_quantizationTrue, dataset./dataset.txt) if ret ! 0: print(Build failed) exit(ret) # 导出RKNN模型 ret rknn.export_rknn(./mobilenetv2.rknn) if ret ! 0: print(Export failed) exit(ret) rknn.release()这里有几个关键参数需要解释。mean_values和std_values是归一化参数必须和训练时的预处理一致否则精度会掉得莫名其妙。quantized_dtype选asymmetric_quantized-8这是RV1106 NPU支持最好的量化类型。optimization_level3会做一些算子融合和内存优化但偶尔会导致精度下降如果发现精度异常可以降到2试试。dataset.txt是量化校准数据集列表每行一张图片的路径。我用了200张训练集图片做校准覆盖所有类别。校准集的选择很讲究不能只用某一类的图片否则量化参数会偏向那类数据。实操心得量化校准集建议用验证集里随机抽样的图片数量在100到500之间。太少会导致量化参数估计不准太多则转换时间过长。我试过用50张精度掉了3个百分点加到200张后精度恢复。3. 四个模型的部署实测与数据对比3.1 MobileNetV2轻量级首选的实际表现MobileNetV2是我第一个跑通的模型也是RV1106上最省心的选择。它的深度可分离卷积结构对NPU非常友好转换过程一次通过没有遇到算子不支持的问题。转换后的RKNN模型大小约3.5MB量化后权重从FP32的14MB压缩到3.5MB压缩比4倍。板端推理时单帧耗时在22ms左右算下来约45FPS这个帧率对于大多数边缘分类场景完全够用。精度方面FP32模型在验证集上的准确率是94.2%量化后掉到92.8%掉了1.4个百分点。这个损失在可接受范围内而且我发现通过调整量化校准集可以把精度损失控制在1个百分点以内。内存占用是我比较关心的指标。RV1106只有1GB内存系统本身占掉一部分留给模型推理的空间有限。MobileNetV2推理时的峰值内存约180MB其中NPU内部缓存占了大头。这个数字意味着你可以在同一块板上同时跑两个MobileNetV2实例做双路视频流的分类。3.2 ResNet18精度与速度的权衡ResNet18的结构比MobileNetV2重不少参数量约11M是MobileNetV2的三倍多。转换过程倒是顺利残差连接在RV1106的NPU上有原生支持没有出现算子拆分的问题。模型大小方面FP32的ONNX约45MB量化后RKNN模型约11MB。板端推理耗时约58ms帧率约17FPS。这个速度做单路视频分类勉强够用但如果要做多路或者实时性要求高的场景就有点吃力了。精度上ResNet18确实有优势FP32准确率96.5%量化后95.1%掉了1.4个百分点。和MobileNetV2的精度差距从FP32的2.3个百分点缩小到量化后的2.3个百分点基本持平。这说明量化对ResNet18的影响和MobileNetV2差不多。但这里有个隐藏成本ResNet18的推理功耗明显更高。我用功率计测了一下MobileNetV2推理时板子整体功耗约1.2WResNet18去到了1.8W。对于电池供电的设备这个差距会直接影响续航。3.3 EfficientNet-Lite结构改造的代价EfficientNet-Lite是我花时间最多的一个模型。原版EfficientNet用了Swish激活函数和SE模块这两个在RV1106的NPU上都不支持。Swish可以替换成ReLU但SE模块的全局池化和通道注意力机制需要手动改写。我参考了开源社区的EfficientNet-Lite实现把SE模块去掉Swish换成ReLU6重新训练后精度从原来的96.8%掉到95.3%。这个精度损失是结构改造带来的不是量化造成的。转换过程还算顺利改造后的模型没有不支持的算子。量化后模型大小约4.2MB比MobileNetV2略大。板端推理耗时约28ms帧率约35FPS介于MobileNetV2和ResNet18之间。量化后的精度是93.6%从95.3%掉了1.7个百分点比前两个模型略高。我分析原因是EfficientNet-Lite的深度可分离卷积层更多量化误差累积更明显。注意如果你打算用EfficientNet系列一定要先确认目标芯片支持哪些激活函数。RV1106不支持Swish强行转换会在build阶段报错。替换激活函数后需要重新训练不能直接拿原版权重转换。3.4 ShuffleNetV2极致轻量的边界ShuffleNetV2是四个模型里最轻的参数量约2.3M比MobileNetV2还少。它的通道混洗操作在RV1106上有对应的NPU算子转换没有障碍。模型大小只有2.1MB量化后更是压缩到1.8MB。板端推理耗时约15ms帧率约66FPS是四个模型里最快的。这个速度甚至可以跑三路视频流分类。但精度是它的短板。FP32准确率91.8%量化后89.5%掉了2.3个百分点。这个精度对于简单分类任务够用但如果你的类别之间差异细微比如工业缺陷的细分类ShuffleNetV2可能力不从心。内存占用方面ShuffleNetV2推理峰值约120MB是四个模型里最低的。如果你的板子内存特别紧张或者需要同时跑多个模型ShuffleNetV2是唯一的选择。3.5 四模型横向数据汇总把四个模型的关键数据整理成表格方便直接对比模型参数量量化后大小推理耗时帧率FP32精度量化精度精度损失峰值内存MobileNetV23.4M3.5MB22ms45FPS94.2%92.8%1.4%180MBResNet1811.2M11MB58ms17FPS96.5%95.1%1.4%320MBEfficientNet-Lite4.7M4.2MB28ms35FPS95.3%93.6%1.7%210MBShuffleNetV22.3M1.8MB15ms66FPS91.8%89.5%2.3%120MB从这张表可以得出几个结论。第一量化精度损失和模型结构有关深度可分离卷积越多的模型量化损失越大。第二ResNet18的精度优势在量化后并没有拉开明显差距但速度和功耗劣势明显。第三MobileNetV2在精度、速度、内存三个维度上最均衡是RV1106上的默认推荐。4. 部署过程中的典型问题与排查实录4.1 转换阶段报错与解决转换阶段最常见的问题是算子不支持。RV1106的NPU支持算子列表在RKNN Toolkit的文档里有但文档更新不及时有些算子实际支持但没写进去有些写了但实际不支持。我遇到过的报错包括Unsupported op: SwishEfficientNet原版的问题替换成ReLU解决。Unsupported op: GlobalAveragePool某些版本的ONNX导出会带这个算子用onnxsim简化后消失。Unsupported op: Resize如果模型里有上采样操作RV1106对Resize的支持有限需要改成反卷积或者直接去掉。排查思路是先用rknn.config(verboseTrue)打开详细日志看具体是哪个算子报错然后去ONNX模型里定位这个算子想办法替换或简化。另一个坑是输入shape不匹配。RV1106要求输入是固定的NHWC格式如果你的ONNX模型是NCHWRKNN转换时会自动插入transpose算子这个算子会拖慢推理速度。解决办法是在导出ONNX时就转成NHWC或者在RKNN config里指定inputs_formatnhwc。4.2 量化精度异常排查量化后精度掉太多一般有三个原因。第一是校准集选择不当比如校准集里某个类别的图片特别多量化参数就会偏向那个类别。解决办法是确保校准集类别均衡每个类别至少20张。第二是预处理参数不匹配。训练时的归一化参数和RKNN config里的mean_values、std_values必须完全一致。我见过有人训练时用了ImageNet的均值方差部署时忘了改精度直接掉10个百分点。第三是量化类型选错。RV1106支持asymmetric_quantized-8和dynamic_fixed_point-8两种前者对大多数模型效果更好但某些模型用后者精度更高。如果发现精度异常可以两种都试一下。实操心得量化精度排查有个笨办法但很有效——把量化后的RKNN模型在PC端用RKNN Toolkit的仿真推理跑一遍和ONNX模型的输出逐层对比看哪一层的输出差异最大。差异大的层往往是量化敏感层可以考虑对这一层保持FP16或者调整量化策略。4.3 板端推理性能优化板端推理性能不达预期除了模型本身的原因还有几个可以优化的点。首先是NPU频率。RV1106的NPU默认频率不是最高档可以通过修改设备树或者用io命令调整。我把NPU频率从默认的400MHz调到600MHz后推理耗时降低了约15%。但频率提高会增加功耗需要权衡。其次是内存分配。RKNN Runtime在推理时会动态分配内存如果内存碎片化严重分配耗时会增加。可以在初始化时用rknn_init的mem_type参数指定预分配内存池减少运行时开销。第三是输入数据的预处理。如果预处理在CPU上做会占用推理时间。RV1106的NPU支持输入数据的归一化可以把mean_values和std_values配置在RKNN模型里让NPU直接处理原始像素数据省掉CPU预处理。4.4 常见问题速查表问题现象可能原因排查方法解决方案转换报错Unsupported op模型含NPU不支持的算子查看verbose日志定位算子替换算子或简化模型量化后精度掉超过5%校准集不均衡或预处理不匹配检查校准集分布和归一化参数重新选校准集对齐预处理板端推理结果全错版本不匹配或输入格式错误检查RKNN Runtime版本和输入shape统一版本确认NHWC格式推理速度远低于预期NPU频率低或内存分配慢查看NPU频率和内存使用提高频率预分配内存池模型加载失败模型文件损坏或内存不足检查文件MD5和可用内存重新导出释放内存5. 选型建议与场景匹配5.1 按场景选模型的决策逻辑选模型不是单纯看精度或者速度而是要匹配你的场景需求。我整理了一个决策流程你可以对照自己的项目来选。如果你的场景是实时视频流分类帧率要求25FPS以上那MobileNetV2和ShuffleNetV2是唯二选择。ResNet18的17FPS达不到实时要求EfficientNet-Lite的35FPS勉强够但余量不大。在MobileNetV2和ShuffleNetV2之间如果精度要求高选MobileNetV2如果速度要求极致选ShuffleNetV2。如果是电池供电的便携设备功耗是首要考虑。MobileNetV2的1.2W功耗最低ShuffleNetV2约1.0W更省但精度差距明显。ResNet18的1.8W功耗对于电池设备来说太高了除非你的电池容量很大。如果是多路视频流处理内存占用是关键。ShuffleNetV2的120MB峰值内存可以让你同时跑4路MobileNetV2的180MB只能跑3路ResNet18的320MB最多跑2路。如果是高精度要求的工业质检精度优先于速度。ResNet18的95.1%量化精度最高但你需要接受17FPS的速度。如果速度不够可以考虑用ResNet18做粗筛再用MobileNetV2做细分类的两级方案。5.2 模型组合与级联策略单一模型很难同时满足高精度和高速度这时候可以考虑级联方案。我的做法是用ShuffleNetV2做第一级快速筛选把明显不属于任何类别的样本过滤掉剩下的难样本交给ResNet18做精细分类。这个方案的实际效果是ShuffleNetV2处理80%的简单样本耗时15msResNet18处理20%的难样本耗时58ms。平均耗时约23.6ms帧率约42FPS精度接近ResNet18的95%。这个方案在工业质检场景下很实用因为大部分产品是合格的难样本只占少数。级联方案的实施要点是两个模型的输入分辨率要一致否则需要做额外的resize操作。另外第一级模型的阈值设置很关键阈值太高会漏掉难样本太低会增加第二级的负担。我一般用验证集来调这个阈值目标是让第二级处理的样本比例在15%到25%之间。5.3 后续扩展方向这套实验框架可以扩展到其他芯片和其他模型。如果你手上有RK3588或者RK3568可以把同样的流程跑一遍对比不同芯片上的表现。RK3588的NPU算力更强ResNet18可能也能跑到实时帧率。模型方面可以试试MobileNetV3、GhostNet这些更新的轻量级结构。MobileNetV3的SE模块需要改造GhostNet的Ghost模块在RV1106上的支持情况我还没测有兴趣的可以试试。另一个扩展方向是目标检测。RV1106也支持YOLO系列的部署但目标检测的后处理比分类复杂得多NPU只负责骨干网络后处理要在CPU上做。如果你要做检测建议先用分类模型跑通整个流程再迁移到检测。最后分享一个小技巧RKNN Toolkit2的仿真推理功能可以在PC端模拟板端NPU的行为包括量化误差。在正式部署到板子之前先用仿真推理验证精度和速度可以省掉大量反复烧录的时间。仿真推理的速度和板端不完全一致但精度趋势是吻合的用来做模型筛选足够了。