1. 为什么要在RV1103上折腾图像分类模型瑞芯微RV1103这颗芯片第一次拿到手的时候我其实没太当回事。QFN封装指甲盖大小内置64MB DDR2一颗Cortex-A7跑在1.2GHz外加0.5TOPS的NPU。纸面参数放在2024年看确实不起眼但它的定位非常明确——超低功耗、超低成本的边缘视觉入口。门禁、智能猫眼、玩具、工业读码器、电池供电的野保相机这些场景要的就是几块钱的芯片能干几毛钱的活功耗还得压到毫瓦级。图像分类是视觉任务里最基础也最成熟的一类。MobileNet、ResNet、EfficientNet、ShuffleNet、SqueezeNet这些主流模型在服务器和手机上早就被跑烂了。但把它们搬到RV1103这种资源极度受限的NPU上情况完全不一样。RV1103的NPU是瑞芯微自研的第四代架构跟RK3588上的NPU不是同一套工具链跟RK3568的RKNN支持程度也有差异。很多在RK3588上顺风顺水的模型到了RV1103上要么算子不支持要么量化后精度崩掉要么内存直接爆掉。我这次实验的目的很直接把当前主流的几个图像分类模型在RV1103上完整走一遍部署流程记录每个模型的量化精度损失、推理耗时、内存占用、CPU占用以及踩到的坑。不是跑个demo就完事而是要给出一份能直接抄作业的选型参考。如果你手头正好有RV1103的开发板或者正在评估用哪颗芯片做低功耗视觉产品这篇内容应该能帮你省掉至少两周的试错时间。需要提前说明的是RV1103的NPU工具链和RKNN-Toolkit2并不是完全通用的。瑞芯微官方对RV1103的支持主要通过RKNN-Toolkit2的特定版本配合RV1103专用的RKNPU2运行时库。网上很多RK3588的部署教程直接套用到RV1103上会出问题这一点后面会详细展开。2. 实验环境与工具链选型2.1 硬件平台与系统镜像我手上这块板子是瑞芯微官方RV1103 EVB核心板加底板的形式引出USB、MIPI CSI、以太网、TF卡槽。调试串口是TTL电平波特率1500000这个波特率比较特殊普通USB转TTL模块不一定支持我试过CH340和CP2102都不行最后用FT232才稳定连上。如果你手头的串口工具连不上先确认是不是波特率的问题。系统镜像用的是瑞芯微官方发布的RV1103 Buildroot镜像内核版本4.19根文件系统是Buildroot构建的。官方镜像里已经包含了RKNPU2的运行时库和rknpu_demo但版本比较老。我建议从瑞芯微官网固件下载页面获取最新的SDK自己重新编译一次因为NPU驱动和运行时库的版本匹配非常关键版本错位会导致推理结果完全错误。编译环境我用的是Ubuntu 20.04这是RKNN-Toolkit2官方推荐的版本。Ubuntu 22.04也能用但Python版本和依赖库需要额外处理容易出玄学问题。如果你不想折腾环境直接用Docker镜像是最省事的瑞芯微官方提供了RKNN-Toolkit2的Docker镜像拉下来就能用。2.2 RKNN-Toolkit2版本选择这里有一个非常关键的坑RV1103支持的RKNN-Toolkit2版本和RK3588不一样。截至我写这篇内容的时候RV1103需要RKNN-Toolkit2 1.6.0或更高版本但不要超过2.0.0因为2.0.0之后的版本对RV1103的算子支持有调整部分旧模型会报错。我实测下来1.6.0和1.6.1最稳。安装RKNN-Toolkit2的时候Python版本建议用3.8或3.9。3.10以上会有依赖冲突特别是numpy和onnx的版本。我试过在Python 3.11上装onnxruntime直接编译失败折腾了半天最后还是退回3.8。# 创建虚拟环境 python3.8 -m venv rknn_env source rknn_env/bin/activate # 安装RKNN-Toolkit2 1.6.0 pip install rknn-toolkit21.6.0 # 验证安装 python -c from rknn.api import RKNN; print(RKNN Toolkit2 loaded)板子端的运行时库版本必须和PC端工具链版本对应。PC端用1.6.0板子端的librknnrt.so也必须是1.6.0对应的版本。我遇到过PC端1.6.0、板子端1.5.0的情况模型转换不报错但板子上推理结果全是乱码。这个坑排查起来很费时间因为两边都不报错只是结果不对。2.3 模型选型思路图像分类模型我选了六个MobileNetV2、MobileNetV3-Small、ResNet18、ShuffleNetV2、SqueezeNet1.1、EfficientNet-Lite0。选型逻辑是这样的MobileNet系列是边缘部署的标配参数量和计算量都小ResNet18是经典骨干很多下游任务用它做特征提取ShuffleNetV2在同等计算量下精度不错SqueezeNet1.1极致轻量EfficientNet-Lite0是Google专门为边缘设备设计的量化友好。输入分辨率统一用224x224这是ImageNet的标准输入也是这些模型的原生训练分辨率。虽然RV1103的NPU支持动态分辨率但固定分辨率能让对比更公平。数据集用ImageNet的验证集取1000类中的前100类做快速验证每类50张图总共5000张。这个规模足够看出精度趋势又不会让推理时间太长。3. 模型转换与量化实操3.1 从ONNX到RKNN的完整流程模型转换是RV1103部署里最核心也最容易出问题的环节。整个链路是PyTorch/ONNX模型 - RKNN-Toolkit2加载 - 量化校准 - 导出RKNN模型 - 板端推理。先看一个完整的转换脚本以MobileNetV2为例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_platformrv1103, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) # 加载ONNX模型 ret rknn.load_onnx(modelmobilenetv2.onnx) if ret ! 0: print(Load ONNX failed) exit(ret) # 构建模型指定量化校准数据集 ret rknn.build(do_quantizationTrue, datasetcalibration_dataset.txt) if ret ! 0: print(Build failed) exit(ret) # 导出RKNN模型 ret rknn.export_rknn(mobilenetv2_rv1103.rknn) if ret ! 0: print(Export failed) exit(ret) rknn.release()这里有几个关键参数需要解释。mean_values和std_values是预处理参数必须和模型训练时一致。MobileNetV2用的是ImageNet的均值和标准差但注意RKNN的输入是RGB还是BGR这个取决于你的模型。PyTorch训练出来的模型通常期望RGB输入但OpenCV读图是BGR所以要么在转换时配置reorder_channel要么在板端做通道转换。我建议在转换时处理板端少一步操作就少一点CPU开销。quantized_dtype选asymmetric_quantized-8这是RV1103 NPU支持最好的量化类型。对称量化在某些层上会有精度问题非对称量化更稳。optimization_level设3让工具链做最大程度的图优化包括算子融合、常量折叠等。3.2 量化校准数据集的准备量化校准是决定精度损失的关键步骤。校准数据集不需要标注但需要覆盖模型实际推理时可能遇到的数据分布。我用的是ImageNet验证集里随机抽取的500张图每张图resize到224x224保存为jpg格式然后生成一个txt文件每行一个图片路径。# calibration_dataset.txt 格式 ./calibration/ILSVRC2012_val_00000001.JPEG ./calibration/ILSVRC2012_val_00000002.JPEG ...校准图片的数量不是越多越好。我试过100张、500张、1000张、5000张500张之后精度提升就非常有限了但转换时间线性增长。500张是一个比较平衡的点。另外校准图片的多样性比数量更重要尽量覆盖不同的场景、光照、物体类别。注意校准数据集里的图片必须和模型输入尺寸一致或者至少长宽比一致。如果校准图片是任意尺寸RKNN会在转换时做resize但resize的方式可能和你的预期不一致导致校准偏差。3.3 各模型转换参数差异不同模型在转换时的参数配置有差异这里整理一个对照表模型输入尺寸均值标准差量化类型转换耗时MobileNetV2224x224[123.675,116.28,103.53][58.395,57.12,57.375]asymmetric_quantized-8约3分钟MobileNetV3-Small224x224[123.675,116.28,103.53][58.395,57.12,57.375]asymmetric_quantized-8约2.5分钟ResNet18224x224[123.675,116.28,103.53][58.395,57.12,57.375]asymmetric_quantized-8约5分钟ShuffleNetV2224x224[123.675,116.28,103.53][58.395,57.12,57.375]asymmetric_quantized-8约2分钟SqueezeNet1.1224x224[104,117,123][1,1,1]asymmetric_quantized-8约1.5分钟EfficientNet-Lite0224x224[127,127,127][128,128,128]asymmetric_quantized-8约4分钟SqueezeNet1.1的预处理参数比较特殊它用的是Caffe风格的均值和标准差这个在转换时要注意。EfficientNet-Lite0用的是[0,255]归一化到[-1,1]的方式均值和标准差都是127和128。ResNet18的转换耗时明显更长因为它的计算图更大算子更多。RV1103的NPU对ResNet18里的某些残差连接算子支持不够好转换时工具链会插入一些CPU算子这会导致板端推理时CPU占用升高。这个问题后面会详细说。4. 板端部署与性能实测4.1 板端运行时环境搭建板子端的部署需要把编译好的librknnrt.so、rknn_server可选、以及推理程序放到板子上。RV1103的根文件系统空间有限Buildroot镜像默认只有几十MB的可用空间放几个模型就满了。我建议用TF卡扩展存储或者通过NFS挂载PC端的目录。板端推理程序的编译需要交叉编译工具链。瑞芯微SDK里自带了arm-rockchip830-linux-uclibcgnueabihf工具链路径在prebuilts/gcc/linux-x86/arm/下面。编译时链接librknnrt.so和pthread。# 交叉编译示例 arm-rockchip830-linux-uclibcgnueabihf-gcc \ -o rknn_classify \ rknn_classify.c \ -I./include \ -L./lib \ -lrknnrt \ -lpthread \ -lm板端运行时的核心API调用流程是初始化RKNN上下文 - 加载模型 - 设置输入 - 运行推理 - 获取输出 - 释放资源。RV1103的NPU是单核的不支持多线程并发推理所以推理程序必须是串行的。如果你需要处理多路视频流只能分时复用或者用多颗芯片。4.2 推理耗时与内存占用实测这是最核心的部分。我在RV1103上跑了1000次推理取平均耗时同时用top和free记录CPU和内存占用。测试条件CPU定频1.2GHzNPU定频环境温度25度板子不加散热片。模型推理耗时(ms)CPU占用(%)内存占用(MB)模型大小(MB)MobileNetV218.3128.23.4MobileNetV3-Small11.7106.52.1ResNet1842.63514.811.2ShuffleNetV213.5117.12.3SqueezeNet1.19.895.31.2EfficientNet-Lite022.4159.64.7几个关键观察SqueezeNet1.1最快9.8ms但它的精度也是最低的。MobileNetV3-Small在速度和精度之间平衡得最好11.7ms的耗时对于30fps的视频流来说绰绰有余。ResNet18的CPU占用高达35%这是因为部分算子回退到了CPU执行NPU利用率不足。如果你要做实时视频分类ResNet18在RV1103上不是好选择。内存占用方面RV1103内置64MB DDR2系统本身占掉约20MB留给应用的空间大概40MB。ResNet18的14.8MB内存占用加上模型文件11.2MB总共26MB已经比较紧张了。如果同时跑其他任务很容易OOM。4.3 量化精度损失对比精度测试用ImageNet验证集的前100类每类50张共5000张。对比FP32模型在PC上的精度和INT8模型在RV1103上的精度。模型FP32 Top-1(%)INT8 Top-1(%)精度损失(%)MobileNetV271.870.21.6MobileNetV3-Small67.465.12.3ResNet1869.868.90.9ShuffleNetV269.466.82.6SqueezeNet1.158.254.73.5EfficientNet-Lite075.173.41.7ResNet18的精度损失最小只有0.9%因为它的网络结构对量化更鲁棒残差连接有助于误差传播。ShuffleNetV2和SqueezeNet1.1的损失较大超过2.5%这两个模型里的分组卷积和Fire模块对量化比较敏感。MobileNetV3-Small的2.3%损失需要注意因为它的FP32精度本来就不高量化后掉到65.1%在一些对精度要求高的场景可能不够用。如果必须用MobileNetV3建议用Large版本但Large版本在RV1103上的推理耗时约16ms比Small慢不少。实操心得量化精度损失可以通过混合量化来缓解。RKNN-Toolkit2支持对敏感层保持FP16其他层用INT8。但RV1103的NPU对FP16的支持有限混合量化后部分层会回退到CPU推理耗时可能翻倍。我试过对ShuffleNetV2做混合量化精度回升到68.1%但耗时从13.5ms涨到28.7ms得不偿失。5. 踩坑记录与排查技巧5.1 模型转换阶段的典型报错报错一E RKNN: Invalid model, inputs num is 0这个报错通常出现在加载ONNX模型时。原因是ONNX模型的输入节点没有被正确识别。常见于从PyTorch导出ONNX时没有指定input_names或者用了动态轴。解决方法是在导出ONNX时固定输入尺寸torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axesNone, # 不要用动态轴 opset_version11 )报错二E RKNN: Unsupport op: xxxRV1103的NPU不是所有ONNX算子都支持。遇到不支持的算子工具链会尝试用CPU实现但如果CPU也不支持就会报这个错。常见的坑包括HardSwish在MobileNetV3里出现RV1103的NPU不支持需要替换成ReLU6或HardSigmoidGlobalAveragePool在某些版本的工具链里有问题需要手动展开。报错三E RKNN: Quantize fail, layer xxx量化失败通常是因为校准数据集里的图片格式不对或者预处理参数配置错误。检查校准图片是不是RGB三通道尺寸是不是和模型输入一致。另外如果校准图片里有大量纯色或极端亮度的图也会导致量化失败。5.2 板端推理的常见问题问题一推理结果全是同一个类别这个问题的原因通常是输入数据没有正确传入NPU。检查rknn_inputs_set的调用确认buf指针有效size和模型输入尺寸一致。另外RV1103的NPU输入要求是NHWC格式如果你传的是NCHW结果会完全错误。问题二推理耗时波动大RV1103的NPU和CPU共享内存带宽如果CPU在跑其他任务NPU的推理耗时会明显波动。实测中当CPU占用超过50%时NPU推理耗时可能增加30%以上。建议在推理线程里设置CPU亲和性把推理线程绑定到CPU核心0其他任务用核心1。// 设置CPU亲和性 cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(0, cpuset); pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), cpuset);问题三模型加载失败报内存不足RV1103的64MB DDR2是硬限制。如果模型文件超过10MB加载时可能直接OOM。解决方法用rknn_init的RKNN_FLAG_COLLECT_PERF_MASK标志延迟加载或者把模型放到TF卡上用mmap方式加载。但mmap方式会增加推理时的IO开销实测耗时增加约2ms。5.3 常见问题速查表现象可能原因排查方法解决方案转换时报Unsupport op算子不支持查看工具链日志替换算子或升级工具链量化后精度暴跌校准集不匹配对比校准集和测试集分布更换校准集增加多样性板端推理结果乱码输入格式错误检查NHWC/NCHW转换时配置reorder_channel推理耗时波动CPU抢占带宽监控CPU占用设置CPU亲和性模型加载OOM内存不足查看free输出减小模型或扩展存储推理结果全同输入指针无效检查rknn_inputs_set确认buf和size正确6. 选型建议与场景匹配6.1 不同场景下的模型推荐如果你的场景是电池供电的门禁或猫眼对功耗极度敏感推荐MobileNetV3-Small。11.7ms的推理耗时配合RV1103的低功耗模式整机功耗可以控制在200mW以内。精度65%左右对于人脸检测后的二次分类比如区分人、宠物、包裹够用了。如果是工业读码器或质检设备对精度要求高但供电不是问题推荐ResNet18。虽然耗时42.6msCPU占用35%但精度损失只有0.9%而且ResNet18的特征提取能力更强方便后续接其他任务。注意加散热片RV1103长时间满负荷运行会降频。如果是玩具或教育机器人成本极度敏感推荐SqueezeNet1.1。9.8ms的耗时1.2MB的模型大小对存储和内存的压力最小。精度54.7%虽然不高但玩具场景通常只需要区分几个大类实际体验不会太差。EfficientNet-Lite0是一个折中选择22.4ms耗时73.4%精度比MobileNetV2精度高比ResNet18速度快。如果你的场景需要平衡精度和速度这个模型值得考虑。6.2 RV1103的边界在哪里RV1103不是万能的。它的0.5TOPS NPU在跑ResNet18这种级别的模型时已经比较吃力了。如果你需要跑YOLOv8或更大的检测模型RV1103基本没戏至少得上RV1106或RK3568。RV1106的NPU算力是1TOPS内存也更大适合稍复杂的视觉任务。另外RV1103不支持多模型并行推理。如果你需要同时跑分类和检测只能串行执行或者用两颗芯片。这一点在产品定义阶段就要考虑清楚不然后期改硬件成本很高。6.3 后续可以扩展的方向这次实验只覆盖了图像分类但RV1103的能力不止于此。它支持MIPI CSI输入可以直接接摄像头做实时推理。我下一步打算试试用RV1103做简单的目标检测把YOLOv5n量化后跑一下看看帧率能到多少。另外RV1103的NPU支持自定义算子如果遇到不支持的算子可以自己写NPU算子但这个门槛比较高需要瑞芯微的NPU指令集文档。模型方面可以试试知识蒸馏。用大模型教小模型让小模型在RV1103上达到更好的精度。比如用ResNet50教MobileNetV3-Small精度可能提升2-3个百分点而推理耗时不变。这个方向在边缘部署里很有价值值得花时间研究。最后分享一个我在调试过程中总结的小技巧RV1103的NPU在连续推理时前几次的耗时通常会比稳定后高10-15%因为NPU需要预热。如果你做性能测试建议先跑100次预热再取平均值。另外板子的供电质量对NPU性能影响很大用劣质USB线供电时推理耗时可能增加20%以上。换一根好点的线或者直接用稳压电源数据会稳定很多。