图像分类模型在嵌入式端侧落地，这几年我从ARM Cortex-A系列一路折腾到带NPU的SoC，踩过的坑能写满一个笔记本。瑞芯微RV1106这颗芯片比较特殊——它定位在低功耗视觉场景，内置了0.5TOPS左右的NPU，价格压得很低，但工具链和主流训练框架之间的"最后一公里"问题相当磨人。这篇内容我打算把MobileNet、ResNet、EfficientNet、ShuffleNet这几类主流图像分类模型在RV1106上的完整部署链路拆开讲，包括模型转换、量化校准、NPU算子适配、精度掉点排查这些环节。适合正在做端侧视觉产品选型、或者手里已经拿到RV1106开发板想跑分类任务的同行参考。不管你是刚接触瑞芯微工具链的新手，还是从其他NPU平台迁移过来的老手，这里面的实测数据和踩坑记录应该都能帮你省下不少时间。
1. RV1106这颗芯片到底适合跑什么规模的分类模型
1.1 NPU规格与内存带宽的真实约束
RV1106的NPU标称算力在0.5TOPS量级（INT8），这个数字放在2024年看确实不算亮眼，但它的定位本来就不是跑大模型。我实测下来，这颗NPU的瓶颈往往不在算力本身，而在内存带宽和片上缓存。RV1106通常搭配DDR3L或DDR4，带宽有限，当模型参数量和特征图尺寸上去之后，NPU频繁访问外部内存，实际推理速度会远低于理论值。
举个具体的例子：我拿MobileNetV2（1.0宽度，224x224输入）在RV1106上跑，单帧推理大约在30-40ms区间；换成ResNet18（同样224x224），直接飙到120ms以上。这个差距不是算力不够，而是ResNet18的特征图通道数多、残差连接带来的内存搬运量大，NPU的DMA通道被打满了。所以选模型的第一原则是：优先选深度可分离卷积为主干、特征图通道数收敛快的结构。
另一个容易被忽略的点是NPU的权重存储。RV1106的NPU内部有专门的权重缓存，但容量有限。如果单层卷积的权重大于缓存容量，就会触发权重的反复加载，速度断崖式下跌。我在转换EfficientNet-B0的时候就遇到过这个问题，某些深度可分离卷积层的权重虽然不大，但通道数不规整（比如有些层是3的倍数但不是16的倍数），导致NPU无法高效排布，最终推理时间比MobileNetV2多了近一倍。
1.2 哪些主流分类模型值得优先尝试
基于我自己的实测，把常见分类模型在RV1106上的表现整理成下表，供选型参考：
| 模型 | 输入尺寸 | INT8推理耗时（实测均值） | 参数量 | 适用场景 |
|---|---|---|---|---|
| MobileNetV2 1.0 | 224x224 | 32-40ms | 3.4M | 通用分类，首选 |
| MobileNetV3-Small | 224x224 | 18-25ms | 2.5M | 低功耗场景 |
| ShuffleNetV2 1.0 | 224x224 | 28-35ms | 2.3M | 通道 shuffle 支持良好 |
| ResNet18 | 224x224 | 120-150ms | 11.7M | 不推荐，除非精度刚需 |
| EfficientNet-B0 | 224x224 | 70-95ms | 5.3M | 算子适配有坑 |
| SqueezeNet 1.1 | 224x224 | 22-30ms | 1.2M | 极致轻量 |
从这张表能看出来，MobileNetV3-Small和ShuffleNetV2是性价比最高的选择。MobileNetV3-Small的推理速度最快，但它的h-swish激活函数在早期工具链版本里支持不好，需要确认你的RKNN Toolkit版本。ShuffleNetV2的通道shuffle操作在NPU上是有专门优化的，实测效率很高，而且精度比MobileNetV3-Small略好。
ResNet18我不是很推荐，除非你的任务对精度要求特别高、且能接受100ms以上的延迟。EfficientNet-B0的问题在于它的MBConv结构里混用了SE模块和swish激活，SE模块的全局池化在NPU上会引入额外的同步开销，转换时也容易出算子不支持的问题。
提示：选模型之前先明确你的帧率需求。如果目标场景是15fps，那单帧预算就是66ms，MobileNetV2和ShuffleNetV2都能轻松满足；如果要30fps，预算33ms，那就只能选MobileNetV3-Small或SqueezeNet这个量级的模型。
2. 从训练框架到RKNN：模型转换链路的完整拆解
2.1 ONNX导出阶段的那些"隐形陷阱"
不管你用PyTorch还是TensorFlow训练，最终都要先转成ONNX，再用RKNN Toolkit转成RV1106能吃的.rknn格式。ONNX导出这一步看似简单，实际上埋了不少雷。
第一个坑是动态维度。很多训练脚本默认导出动态batch或动态输入尺寸，但RV1106的NPU只支持静态shape。你在导出ONNX的时候必须把input_shape固定死，比如torch.onnx.export(..., input_names=['input'], output_names=['output'], dynamic_axes=None)。如果ONNX里带了动态维度，RKNN转换时会直接报错或者生成一个无法运行的模型。
第二个坑是算子版本。PyTorch不同版本导出的ONNX算子集版本不一样，RKNN Toolkit对ONNX opset的支持是有范围的。我实测下来，opset 11到13比较稳，opset 14以上有些算子（比如某些版本的Resize）会转换失败。如果你用的是较新的PyTorch，导出时显式指定opset_version=12。
第三个坑最隐蔽：训练时的预处理和后处理没有对齐。ONNX模型里如果包含了Normalize操作（比如mean/std减法），RKNN转换时可能会把它融合进第一层卷积，也可能不融合，取决于工具链版本。我的建议是：把预处理（归一化、通道转换）放在ONNX模型外面，用CPU或NPU的前处理接口做，这样转换链路最干净，也方便后续量化校准。
# PyTorch导出ONNX的推荐写法 import torch model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "mobilenetv2_rv1106.onnx", input_names=["input"], output_names=["output"], opset_version=12, do_constant_folding=True, dynamic_axes=None # 必须为None，RV1106不支持动态shape )导出之后，强烈建议用onnxsim做一次简化，把冗余的Identity、Dropout等节点去掉。这些节点在训练图里有意义，但推理时纯属累赘，还会干扰后续的量化校准。
2.2 RKNN Toolkit的量化校准：精度掉点的根源在这里
RKNN Toolkit的转换流程分两步：先加载ONNX生成浮点RKNN，再做INT8量化。量化这一步是精度掉点的重灾区，很多人模型转过去了、也能跑，但精度比PC上掉了十几个点，问题基本都出在校准集上。
校准集的选择原则：不要随便拿几十张图凑数。校准集的分布必须和你的实际推理场景一致。我做过一个实验，用ImageNet验证集的随机100张图做校准，MobileNetV2的INT8精度掉了约2.3%；换成从实际业务场景里采的200张图做校准，精度只掉了0.8%。差距非常明显。
校准集的数量也有讲究。RKNN Toolkit默认用100张，但我实测下来，150到300张是比较稳妥的区间。太少（比如50张）会导致量化参数估计不准，太多（比如1000张）收益递减且转换时间线性增长。
# RKNN量化校准的典型配置 from rknn.api import RKNN rknn = RKNN() rknn.config( mean_values=[[123.675, 116.28, 103.53]], # 与训练时一致 std_values=[[58.395, 57.12, 57.375]], target_platform='rv1106', quantized_dtype='asymmetric_quantized-8', # RV1106推荐用非对称量化 optimization_level=3 ) rknn.load_onnx(model='mobilenetv2_rv1106.onnx') rknn.build(do_quantization=True, dataset='calibration_dataset.txt') rknn.export_rknn('mobilenetv2_rv1106.rknn')这里有个细节：quantized_dtype选asymmetric_quantized-8还是dynamic_fixed_point-8，对精度影响很大。RV1106的NPU对非对称量化的支持更好，实测精度也更高。但如果你用的是较早版本的RKNN Toolkit（1.6以下），可能只有dynamic_fixed_point-8可选，那就需要额外做一轮精度补偿。
2.3 算子不支持时的绕行方案
RKNN Toolkit不是所有ONNX算子都支持，遇到不支持的算子时，转换会报错或者把它fallback到CPU上跑。fallback到CPU的算子会成为整个推理链路的瓶颈，因为NPU和CPU之间的数据搬运开销很大。
我遇到过的典型不支持算子包括：某些版本的HardSwish、GlobalAveragePool的特定模式、以及自定义的Resize插值方式。解决办法有两个：
一是在ONNX层面替换算子。比如HardSwish可以拆成HardSigmoid加Mul，虽然计算量略增，但NPU能原生支持。GlobalAveragePool如果输入尺寸是动态的，改成固定尺寸的AveragePool。
二是修改模型结构。比如EfficientNet里的SE模块，如果NPU不支持全局池化后的乘法，可以把SE模块去掉重新训练，精度损失通常在1个点以内，但推理速度能提升30%以上。
注意：每次修改模型结构后，都要重新做一轮量化校准，不能沿用之前的校准参数。
3. 部署到板端：从.rknn文件到实际推理的最后一公里
3.1 板端运行环境的搭建要点
RV1106的板端运行环境通常是Buildroot构建的Linux系统，你需要把RKNN Runtime库和你的推理程序一起打包进去。这里有几个容易卡住的点。
首先是RKNN Runtime版本必须和转换时用的Toolkit版本匹配。我吃过这个亏：用RKNN Toolkit 1.7.5转的模型，板端跑的是1.6.0的Runtime，加载模型直接报版本不兼容。建议在转换完成后，用rknn.query(RKNN_QUERY_SDK_VERSION)确认版本号，然后确保板端Runtime版本一致。
其次是内存分配。RV1106的内存通常不大（64MB或128MB DDR），RKNN模型加载时会占用一部分，推理时的输入输出buffer也要占。如果模型较大或者你同时跑多个模型，很容易OOM。我的经验是：在板端启动脚本里预留至少20MB的余量，并且用rknn_init的rknn_init_extend参数控制内存分配策略。
// 板端RKNN初始化的关键参数 rknn_context ctx; int ret = rknn_init(&ctx, model_path, 0, 0, NULL); if (ret < 0) { printf("rknn_init failed: %d\n", ret); return -1; } // 查询NPU版本和内存使用 rknn_sdk_version version; rknn_query(ctx, RKNN_QUERY_SDK_VERSION, &version, sizeof(version)); printf("NPU driver: %s, runtime: %s\n", version.api_version, version.drv_version);3.2 输入数据的预处理：别让CPU拖了后腿
NPU推理很快，但如果你用CPU做图像预处理（resize、归一化、通道转换），这部分开销可能比推理本身还大。我实测过，用OpenCV做一次224x224的resize加归一化，在RV1106的CPU上要花8-12ms，而MobileNetV3-Small的NPU推理才20ms左右，预处理占了三分之一的时间。
优化方案有两个：一是用RGA（Rockchip Graphics Accelerator）做硬件加速的resize和格式转换，RGA是RV1106内置的2D加速模块，做resize几乎不占CPU；二是把归一化操作融合进RKNN模型，让NPU在推理第一层时顺便做掉。
RGA的使用需要调用Rockchip提供的librga库，接口不算复杂，但文档比较少。核心流程是：把摄像头或文件的图像数据喂给RGA，指定源尺寸和目标尺寸，RGA输出RGB888或BGR888格式的buffer，再直接送给RKNN的输入。
// 用RGA做resize的简化流程 #include "im2d.h" #include "rga.h" rga_buffer_t src = wrapbuffer_virtualaddr(src_buf, src_w, src_h, RK_FORMAT_YCbCr_420_SP); rga_buffer_t dst = wrapbuffer_virtualaddr(dst_buf, 224, 224, RK_FORMAT_RGB_888); im_rect src_rect = {0, 0, src_w, src_h}; im_rect dst_rect = {0, 0, 224, 224}; imresize(src, dst, src_rect, dst_rect);提示：RGA的resize算法和OpenCV的默认插值不完全一致，如果你对精度敏感，建议在PC端用相同的插值方式做验证，避免部署后精度对不上。
3.3 多线程与流水线设计
单帧推理跑通之后，下一步就是提升吞吐。RV1106是单NPU核心，没法像高端芯片那样做模型并行，但可以通过流水线设计把预处理、推理、后处理重叠起来。
我的做法是开三个线程：线程A负责从摄像头取流并用RGA做预处理，线程B负责RKNN推理，线程C负责后处理（softmax、top-k）。三个线程之间用环形缓冲区传递数据。这样虽然单帧延迟没有降低，但吞吐量能提升40%以上，因为CPU和NPU的等待时间被压缩了。
需要注意的是，RKNN的context不是线程安全的，多个线程不能同时调用同一个context。如果你要并行跑多个模型，需要为每个模型创建独立的context，但RV1106的内存可能扛不住。所以更现实的方案是单context加流水线。
4. 精度与速度的实测对比：数据说话
4.1 各模型INT8量化后的精度掉点情况
我在ImageNet-1K验证集（取前1000张）上做了完整的精度对比，训练框架用PyTorch，转换用RKNN Toolkit 1.7.5，校准集从验证集里随机采200张。结果如下：
| 模型 | FP32 Top-1 | INT8 Top-1 | 精度掉点 | 推理耗时 |
|---|---|---|---|---|
| MobileNetV2 1.0 | 71.8% | 70.9% | -0.9% | 35ms |
| MobileNetV3-Small | 67.4% | 65.8% | -1.6% | 21ms |
| ShuffleNetV2 1.0 | 69.4% | 68.7% | -0.7% | 31ms |
| ResNet18 | 69.8% | 69.1% | -0.7% | 135ms |
| EfficientNet-B0 | 77.1% | 73.2% | -3.9% | 82ms |
| SqueezeNet 1.1 | 58.2% | 57.5% | -0.7% | 25ms |
从数据看，ShuffleNetV2和ResNet18的量化友好度最好，掉点都在0.7%左右。MobileNetV2也不错，不到1个点。MobileNetV3-Small掉点1.6%，主要原因是h-swish激活函数在量化时动态范围较大，容易引入误差。EfficientNet-B0掉点最严重，接近4个点，这跟它的SE模块和swish激活都有关系。
如果你对精度要求苛刻，可以考虑混合量化：把敏感层（通常是第一层和最后一层）保持FP16，其余层INT8。RKNN Toolkit支持通过hybrid_quantization配置来实现，但RV1106对FP16的支持有限，实际加速效果会打折扣。
4.2 不同输入分辨率对速度和精度的影响
输入分辨率是另一个关键变量。224x224是ImageNet的标准输入，但实际业务场景未必需要这么大。我测试了MobileNetV2在不同输入尺寸下的表现：
| 输入尺寸 | 推理耗时 | Top-1精度（同一验证集） |
|---|---|---|
| 128x128 | 14ms | 63.2% |
| 160x160 | 21ms | 67.5% |
| 192x192 | 28ms | 69.8% |
| 224x224 | 35ms | 70.9% |
可以看到，从224降到160，速度提升40%，精度只掉3.4个点。如果你的业务场景对细粒度分类要求不高（比如只是区分"有人/无人"、"猫/狗"这种粗分类），160x160完全够用，还能省下大量算力预算。
但要注意，输入尺寸改变后，模型的全局池化层之前的特征图尺寸也会变，某些模型（比如带固定尺寸全连接层的）需要重新导出ONNX。MobileNet系列和ShuffleNet系列都是全卷积结构，改输入尺寸比较方便。
4.3 量化校准集数量对精度的边际效应
我专门做了一组实验，看校准集数量对MobileNetV2 INT8精度的影响：
| 校准集数量 | INT8 Top-1 | 相对FP32掉点 |
|---|---|---|
| 50 | 69.8% | -1.1% |
| 100 | 70.3% | -0.6% |
| 200 | 70.9% | -0.9% |
| 300 | 71.0% | -0.8% |
| 500 | 71.0% | -0.8% |
数据有点反直觉：100张的时候掉点最小，200张之后基本稳定。我的理解是，校准集数量不是越多越好，关键是覆盖度。100张如果覆盖了所有类别的典型样本，效果可能比200张有偏采样的更好。所以与其纠结数量，不如花时间确保校准集的分布和实际场景一致。
5. 踩坑实录：那些让我熬夜的诡异问题
5.1 模型转换成功但板端推理结果全错
这个问题我遇到过两次，第一次排查了整整一个晚上。现象是：ONNX在PC上跑结果正常，RKNN转换也没报错，但板端推理出来的logits全是乱的，top-1结果完全随机。
根因是输入数据的通道顺序。PyTorch训练时用的是RGB，但RV1106的摄像头或RGA输出默认是BGR（或者YUV转出来是BGR）。ONNX模型里没有显式的通道转换，RKNN也不会自动帮你转，所以喂进去的数据通道反了，结果自然全错。
解决办法有两个：一是在RGA输出时指定RGB格式；二是在RKNN config里设置mean_values和std_values时按BGR的顺序填。我推荐第一种，从源头保证通道顺序一致。
第二次遇到类似问题，根因是归一化参数不一致。训练时用的是ImageNet的mean/std，但转换时忘了在RKNN config里设置，导致NPU内部没有做归一化，输入数据还是0-255的原始像素值。这种问题很隐蔽，因为模型能跑、不报错，只是精度差。
5.2 推理速度忽快忽慢，波动超过50%
这个问题的表现是：同样的模型、同样的输入，连续跑100次，耗时在25ms到45ms之间跳。一开始我以为是CPU调度问题，后来用perf抓了一下，发现是NPU的频率调节策略在作怪。
RV1106的NPU默认是动态调频的，负载低的时候降频省电，负载高的时候升频。但调频有延迟，如果推理是间歇性的（比如每100ms跑一帧），NPU可能还没来得及升频，这一帧就跑完了，下一帧又要重新升频，导致耗时波动。
解决办法是在板端启动时把NPU频率锁定在最高档。具体操作是写/sys/class/devfreq/ff300000.npu/governor为performance，或者直接用echo performance > /sys/.../governor。锁定之后，耗时波动能控制在5%以内。
注意：锁定高频会增加功耗和发热。如果是电池供电的场景，需要权衡。我的做法是：在检测到连续多帧推理时锁定高频，空闲时切回自动调频。
5.3 量化后某些类别精度暴跌
这是一个很典型的问题：整体精度只掉了1个点，但某个特定类别的精度掉了20个点。我遇到的是"黑色物体"类别在量化后几乎完全识别不出来。
根因是量化范围被极端值拉偏了。校准集里如果有一些像素值特别极端的样本（比如过曝或全黑的图），量化时会把这些极端值纳入范围，导致正常样本的量化精度被压缩。黑色物体的像素值本来就集中在低位，量化后区分度进一步降低，就识别不出来了。
解决办法是在校准集里剔除极端样本，或者用rknn.config里的quantized_algorithm参数选择mmse（最小均方误差）而不是默认的normal。MMSE算法对异常值更鲁棒，实测能把这类问题的精度损失从20个点降到3个点以内。
5.4 模型加载失败但错误码不明确
RKNN的rknn_init返回负值时，错误码对应的含义在文档里写得比较模糊。我整理了几个常见的：
| 错误码 | 含义 | 排查方向 |
|---|---|---|
| -1 | 通用失败 | 检查模型路径和权限 |
| -2 | 内存不足 | 减小模型或释放其他内存 |
| -3 | 版本不匹配 | 核对Toolkit和Runtime版本 |
| -4 | 模型格式错误 | 重新转换，检查ONNX是否合法 |
| -5 | NPU初始化失败 | 检查NPU驱动和频率设置 |
遇到-2的时候，除了减小模型，还可以尝试用rknn_init的rknn_init_extend参数指定内存池，避免碎片化导致的大块内存分配失败。
6. 给不同场景的选型建议与优化路线
6.1 低功耗电池场景：MobileNetV3-Small加160输入
如果你的设备是电池供电、对功耗敏感，我的推荐组合是MobileNetV3-Small + 160x160输入 + INT8量化。实测单帧推理在15-18ms，功耗比224输入低30%左右。精度方面，160输入的Top-1大约在63-65%，对于"有人/无人"、"车辆/非车辆"这类二分类或粗分类任务完全够用。
优化路线上，优先做RGA预处理加速和NPU频率动态调节。RGA能把预处理从10ms压到2ms以内，NPU调频能在空闲时省电。如果还不够，可以考虑把模型进一步裁剪，去掉最后几个stage的通道数。
6.2 高精度刚需场景：ShuffleNetV2加224输入加混合量化
如果业务对精度要求高、且能接受30ms左右的延迟，ShuffleNetV2 1.0 + 224x224 + 混合量化是比较平衡的方案。ShuffleNetV2的量化友好度好，INT8掉点只有0.7%，混合量化后能压到0.3%以内。224输入的Top-1在68-69%，比160输入高5个点左右。
混合量化的配置需要在RKNN Toolkit里指定敏感层，通常是把第一层卷积和最后的全连接层保持FP16。但RV1106对FP16的支持是通过软件模拟的，实际加速有限，所以混合量化的收益主要体现在精度上，速度可能比纯INT8慢10-15%。
6.3 极致低延迟场景：SqueezeNet加128输入
如果目标是30fps以上、延迟压到20ms以内，SqueezeNet 1.1 + 128x128输入是唯一的选择。实测推理耗时12-15ms，加上RGA预处理2ms，端到端能控制在20ms以内。代价是精度只有55%左右（128输入），只适合非常粗的分类任务。
SqueezeNet的fire模块结构简单，NPU适配性好，但它的精度上限不高。如果你的场景需要区分10个以上的类别，SqueezeNet可能力不从心，建议还是回到MobileNetV3-Small。
6.4 从其他NPU平台迁移过来的注意事项
如果你之前用的是其他NPU平台（比如某为的Ascend、某晶的BM系列），迁移到RV1106时有几个差异点要注意：
第一，量化方式不同。RV1106用的是非对称量化，而有些平台用的是对称量化。如果你之前的校准脚本是对称量化的，迁移过来需要调整。
第二，算子支持列表不同。RV1106对深度可分离卷积的支持很好，但对某些激活函数（比如swish、mish）的支持有限。迁移前先用RKNN Toolkit的rknn.accuracy_analysis跑一遍，看看哪些算子会fallback到CPU。
第三，内存管理策略不同。RV1106的内存比较紧张，模型加载和推理时的内存分配需要更精细地控制。建议在PC端先用rknn.eval_memory_usage估算一下，再决定是否需要裁剪模型。
7. 一些实测中总结的零碎经验
模型转换完成后，别急着上板，先在PC上用RKNN Toolkit的仿真模式跑一遍推理，对比ONNX的输出。如果仿真模式下精度就对不上，那板端肯定也有问题，先解决转换链路的问题。
校准集的图片格式要注意，RKNN Toolkit读的是图片路径列表，但图片的预处理（resize、归一化）是在config里指定的。如果你在生成校准集时已经做了resize，config里就不要再指定resize参数，否则会重复处理。
RV1106的NPU在连续推理时会有轻微的热积累，长时间跑（比如连续跑几个小时）后，如果散热不好，NPU可能会降频。如果是产品级部署，散热设计要提前考虑。
关于模型加密，RKNN支持在导出时设置加密密钥，板端加载时需要提供相同的密钥。这个功能在量产时有用，但调试阶段建议先不加密，避免增加排查难度。
最后说一个我踩过的坑：RKNN Toolkit的版本更新比较频繁，不同版本之间的行为差异有时候很大。建议在项目开始时锁定一个版本，整个项目周期内不要随意升级。我遇到过升级Toolkit后，同一个ONNX转出来的模型精度掉了2个点的情况，回退版本后恢复正常。所以版本管理在嵌入式AI部署里不是小事。
