在嵌入式 Linux 板子上做 AI 推理最折腾人的往往不是模型本身而是环境。上一篇我初步理清了 RK3588 部署 YOLOv5s 的整体思路这一篇直接落地专门讲清楚环境搭建和模型获取这两个环节。RK3588 的 NPU神经网络处理单元性能很不错6 TOPS 的算力跑 YOLOv5s 完全够用但它的工具链和 X86 主机上的 PyTorch 体系是两套逻辑搞不明白这一点后面每一步都会踩坑。这篇文章面向的是准备在 RK3588 上做目标检测开发的人。不管你是之前只跑过服务器端的模型还是刚接触嵌入式 AI这篇内容会把从主机端环境准备、模型下载导出到开发板端系统烧写和运行库安装的过程完整走一遍。涉及版本选择、依赖安装、参数配置和常见报错处理都是实打实操作过的记录可以直接照着来。1. 环境搭建的整体思路为什么这是一套双环境体系1.1 主机端负责训练转模型开发板端负责加载推理RK3588 部署 YOLOv5s说白了要准备两套环境一套是开发主机通常是 X86 架构的 Ubuntu 系统另一套是 RK3588 开发板本身。两套环境的职责完全不同千万别想用一套环境省事。主机端主要负责三件事跑 YOLOv5 的 PyTorch 前向推理做验证、把 PyTorch 模型导出为 ONNX、再通过 RKNN-Toolkit2 把 ONNX 转换成 RK3588 NPU 能识别的 RKNN 格式。开发板端则是把 RKNN 模型加载到 NPU 上执行推理这个过程依赖 RK3588 上的 librknnrt 运行库和 Python 的 rknn 接口。很多人犯错的地方在于试图在 RK3588 板子上直接跑 PyTorch或者用板子上的 CPU 跑 YOLOv5s 的原始模型。不是说完全不行而是效率极低。RK3588 的 CPU 跑 YOLOv5s处理一帧 640x640 的图片大概需要一两秒而 NPU 跑经过 RKNN 转换后的模型耗时能缩短到二三十毫秒差距非常明显。另一个常见误区是把 RKNN-Toolkit2 装到板子上做模型转换这个工具链依赖很多 X86 下的 Python 库在 ARM 板子上装又慢又容易出兼容性问题完全没有必要。所以我一开始就确定下来主机和板子分开配置各干各的活这条路走通之后几乎不会再遇到环境层面的坑。1.2 版本选型是环境搭建的第一步也是最关键的一步环境搭建前必须先把版本定清楚因为 RKNN-Toolkit2 对 Python 版本、Ubuntu 版本、甚至 NumPy 版本都有要求。我第一次搭建时没看官方文档的版本约束直接在 Python 3.10 下装 RKNN-Toolkit2结果装完之后转换模型时一直报 NumPy 相关的错误折腾了整整一天才定位到是版本不匹配的问题。这里直接给出我实测稳定的版本组合组件推荐版本说明主机系统Ubuntu 20.04 / 22.0418.04 也可以但部分依赖包比较旧Python3.8 ~ 3.10RKNN-Toolkit2 v2.x 都支持RKNN-Toolkit22.1.0 及以上建议用官方 release 的最新版PyTorch1.12 ~ 2.0用于跑 YOLOv5s 原始模型验证NumPy1.23.5 及以下高版本 NumPy 会导致 RKNN 兼容性报错rknpu2对应的库版本板端运行库需和工具链版本对应参考官方的推荐RKNN-Toolkit2 2.x 系列支持 Python 3.8~3.10这个区间比较稳。我实际用的是 Python 3.10 RKNN-Toolkit2 2.2.0 PyTorch 2.0这套组合在模型导出和转换阶段没出现过版本兼容性问题。提示如果主机已经装了 Anaconda强烈建议单独建一个虚拟环境给 RKNN 相关的工作使用。conda create -n rknn python3.10不要和深度学习的其他环境混在一起否则依赖冲突早晚会找上你。另外YOLOv5s 的版本选择同样要提前定。目前网络上有大量第三方修改版我不太建议在起步阶段用因为 RKNN 工具链对模型算子结构的支持是有限制的第三方版本很可能引入了 RKNN 无法解析的自定义算子。直接用官方 YOLOv5 仓库的 6.0 或 6.1 release 版本最省心后续导出 ONNX 时遇到算子兼容问题的概率最小。我在初版实践里就是直接用了 YOLOv5 6.1 版本搭配官方yolov5s.pt权重文件这条路是最顺的。2. 主机端环境搭建PyTorch 与 RKNN-Toolkit2 的安装全流程2.1 虚拟环境与基础依赖安装主机环境的搭建按顺序来不要跳步。首先是创建虚拟环境并激活conda create -n rknn python3.10 -y conda activate rknn然后安装 PyTorch。我选择的是 PyTorch 2.0 的 CPU 版本为什么不用 GPU 版本因为在这个流程中PyTorch 只用来做模型前向验证也就是看看 YOLOv5s 在标准 PyTorch 环境下能不能正常出检测结果这个过程用 CPU 跑一两张图片就够了没必要引入 CUDA 相关的驱动和库来增加变数。pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu接着安装 RKNN-Toolkit2。这里有两种方式一种是通过 pip 直接安装官方发布的 wheel 包另一种是从 GitHub 拉 RKNN-Toolkit2 仓库源码然后本地安装。两种我都试过pip 方式最简单仓库方式的好处是源码里面有完整的 example 目录和文档。# pip 方式 pip install rknn-toolkit22.2.0 # 仓库方式 git clone https://github.com/airockchip/rknn-toolkit2.git cd rknn-toolkit2/rknn-toolkit2 pip install -r requirements_cp310-2.2.0.txtpip 方式安装完成后需要确认一下关键依赖是否都装好了。直接用pip list | grep rknn查看也可以运行 Python 交互环境导入试一下from rknn.api import RKNN如果没有报错说明工具链的主库已经就绪。这里有一个经常被忽略的细节RKNN-Toolkit2 依赖onnx、onnxoptimizer、onnxsim这些 ONNX 处理相关的库以及opencv-python。pip 方式安装时这些依赖一般都会自动拉下来但如果你之前手动改过环境里的包版本就有可能出现依赖缺失或者版本冲突。遇到这种情况不要一个个手动装直接用requirements_cp310-2.2.0.txt文件重新统一安装是最有效的。2.2 测试 RKNN-Toolkit2 是否真的安装成功安装完之后我建议用官方自带的一个最小测试流程来验证不要直接上手转换 YOLOv5s。原因很简单YOLOv5s 的模型结构相对复杂如果转换失败不好判断是安装问题还是模型问题。先跑通一个最简单的模型比如官方 examples 里的 resnet18 测试能排除很多干扰因素。进入 RKNN-Toolkit2 仓库的 examples/resnet18 目录cd examples/resnet18 python test.pytest.py这个脚本会下载 resnet18 的 ONNX 模型然后完成转换、推理、精度对比的完整流程如果输出结果中显示accuracy: 1.0这样类似的结果或者至少没有报错说明工具链安装成功可以进入模型获取和转换环节了。这一步的判断标准很重要不是运行了不报错就行而是要明确看到模型加载、量化、推理这几个阶段都正常走通。我见过有人import rknn成功就以为环境装好了结果真正转换时才发现缺少某个依赖库白白浪费排查时间。3. 模型获取与导出从 YOLOv5s 到 ONNX 的完整过程3.1 获取官方 YOLOv5s 权重文件YOLOv5s 模型获取这一步相对简单官方仓库直接给出了下载方式。克隆 YOLOv5 v6.1 的代码仓库然后用仓库里的下载脚本拉权重git clone -b v6.1 https://github.com/ultralytics/yolov5.git cd yolov5 pip install -r requirements.txt这里要注意requirements.txt里的依赖版本需要和自己环境里的 PyTorch 匹配。YOLOv5 v6.1 对应的 PyTorch 版本要求是 1.7 以上实测 PyTorch 2.0 也能正常跑通前向推理不需要特意降低版本。权重文件的获取有两种方式一种是直接下载官方预训练好的yolov5s.pt文件文件大小约 14 MB另一种是自己在自定义数据集上训练得到权重。对于部署链路实践来说直接用官方权重验证流程即可。如果你后续要部署自己的检测任务在模型导出这一步的操作是完全一致的因为无论权重来源如何导出 ONNX 的方式都一样。下载方式# 方式一从官方 release 下载需要科学网络环境这里不展开 # 方式二如果网络受限可以通过 pypi 镜像等方式尝试实际上如果你在国内网络环境直接访问 GitHub release 下载权重文件确实容易断线。一个可行的替代方案是使用 hf-mirror 相关的镜像站或者通过一些第三方存储下载后再校验文件 MD5 是否与官方一致。这里我不做过多展开记住一个原则只要能拿到与官方一致的yolov5s.pt文件即可不要使用来路不明的变体文件。3.2 导出 ONNX 时的重要参数选择拿到yolov5s.pt后接下来是导出 ONNX 文件。YOLOv5 官方仓库提供了export.py脚本但直接导出出来的 ONNX 并不适合 RKNN 工具链转换需要调整几个关键参数。关键指令如下python export.py --weights yolov5s.pt --include onnx --img-size 640 640 --batch-size 1 --opset 12 --simplify逐个解释这几个参数--img-size 640 640输入尺寸固定为 640x640这是 YOLOv5s 的标准输入尺寸也是后续在 RK3588 上推理时使用的分辨率。--batch-size 1导出 batch 为 1 的 ONNX 模型RKNN 转换时对动态 batch 的支持不如静态 1 稳定这里直接锁死。--opset 12ONNX 算子集版本选择 opset 12。RKNN-Toolkit2 对 opset 12 的支持最成熟太高比如 17或太低比如 9都可能在转换时出现算子不支持的情况。--simplify开启 ONNX Simplifier这一步很重要。YOLOv5 导出的 ONNX 原始结构比较冗余存在大量 Identity、Shape 等冗余算子通过简化可以去掉这些无关节点降低后续 RKNN 转换的报错概率。我实测的结果是直接不加--simplify的 ONNX 文件在 RKNN 转换时偶尔会出现 Reshape 相关的解析问题加了--simplify之后转换一次性通过。提示--simplify依赖onnx-simplifier这个 Python 包。如果执行 export 时提示找不到onnxsim需要先pip install onnx-simplifier。导出完成后在yolov5目录下会生成yolov5s.onnx文件。导出之后建议顺手用 Netron 看一遍模型结构重点确认输入节点名称通常是images和输出节点数量YOLOv5s 有 3 个输出分别是 P3、P4、P5 特征层的检测头。输入输出节点的名称在后续编写 RKNN 配置时都需要用到。3.3 图像预处理与后处理的一致性检查这里分享一个我踩过的深坑ONNX 模型的预处理方式和 RKNN 部署时的预处理逻辑如果不一致会导致推理结果完全错误但程序本身不报任何错误。YOLOv5 的标准预处理是图片缩放填充至 640x640、BGR 通道顺序、像素值归一化到 0~1、除以 255。在 RKNN 推理时需要保持一致。尤其要注意letterbox填充比例的计算保证缩放后填充到 640x640 时不会破坏原始图像的宽高比。后处理同样是关键每个检测头输出的特征是(batch_size, anchors, 41num_classes)的形式。RKNN 输出的张量结构与 ONNX 一致所以拿到 RKNN 输出后需要做置信度过滤、NMS 非极大值抑制等操作。这部分逻辑在后续部署环节中再展开这里提前说清楚是为了提醒大家导出模型时就要想着后处理怎么接不要到了板子上再想。4. RK3588 目标板环境准备系统烧写与运行库安装4.1 RK3588 板卡系统烧写以 Ubuntu 20.04 为例开发板端的环境搭建第一步是烧写操作系统。RK3588 官方和各硬件厂商普遍提供 Ubuntu 20.04 的镜像包括 RK3588 的 evb 板和一些第三方开发板流程基本一致。烧写前置准备一块 RK3588 开发板比如基于 RK3588 的 evb 或类似板卡一根 USB Type-C 数据线同时用于通信和供电部分板卡需要额外供电线一台运行 Windows 或 Ubuntu 的主机开发板厂商提供的烧写工具以及 Ubuntu 镜像文件如果你用的是 RK3588 evb 这类官方板通常会提供一个完整的烧写工具比如 Windows 上使用 RKDevTool或者直接在主机上使用官方提供的 Linux 烧写脚本。操作步骤大致是先安装 USB 驱动然后进入开发板的 MaskROM 或 Loader 模式一般是在板上短接特定触点或按住 recovery 键并通电接着在工具中选择镜像分区表文件和对应的 img 镜像最后执行烧写。这里需要特别提醒的一点烧写时如果使用 Windows 主机USB 驱动没装好的可能性很高。装驱动前注意先连接设备然后在设备管理器里查看有没有未知设备确认未知设备出现后再装驱动顺序反了会导致驱动无法生效。我第一次烧写时就是在设备没连接状态下先装了驱动结果系统一直不识别设备重新卸载驱动再反序操作一遍才解决。烧写成功之后板子会正常进入 Ubuntu 桌面或命令行界面。建议先核对系统版本lsb_release -a uname -m预期看到 Ubuntu 20.04 和aarch64架构输出。这个aarch64非常重要因为它决定了后续安装的所有软件包必须选 ARM64 版本不能在板子上使用 pip 安装 X86 的轮子当然 pip 一般会自动选 ARM64 的但某些需要编译的包就不那么友好了。提示部分 RK3588 板卡出厂预装的 Ubuntu 镜像是精简版可能没有 apt 源或者没有安装python3-pip。烧写完成后第一件事建议执行sudo apt update sudo apt upgrade确认系统基础软件都是完整的再进行后续安装。4.2 安装 Python 环境和 rknn runtime系统准备好后接下来安装板端的 Python 环境和 RKNN 运行库。板端不需要 RKNN-Toolkit2那个是主机端做模型转换用的只需要 RKNN 推理时依赖的 runtime 库。运行库的获取有两种方式方式一从 RKNN-Toolkit2 仓库中直接获取预编译运行库。在主机上克隆仓库后rknn-toolkit2/rknpu2/runtime/目录下包含了Linux/librknnrt.so和 Python 的rknnAPI 包。将这整个目录拷贝到开发板上然后# 安装 Python 运行库 cd Linux/rknn_server_aarch64 # 或其他实际目录名 pip install rknn-*.whl # 将 librknnrt.so 放到系统库目录 sudo cp runtime/Linux/librknnrt.so /usr/lib/ sudo ldconfig方式二直接用 pip 在板子安装rknn-toolkit-lite或者对应的rknpu2轮子包。具体包名和版本需要看你的 RKNN-Toolkit2 版本对应关系不同版本的接口有差异建议以官方 README 为准。装完运行库后用这个方式验证板端环境是否可用from rknnlite.api import RKNNLite print(RKNNLite loaded)注意板端导入的是rknnlite和主机端的rknn导入名不同。两个模块的功能定位也不同主机端rknn负责模型转换和仿真推理板端rknnlite负责加载 RKNN 模型走 NPU 推理。4.3 开发板端的其他工具安装在板子上跑推理除了 RKNN 运行库还需要准备一些图像处理相关的依赖。因为实际部署时YOLOv5s 推理前后的图像缩放、填充、颜色空间转换都需要在板端完成。具体安装哪些取决于你的部署方案。如果你用 Python 脚本直接调用 RKNNLite那么需要安装numpy、opencv-python、Pillow如果你用 C/C 接口调用那么需要 OpenCV 的开发库以及各编译器工具链。sudo apt install -y python3-pip python3-dev pip install numpy opencv-python-headless这里我推荐用 opencv-python-headless 而不是 opencv-python原因很简单开发板往往不带显示器headless 版本不包含 GUI 相关模块安装体积更小依赖冲突也更少。如果你后续要做摄像头实时推理只需要额外安装opencv-python的 VideoCapture 功能即可实际 headless 版本也能调用 VideoCapture因为它依赖 GStreamer/V4L2 后端不依赖 GUI 模块。板端有一个坑需要特别提一下RK3588 的 Ubuntu 20.04 镜像在默认状态下可能会缺少一些基础的工具链如 gcc、make。如果后续有编译需求务必提前装好sudo apt install -y build-essential cmake git这个准备工作看似不起眼但到真正部署时如果编译某个库才发现没有编译器临时安装会比较耗时。5. 实际转换流程从 ONNX 到 RKNN 的完整操作记录5.1 编写 RKNN 转换配置文件在主机端准备好 ONNX 模型后用 RKNN-Toolkit2 进行转换。转换的核心逻辑很简单就是读取 ONNX 文件、配置输入信息、执行转换和量化、保存 RKNN 模型。但有几个配置参数会直接影响最终模型在板上的推理精度和速度必须仔细处理。下面是我实际使用的转换脚本的骨架省去加载模型逻辑聚焦关键配置from rknn.api import RKNN rknn RKNN(verboseTrue) # 配置模型输入信息 rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588 ) # 加载 ONNX 模型 ret rknn.load_onnx(modelyolov5s.onnx) assert ret 0, load onnx failed # 模型转换假设导出时用了 --opset 12 和 simplify ret rknn.build(do_quantizationTrue, datasetdataset.txt) assert ret 0, build failed # 保存 RKNN 模型 ret rknn.export_rknn(yolov5s.rknn) assert ret 0, export failed逐项解释一下参数mean_values和std_values这是预处理参数的直接映射。YOLOv5 的预处理是像素除以 255 归一化对应的mean_values为 0std_values为 255。如果你的模型用的是其他归一化方式例如 ImageNet 标准的 mean/std这里必须改成一致的数值否则精度会大幅下降。target_platformrk3588明确指定目标平台。如果写错了平台生成的 RKNN 模型在 RK3588 上可能无法加载或者 NPU 效率异常。do_quantizationTrue开启动态量化。RK3588 的 NPU 主要支持 INT8 计算所以 RKNN 工具链默认会把 FP32 模型量化为 INT8。YOLOv5s 全模型量化后精度通常会下降 1~3 个百分点在目标检测任务中这种损失是可接受的。如果你的检测任务对精度极其敏感可以暂时关闭量化转出 FP16 模型或不量化但推理速度会有所下降。我实测 RK3588 上 INT8 量化的 YOLOv5s 单帧推理大约 20~40msFP16 或 FP32 则要到 50ms 以上。dataset.txt文件是在量化时用来做校准的图像列表。每行一个图像路径推荐选择 100~300 张具有代表性的图片最好是实际检测场景中的图像图片过少会导致量化后精度波动较大图片过多则转换时间太长但精度提升有限。我在实际转换时用的是自己数据集中的 200 张图片内容包括不同光照、不同目标尺寸的场合这样量化时算出来的激活值分布会更接近真实推理场景。建议不要随便选几百张风景图做校准因为场景无关导致量化效果不稳定。5.2 转换过程中的常见报错与处理转换过程并不总是一帆风顺我在实践中遇到过的几个典型问题这里集中梳理报错 1onnx op xxx is not supported这个错误说明 ONNX 模型中包含了 RKNN 工具链不支持的算子。处理思路是首先检查 ONNX 版本是否为 float32某些导出工具会根据精度类型而变化算子其次检查是否有特殊算子如GridSample、MultilevelCrop等。YOLOv5s 官方版本在 opset 12 下一般不会触发这个错误。如果触发了考虑升级 RKNN-Toolkit2 版本或检查导出 ONNX 时是否开了某些额外优化选项。报错 2The shape of tensor is invalid或Reshape dimension mismatch这种大都是因为 ONNX 模型的动态维度问题。导出 ONNX 时如果 batch size 未被固定成 1或者 yolo 层带了一些动态 shape 的操作就会引发这类错误。规避方式就是在导出时恪守参数固定 batch1、固定输入尺寸、开启 simplify。报错 3量化后精度大幅下降原因常见于数据集文件和实际数据分布不符或者数据集图片分辨率与模型输入尺寸差异过大。通常是重新生成一个更贴合真实场景的dataset.txt把校准图像的分辨率统一到接近模型输入不要直接把 4K 图塞进去量化时会将图片 resize 到 640x640然后重新 build 一次就行。报错 4RKNN 模型在板上加载时报version mismatch这个大概率是板端 runtimelibrknnrt.so版本和主机端 RKNN-Toolkit2 版本不对应。解决方案很简单重新从与你 RKNN-Toolkit2 版本匹配的 rknpu2 中拉取对应的 runtime 库重新拷贝并 ldconfig。5.3 在板子上完成一次完整的推理验证转换完成后把yolov5s.rknn拷贝到开发板然后跑一个最简单的推理脚本验证全链路是否通顺。这一步的作用是打通模型加载 - 推理 - 输出结果的最小闭环暂时不管性能优化。板端推理脚本的原则是先在 CPU 上做一次相同预处理并保存中间结果再调用 NPU 推理确认两者输出一致。比较输出结果时不要苛求完全一致——INT8 量化后输出有小幅浮动是正常的重点看检测框和类别是否基本吻合。我在板端做首次验证时使用的流程大概是加载yolov5s.rknn到 RKNNLite 上下文读取一张测试图片按照 YOLOv5 的标准流程做 letterbox 缩放、BGR 归一化调用inference(inputs[img])得到输出将输出在 PC 上用解码脚本解析出检测框流程本身很简单但值得一提的坑是RKNNLite 的inference接口返回的是一个列表不同工具链版本的输出格式有细微差别比如有的直接返回检测结果张量有的还附带额外的输出节点信息。所以即便在板子上跑通了也建议先打印输出的 shape看它是否符合(1, 25200, 85)这类预期再接着做后处理。如果推理输出的 shape 对不上比如(1, 4, 84, 80)这种不要慌大概率是因为 yolo 模型在导出时某些参数如 nc 类别数改了但后处理没同步。我吃过这个亏后来统一用脚本检查每个输出维度的含义后再写后处理就再也没有在这个环节卡过。6. 常见问题与排查技巧实录部署过程中总有些问题是文档里不写的我这里集中记录几条实战经验。关于板子存储空间不足的问题RK3588 的 Ubuntu 20.04 是从 SD 卡或 eMMC 启动的很多板卡厂商分区较小烧写完成之后系统剩余存储往往只有几个 GB。如果在安装依赖时提示磁盘空间不足常见的报错是E: You dont have enough free space in /var/cache/apt/archives/这时做一件事先清理 apt 缓存sudo apt clean再使用sudo apt --fix-broken install修复依赖关系后重试。如果空间仍然紧张建议用df -h查看具体分区使用情况必要时扩展根分区。关于 NPU 算子生成失败的问题RKNN-Toolkit2 在 build 阶段报算子不支持或生成失败时除了升级工具链还有一个常见原因是target_platform参数填写过旧或过新。我们这里统一使用rk3588不要写成rk3588s或其他衍生型号。不同型号的 NPU 架构有细微差异写错会直接影响算子生成结果。关于主机端与板端 Python 版本不一致的问题在主机端写好的推理脚本拷贝到板端运行时如果两边 Python 版本差距过大且用到了较新的语法特性可能会出现解释错误。建议两边统一使用 Python 3.10这样测试过的脚本基本可以直接运行。关于librknnrt.so找不到的问题板端运行 Python 推理时报librockchip相关错误或者librknnrt.so: cannot open shared object file大概率是没有正确配置共享库路径。解决办法是确认librknnrt.so已经放到/usr/lib目录并且执行了sudo ldconfig同时可以在启动脚本里export LD_LIBRARY_PATH/usr/lib:$LD_LIBRARY_PATH双重保障。关于模型推理结果全为 0 的问题新手上路最常遇到的现象就是推理完了后处理时发现输出张量里全是 0 或者数值极小看起来模型没有识别能力。这个问题的根源九成是预处理不一致——比如把 RGB 当成 BGR 输入了或者用了std_values、mean的组合方式不同。排查方法是打印模型输出的最大值和最小值正常情况输出不会全是 0如果全为 0 则优先排查预处理打印一张经 RKNN 预处理后实际传给模型的图像保存下来肉眼确认。针对这些常见问题我把它们汇总成一个速查表方便后续排查定位现象可能原因排查方向转换时报算子不支持ONNX opset 版本过高或模型含特殊算子重新导出时使用 opset 12 并开启 simplify模型加载时报版本不匹配板端 runtime 与主机端工具链版本不一致对照 rknpu2 仓库重新拷贝运行库推理结果全为 0预处理参数不一致 / 输入格式错误核对 mean、std、通道顺序、letterbox板端报 librknnrt.so 缺失运行库未正确安装确认 librknnrt.so 路径并 ldconfig磁盘空间不足系统分区过小或缓存积累清理 apt 缓存、扩展根分区推理非常慢未使用 NPU / 使用了 CPU 模式确认用 RKNNLite 而非原始 PyTorch关于模型轻量化的一个经验YOLOv5s 在 RK3588 上已经算轻量但如果你希望进一步降低 NPU 负载可以在导出一个更小输入尺寸比如 416x416的 ONNX然后再转换 RKNN。代价是检测小目标的能力下降。具体取舍要根据你的实际业务场景和摄像头离目标距离来定。我个人的原则是能用 640 就不用 416因为 NPU 的算力余量在 YOLOv5s 这种模型上是很充足的没有必要为了几毫秒牺牲精度。7. 我的补充经验与下一步展望这一篇从环境搭建写到模型获取和转换整个链路已经是可运行的。但需要明确的是部署 YOLOv5s 到 RK3588 绝不止步于模型跑通。后续还有几个方向需要继续实践这里先留个标记第一个方向是后处理的完整优化和边界情况处理。当前测试阶段用的是最简单的解码方式实际部署时还需要处理多尺度检测、类别置信度阈值调整、NMS 参数调优、视频流逐帧推理的帧率控制等问题。尤其在 RK3588 上做视频流实时推理时解码和推理线程的分工、ZeroCopy 内存的使用、多线程缓冲队列的设计都会直接影响整体性能和稳定性。第二个方向是性能评测与调度参数优化。虽然 NPU 跑 YOLOv5s 已经很快但要想做得更到位还要关注 NPU 的频率设置、是否开启 CPU/NPU 的异构计算、RKNN 推理时的核心绑定策略。这些操作可以借助 RK3588 的官方 profiling 工具分析各阶段的耗时占比进一步找到瓶颈。第三个方向是大模型的本地部署思路。最近不少人在讨论 RK3588 上运行大语言模型的可行性比如通过 ollama 或者一些轻量级推理框架跑 qwen 系列小模型。这和 YOLOv5s 部署在底层工具链上是完全不同的路径但也说明 RK3588 这类开发板的可玩性很高值得持续折腾。回到当前这篇的核心环境搭建和模型获取是部署的地基地基稳不稳直接决定上层能盖多高的楼。实测下来RK3588 YOLOv5s 这套组合在工具链和硬件层面已经足够成熟真正的变数在于开发者手是否够稳、路径是否清晰。按照这篇文章的流程走一遍至少能保证你从一张白纸到模型在板端跑通的过程中不再被环境问题反复折磨。接下来我打算继续写全链路实践的后续部分到时候会把后处理、多线程推理和实际性能数据一起放出来欢迎有同样兴趣的一起交流。