用MobileNet验证RK3566/RK3588开发板NPU是否真正工作

跑通 demo 不代表 NPU 在工作：很多 RK3566/RK3588 开发板用户买到板子第一件事，就是跑厂家自带的 yolov5 目标检测 demo，看到画面里框出几个物体就以为 NPU 没问题了。实际上这个结论下得太早，因为 demo 能不能跑、跑得快不快，取决于硬件、固件、驱动、工具链、runtime 五层配合。你后面换自己的模型、自己的预处理，任何一层对不上都会翻车。我这两年经手过不少 RK3566、RK3588 板卡，也帮朋友排查过各种"demo 正常但自己模型跑不起来"的问题，逐渐养成一个习惯：新板子到手，先不跑重量级 demo，用 mobilenet 这个小模型把 NPU 全链路验证一遍。这篇文章就把这套验证方法完整拆开，覆盖环境准备、模型转换、上板推理、数据判断和常见坑，适合刚拿到 RK3566/RK3588 开发板、想确认 NPU 是否真在工作的人参考。

1. 跑通 demo 不代表 NPU 在干活：验证思路从哪来

1.1 标称算力与实际吞吐量之间隔着一整条工具链

RK3566 标称 NPU 算力 0.8 TOPS（INT8），RK3588 标称 6 TOPS（INT8），看着差距很大。但标称算力是芯片理论峰值，它默认一个前提：模型已经成功转换成了 RKNN 格式、量化配置正确、runtime 驱动正常加载、数据布局和模型输入约束一致。这四个环节任何一环出问题，实际吞吐量可能直接掉到 CPU 水平，甚至根本跑不起来。

我见过一个很典型的案例：有朋友在 RK3588 上跑官方 rknn_model_zoo 里的 mobilenet demo，一切正常，耗时也很漂亮。但他把自己的 TensorFlow 分类模型转成 RKNN 后，上板发现单次推理竟然要 200 多毫秒，比直接用 TFLite 跑 CPU 还慢。排查到最后发现是量化数据集只有 3 张图，量化误差导致模型输出结果大量重试？不对，更常见的是模型转换时 target_platform 没写、默认落到了旧版本格式，板端 runtime 反复做格式转换。这类问题用"能不能出结果"判断根本看不出来，必须用耗时、精度、NPU 核占用一起来判断。

所以我的建议是：新板子到手，或者换了新固件、新版本工具链之后，先跑一个最基础、最不容易出幺蛾子的模型链路。mobilenet 就是最合适的候选。

1.2 为什么选 mobilenet 当 NPU 试金石

mobilenet 在 NPU 验证这件事上，有四个别的大模型比不了的优势：

第一，结构简单。mobilenet_v1 的核心就是深度可分离卷积，没有复杂的动态 shape、没有 anchor 后处理、没有 NMS，这些都是 NPU 兼容性的重灾区。mobilenet 干净，出问题容易定位是工具链还是 runtime。

第二，公开权重多、格式全。TensorFlow 有官方 pb 文件，PyTorch 有 torchvision 版本，ONNX 模型也随手能下。这意味着你能用同一条数据、同一个模型，横向对比不同转换路径的差异，而不用怀疑模型本身有毛病。

第三，输入输出极其标准。224x224 输入、1000 类输出，mean/std 归一化方式也是 ImageNet 的标准做法，和 RKNN 工具链默认配置一致，少了很多调参的干扰。

第四，推理耗时在可观察区间。模型体量小，RK3566 上大概十几毫秒到二十几毫秒，RK3588 上几毫秒。这个区间既不会快到让你感觉不到差异，也不会慢到浪费调试时间，非常适合做"改一个配置看一次效果"的循环。

你可以把 mobilenet 验证理解为给开发板做"出厂体检"：不追求跑业务模型，只确认从 PC 到板子这条链路的每一环都是通的。体检通过之后，再上 yolov8、OCR、多路视频流这些重负载，才有排查问题的参照系。

2. 环境准备是第一个翻车重灾区：工具链与固件匹配问题

2.1 rknn-toolkit2 安装与 Python 环境陷阱

RKNN 模型转换必须在 x86 PC 上完成，开发板本身只负责推理。Rockchip 提供的转换工具叫 rknn-toolkit2，它不是一个"装完就能用"的普通 pip 包，有几个隐藏要求容易被忽略。

首先是操作系统和 Python 版本。rknn-toolkit2 的 Release 页面会明确标注支持的 Python 版本，不同大版本差异不小。我自己常用的组合是 Ubuntu 20.04 + Python 3.8 或 Python 3.10，用 conda 建独立环境，避免和系统 Python 打架。很多人在这一步栽跟头，是因为直接在板子的 Ubuntu 系统里尝试 pip install rknn-toolkit2，结果依赖一堆编译错误。记住，rknn-toolkit2 只装 PC 端，板子端要的是另一套东西。

其次是安装顺序。建议严格按官方 README 来：

conda create -n rknn python=3.8 conda activate rknn pip install rknn-toolkit2-x.x.x-cp38-cp38-linux_x86_64.whl

装完跑一下官方自带的验证脚本，确认 import 能过。如果 import rknn 报缺某个 .so，多数是 numpy/opencv 版本冲突，用 conda 重装 numpy 通常能解决。

这里有个小细节：rknn-toolkit2 安装时会把依赖的 onnx、tensorflow、torch 等一连串深度学习框架都带进来，体积很大。如果只是转换 mobilenet 这种轻量模型，确实用不到全部框架，但别自作聪明用 --no-deps 跳过依赖，后面转换时报缺模块更头疼。

2.2 板端 runtime 库和固件怎么对版本

模型转换在 PC 完成，真正推理时依赖的是板子上的 runtime 库。这个库在 Rockchip 体系里有两个名字：

• C/C++ 接口：librknnrt.so
• Python 接口：rknn-toolkit-lite2 包里的 RKNNLite 模块

板子固件里通常自带一份 librknnrt.so，在 /usr/lib/ 下。但关键问题在于，固件里这份库的版本必须和 PC 端 rknn-toolkit2 的版本配套。版本差太远时，最常见的表现是 load_rknn 直接报错，或者推理输出结果全是垃圾值。

我踩过的一个具体坑：PC 端用的是 rknn-toolkit2 1.6.0，板子固件里带的 librknnrt.so 是旧版本，加载模型时抛了一个 "invalid magic number" 错误。原因是新版本转换工具生成的 RKNN 文件头部格式变了，老 runtime 不认。后来把板端 runtime 升级到配套版本才解决。

检查板端 runtime 版本，可以用：

strings /usr/lib/librknnrt.so | grep -i version

或者直接跑官方 demo 里的版本打印代码。如果你打算长期做 RKNN 开发，建议把固件和 rknn-toolkit2 的版本对应关系记下来，Rockchip 的 wiki 上有明确表格，升级任何一边之前先查这个表。

另外，开发板固件本身也有讲究。同一个 RK3588，Debian 固件和 Ubuntu 固件带的 NPU 驱动版本可能不同，直接导致 NPU 性能差异。我实测过同一台 RK3588 板子，厂家旧版固件跑 mobilenet 耗时 6ms，升级新版 BSP 固件后降到 4ms 出头。如果你在验证性能时发现数据和网上的评测差很多，先别急着怀疑硬件，看一眼固件版本。

3. 模型转换：从 TensorFlow pb 到 RKNN 的完整链路

3.1 拿模型与输入预处理约定

验证链路的起点是一个干净的 mobilenet_v1 pb 文件。我建议直接用 TensorFlow 官方发布的那份mobilenet_v1_1.0_224.tgz，解压后得到mobilenet_v1_1.0_224_frozen.pb。这个文件是冻结后的推理图，输入节点名是input，输出节点名是MobilenetV1/Predictions/Reshape_1，尺寸 1x224x224x3，取值范围是 0~255 的原始像素。

之所以强调"官方原版"，是因为网上很多第三方转换过的 pb 文件输入节点名被改过，或者预处理方式被揉进了图里面，用来验证链路时会平白多出很多干扰变量。用最标准的输入输出，才能保证出了问题能一两句话在网上搜到答案。

顺便说一句，mobilenet_v1 的 ImageNet 预处理是 RGB 顺序，mean = [123.675, 116.28, 103.53]，std = [58.395, 57.12, 57.375]。但 OpenCV 读图默认是 BGR 顺序，这一点稍不注意就会让推理精度暴跌。后面我会专门说怎么处理。

3.2 dataset 文件与量化之间的隐秘关系

RKNN 工具链支持两种转换模式：

• 不量化：直接 fp32 推理，精度最高，但 NPU 性能优势发挥不出来
• 量化（INT8）：模型权重和激活值映射到 8bit 整数，速度翻倍，但需要一组代表性图片来计算量化范围

很多人对量化的理解是"随便找几张图丢进去就完事"，实际上代表性数据集（representative dataset）的选择直接决定量化后模型的精度。最典型的问题：如果你的业务场景是工业检测，但你量化数据集放的全是风景图，那模型在检测目标上的输出可能直接变成噪声。

对于 mobilenet 验证场景，我的建议是：

• 准备 100 到 200 张图，覆盖你实际要用的场景
• 图片尺寸不必和训练集完全一致，工具链会按模型输入自动缩放
• dataset.txt 文件里写的是图片路径列表，每行一个路径，用相对路径或绝对路径都行，注意别写错

下面是一个 dataset.txt 的示例：

./imgs/img_001.jpg ./imgs/img_002.jpg ./imgs/img_003.jpg

量化数据集太少时，转换过程本身不会报错，但结果可能很离谱。我就遇到过只用 3 张图量化后，mobilenet 对一张猫图的 top-1 置信度从 0.95 掉到 0.3 的情况。这属于典型的"工具链没报错但结果不对"的坑，排查起来相当费劲。

3.3 转换脚本与常见转换报错

下面是一份完整的转换脚本，以 mobilenet_v1 为例，目标平台是 RK3588：

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' ) # 加载 TensorFlow 模型 ret = rknn.load_tensorflow( tf_pb='mobilenet_v1_1.0_224_frozen.pb', inputs=['input'], outputs=['MobilenetV1/Predictions/Reshape_1'], input_size_list=[[1, 224, 224, 3]] ) if ret != 0: print('load_tensorflow failed') exit(ret) # 构建模型并量化 ret = rknn.build(do_quantization=True, dataset='dataset.txt') if ret != 0: print('build failed') exit(ret) # 导出 RKNN 模型 ret = rknn.export_rknn('mobilenet_v1.rknn') if ret != 0: print('export failed') exit(ret) rknn.release()

这段代码的每一步都有讲究：

• mean_values和std_values必须和模型训练时一致。RKNN 工具链的预处理逻辑是(pixel - mean) / std，且是在 uint8 输入上做的。如果模型训练时用的是其他归一化方式，必须在转换前先确认清楚。
• target_platform不写也能转换，但生成模型的算子布局可能不是针对目标芯片优化的，甚至在某些版本里会默认生成 RK3566 的版本，导致 RK3588 上加载时性能打折。所以这个参数一定要显式写。
• input_size_list的 NHWC 顺序要和 pb 图的输入一致。mobilenet 官方 pb 是 NHWC，写作[1, 224, 224, 3]。如果你从 PyTorch 导出的 ONNX 模型，通常是 NCHW 顺序，两种布局在转换时的处理方式不一样，搞混了会得到" shape 对不上"的报错。

转换过程中最常见的报错有下面几类：

转换完成后，你会得到一个mobilenet_v1.rknn文件。建议在 PC 端先用 rknn-toolkit2 自带的模拟器跑一次推理，确认输出 softmax 结果正常，再上板。虽然模拟器用的是 x86 CPU，跑得慢，但它能帮你排除"模型转换坏了"这个变量。

4. 上板实测：推理代码、数据解读与判断标准

4.1 RKNNLite 推理代码骨架

模型转换验证通过后，把mobilenet_v1.rknn拷贝到开发板上。板端的推理代码要比 PC 端简洁很多，因为只需要加载模型和跑推理，不需要转换功能。官方提供的是 rknn-toolkit-lite2 包，代码骨架如下：

from rknnlite.api import RKNNLite import cv2 import numpy as np # 加载模型 rknn_lite = RKNNLite() ret = rknn_lite.load_rknn('mobilenet_v1.rknn') if ret != 0: print('load_rknn failed') exit(ret) # 初始化 runtime，指定 NPU 核心 ret = rknn_lite.init_runtime(core_mask=RKNNLite.NPU_CORE_0) if ret != 0: print('init_runtime failed') exit(ret) # 读取图片并预处理 img = cv2.imread('cat.jpg') # 注意：cv2 读出来是 BGR，需要转成 RGB img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img = cv2.resize(img, (224, 224)) # 推理 outputs = rknn_lite.inference(inputs=[img]) print(outputs[0].shape) print(outputs[0][0][:10]) rknn_lite.release()

这段代码里有几个容易踩的点。

core_mask参数控制 NPU 使用哪个核心。RK3588 的 NPU 是三核设计，RK3566 是单核。NPU_CORE_0表示只用第一个核，NPU_CORE_0_1_2表示三个核一起上。mobilenet 这种小模型，单核和多核的耗时差异未必明显，但如果你想后面跑大模型，这个参数需要单独调试。我的习惯是验证硬件时先指定单核，因为单核跑出来的数据更稳定，不受多核调度策略影响。

inference接口接收的是 numpy 数组，不需要手动转成 float 或做归一化，因为归一化已经在模型转换时通过 mean/std 配置固化在 RKNN 模型里了。但输入的数据类型必须是 uint8，RGB 顺序。如果你传了 float32 数据，或者 BGR 顺序，推理结果会非常奇怪。

如果你习惯用 C/C++，也可以直接调用 librknnrt.so 的 C 接口，核心流程是：

#include <stdio.h> #include "rknn_api.h" rknn_context ctx; rknn_init(&ctx, "./mobilenet_v1.rknn", 0, 0, NULL); rknn_input inputs[1]; 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 = img_buffer; rknn_inputs_set(ctx, 1, inputs); rknn_run(ctx, NULL); rknn_output outputs[1]; outputs[0].want_float = 0; rknn_outputs_get(ctx, 1, outputs, NULL); // 处理 outputs[0].buf rknn_outputs_release(ctx, 1, outputs); rknn_destroy(ctx);

Python 版适合快速验证，C 接口适合正式部署。验证阶段用 Python 完全够，重点是把整个链路跑通，而不是追求接口形式。

4.2 实测数据看板：RK3566 vs RK3588

我在几款常见的 RK3566 和 RK3588 开发板上跑过 mobilenet_v1（224x224、INT8 量化），典型的单次推理耗时大致如下。注意这是"典型区间"，实际数值受固件版本、DDR 频率、散热降频、是否开启多核等因素影响。

这张表最有价值的不是绝对数值，而是"数量级"本身。mobilenet 是小模型，如果它在 RK3566 上耗时超过 100ms、在 RK3588 上超过 30ms，那基本可以断定 NPU 没正常工作，推理是在 CPU 上兜底的。反过来，如果耗时在这个区间，说明 NPU 大概率在正常工作。

判断 NPU 是否正常，光看模型输出 result 的置信度还不够，我一般会做两类"额外确认"。

第一种，耗时对比法。在开发板上用 TFLite 或 NCNN 跑同样的 mobilenet 模型，得到 CPU 推理耗时；然后跑 RKNN 版本，得到 NPU 推理耗时。两者的差距如果小于 3 倍，基本可以认定 NPU 没被真正使用。我实测 RK3566 上同一个模型，TFLite CPU 耗时 150ms 左右，RKNN NPU 耗时 18ms，差距 8 倍，这才是正常状态。

第二种，系统日志法。在开发板 shell 里执行：

dmesg | grep -i rknpu

如果能看到 rknpu 驱动初始化的日志，说明硬件和驱动链路正常。部分新版本 BSP 还提供了/sys/kernel/debug/rknpu/load或者类似节点，可以实时读取 NPU 占用率，跑推理时数值有明显跳动，就是铁证。固件不同的板子路径不太一样，没有这个节点也不代表 NPU 坏了。

4.3 数据之外的三个判断维度

耗时只是最简单直接的一个维度。做 NPU 验证时，我还会看三个容易被忽略的维度。

第一，稳定性。连续跑 100 次推理，记录耗时波动。正常 NPU 推理的耗时波动应该在 10% 以内。如果出现某些帧突然变慢，可能是 DDR 带宽竞争或 NPU 频率调度问题，后面接多路视频流时会放大成明显的卡顿。

第二，精度合理性。用一张典型的猫图或 ImageNet 样图跑 mobilenet，看 top-5 输出里有没有合理类别。如果输出乱七八糟，说明模型转换或预处理环节有问题，哪怕耗时再漂亮也是白搭。这个维度通常最先出问题，但很多人的第一反应却是质疑硬件，白白浪费时间。

第三，多线程并发能力。把同一个 RKNN model 在多个线程里同时推理，观察耗时变化。RK3588 的 NPU 支持多任务并发，mobilenet 这种小模型能轻松扛住 4 到 8 路并发，且单路耗时增加不明显。RK3566 算力弱一些，但跑 2 到 4 路 mobilenet 并发也没问题。如果你预期要做多路视频分析，这一步验证比单纯看单帧耗时更有参考意义。

5. 最容易踩的坑：从"看起来正常"到"真的正常"

5.1 常见报错与排查链路

整个验证流程里，我遇到过的问题可以归成三大类。下面这张表是高频问题的直接对应关系。

排查时我习惯按"从下往上"的顺序：先确认驱动加载（dmesg），再确认库文件存在（ls /usr/lib/librknnrt.so），再确认模型能加载（load_rknn），最后才看推理结果。很多人一上来就怀疑模型转换，其实底层驱动没加载时，所有上层现象都会表现得很奇怪，反而容易把人带偏。

5.2 性能不达标的排查路径

有一类坑特别隐蔽：模型能跑、结果也对，但性能和数据表对不上。这时候按下面这个顺序排查，命中率最高。

第一步，看频率。RK3588 的 NPU 有不同工作频率档位，BSP 会根据负载动态调频。如果板子散热不行或者电源供电不稳，NPU 可能被限制在低频率。执行cat /sys/class/devfreq/fdab0000.npu/cur_freq（不同 BSP 路径可能不同）能看到当前频率。如果长时间跑在高负载，还要看有没有降到最低档。

第二步，看内存带宽。NPU 推理时大量读写 DDR，如果板子用的是低速率 DDR 或者内存带宽被 GPU/显示占用，推理耗时会有明显波动。这个不好直接测，但可以通过对比"纯计算型模型"和"数据密集型模型"的耗差异来间接判断。

第三步，看算子切分。出现耗时异常时，我建议在 PC 端用 rknn-toolkit2 的rknn.analysis()接口分析模型每一层的耗时分布。有时同一个模型在 RK3566 上某些算子会被拆成多个小算子执行，而在 RK3588 上是融合算子，这个差异会导致性能远低于理论预期。分析接口的日志会直接告诉你哪些算子耗时异常，能省去大量盲猜。

第四步，干脆换模型验证。如果 mobilenet 正常，但你的重点模型慢，问题多半在模型本身的结构复杂度上。比如带大量 reshape/transpose 的模型，在 NPU 上可能效率很低。这时候不是硬件坏了，是模型结构不适合 NPU。

5.3 一个隐蔽但高发的陷阱：模型文件与 runtime 口径不一致

最后单独说一个我踩过多次、也帮别人排过多次的坑：rknn-toolkit2 发布新版本后，生成的 RKNN 文件格式可能向后不兼容。你拿着新版本转换工具在 PC 上生成的模型，放到板子上跑，如果用旧版 runtime，轻则报错，重则静默输出错误结果。

这个问题之所以隐蔽，是因为它不像"驱动没加载"那样有明显报错，而是表现为"有时正常、有时不正常"或者"精度忽高忽低"。我见过有人因为这个问题怀疑板子 NPU 硬件有瑕疵，折腾了好几天，最后发现只是 PC 端和板端版本差了两个大版本。

所以，我给自己定了一个规矩：PC 端 rknn-toolkit2 版本、板端 librknnrt.so 版本、固件版本，三者必须记录在同一个文档里。每次升级其中任何一个，都要重新跑一遍 mobilenet 验证链路，确认无误再继续后面的业务开发。这个习惯帮我规避了大量潜在的"神秘问题"。

6. 验证通过之后还能怎么用这套环境

mobilenet 验证链路跑通后，你手里其实已经有了一套完整的 RKNN 开发环境，后面扩展其他模型就很顺了。

一个自然的延伸是用同样的工具链部署 yolov8。Rockchip 官方的 rknn_model_zoo 里已经有现成的 yolov8 转换脚本和部署 demo，但你需要重点关注的是 anchor 配置、输入尺寸、NMS 后处理这些环节。mobilenet 验证只覆盖了"分类模型"这一条路径，yolov8 涉及检测头的输出解析，多出来的这部分正好是 NPU 部署最容易出错的地方。建议先用 COCO 预训练权重跑通，再换自己的数据集。

另一个方向是摄像头实时推理。RK3588 有强大的视频编解码能力，可以做 USB 摄像头 RTSP 推流加 NPU 推理的完整链路。这种做法在边缘计算项目里很常见，mobilenet 这种小模型可以做成一个低延迟的 demo，先把"采集 -> 解码 -> NPU 推理 -> 编码推流"整条pipeline 打通，再替换成实际业务模型。我在实际项目中就是这么干的：先用 mobilenet 验证整个视频链路没有瓶颈，再切换到重模型，后面排查问题就有了明确的分层依据。

还有一点值得提的是，如果你买了 RK3566 的板子但发现 mobilenet 推理耗时偏大，先别急着换 RK3588。很多 RK3566 板子出厂固件没有调好 NPU 频率，或者 DDR 跑在较低速率。先检查 devfreq 配置，把 NPU 频率调到最高档位再测一次，数据可能完全不一样。同样的方法在 RK3588 上也适用，毕竟性能数据的意义是用来判断"板子调好了没有"，而不是"芯片能跑多快"。

把这个验证方法养成习惯之后，你会发现后续不管换板子、换固件还是换模型，都能用最小成本快速判断环境是否健康。我个人的体会是，NPU 开发里 80% 的"疑难杂症"其实都是环境版本不匹配造成的，早点把基础链路验证工具打磨好，后面会省下大量排查时间。