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 root192.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_64Python 版本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-toolkit21.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_platformrk3568)config 里的 target_platform 参数决定转换出来的模型针对哪个平台优化。rk3568 必须写成小写字母加数字写成 RK3568 也不会报错但会有警告。命令 3加载 ONNX 模型ret rknn.load_onnx(model./yolov5s.onnx)这一步会做 ONNX 模型解析和图优化如果 ONNX 文件包含动态 shape 或者新增的算子这一步的输出日志会非常长。重点看 ERROR 开头的行。命令 4执行模型转换并导出 RKNN 文件ret rknn.build(do_quantizationTrue, dataset./dataset.txt) ret rknn.export_rknn(./yolov5s.rknn)dataset.txt 里每行是一个图像路径用于量化校准通常选 50 到 200 张代表性图片。图片越接近真实业务场景量化精度越稳。命令 5初始化板端运行时环境ret rknn.init_runtime(targetrk3568)这条命令只有在 PC 和板子通过 USB 或网络连接成功后才能执行。它的作用是在 PC 端通过接口与板端 Runtime 建立通信后续可以调用 inference 接口在真实 NPU 上跑推理验证。4.2 场景二板端环境准备与模型传输相关命令命令 6查看板卡运行状态adb devices如果 PC 上装了 adb 工具通过 USB 连接板子后先执行这条命令确认设备是否被识别。正常情况会显示一个设备序列号。如果显示 unauthorized需要在板端弹窗中确认授权。命令 7adb 推送模型文件到板端adb push ./yolov5s.rknn /userdata/RK3568 官方开发板的 /userdata 分区是用户可写分区适合存放模型文件和测试脚本。千万不要推到根目录或 /system 分区这两种分区通常会因为只读导致 push 失败。命令 8通过 SSH 连接板端ssh root192.168.1.100板子连上局域网后查看板端 IP 可以用 adb shell ifconfig 或者板端开机日志。SSH 进入板端之后后续操作完全是在 ARM Linux 环境里执行。命令 9NFS 挂载共享目录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/loadRK3568 的 NPU 使用率信息会输出到 debugfs 里但通常需要 root 权限。如果这个路径不存在可以在内核开启 rknpu 的相关 debug 配置。这个指标对性能调优很重要——如果 NPU load 一直跑不满但帧率上不去问题大概率出在数据预处理或者后处理上。命令 13查看板端 CPU 核心频率cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freqRK3568 的 CPU 默认可能有大小核调度策略查看各核心频率可以判断任务是否被调度到了高性能核。命令 14查看内存占用free -h推理模型加载到内存后占用大小直接影响系统稳定性。YOLOv5s INT8 量化版跑起来大约占 200-400MB 内存如果板子内存只有 2GB需要重点控制模型大小和输入分辨率。命令 15关闭掉部分高频日志提升推理稳定性export RKNN_LOG_LEVEL3RKNN 的日志等级从 0 到 3等级越低输出越详细。默认级别会打印大量调试信息在跑正式推理时建议调到 3减少 IO 开销实测对帧率有 5% 左右的提升。5. 从 ONNX 到 RKNN 的完整转换实操以 YOLOv5s 为例5.1 准备工作导出 ONNX 和准备量化数据集首先在训练环境里把 PyTorch 的 YOLOv5s 导出为 ONNXpython export.py --weights yolov5s.pt --include onnx --opset 12 --simplify注意 opset 版本建议设置在 12 到 16 之间。opset 太高RKNN-Toolkit2 的算子兼容层有可能解析不了opset 太低某些子图又不会被完整展开。我实际测试下来 opset12 搭配 YOLOv5 7.0 版本的导出脚本是最稳的。量化数据集是转换流程里最容易被忽略的一环。我的做法是在训练集之外单独抽 100 张覆盖真实场景的图片放到一个目录里。然后生成 dataset.txtfind ./calibration_images -name *.jpg dataset.txt生成的 dataset.txt 每行都是绝对路径或相对于脚本工作目录的相对路径建议统一用绝对路径避免转换时 FileNotFound。5.2 转换脚本完整范例from rknn.api import RKNN rknn RKNN() # 配置目标平台为 RK3568 ret rknn.config( target_platformrk3568, mean_values[[0, 0, 0]], std_values[[255, 255, 255]], quantized_dtypew8a8, quantized_algorithmnormal, ) 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_quantizationTrue, dataset./dataset.txt, rknn_batch_size1, ) 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 或 mmsemmse 量化精度通常更好但转换耗时也更长对于 YOLO 类检测模型我建议先用 normal精度不够再换 mmse。5.3 loader 阶段常见报错与处理思路我在这个阶段遇到过的报错可以列成一个常用排查表报错信息原因处理方式Load onnx model failedONNX 文件损坏或算子不兼容先用 onnx.checker 和 onnxsim 验证模型RKNN model not existbuild 之前没有加载模型检查 load_onnx 是否执行成功Config target_platform is invalid目标平台名称不合法确认 target_platform 值为 rk3568 或 rk3588Quantization failed: no datasetdataset.txt 为空或路径错误检查文件是否存在、每行是否是有效图片export failed: file exists输出文件已存在且被占用删除旧文件或换输出文件名这些报错看起来五花八门实际上绝大多数是环境层面或者文件路径层面导致不需要改代码。我在次踩到 onnx 模型本身有个动态 shape导致 load_onnx 后某些 shape 打印成 None当时差点重训模型后来用 onnx-simplifier 固定 batch size 为 1 就解决了。这里提示一下边缘部署场景里 99% 都用固定 batch size1导出 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_maskRKNNLite.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 再乘 385 是 4 个坐标 1 个置信度 80 个类别概率。后处理需要做的是 NMS非极大值抑制筛选。我这里直接用 Python 写一个简化版后处理思路def postprocess(outputs, conf_thres0.25, iou_thres0.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(axis1) # 这里只是示例实际 NMS 需要用 cv2.dnn.NMSBoxes 或者自己实现 return boxes, cls_ids实际工程里我会建议直接用 cv2.dnn.NMSBoxes逻辑简单、速度也快不需要自己造轮子。后处理在 CPU 上执行RGB 到 BGR 的转换、缩放、padding 都尽量用 OpenCV 的向量化操作不要在 Python 层写 for 循环不然 CPU 会成为瓶颈。6.3 板端推理性能验收参考我最终在 RK3568 上验证的场景是 YOLOv5s输入 640x640INT8 量化单线程推理指标数值单帧推理耗时约 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-Toolkit2PC 端版本号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 时不传 targetrk3568而是传 targetNone工具会调用模拟器做推理输出的结果可以用来和板端结果做对比。这一步虽然比真实 NPU 推理慢但能提前发现“模型转换是否正确”的问题不用反复传文件到板子上。我实测过卷积层计算的输出差异模拟器结果和板端实际推理结果在 INT8 下基本一致误差在千分之一以内。如果两者差异很大说明你的板端 Runtime 版本有问题或者模型文件根本传错了。8.4 建议四性能优化优先级要按“数据流瓶颈”来看如果在板端推理达不到实时要求我的调优顺序是这样的先看输入图片的预处理时间CPU 上做 resize、颜色转换容易成为瓶颈再看推理时间NPU 占用率、模型结构最后看后处理时间NMS 在 CPU 上跑得慢的话用 cv2.dnn 替代。不要一上来就换轻量化模型——那会牺牲精度。很多时候把输入从 640x640 降到 416x416推理耗时直接减半而精度损失在多数业务场景里可接受。这是我实测在 RK3568 上最有效的提帧手段。坦白说RK3568 这颗芯片在边缘 AI 领域的性价比确实很高但它的学习曲线并不算平缓。核心卡点不是硬件接线或者系统启动而是模型转换这条链路上的细节。把 PC 转换、传输、板端推理这三层分工弄清晰再把那 15 条命令吃透你基本就能脱离教程自己跑通一个完整的边缘检测项目了。下一步我会接着写板端摄像头取流和视频流推理的实战细节特别是 RK3568 调试 OV5695 摄像头的设备树配置以及用 NFS 挂载 rootfs 做断电保护的经验。