RK3568边缘AI模型转换实战：PC端RKNN环境搭建与高频命令

1. 为什么说搭建 PC 端转换环境是 RK3568 边缘 AI 的第一道关卡

先交代一个背景：我手头这块 RK3568 板子，是正点原子的 ATK-DLRK3568，拿到手的第一周几乎全在跟交叉编译和模型转换较劲。RK3568 这块芯片本身定位非常明确——四核 Cortex-A55 + 0.8T NPU，面向边缘 AI 推理场景，跑轻量级视觉模型、工业质检、智能安防这类任务相当合适。但所有板端推理的前提，是模型得先从 PC 端转成 RKNN 格式。

很多人第一次接触这块板子时有个误区：以为模型转换是在板子上完成的。实际上 RKNN-Toolkit2 的转换流程几乎都在 x86 架构的 PC 上执行，转换完成后把 .rknn 文件通过 adb、scp 或 NFS 丢到板子上，再用 RKNN Runtime 在板端加载推理。

这个“先在 PC 转换、再部署到板端”的工作模式，本质上是由 RK3568 的资源限制和转换工具链的架构共同决定的。转换过程涉及算子解析、量化校准、权重重排，这些计算放在 0.8T NPU 的开发板上跑不仅慢，而且内存和存储都可能撑不住。转换工具跑在 PC 上，板子只负责加载和推理，这才是边缘 AI 开发的标准姿势。

这篇文章是这个系列的第三篇，聚焦两件事：一是把 RK3568 边缘 AI 开发中的“三层分工”彻底讲明白，二是我自己在 PC 端搭转换环境时沉淀下来的 15 条高频命令。整套流程走通之后，你从训练好的 PyTorch 模型文件到板端成功跑出推理结果，理论上只需要一条龙操作，但前提是每一步的环境都不能出错。

2. 三层分工：PC 转换、网络传输、板端推理分别该干什么

2.1 PC 端转换：为什么模型必须先在 x86 环境里“脱胎换骨”

RK3568 的 NPU 不能直接吃 PyTorch 的 .pt、ONNX 的 .onnx 或者 TensorFlow 的 .pb 文件，它只能识别 RKNN 格式。这个 RKNN 格式是瑞芯微自己定义的一种模型封装，里面不仅包含网络结构和权重数据，还包含 NPU 驱动能够直接调度的算子指令序列和参数配置。

所以 PC 端转换工具 RKNN-Toolkit2 干的事情，可以类比成“编译器”：ONNX 模型是源代码，RKNN 格式是本地可执行文件。转换过程要做的事包括但不限于算子映射（把 ONNX 里的算子逐一映射到 NPU 支持的算子）、量化（把 FP32 权重转成 INT8 或 INT16）、权重布局重排（适配 NPU 内部的存储访问模式）。

我用的是一个实际案例来理解这件事。一个 YOLOv5s 模型，PyTorch 版本下权重文件大概 28MB，转成未量化的 RKNN 文件大约也是 28MB 上下，但转成 INT8 量化版之后就降到 7.5MB 左右。推理速度在 RK3568 上从 380ms 左右降到 120ms 左右，帧率从不到 3 提升到 8 上下。这个差距在边缘场景里会直接决定方案能不能落地。

转换动作必须在 PC 上完成还有一个原因：RKNN-Toolkit2 的完整版依赖 x86_64 架构的 Python 环境，官方提供 docker 镜像，也支持原生 pip 安装。它内部调用了瑞芯微的编译器库，这套库没有 ARM 版本。如果你尝试在板子上直接 pip install rknn-toolkit2，大概率会碰到 not supported 或者编译失败——不是官方不努力，是架构限制摆在那里。

2.2 传输层：三种把 RKNN 模型送进板子的方式

模型转换完成之后，.rknn 文件需要从 PC 传到板子上。根据开发阶段不同，我用过三种方式，各有各的适用场景：

第一种是 adb push。这种方式最简单，适合板子开启了 adb 调试、通过 USB 线直接连接 PC 的情况。在 PC 端执行 adb push ./yolov5s.rknn /userdata/ 就能把文件推过去，再 adb shell 登录板端确认文件大小和 MD5 校验一致。这种方式适合小体积模型（几十 MB 以内）的快速迭代。

第二种是 scp 传输。板子连接到局域网后，通过 SSH 服务直接传，适合板子和 PC 不在同一物理位置、只能通过网络互通的场景。命令是 scp ./yolov5s.rknn root@192.168.1.100:/userdata/。注意 RK3568 的官方固件默认可能没开启 SSH 的 root 登录，需要先在板端的 /etc/ssh/sshd_config 里设置 PermitRootLogin yes。

第三种是 NFS 挂载。这种方案适合模型文件非常多、反复微调迭代的场景。在 PC 端配置 NFS 服务器，把存放 RKNN 模型的目录共享出去，板子端 mount -t nfs 192.168.1.100:/home/user/rknn_models /mnt/models，之后模型文件在 PC 端更新，板端直接就能看到最新版本，省去反复传输的麻烦。这也是嵌入式内核调试时常用的 rootfs 挂载思路，原理一致。

这里需要提醒的是：传输方式不影响推理性能，因为 RKNN 模型加载到内存之后，输入输出数据都在板端 DDR 里流转。传输只是部署阶段的事。

2.3 板端推理： RKNN Runtime 的运行角色

板端负责跑推理的组件叫 RKNN Runtime，它是一套 C/C++ 运行时库，对应的 Python 接口是 RKNN 的 Python API（在板端的 Python 环境中 import rknn）。它做的事情是：读取 RKNN 模型文件，加载到 NPU 驱动层，初始化输入输出缓冲区，然后调用 rknn_inputs_set、rknn_run、rknn_outputs_get 这一套 API 完成一次推理。

这里要特别理解一个概念：板端并不关心模型是从 PyTorch 转的、还是从 TensorFlow 转的、或者是 Paddle 转的。RKNN Runtime 只认 RKNN 格式本身。这就是转好一次、到处部署的好处——只要你生成的 RKNN 文件和板端 Runtime 版本兼容，跑什么框架的原始模型都无所谓。

三层分工的边界清晰之后，调试思路就顺了：模型精度有问题，先回 PC 端看转换日志、量化配置；板端推理崩溃，先查板端 Runtime 日志和设备节点是否正常；模型跑得慢，优先看量化配置、输入分辨率、NPU 频率和 CPU 占用。别一上来就怀疑板卡硬件坏了，我在早期调试中最浪费时间的就是定位层搞混。

3. PC 端转换环境的完整搭建：从 Python 版本到 RKNN-Toolkit2 安装

3.1 环境版本选型：这一步错了后面全白搭

RKNN-Toolkit2 的版本更新节奏比较快，不同版本支持的 Python 版本和板端 Runtime 版本都不同。我踩过最深的坑就是 2023 年初用 RKNN-Toolkit2 1.4.0 转换模型，烧到板子上之后 Runtime 1.3.0 报 unsupported version，重新回到 PC 端查了文档才发现是转换端和推理端的版本 API 不匹配。

当前这个阶段（系列文章写作时），我推荐使用的组合是：

• PC 端系统：Ubuntu 20.04 x86_64 或 Ubuntu 22.04 x86_64
• Python 版本：3.8 或 3.10（注意 3.9 在某些依赖上容易出问题，我自己在 3.9 上遇到过 numpy 版本打架的崩溃）
• RKNN-Toolkit2 版本：1.5.2 或更新版本（以官方 GitHub Releases 为准）
• 板端 RKNN Runtime 版本：与转换工具版本保持一致（1.5.2 配 1.5.2）

安装方式我建议直接用 docker 镜像，避免污染你 PC 上已有的 Python 环境，也避免 numpy、onnx、tensorflow 这些库之间互相干扰。如果你像我一样懒于敲 docker 命令，也可以直接创建虚拟环境装原生版本。

3.2 Docker 方式快速起步

官方仓库（airockchip/rknn-toolkit2）的 docker 目录下提供了 Dockerfile_ubuntu_20.04，构建命令大致是：

cd rknn-toolkit2/docker docker build -t rknn-toolkit2:1.5.2 -f Dockerfile_ubuntu_20.04 .

构建完成后，把 PC 上存放模型的工作目录挂载进容器：

docker run -it --rm \ -v $(pwd):/work \ -w /work \ rknn-toolkit2:1.5.2 \ /bin/bash

进入容器之后，Python 环境里已经预装了 rknn-toolkit2 及其所有依赖，直接 import 验证：

python -c "from rknn.api import RKNN; print('ok')"

如果打印出 ok，说明环境正常。

3.3 原生 pip 安装方式

如果你更习惯原生环境，可以在 Python 虚拟环境中安装：

python3 -m venv ~/rknn-env source ~/rknn-env/bin/activate pip install --upgrade pip pip install rknn-toolkit2==1.5.2

这里有一个非常容易踩的坑：rknn-toolkit2 的 pip 依赖里包含固定版本的 numpy、opencv-python、onnx、onnxruntime，默认 pip 会尝试自动解决，但如果系统里装了 conda 或者已有高版本 numpy，很可能导致冲突。我的实际经验是：在干净的虚拟环境里安装，不要复用你平时做训练用的环境。

装完后同样验证：

python -c "from rknn.api import RKNN; print(rknn_toolkit_version = RKNN().get_version())"

能输出版本号就说明核心包没问题。

3.4 环境验证：用官方 demo 跑通第一个转换流程

环境装好不等于会用了。我强烈建议先把官方自带的 resnet18 示例跑通，流程是：

cd rknn-toolkit2/examples/onnx/resnet18 python test.py

这个脚本会下载 resnet18 的 ONNX 模型，然后自动完成转换、推理、输出验证结果和耗时统计。如果这一步能全绿通过，PC 端转换环境就算彻底打通了。

我当时在这个环节卡了一下午，卡住的点非常蠢：脚本运行时提示 urlopen error [Errno -2] Name or service not known，原因是模型下载环节依赖外网访问。如果网络受限，需要提前把 resnet18.onnx 下载好放到 models 目录，并在脚本里把 download 相关代码注释掉，直接加载本地文件。

4. 15 条 RK3568 边缘 AI 开发高频命令：按使用场景分组说明

4.1 场景一：PC 端转换环境相关命令

命令 1：激活转换环境

source ~/rknn-env/bin/activate

转换之前必须先激活虚拟环境，否则 import rknn 会直接 ModuleNotFoundError。如果你用 docker，这一步对应的是进入已在正确 Python 环境中的容器。

命令 2：在 Python 脚本里创建 RKNN 对象并配置目标平台

from rknn.api import RKNN rknn = RKNN() ret = rknn.config(target_platform='rk3568')

config 里的 target_platform 参数决定转换出来的模型针对哪个平台优化。rk3568 必须写成小写字母加数字，写成 RK3568 也不会报错，但会有警告。

命令 3：加载 ONNX 模型

ret = rknn.load_onnx(model='./yolov5s.onnx')

这一步会做 ONNX 模型解析和图优化，如果 ONNX 文件包含动态 shape 或者新增的算子，这一步的输出日志会非常长。重点看 ERROR 开头的行。

命令 4：执行模型转换并导出 RKNN 文件

ret = rknn.build(do_quantization=True, dataset='./dataset.txt') ret = rknn.export_rknn('./yolov5s.rknn')

dataset.txt 里每行是一个图像路径，用于量化校准，通常选 50 到 200 张代表性图片。图片越接近真实业务场景，量化精度越稳。

命令 5：初始化板端运行时环境

ret = rknn.init_runtime(target='rk3568')

这条命令只有在 PC 和板子通过 USB 或网络连接成功后才能执行。它的作用是在 PC 端通过接口与板端 Runtime 建立通信，后续可以调用 inference 接口在真实 NPU 上跑推理验证。

4.2 场景二：板端环境准备与模型传输相关命令

命令 6：查看板卡运行状态

adb devices

如果 PC 上装了 adb 工具，通过 USB 连接板子后先执行这条命令，确认设备是否被识别。正常情况会显示一个设备序列号。如果显示 unauthorized，需要在板端弹窗中确认授权。

命令 7：adb 推送模型文件到板端

adb push ./yolov5s.rknn /userdata/

RK3568 官方开发板的 /userdata 分区是用户可写分区，适合存放模型文件和测试脚本。千万不要推到根目录或 /system 分区，这两种分区通常会因为只读导致 push 失败。

命令 8：通过 SSH 连接板端

ssh root@192.168.1.100

板子连上局域网后，查看板端 IP 可以用 adb shell ifconfig 或者板端开机日志。SSH 进入板端之后，后续操作完全是在 ARM Linux 环境里执行。

命令 9：NFS 挂载共享目录

mount -t nfs 192.168.1.100:/home/user/rknn_models /mnt/models

这条命令适合持续迭代模型文件的场景。使用前需要确认 PC 端 NFS 服务已启动、共享目录已配置、防火墙放行了相关端口。挂载成功后，在板端 /mnt/models 目录下 ls 应该能看到 PC 端的模型文件。

命令 10：检查板端 RKNN Runtime 版本

python -c "from rknn.api import RKNN; print(RKNN().get_version())"

板端安装的 rknn-toolkit-lite 或 rknn runtime 版本必须跟转换端匹配，否则推理阶段会出现 load model fail 或版本不兼容的错误。

4.3 场景三：模型推理与调试相关命令

命令 11：在板端执行 Python 推理脚本

python3 ./infer_yolov5s.py

执行前确认 Python 环境中已经安装 rknnlite 或对应的板端运行库。推荐使用 rknnlite，它是轻量版，专门为 ATK 等开发板预装。

命令 12：查看 NPU 使用率和温度

cat /sys/kernel/debug/rknpu/load

RK3568 的 NPU 使用率信息会输出到 debugfs 里，但通常需要 root 权限。如果这个路径不存在，可以在内核开启 rknpu 的相关 debug 配置。这个指标对性能调优很重要——如果 NPU load 一直跑不满但帧率上不去，问题大概率出在数据预处理或者后处理上。

命令 13：查看板端 CPU 核心频率

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq

RK3568 的 CPU 默认可能有大小核调度策略，查看各核心频率可以判断任务是否被调度到了高性能核。

命令 14：查看内存占用

free -h

推理模型加载到内存后，占用大小直接影响系统稳定性。YOLOv5s INT8 量化版跑起来大约占 200-400MB 内存，如果板子内存只有 2GB，需要重点控制模型大小和输入分辨率。

命令 15：关闭掉部分高频日志，提升推理稳定性

export RKNN_LOG_LEVEL=3

RKNN 的日志等级从 0 到 3，等级越低输出越详细。默认级别会打印大量调试信息，在跑正式推理时建议调到 3，减少 IO 开销，实测对帧率有 5% 左右的提升。

5. 从 ONNX 到 RKNN 的完整转换实操：以 YOLOv5s 为例

5.1 准备工作：导出 ONNX 和准备量化数据集

首先在训练环境里把 PyTorch 的 YOLOv5s 导出为 ONNX：

python export.py --weights yolov5s.pt --include onnx --opset 12 --simplify

注意 opset 版本建议设置在 12 到 16 之间。opset 太高，RKNN-Toolkit2 的算子兼容层有可能解析不了；opset 太低，某些子图又不会被完整展开。我实际测试下来 opset=12 搭配 YOLOv5 7.0 版本的导出脚本是最稳的。

量化数据集是转换流程里最容易被忽略的一环。我的做法是在训练集之外单独抽 100 张覆盖真实场景的图片，放到一个目录里。然后生成 dataset.txt：

find ./calibration_images -name "*.jpg" > dataset.txt

生成的 dataset.txt 每行都是绝对路径或相对于脚本工作目录的相对路径，建议统一用绝对路径，避免转换时 FileNotFound。

5.2 转换脚本完整范例

from rknn.api import RKNN rknn = RKNN() # 配置目标平台为 RK3568 ret = rknn.config( target_platform='rk3568', mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], quantized_dtype='w8a8', quantized_algorithm='normal', ) assert ret == 0, 'config failed' # 加载 ONNX 模型 ret = rknn.load_onnx(model='./yolov5s.onnx') assert ret == 0, 'load_onnx failed' # 构建 RKNN 模型并做 INT8 量化 ret = rknn.build( do_quantization=True, dataset='./dataset.txt', rknn_batch_size=1, ) assert ret == 0, 'build failed' # 导出 RKNN 文件 ret = rknn.export_rknn('./yolov5s.rknn') assert ret == 0, 'export failed' # 释放资源 rknn.release()

这段脚本里有两个细节需要展开：

mean_values 和 std_values 的配置必须跟模型训练时的预处理一致。YOLOv5 的训练代码里对输入图像的预处理是 /255 归一化，对应到这里就是 mean 填 0 或 0.0、std 填 255。如果填错，模型推理结果的置信度会整体偏低，物体会检不出来。

quantized_dtype 参数在较新的工具链版本里才支持，w8a8 表示权重和激活都量化成 INT8。如果你的工具链版本较老、不认识这个参数，直接略过也行，默认就是 w8a8。另一个参数 quantized_algorithm 可选 normal 或 mmse，mmse 量化精度通常更好，但转换耗时也更长，对于 YOLO 类检测模型我建议先用 normal，精度不够再换 mmse。

5.3 loader 阶段常见报错与处理思路

我在这个阶段遇到过的报错可以列成一个常用排查表：

报错信息	原因	处理方式
Load onnx model failed	ONNX 文件损坏或算子不兼容	先用 onnx.checker 和 onnxsim 验证模型
RKNN model not exist	build 之前没有加载模型	检查 load_onnx 是否执行成功
Config target_platform is invalid	目标平台名称不合法	确认 target_platform 值为 rk3568 或 rk3588
Quantization failed: no dataset	dataset.txt 为空或路径错误	检查文件是否存在、每行是否是有效图片
export failed: file exists	输出文件已存在且被占用	删除旧文件或换输出文件名

这些报错看起来五花八门，实际上绝大多数是环境层面或者文件路径层面导致，不需要改代码。我在次踩到 onnx 模型本身有个动态 shape，导致 load_onnx 后某些 shape 打印成 None，当时差点重训模型，后来用 onnx-simplifier 固定 batch size 为 1 就解决了。这里提示一下：边缘部署场景里 99% 都用固定 batch size=1，导出 ONNX 时就直接固定，不要用动态维度。

6. 拿到 RKNN 文件之后：板端推理脚本的关键写法

6.1 板端推理的最小 Python 脚本

模型文件传到板子上之后，可以在板端的 Python 环境写一个最小推理脚本：

from rknnlite.api import RKNNLite rknn_lite = RKNNLite() # 加载 RKNN 模型 ret = rknn_lite.load_rknn('./yolov5s.rknn') assert ret == 0, 'load rknn failed' # 初始化 runtime，核心设置 ret = rknn_lite.init_runtime(core_mask=RKNNLite.NPU_CORE_0_1_2) assert ret == 0, 'init runtime failed' # 读取并预处理图像 import cv2 import numpy as np img = cv2.imread('./test.jpg') img_resized = cv2.resize(img, (640, 640)) img_input = img_resized[:, :, ::-1] # BGR -> RGB # 推理 outputs = rknn_lite.inference(inputs=[img_input]) print(outputs)

这里核心设置是 core_mask，它决定了模型跑在 NPU 的哪个核心上。RK3568 的 NPU 内部有三个核心可以并发跑同一个模型，也可以分别跑不同模型。默认情况下 init_runtime 不传 core_mask 的话，由调度器自动分配。但如果你同时开了多个推理线程，需要手动指定核心，否则两个线程可能抢占同一个核心导致性能骤降。

6.2 从裸输出到检测结果：后处理别漏了

很多人拿到 outputs 后直接看到的是一堆浮点数，完全不知道转成检测框。

YOLOv5 的输出是一个 shape 为 [1, 25200, 85] 的张量，其中 25200 是 3 个尺度下的 anchor 总和（80x80 + 40x40 + 20x20 再乘 3），85 是 4 个坐标 + 1 个置信度 + 80 个类别概率。后处理需要做的是 NMS（非极大值抑制）筛选。

我这里直接用 Python 写一个简化版后处理思路：

def postprocess(outputs, conf_thres=0.25, iou_thres=0.45): # outputs shape: [1, 25200, 85] preds = outputs[0] scores = preds[:, 4] # 先按置信度过滤 mask = scores > conf_thres preds = preds[mask] boxes = preds[:, :4] cls_conf = preds[:, 5:] * preds[:, 4:5] cls_ids = cls_conf.argmax(axis=1) # 这里只是示例，实际 NMS 需要用 cv2.dnn.NMSBoxes 或者自己实现 return boxes, cls_ids

实际工程里我会建议直接用 cv2.dnn.NMSBoxes，逻辑简单、速度也快，不需要自己造轮子。后处理在 CPU 上执行，RGB 到 BGR 的转换、缩放、padding 都尽量用 OpenCV 的向量化操作，不要在 Python 层写 for 循环，不然 CPU 会成为瓶颈。

6.3 板端推理性能验收参考

我最终在 RK3568 上验证的场景是 YOLOv5s，输入 640x640，INT8 量化，单线程推理：

指标	数值
单帧推理耗时	约 120ms
帧率	约 8 FPS
加载模型耗时	约 600ms
内存占用	约 280MB

这个性能对 0.8T 算力的 NPU 来说基本正常。如果要做实时视频流检测，需要优化输入分辨率（降到 416 或 320）、开启多线程并发跑，或者用更轻量的模型如 YOLOv5n、YOLOv6n。我试过用 YOLOv5n 在同样条件下跑，帧率能到 14-15 FPS 左右。

7. 转换链路上的常见坑与避坑经验

7.1 版本匹配：转换工具版本与板端 Runtime 版本是一一对应的

这是整个 RKNN 生态里最容易踩、且后果最严重的一个坑。转换工具 1.5.2 转出来的 RKNN 模型文件，如果拿到板端跑的 Runtime 是 1.4.0 或更低，大概率会出现 load model fail 或者 aborted 崩溃。这两个组件之间有一个协议层，每次版本升级都可能引入格式变化，新旧不兼容是常态。

我的解决办法是：在 PC 端的转换脚本里，每次转换完都通过 init_runtime 的接口去验证一遍模型能在板端正常加载，再交付给后续的推理程序。如果公司里有多台机器，建议做一个统一的版本 checklist，包括 Python、RKNN-Toolkit2、板端 rknnlite 三个版本号，全部对齐后再开始。

7.2 量化校准：校准集图片数量太少，检测精度会“断崖式”下跌

有次我图省事，从测试视频里抽了 20 帧画面做量化校准集，结果转出来的模型在板端跑，置信度普遍从 0.85 掉到 0.3 左右，好多目标直接漏检。原因是这 20 帧画面内容太相似，无法反映真实业务中的光照、角度、遮挡差异，量化时计算出的激活值动态范围与真实分布不匹配。

校准集至少要覆盖以下维度：

• 不同亮度场景（白天、夜间、逆光）
• 不同距离和尺度的目标
• 尽量贴近实际业务的摄像头视角

100 张起步，200 张比较稳。这些图片不需要标注，只需要是真实场景的 raw 图像，这一点很多人会忘了。

7.3 算子兼容性：遇到不支持的算子怎么办

YOLO 系列的模型结构相对常规，但如果你的模型里有自定义 op（自定义损失函数、自定义激活函数、ROI Align 等），转换阶段 PC 端会报 unsupported node type。处理方法优先级：

第一选择：在导出 ONNX 时把这些自定义 op 替换成标准算子，比如把 SiLU 换成 swish 的标准表达； 第二选择：在 RKNN-Toolkit2 里增加自定义 op 的解析规则（较复杂，需要熟悉工具链内部机制）； 第三选择：把不支持的算子保留在 CPU 上计算。但需要通过 RKNN 的自定义层功能让模型混合跑 NPU 和 CPU。

实际案例中，我最常遇到的是 Focus 层。YOLOv5 早期版本里的 Focus 层，在 ONNX 导出时有时会变成一个比较复杂的切片拼接组合。转换时 RKNN 也能够处理，但效率不高。我后来直接在导出 ONNX 前把 Focus 换成普通的卷积下采样，模型参数几乎没变，推理速度反而有提升。

这里不展开具体代码了，核心思路是：转换前先用代码检查模型里有哪些算子类型，提前评估工具链是否支持。我常用 onnx_graphsurgeon 来遍历节点类型，打印出不在白名单里的算子，这样能省去大量反复试错的时间。

8. 个人实测后的几点总结性建议

8.1 建议一：从一开始就建立“版本四件套”清单

我建议每个项目开始前把下面四项版本号写在一个文档里，后续所有联调以这份清单为准：

• RKNN-Toolkit2（PC 端）版本号
• rknnlite / RKNN Runtime（板端）版本号
• Python 主版本（PC 和板端可能不同，但要记录）
• ONNX 导出时使用的 opset 版本

四个版本只要有一个变化，就要重新跑一遍完整的转换和推理验证流程。尤其是板端直刷官方系统后，预装的 Runtime 版本可能和你正在用的转换工具不匹配。

8.2 建议二：用 docker 做转换环境，能省下大量“环境地狱”的时间

我后来把 RKNN-Toolkit2 的 docker 镜像固化成一个项目模板，所有新来的工程师直接拉镜像进入容器操作。这样不管 PC 是 Ubuntu 20.04 还是 22.04，不管系统里装了多少其他 Python 包，模型转换环境始终是干净的。这种做法对团队协作尤其重要——否则你今天能跑的脚本，换台机器可能就莫名其妙报 Segment Fault。

8.3 建议三：先在 PC 端模拟运行验证，再上板子

RKNN-Toolkit2 在 PC 端可以不依赖板子进行模拟推理。在 init_runtime 时不传 target='rk3568'，而是传 target=None，工具会调用模拟器做推理，输出的结果可以用来和板端结果做对比。这一步虽然比真实 NPU 推理慢，但能提前发现“模型转换是否正确”的问题，不用反复传文件到板子上。

我实测过卷积层计算的输出差异，模拟器结果和板端实际推理结果在 INT8 下基本一致，误差在千分之一以内。如果两者差异很大，说明你的板端 Runtime 版本有问题，或者模型文件根本传错了。

8.4 建议四：性能优化优先级要按“数据流瓶颈”来看

如果在板端推理达不到实时要求，我的调优顺序是这样的：先看输入图片的预处理时间（CPU 上做 resize、颜色转换容易成为瓶颈），再看推理时间（NPU 占用率、模型结构），最后看后处理时间（NMS 在 CPU 上跑得慢的话用 cv2.dnn 替代）。

不要一上来就换轻量化模型——那会牺牲精度。很多时候把输入从 640x640 降到 416x416，推理耗时直接减半，而精度损失在多数业务场景里可接受。这是我实测在 RK3568 上最有效的提帧手段。

坦白说，RK3568 这颗芯片在边缘 AI 领域的性价比确实很高，但它的学习曲线并不算平缓。核心卡点不是硬件接线或者系统启动，而是模型转换这条链路上的细节。把 PC 转换、传输、板端推理这三层分工弄清晰，再把那 15 条命令吃透，你基本就能脱离教程自己跑通一个完整的边缘检测项目了。下一步我会接着写板端摄像头取流和视频流推理的实战细节，特别是 RK3568 调试 OV5695 摄像头的设备树配置，以及用 NFS 挂载 rootfs 做断电保护的经验。