RK3588 端侧 AI 部署（一）：平台、NPU 与 RKNN 工具链#

这是一套基于 RK3588 的端侧 AI 学习笔记。内容来自 Coder-Dawn 的 B 站课程《嵌入式 AI 教程（基于 RK3588）》，并结合瑞芯微、ONNX 和 Ultralytics 的官方资料进行了补充。

整套笔记不以“跑出一个 Demo”为终点，而是希望真正打通下面这条链路：

1
训练框架模型
2
  → 导出并验证 ONNX
3
  → RKNN-Toolkit2 转换/量化
4
  → PC 模拟器与 RK3588 连板验证
5
  → Lite2 Python 原型或 RKNPU2 C/C++ 部署
6
  → 精度、性能、内存与稳定性测试
7
  → 摄像头、视频流和业务系统集成

版本说明：本文写于 2026-07-21。官方 airockchip/rknn-toolkit2 仓库此时标注的发布版本为 v2.3.2，但工具链会继续更新。实际安装时应以当前仓库的 README、Release、wheel 文件名和板卡 BSP 说明为准，不要把本文版本号当成永久要求。

一、先理解 RK3588 上各处理单元的分工#

RK3588 是一颗面向高性能嵌入式和边缘计算的 SoC。做视觉 AI 时，真正高效的系统通常不是只使用 NPU，而是多个硬件模块协同：

模块	适合承担的工作	不适合硬塞进去的工作
CPU	操作系统、I/O、业务逻辑、任务调度、部分前后处理	大规模重复张量计算
NPU	卷积、矩阵乘、激活、池化等神经网络推理	复杂分支、任意不受支持的算子
GPU	图形渲染和高度并行计算	代替所有 NPU 推理工作
RGA/2D	resize、裁剪、旋转、颜色转换、填充	模型推理本身
ISP/编解码器	摄像头图像处理、H.264/H.265/JPEG 编解码	通用业务逻辑
DDR	模型权重、输入输出和中间张量存储	低成本无限带宽

典型视频分析链路是：

1
摄像头/视频文件
2
  → ISP 或硬件解码
3
  → RGA 做颜色转换、resize、letterbox
4
  → NPU 推理
5
  → CPU 解码输出、NMS、业务判断
6
  → RGA/显示/编码/网络发送

如果只盯着 NPU 的推理时间，忽略解码、图像拷贝、预处理、后处理和显示，最后得到的 FPS 往往与真实应用相差很大。

二、NPU、CPU 和 GPU 到底有什么区别#

NPU（Neural Processing Unit）是为矩阵、卷积和张量数据流定制的处理器。与 CPU、GPU 相比，它牺牲一部分通用性，换取端侧推理的吞吐和能效。

对比项	CPU	GPU	NPU
核心特点	少量复杂核心、强控制能力	大量并行计算单元	张量和乘加数据流专用化
优势	通用、分支和系统任务强	并行生态成熟	AI 推理能效高
主要限制	张量吞吐有限	功耗和部署成本较高	依赖算子支持和厂商工具链
端侧职责	调度、I/O、前后处理	图形或特定计算	神经网络主体推理

RK3588 集成三个 NPU 核心，标称总算力约 6 TOPS。这里必须记住两件事：

TOPS 是特定数据类型和统计口径下的理论峰值，并不等于某个模型的实际 FPS。
三个核心不保证单次推理线性变快三倍。计算图切分、内存带宽、核心掩码、Context 数量和任务粒度都会影响结果。

实际选型应比较：任务精度、端到端延迟、持续吞吐、峰值内存、功耗和温度，而不是只比较 TOPS。

三、RKNPU 软件架构#

可以把 RKNPU 系统理解成三层：

1
应用层：Python/C/C++ 应用、RKNN API、Runtime
2
                       ↓
3
驱动层：RKNPU 内核驱动，负责内存、任务和硬件调度
4
                       ↓
5
硬件层：NPU 核心、片上缓存、总线和计算单元

上层程序不会直接控制 NPU 内部乘加单元，而是通过 Runtime 和驱动提交模型、输入张量与推理任务。

1. RKNN-Toolkit2#

运行在 x86 Linux 主机，主要负责：

加载 ONNX、PyTorch 等来源模型；
配置目标芯片、输入预处理和量化；
构建并导出 .rknn；
精度、性能、内存分析；
PC 模拟器或连接开发板快速验证。

2. RKNN-Toolkit-Lite2#

运行在 RK3588 板端，提供精简的 Python 推理接口。它适合快速原型和调试，但不负责把 ONNX 转为 RKNN。

3. RKNPU2 Runtime#

提供板端 C/C++ API 和动态库，适合正式产品、零拷贝、线程池、多路视频等工程部署。

4. RKNPU 内核驱动#

负责与 NPU 硬件交互。驱动、Runtime、rknn_server、Toolkit2 和模型格式必须兼容。

最容易记忆的对应关系是：

1
PC：Toolkit2 负责“做模型”
2
板端 Python：Lite2 负责“快速运行模型”
3
板端 C/C++：RKNPU2 负责“工程化运行模型”

四、必须认识的官方资料#

资料	用途
RKNN-Toolkit2 主仓库	安装包、文档、Lite2、RKNPU2 Runtime 和版本说明
RKNN 官方文档目录	Quick Start、Toolkit2 API、RKNNRT C API、算子支持表
RKNN Model Zoo	MobileNet、YOLO、OCR、语音等转换和 C/Python Demo
RKNPU2 Runtime 目录	板端 Runtime、头文件和示例
RKLLM	Qwen、DeepSeek 等大模型转换和运行
Netron	查看 ONNX/RKNN 等模型的输入、输出和计算图

早期的 rockchip-linux/rknn-toolkit2 和 rockchip-linux/rknpu2 仓库已经停止维护并迁移到 airockchip。搜索资料时要先确认链接是否仍属于当前主仓库。

五、模型从训练到板端的完整流程#

1. 定义验收指标#

在训练前先确定：

任务指标：Accuracy、mAP、Recall、漏检率等；
输入尺寸、摄像头路数和期望 FPS；
最大端到端延迟；
可接受的内存、功耗和温度；
是否要求离线运行、模型加密或动态输入。

2. 训练和导出#

训练得到 .pt 等框架模型，再导出 ONNX。导出后必须使用相同输入比较框架与 ONNX 输出，不能看到 ONNX 文件生成就直接进入 RKNN。

3. 转换 RKNN#

Toolkit2 会完成模型加载、图优化、量化、针对 RK3588 的编译和 .rknn 导出。输入布局、RGB/BGR、均值、标准差和量化校准集都可能影响最终精度。

4. 分阶段验证#

1
原框架结果
2
  ↕ 对比
3
ONNX Runtime 结果
4
  ↕ 对比
5
RKNN PC 模拟器结果
6
  ↕ 对比
7
RK3588 NPU 结果
8
  ↕ 对比
9
C/C++ 最终应用结果

每跨一层就比较一次输出，错误会比“全部完成后再调”容易定位得多。

5. 工程部署#

最后才进入摄像头、队列、线程、零拷贝、RGA、显示/编码和业务逻辑。此时模型正确性已经被单独验证，工程问题与算法问题不会混在一起。

六、开始实践前的板端检查#

在 RK3588 上执行：

1
uname -a
2
uname -m
3
lscpu
4
cat /proc/device-tree/compatible 2>/dev/null | tr '\0' '\n'
5
dmesg | grep -i rknpu

期望看到：

用户态架构通常为 aarch64；
设备树信息包含对应板卡/RK3588；
内核日志能找到 RKNPU 驱动初始化信息；
板卡具有足够散热和稳定供电。

再记录一个项目版本表：

1
板卡/BSP：
2
Linux 内核：
3
RKNN-Toolkit2：
4
RKNN Runtime：
5
rknn_server：
6
RKNPU 驱动：
7
目标模型与输入尺寸：

后续任何结果都应与这张表绑定，否则不同环境的性能和错误日志无法可靠比较。

七、我认为最重要的五条原则#

转换成功不等于模型正确，更不等于产品完成。
训练、ONNX、RKNN 和 C++ 的预处理必须完全一致。
Toolkit、Runtime、驱动和模型版本要作为一组管理。
优化前先建立正确且可复现的基线。
端侧性能要统计完整数据链路，而不是只报 NPU 内核时间。

八、本篇实践验收#

完成本篇后，我应该能够：

解释 CPU、GPU、NPU、RGA 和编解码器各自负责什么；
说清 Toolkit2、Lite2、RKNPU2、驱动的区别；
画出原模型到 RKNN 板端应用的完整流程；
在开发板上确认架构和 RKNPU 驱动信息；
建立项目版本记录表。

下一篇：RK3588 端侧 AI 部署（二）：主机与板端环境搭建

纸翼