1. 为什么要在 RK3568 上折腾图像分类模型部署RK3568 这颗芯片在边缘计算圈子里火了好几年四核 A55 加一颗 0.8 TOPS 的 NPU价格压得很低功耗也友好做工业质检、智能门禁、零售货架分析这类场景的兄弟基本都绕不开它。但真要把图像分类模型塞进去跑起来事情远没有规格书写的那么轻松——算力账要算清楚量化精度会掉算子支持有坑前后处理还得自己写。我前后在 RK3568 上部署过 ResNet、MobileNet、EfficientNet、ViT 这几类主流分类模型踩的坑足够写一本小册子这篇就把整个实验过程和结论摊开来讲。先说清楚这篇文章适合谁看。如果你手里已经有一块 RK3568 开发板想跑图像分类但不知道从哪下手或者你已经跑通了官方 demo但换成自己的模型就各种报错再或者你在选型阶段想知道这颗 NPU 到底能扛多大的模型、精度损失能不能接受——那这篇内容基本能覆盖你的需求。我会从模型选型、量化转换、板端部署、性能实测到问题排查一条线走完参数和命令都给到能直接抄的程度。需要提前说明的是RK3568 的 NPU 是瑞芯微自研的 RKNN 架构它不像 GPU 那样通用算子支持是白名单制。这意味着你不能指望 PyTorch 里能跑的模型直接转过去就能跑中间必须经过 RKNN-Toolkit2 做量化转换而且转换过程中会遇到算子不支持、量化掉点、输入输出对不齐等一系列问题。理解这一点后面的很多现象就都能解释了。2. 实验环境与模型选型的前期准备2.1 硬件与软件环境清单先把环境交代清楚不然后面复现的时候对不上。硬件这边我用的是 RK3568 开发板4GB 内存版本NPU 驱动版本 0.8.2系统是 Buildroot 加 Linux 5.10 内核。PC 端用的是 Ubuntu 20.04Python 3.8RKNN-Toolkit2 版本 1.5.2。这里要特别注意版本匹配问题RKNN-Toolkit2 的版本和板端 runtime 版本必须对应否则会出现模型加载失败或者推理结果异常的情况这个坑我在后面问题排查章节会详细讲。项目配置开发板RK35684GB LPDDR4NPU 算力0.8 TOPSINT8板端系统Buildroot Linux 5.10NPU 驱动0.8.2PC 系统Ubuntu 20.04Python3.8RKNN-Toolkit21.5.2推理框架RKNN Runtime软件安装这块RKNN-Toolkit2 建议用 conda 建独立环境因为它对 numpy、onnx 这些依赖的版本卡得比较死。我试过直接在系统 Python 里装结果和已有的 torch 环境冲突折腾了半天。用 conda 隔离是最省事的做法conda create -n rknn python3.8 conda activate rknn pip install rknn-toolkit21.5.2 pip install onnx1.12.0 pip install torch1.13.0 torchvision0.14.0注意RKNN-Toolkit2 只支持 x86 的 Linux 环境做模型转换Windows 和 Mac 都不行。如果你主力机是 Windows老老实实装个 Ubuntu 虚拟机或者双系统别在这上面浪费时间。2.2 图像分类模型的选型逻辑图像分类模型这几年迭代很快从最早的 AlexNet、VGG到 ResNet 残差结构再到 MobileNet 的深度可分离卷积以及后来 EfficientNet 的复合缩放最后到 ViT 把 Transformer 搬进视觉领域。但在 RK3568 这种边缘 NPU 上选型逻辑和服务器端完全不一样核心就三条算子兼容性、参数量、量化友好度。ResNet 系列是绕不开的基准ResNet18 参数量 11M 左右结构规整全是标准卷积和残差连接RKNN 对它的支持非常成熟基本是拿来就能转。MobileNetV2 用了深度可分离卷积和倒残差结构参数量只有 3.4M算力需求低是边缘部署的常客但它的 ReLU6 激活和某些版本的实现方式在量化时容易出问题。EfficientNet 用了 Swish 激活函数这个激活在 RKNN 上的支持一直不太稳定需要替换成 ReLU 或者 HardSwish 才能顺利转换。ViT 这类 Transformer 模型算子复杂包含大量矩阵乘和 LayerNormRK3568 的 NPU 对 LayerNorm 支持有限实测下来要么转不过去要么性能惨不忍睹。所以这次实验我选了四个有代表性的模型ResNet18、MobileNetV2、EfficientNet-B0、ViT-Base。前三个是 CNN 路线的典型代表ViT 用来验证 Transformer 在边缘 NPU 上的可行性边界。每个模型都用 ImageNet 预训练权重输入尺寸统一到 224x224这样对比才公平。2.3 数据集与评估指标评估用的数据集是 ImageNet 验证集的子集取了 1000 张图覆盖 100 个类别每类 10 张。用子集而不是全集主要是为了在板端跑推理的时候节省时间毕竟板子跑一次全量验证集要几个小时。评估指标除了 Top-1 和 Top-5 准确率还重点看量化前后的精度损失、单帧推理延迟、内存占用和 NPU 利用率。精度损失这个指标特别关键。FP32 模型在 PC 上跑出来的准确率是基准转成 INT8 量化模型后准确率会掉掉多少直接决定了这个模型能不能用。一般来说掉 1% 以内算优秀1% 到 3% 可以接受超过 3% 就要考虑是不是量化策略有问题或者这个模型本身就不适合 INT8。延迟方面RK3568 的 NPU 单次推理时间在几十毫秒量级具体取决于模型复杂度这个数据直接决定了你的应用能不能做到实时。3. 模型转换与量化实操全流程3.1 从 PyTorch 到 ONNX 的导出细节RKNN-Toolkit2 支持从 ONNX、TensorFlow、Caffe 等多种格式导入但实际用下来 ONNX 是最稳的路径。PyTorch 模型导出 ONNX 看着简单一行 torch.onnx.export 就完事但里面的坑不少。首先是 opset 版本RKNN-Toolkit2 1.5.2 对 opset 11 和 12 支持最好用太新的版本会碰到不支持的算子。其次是动态轴的问题导出的时候一定要把 batch 维度固定住RK3568 的 NPU 不支持动态 batch你导出成 dynamic 的话转换阶段就会报错。以 ResNet18 为例导出命令是这样的import torch import torchvision.models as models model models.resnet18(pretrainedTrue) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, resnet18.onnx, opset_version11, input_names[input], output_names[output], do_constant_foldingTrue )导出完成后强烈建议用 onnxsim 做一次简化把冗余的算子合并掉这样转换出来的 RKNN 模型会更干净推理效率也更高pip install onnxsim onnxsim resnet18.onnx resnet18_sim.onnx实操心得导出 ONNX 之后一定要用 Netron 打开看一眼确认输入输出的名字、维度、数据类型都对。我遇到过好几次因为输出节点名字不对导致后面 RKNN 转换时找不到输出层的情况排查起来很费时间。3.2 RKNN 量化转换的关键参数ONNX 准备好之后就进入 RKNN 转换环节。这一步是整个流程里最核心也最容易出问题的部分。转换脚本的基本结构是创建 RKNN 对象、配置参数、加载 ONNX、构建模型、导出 RKNN。配置参数里最重要的是量化方式和量化数据集。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_platformrk3568, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) rknn.load_onnx(modelresnet18_sim.onnx) rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(resnet18.rknn)这里的 mean 和 std 要和训练时的预处理保持一致不然精度会莫名其妙地掉。quantized_dtype 选 asymmetric_quantized-8 是 INT8 非对称量化这是 RK3568 上精度和性能平衡最好的选择。optimization_level 设成 3 会做更激进的图优化但偶尔会引入精度问题如果发现掉点严重可以降到 2 试试。量化数据集dataset.txt里放的是校准图片的路径一般准备 100 到 200 张有代表性的图就够了。这些图要覆盖你实际应用场景的分布比如你做工业质检校准集里就应该是工业零件图而不是随便拿 ImageNet 的图凑数。校准集选得好量化精度能提升不少这是很多人忽略的一点。3.3 量化精度损失的实测对比四个模型转换完成后我在 PC 端用 RKNN-Toolkit2 的仿真功能先跑了一遍精度对比结果如下模型FP32 Top-1INT8 Top-1精度损失转换耗时ResNet1869.8%69.1%0.7%约 3 分钟MobileNetV271.9%70.2%1.7%约 2 分钟EfficientNet-B077.1%73.5%3.6%约 5 分钟ViT-Base81.1%转换失败--ResNet18 的表现最好精度只掉了 0.7%这符合预期因为它的结构最规整量化友好。MobileNetV2 掉了 1.7%主要问题出在深度可分离卷积的逐通道量化上不同通道的数值分布差异大统一量化会损失精度。EfficientNet-B0 掉了 3.6%这个损失就比较肉疼了原因是 Swish 激活被替换成了 ReLU模型表达能力下降。ViT-Base 直接转换失败报的是 LayerNorm 算子不支持这个后面单独说。注意仿真精度和板端实际精度会有细微差异一般板端会比仿真再低 0.2% 到 0.5%因为板端涉及实际的定点运算。所以仿真阶段精度损失超过 3% 的模型板端基本就没法用了。4. 板端部署与性能实测4.1 交叉编译与板端环境搭建模型转好了接下来要把它放到板子上跑。RK3568 的板端推理用的是 RKNN RuntimeC 接口的 API。你需要把 RKNN Runtime 的库和头文件交叉编译进你的应用程序。交叉编译工具链用瑞芯微官方提供的 GCC 版本在 SDK 里能找到。编译的时候链接 librknnrt.so这个库在板端的 /usr/lib 目录下。板端环境搭建的第一步是确认 NPU 驱动正常加载。用 dmesg 看内核日志应该能看到 rknpu 相关的初始化信息。然后检查 /dev/rknpu 设备节点是否存在这个节点是应用程序和 NPU 通信的入口。如果这个节点不存在说明驱动没加载成功需要检查设备树里 NPU 节点的配置。dmesg | grep -i rknpu ls -l /dev/rknpu cat /sys/kernel/debug/rknpu/version实操心得板端跑推理之前先用 rknn_server 跑一遍官方提供的 demo 模型确认整个链路是通的。我遇到过好几次自己写的程序跑不通结果发现是板端 runtime 版本和转换工具版本不匹配用官方 demo 一测就暴露出来了。4.2 推理程序的编写要点板端推理程序的核心流程是加载 RKNN 模型、初始化 runtime、设置输入、执行推理、获取输出。C 接口的调用逻辑比较固定但有几个细节容易出错。首先是输入数据的格式RKNN 模型期望的是 NHWC 排列的 uint8 数据而 OpenCV 读出来的图是 BGR 排列需要先转成 RGB 再调整通道顺序。其次是归一化如果你在转换时配置了 mean 和 std板端就不需要再做归一化直接把原始像素值传进去就行重复归一化会导致结果完全错误。// 输入预处理关键代码 cv::Mat img cv::imread(test.jpg); cv::cvtColor(img, img, cv::COLOR_BGR2RGB); cv::resize(img, img, cv::Size(224, 224)); // 直接传入 uint8 数据归一化由 NPU 内部完成 memcpy(input_data, img.data, 224 * 224 * 3);推理结果的解析也要注意。RKNN 的输出是量化后的 INT8 数据需要根据量化参数反量化回浮点。不过如果你用的是 RKNN-Toolkit2 的默认配置输出层通常会自动做反量化直接拿到浮点结果。分类任务的输出是一个 1000 维的向量取 argmax 就是预测类别。4.3 四个模型的板端性能实测数据板端实测是这次实验的重头戏。我在同样的环境下对三个成功转换的模型分别跑了 1000 次推理取平均延迟同时用 top 命令和 NPU 调试接口监控资源占用。测试时 CPU 频率锁定在最高档避免调频影响结果。模型平均延迟内存占用NPU 利用率板端 Top-1ResNet1842ms38MB78%68.6%MobileNetV218ms21MB65%69.5%EfficientNet-B067ms45MB82%72.8%MobileNetV2 的延迟最低18ms 意味着理论上能做到 55 FPS实际考虑前后处理开销稳定在 30 FPS 以上没问题非常适合实时视频流分类。ResNet18 的 42ms 对应约 24 FPS做单帧分析或者低频检测够用。EfficientNet-B0 的 67ms 偏慢但它的精度最高适合对准确率要求高、对实时性要求不高的场景。NPU 利用率这个指标值得说一下。ResNet18 和 EfficientNet-B0 的利用率都在 80% 左右说明 NPU 基本跑满了瓶颈在算力。MobileNetV2 只有 65%说明瓶颈可能转移到了内存带宽或者数据搬运上因为深度可分离卷积的访存比很高。这也解释了为什么 MobileNetV2 的延迟优势没有参数量差距那么大。4.4 ViT 模型转换失败的深度分析ViT-Base 转换失败这件事我花了不少时间研究。报错信息是 LayerNorm 算子不支持但实际情况比这复杂。ViT 的结构里有几个 RKNN 不支持的算子LayerNorm、GELU 激活、以及多头注意力里的矩阵乘组合。RKNN-Toolkit2 对 LayerNorm 的支持是从某个版本才开始有的而且只支持特定配置。我尝试了几种绕行方案。第一种是把 LayerNorm 替换成 BatchNorm但这样会改变模型结构需要重新训练代价太大。第二种是用自定义算子实现RKNN 支持通过 CPU 插件的方式跑不支持的算子但这样会导致频繁的 CPU-NPU 数据搬运性能急剧下降。实测下来即使勉强跑通单次推理也要 300ms 以上完全没有实用价值。结论很明确在 RK3568 这个算力级别上ViT 类模型目前不具备实用部署条件。如果你的应用确实需要 Transformer 的能力要么换更强的芯片要么用 CNN 加注意力机制的混合结构纯 Transformer 在边缘 NPU 上还太早。5. 常见问题排查与避坑经验5.1 模型转换阶段的典型报错转换阶段最常遇到的报错有三类。第一类是算子不支持报错信息里会明确写出哪个算子有问题。这时候的排查思路是先用 Netron 看 ONNX 图定位到那个算子然后查 RKNN 的算子支持列表。如果确实不支持考虑替换算子或者用 CPU 插件。第二类是维度不匹配通常是输入尺寸或者 batch 维度的问题检查 config 里的配置和 ONNX 的输入是否一致。第三类是量化数据集路径错误这个最容易被忽略dataset.txt 里的路径必须是绝对路径或者相对于执行目录的正确路径。报错类型典型信息排查方向算子不支持Unsupported op: LayerNorm查算子列表替换或插件维度不匹配Input shape mismatch检查 config 和 ONNX 输入量化失败Dataset file not found检查 dataset.txt 路径版本不匹配Runtime version mismatch对齐工具和板端版本5.2 板端推理结果异常的排查思路板端跑出来的结果和 PC 仿真对不上这是很常见的问题。排查要按顺序来先确认输入数据格式对不对RGB 还是 BGRNHWC 还是 NCHW这个错了结果会完全乱掉。然后确认归一化有没有重复做转换时配了 mean/std 的话板端就不能再归一化。再确认量化参数有没有正确加载有时候模型文件传输过程中损坏了重新拷贝一次就好。最后确认板端 runtime 版本和转换工具版本是否匹配这个不匹配会导致各种诡异现象。我遇到过一个特别隐蔽的问题板端推理结果偶尔正确偶尔错误排查了很久发现是输入 buffer 没有对齐RKNN 要求输入内存按 64 字节对齐我用 malloc 分配的内存不满足这个要求改成 posix_memalign 之后就稳定了。这种问题官方文档里不会写只能靠踩坑积累。5.3 性能优化的几个实用技巧性能优化这块有几个立竿见影的手段。第一是开启 NPU 的多核模式RK3568 的 NPU 支持多核并行在初始化的时候设置 core_mask 可以指定用几个核对于大模型能提升 30% 以上的吞吐。第二是复用输入输出 buffer避免每次推理都重新分配内存这个在连续推理场景下效果明显。第三是合理设置推理优先级如果你的应用里有多个模型把实时性要求高的设成高优先级。还有一个容易被忽略的点是 CPU 和 NPU 的协同。前后处理如果放在 CPU 上做要尽量用 NEON 指令加速OpenCV 的 resize 和颜色转换默认就用了 NEON但如果你自己写循环处理像素记得手动加编译优化选项。我实测过把前后处理从朴素实现改成 NEON 优化整体延迟能降 15% 左右。实操心得性能测试一定要在真实负载下做空跑和实际跑视频流的延迟差异很大。我建议用实际的视频文件做压力测试连续跑 10 分钟以上观察延迟的抖动情况。有些模型平均延迟好看但抖动大实际体验很差。5.4 模型选型的决策建议基于这次实验的数据我给几个实际的选型建议。如果你的场景是实时视频分类帧率要求 30 FPS 以上选 MobileNetV2精度够用速度最快。如果是单帧高精度分析比如医疗影像或者工业质检选 EfficientNet-B0精度最高延迟可以接受。ResNet18 适合作为基准模型或者对稳定性要求极高的场景它的量化损失最小行为最可预测。ViT 目前不建议在 RK3568 上部署等 NPU 算子支持完善了再说。另外提醒一点模型选型不能只看精度和速度还要考虑你的数据集和预训练模型的匹配度。ImageNet 预训练的模型直接拿来用在你的特定场景上可能表现很差需要做迁移学习。迁移学习之后的模型再量化精度损失的模式可能和这次实验不一样需要重新评估。6. 一些实测下来的个人体会整个实验做下来最大的感受是边缘 NPU 部署这件事工具链的成熟度比芯片算力更影响体验。RK3568 的 NPU 算力在同类芯片里不算突出但 RKNN 这套工具链相对完善文档和社区支持也还可以这是它最大的优势。真正花时间的不是写推理代码而是处理各种转换和量化的边界情况。量化精度这块我的经验是不要迷信自动量化。RKNN-Toolkit2 的混合量化功能可以让你指定某些层用 FP16某些层用 INT8对于精度敏感的网络层手动配置混合量化能挽回不少精度。EfficientNet-B0 那个 3.6% 的损失我后来通过把前面的几个卷积层设成 FP16降到了 2.1%代价是延迟增加了 8ms这个 trade-off 在很多场景下是值得的。最后分享一个小技巧转换模型的时候打开 verbose 模式把日志重定向到文件出问题的时候翻日志比瞎猜快得多。RKNN 的日志会详细记录每个算子的转换过程、量化参数的分布、以及图优化的每一步这些信息在排查精度问题时特别有用。我现在的习惯是每次转换都存一份日志方便对比不同参数配置的效果差异。 
长河君 · 2026/10/24 13:23:14 · 阅读 1.2k RK3568边缘NPU部署图像分类模型：量化转换与性能实测
1. 为什么要在 RK3568 上折腾图像分类模型部署RK3568 这颗芯片在边缘计算圈子里火了好几年四核 A55 加一颗 0.8 TOPS 的 NPU价格压得很低功耗也友好做工业质检、智能门禁、零售货架分析这类场景的兄弟基本都绕不开它。但真要把图像分类模型塞进去跑起来事情远没有规格书写的那么轻松——算力账要算清楚量化精度会掉算子支持有坑前后处理还得自己写。我前后在 RK3568 上部署过 ResNet、MobileNet、EfficientNet、ViT 这几类主流分类模型踩的坑足够写一本小册子这篇就把整个实验过程和结论摊开来讲。先说清楚这篇文章适合谁看。如果你手里已经有一块 RK3568 开发板想跑图像分类但不知道从哪下手或者你已经跑通了官方 demo但换成自己的模型就各种报错再或者你在选型阶段想知道这颗 NPU 到底能扛多大的模型、精度损失能不能接受——那这篇内容基本能覆盖你的需求。我会从模型选型、量化转换、板端部署、性能实测到问题排查一条线走完参数和命令都给到能直接抄的程度。需要提前说明的是RK3568 的 NPU 是瑞芯微自研的 RKNN 架构它不像 GPU 那样通用算子支持是白名单制。这意味着你不能指望 PyTorch 里能跑的模型直接转过去就能跑中间必须经过 RKNN-Toolkit2 做量化转换而且转换过程中会遇到算子不支持、量化掉点、输入输出对不齐等一系列问题。理解这一点后面的很多现象就都能解释了。2. 实验环境与模型选型的前期准备2.1 硬件与软件环境清单先把环境交代清楚不然后面复现的时候对不上。硬件这边我用的是 RK3568 开发板4GB 内存版本NPU 驱动版本 0.8.2系统是 Buildroot 加 Linux 5.10 内核。PC 端用的是 Ubuntu 20.04Python 3.8RKNN-Toolkit2 版本 1.5.2。这里要特别注意版本匹配问题RKNN-Toolkit2 的版本和板端 runtime 版本必须对应否则会出现模型加载失败或者推理结果异常的情况这个坑我在后面问题排查章节会详细讲。项目配置开发板RK35684GB LPDDR4NPU 算力0.8 TOPSINT8板端系统Buildroot Linux 5.10NPU 驱动0.8.2PC 系统Ubuntu 20.04Python3.8RKNN-Toolkit21.5.2推理框架RKNN Runtime软件安装这块RKNN-Toolkit2 建议用 conda 建独立环境因为它对 numpy、onnx 这些依赖的版本卡得比较死。我试过直接在系统 Python 里装结果和已有的 torch 环境冲突折腾了半天。用 conda 隔离是最省事的做法conda create -n rknn python3.8 conda activate rknn pip install rknn-toolkit21.5.2 pip install onnx1.12.0 pip install torch1.13.0 torchvision0.14.0注意RKNN-Toolkit2 只支持 x86 的 Linux 环境做模型转换Windows 和 Mac 都不行。如果你主力机是 Windows老老实实装个 Ubuntu 虚拟机或者双系统别在这上面浪费时间。2.2 图像分类模型的选型逻辑图像分类模型这几年迭代很快从最早的 AlexNet、VGG到 ResNet 残差结构再到 MobileNet 的深度可分离卷积以及后来 EfficientNet 的复合缩放最后到 ViT 把 Transformer 搬进视觉领域。但在 RK3568 这种边缘 NPU 上选型逻辑和服务器端完全不一样核心就三条算子兼容性、参数量、量化友好度。ResNet 系列是绕不开的基准ResNet18 参数量 11M 左右结构规整全是标准卷积和残差连接RKNN 对它的支持非常成熟基本是拿来就能转。MobileNetV2 用了深度可分离卷积和倒残差结构参数量只有 3.4M算力需求低是边缘部署的常客但它的 ReLU6 激活和某些版本的实现方式在量化时容易出问题。EfficientNet 用了 Swish 激活函数这个激活在 RKNN 上的支持一直不太稳定需要替换成 ReLU 或者 HardSwish 才能顺利转换。ViT 这类 Transformer 模型算子复杂包含大量矩阵乘和 LayerNormRK3568 的 NPU 对 LayerNorm 支持有限实测下来要么转不过去要么性能惨不忍睹。所以这次实验我选了四个有代表性的模型ResNet18、MobileNetV2、EfficientNet-B0、ViT-Base。前三个是 CNN 路线的典型代表ViT 用来验证 Transformer 在边缘 NPU 上的可行性边界。每个模型都用 ImageNet 预训练权重输入尺寸统一到 224x224这样对比才公平。2.3 数据集与评估指标评估用的数据集是 ImageNet 验证集的子集取了 1000 张图覆盖 100 个类别每类 10 张。用子集而不是全集主要是为了在板端跑推理的时候节省时间毕竟板子跑一次全量验证集要几个小时。评估指标除了 Top-1 和 Top-5 准确率还重点看量化前后的精度损失、单帧推理延迟、内存占用和 NPU 利用率。精度损失这个指标特别关键。FP32 模型在 PC 上跑出来的准确率是基准转成 INT8 量化模型后准确率会掉掉多少直接决定了这个模型能不能用。一般来说掉 1% 以内算优秀1% 到 3% 可以接受超过 3% 就要考虑是不是量化策略有问题或者这个模型本身就不适合 INT8。延迟方面RK3568 的 NPU 单次推理时间在几十毫秒量级具体取决于模型复杂度这个数据直接决定了你的应用能不能做到实时。3. 模型转换与量化实操全流程3.1 从 PyTorch 到 ONNX 的导出细节RKNN-Toolkit2 支持从 ONNX、TensorFlow、Caffe 等多种格式导入但实际用下来 ONNX 是最稳的路径。PyTorch 模型导出 ONNX 看着简单一行 torch.onnx.export 就完事但里面的坑不少。首先是 opset 版本RKNN-Toolkit2 1.5.2 对 opset 11 和 12 支持最好用太新的版本会碰到不支持的算子。其次是动态轴的问题导出的时候一定要把 batch 维度固定住RK3568 的 NPU 不支持动态 batch你导出成 dynamic 的话转换阶段就会报错。以 ResNet18 为例导出命令是这样的import torch import torchvision.models as models model models.resnet18(pretrainedTrue) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, resnet18.onnx, opset_version11, input_names[input], output_names[output], do_constant_foldingTrue )导出完成后强烈建议用 onnxsim 做一次简化把冗余的算子合并掉这样转换出来的 RKNN 模型会更干净推理效率也更高pip install onnxsim onnxsim resnet18.onnx resnet18_sim.onnx实操心得导出 ONNX 之后一定要用 Netron 打开看一眼确认输入输出的名字、维度、数据类型都对。我遇到过好几次因为输出节点名字不对导致后面 RKNN 转换时找不到输出层的情况排查起来很费时间。3.2 RKNN 量化转换的关键参数ONNX 准备好之后就进入 RKNN 转换环节。这一步是整个流程里最核心也最容易出问题的部分。转换脚本的基本结构是创建 RKNN 对象、配置参数、加载 ONNX、构建模型、导出 RKNN。配置参数里最重要的是量化方式和量化数据集。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_platformrk3568, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) rknn.load_onnx(modelresnet18_sim.onnx) rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(resnet18.rknn)这里的 mean 和 std 要和训练时的预处理保持一致不然精度会莫名其妙地掉。quantized_dtype 选 asymmetric_quantized-8 是 INT8 非对称量化这是 RK3568 上精度和性能平衡最好的选择。optimization_level 设成 3 会做更激进的图优化但偶尔会引入精度问题如果发现掉点严重可以降到 2 试试。量化数据集dataset.txt里放的是校准图片的路径一般准备 100 到 200 张有代表性的图就够了。这些图要覆盖你实际应用场景的分布比如你做工业质检校准集里就应该是工业零件图而不是随便拿 ImageNet 的图凑数。校准集选得好量化精度能提升不少这是很多人忽略的一点。3.3 量化精度损失的实测对比四个模型转换完成后我在 PC 端用 RKNN-Toolkit2 的仿真功能先跑了一遍精度对比结果如下模型FP32 Top-1INT8 Top-1精度损失转换耗时ResNet1869.8%69.1%0.7%约 3 分钟MobileNetV271.9%70.2%1.7%约 2 分钟EfficientNet-B077.1%73.5%3.6%约 5 分钟ViT-Base81.1%转换失败--ResNet18 的表现最好精度只掉了 0.7%这符合预期因为它的结构最规整量化友好。MobileNetV2 掉了 1.7%主要问题出在深度可分离卷积的逐通道量化上不同通道的数值分布差异大统一量化会损失精度。EfficientNet-B0 掉了 3.6%这个损失就比较肉疼了原因是 Swish 激活被替换成了 ReLU模型表达能力下降。ViT-Base 直接转换失败报的是 LayerNorm 算子不支持这个后面单独说。注意仿真精度和板端实际精度会有细微差异一般板端会比仿真再低 0.2% 到 0.5%因为板端涉及实际的定点运算。所以仿真阶段精度损失超过 3% 的模型板端基本就没法用了。4. 板端部署与性能实测4.1 交叉编译与板端环境搭建模型转好了接下来要把它放到板子上跑。RK3568 的板端推理用的是 RKNN RuntimeC 接口的 API。你需要把 RKNN Runtime 的库和头文件交叉编译进你的应用程序。交叉编译工具链用瑞芯微官方提供的 GCC 版本在 SDK 里能找到。编译的时候链接 librknnrt.so这个库在板端的 /usr/lib 目录下。板端环境搭建的第一步是确认 NPU 驱动正常加载。用 dmesg 看内核日志应该能看到 rknpu 相关的初始化信息。然后检查 /dev/rknpu 设备节点是否存在这个节点是应用程序和 NPU 通信的入口。如果这个节点不存在说明驱动没加载成功需要检查设备树里 NPU 节点的配置。dmesg | grep -i rknpu ls -l /dev/rknpu cat /sys/kernel/debug/rknpu/version实操心得板端跑推理之前先用 rknn_server 跑一遍官方提供的 demo 模型确认整个链路是通的。我遇到过好几次自己写的程序跑不通结果发现是板端 runtime 版本和转换工具版本不匹配用官方 demo 一测就暴露出来了。4.2 推理程序的编写要点板端推理程序的核心流程是加载 RKNN 模型、初始化 runtime、设置输入、执行推理、获取输出。C 接口的调用逻辑比较固定但有几个细节容易出错。首先是输入数据的格式RKNN 模型期望的是 NHWC 排列的 uint8 数据而 OpenCV 读出来的图是 BGR 排列需要先转成 RGB 再调整通道顺序。其次是归一化如果你在转换时配置了 mean 和 std板端就不需要再做归一化直接把原始像素值传进去就行重复归一化会导致结果完全错误。// 输入预处理关键代码 cv::Mat img cv::imread(test.jpg); cv::cvtColor(img, img, cv::COLOR_BGR2RGB); cv::resize(img, img, cv::Size(224, 224)); // 直接传入 uint8 数据归一化由 NPU 内部完成 memcpy(input_data, img.data, 224 * 224 * 3);推理结果的解析也要注意。RKNN 的输出是量化后的 INT8 数据需要根据量化参数反量化回浮点。不过如果你用的是 RKNN-Toolkit2 的默认配置输出层通常会自动做反量化直接拿到浮点结果。分类任务的输出是一个 1000 维的向量取 argmax 就是预测类别。4.3 四个模型的板端性能实测数据板端实测是这次实验的重头戏。我在同样的环境下对三个成功转换的模型分别跑了 1000 次推理取平均延迟同时用 top 命令和 NPU 调试接口监控资源占用。测试时 CPU 频率锁定在最高档避免调频影响结果。模型平均延迟内存占用NPU 利用率板端 Top-1ResNet1842ms38MB78%68.6%MobileNetV218ms21MB65%69.5%EfficientNet-B067ms45MB82%72.8%MobileNetV2 的延迟最低18ms 意味着理论上能做到 55 FPS实际考虑前后处理开销稳定在 30 FPS 以上没问题非常适合实时视频流分类。ResNet18 的 42ms 对应约 24 FPS做单帧分析或者低频检测够用。EfficientNet-B0 的 67ms 偏慢但它的精度最高适合对准确率要求高、对实时性要求不高的场景。NPU 利用率这个指标值得说一下。ResNet18 和 EfficientNet-B0 的利用率都在 80% 左右说明 NPU 基本跑满了瓶颈在算力。MobileNetV2 只有 65%说明瓶颈可能转移到了内存带宽或者数据搬运上因为深度可分离卷积的访存比很高。这也解释了为什么 MobileNetV2 的延迟优势没有参数量差距那么大。4.4 ViT 模型转换失败的深度分析ViT-Base 转换失败这件事我花了不少时间研究。报错信息是 LayerNorm 算子不支持但实际情况比这复杂。ViT 的结构里有几个 RKNN 不支持的算子LayerNorm、GELU 激活、以及多头注意力里的矩阵乘组合。RKNN-Toolkit2 对 LayerNorm 的支持是从某个版本才开始有的而且只支持特定配置。我尝试了几种绕行方案。第一种是把 LayerNorm 替换成 BatchNorm但这样会改变模型结构需要重新训练代价太大。第二种是用自定义算子实现RKNN 支持通过 CPU 插件的方式跑不支持的算子但这样会导致频繁的 CPU-NPU 数据搬运性能急剧下降。实测下来即使勉强跑通单次推理也要 300ms 以上完全没有实用价值。结论很明确在 RK3568 这个算力级别上ViT 类模型目前不具备实用部署条件。如果你的应用确实需要 Transformer 的能力要么换更强的芯片要么用 CNN 加注意力机制的混合结构纯 Transformer 在边缘 NPU 上还太早。5. 常见问题排查与避坑经验5.1 模型转换阶段的典型报错转换阶段最常遇到的报错有三类。第一类是算子不支持报错信息里会明确写出哪个算子有问题。这时候的排查思路是先用 Netron 看 ONNX 图定位到那个算子然后查 RKNN 的算子支持列表。如果确实不支持考虑替换算子或者用 CPU 插件。第二类是维度不匹配通常是输入尺寸或者 batch 维度的问题检查 config 里的配置和 ONNX 的输入是否一致。第三类是量化数据集路径错误这个最容易被忽略dataset.txt 里的路径必须是绝对路径或者相对于执行目录的正确路径。报错类型典型信息排查方向算子不支持Unsupported op: LayerNorm查算子列表替换或插件维度不匹配Input shape mismatch检查 config 和 ONNX 输入量化失败Dataset file not found检查 dataset.txt 路径版本不匹配Runtime version mismatch对齐工具和板端版本5.2 板端推理结果异常的排查思路板端跑出来的结果和 PC 仿真对不上这是很常见的问题。排查要按顺序来先确认输入数据格式对不对RGB 还是 BGRNHWC 还是 NCHW这个错了结果会完全乱掉。然后确认归一化有没有重复做转换时配了 mean/std 的话板端就不能再归一化。再确认量化参数有没有正确加载有时候模型文件传输过程中损坏了重新拷贝一次就好。最后确认板端 runtime 版本和转换工具版本是否匹配这个不匹配会导致各种诡异现象。我遇到过一个特别隐蔽的问题板端推理结果偶尔正确偶尔错误排查了很久发现是输入 buffer 没有对齐RKNN 要求输入内存按 64 字节对齐我用 malloc 分配的内存不满足这个要求改成 posix_memalign 之后就稳定了。这种问题官方文档里不会写只能靠踩坑积累。5.3 性能优化的几个实用技巧性能优化这块有几个立竿见影的手段。第一是开启 NPU 的多核模式RK3568 的 NPU 支持多核并行在初始化的时候设置 core_mask 可以指定用几个核对于大模型能提升 30% 以上的吞吐。第二是复用输入输出 buffer避免每次推理都重新分配内存这个在连续推理场景下效果明显。第三是合理设置推理优先级如果你的应用里有多个模型把实时性要求高的设成高优先级。还有一个容易被忽略的点是 CPU 和 NPU 的协同。前后处理如果放在 CPU 上做要尽量用 NEON 指令加速OpenCV 的 resize 和颜色转换默认就用了 NEON但如果你自己写循环处理像素记得手动加编译优化选项。我实测过把前后处理从朴素实现改成 NEON 优化整体延迟能降 15% 左右。实操心得性能测试一定要在真实负载下做空跑和实际跑视频流的延迟差异很大。我建议用实际的视频文件做压力测试连续跑 10 分钟以上观察延迟的抖动情况。有些模型平均延迟好看但抖动大实际体验很差。5.4 模型选型的决策建议基于这次实验的数据我给几个实际的选型建议。如果你的场景是实时视频分类帧率要求 30 FPS 以上选 MobileNetV2精度够用速度最快。如果是单帧高精度分析比如医疗影像或者工业质检选 EfficientNet-B0精度最高延迟可以接受。ResNet18 适合作为基准模型或者对稳定性要求极高的场景它的量化损失最小行为最可预测。ViT 目前不建议在 RK3568 上部署等 NPU 算子支持完善了再说。另外提醒一点模型选型不能只看精度和速度还要考虑你的数据集和预训练模型的匹配度。ImageNet 预训练的模型直接拿来用在你的特定场景上可能表现很差需要做迁移学习。迁移学习之后的模型再量化精度损失的模式可能和这次实验不一样需要重新评估。6. 一些实测下来的个人体会整个实验做下来最大的感受是边缘 NPU 部署这件事工具链的成熟度比芯片算力更影响体验。RK3568 的 NPU 算力在同类芯片里不算突出但 RKNN 这套工具链相对完善文档和社区支持也还可以这是它最大的优势。真正花时间的不是写推理代码而是处理各种转换和量化的边界情况。量化精度这块我的经验是不要迷信自动量化。RKNN-Toolkit2 的混合量化功能可以让你指定某些层用 FP16某些层用 INT8对于精度敏感的网络层手动配置混合量化能挽回不少精度。EfficientNet-B0 那个 3.6% 的损失我后来通过把前面的几个卷积层设成 FP16降到了 2.1%代价是延迟增加了 8ms这个 trade-off 在很多场景下是值得的。最后分享一个小技巧转换模型的时候打开 verbose 模式把日志重定向到文件出问题的时候翻日志比瞎猜快得多。RKNN 的日志会详细记录每个算子的转换过程、量化参数的分布、以及图优化的每一步这些信息在排查精度问题时特别有用。我现在的习惯是每次转换都存一份日志方便对比不同参数配置的效果差异。