1. 实验背景与方案设计1.1 RK3568这颗芯片到底适合跑什么RK3568 是这两年在边缘视觉项目里出镜率很高的一颗 SoC四核 A55 的 CPU 算通用任务不算强但它内置了一个 NPU最典型的用途就是把图像分类这类算子密集的活接过去。标称 INT8 算力大概在 1 TOPS 级别光看数字会觉得有点弱但实际配合 MobileNetV3 这种轻量模型跑个二三十帧是没问题的做门禁、抓拍、质检、智能盒子的候选绰绰有余。真正让人头疼的问题是主流图像分类模型那么多到底哪个量化后能保住精度哪个在 NPU 上真正跑得快只看理论 FLOPs 根本判断不了。所以我花了一周多时间做了一次系统的部署实验把 MobileNet 系列、ShuffleNetV2、ResNet、EfficientNet 和一个轻量 Transformer 类型的代表模型挨个在 RK3568 上过了一遍记录从模型转换、INT8 量化到板端推理的完整数据。这篇文章就是这次实验的记录和分析目标读者是准备在 RK3568 或者类似边缘平台上做算法部署的开发者。如果你正在模型选型阶段或者已经遇到量化掉精度、算子不支持、帧率上不去这些问题这篇文章应该能帮你节省至少两天试错时间。需要先说明一点所有数据都来自我手头这块板子和当时的驱动版本不同板卡、不同 RKNN 工具链版本跑出来的绝对数值会有偏差但模型之间的相对趋势是稳定可靠的值得参考。1.2 参测模型清单与选择理由我选的模型不是随便凑数的而是按照边缘部署的典型诉求分成几个梯队模型类型参数量选型理由MobileNetV3-Small轻量 CNN约 2.5M低算力平台的常青树部署首选候选MobileNetV3-Large轻量 CNN约 5.4M对比 Small 看容量换精度的性价比ShuffleNetV2 1.0x轻量 CNN约 2.3M通道重排策略在 NPU 上的兼容性值得验证ResNet18中量 CNN约 11.7M精度基线代表经典中的经典ResNet50中量 CNN约 25.6M中量级模型在 RK3568 上的极限测试EfficientNet-B0均衡缩放 CNN约 5.3M复合缩放策略在部署链路上的兼容性验证MobileViT-XXSCNNTransformer约 1.3M轻量 Transformer 在低算力 NPU 上的真实表现选这些模型有一个很重要的原因不能只看算力指标来判断部署效果。ResNet50 的 FLOPs 是 MobileNetV3 的二十倍左右但 NPU 上跑起来并不是严格的二十倍耗时算子映射、内存访问模式、量化敏感度都会带来差异。尤其是 MobileViT 这种含 attention 的结构理论 FLOPs 不高实际在 NPU 上的算子拆解可能非常吃亏。这批模型恰好覆盖了极轻量、经典中量、新架构三种类型用来做横向对比信息量足够大。模型权重统一用标准 ImageNet 预训练权重不做任何微调或结构修改保证变量只有模型本身。所有模型输入分辨率统一设 224x224这个也是后面部署时最容易踩坑的地方很多人在 PC 上测试用一个分辨率转 RKNN 后又换了预处理精度直接就崩了。1.3 实验评测维度与指标口径这次实验不只测一个帧率而是从四个维度记录每个模型的表现转换成功率ONNX 能否顺利转为 RKNN转换过程有没有算子告警这些告警是否影响 NPU 加速。精度损失以标准分类验证集子集为基准对比 FP32 模型和 INT8 量化后 RKNN 模型的 Top-1 准确率差。推理耗时与帧率分别测 NPU 单模型推理和纯 CPU 多线程推理两种模式记录第 50 百分位和 95 百分位耗时。内存占用记录模型加载后进程物理内存增量这个指标直接影响能否跑在带内存上限的设备上。之所以定义成这样是因为每个指标都对应一个实际场景问题转换失败说明这个模型根本没法用精度掉太多说明不敢上生产帧率不够说明没法做实时视频流内存超了说明只能降分辨率或者换模型。我在实验中也重点记录了 CPU-only 的表现很多项目会把 NPU 推理作为主力但同时需要一个纯 CPU 兜底路径这个数据在平时文档里很少能看到。2. 从 ONNX 到 RKNN 的转换链路搭建2.1 工具链准备与版本选择RKNN 的转换工具是 RKNN-Toolkit2在 PC 上完成模型转换和量化模拟生成的 .rknn 文件再放到板子上用 RKNNLite 或 C API 加载推理。建议用 Python 虚拟环境安装避免把系统环境搞乱。版本方面我当时用的是当时相对稳定的版本现在建议直接选官方最新的稳定版老版本对 EfficientNet 这类复合缩放模型的算子支持问题比较多。安装环境的基本步骤创建独立虚拟环境Python 版本按工具链要求来一般 3.8 到 3.10 都比较稳。安装 rknn-toolkit2 及其依赖安装后先做一个导入验证。验证环境是否可用能正常导入说明 PC 端转换环境就绪。板端部署时还需要把对应的 rknn-toolkit-lite2 安装到开发板的 Python 环境里。这里有个常见混淆PC 上装的是完整版用于转换和仿真板子上装的是精简版只负责加载和推理两者不能混用。我第一次弄的时候就装反了板子上怎么 import 都失败排查半天发现装成了完整版但依赖不齐反而比精简版更麻烦。2.2 ONNX 导出与图精简模型转换的入口文件最好是 ONNX 格式PyTorch 导出时有两个细节直接影响后续 RKNN 转换成功率第一opset 版本不要追求最新设 11 或 12 比较稳妥。新版 opset 会引入一些高级算子RKNN 解析器不一定认识反而导致转换失败。第二导出后用 onnxsim 做一轮图精简。很多 PyTorch 导出的 ONNX 图里会残留大量 Identity、冗余 Reshape 节点这些节点在 RKNN 构建时会增加解析负担偶尔还会触发形状推断错误。onnxsim 跑一遍通常能消除大部分冗余转换成功率和速度都会有明显提升。PyTorch 侧导出代码大概是这样的import torch model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model.onnx, opset_version12, input_names[input], output_names[output], do_constant_foldingTrue )导出之后建议先用 onnxruntime 跑一遍确认 ONNX 本身没问题再进入 RKNN 转换否则后面出了问题很难定位是模型结构问题还是转换链路问题。2.3 转换配置与 INT8 量化关键点RKNN 转换的核心代码看起来很简单但参数里面的坑特别多。下面是一个标准的转换流程from rknn.api import RKNN rknn RKNN() # 关键点mean/std 必须与训练时一致 rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrk3568, ) rknn.load_onnx(modelmodel.onnx) rknn.build(do_quantizationTrue, datasetcalib_dataset.txt) rknn.export_rknn(model.rknn)三个参数值得重点说mean_values 和 std_values必须和模型训练时的归一化方式保持一致。如果训练时用的是 [0,1] 归一化而这里配了 ImageNet 标准 mean/std精度会直接崩。这个错误我见过很多次症状是量化后 Top-1 比随机猜好不了多少排查半天发现就是归一化写错了。dataset 文件每行一个量化校准图片的路径推荐 200 到 500 张。校准图要尽量覆盖各个类别、各种光照条件不能随手传 10 张白底图。校准集质量直接影响量化后的精度表现这个在后面 MobileViT 的实例中会看到差异有多大。target_platform这里必须指定为 rk3568不能写通用平台或 rk3588不同芯片的 NPU 指令集和算子支持范围有差异写错可能导致部分算子没有利用 NPU 加速。转换完成后建议在 PC 端立刻用模型的模拟推理功能跑几张测试图和 ONNX Runtime 的结果做交叉验证确认输出类别一致再往板子上搬。2.4 精度验证量化后到底掉了多少量化精度的验证我分了两层做第一层是 PC 端模拟用 RKNN 在 PC 上跑量化后的模型对比推理结果和 ONNX Runtime 的余弦相似度以及 Top-1 一致率第二层是板端实测把 .rknn 文件部署到开发板上用同样的测试图集再跑一遍。测试图集我用了 1000 张从标准分类验证集里抽出的图片分布大致均匀。每张图分别记录三个结果ONNX FP32 的预测类别、RKNN INT8 模拟的预测类别、板端 RKNNLite 的预测类别。最后统计 RKNN 相对 FP32 的 Top-1 准确率变化。这样做能同时验证三件事转换本身有没有问题、量化有没有明显掉点、板端和 PC 端行为是否一致。实测下来 PC 模拟和板端结果基本一致差距主要来自芯片温度导致的微小数值抖动类别层面几乎没有差异。3. 板端部署实现与性能采集3.1 推理主流程与核心代码板端我用的是 RKNNLite 的 Python 接口方便快速验证。加载模型之后推理主流程非常简洁但有几个细节直接影响性能和正确性from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(model.rknn) # core_mask 控制 NPU 核心使用策略 rknn_lite.init_runtime(core_maskRKNNLite.NPU_CORE_AUTO) # 图像预处理保证与量化配置的 mean/std 一致 img cv2.imread(test.jpg) img cv2.resize(img, (224, 224)) # 不需要手动归一化RKNN config 里已经配置了 outputs rknn_lite.inference(inputs[img]) pred outputs[0].reshape(-1).argmax()这里有两个容易出错的点第一输入图片的格式。OpenCV 读出来是 BGR 顺序而训练时很多模型用的是 RGB。RKNN 配置里 mean/std 是按 RGB 计算的如果直接扔 BGR 图进去相当于通道顺序反了精度会莫名下降但又不是完全不可用很容易让人误以为是量化问题。稳妥做法是先把 BGR 转成 RGB 再送入推理或者确认训练时用的就是 BGR 输入。第二init_runtime 的 core_mask 参数。RK3568 的 NPU 有多个核心AUTO 模式会自动分配负载。性能测试时建议固定调用方式否则两次测试可能走了不同调度策略数据会不稳定。实际项目里用 AUTO 一般就是最优解不需要手动指定单核。3.2 测速方法避开常见的性能测试误区帧率测试看起来简单实际是最容易测出假数据的一环。很多人拿官方 demo 里的单次推理时间当性能指标这个数字会被首次加载、缓存未命中、CPU 变频等因素严重影响偏差可以到一倍以上。我这次的测速方法如下先跑 10 次预热让模型权重加载、NPU 调度、内存分配都稳定下来。正式循环 100 次对同一张预处理好的图片反复推理记录每次耗时。统计第 50 百分位和 95 百分位耗时同时记录平均值。单片测试期间关闭后台负载固定 CPU 调频策略或者至少监控频率避免变频造成误差。另外还有一个细节输入张量复用。默认调用 inference 时每次都会做输入数据拷贝和内存分配测试时可以提前把输入数据准备好循环内只更新数据内容减少 IO 干扰。实测下来这个操作能带来几个毫秒的差异在算帧率时不可忽略。3.3 性能实测汇总与分析下面是我这次实验记录到的核心数据所有模型输入统一 224x224INT8 量化NPU 模式为 AUTO 调度模型量化方式NPU 平均耗时 (ms)实测帧率 (FPS)Top-1 相对损失MobileNetV3-SmallINT835280.6%MobileNetV3-LargeINT848210.8%ShuffleNetV2 1.0xINT832310.5%ResNet18INT855181.0%ResNet50INT814571.3%EfficientNet-B0INT878131.5%MobileViT-XXSINT895101.8%纯 CPU 多线程模式也全部测了一遍印象最深的是 MobileNetV3-Small 大约 120msResNet50 直接到了 700ms 以上。这说明 CPU 兜底路径虽然可用但实时性基本别想只能做小批量或非实时任务。从数据里能看出几个有意思的结论。ShuffleNetV2 反而是帧率最高的这和理论 FLOPs 排名并不完全一致因为它在 NPU 上的算子映射比较干净没有太多奇奇怪怪的激活函数和 reshuffle 开销。MobileViT-XXS 的账面 FLOPs 很低但 NPU 上只有 10 FPS 左右最主要原因是 attention 部分的 reshape、transpose、softmax 这些操作在 NPU 上会被拆成多个算子每一层都有额外内存搬运实际执行效率远不如 CNN 的卷积算子那么整齐。EfficientNet-B0 的情况类似它的 Swish 激活在 RKNN 里不是原生算子部分层落到 CPU 执行把整体耗时拉高了。4. 部署中的典型问题与排查实录4.1 ONNX 转 RKNN 失败算子兼容的坑转换阶段遇到的第一类问题就是算子不支持或部分算子落 CPU。比如 EfficientNet 里的 Swish 激活函数在部分 RKNN 版本中被标记为非 NPU 算子转换虽然能通过但推理时这部分会默默跑到 CPU 上帧率直接少一半。这类问题排查思路比较固定转换时开启更详细的日志输出RKNN 构建日志里会明确提示哪些节点被分配到 CPU。用 onnxsim 精简图把多余节点清理掉有时候问题就消失了。如果确认为特定算子不兼容尝试替换成等价结构比如把 Swish 换成 ReLU6 或带固定系数的近似版本重新导出 ONNX。MobileViT 转换时还遇到过一个情况它内部的 attention 使用了大量动态 shape 操作RKNN 静态图推理无法处理这类动态维度。我的处理方式是把输入分辨率固定为 224x224并且在导出 ONNX 时用固定尺寸的 dummy input避免动态轴进入 RKNN 解析环节。4.2 量化精度损失的根因与处理量化掉精度是部署流程里最烦人的问题我这次也专门做了控制变量实验。第一个典型案例是 MobileViT-XXS第一次转换时为了省事只准备了 10 张校准图量化后 Top-1 直接掉了 8.7%几乎不能用了。后来把校准集扩充到 300 张覆盖不同类别和光照掉点降到了 1.8%虽然还是比纯 CNN 模型高但已经处于可接受范围。第二个典型案例是归一化参数不一致。ONNX 导出时用了 ImageNet 的 mean/std但 RKNN config 里我填写的是 [0,1] 归一化结果 FP32 模拟就出现精度崩坏根本到不了量化那一步。检查方式很简单拉出转换后的模型跑同一张图对比 ONNX Runtime 的输出向量余弦相似度如果相似度低于 0.9先检查输入预处理而不是模型结构。第三个情况是敏感算子导致的精度损失主要出现在 MobileViT 的 attention 和 EfficientNet 的某些深度可分离卷积层。这类问题可以通过混合量化缓解对敏感层单独配置量化策略但 RK3568 的 NPU 对混合精度的支持不像高端芯片那么灵活操作空间有限。我最后的妥协方案是优先保精度换用 MobileNetV3-Large它在这个平台上的量化表现明显更稳。4.3 模型跑不快算子落到 CPU 的排查性能问题的第一排查目标永远是看看哪些层没走 NPU。RKNN 的构建日志里会输出每层算子执行的硬件信息常见标志是CPU或NPU字样。如果日志里 CPU 节点过多实际推理速度就一定上不去。我遇到过两个具体案例。一个是 EfficientNet-B0 的 Swish 问题如前所述日志里能看到大量 CPU 节点另一个是 MobileViT 的 softmax 和 reshape 链整个 attention 块几乎都落到 CPU 上执行。前者我把激活函数替换后重测帧率从 9 提升到 13后者结构替代比较困难只能接受它的性能现状或者换模型。还有一个容易忽略的问题内存拷贝。RKNN 推理时如果每次输入都用 numpy 数组直接传会触发额外的数据拷贝操作。如果对帧率极其敏感建议用 C API 或者 RKNNLite 的输入输出复用接口减少 Python 层的数据搬运开销。我实验里 Python 接口对比 C 接口在 MobileNetV3-Small 上有大约 5% 的耗时差距不算大但积少成多。4.4 内存占用异常与推理稳定性内存问题在测试前期没引起我注意后来连续加载不同模型时发现进程物理内存一路走高。排查了半天才找到根因release()没有正确调用以及每次init_runtime()都会重新分配缓冲。在实时任务里频繁反复初始化运行时环境非常不划算正确做法是加载一次模型初始化一次运行时然后不断复用同一个实例做推理直到进程退出前再统一释放。另外补充一点RKNNLite 多次推理后内存小幅上涨是正常现象只要不是持续线性增长就不用太紧张。如果出现不断上涨优先怀疑输入输出张量没有复用每次 inference 都重新创建了大型缓冲Python 层的垃圾回收又不及时内存自然越堆越高。4.5 问题速查表为了便于后续回顾我把这段时间遇到的典型问题整理成一张表问题现象可能原因排查建议转换失败提示算子不支持opset 版本过高 / 特定算子未映射降 opset 到 11-12替换不兼容激活函数转换成功但帧率很低部分算子落到 CPU 执行在 build 日志中搜 CPU 节点逐个替换量化后精度剧烈下降校准集过少 / mean-std 错误扩充校准集到 200 张以上核对训练归一化参数推理结果类别完全不对通道顺序错误 / 输入尺寸与训练不一致检查 BGR-RGB 转换确认 resize 与训练保持一致内存持续增长未释放模型 / 未复用输入输出缓冲正确调用 release复用同一运行时实例首次推理耗时异常高缓存未预热 / NPU 调度未就绪用 10 次循环预热后再统计耗时5. 模型选型建议与优化扩展5.1 从实验数据能得出什么结论这次实验跑完对于 RK3568 上的图像分类模型选型我心里基本有一个明确的优先级顺序。优先选型梯队MobileNetV3-Small 和 ShuffleNetV2 是闭眼可选的组合。量化掉点都控制在 1% 以内帧率在 28 到 31 FPS内存占用也不高对实时视频流场景非常友好。如果后续产品迭代不频繁直接在这两个里选一个作为主模型就行。精度兜底梯队ResNet18 是精度和速度的一个平衡点18 FPS 虽然不算高但分类精度比轻量模型稳很多。ResNet50 在这个平台上已经不太适合做实时推理了7 FPS 只能用在非实时批处理场景或者配合其他加速手段使用。谨慎使用梯队MobileViT-XXS 和 EfficientNet-B0 不是不能用但需要额外投入调优成本。MobileViT 的量化敏感度和算子落 CPU 问题是硬伤EfficientNet 的激活函数替换会略微影响精度。除非你的项目有专人维护部署链路否则不建议作为首发方案。5.2 后续扩展方向与最终建议如果时间允许我接下来的优化方向有两件事。第一对 MobileViT 这类量化敏感模型做混合量化尝试敏感算子走更高精度其余层继续 INT8虽然 RK3568 对混合精度支持有限但值得验证。第二尝试输入分辨率降到 160 或 192同时配合模型微调而不是直接拿 224 的模型降分辨率部署。直接降分辨率会让小目标识别能力明显下降微调一下能补回来不少。从这次实验的经验来看我给大家的核心建议是在 RK3568 上做图像分类部署不要先纠结模型多先进先跑通一个 MobileNetV3-Small 加 300 张校准图的 INT8 量化链路再用实际数据决定要不要升级模型。整个过程最难的不是框架配置而是理解每个环节的变量——归一化、校准集、算子落 CPU、内存复用——这些在我刚接触的时候都以为是框架自动处理的事实际踩过坑才知道RK3568 的 NPU 虽然方便但每一个细节都值得亲手确认一遍。后续真要继续往深了做我会先把这次记录的四类排查经验固化成团队内部的部署检查清单再针对具体项目的类别分布做数据增强和量化校准到时候再写一篇实际的落地复盘出来。
