目录RK3588RKNN1. 模型导出1.1 环境搭建1.2 导出RKNN模型2. 推理2.1 环境搭建2.2 推理代码2.3 评测代码3. 指标对比3.1 指标对比3.2 异常差异说明3.3 对比结论3.4 详细日志参考文档RK3588RK3588作为瑞芯微电子Rockchip倾力打造的新一代旗舰级系统级芯片Soc自其发布以来便以其卓越的性能表现和广泛的应用潜力在业界引起了广泛的关注。这款芯片不仅集成了多种高性能处理单元更在功耗控制、图形处理、视频编解码以及人工智能计算能力等方面展现出了非凡的实力。它内嵌了一个高性能的NPU神经网络处理器支持INT4、INT8、INT16、FP16等多种运算模式算力高达6TOPS每秒万亿次操作。这使得RK3588能够高效地处理复杂的深度学习模型和神经网络推理任务。NPU具有广泛的框架兼容性能够轻松转换基于PyTorch、TensorFlow、MXNet和Caffe等主流框架的网络模型。RKNNRKNN(Rockchip Neural Network)是瑞芯微(Rockchip)为其NPU(Neural Processing Unit)开发的专用神经网络模型格式及工具链旨在优化AI模型在边缘设备上的部署与推理性能。RKNN 模型专为充分利用 Rockchip 神经网络处理单元 (NPU) 的硬件加速能力而设计。与在同一硬件上运行 ONNX 或 LiteRT 等通用模型格式相比这种优化能带来显著更快的推理速度并降低延迟。使用 RKNN 模型能更高效地利用设备资源从而降低功耗并提升整体性能这对于边缘设备上的实时应用尤为关键。通过将你的 Ultralytics YOLO 模型转换为 RKNN你可以在搭载 RK3588、RK3566 等 Rockchip SoC 的设备上获得最佳性能。RKNN 模型在 Rockchip 平台上部署具有以下优势针对 NPU 优化RKNN 模型经过专门优化可在 Rockchip 的 NPU 上运行确保最佳的性能和效率。低延迟RKNN 格式可最大限度地减少推理延迟这对边缘设备的实时应用至关重要。平台特定自定义RKNN 模型可以针对特定 Rockchip 平台进行调整从而实现硬件资源的更好利用。电源效率通过利用专用的 NPU 硬件RKNN 模型比基于 CPU 或 GPU 的处理消耗更少的电量从而延长了便携式设备的电池寿命。在嵌入式设备尤其是搭载 Rockchip 处理器的设备上部署计算机视觉模型时拥有兼容的模型格式至关重要。将 Ultralytics YOLO26 模型导出为 RKNN 格式可确保在 Rockchip 硬件上实现最佳性能和兼容性。本指南将引导你完成将 YOLO26 模型转换为 RKNN 格式的过程包括浮点和 INT8 量化导出从而在 Rockchip 平台上实现高效部署。使用 Ultralytics Python 包中的 export() 方法或通过命令行界面 (CLI) 将 Ultralytics YOLO 模型导出为 RKNN 格式。请确保使用基于 x86 的 Linux PC 进行导出过程因为不支持在 Rockchip 等 ARM64 设备上进行此操作。你可以使用 name 参数例如 rk3588、rk3566 等指定目标 Rockchip 平台。此过程会生成一个优化后的 RKNN 模型用于在 Rockchip 设备上部署并利用其神经网络处理单元 (NPU) 进行加速推理。1. 模型导出1.1 环境搭建系统环境24.04.2-Ubuntu, x86_64Python环境python 3.12pip install ultralytics pip install rknn-toolkit22.3.2 pip install onnx1.12.0,1.19.0 onnxruntime onnxslim0.1.82备注ultralytics-8.4.821.2 导出RKNN模型from ultralytics import YOLO # Load a YOLO26 model model YOLO(/path/to/weights/best.pt) # Export the model to RKNN format model.export(formatrknn, namerk3588) # creates /yolo26n_rknn_model # Export an INT8-quantized RKNN model with calibration data # model.export(formatrknn, namerk3588, quantize8, datadataset.yaml)导出模型目录zhangjunhaoengo-gpu02:~$ tree best_rknn_model/ best_rknn_model/ ├── best-rk3588.rknn └── metadata.yaml 1 directory, 2 files zhangjunhaoengo-gpu02:~$备注默认情况下RKNN 导出对支持 FP16 的 Rockchip 目标使用浮点构建路径quantize16。使用 quantize8 可以构建带有校准数据的 INT8 量化 RKNN 模型。RKNN 导出不提供单独的 FP32 模式默认的 FP16 不会请求 FP32。导出的INT8量化RKNN模型实测检测不到目标所以采用精度FP162. 推理2.1 环境搭建系统环境Linux firefly 6.1.118, aarch64Python环境python 3.10pip install ultralytics -i https://pypi.tuna.tsinghua.edu.cn/simple pip install rknn-toolkit-lite2可以先安装cpu版本pytorch这样安装ultralytics时就不会下载安装cuda相关的pytorch包。如果你遇到日志消息显示 RKNN 运行时版本与 RKNN Toolkit 版本不匹配且推理失败请将 /usr/lib/librknnrt.so 替换为官方 librknnrt.so文件。2.2 推理代码from ultralytics import YOLO # Load the exported RKNN model model YOLO(./best_rknn_model) # Run inference results model.predict(sourcedataset/images/test, saveTrue, conf0.05)2.3 评测代码from ultralytics import YOLO # Load the exported RKNN model model YOLO(./best_rknn_model) # 运行验证splittest 指定使用测试集 metrics model.val(datadataset.yaml, splittest) # 提取边界框 (Box) 指标 print(fPrecision: {metrics.box.mp:.3f}) # 全类平均精确率 print(fRecall: {metrics.box.mr:.3f}) # 全类平均召回率 print(fmAP50: {metrics.box.map50:.3f}) # mAP0.5 print(fmAP50-95: {metrics.box.map:.3f}) # mAP0.5:0.953. 指标对比3.1 指标对比NVIDIA GeForce RTX 5080NVIDIA GeForce RTX 5080RK3588 NPUTest dataset74张Modelyolo26m(FP32)yolo26m(FP16)RKNN(FP16)Precision0.7960.7990.905Recall0.8810.8800.856mAP500.8870.8880.891mAP50-950.5830.5880.597Inference Speed5.9ms39.0ms290.3ms3.2 异常差异说明3.2.1 YOLO26检测模型在NVIDIA GeForce RTX 5080和RK3588 NPU Precision差异在 RK3588 (RKNN) 上的 Precision 高于 RTX 5080 (PyTorch FP16)通常是由以下几个因素导致的1.后端处理差异 (Post-processing)根据 Rockchip RKNN Export 文档RKNN 导出通常会将部分解码逻辑固化或调整。不同的推理引擎TensorRT vs RKNN在处理浮点数边界、NMS非极大值抑制及置信度阈值时存在微小差异。如果 RKNN 后端过滤掉了更多低置信度的“假阳性”预测Precision (精确率) 就会显著提升尽管这可能会以微弱降低 Recall (召回率) 为代价 Recall 从 0.880 降至 0.856 正印证了这一点。2.量化与数据类型转换虽然使用了 halfTrue (FP16)但 RKNN 在导出时默认 quantize16会根据 RKNN Toolkit 的权重重排和算子融合进行优化。这种硬件底层的数值截断有时会起到类似“正则化”的效果压制了某些类别的弱噪声激活。3.模型一致性mAP50 (0.888 vs 0.891) 和 mAP50-95 (0.588 vs 0.597) 在两个平台上非常接近。这说明模型的整体检测性能是稳定的Precision 的波动属于推理后端实现差异导致的正常范围3.2.2 NVIDIA GeForce RTX 5080 上 FP32和FP16推理速度差异FP32 推理耗时 5.9ms而 FP16 推理耗时 39.0ms。导致这种现象的原因如下1. PyTorch FP16 的实现机制在 PyTorch 框架下直接对 .pt 模型调用 half()或 quantize16进行推理时如果相关算子在当前环境中没有针对 FP16 的高度优化或者由于内存对齐/数据转换带来了额外开销速度反而会变慢。2.缺少硬件级优化 (TensorRT)对于NVIDIA RTX 5080 这种高性能显卡要真正发挥FP16的速度优势必须通过TensorRT 进行模型编译。原生PyTorch FP16往往只是减少了显存不一定能触发Tensor Cores加速。TensorRT FP16会将算子融合并强制在Tensor Cores上运行通常可获得 2-8 倍加速。3.首次运行的预热与 CPU 瓶颈从日志看 FP16 验证循环5/5每秒处理次数1.5it/s远低于 FP323.5it/s。这可能涉及到数据从 FP32 转换为 FP16 的开销。通过 TensorRT 导出才能在 RTX 5080 上看到 FP16 的显著性能提升3.3 对比结论YOLO26m转RKNN(FP16)格式后在RK3588 NPU上推理精度指标和YOLO26m在NVIDIA GeForce RTX 5080上整体相差不大但推理速度有50倍左右差异290.3ms vs 5.9ms, 但300ms左右的推理延时目前在可接受范围之内。3.4 详细日志NVIDIA GeForce RTX 5080 FP32(venv) roote9a5fcb4a688:/workspace/bohe/DetectionTrain# python metric.py Ultralytics 8.4.82 Python-3.12.3 torch-2.11.0cu130 CUDA:0 (NVIDIA GeForce RTX 5080, 15840MiB) YOLO26m summary (fused): 132 layers, 20,362,559 parameters, 0 gradients, 67.9 GFLOPs val: Fast image access ✅ (ping: 0.0±0.0 ms, read: 6458.1±1912.1 MB/s, size: 1486.5 KB) val: Scanning /workspace/bohe/DetectionTrain/TurbineHall/labels/test.cache... 74 images, 4 backgrounds, 0 corrupt: 100% ━━━━━━━━━━━━ 74/74 20.7Mit/s 0.0s Class Images Instances Box(P R mAP50 mAP50-95): 100% ━━━━━━━━━━━━ 5/5 3.5it/s 1.4s all 74 269 0.796 0.881 0.887 0.583 bearing_box 3 3 0.823 1 0.995 0.746 conductivity_meter 3 3 1 0.598 0.665 0.51 direct_reading_level_gauge 2 2 0.771 1 0.995 0.795 gate_valve 17 40 0.732 0.625 0.702 0.36 hydr_purity_analyzer 1 2 0.653 1 0.995 0.597 indicator_light 14 128 0.916 0.969 0.983 0.478 mag_flap_level_gauge 16 17 0.711 0.882 0.837 0.569 single_hand_round_meter 36 74 0.764 0.973 0.923 0.606 Speed: 4.5ms preprocess, 5.9ms inference, 0.0ms loss, 0.1ms postprocess per image Results saved to /workspace/bohe/DetectionTrain/runs/detect/val-2 Precision: 0.796 Recall: 0.881 mAP50: 0.887 mAP50-95: 0.583 (venv) roote9a5fcb4a688:/workspace/bohe/DetectionTrain#NVIDIA GeForce RTX 5080 FP16(venv) roote9a5fcb4a688:/workspace/bohe/DetectionTrain# python metric_fp16.py WARNING ⚠️ half is deprecated and will be removed in the future. Use quantize instead. Ultralytics 8.4.82 Python-3.12.3 torch-2.11.0cu130 CUDA:0 (NVIDIA GeForce RTX 5080, 15840MiB) YOLO26m summary (fused): 132 layers, 20,362,559 parameters, 0 gradients, 67.9 GFLOPs val: Fast image access ✅ (ping: 0.0±0.0 ms, read: 4377.4±433.1 MB/s, size: 563.2 KB) val: Scanning /workspace/bohe/DetectionTrain/TurbineHall/labels/test.cache... 74 images, 4 backgrounds, 0 corrupt: 100% ━━━━━━━━━━━━ 74/74 17.2Mit/s 0.0s Class Images Instances Box(P R mAP50 mAP50-95): 100% ━━━━━━━━━━━━ 5/5 1.5it/s 3.4s all 74 269 0.799 0.88 0.888 0.588 bearing_box 3 3 0.823 1 0.995 0.788 conductivity_meter 3 3 1 0.589 0.665 0.51 direct_reading_level_gauge 2 2 0.771 1 0.995 0.795 gate_valve 17 40 0.752 0.625 0.7 0.353 hydr_purity_analyzer 1 2 0.652 1 0.995 0.597 indicator_light 14 128 0.917 0.969 0.983 0.476 mag_flap_level_gauge 16 17 0.711 0.882 0.844 0.573 single_hand_round_meter 36 74 0.767 0.976 0.924 0.611 Speed: 1.7ms preprocess, 39.0ms inference, 0.0ms loss, 0.1ms postprocess per image Results saved to /workspace/bohe/DetectionTrain/runs/detect/val-3 Precision: 0.799 Recall: 0.880 mAP50: 0.888 mAP50-95: 0.588RK3588 NPU(rknn) rootfirefly:~/rknn# python rknn_metrics.py WARNING ⚠️ Unable to automatically guess model task, assuming taskdetect. Explicitly define task for your model, i.e. taskdetect, segment, classify, pose, obb or semantic. Ultralytics 8.4.82 Python-3.10.12 torch-2.12.1cu130 CPU (aarch64) Loading ./best_rknn_model for RKNN inference... W rknn-toolkit-lite2 version: 2.3.2 I RKNN: [08:29:12.314] RKNN Runtime Information, librknnrt version: 2.4.2a2 (19838178182026-06-23T09:55:10) I RKNN: [08:29:12.314] RKNN Driver Information, version: 0.9.8 I RKNN: [08:29:12.315] RKNN Model Information, version: 6, toolkit version: 2.3.2(compiler version: 2.3.2 (e045de294f2025-04-07T19:48:25)), target: RKNPU v2, target platform: rk3588, framework name: ONNX, framework layout: NCHW, model inference type: static_shape W RKNN: [08:29:12.447] query RKNN_QUERY_INPUT_DYNAMIC_RANGE error, rknn model is static shape type, please export rknn with dynamic_shapes W Query dynamic range failed. Ret code: RKNN_ERR_MODEL_INVALID. (If it is a static shape RKNN model, please ignore the above warning message.) Setting batch1 input of shape (1, 3, 640, 640) val: Fast image access ✅ (ping: 0.0±0.0 ms, read: 1208.9±289.1 MB/s, size: 786.4 KB) val: Scanning /root/rknn/TurbineHall/labels/test.cache... 74 images, 4 backgrounds, 0 corrupt: 100% ━━━━━━━━━━━━ 74/74 6.3Mit/s 0.0s Class Images Instances Box(P R mAP50 mAP50-95): 100% ━━━━━━━━━━━━ 74/74 2.4it/s 30.9s all 74 269 0.905 0.856 0.891 0.597 bearing_box 3 3 0.951 1 0.995 0.763 conductivity_meter 3 3 0.924 0.667 0.665 0.599 direct_reading_level_gauge 2 2 0.905 1 0.995 0.846 gate_valve 17 40 0.848 0.575 0.724 0.328 hydr_purity_analyzer 1 2 0.91 1 0.995 0.547 indicator_light 14 128 0.98 0.777 0.974 0.459 mag_flap_level_gauge 16 17 0.863 0.882 0.831 0.575 single_hand_round_meter 36 74 0.86 0.946 0.946 0.659 Speed: 2.6ms preprocess, 290.3ms inference, 0.0ms loss, 3.9ms postprocess per image Results saved to /root/rknn/runs/detect/val-3 Precision: 0.905 Recall: 0.856 mAP50: 0.891 mAP50-95: 0.597 (rknn) rootfirefly:~/rknn#参考文档Rockchip RKNN Export for Ultralytics YOLO26 ModelsYOLO26 RKNN Export for Rockchip NPU | Ultralyticsairockchip/rknn-toolkit2GitHub - airockchip/rknn-toolkit2 · GitHub