RV1103低成本视觉芯片图像分类部署实战：RKNN转换与INT8量化

做嵌入式视觉的人，迟早会面对“预算有限但还要上模型”这种灵魂拷问。而瑞芯微 RV1103 正是这一类需求里绕不开的芯片。这颗主打 IPC（网络摄像头）和 IoT 视觉的 SoC，单核 Cortex-A7 配 0.5TOPS 级别的 NPU，和“高算力”三个字完全不沾边，却偏偏是当前低价位图像分类部署最活跃的平台之一。这篇文章把我近两个月在 RV1103 上折腾各种主流图像分类模型的完整过程记录下来，包括模型选型、RKNN 转换、INT8 量化、板端推理、性能对比和踩坑实录，给准备在这颗芯片上做分类项目的朋友当个参考。

先说结论：MobileNetV3-Small 在 RV1103 上能达到“能看”的实时性，ResNet18 这类大一点儿的模型则属于“能跑但不是特别舒服”的范畴。更重要的不是某个模型跑多快，而是你如何在一颗只有 0.5TOPS 算力的芯片上，用正确的流程把一个模型从 PyTorch 一路送到 C 语言推理代码里。这个流程，才是这篇文章真正想讲的。

1. 在动手之前，先看懂 RV1103 这颗芯片

1.1 单核 CPU + NPU 的奇葩组合意味着什么

RV1103 在瑞芯微的产品序列里定位很清晰：低成本 IPC 主控。它有一颗 ARM Cortex-A7 单核 CPU，频率在 1GHz 级别，配套的 NPU 算力约 0.5TOPS（INT8）。和电脑显卡动辄几百 TOPS 比，这个数据寒酸到让人怀疑人生，但对一个售价极低的摄像头主控来说，它最大的价值是：把神经网络中计算量最大的卷积层从 CPU 搬到 NPU 上，让 CPU 专心做控制、网络协议和预处理。

这个“单核 A7 + 0.5TOPS NPU”的组合非常有意思。单核 CPU 意味着任何需要在 CPU 上跑的图像预处理、后处理、softmax、网络通信，都得精打细算。你以为瓶颈是 NPU，实际跑起来常常发现 CPU 先撑不住了。我自己测试时就遇到一个典型场景：输入分辨率从 224 改成 320，NPU 耗时只增加了十几毫秒，但 CPU 端的 resize 和归一化直接吃掉大几十毫秒。所以后面所有实验，我都会把图像预处理作为整体耗时的一部分来统计，而不是只看 NPU 推理时间。

内存方面，RV1103 这类板卡通常集成内置内存，容量不大，我手上这块评估板可用内存大概在几十 MB 这个量级。这意味着大模型、大输入分辨率、多路数据流这些想法在动手前就要被砍掉一半。做部署设计时，我基本都是按“模型权重 + 中间特征图 + 输入输出 buffer + 系统余量”的顺序估算，算完再决定用哪个模型。

1.2 为什么偏偏拿它做图像分类部署实验

有人可能会问，图像分类模型那么多，随便找台电脑跑一下不就知道准确率了？部署实验的意义不在“模型效果”，而在“芯片到底能不能把这个模型跑起来、跑多快、精度损失多少”。

选择 RV1103 做这场实验，原因有三。第一，它足够便宜，围绕它的开发板几十块钱就能买到，适合低成本产品原型验证。第二，它的 NPU 是瑞芯微 RKNN 生态，和 RK3568、RK3588 这些中高端芯片共用一套工具链，在低端芯片上跑通的流程，将来迁移到高算力平台几乎是平滑的。第三，也是最实际的一点，图像分类是目标检测、图像分割、人脸识别等一切视觉任务的基础，把分类模型部署链路摸透了，后面上 YOLO 类模型会轻松很多。

整个实验我用了 6 个主流分类模型：MobileNetV1、MobileNetV2、MobileNetV3-Small、ShuffleNetV2、EfficientNet-Lite0、ResNet18，外加一个“反面教材”ResNet50 做压力测试。所有模型统一从 PyTorch 导出 ONNX，再转换为 RKNN 格式，先在 PC 模拟器跑通，再烧到板子上实测。下面按顺序拆解整个过程。

2. 模型选型：用什么标准判断模型配得上 0.5TOPS

2.1 先算一笔算力账，避免盲目乐观

部署之前先做理论推算，可以帮你过滤掉一大批“看起来很美好”的模型。NPU 的 0.5TOPS 指标，按字面理解是每秒 5000 亿次操作。一个 224x224 输入的 MobileNetV2，计算量大约是 300M MACs（乘累加操作数）。如果按 1 MAC = 2 ops 粗算，就是 600M 次操作。理论上在 0.5TOPS NPU 上跑一次约需 1.2 毫秒，折合 800 帧每秒。

但这个数字是纯理想值，实际永远达不到。NPU 的算力利用率通常取决于卷积算子的形状、内存带宽、数据搬运开销和 API 调用损耗。在 RV1103 上我实测的 NPU 利用率大约在 20%~40% 之间。也就是说，MobileNetV2 单次推理实际耗时可能在 3~6 毫秒这个区间，加上预处理和 CPU 开销，整链路跑到 30 FPS 以上就算理想状态。

所以我做选型时先给自己定了几个硬指标：

• 整链路（含预处理和输出处理）不低于 20 FPS，这是低成本摄像头场景比较常见的实时性底线。
• 模型权重文件不超过 10MB，INT8 量化后权重尽量控制在 5MB 以内，给运行时留足内存。
• Top-1 精度（ImageNet 验证集）不低于 65%，否则很多实际场景会误判得没法用。
• 算子尽量简单通用，避免某些花哨结构在 RKNN 转换时爆算子不支持。

按这个标准划拉一圈，ResNet50 直接出局——它的计算量是 MobileNet 系列的十几倍，0.5TOPS 上理论能跑，实际上帧率惨不忍睹，没有任何工程意义。ResNet18 勉强及格，但后面实测数据也确实印证了它“能跑但不舒服”。真正舒服的是 MobileNet 系、ShuffleNet 系这种轻量骨架。

2.2 候选模型清单和各自脾气

我最终选定的 6 个模型，覆盖面足够广，每个都有代表性：

• MobileNetV1：老牌轻量模型，结构简单，深度可分离卷积的祖师爷，RKNN 支持非常成熟，作为基准模型测试工具链最稳。
• MobileNetV2：带倒残差结构和线性瓶颈，理论计算量比 V1 略低，实际部署时内存占用和 NPU 算子调度反而更复杂一些。
• MobileNetV3-Small：专为低算力场景设计的版本，引入了 h-swish 和 SE 模块，精度和速度的平衡在轻量模型里很突出。
• ShuffleNetV2：作者明确提出“实测速度才是王道”，分组卷积加通道重排，在 ARM 平台一直口碑很好，但分组卷积在部分 NPU 上效率波动大。
• EfficientNet-Lite0：EfficientNet 的移动端版本，去掉了一些 NPU 不太友好的算子，输入分辨率 224，理论精度高，但结构相对复杂。
• ResNet18：标准残差网络，做对比实验很好用，看看传统骨干在 0.5TOPS 下到底什么水平。

这里我给一个建议：如果你纯粹是给产品选型，先跑 MobileNetV2 和 MobileNetV3-Small 就够了，大多数低压分类场景这两个模型基本覆盖。其他模型是为了观察规律，而不是为了找最优解。

2.3 预训练权重怎么挑

实验用的权重，我全部来自 PyTorch 官方 TorchVision 或 Timm 库。使用官方权重的好处是 ImageNet 准确保值和输入预处理约定是公开的，不需要自己重新训练。每个模型的输入归一化参数，我都提前记下来：TorchVision 系列基本都用 mean=[0.485, 0.456, 0.406]，std=[0.229, 0.224, 0.225]，缩放系数是 1/255。后面转 RKNN 时这几个参数要原封不动写进配置，否则部署出来精度一定出问题。

另外注意输入尺寸。TorchVision 分类模型大部分默认 224x224，但 EfficientNet-Lite0 也是 224，MobileNetV3-Small 同样是 224，这就省了很多事。我统一用 224x224 做对比，排除分辨率变量。

3. 部署环境搭建和模型转换全流程

3.1 把 RKNN 工具链装到一台干净的 Linux 机器上

RV1103 用的推理框架是瑞芯微的 RKNN，模型转换工具是 RKNN-Toolkit2。这套工具链只负责把 PyTorch、ONNX、TensorFlow 等模型转成 RKNN 格式，真正的板端推理还要配合 SDK 里的 RKNN Runtime。

我建议单独准备一台 Ubuntu 20.04 或 22.04 的 x86 机器做转换，不要混在开发环境里。RKNN-Toolkit2 对 Python 版本有要求，官方文档推荐 Python 3.8~3.11 左右，我用的是 Ubuntu 20.04 + Python 3.8，基本没碰到兼容性问题。安装核心命令就一行：

pip install rknn-toolkit2

装完验证一下：

python -c "from rknn.api import RKNN; print('ok')"

如果打印 ok，说明库能正常导入。接着要准备三样东西：训练好的/官方预训练模型文件（或 ONNX）、量化校准图片集、以及板端 SDK。RV1103 的 SDK 里带有 rknn-server 和 runtime 库，但每次实验我都是先用 PC 模拟器把转换和推理逻辑调通，再连接板子做真机验证。这个习惯帮我节省了大量改板子固件的时间。

3.2 从 PyTorch 导出 ONNX，这一步决定后续生死

ONNX 是中间格式，导出得好不好直接影响 RKNN 转换成功率。以 MobileNetV2 为例，导出代码非常简短：

import torch from torchvision.models import mobilenet_v2, MobileNet_V2_Weights model = mobilenet_v2(weights=MobileNet_V2_Weights.IMAGENET1K_V1) model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "mobilenet_v2.onnx", opset_version=12, input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}} )

这里有两个细节值得注意。第一，opset_version 不要追求新版，我测试下来 12 比 15、17 更稳，因为高版本 ONNX 会引入更多新算子，RKNN 解析器不一定覆盖。第二，如果能确定部署时 batch=1，就不要开 dynamic_axes，省得转换器额外处理动态维度逻辑。上面的代码我故意保留了 dynamic_axes 是给想看多 batch 的读者一个参考，实际项目里直接删掉更省心。

导出之后用 Netron 打开 ONNX 看一眼，重点确认输入节点名字是 input、输出是 output，以及有没有奇怪的算子。我自己遇到过一次 torchvision 新版本导出的 ResNet18 里出现了aten::__getitem__之类的临时算子，虽然最终能被 RKNN 解析，但会多出很多无谓的转换警告，严重时直接失败。遇到这种情况，解决方案是导出前把模型的 forward 函数改写得更“朴素”一些，删掉所有不影响数值的 reshape、切片和 getitem 逻辑。

3.3 ONNX 转 RKNN：INT8 量化不是简单咔嚓一刀

转换的核心代码在 PC 上跑。先初始化 RKNN 对象，指定目标平台，再加载 ONNX，然后量化、构建、导出：

from rknn.api import RKNN rknn = RKNN() rknn.config( target_platform="rv1103", mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], quantized_dtype="w8a8", quantized_algorithm="normal", quantized_method="layer", ) ret = rknn.load_onnx(model="mobilenet_v2.onnx") if ret != 0: print("load onnx failed") exit(1) ret = rknn.build(do_quantization=True, dataset="dataset.txt") if ret != 0: print("build failed") exit(1) rknn.export_rknn("mobilenet_v2.rknn") rknn.release()

这一段代码里有三个坑，是我反复踩过以后才彻底理解的。

第一个坑是 mean_values 和 std_values 的语义。RKNN 的 mean/std 和 PyTorch 的归一化写法次序相反，而且它是按像素值 0~255 来算的。如果你的 PyTorch 模型输入是 0~1 的 float，在导出 ONNX 前可以不做预处理，直接在 RKNN config 里写 mean=0、std=255，让 NPU 入模之前自己缩放，前提是量化的输入数据分布合理。如果模型训练时的输入就是标准化后的 tensor，那就要按照 mean=[0.485,0.456,0.406] 这种真实值配置，并在板端也保持完全一致的预处理。两种写法都能跑，但混用一定出问题。我的测试统一采用“ONNX 输入为 0~1 的 RGB 图，RKNN 侧 mean=[0,0,0], std=[255,255,255]”，这样板端预处理简单，只做 resize 和通道顺序调整。

第二个坑是量化算法。默认的 normal + layer 量化对大多数模型够用，但如果你发现某个模型量化后精度掉得离谱，可以试试quantized_algorithm="mmse"或quantized_method="channel"。代价是转换时间变长、量化模型可能变大，但对 ShuffleNetV2 这种分组卷积多的模型，channel 量化的精度通常明显更好。

第三个坑是 dataset.txt 里的校准图片。别随便弄三五张就上了。量化过程本质是统计激活值的分布，校准集必须覆盖真实场景的多样性。我用的是 ImageNet 验证集里每个类别抽 1~2 张，总共 200~400 张图，存成一个 txt 文件，每行一个图片绝对路径。图片不需要标注，但内容要有变化，不能全是纯色或单一场景。校准图片太少，最常见的结果是 Top-1 精度从 71% 掉到 50% 以下，而且完全无规律。

转换完成后，强烈建议先用 PC 模拟器跑一遍，对比 RKNN 输出和原始 PyTorch 输出的数值差异。RKNN-Toolkit2 提供了rknn.init_runtime()接口，不接板子也能模拟推理。我自己所有模型都会先做这一步，确认 Top-1 类别一致后才上板。

4. 板端运行：从模拟器到真机推理

4.1 板端程序骨架：C API 还是 Python API

RV1103 板端跑 Linux，SDK 里提供了 Python 和 C 两套 RKNN 推理接口。Python API 在原型验证阶段很好用，因为调试方便，不用交叉编译；但产品化阶段一定要用 C API，因为 Python 解释器吃内存、启动慢，在内存只有几十 MB 的板子上压力很大。我的实验为了贴近真实产品，全部使用 C API 写测试程序。

C API 程序的基本骨架如下：

#include "rknn_api.h" // 加载模型 rknn_context ctx; rknn_init(&ctx, model_data, model_size, 0, NULL); // 设置输入 rknn_input inputs[1]; inputs[0].index = 0; inputs[0].type = RKNN_TENSOR_UINT8; inputs[0].size = width * height * 3; inputs[0].fmt = RKNN_TENSOR_NHWC; inputs[0].buf = img_data; inputs[0].pass_through = 0; rknn_inputs_set(ctx, 1, inputs); // 推理 rknn_run(ctx, NULL); // 获取输出 rknn_output outputs[1]; outputs[0].want_float = 1; rknn_outputs_get(ctx, 1, outputs, NULL); float* scores = (float*)outputs[0].buf; // 在这里做 argmax / softmax rknn_outputs_release(ctx, 1, outputs);

这段代码有几个参数需要解释。pass_through = 0表示输入数据会经过 RKNN 内部的预处理，也就是我前面配置的 mean/std 归一化；如果置 1，则是原始数据直接送入 NPU，预处理全部由自己搞定。为了和转换配置保持一致，我用 pass_through=0，板端只负责把图像数据按 NHWC 排列成 uint8 数组。

输出部分want_float = 1表示让 NPU 把 INT8 输出反量化成 float，方便我直接比较 softmax 分数。如果你对性能极致敏感，可以设成 0 直接在 INT8 输出上做 argmax，省去反量化时间。但注意在 INT8 输出上做 argmax，类别顺序不变，所以实际项目里完全可以这么干。

4.2 预处理对齐：九成部署翻车都在这

板端预处理是整个流程里最“阴”的部分，因为它在代码里看不出错，但结果就是不对。我在实验里统一用 OpenCV 读图，处理链是：

1. cv::imread读取 BGR 图。
2. cv::resize缩放到 224x224，默认双线性插值。
3. 转换通道顺序为 RGB（因为 RKNN-Toolkit2 的 ONNX 输入约定是 RGB）。
4. 数据拷贝成连续 uint8 数组。

为什么要单独强调通道顺序？因为 TorchVision 的模型基本都是 RGB 输入，而 OpenCV 的 imread 读出来是 BGR，一旦忘记转换，整个模型的输出会变成一团乱码，但更诡异的是，由于有些类别颜色特征不明显，偶尔还能蒙对几个，让你以为只是精度略低。我调试时吃过这个亏，最后是用一张纯红色图片做对照，PyTorch 输出类别 index 和板端对不上，才定位到通道问题。

resize 的插值方式也要留意。RKNN Runtime 内部如果自己带预处理，会使用特定的插值算法，不同版本可能不同。我建议板端统一用 OpenCV 做 resize，然后让 pass_through=0 或 1 都行，只要保证转换、模拟器、板端三处一致即可。这里的一致性指：训练、量化校准、推理三个阶段的预处理严格相同。

4.3 计时方法：别只盯着 NPU 推理时间

整个实验的性能数据，我采用std::chrono在板端做毫秒级计时，分三段：

• 总耗时：从图像 buffer 准备好之后，到 outputs 拿到之前，包括 rknn_inputs_set、rknn_run、rknn_outputs_get。
• NPU 耗时：用rknn_query查询内部时间，或者连续调用 rknn_run 来测。
• 预处理耗时：从 OpenCV 的 resize 和通道转换开始计时。

实际上，如果你只用rknn_run计时，得到的数据“很好看”，但完全不代表用户体验。我曾遇到一个问题：NPU 推理只要 8ms，但整条链跑下来 200ms，罪魁祸首是 CPU 端把图像做 resize 时没有释放 OpenCV 的中间 Mat 对象，内存频繁分配导致卡顿。这类问题只有统计整链路耗时才能暴露。

5. 实验数据：跑分之前，先统一度量衡

5.1 测试条件的统一口径

模型对比最怕的就是各跑各的条件。我在所有模型上强制统一以下设置：

• 输入分辨率：224x224，RGB，uint8。
• 板端固件：同一版本 SDK，NPU 频率固定为评估板默认值。
• 预处理：OpenCV resize（双线性） + BGR2RGB，归一化在 RKNN 内部通过 mean/std 完成。
• 推理次数：每模型预热 50 次，再连续测 200 次取平均。
• 环境：板卡被动散热，室温约 25 度，连续测试时注意不要因降频导致数据忽高忽低。

这里提醒一下，NPU 频率对 FPS 影响极大，SDK 里可能有动态调频策略。如果实验途中温度过高，NPU 降频后性能可能掉 30% 以上。做对比前先跑个 MobileNetV2 打底，确认帧率和以往一致再开始，否则数据不可比。

5.2 六个模型的实测结果

经过一轮完整测试，我得到的数据大概如下：

说明：这是我自己板子上的实测值，换不同 SDK、不同 NPU 频率或不同量化校准集，数据会有变化。Top-1 是 ImageNet 验证集抽样子集上的近似结果，并不是完整 5 万张逐一跑完。

从数据可以看出三个规律。第一，算力消耗和 FPS 不成严格反比。EfficientNet-Lite0 计算量只有 ResNet18 的五分之一，但帧率只高了 11 帧，说明它那些复杂结构在 RV1103 上并没有发挥出理论优势，NPU 算子调度效率明显不如 MobileNet 系列。第二，MobileNetV3-Small 是这轮实验的“性价比之王”，66M MACs 就跑出 43 FPS，虽然精度比 MobileNetV2 低了几个点，但换来的速度收益完全值得。第三，ResNet18 在 0.5TOPS 上确实只能算“技术验证”，8 FPS 做交互式应用可以，做实时视频流分析就太吃力了。

5.3 精度损失：INT8 量化不是免费的午餐

每个模型在转换后，精度相比 FP32 都有一定损失，量级在 1~4 个百分点。损失最小的通常是 MobileNetV2 和 MobileNetV3-Small，因为它们的结构对激活值分布更友好；损失最大的是 ShuffleNetV2，分组卷积和通道重排导致逐层量化误差累积更明显。

如果你在意精度，我有两个招儿。第一，校准集尽量贴近真实数据分布，例如你产品是拍车间还是拍街道，校准图就选对应场景，比乱用 ImageNet 通用图效果好得多。第二，部分层可以用 INT16 混合量化，RKNN 支持指定某些层保留更高精度，代价是推理速度变慢。我实测混合量化后 ShuffleNetV2 的精度能拉回 2 个点，速度大概下降 15%，值不值看场景。

6. 部署中踩过的坑和排查速查

6.1 高频报错与排查思路

实验过程中，我整理了五个出现频率最高的坑，基本覆盖了新手会遇到的 80% 问题：

• load_onnx failed或各种算子不支持：先用 Netron 检查 ONNX 里有没有 BatchNorm、Resize 等特殊算子的奇怪变体，再尝试降低 opset 版本到 11 或 12。真不行就改模型结构，把复杂算子替换成等价的基础算子。
• 转换成功但板端推理结果全是一个类别：多半是预处理或通道顺序问题，用一个固定输入图分别跑 PyTorch 和板端 RKNN，对比输出分数。
• 精度掉到 60% 以下：校准集太少或分布偏了。我试过只用 10 张图校准 MobileNetV2，精度能掉到 50% 以下。校准集至少 100 张，类别尽量均衡。
• rknn_init返回错误码：确认模型文件完整，SDK 和工具链版本匹配。RV1103 的 runtime 库版本太旧，可能加载不了新版 RKNN 格式。
• 板端内存不足导致启动崩溃：降低输入分辨率、换更小模型，或者检查代码里是否有未释放的 buffer。RV1103 的内存经不起任何“随手 new 一个几 MB 数组”的折腾。

6.2 容易被忽略的三个细节

第一个是关于 NPU 频率的“玄学”。有些板卡默认 NPU 频率保守，跑模型性能不佳，需要手动在设备树或驱动层确认频率配置。不要盲目调太高，RV1103 本身算力不大，频率上去了发热也快，做产品还要考虑稳定性。

第二个是 OpenCV 在板端 CPU 上的性能问题。RV1103 的单核 A7 处理 224x224 resize 其实问题不大，但如果你用了裁剪、旋转、透视变换这些复杂操作，CPU 时间会爆炸。能省则省，必要时用简单最近邻插值或直接降采样，优先保证整链路帧率。

第三个是前后端数据拷贝。如果图像数据从 ISP 或摄像头模组出来已经是连续的 RGB buffer，尽量直接 zero-copy 复用，避免一次 memcpy 浪费几十毫秒。我用过零拷贝方式后，把 MobileNetV3-Small 的整链路 FPS 从 38 拉到了 43，效果立竿见影。

6.3 我踩过坑之后的推荐操作顺序

如果从现在开始重新做一个 RV1103 分类项目，我会按这个顺序走：

1. 先用 PC 模拟器搭好转换流程，选 2~3 个备选模型。
2. 板端先跑 MobileNetV2 作为 baseline，验证整个推理链路和性能采集方法没问题。
3. 再跑备选模型，对比 FPS 和精度，选出主模型。
4. 最后优化预处理和内存拷贝，把整链路帧率榨到极限。
5. 产品化时，把模型、运行时库、预处理和后处理都固定版本，专人维护，避免“哪都能跑、但每次数据都不一样”。

关于如何快速判断一个新模型能不能上 RV1103，我个人的经验是：先看权重和计算量，INT8 权重超过 15MB、MACs 超过 800M 的基本别想了；再转成 RKNN 用模拟器跑一遍，如果模拟器单次都超过 50ms，上板大概率也不会好到哪去；最后上板实测整链路。这套流程下来，至少能帮你少浪费一两天调研时间。