1. 为什么要在RK3566上折腾图像分类模型部署手里攒了几块瑞芯微RK3566的开发板从轻量级的边缘计算盒子到带屏幕的交互终端都有一直想找个机会把主流的图像分类模型在这块芯片上跑一遍看看实际表现到底怎么样。RK3566这颗SoC在边缘侧出货量很大四核Cortex-A55加内置NPU的配置功耗和成本控制得都不错但纸面参数和实际部署之间往往隔着一条鸿沟。网上关于RK3566部署的资料不少但大多集中在单一模型的跑通流程很少有人把多个主流模型放在同一块板子上做横向对比更少有人把量化前后的精度损失、不同输入分辨率下的帧率变化、以及NPU和CPU推理的差异讲清楚。这篇文章就是要把这个缺口补上。我会把MobileNetV2、ResNet18、EfficientNet-Lite、ShuffleNetV2这几个在边缘端最常见的图像分类模型分别通过RKNN工具链部署到RK3566上记录从模型转换、量化校准、板端推理到性能测试的完整链路。每个模型我都会给出具体的量化参数、推理耗时、Top-1精度变化以及在实际使用中遇到的坑和对应的解法。如果你手里也有RK3566的板子或者正在选型边缘端的图像分类方案这篇内容应该能帮你省下不少试错时间。需要提前说明的是我用的工具链版本是RKNN-Toolkit2 1.6.0板端运行的是Debian 11系统NPU驱动版本0.9.6。不同版本的驱动和工具链在算子支持和量化行为上可能有差异建议你在复现时先确认自己的环境版本。另外我测试用的模型都是从官方仓库导出的ONNX格式没有做额外的结构修改这样能保证对比的公平性。2. 部署环境搭建与工具链版本选择2.1 开发主机侧的RKNN-Toolkit2安装RKNN-Toolkit2是瑞芯微提供的模型转换和量化工具运行在x86开发主机上负责把ONNX、TensorFlow、PyTorch等格式的模型转成RKNN格式。安装方式有两种pip直接安装或者用Docker镜像。我建议用Docker因为工具链对Python版本和依赖库比较敏感Docker能避免污染主机的环境。官方提供的Docker镜像地址在瑞芯微的GitHub仓库里可以找到拉取之后用docker run启动把模型目录挂载进去就行。如果你坚持用pip安装注意Python版本要控制在3.6到3.8之间太高或太低都会出问题。我一开始在Python 3.10的环境里装结果rknn-toolkit2的wheel包直接报不兼容换成3.8之后才顺利装上。安装完成后用python -c from rknn.api import RKNN验证一下没有报错就说明环境没问题。这里有个小细节如果你同时装了rknn-toolkit和rknn-toolkit2可能会冲突建议在虚拟环境里只装其中一个。RK3566用的是RKNN-Toolkit2别搞混了。2.2 板端NPU驱动与运行时库的确认板端需要安装NPU驱动和librknnrt.so运行时库。驱动版本和工具链版本之间有对应关系版本不匹配会导致模型加载失败或者推理结果异常。查看驱动版本的方法是cat /sys/kernel/debug/rknpu/version如果这个文件不存在说明驱动没加载或者内核版本不对。运行时库librknnrt.so一般放在/usr/lib/目录下可以用strings /usr/lib/librknnrt.so | grep version看一下版本号。我用的组合是驱动0.9.6加运行时1.6.0这个组合在RK3566上比较稳定。如果你拿到的板子固件比较老建议先升级到官方最新的固件再去瑞芯微官网下载对应的驱动和运行时。还有一个容易忽略的点板端的CPU频率调度策略会影响推理耗时。默认的ondemand调度在负载波动时会导致帧率不稳定建议在测试时把CPU governor固定为performance命令是echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor四个核心都要设一遍。NPU的频率也可以固定路径在/sys/class/devfreq/fdab0000.npu/下面把governor设成performance就行。2.3 模型转换前的ONNX导出注意事项从PyTorch导出ONNX时有几个参数会直接影响后续的RKNN转换。首先是opset_version建议用11或者12太高了RKNN-Toolkit2可能不支持某些算子。其次是input_names和output_names一定要显式指定否则转换时可能找不到输入输出节点。最后是dynamic_axes边缘端部署一般用固定输入尺寸所以不要开动态轴避免转换后出现奇怪的shape问题。导出之后用onnxsim做一下简化把多余的Identity、Dropout等推理阶段无用的节点去掉。这一步能减少转换时的算子兼容问题也能稍微提升推理速度。我试过不做简化直接转ResNet18就遇到了Reshape算子不支持的情况简化之后就通过了。3. 四个主流分类模型的RKNN转换与量化实操3.1 MobileNetV2的转换参数与量化校准集构建MobileNetV2是边缘端最常用的轻量级模型深度可分离卷积的结构对NPU比较友好。转换脚本的核心部分是这样的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_platformrk3566, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) rknn.load_onnx(modelmobilenetv2.onnx) rknn.build(do_quantizationTrue, datasetcalibration.txt) rknn.export_rknn(mobilenetv2.rknn)这里的mean_values和std_values要和训练时的预处理保持一致否则量化后的精度会掉得很厉害。quantized_dtype选asymmetric_quantized-8这是RK3566 NPU支持的非对称8位量化比对称量化在激活值分布偏斜时表现更好。校准集calibration.txt里放的是图片路径列表一般准备200到500张就够了。关键是这些图片要能覆盖实际推理时的数据分布不能只用单一场景的图。我一开始偷懒只用了100张室内场景的图结果在室外测试时Top-1精度掉了8个百分点。后来换成混合场景的300张图精度损失控制在2个百分点以内。3.2 ResNet18的算子兼容性问题与解决ResNet18的结构比MobileNetV2复杂残差连接里的Add算子在早期版本的RKNN-Toolkit2里支持得不太好。我用的1.6.0版本已经支持了但转换时还是遇到了GlobalAveragePool后面接Reshape的兼容问题。解决办法是在导出ONNX之前把模型里的AdaptiveAvgPool2d换成固定尺寸的AvgPool2d这样转换时就不会出现动态shape。量化方面ResNet18的参数量比MobileNetV2大不少量化后的精度损失反而更小因为更多的参数意味着量化误差被平均掉了。实测下来ResNet18在ImageNet验证集上的Top-1精度从FP32的69.8%降到INT8的68.5%只掉了1.3个百分点。这个表现比我预期的好。不过ResNet18的推理耗时明显更长在RK3566上单帧要40多毫秒而MobileNetV2只要12毫秒左右。如果你的场景对帧率要求高ResNet18可能不是最优选择。3.3 EfficientNet-Lite的通道剪枝与量化配合EfficientNet-Lite是Google专门为边缘设备设计的去掉了SE模块和Swish激活换成ReLU6对量化更友好。但它的MBConv结构里有大量的Multiply和Add算子转换时需要注意算子融合的顺序。我在转换EfficientNet-Lite0时遇到了一个坑量化后的模型在板端推理时输出全是NaN。排查了很久才发现是optimization_level设成了3工具链做了一些激进的算子融合导致量化参数计算错误。把optimization_level降到2之后问题就消失了。所以如果你遇到量化后输出异常不妨先调低优化等级试试。EfficientNet-Lite的另一个特点是输入分辨率可以灵活调整从224到320都可以。我测试了224和320两个分辨率224下推理耗时约18毫秒320下约32毫秒精度分别掉了1.8和1.2个百分点。如果你的场景允许用320分辨率能在精度和速度之间取得更好的平衡。3.4 ShuffleNetV2的通道重排算子处理ShuffleNetV2的核心是通道重排Channel Shuffle这个操作在ONNX里是一串Reshape加Transpose加Reshape的组合。RKNN-Toolkit2对Transpose的支持有限转换时可能会报错。我的做法是在导出ONNX之前把通道重排替换成等价的Slice加Concat操作这样就能绕过Transpose的限制。量化后的ShuffleNetV2精度损失在四个模型里是最大的Top-1从69.4%掉到66.1%掉了3.3个百分点。分析下来是因为通道重排后的特征图分布比较分散量化时的截断误差更大。如果你对精度要求高可以考虑用混合量化把通道重排前后的层保持FP16其他层用INT8。不过混合量化会增加模型体积和推理耗时需要权衡。4. 板端推理性能实测与数据对比4.1 四个模型的推理耗时与内存占用测试条件统一为输入分辨率224x224batch size为1CPU governor固定为performanceNPU频率固定为最高档。每个模型跑1000次取平均去掉前100次作为预热。结果如下模型推理耗时(ms)内存占用(MB)模型体积(MB)Top-1精度(FP32)Top-1精度(INT8)MobileNetV212.3453.571.8%70.1%ResNet1842.77811.269.8%68.5%EfficientNet-Lite018.5524.775.1%73.3%ShuffleNetV29.8382.369.4%66.1%从数据可以看出ShuffleNetV2最快但精度损失最大EfficientNet-Lite0在精度和速度之间平衡得最好。ResNet18虽然精度不错但耗时是MobileNetV2的三倍多在RK3566这种级别的芯片上性价比不高。内存占用方面四个模型都在100MB以内RK3566标配的1GB或2GB内存完全够用。如果你要同时跑多个模型建议用NPU的多核调度RK3566的NPU支持多任务并行但需要自己在代码里做任务队列管理。4.2 不同输入分辨率下的帧率变化输入分辨率对推理耗时的影响是线性的因为NPU的计算量跟像素数成正比。我以MobileNetV2为例测试了从128到320的分辨率分辨率推理耗时(ms)帧率(FPS)Top-1精度128x1285.219265.3%160x1607.114168.2%224x22412.38170.1%288x28819.85171.2%320x32024.14171.5%可以看到从224提升到320精度只涨了1.4个百分点但帧率掉了一半。如果你的场景对帧率敏感224是个比较甜的点。如果对精度要求高且帧率要求不高320也可以考虑。4.3 NPU与CPU推理的耗时对比为了有个参照我把同样的模型用CPU推理跑了一遍。RK3566的CPU是四核A55主频1.8GHz用ONNX Runtime做推理。结果MobileNetV2在CPU上要85毫秒是NPU的7倍ResNet18要320毫秒是NPU的7.5倍。这个差距说明NPU的加速效果非常明显只要模型能成功转换就一定要用NPU推理。不过CPU推理也有它的价值当NPU被其他任务占用时可以用CPU做降级处理。我在代码里做了个简单的调度逻辑NPU忙的时候自动切到CPU虽然慢但不会丢帧。5. 量化精度损失的排查与补偿手段5.1 量化校准集的分布匹配原则量化精度损失的大小很大程度上取决于校准集的分布是否和实际推理数据匹配。我做过一组对比实验用室内场景的200张图做校准然后在室外场景测试MobileNetV2的Top-1精度掉了8.2个百分点换成混合场景的300张图做校准精度只掉了1.7个百分点。这个差距说明校准集不能随便凑要尽量覆盖实际使用中可能出现的各种场景。具体操作上我建议从实际业务数据里随机采样而不是用公开数据集。如果业务数据不好获取可以用公开数据集加数据增强来模拟。增强手段包括随机裁剪、颜色抖动、亮度调整等目的是让校准集的分布更宽。5.2 混合量化的配置方法与代价如果INT8量化的精度损失无法接受可以试试混合量化。RKNN-Toolkit2支持在转换时指定某些层保持FP16其他层用INT8。配置方法是在config里加一个hybrid_quantization参数然后传一个层名列表。混合量化的代价是模型体积增大和推理耗时增加。我试过把ShuffleNetV2的通道重排层保持FP16模型体积从2.3MB涨到3.1MB推理耗时从9.8毫秒涨到11.2毫秒但Top-1精度从66.1%回升到68.3%。如果你的场景对精度敏感且能接受一定的性能损失混合量化是个可行的方案。5.3 量化感知训练在RK3566上的可行性量化感知训练QAT是在训练阶段模拟量化误差让模型提前适应INT8推理。理论上QAT能比PTQ训练后量化获得更好的精度但在RK3566上做QAT有几个现实问题一是RKNN-Toolkit2不直接支持QAT模型的转换需要先用其他工具把QAT模型转成普通ONNX二是QAT的训练成本高需要重新训练整个模型三是QAT后的模型在RKNN上的量化行为可能和训练时模拟的不一致。我试过用PyTorch的QAT工具对MobileNetV2做量化感知训练然后导出ONNX再转RKNN。结果是Top-1精度比PTQ高了0.8个百分点但整个流程多花了两天时间。如果你的项目对精度要求极高且有时间预算可以尝试QAT否则PTQ加混合量化已经够用了。6. 实际部署中遇到的典型问题与解法6.1 模型加载失败与驱动版本不匹配板端加载RKNN模型时最常见的报错是rknn_init fail原因通常是驱动版本和模型版本不匹配。RKNN模型在转换时会记录工具链版本板端运行时库如果版本低于这个版本就会拒绝加载。解决办法是升级板端的运行时库或者用低版本的工具链重新转换。还有一个隐蔽的坑板端如果有多个版本的librknnrt.so加载时可能链接到错误的版本。可以用ldd命令查看程序实际链接的库路径确认是不是你期望的那个。6.2 推理结果与PC端不一致的排查思路有时候模型在PC上用RKNN模拟器跑的结果和板端不一致这通常是量化参数在板端重新计算导致的。RKNN-Toolkit2在转换时会生成量化参数文件板端加载时会用这些参数做反量化。如果板端的量化参数文件和模型不匹配结果就会异常。排查方法是先在PC上用rknn.inference跑一遍保存输入和输出然后在板端用同样的输入跑一遍对比输出差异。如果差异很大检查模型转换时有没有开do_quantization以及板端加载时有没有正确设置data_type。6.3 多模型切换时的内存泄漏问题如果你的应用需要动态切换模型比如根据场景选择不同的分类模型要注意RKNN运行时的内存管理。每次rknn_init都会分配内存如果不在切换时调用rknn_release内存会持续增长最终导致OOM。我的做法是维护一个模型池每个模型只初始化一次切换时只做rknn_inputs_set和rknn_run不重新初始化。这样既能避免内存泄漏又能减少模型加载的耗时。模型池的大小根据板端内存来定1GB内存的板子建议最多同时加载两个模型。6.4 输入数据预处理对推理耗时的影响很多人只关注模型推理的耗时忽略了数据预处理的耗时。在RK3566上把一张1080P的图缩放到224x224用CPU做双线性插值要3到5毫秒用RGA硬件加速只要0.5毫秒。如果你的应用对帧率要求高一定要用RGA做预处理。RGA的使用方法是通过librga库在C代码里调用imresize接口。Python端可以用opencv的cuda模块但RK3566没有CUDA所以还是得走RGA。我实测下来用RGA预处理后整个pipeline的帧率能提升15%左右。7. 模型选型建议与场景匹配7.1 高帧率场景下的模型选择如果你的场景要求30FPS以上比如实时视频分析MobileNetV2和ShuffleNetV2是首选。MobileNetV2的精度更高ShuffleNetV2的速度更快但精度损失大。我一般推荐MobileNetV2因为它在224分辨率下能跑到80FPS留足了余量给预处理和后处理。如果帧率要求更高比如60FPS可以把输入分辨率降到160x160MobileNetV2能跑到140FPS。代价是精度掉2个百分点需要根据业务容忍度来权衡。7.2 高精度场景下的模型选择如果场景对精度要求高比如工业质检EfficientNet-Lite0是更好的选择。它在224分辨率下的Top-1精度比MobileNetV2高3.2个百分点推理耗时只多了6毫秒。如果精度还不够可以上320分辨率精度能到74.5%耗时32毫秒帧率31FPS仍然能满足大部分实时场景。ResNet18在RK3566上有点尴尬精度不如EfficientNet-Lite0速度不如MobileNetV2除非你的模型是从ResNet18微调来的不想换结构否则不建议在RK3566上用ResNet18。7.3 多模型级联的部署策略在实际项目中经常需要多个模型级联比如先用人脸检测模型定位人脸再用分类模型判断性别年龄。这种场景下建议把轻量级模型放在前面做粗筛重量级模型放在后面做精判。RK3566的NPU支持多模型并行但需要合理分配NPU核心。我的做法是把检测模型和分类模型分别绑定到不同的NPU核心通过rknn_set_core_mask来指定。这样两个模型可以同时推理整体吞吐量能提升40%左右。不过要注意NPU核心之间的内存带宽竞争如果两个模型都很大并行效果会打折扣。8. 一些实测数据和经验教训8.1 温度对推理稳定性的影响RK3566在长时间高负载下会发热温度超过80度后NPU会降频推理耗时增加20%到30%。我连续跑了30分钟MobileNetV2推理前10分钟耗时稳定在12.3毫秒15分钟后涨到14.1毫秒25分钟后涨到16.8毫秒。如果你做的是长时间运行的应用一定要加散热片或者风扇。软件层面也可以做温度管理定期读取/sys/class/thermal/thermal_zone0/temp当温度超过阈值时主动降低推理频率或者切换到CPU推理。虽然CPU更慢但至少不会因为降频导致帧率剧烈波动。8.2 不同批次板子的性能差异我手上有三块不同批次的RK3566板子同一模型同一条件下的推理耗时差异在5%以内但NPU的算子支持有细微差别。有一块早期批次的板子不支持HardSwish算子导致EfficientNet-Lite转换失败。后来换了新批次的板子就正常了。所以如果你遇到算子不支持的问题先确认一下板子的批次和固件版本。8.3 模型转换时的日志分析技巧RKNN-Toolkit2在转换时会输出大量日志很多人直接忽略其实日志里有很多有用的信息。比如warning: unsupported op会告诉你哪些算子没被NPU支持quantize error会告诉你哪些层的量化误差大。我一般会把日志重定向到文件然后用grep过滤关键词快速定位问题。如果日志里出现fallback to cpu说明某些层被回退到CPU执行了这会大幅增加推理耗时。解决办法是调整模型结构把不支持的算子替换成等价的受支持算子或者用混合量化把这些层保持FP16。8.4 从ONNX到RKNN的自动化转换脚本手动转换模型很繁琐尤其是要调参的时候。我写了个自动化脚本把模型路径、校准集路径、量化参数都做成配置文件一键完成转换和测试。脚本的核心逻辑是读取配置、初始化RKNN、加载ONNX、构建模型、导出RKNN、在PC上做精度验证。如果精度不达标自动调整量化参数重试。这个脚本帮我省了很多时间尤其是在对比不同量化参数的时候。如果你经常做模型转换建议也搞一个类似的工具。脚本不用太复杂能覆盖你的常用模型就行。