RV1126B边缘NPU部署图像分类模型：MobileNet/ResNet/EfficientNet量化实测与选型

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.04，Python环境3.8，PyTorch 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 评估指标怎么定

光看推理耗时是不够的，边缘端部署要综合考虑多个维度。我定了这几个指标：

这里要特别说一下量化掉点这个指标。RV1126B的NPU对INT8量化支持最好，FP16虽然也能跑但算力利用率会打折扣。所以实际部署基本都要走INT8量化，而量化必然带来精度损失，损失多少直接决定了这个模型能不能用。

3. 模型转换与量化实操全流程

3.1 从训练框架到ONNX的导出细节

不管用什么框架训练，第一步都是导出成ONNX。这一步看着简单，但坑不少。以PyTorch为例，导出的时候有几个参数必须注意：

torch.onnx.export( model, dummy_input, "model.onnx", opset_version=11, input_names=["input"], output_names=["output"], dynamic_axes=None # 边缘端固定输入，不要开动态轴 )

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(verbose=True) rknn.config( mean_values=[[123.675, 116.28, 103.53]], std_values=[[58.395, 57.12, 57.375]], target_platform='rv1126b', quantized_dtype='asymmetric_quantized-8', optimization_level=3 ) rknn.load_onnx(model='model_sim.onnx') rknn.build(do_quantization=True, dataset='quant_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各跑一遍：

从掉点幅度能看出一些规律。ResNet18掉点最小，因为它的结构以标准卷积为主，量化友好。MobileNetV3和EfficientNet掉点较大，罪魁祸首是h-swish和SE模块——h-swish在零点附近变化剧烈，INT8的离散化误差被放大；SE模块里的全局池化和通道乘法对量化尺度很敏感。

ShuffleNetV2掉点也不小，通道混洗操作在量化后信息混淆更严重。这个结果提醒我，选模型不能只看论文里的浮点精度，量化友好度同样重要。

4.2 推理耗时与内存占用

耗时数据是在板子上实测的，输入224x224，batch size为1，取100次平均：

INT8相比FP16基本都有两倍左右的加速，这个提升幅度符合预期。MobileNetV3-Small是最快的，7.8ms意味着理论上能跑到120FPS以上，当然实际业务里还要算上预处理和后处理的时间。

ResNet18的耗时明显高出一截，21.3ms对应大约47FPS。它的参数量和计算量摆在那里，NPU算力就这么多，快不起来。如果业务对帧率要求高，ResNet18基本可以排除。

内存占用方面，ResNet18的78MB峰值需要留意。如果板子内存紧张，或者要同时跑多个模型，这个数字可能会成为瓶颈。

4.3 综合性价比分析

把精度、速度、体积放一起看，就能得出一些选型结论：

• 追求极致速度：MobileNetV3-Small，7.8ms的耗时几乎是最优解，精度也有90.2%，适合对实时性要求苛刻的场景。
• 追求精度与速度平衡：MobileNetV2，9.2ms耗时加90.5%精度，量化掉点也控制得不错，是最稳妥的选择。
• 精度优先且能接受低帧率：ResNet18，93.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 精度异常的排查思路

量化后精度掉得离谱，先别急着换模型，按这个顺序排查：

1. 确认预处理一致性：训练时的归一化参数、resize方法、通道顺序，和转换时填的是否完全一致。这是最高频的原因。
2. 检查校准集质量：换一批更多样化的校准图重新量化，看精度是否回升。
3. 逐层对比输出：RKNN工具链支持逐层精度分析，可以定位到是哪一层开始出现大偏差。通常是某个激活层或者池化层。
4. 尝试混合量化：把敏感层保持FP16，其余层INT8。工具链支持这种混合精度配置，能有效缓解掉点。

避坑技巧：如果时间充裕，建议在训练阶段就做量化感知训练（QAT），让模型提前适应量化误差。我试过对MobileNetV3做QAT，INT8精度从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. 常见问题速查表

这张表是我自己遇到问题后整理的，基本覆盖了八成以上的常见故障。遇到新问题的时候，先对照这张表过一遍，能省不少排查时间。

7. 一些个人体会和后续可扩展的方向

跑完这一轮实验，我最大的感受是：边缘端部署没有银弹，选模型本质上是在精度、速度、内存、量化友好度之间做权衡。RV1126B这颗芯片的NPU对标准卷积的支持很好，对深度可分离卷积和注意力机制就相对吃力，这个特性直接影响了模型选型。

如果后续要继续深入，我觉得有几个方向值得做：一是把检测和分割模型也纳入对比，看看分类模型上的结论能否迁移；二是尝试INT4量化，进一步压缩模型体积和提升速度；三是把整个流程脚本化，做成一个自动化的模型评估流水线，换模型只需要改配置。

最后分享一个小技巧：在正式部署前，先用RKNN Toolkit的模拟器在PC上跑一遍量化模型，确认精度和输出都正常，再放到板子上。这样能快速排除大部分转换问题，不用每次都烧板子调试，效率高很多。