RV1103边缘图像分类模型部署实战：从PyTorch到RKNN的量化与性能对比

1. 为什么要在 RV1103 上折腾图像分类模型

瑞芯微 RV1103 这颗芯片在边缘视觉圈子里热度一直不低，它把 CPU、NPU、ISP 和视频编解码集成在一颗 QFN 封装里，典型功耗控制在 1W 上下，价格又压得很低，非常适合做电池供电的智能门铃、猫眼、玩具相机、工业扫码头这类产品。这颗芯片的 NPU 算力标称 0.5TOPS（INT8），听起来不大，但跑一个轻量图像分类网络做“有人/没人”“猫/狗”“合格/不合格”这种二分类或小类别判断，是完全够用的。

问题在于，很多人拿到 RV1103 开发板之后，卡在“模型怎么从 PyTorch 变成板子上能跑的 .rknn 文件”这一步。官方文档给的是流程骨架，但真正落到某个具体模型上，量化精度掉多少、输入分辨率怎么选、NPU 算子支持不支持、后处理放 CPU 还是 NPU，这些细节文档里基本不会写。我前后在 RV1103 上部署过 MobileNetV2、ResNet18、EfficientNet-Lite、ShuffleNetV2、SqueezeNet 这几类主流分类模型，踩了不少坑，也积累了一些实测数据，这里系统性地整理一遍。

这篇文章适合三类人看：一是刚拿到 RV1103 开发板、想跑通第一个分类模型的嵌入式工程师；二是正在做边缘视觉产品选型、需要评估“哪个模型在这颗芯片上性价比最高”的方案设计者；三是对 NPU 部署流程感兴趣、想了解 RKNN 工具链实际表现的算法同学。我会把模型选型、量化校准、算子兼容、实测帧率和精度对比这些环节都讲透，给出可以直接抄作业的命令和配置。

需要提前说明的是，RV1103 的 NPU 是瑞芯微自研的，和 RK3588、RK3568 上的 NPU 架构不完全一样，工具链版本也有差异。我用的环境是 RKNN-Toolkit2 1.6.0 配合 RV1103 的 1.6.0 版本 runtime，如果你用的是更新的版本，部分 API 可能有变化，但整体思路是通用的。

2. 部署前的整体思路与方案选型

2.1 先想清楚“分类”在边缘端到底要解决什么问题

在服务器上做图像分类，大家习惯性追求 Top-1 精度，ImageNet 上刷到 80% 以上才觉得能用。但在 RV1103 这种边缘芯片上，逻辑完全不一样。边缘分类任务通常是“闭集小类别”问题：比如门铃只需要判断“人形/非人形”，工业质检只需要判断“良品/次品”，宠物喂食器只需要判断“猫/狗/其他”。类别数往往在 2 到 20 之间，而且场景相对固定，光照、角度、背景的变化范围可控。

这意味着两件事。第一，你不需要一个在 ImageNet 1000 类上表现很好的大模型，一个在你自己数据集上微调过的小模型，精度可能比通用大模型还高。第二，量化带来的精度损失，在小类别闭集任务上通常比在 1000 类开放集上要小得多，因为类别之间的决策边界更宽。我实测下来，MobileNetV2 在 ImageNet 上 INT8 量化后 Top-1 掉 1.5% 左右，但在一个 5 类工业质检数据集上，量化前后准确率几乎没变化。

所以选型的第一原则是：先明确你的类别数和场景复杂度，再倒推需要的模型容量，而不是一上来就挑最准的模型。

2.2 模型选型的三个硬约束

在 RV1103 上选分类模型，有三个硬约束绕不开。

第一个是内存。RV1103 内置的 DDR 容量有限（常见配置是 64MB 或 128MB SIP DDR），模型权重、中间特征图、输入输出 buffer 都要从这里面出。一个 ResNet50 的 INT8 权重大概 25MB，加上中间激活，很容易把内存吃满。所以实际能用的模型，参数量最好控制在 5M 以内，权重文件控制在 10MB 以内。

第二个是算子支持。RKNN 工具链对常见卷积、深度可分离卷积、全连接、池化、BN、ReLU 支持很好，但一些“花哨”的结构，比如某些注意力机制、动态卷积、非标准的上采样方式，可能会 fallback 到 CPU，速度直接掉一个数量级。选模型时要优先选结构规整的。

第三个是输入分辨率。RV1103 的 ISP 支持的最大输入分辨率不低，但 NPU 跑分类时，输入越大，特征图越大，内存和算力消耗都上去。224x224 是分类模型的标准输入，但在 RV1103 上，我建议优先考虑 160x160 或 128x128，尤其是当你的目标物体在画面中占比比较大的时候。

2.3 我实际对比的五个模型

基于上面三个约束，我选了五个模型做对比实验，覆盖了从“极小”到“中等”的容量区间：

选这五个的原因是：SqueezeNet 和 ShuffleNetV2 代表“极限轻量”路线，MobileNetV2 是边缘部署的事实标准，EfficientNet-Lite 代表“用更少参数换更高精度”的新思路，ResNet18 则是结构最规整、算子兼容性最好的对照组。这样对比下来，能比较清楚地看出“参数量、精度、速度、内存”四者之间的权衡关系。

3. 从 PyTorch 到 RKNN 的完整实操链路

3.1 环境搭建与工具链版本对齐

RKNN 部署最容易被忽视、也最容易出问题的环节，就是工具链版本和板端 runtime 版本必须对齐。RKNN-Toolkit2 负责在 PC 上把模型转成 .rknn，板端的 librknnrt.so 负责加载执行。如果两者版本差太多，会出现“PC 上转换成功、板子上加载失败”的情况，报错信息还特别含糊。

我的环境配置是这样的：

# PC端（Ubuntu 20.04，Python 3.8） pip install rknn-toolkit2==1.6.0 # 板端确认runtime版本 cat /usr/lib/librknnrt.so | strings | grep -i "librknnrt version"

板端 runtime 版本要和 toolkit 的版本号一致。RV1103 的固件里通常自带 runtime，如果你是自己编译的固件，记得把对应版本的 librknnrt.so 打包进去。这一步没对齐，后面全是白费功夫。

提示：RV1103 和 RV1106 的工具链在 1.6.0 版本是共用的，但生成的 .rknn 文件不通用，因为 NPU 配置不同。转换时 target_platform 一定要写对，RV1103 写rv1103，RV1106 写rv1106。

3.2 模型导出为 ONNX 的关键细节

RKNN-Toolkit2 支持从 PyTorch、ONNX、TensorFlow 等多种格式导入，但我强烈建议统一走 ONNX 这条路。原因是 ONNX 是中间格式，出了问题容易定位，而且 PyTorch 直接导入有时候会因为算子版本问题报奇怪的错。

从 PyTorch 导出 ONNX 时，有几个坑要注意：

import torch import torchvision.models as models model = models.mobilenet_v2(pretrained=True) model.eval() # 关键：输入用固定尺寸，不要用动态轴 dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "mobilenetv2.onnx", opset_version=11, # 建议11或12，太高RKNN可能不支持 input_names=["input"], output_names=["output"], do_constant_folding=True, # 常量折叠，减小模型体积 )

第一个坑是opset_version。RKNN-Toolkit2 1.6.0 对 opset 11 和 12 支持最好，opset 13 以上有些算子会解析失败。第二个坑是动态轴。分类模型输入尺寸固定，导出时不要设置 dynamic_axes，否则 RKNN 转换时可能推断不出 shape。第三个坑是输出节点。有些模型导出后会带额外的后处理节点（比如 softmax），如果 RKNN 里还要再做量化，最好把 softmax 去掉，让 NPU 只输出 logits，softmax 放到 CPU 做，这样量化误差更小。

3.3 RKNN 转换脚本与量化校准

转换脚本是整个流程的核心，我以 MobileNetV2 为例，把关键参数都标注出来：

from rknn.api import RKNN rknn = RKNN(verbose=True) # 配置：均值方差要和训练时一致 rknn.config( mean_values=[[123.675, 116.28, 103.53]], # ImageNet标准均值 std_values=[[58.395, 57.12, 57.375]], # ImageNet标准方差 target_platform='rv1103', quantized_dtype='asymmetric_quantized-8', # RV1103用非对称量化 quantized_algorithm='normal', # 普通量化算法 optimization_level=3, # 最高优化等级 ) # 加载ONNX ret = rknn.load_onnx(model='mobilenetv2.onnx') if ret != 0: print('Load ONNX failed') exit(ret) # 构建：指定量化校准数据集 ret = rknn.build( do_quantization=True, dataset='calibration_dataset.txt', # 校准图片列表 rknn_batch_size=1, ) if ret != 0: print('Build failed') exit(ret) # 导出 ret = rknn.export_rknn('mobilenetv2_rv1103.rknn') rknn.release()

这里最关键的参数是quantized_dtype。RV1103 的 NPU 支持非对称量化（asymmetric_quantized-8），相比对称量化，非对称量化对激活值分布偏斜的模型更友好，精度损失更小。但要注意，不是所有算子都支持非对称量化，个别算子会强制走对称量化。

校准数据集是量化精度的命门。官方文档说“准备 100 到 200 张图片”，但没说清楚这些图片该怎么选。我的经验是：校准图片必须来自真实部署场景，而且要覆盖各种光照、角度、目标大小。如果你用 ImageNet 的随机图片去校准一个工业质检模型，量化后的精度会惨不忍睹。我一般准备 200 张左右，其中 80% 是正常样本，20% 是边界样本（比如光照很暗、目标很小的情况）。

校准图片的预处理也要和推理时完全一致。如果推理时是 resize 到 224x224 再归一化，校准图片也要走同样的流程，并且保存成 RKNN 能读的格式（通常是 jpg 或 png，放在一个 txt 列表里，每行一个路径）。

3.4 板端推理代码与性能测量

板端推理用 Python 和 C 都可以，Python 方便调试，C 方便测真实性能。我先用 Python 验证功能，再用 C 测性能。

Python 推理的核心代码：

from rknnlite.api import RKNNLite import numpy as np import cv2 rknn_lite = RKNNLite() ret = rknn_lite.load_rknn('mobilenetv2_rv1103.rknn') ret = rknn_lite.init_runtime(core_mask=RKNNLite.NPU_CORE_0) img = cv2.imread('test.jpg') img = cv2.resize(img, (224, 224)) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img = img.astype(np.float32) # 注意：RKNN的归一化在config里配了，这里不要再除255 outputs = rknn_lite.inference(inputs=[img])

这里有个容易搞混的点：归一化到底在哪做。如果你在 rknn.config 里配了 mean_values 和 std_values，那么输入给 inference 的就是原始像素值（0-255），RKNN 内部会做减均值除方差。如果你没配，那就要自己在外面归一化。两种方式都行，但一定要统一，否则精度会莫名其妙地掉。

性能测量我用 C 版本的 rknn_api，重点测三个指标：单帧推理耗时（用 clock_gettime 测）、内存占用（读 /proc/self/status 的 VmRSS）、CPU 占用（读 /proc/stat）。每个模型跑 1000 次取平均，前 100 次作为 warmup 不计入。

4. 五个模型的实测数据与深度对比

4.1 推理速度对比：谁才是 RV1103 上的速度王者

先看最直观的推理耗时数据。测试条件统一为：输入 224x224，INT8 量化，NPU 单核，室温 25 度，板子不加散热片。

这个结果和参数量基本成正比，但有几个细节值得说。SqueezeNet 虽然参数量最小，但它的 Fire 模块里有大量 1x1 卷积和 concat 操作，concat 在 NPU 上需要额外的内存搬运，所以它的速度优势没有参数量差距那么大。ShuffleNetV2 的通道混洗操作在 NPU 上有专门优化，速度表现比预期好。

MobileNetV2 的 32.7ms 是一个很有意思的节点。30 FPS 刚好是很多实时应用的门槛，如果你要做 30 帧的实时分类，MobileNetV2 是能用的上限。再往上 EfficientNet-Lite0 就掉到 24 FPS 了，做实时会有点勉强。

ResNet18 的 78.6ms 基本宣告了它在 RV1103 上不适合做实时任务，但如果是“每秒分析一帧”这种低频场景，它还是能用的。

注意：这个数据是在 NPU 单核下测的。RV1103 的 NPU 只有一个核心，不像 RK3588 有三核可以轮流跑。所以不要指望通过多核调度来提速。

4.2 精度对比：量化到底掉了多少

精度测试我用了两个数据集：一个是 ImageNet 验证集的 5000 张子集，一个是自建的 5 类工业质检数据集（每类 200 张测试图）。前者代表通用场景，后者代表实际落地场景。

几个结论很清晰。第一，量化掉点在通用数据集上普遍在 1.3% 到 2.1% 之间，这个幅度是可以接受的。第二，在闭集小类别任务上，量化掉点大幅缩小到 0.3% 到 0.7%，这验证了我前面的判断——边缘分类任务对量化更友好。第三，ResNet18 的量化掉点最小，因为它的结构最规整，没有深度可分离卷积那种对量化敏感的算子。

EfficientNet-Lite0 在 ImageNet 上精度最高（73.2% INT8），但它的速度只有 24 FPS。MobileNetV2 精度 70.3%，速度 30 FPS，是精度和速度平衡得最好的。如果你的场景对精度要求极高、对帧率要求不高，EfficientNet-Lite0 是更好的选择。

4.3 内存占用：64MB DDR 下的生存法则

内存是 RV1103 上最紧张的资源。我测了每个模型在推理时的峰值内存占用（包括模型权重、中间激活、输入输出 buffer）：

ResNet18 的 38.6MB 峰值内存，在 64MB DDR 的板子上已经占了 60%，如果系统还要跑 ISP、视频编码、网络协议栈，很容易 OOM。所以如果你的板子是 64MB DDR 版本，ResNet18 基本可以排除。128MB 版本的话，五个模型都能跑。

这里有个优化技巧：RKNN 支持内存复用，在 build 的时候设置optimization_level=3会开启内存复用优化，把不同层的中间 buffer 复用同一块内存。我实测下来，开启后 MobileNetV2 的峰值内存从 18MB 降到了 14.8MB，效果明显。

4.4 算子兼容性：哪些模型会偷偷 fallback 到 CPU

算子兼容性是文档里最不会写、但实际最影响性能的部分。RKNN 在 build 的时候会打印每个算子的分配情况，如果某个算子不支持 NPU，会 fallback 到 CPU。我统计了五个模型在 RV1103 上的算子分配：

EfficientNet-Lite0 有少量 Resize 算子 fallback 到 CPU，这是它速度偏慢的一个原因。虽然占比只有 1.3%，但 Resize 操作的数据量不小，CPU 处理起来耗时明显。

实操心得：build 的时候一定要开 verbose=True，仔细看算子分配日志。如果发现大量算子 fallback 到 CPU，要么换模型，要么改模型结构。我曾经遇到一个带 SE 模块的模型，SE 里的全局池化和乘法全部 fallback，速度直接掉了 5 倍。

5. 常见问题排查与避坑经验

5.1 转换阶段的高频报错

报错一：E build: The input shape is not supported

这个通常是因为 ONNX 的输入 shape 带了动态维度。解决方法是在导出 ONNX 时固定输入尺寸，或者用rknn.load_onnx(inputs=['input'], input_size_list=[[1,3,224,224]])显式指定。

报错二：E quantize: Unsupport quantized dtype

RV1103 只支持asymmetric_quantized-8，如果你写了dynamic_fixed_point-8或dynamic_fixed_point-16，会报这个错。改过来就行。

报错三：E build: Meet unsupported op: xxx

某个算子 RKNN 完全不认识。这种情况要么换模型，要么用 ONNX 的算子替换功能，把不支持的算子拆成支持的算子组合。比如某些自定义的激活函数，可以拆成 ReLU 加线性变换。

5.2 精度异常的排查思路

量化后精度掉得离谱（比如掉了 20%），排查顺序是这样的：

第一步，检查校准数据集。是不是图片太少？是不是和推理场景差异太大？是不是预处理不一致？我遇到过最离谱的一次，校准图片是 RGB 顺序，推理时是 BGR，精度直接崩了。

第二步，检查 mean/std 配置。RKNN 的 mean_values 和 std_values 是作用在 0-255 的像素值上的，不是 0-1。如果你训练时用的是 0-1 归一化，那 RKNN 里应该配 mean=0, std=255，而不是 mean=0.485, std=0.229。

第三步，逐层对比输出。RKNN 支持导出中间层结果，可以拿 FP32 和 INT8 的中间层输出做对比，看是哪一层开始误差放大的。通常是第一个卷积层或者最后一个全连接层最容易出问题。

第四步，尝试混合量化。RKNN 支持对特定层保持 FP16，其他层 INT8。如果某一层对量化特别敏感，可以把它单独设为 FP16。代价是模型体积和内存会增大。

5.3 板端运行的稳定性问题

问题一：推理几次后程序崩溃

大概率是内存泄漏。RKNN 的 inference 接口每次调用会分配输出 buffer，如果没释放，跑几百次就 OOM 了。Python 版本一般不用担心，C 版本要手动管理。建议用rknn_outputs_release释放输出。

问题二：帧率忽高忽低

RV1103 的 NPU 和 CPU 共享 DDR 带宽，如果同时跑视频编码或者网络传输，NPU 的带宽会被挤占，帧率就波动。解决方法是给 NPU 任务更高的优先级，或者错峰执行。

问题三：板子发热后降频

RV1103 在持续满载下会发热，温度到 85 度左右会触发降频，帧率掉 20% 到 30%。如果产品是密闭外壳，一定要考虑散热。我一般会在 NPU 上方贴一块小铝片，成本几毛钱，效果很明显。

5.4 常见问题速查表

6. 我的选型建议与实战体会

如果你现在就要在 RV1103 上做一个图像分类项目，我的建议是这样的。

追求极致速度、精度要求不高：选 SqueezeNet 1.1 或 ShuffleNetV2 0.5x。前者 55 FPS，后者 46 FPS，都能轻松跑满 30 帧。精度在闭集任务上 90% 左右，做二分类绰绰有余。

精度和速度要平衡：MobileNetV2 1.0x 是首选。30 FPS 刚好卡在实时门槛上，70% 的 ImageNet 精度和 95% 的闭集精度，覆盖绝大多数场景。它的算子兼容性也是满分，不会给你添麻烦。

精度优先、帧率可以妥协：EfficientNet-Lite0。24 FPS 做实时有点勉强，但如果你做的是“每 100ms 分析一帧”这种准实时任务，它的精度优势值得。注意它有少量算子 fallback，实际速度可能比标称的再低一点。

需要结构规整、方便二次开发：ResNet18。虽然慢（12.7 FPS）且吃内存（38.6MB），但它的结构最标准，改起来最方便。如果你的板子是 128MB DDR，且任务对帧率要求不高，它是个稳妥的选择。

最后分享一个我在实际项目中总结的小技巧：不要一开始就追求最优模型，先用 MobileNetV2 把整条链路跑通，包括数据采集、标注、训练、量化、部署、后处理。链路通了之后，再根据实测的精度和速度瓶颈，决定是换更快的模型还是更准的模型。我见过太多人一上来就纠结选哪个模型，结果卡在量化校准这一步好几天，链路根本没跑通。先把能跑的跑起来，再优化，这是边缘部署最务实的路径。