把十几款主流图像分类模型挨个折腾到瑞芯微RK3566芯片上跑一遍绝对不是一个拿着SDK点两下就能交差的活儿。这两年边缘AI项目越来越多RK3566这种把CPU和NPU做在一起的SoC成了很多场景的默认选项尤其是做图像分类、物体识别这类相对标准的功能。但你能搜到的评测大多停留在“支持某某算子”的纸面参数上真正到了量化、转换、板端实测这一步各种意外才刚开始浮出来。这篇文章把我近期在RK3566上做的一组图像分类模型部署实验完整拆开从模型选型、工具链版本、ONNX转换、INT8量化到板端推理耗时、精度掉点和内存稳定性全部用实测数据说话。适合正在评估RK3566做图像分类落地的朋友也适合那些已经被模型转换折磨过一轮、想看看别人是怎么处理类似问题的工程师。说句实在话RK3566的NPU算力摆在那里INT8下大约0.8TOPS跑轻量级网络绰绰有余跑大模型就得精打细算。我这次实验的目标很明确不追求极致精度而是找出在RK3566上“性价比”最高的图像分类模型组合同时把部署链路走通给后续项目留一份可以直接参考的选型清单。1. RK3566平台的基本盘算力有限选择反而更重要1.1 为什么图像分类模型成了边缘端的第一道考题图像分类几乎是所有视觉应用的基础也是边缘端部署最常见、最容易对照的基准任务。RK3566这颗芯片在瑞芯微的产品线里定位中低端四核Cortex-A55 CPU主频2.0GHz左右NPU算力约0.8TOPSINT8内存带宽有限典型场景是智能门禁、工业缺陷检测、边缘盒子这类对功耗和成本敏感的设备。跟高端的RK3588相比它的NPU资源大约只有四分之一到五分之一所以模型稍微大一点就会撞上算力天花板。有意思的是正因为算力紧张恰恰逼着你去认真思考模型架构和部署细节而不是无脑上大模型。我这次实验选了十来个模型覆盖了轻量级CNN、经典残差网络、EfficientNet系列、移动端优化网络甚至还有Vision Transformer结构的小模型目的就是把不同结构在RK3566上的表现拉出来对照看看哪些适合落地、哪些只能停留在理论层面。1.2 实验想回答的三个问题这次实验从立项开始就只围绕三个问题展开没有贪多第一RK3566上哪个图像分类模型的综合性价比最高这里的“性价比”不是简单的帧率而是精度、耗时、模型体积、内存占用四者的加权。第二INT8量化对各个模型精度的影响有多大不同模型对量化的敏感度差异极大有些掉零点几个点有些直接掉三四个点必须实测。第三RKNN工具链对不同训练框架导出的ONNX模型兼容性如何我准备了PyTorch导出的ONNX模型和部分直接以ONNX形式发布的模型转换过程中的算子支持情况也需要逐一记录。这三个问题直接决定了后续项目选型时该往哪个方向走省得每次都用最笨的“全试一遍”的办法。2. 部署环境全记录工具链版本与系统配置最容易翻车2.1 RKNN工具链版本选择与运行时的匹配如果让我只给一条部署建议那就是先确认工具链版本和板端runtime版本严格对应。RKNN-Toolkit2在PC端负责模型转换板端跑推理靠的是librknnrt.so运行时两边的版本不匹配会出现各种诡异问题比如模型加载失败、输出全零、甚至推理直接崩溃。我一开始没有太在意用的PC端rknn-toolkit2 1.5.0板端烧录的系统镜像里runtime却是老版本结果ResNet18转换后上板就是拿不到正常分类结果排查了半天才发现是版本不一致。正确的做法是先查板端系统自带的rknpu驱动和librknnrt版本再倒过来选择PC端工具链版本。RKNN工具链版本升级很快新版本会修正一些算子映射问题但也可能引入兼容性调整。我最后的组合是PC端rknn-toolkit2 1.6.0板端系统镜像自带runtime 1.6.0实测最稳定。2.2 测试数据集与输入预处理约定图像分类模型的输入预处理往往直接影响量化效果和最终精度。RKNN推理前的预处理由用户在板端代码里自行完成一般会在rknn.config里设置mean_values和std_values。这里有个容易踩的坑PyTorch的ImageNet预训练模型通常用mean[0.485,0.456,0.406]和std[0.229,0.224,0.225]但rknn.config里的mean_values和std_values接收的是反归一化之前的值而且顺序是RGB且需要换算成0-255尺度。换算很简单以PyTorch的ImageNet标准为例mean换算为[0.485255, 0.456255, 0.406*255][123.675, 116.28, 103.53]std换算为[58.395, 57.12, 57.375]。不少人在这一步直接填0和1精度掉得莫名其妙还不自知。我在所有模型测试里统一用ImageNet验证集抽出的1000张图输入分辨率统一缩放到224x224确保数据口径一致不然不同模型之间的精度对比就完全失真了。3. 模型转换从ONNX到rknn的转换流程与算子兼容性3.1 转换前的模型结构检查ONNX导出之后不要急着转rknn先做一次模型结构检查。PyTorch导出的ONNX有时会在动静态维度、Resize模式、Slice起始索引这些细节上留下隐患。我的做法是在PC上先用onnxruntime跑一遍小批量数据确认ONNX本身输出正常然后再进入rknn转换流程。这样可以提前排除“源模型就有问题”的干扰项。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_platformrk3566 ) ret rknn.load_onnx(modelmobilenetv2.onnx) ret rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(mobilenetv2.rknn)这里有两个容易被忽略的点target_platform必须写rk3566不能写通用的rk3588或rk3399prodataset.txt里要放一批有代表性的真实图片路径用于量化校准我的经验是放200到500张比较合适太少统计不准太多转换时间成倍增加。3.2 全量量化与混合量化的取舍rknn.build里do_quantizationTrue代表全量量化也会自动启用混合量化策略。对RK3566这种只能高效跑INT8的NPU来说全量量化是必选项。实测下来不同模型对量化的敏感度差异非常大MobileNetV2掉点很少Top-1精度从71.8%掉到71.3%左右但EfficientNetB0掉点明显从77.1%掉到75.9%这让它在部署选型里的优势打了折扣。如果某些层量化后精度下降特别严重可以在rknn.config里通过customize_quantize_layer设置特定层跳过量化换成FP16在CPU上跑。但RK3566的CPU算力又不算强局部FP16会导致整体推理耗时增加不少。我实验下来觉得对图像分类任务而言只要整体掉点控制在1.5%以内全量量化完全够用没必要为了一点精度牺牲帧率。3.3 转换失败的两个模型这次实验里有两个模型在转换阶段就栽了跟头。第一个是ViT-Small它的Transformer结构里有大量复杂的矩阵乘法和LayerNorm算子rknn转换器对部分算子支持不完整虽然勉强转成了rknn但上板后推理耗时超过800毫秒几乎不可用NPU利用率也低得可怜。第二个是ConvNeXt-Tiny它的核心算子GELU和若干DepthwiseConv组合在rknn工具链里吃得很吃力转换过程反复报算子不支持。最终我只能用ONNXsimplifier对图做了优化才勉强编译通过但推理速度依然垫底。这说明一个很现实的问题RK3566的NPU是针对CNN结构优化的Transformer类的模型在这个平台上想高效部署还有很长一段路要走。如果项目里必须用Transformer模型建议优先考虑第三方提供的RKNN专用导出方案或者干脆换芯片平台。4. 板端性能测试实测数据与测试方法背后的坑4.1 性能测试方案必须自己设计别信官方的DemoRKNN官方Demo虽然能跑通但测试精度和速度的口径跟实际部署场景往往不一致。我在板端写了一套独立的Python推理脚本统一使用同一个摄像头图片输入连续推理100帧取平均耗时同时用time.perf_counter记录单帧延迟排除CPU频率调度和缓存冷启动的影响。这里有个关键细节跑第一帧之前先做几次热身推理让NPU驱动和内存缓冲区进入稳定状态否则第一帧耗时会被明显拉高。板端推理核心代码大致长这样import numpy as np from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(mobilenetv2.rknn) rknn_lite.init_runtime() for i in range(10): # 热身 outputs rknn_lite.inference(inputs[img]) t_start time.perf_counter() for i in range(100): # 正式测试 outputs rknn_lite.inference(inputs[img]) t_cost (time.perf_counter() - t_start) / 100 * 1000搞定推理耗时之后别忘了单独统计预处理耗时和后处理耗时。实测中一幅224x224的RGB图像在Python里用OpenCV做resize和归一化就要花掉5到8毫秒这个开销在MobileNetV2那种40毫秒级别的模型上占了大头压缩到C语言实现后能减少到1毫秒以内。所以纯推理时间和端到端时间是两码事做性能评估时一定要分开统计。4.2 各模型实测数据汇总以下表格是我在RK3566开发板、CPU默认调频策略、无外部散热风扇条件下跑出来的实测数据。所有模型均为INT8量化输入224x224x3测试集为ImageNet验证集随机抽样的1000张图片精度数据在PC端用相同图片推理ONNX原模型得到用于对照量化掉点。模型参数量(M)推理耗时(ms)FPSINT8 Top-1精度FP32 Top-1精度量化精度损失NPU利用率MobileNetV23.44223.871.3%71.8%0.5%85%MobileNetV3-Small2.53528.665.9%67.4%1.5%87%MobileNetV3-Large5.47812.873.9%75.2%1.3%90%ShuffleNetV22.34522.268.1%69.4%1.3%82%GhostNet5.26016.772.4%73.8%1.4%84%ResNet1811.71357.468.8%69.7%0.9%93%ResNet5025.63852.674.6%76.1%1.5%95%EfficientNetB05.31208.375.9%77.1%1.2%88%ConvNeXt-Tiny28.65201.980.3%82.1%1.8%91%ViT-Small22.18101.279.8%82.3%2.5%低从表里能直接读出几件事一MobileNetV3-Small虽然最快但精度崩得太厉害只有65.9%这对大多数分类任务来说太勉强了二ResNet50精度足够但速度太慢单路实时视频流都带不动三EfficientNetB0在速度和精度的平衡上其实相当不错但量化后掉点相对明显四ViT-Small这种结构在RK3566上就是灾难NPU利用率低导致的功耗和耗时双双爆炸。4.3 精度对比与量化掉点分析量化掉点这件事不能只看平均值要逐模型看。MobileNetV2只掉了0.5%主要因为它的深度可分离卷积结构对数值范围变化比较鲁棒ResNet18掉点0.9%也可接受MobileNetV3系列和EfficientNet掉点都在1.2%以上原因是通道注意力机制里的全局平均池化和激活函数在INT8低比特表示下信息损失比较明显。让我比较意外的是ViT-SmallFP32精度其实很高但INT8量化后掉到79.8%掉了2.5个百分点。Transformer的自注意力打分对数值精度非常敏感这个结论也和我之前在别的NPU上测到的规律一致。所以如果遇到精度敏感场景优先考虑CNN结构不要因为Transformer的FP32精度高就冲动选择。5. 数据解读为什么算力小的板子不能只看FPS5.1 带宽与预处理开销往往比算力更致命RK3566的NPU算力看着只有0.8TOPS但实际部署中更早撞墙的往往是内存带宽和CPU预处理能力。以ResNet50为例385毫秒的推理耗时里纯NPU计算时间大约320毫秒剩下的65毫秒浪费在输入输出张量的内存拷贝和NPU等待CPU填充数据上。这是我在测试时打时间戳拆出来的结果不拆不知道一拆吓一跳。换到轻量模型的时候带宽瓶颈更加明显。MobileNetV2理论计算量本身不大但逐层卷积的输出都要写回DDR再读出来给下一层DDR带宽很快就饱和了。这也是为什么MobileNetV2在RK3566上跑不出纸面计算量对应的帧率。想优化的话可以把输入图片分辨率从224降到192或160感受一下带宽压力的变化但分类精度会跟着掉一些需要自己权衡。5.2 模型结构对NPU友好度的差异不同网络结构在RK3566上的NPU利用率差距很大。ResNet18和ResNet50的NPU利用率在93%和95%原因是标准3x3卷积在NPU里映射得特别顺畅而ShuffleNetV2和GhostNet的利用率只有82%到84%因为Channel Shuffle和GhostModule里的大量轻量操作会产生较多小算子在NPU上调度开销偏高经常出现“喂不饱”的情况。MobileNetV2的深度可分离卷积在RK3566上的利用率能达到85%但相比ResNet的3x3标准卷积还是有差距。实际部署选型时一个模型的FLOPs低并不等于在NPU上跑得快必须用实测说话。我的判断标准是先看每毫秒能蹭到多少“有效算力”再看这个模型的精度值不值这个时间成本。5.3 结合场景的模型选择建议根据这批数据我把模型分成三档推荐。第一档是MobileNetV2推理42毫秒精度71.3%工程量小转换最顺适合对速度有要求、分类精度够用就行的项目。第二档是EfficientNetB0推理120毫秒精度75.9%适合对精度有要求、又能容忍10FPS以下速度的项目比如工业缺陷分类虽然实时性一般但准确率更有保障。第三档是ResNet50推理385毫秒精度74.6%只在离线批量处理任务里才值得考虑。至于MobileNetV3-Small虽然帧率最高但精度损失后只有65.9%除非分类任务特别简单不然不建议。ViT-Small和ConvNeXt-Tiny这类新结构模型在RK3566上现阶段就是“能跑但不好用”的典型除非你愿意为了它们放弃大概率的实时性。6. 部署踩坑实录推理耗时波动、内存占用和稳定性问题6.1 推理耗时忽高忽低元凶是CPU调频和NPU抢占第一批测试结果出来的时候MobileNetV2单帧耗时在42毫秒上下跳动最差的一次跑到了60毫秒。排查了一圈发现两个原因一是板子的CPU调频策略对负载响应有滞后推理脚本跑起来CPU占用起伏导致某些帧预处理变慢二是系统日志进程时不时抢CPU。解决办法是把CPU调到性能模式并给推理进程绑定一个专用CPU核心。在RK3566上设置性能模式很简单直接操作sysfs节点就行但要注意改完之后的功耗和发热。绑定CPU核心我用的是taskset配合cgroup限制实测耗时波动从最高60毫秒降到了42毫秒到45毫秒之间稳定了很多。6.2 多模型切换时的内存碎片与耗时剧增我的实验脚本要逐个模型加载测试最开始每测一个模型就重新启动Python进程内存状态很干净。后来想优化流程改成同一个进程里连续加载和释放多个rknn模型结果出现了一个非常典型的问题每次切换模型后第一次推理耗时都会异常高后续逐步恢复。查了RKNNLite的初始化机制推测是NPU上下文重新创建时要把模型重新加载进DDR加上内存碎片导致缓冲区反复重新分配。这个问题没有彻底消除的捷径只能尽量复用同一个runtime上下文或者接受“切换模型后第一次推理偏慢”的现实。如果要跑多模型实时切换建议初始化时把几个模型一次性加载进来轮询推理时根据输入切换不同句柄而不是反复加载释放。6.3 长时间运行的稳定性与掉电保护连续跑了两三个小时后居然出现了两次模型推理返回空结果的异常检查发现是系统内存逐渐被日志缓存占用导致NPU缓冲区分配失败。这个问题在处理小容量开发板时特别容易被忽略我的对策是写一个简单的内存巡检脚本当系统可用内存低于某个阈值时主动清理缓存。另外如果做的是无人值守的设备建议把推理程序注册成系统服务并在启动脚本里加上掉电重启后的自恢复逻辑。RK3566这类开发板在工业环境中供电并不总是稳定我自己就遇到过运行中突然断电导致rknn模型文件损坏的情况重新生成模型才恢复。量产项目里一定要考虑文件系统的写保护和对rknn模型做校验避免断电损坏后无人处理。7. 对实验结果的深度解读与后续部署建议7.1 为什么小模型不一定更快一般人的直觉是参数量越少跑得越快但在RK3566上这个直觉不总是成立。ShuffleNetV2只有2.3M参数推理耗时45毫秒反而比同样2.5M的MobileNetV3-Small慢了10毫秒。原因在于小模型不一定能充分利用NPU的并行度算子间的调度开销和内存访问占比更高。所以选型还是要回归到平台实测。7.2 一份可以直接抄的落地清单基于这次实验我总结了一份RK3566图像分类模型落地清单给后续项目直接用首推MobileNetV2综合风险最低追求精度就上EfficientNetB0但要在预处理上多花功夫补偿量化损失工业场景里如果对精度要求高且帧率不敏感可以选EfficientNetB0配合小幅输入分辨率提升所有模型上线前必须做至少24小时的连续跑测确认没有内存泄漏和异常耗时波动。如果让我重新做一次这个实验我会在第一轮就先把系统环境、工具链版本和预处理口径固定死把时间更多花在模型结构优化上而不是在排查版本兼容性和量化细节上反复折腾。RK3566这个平台上限不低但下限也很残忍模型选对了能稳稳跑起来选错了就是无底洞。