1. 为什么要在RV1126B上折腾图像分类模型边缘计算这几年从概念落到实地最明显的变化就是各类带NPU的低功耗芯片开始批量出货。瑞芯微RV1126B算是其中比较有代表性的一颗——它面向视觉场景设计内置独立NPU标称算力在2TOPS级别功耗控制得也还算克制常被用在智能门禁、工业质检、车载辅助这类需要本地推理的设备上。我手头正好有一批基于这颗芯片的板子就想着把常见的图像分类模型挨个跑一遍看看实际部署下来到底谁更划算。这篇文章要聊的就是这件事把MobileNet、ResNet、EfficientNet、ShuffleNet这几个主流分类网络通过模型转换工具链部署到RV1126B上对比它们的精度、推理耗时、内存占用和量化后的表现。适合谁看如果你正在做边缘端视觉方案选型或者手里已经拿到了RV1126B的开发板但不知道怎么把训练好的模型塞进去那这篇内容应该能帮你少走一些弯路。我不会只贴一堆跑分表格而是把转换过程中踩的坑、参数怎么调、量化为什么掉点这些细节都摊开讲。需要提前说明的是下面所有实验数据都来自我自己的测试环境不同板子、不同散热条件、不同工具链版本都可能让结果有出入把它当作一个参考基线就好别当成绝对标准。2. 实验环境与模型选型思路2.1 硬件与软件栈的基本盘先交代一下测试平台。板子是基于RV1126B的核心板加底板内存配置是DDR4 2GB存储用eMMC系统跑的是官方提供的Linux SDK。NPU这边通过RKNN工具链来调用版本用的是1.6.0——这个版本对RV1126B的支持比较完整再老的版本有些算子会缺再新的版本我又没来得及验证稳定性所以折中选了这个。软件栈方面模型训练和转换都在一台x86主机上完成系统是Ubuntu 20.04Python环境3.8PyTorch 1.10用来导出ONNX然后通过RKNN-Toolkit2做量化转换。板子端用RKNN Runtime的C接口做推理计时用clock_gettime取单调时钟避免系统时间跳变干扰。注意RKNN工具链的版本和板端Runtime版本必须匹配我一开始用1.5.0转换的模型放到1.6.0的Runtime上跑直接报错说模型版本不兼容。这个坑很隐蔽因为转换阶段不会报任何警告。2.2 为什么挑这几个模型图像分类模型多如牛毛全跑一遍不现实也没必要。我选型的逻辑是覆盖三类典型场景极轻量级、中等精度、高精度但代价大。具体来说MobileNetV2深度可分离卷积的代表参数量小是边缘端最常被拿来当baseline的模型。MobileNetV3-Small在V2基础上加了SE模块和h-swish激活精度更高但结构更复杂想看看NPU对这类结构的友好度。ShuffleNetV2通道混洗操作对硬件实现不太友好正好用来测试工具链的算子支持程度。ResNet18经典残差结构参数量比MobileNet大不少用来观察算力瓶颈在哪里。EfficientNet-B0复合缩放策略的产物精度不错但深度可分离卷积堆得很深对NPU的调度是个考验。输入分辨率统一用224x224这是这些模型的标准输入尺寸也方便横向对比。数据集方面我用了一个自建的10分类数据集大概每类800张图训练集验证集按8:2划分。选10分类而不是ImageNet千分类是因为实际项目里大多数场景的类别数都不多千分类的测试结果参考意义有限。2.3 评估指标怎么定光看推理耗时是不够的边缘端部署要综合考虑多个维度。我定了这几个指标指标含义测量方式Top-1精度分类正确率验证集上统计推理耗时单帧前向时间取100次平均排除首次预热内存占用运行时峰值内存读取/proc/self/status的VmPeak模型体积转换后rknn文件大小文件系统直接读取量化掉点FP16与INT8精度差同一验证集对比这里要特别说一下量化掉点这个指标。RV1126B的NPU对INT8量化支持最好FP16虽然也能跑但算力利用率会打折扣。所以实际部署基本都要走INT8量化而量化必然带来精度损失损失多少直接决定了这个模型能不能用。3. 模型转换与量化实操全流程3.1 从训练框架到ONNX的导出细节不管用什么框架训练第一步都是导出成ONNX。这一步看着简单但坑不少。以PyTorch为例导出的时候有几个参数必须注意torch.onnx.export( model, dummy_input, model.onnx, opset_version11, input_names[input], output_names[output], dynamic_axesNone # 边缘端固定输入不要开动态轴 )opset_version选11是比较稳妥的太高了RKNN工具链可能不支持太低了有些算子表达不了。dynamic_axes一定要设成None因为NPU推理时输入尺寸是固定的开动态轴反而会让后续转换报错。导出之后我习惯用onnxsim做一次简化把多余的Identity、Dropout之类的节点去掉。这一步能减少转换时的算子映射工作量也能避免一些莫名其妙的转换失败。python -m onnxsim model.onnx model_sim.onnx实操心得导出ONNX后一定要用Netron打开看一眼确认输入输出节点名称和维度都对。我有一次因为模型里有个自定义的Reshape层导出后维度变成了-1转换工具直接卡死排查了半天才发现是这里的问题。3.2 RKNN量化配置的关键参数ONNX准备好之后就进入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_platformrv1126b, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) rknn.load_onnx(modelmodel_sim.onnx) rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(model.rknn)这里有几个参数值得展开说。mean_values和std_values必须和训练时的预处理一致否则量化校准会偏。我见过有人训练时用的是0-1归一化转换时却填了ImageNet的均值和方差结果精度直接崩掉。quantized_dtype选asymmetric_quantized-8这是非对称INT8量化对激活值的表达能力比对称量化强尤其适合ReLU6这种非负激活。optimization_level开到3会做一些图层融合和算子替换能提升推理速度但偶尔也会引入精度损失如果发现掉点严重可以降到2试试。dataset参数指向一个文本文件里面是量化校准用的图片路径列表。一般准备100到200张就够了要从训练集里随机抽保证覆盖各个类别。校准集选得不好量化误差会明显放大。3.3 量化校准集的选取策略校准集这件事值得单独拎出来讲。很多人随便拿几张图就去做量化结果精度掉得莫名其妙。我的经验是数量上100到200张足够再多边际收益很低。分布上每个类别都要有且尽量覆盖不同的光照、角度、背景。预处理上校准图片的预处理方式必须和推理时完全一致包括resize的插值方法。我做过一个对比实验用50张单一背景的图做校准MobileNetV2的INT8精度比FP16掉了4.2个百分点换成200张多样背景的图掉点缩小到1.8个百分点。这个差距在實際项目里可能就是能不能上线的区别。4. 各模型部署实测数据与横向对比4.1 精度与量化掉点对比先看最关心的精度数据。所有模型都在同一个验证集上测试FP16和INT8各跑一遍模型FP16 Top-1INT8 Top-1掉点MobileNetV292.3%90.5%-1.8%MobileNetV3-Small93.1%90.2%-2.9%ShuffleNetV291.7%88.4%-3.3%ResNet1894.6%93.8%-0.8%EfficientNet-B095.2%92.1%-3.1%从掉点幅度能看出一些规律。ResNet18掉点最小因为它的结构以标准卷积为主量化友好。MobileNetV3和EfficientNet掉点较大罪魁祸首是h-swish和SE模块——h-swish在零点附近变化剧烈INT8的离散化误差被放大SE模块里的全局池化和通道乘法对量化尺度很敏感。ShuffleNetV2掉点也不小通道混洗操作在量化后信息混淆更严重。这个结果提醒我选模型不能只看论文里的浮点精度量化友好度同样重要。4.2 推理耗时与内存占用耗时数据是在板子上实测的输入224x224batch size为1取100次平均模型FP16耗时(ms)INT8耗时(ms)内存峰值(MB)模型体积(MB)MobileNetV218.69.2423.4MobileNetV3-Small15.37.8382.5ShuffleNetV216.18.5402.8ResNet1842.721.37811.2EfficientNet-B035.417.6655.3INT8相比FP16基本都有两倍左右的加速这个提升幅度符合预期。MobileNetV3-Small是最快的7.8ms意味着理论上能跑到120FPS以上当然实际业务里还要算上预处理和后处理的时间。ResNet18的耗时明显高出一截21.3ms对应大约47FPS。它的参数量和计算量摆在那里NPU算力就这么多快不起来。如果业务对帧率要求高ResNet18基本可以排除。内存占用方面ResNet18的78MB峰值需要留意。如果板子内存紧张或者要同时跑多个模型这个数字可能会成为瓶颈。4.3 综合性价比分析把精度、速度、体积放一起看就能得出一些选型结论追求极致速度MobileNetV3-Small7.8ms的耗时几乎是最优解精度也有90.2%适合对实时性要求苛刻的场景。追求精度与速度平衡MobileNetV29.2ms耗时加90.5%精度量化掉点也控制得不错是最稳妥的选择。精度优先且能接受低帧率ResNet1893.8%的INT8精度是这几个里最高的但21.3ms的耗时需要确认业务能否接受。不建议在RV1126B上部署EfficientNet-B0和ShuffleNetV2前者掉点大且速度不占优后者量化不友好都有更好的替代品。这个结论只针对RV1126B这颗芯片。换一颗NPU算力更强或者量化支持更好的芯片排序可能完全不一样。5. 部署过程中踩过的坑与排查技巧5.1 转换阶段的典型报错报错一Unsupported op type这是最常见的。RKNN工具链不是所有ONNX算子都支持遇到不支持的算子会直接报错。解决办法有两个一是改模型结构把不支持的算子替换成等价的受支持算子二是用工具链提供的自定义算子接口自己实现。我遇到过一次是模型里用了Hardswish工具链不认。后来把Hardswish拆成HardSigmoid加Mul就顺利通过了。虽然推理时会多几个算子但总比跑不起来强。报错二Quantize calibration failed量化校准失败通常是校准集的问题。检查三点图片路径是否正确、图片格式是否支持、预处理参数是否匹配。我有一次是因为校准集里混进了灰度图而模型输入是三通道导致校准过程直接崩掉。报错三Model version mismatch前面提过的工具链版本和Runtime版本不匹配。解决办法就是统一版本转换和推理用同一套SDK。5.2 精度异常的排查思路量化后精度掉得离谱先别急着换模型按这个顺序排查确认预处理一致性训练时的归一化参数、resize方法、通道顺序和转换时填的是否完全一致。这是最高频的原因。检查校准集质量换一批更多样化的校准图重新量化看精度是否回升。逐层对比输出RKNN工具链支持逐层精度分析可以定位到是哪一层开始出现大偏差。通常是某个激活层或者池化层。尝试混合量化把敏感层保持FP16其余层INT8。工具链支持这种混合精度配置能有效缓解掉点。避坑技巧如果时间充裕建议在训练阶段就做量化感知训练QAT让模型提前适应量化误差。我试过对MobileNetV3做QATINT8精度从90.2%提升到92.4%几乎追平了FP16。代价是训练流程复杂一些但对于精度敏感的项目很值得。5.3 运行时性能优化模型转换好了部署到板子上还有优化空间零拷贝输入RKNN Runtime支持直接使用NPU的物理内存做输入避免CPU到NPU的数据拷贝。这个优化能省下1到2ms。多线程推理如果业务允许可以开两个NPU推理线程交替执行提升吞吐量。但要注意内存占用会翻倍。预处理下放把resize和归一化用RGA硬件做比CPU做快很多。RKNN工具链提供了RGA接口值得花时间集成。我实测下来零拷贝加RGA预处理MobileNetV2的端到端耗时从12ms左右降到了9.5ms提升还是挺明显的。6. 常见问题速查表问题现象可能原因解决方向转换报Unsupported op算子不支持替换等价算子或自定义实现量化后精度暴跌预处理不一致/校准集差核对参数更换校准集推理结果全错输出节点解析错误检查输出tensor的shape和顺序运行时报内存不足模型太大/内存泄漏减小模型或检查代码释放逻辑耗时波动大CPU降频/散热问题加散热片锁定CPU频率首次推理特别慢模型加载和预热排除首次数据或提前预热这张表是我自己遇到问题后整理的基本覆盖了八成以上的常见故障。遇到新问题的时候先对照这张表过一遍能省不少排查时间。7. 一些个人体会和后续可扩展的方向跑完这一轮实验我最大的感受是边缘端部署没有银弹选模型本质上是在精度、速度、内存、量化友好度之间做权衡。RV1126B这颗芯片的NPU对标准卷积的支持很好对深度可分离卷积和注意力机制就相对吃力这个特性直接影响了模型选型。如果后续要继续深入我觉得有几个方向值得做一是把检测和分割模型也纳入对比看看分类模型上的结论能否迁移二是尝试INT4量化进一步压缩模型体积和提升速度三是把整个流程脚本化做成一个自动化的模型评估流水线换模型只需要改配置。最后分享一个小技巧在正式部署前先用RKNN Toolkit的模拟器在PC上跑一遍量化模型确认精度和输出都正常再放到板子上。这样能快速排除大部分转换问题不用每次都烧板子调试效率高很多。