NPU 架构与性能概览

1. 概述

1.1 功能简介

RK3588 内置一颗高性能 NPU（Neural Processing Unit，神经网络处理器：专门为深度学习计算设计的独立硬件，比 CPU 快得多，又比 GPU 省电），INT8 精度下算力达到 6 TOPS（TOPS 是每秒万亿次运算的算力单位），这也是目前 Rockchip 旗舰级 AI 加速引擎的水平。NPU 支持 INT8、INT16 和 FP16 三种量化精度（量化指把模型里用 32 位浮点数保存的权重压缩成 INT8 这类低位数格式，模型更小、算得更快，代价是少量精度损失），在保持较高推理精度的同时能提供很高的计算吞吐量。

NPU 模块由三个独立推理核心组成（NPU0、NPU1、NPU2），每个核心内部都有一片大规模 MAC 阵列（Multiply-Accumulate，乘加运算单元阵列，卷积和矩阵乘法最终都拆成乘加来做），可并行执行卷积、矩阵乘法、激活等深度学习算子。多个核心可以协同工作加速同一个大模型的推理，也可以各跑各的模型，灵活做多任务调度。

核心特性一览：

特性说明
算力6 TOPS（INT8）
量化精度INT8 / INT16 / FP16
推理核心3 个独立核心（NPU0、NPU1、NPU2）
架构基于 Rockchip 自研 NPU 架构，MAC 阵列并行计算
软件栈RKNN Toolkit2（模型转换）+ rknpu2（驱动）+ librknnrt（运行时）
算子覆盖60+ ONNX 算子、35+ Caffe 算子、30+ PyTorch 算子、35+ TensorFlow 算子、15+ Darknet 算子
框架支持ONNX、PyTorch、TensorFlow、Caffe、Darknet

1.2 应用场景

RK3588 NPU 适合跑这些典型 AI 推理场景：

  • 智能安防：实时视频分析、人脸识别、行为检测、车牌识别
  • 智慧零售：商品识别、客流统计、自助结算
  • 工业视觉：缺陷检测、产品分类、尺寸测量
  • 智能驾驶：ADAS 辅助驾驶、DMS 驾驶员监控、环视拼接
  • 边缘 AI 服务器：多路视频并发推理、云端模型边缘部署
  • 机器人：SLAM、目标跟踪、语义理解
  • 智慧医疗：医学影像辅助诊断、X 光片分析
  • AIoT 终端：语音识别加速、智能音箱、无人机视觉

1.3 工作原理

RK3588 NPU 的使用链路涉及硬件加速层、驱动层、运行时层和应用层四个层次，自上而下分工如下：

┌─────────────────────────────────────────────────────┐
│                  应用层（Application）                 │
│   Python 应用 / C/C++ 应用 / Android App              │
├─────────────────────────────────────────────────────┤
│              工具链层（rknn-toolkit2）                  │
│   模型转换 · 量化校准 · 模型优化 · 模型导出              │
├─────────────────────────────────────────────────────┤
│             运行时层（librknnrt）                       │
│   模型加载 · 内存分配 · 算子调度 · 推理执行              │
├─────────────────────────────────────────────────────┤
│              驱动层（rknpu2）                          │
│   内核模块 · IOCTL 接口 · DMA-BUF 管理                 │
├─────────────────────────────────────────────────────┤
│              硬件层（NPU Hardware）                    │
│   NPU0 Core · NPU1 Core · NPU2 Core                  │
│   MAC 阵列 · 片上 SRAM · 数据搬运引擎                   │
└─────────────────────────────────────────────────────┘

对应到实际操作，一个模型从 PC 走到 NPU 要经过这几步：

阶段组件功能
模型转换rknn-toolkit2在 PC 主机上将 ONNX/PyTorch/TensorFlow 等模型转换为 RKNN 格式，执行量化校准
模型传输adb / scp将转换后的 .rknn 模型文件拷贝到开发板存储
运行时初始化librknnrt加载 RKNN 模型，分配 NPU 内存，初始化推理上下文
推理执行NPU 硬件NPU 核心接收指令，MAC 阵列并行计算，输出推理结果
结果获取librknnrt从 NPU 内存读回输出张量，供应用层处理

三个 NPU 核心支持以下调度模式：

模式说明适用场景
单核模式仅使用一个核心推理单模型、低延迟需求
多核分组多个核心协同推理同一模型大模型、高吞吐需求
多核独立各核心独立运行不同模型多任务并发推理

2. 硬件准备

2.1 硬件清单

序号物料名称型号/规格数量用途
1核心板 + 底板C-3588LQ 核心板 + SHIMETAPI-M5-R2A 底板1主开发板
2调试串口USB to TTL 3.3V 转换器1串口调试，波特率 1500000
3NVMe SSD（可选）M.2 2242/2280 NVMe 固态硬盘1模型文件大容量存储
4电源适配器12V/2A DC 电源1主板供电
5显示器 + HDMI 线支持 4K 的显示器1图形界面调试（可选）

2.2 硬件确认

板子接上网线或串口、进入系统后，先用下面的命令确认 NPU 硬件信息（输出取自本机）：

# 查看设备树中 NPU 节点（注意实际节点名带地址后缀）
ls -d /proc/device-tree/*npu*
# 输出:
# /proc/device-tree/npu@fdab0000
# /proc/device-tree/npu-opp-table

cat /proc/device-tree/npu@fdab0000/compatible
# 输出: rockchip,rk3588-rknpu

cat /proc/device-tree/npu@fdab0000/status
# 输出: okay

# 查看 NPU 寄存器（reg 是二进制属性，用 od 查看）
od -A x -t x1 /proc/device-tree/npu@fdab0000/reg
# 输出（三段寄存器区域）:
# 000000 00 00 00 00 fd ab 00 00 00 00 00 00 00 01 00 00
# 000010 00 00 00 00 fd ac 00 00 00 00 00 00 00 01 00 00
# 000020 00 00 00 00 fd ad 00 00 00 00 00 00 00 01 00 00
# 解析: 0xfdab0000/0xfdac0000/0xfdad0000 三段，每段 0x10000（64KB）

# 查看内存信息
cat /proc/meminfo | grep MemTotal
# 输出: MemTotal:        3989628 kB

# 查看 SoC 型号
cat /proc/device-tree/compatible
# 输出包含 rk3588 关键字

确认成功的标志：compatible 输出 rockchip,rk3588-rknpu、status 输出 okay，说明设备树里的 NPU 节点已启用，硬件这关就过了。

3. 软件准备

3.1 内核配置

NPU 驱动需要在 Linux 内核配置里打开对应选项，用 menuconfig 勾选或直接修改 .config 文件都可以：

# 路径: Device Drivers → Accelerators → Rockchip NPU
CONFIG_ROCKCHIP_RKNPU=y
CONFIG_ROCKCHIP_RKNPU_DEBUG_FS=y

接着确认内核版本和驱动编译情况：

# 查看内核版本
uname -a
# 输出: Linux linaro-alip 6.1.141 #11 SMP ... aarch64 GNU/Linux

# 查看 NPU 驱动是否编译入内核
# 注意：本机 /boot/ 下没有 config-<内核版本> 文件，正确方法读 /proc/config.gz
zcat /proc/config.gz | grep -i rknpu
# 输出:
# # RKNPU
# CONFIG_ROCKCHIP_RKNPU=y
# CONFIG_ROCKCHIP_RKNPU_DEBUG_FS=y

注意：本机驱动以 =y 方式编进内核（不是可卸载模块），所以 lsmod 里看不到它；而且本机的 lsmod 会因内核问题挂死（读 /proc/modules 阻塞），不要用它。验证驱动请改用下面的 /sys/module 方法：

ls /sys/module/ | grep -i rknpu
# 输出: rknpu

能看到 rknpu 就说明驱动已在内核里。

3.2 设备树

NPU 设备树节点定义了寄存器地址、中断号、时钟和复位等硬件信息，下面是 RK3588 的节点内容（注意与 RK356x 系列的 ff630000 不同）：

npu: npu@fdab0000 {
    compatible = "rockchip,rk3588-rknpu";
    reg = <0x0 0xfdab0000 0x0 0x10000>,
          <0x0 0xfdac0000 0x0 0x10000>,
          <0x0 0xfdad0000 0x0 0x10000>;
    interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
    interrupt-names = "npu0_irq", "npu1_irq", "npu2_irq";
    clocks = <&cru CLK_NPU>, <&cru PCLK_NPU>;
    clock-names = "clk_npu", "pclk_npu";
    assigned-clocks = <&cru CLK_NPU>;
    assigned-clock-rates = <1000000000>;
    resets = <&cru SRST_NPU>;
    reset-names = "npu";
    power-domains = <&pd_npu>;
    operating-points-v2 = <&npu_opp_table>;
    status = "okay";
    #cooling-cells = <2>;
};

各关键字段的含义：

属性值说明
compatiblerockchip,rk3588-rknpuNPU 设备兼容字符串（注意是 rknpu）
reg0xfdab0000 / 0xfdac0000 / 0xfdad0000 各 64KB三段寄存器，对应 3 个 NPU 核
interruptsGIC_SPI 142 / 143 / 1443 个中断号，对应 NPU0/1/2，与 IOMMU 共享
clocksCLK_NPU, PCLK_NPUNPU 功能时钟和总线时钟
resetsSRST_NPUNPU 复位信号
statusokay本机出厂已启用

再验证一下中断号输出：

grep npu /proc/interrupts
# 输出:
# 46: ... GICv3 142 Level  fdab9000.iommu, fdab0000.npu
# 47: ... GICv3 143 Level  fdab9000.iommu, fdab0000.npu
# 48: ... GICv3 144 Level  fdab9000.iommu, fdab0000.npu

4. 操作步骤

4.1 查看 NPU 驱动信息

开发板启动后，用下面的命令确认 NPU 驱动已正确加载：

# 查看驱动是否编入内核（lsmod 在本机会挂死，且驱动是内建的不是模块）
ls /sys/module/ | grep rknpu
# 输出: rknpu

# 查看内核日志中 NPU 初始化信息
dmesg | grep -i rknpu
# 输出:
# [    4.809868] RKNPU fdab0000.npu: Adding to iommu group 0
# [    4.810208] RKNPU fdab0000.npu: RKNPU: rknpu iommu is enabled, using iommu mode
# [    4.812726] [drm] Initialized rknpu 0.9.8 20240828 for fdab0000.npu on minor 1
# [    4.817666] RKNPU fdab0000.npu: RKNPU: bin=0
# [    4.817866] RKNPU fdab0000.npu: RKNPU: idc=7

# 查看 NPU 设备节点（RK3588 的 NPU 走 DRM 接口，不是 /dev/rknpu）
ls -la /dev/dri/
# 输出:
# crw-rw----+ 1 root video  226,   0 ... card0     # 显示控制器 VOP
# crw-rw----+ 1 root video  226,   1 ... card1     # RKNPU（minor 1）
# crw-rw---- 1 root render 226, 128 ... renderD128 # Mali-G610 GPU
# crw-rw---- 1 root render 226, 129 ... renderD129 # RKNPU 渲染节点

结论：本机 NPU 驱动版本为 rknpu 0.9.8（20240828），以 DRM render node 的方式暴露（DRM 是 Linux 内核的图形设备接口，NPU 对应 /dev/dri/renderD129）。老教程里写的 /dev/rknpu 字符设备在这套驱动上不存在，照抄会找不到设备。

4.2 查看 NPU 频率

优先用 devfreq 接口（内核的动态调频框架，普通用户即可读取，可用）：

# 当前频率
cat /sys/class/devfreq/fdab0000.npu/cur_freq
# 输出: 1000000000    （1 GHz，满频）

# 可用频率档位
cat /sys/class/devfreq/fdab0000.npu/available_frequencies
# 输出: 300000000 400000000 500000000 600000000 700000000 800000000 900000000 1000000000

# 调频策略
cat /sys/class/devfreq/fdab0000.npu/governor
# 输出: rknpu_ondemand

# 同目录还有 min/max_freq、load、target_load 等节点
ls /sys/class/devfreq/fdab0000.npu/

cur_freq 读到 1000000000（1 GHz 满频）即说明 NPU 处于正常工作状态。另有一个需要 root 的 debugfs 时钟接口，注意 clk_npu 这个名字在本机不存在：debugfs 下是 23 个 npu 相关时钟，命名不同，先列出实际时钟名再继续查：

sudo ls /sys/kernel/debug/clk/ | grep -i npu   # 查实际时钟名

4.3 安装 RKNN Toolkit2

rknn-toolkit2 是模型转换工具，负责把 ONNX 等通用格式模型转成 NPU 认识的 RKNN 格式（Rockchip 专用模型格式），装在 PC 主机上使用。先看各平台支持情况（PyPI 2.3.2）：

平台支持情况（PyPI 2.3.2）
Linux x86_64支持：manylinux wheel（cp36~cp312）
Linux aarch64支持：manylinux wheel（cp36~cp312），可直接装在 RK3588 板上
Windows不支持：PyPI 无 win wheel（PC 上建议用 WSL2/Ubuntu 虚拟机）

在 Linux PC 上安装：

# 创建 Python 虚拟环境
python3 -m venv rknn_env
source rknn_env/bin/activate

# 安装（版本要与板端 librknnrt 匹配，本机 librknnrt = 2.3.2）
pip install rknn-toolkit2==2.3.2

# 验证安装
python3 -c "from rknn.api import RKNN; print('RKNN Toolkit2 installed successfully')"

注意：国内 pip 镜像源（如 tuna）没有收录 rknn-toolkit2，安装时要加 -i https://pypi.org/simple 走官方源。

要在板上直接跑 Python 推理，还得装 rknn-toolkit-lite2（toolkit2 的板端精简版，只保留推理功能）：

# 板上安装（版本 2.3.2 与系统 librknnrt.so 2.3.2 匹配，避免 runtime mismatch）
sudo pip3 install --break-system-packages rknn-toolkit-lite2==2.3.2

python3 -c "from rknnlite.api import RKNNLite; print('ok')"
# 输出: ok

最后确认板端运行时版本：

strings /usr/lib/librknnrt.so | grep -m1 "librknnrt version"
# 输出: librknnrt version: 2.3.2 (429f97ae6b@2025-04-09T09:09:27)

PC 端 toolkit2、板端 toolkit-lite2、板端 librknnrt 三者都用 2.3.2 就对齐了；版本不一致会报 runtime mismatch。

4.4 模型转换示例

在 PC 上把 ONNX 模型转成 RKNN 格式的完整流程：

from rknn.api import RKNN

rknn = RKNN()

# 配置输入预处理参数
rknn.config(mean_values=[[123.675, 116.28, 103.53]],
            std_values=[[58.395, 57.12, 57.375]],
            target_platform='rk3588')

# 加载 ONNX 模型
rknn.load_onnx(model='model.onnx')

# 执行量化（INT8）
rknn.build(do_quantization=True, dataset='calibration_data.txt')

# 导出 RKNN 模型
rknn.export_rknn('model.rknn')

rknn.release()
print("Model conversion completed: model.rknn")

转换也可以直接在板上做（aarch64 同样能装 toolkit2）。下面是 mobilenetv2-12.onnx 转 RKNN（fp16）的用法和输出：

ret = rknn.load_onnx(model='/var/tmp/mobilenetv2_static.onnx')  # 注意：须先固定动态 batch 维
ret = rknn.build(do_quantization=False)   # fp16 无需校准集
ret = rknn.export_rknn('/var/tmp/mobilenetv2_fp16.rknn')
[3] load_onnx() ret=0  0.3s
[4] build(do_quantization=False) ret=0  4.8s
[5] export_rknn() ret=0  4.8s
[6] model size = 7665073 bytes (7.3 MB)  total 4.8s

踩过两个坑：

  1. mobilenetv2-12.onnx 输入是动态 batch（['batch_size',3,224,224]），直接 load 会报 The input shape ... is not support!。用 onnx 库把 batch 固定为 1 后再转：
    import onnx
m = onnx.load('mobilenetv2-12.onnx')
d = m.graph.input[0].type.tensor_type.shape.dim
d[0].dim_param = ''; d[0].dim_value = 1
onnx.save(m, 'mobilenetv2_static.onnx')
  2. 板上 pip 装 toolkit2 时 onnxoptimizer 依赖会源码编译失败（PyPI 无 aarch64 wheel），用 pip3 install --no-deps rknn-toolkit2==2.3.2 + 单独 pip3 install onnx 绕过（fp16 转换不需要 onnxoptimizer）。

4.5 传输模型到开发板

模型转好后，用 scp 传到板子上（示例 IP 为 192.168.49.60；Debian 镜像用户为 linaro，Ubuntu 镜像为 root，见镜像差异）：

# 通过 scp 传输（示例 IP；账户按镜像选择）
scp model.rknn linaro@192.168.49.60:/var/tmp/    # Debian 镜像；Ubuntu 镜像用 root@

4.6 在开发板上执行推理

在开发板上用 RKNNLite 的 Python 接口跑推理：

from rknnlite.api import RKNNLite
import numpy as np

# 初始化 RKNNLite
rknn = RKNNLite()

# 加载 RKNN 模型
rknn.load_rknn('model.rknn')

# 初始化运行时，指定 NPU 核心
rknn.init_runtime(core_mask=RKNNLite.NPU_CORE_0)

# 准备输入数据
img = np.random.randint(0, 255, size=(1, 224, 224, 3), dtype=np.uint8)

# 执行推理
outputs = rknn.inference(inputs=[img])

# 处理输出
print(f"Output shape: {outputs[0].shape}")
print(f"Predicted class: {np.argmax(outputs[0])}")

# 释放资源
rknn.release()

下面是实机输出（mobilenetv2 fp16，224×224 输入）：

[1] load_rknn() ret=0  0.01s
[2] init_runtime(NPU_CORE_0) ret=0  0.07s
[3] 首次推理 9.0 ms, output shape=(1, 1, 1000)
[4] 20 次平均 9.28 ms/帧 (~107.8 FPS)
[5] output[0] shape=(1, 1000) dtype=float32
[6] argmax=971  top5=[971, 644, 904, 107, 632]
[7] release() done
I RKNN: RKNN Runtime Information, librknnrt version: 2.3.2
I RKNN: RKNN Driver Information, version: 0.9.8
I RKNN: RKNN Model Information, version: 6, toolkit version: 2.3.2,
       target: RKNPU v2, target platform: rk3588, framework name: ONNX

要点：

  1. 调用顺序必须是 load_rknn() → init_runtime()。顺序反了会报 E Model is not loaded yet, this interface should be called after load_rknn!，且 init_runtime 返回 -1。
  2. Query dynamic range failed 警告对静态 shape 模型可以忽略，日志里也是这么提示的。
  3. NPU 权限：以普通用户即可跑通（Debian 镜像为 linaro），无需 sudo（/dev/dri/renderD129 对 render 组可读；如遇权限错误，执行 sudo usermod -aG render $USER 后重新登录即可）。

让三个核心一起干能明显提速。多核模式对比（同一 mobilenetv2 fp16 模型，30 次平均）：

core_mask耗时/帧帧率说明
NPU_CORE_010.51 ms95.2 FPS单核
NPU_CORE_0_1_25.28 ms189.2 FPS三核并行，加速比约 1.99 倍
NPU_CORE_AUTO8.89 ms112.5 FPS框架自动分配

5. 代码详解

5.1 NPU 硬件架构

RK3588 NPU 内部是三个对等的独立推理核心，每个核心都有完整的计算单元和本地存储：

┌──────────────────────────────────────────────────┐
│              RK3588 NPU 子系统                     │
│                                                   │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐  │
│  │   NPU0     │  │   NPU1     │  │   NPU2     │  │
│  │ ┌────────┐ │  │ ┌────────┐ │  │ ┌────────┐ │  │
│  │ │MAC 阵列│ │  │ │MAC 阵列│ │  │ │MAC 阵列│ │  │
│  │ │64×64   │ │  │ │64×64   │ │  │ │64×64   │ │  │
│  │ └────────┘ │  │ └────────┘ │  │ └────────┘ │  │
│  │ ┌────────┐ │  │ ┌────────┐ │  │ ┌────────┐ │  │
│  │ │片上SRAM│ │  │ │片上SRAM│ │  │ │片上SRAM│ │  │
│  │ └────────┘ │  │ └────────┘ │  │ └────────┘ │  │
│  └────────────┘  └────────────┘  └────────────┘  │
│                                                   │
│  ┌──────────────────────────────────────────┐     │
│  │         共享数据总线 / DMA 引擎            │     │
│  └──────────────────────────────────────────┘     │
│                                                   │
│  ┌──────────────────────────────────────────┐     │
│  │      AXI 总线接口（连接 DDR 控制器）       │     │
│  └──────────────────────────────────────────┘     │
└──────────────────────────────────────────────────┘

每个 NPU 核心里的 MAC 阵列负责卷积和矩阵乘法运算；片上 SRAM 用来缓存权重数据和中间特征图，减少对外部 DDR 的访问带宽压力；DMA 引擎负责在 DDR 和片上 SRAM 之间搬运数据。

5.2 RKNN 软件栈详解

RKNN 软件栈分三层：主机端的 rknn-toolkit2、内核里的 rknpu2 驱动、板端的 librknnrt 运行时库。各自的职责如下。

rknn-toolkit2（主机端工具链）：

模块功能
模型加载支持 ONNX、PyTorch、TensorFlow、Caffe、Darknet 格式
图优化算子融合、常量折叠、冗余节点消除
量化校准基于校准数据集的 INT8/INT16 量化
模型导出生成 .rknn 二进制模型文件
仿真验证在 PC 上模拟 NPU 推理行为

rknpu2（内核驱动）：

功能说明
IOCTL 接口为用户态运行时提供设备控制接口
DMA-BUF 管理管理 NPU 与 DDR 之间的内存共享
中断处理处理 NPU 完成中断和错误中断
时钟管理控制 NPU 核心时钟频率和功耗状态
多核心调度分配和管理 NPU0/NPU1/NPU2 核心资源

librknnrt（运行时库）：

功能说明
模型加载解析 .rknn 文件并映射到 NPU 内存
内存管理分配推理所需的输入/输出缓冲区
算子调度将模型中的算子分配到合适的 NPU 核心
推理执行触发 NPU 硬件执行计算
后处理提供输出数据格式转换接口

5.3 RKNN C/C++ API 概览

对性能敏感的嵌入式场景，一般用 C/C++ API 做推理。一个最小可用的流程如下：

#include "rknn_api.h"
#include <stdio.h>
#include <stdlib.h>

int main() {
    rknn_context ctx;
    rknn_input inputs[1];
    rknn_output outputs[1];
    rknn_input_output_num io_num;

    // 1. 读取模型文件
    FILE *fp = fopen("model.rknn", "rb");
    fseek(fp, 0, SEEK_END);
    int model_size = ftell(fp);
    fseek(fp, 0, SEEK_SET);
    void *model_data = malloc(model_size);
    fread(model_data, 1, model_size, fp);
    fclose(fp);

    // 2. 初始化 RKNN 上下文
    rknn_init(&ctx, model_data, model_size, 0, NULL);
    free(model_data);

    // 3. 查询输入输出信息
    rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, &io_num, sizeof(io_num));
    printf("Input num: %d, Output num: %d\n", io_num.n_input, io_num.n_output);

    // 4. 配置输入
    inputs[0].index = 0;
    inputs[0].type = RKNN_TENSOR_UINT8;
    inputs[0].size = 224 * 224 * 3;
    inputs[0].fmt = RKNN_TENSOR_NHWC;
    inputs[0].buf = input_image_data;
    inputs[0].pass_through = 0;
    rknn_inputs_set(ctx, 1, inputs);

    // 5. 执行推理
    rknn_run(ctx, NULL);

    // 6. 获取输出
    outputs[0].want_float = 1;
    rknn_outputs_get(ctx, 1, outputs, NULL);
    printf("Output[0] shape: [%d, %d, %d, %d]\n",
           outputs[0].size / (224 * 224),
           224, 224, 1);

    // 7. 释放资源
    rknn_outputs_release(ctx, 1, outputs);
    rknn_destroy(ctx);

    return 0;
}

编译命令：

aarch64-linux-gnu-gcc -o rknn_demo rknn_demo.c -lrknn_api -I./include -L./lib

5.4 内存管理（DMA-BUF）

RK3588 NPU 用 DMA-BUF 机制（Linux 内核提供的跨设备共享内存接口）实现 NPU 与 CPU 之间的零拷贝数据共享，也就是数据写进内存后双方都能直接访问，省掉中间的复制开销：

#include <linux/dma-buf.h>

// NPU 推理所需的输入/输出缓冲区通过 DMA-BUF 分配
// 数据在 DDR 中由 CPU 或 ISP 写入后，NPU 可直接通过 DMA 访问
// 避免了 CPU 和 NPU 之间的数据拷贝开销

内存布局如下：

区域用途说明
输入缓冲区存放预处理后的输入张量通过 DMA-BUF 在 CPU 和 NPU 间共享
模型权重区存放量化后的模型权重加载模型时由 librknnrt 分配
中间特征图存放层间计算结果NPU 运行时自动管理
输出缓冲区存放推理输出结果通过 DMA-BUF 供 CPU 读取

6. 常见问题

6.1 NPU 驱动未加载

现象：/sys/module/rknpu 不存在，或 /dev/dri/ 下没有 render 节点。

按下面的顺序排查（命令均验证可用）：

# 检查内核配置（本机无 /boot/config-*，读 /proc/config.gz）
zcat /proc/config.gz | grep -i rknpu
# 确认: CONFIG_ROCKCHIP_RKNPU=y、CONFIG_ROCKCHIP_RKNPU_DEBUG_FS=y

# 检查驱动是否编入内核（驱动是内建的，不是模块；本机 lsmod 会挂死勿用）
ls /sys/module/ | grep rknpu
# 输出: rknpu

# 检查设备树 NPU 节点是否启用
cat /proc/device-tree/npu@fdab0000/status
# 输出: okay

# 查看内核日志中的错误信息
dmesg | grep -i rknpu
# 关键行: [drm] Initialized rknpu 0.9.8 20240828 for fdab0000.npu on minor 1

# 如果设备树中 status 为 "disabled"，需修改板级 DTS 重新编译
# 在板级 DTS 中添加:
# &npu { status = "okay"; };

6.2 模型转换失败

现象：用 rknn-toolkit2 转换模型时提示算子不支持或维度错误。

先弄清模型里有哪些算子，再逐项处理：

# 1. 检查 ONNX 模型版本和算子兼容性
python3 -c "
import onnx
model = onnx.load('model.onnx')
print('ONNX opset:', model.opset_import[0].version)
for node in model.graph.node:
    print(f'  {node.op_type}')
"

# 2. 简化模型（使用 onnx-simplifier）
pip install onnx-simplifier
python3 -m onnxsim model.onnx model_sim.onnx

# 3. 降低不支持的算子复杂度
#    - 将不支持的自定义算子替换为等效的标准算子组合
#    - 调整输入维度为静态（避免动态 shape）

# 4. 查看 RKNN Toolkit2 支持的算子列表
rknn_list_ops  # 命令行工具
# 或在 Python 中查看
from rknn.api import RKNN
rknn = RKNN()
# 转换日志中会列出不支持的算子

6.3 推理结果异常

现象：模型在 PC 上推理结果正常，在 NPU 上偏差很大。

问题多半出在预处理或量化校准上，按顺序检查：

# 1. 检查输入预处理是否一致
#    确认 mean_values 和 std_values 与训练时一致
#    确认输入数据格式（RGB/BGR）与模型期望一致

# 2. 检查量化校准数据集
#    使用有代表性的校准数据（覆盖真实场景的多样性）
#    校准数据集建议 50-200 张图片

# 3. 对比 PC 端和 NPU 端的输出
#    可使用 rknn-toolkit2 的性能分析工具
python3 -c "
from rknn.api import RKNN
rknn = RKNN()
rknn.config(mean_values=[[123.675, 116.28, 103.53]],
            std_values=[[58.395, 57.12, 57.375]],
            target_platform='rk3588')
rknn.load_onnx(model='model.onnx')
rknn.build(do_quantization=True, dataset='calibration_data.txt')
# 使用量化前后的模型分别推理，对比精度差异
"

# 4. 尝试使用 FP16 量化替代 INT8
rknn.build(do_quantization=True, dataset='calibration_data.txt',
           quantized_dtype='asymmetric_quantized-16')

# 5. 检查输入数据的内存布局
#    确认 NHWC vs NCHW 格式与模型定义一致

6.4 NPU 推理性能低于预期

现象：推理帧率明显低于预期值。

先查最常见的两个因素：频率和核数。

# 1. 确认 NPU 运行在最高频率（devfreq 接口，无需 root）
cat /sys/class/devfreq/fdab0000.npu/cur_freq
# 输出: 1000000000 (1GHz 满频)

# 2. 检查是否使用了多核模式
#    Python: init_runtime(core_mask=RKNNLite.NPU_CORE_0_1_2)
#    单核 10.51ms vs 三核 5.28ms（mobilenetv2 fp16），单核约为多核的 1/2

# 5. 查看 NPU 实际利用率（devfreq load 节点）
cat /sys/class/devfreq/fdab0000.npu/load
# 输出（推理刚结束时读）: 100@1000000000Hz  即 100% 负载@1GHz

6.5 NPU 与 GPU/VPU 资源冲突

现象：同时用 GPU 渲染和 NPU 推理时性能下降或系统不稳定。

这通常是内存带宽和 CPU 调度的竞争问题，可以这样缓解：

# 1. 合理分配 CPU 核心
#    将 NPU 推理线程绑定到大核（CPU4-7）
taskset -c 4-7 python3 inference.py

# 2. 使用多核模式分散负载
#    当 NPU 多核推理和 GPU 并发时，注意内存带宽竞争

# 3. 调整 DDR 频率
cat /sys/class/devfreq/dmc/cur_freq
# 确认 DDR 运行在较高频率

# 4. 避免 NPU 推理过程中频繁进行 DMA 传输
#    批量处理可减少总线竞争

相关文档