RK3588部署YOLOv8实战：从RKNN模型转换到NPU推理全流程

1. 项目概述为什么把 yolov8 跑在 RK3588 上先交代一下背景。我最近在做一个边缘端视觉检测项目需求很直接把目标检测模型从服务器挪到 RK3588 板子上实现本地推理不依赖云服务。选型阶段对比了几款主流边缘算力平台最终锁定了 RK3588。原因不复杂这颗芯片自带 6 TOPS 算力的 NPU在 8K 视频编解码、多路显示输出、PCIe 扩展这些外围能力上也很均衡属于目前边缘计算场景里综合性价比很高的选择。在此之前我其实在树莓派上跑过轻量级模型也在 Jetson Nano 上折腾过 CUDA 生态但 RK3588 的 NPU 部署路径完全不同——它不认 PyTorch 的 pth 权重也不认 TensorFlow 的 pb 格式必须通过瑞芯微自研的 RKNN 工具链把模型转换成 rknn 格式才能跑。这中间涉及环境搭建、模型转换、量化校准、板端推理一整套流程踩坑无数。这篇博文就是把我从零到一完整趟一遍的过程写下来。内容包括RK3588 NPU 的整体架构和编程思路、RKNN-Toolkit2 的安装与模型转换、板端 RKNN Runtime 的部署方法以及一个 yolov8 目标检测模型的完整移植案例。适合正在做 RK3588 边缘部署的开发者也适合刚入手 RK3588 开发板、想搞清楚 NPU 到底怎么用的人。读完你至少能独立完成一个 PyTorch 检测模型从训练端到板端推理的完整链路。2. RK3588 NPU 架构认知先搞清楚计算是怎么一回事2.1 CPU、GPU、NPU 的分工逻辑很多第一次接触 NPU 的开发者容易犯一个错误把 NPU 理解成“另一个 GPU”。实际上 NPU 的设计目标是完全不同的方向。CPU 强调通用性什么任务都能干但并行计算能力有限。GPU 强调大规模并行适合图形渲染和矩阵运算但功耗高而且通用计算需要特定编程模型CUDA 或 OpenCL。NPU 则是为神经网络推理专门设计的专用计算单元核心工作是高效完成卷积、矩阵乘、激活函数这类算子。它的优势体现在三个方面每瓦特算力远高于 CPU 和 GPU、对定点运算做了硬件级优化、算力利用率高。打个不太严谨但好懂的比方CPU 像一个全科医生什么病都能看但一次只能看一个病人GPU 是综合医院可以同时开很多科室但每个科室的配置是通用的NPU 是专科诊所只擅长特定病种但在这个领域效率极高。RK3588 内置的 NPU 是瑞芯微自研的架构算力标称 6 TOPS。这个数字意味着在 INT8 精度下理论峰值可以做到每秒 6 万亿次操作。实际跑模型时会受限于内存带宽、算子支持度、数据搬运开销通常能用到峰值性能的 30%-60% 就不错了。这一点先有心理预期后面调优的时候会用到。2.2 RKNN 工具链的定位RKNN 是 Rockchip Neural Network 的缩写。工具链由两部分组成PC 端负责模型转换、量化、仿真验证的 RKNN-Toolkit2以及板端负责加载和执行模型的 RKNN Runtime包含在 librknnrt.so 中。他们之间是什么关系用编译链来类比就很好理解RKNN-Toolkit2 相当于交叉编译器把 PyTorch / ONNX / TensorFlow 训练的浮点模型转换成 RK3588 上 NPU 能直接运行的 INT8 或 FP16 指令文件得到xxx.rknn格式的文件。RKNN Runtime 相当于板端的运行时解释器预装或预编译到板子里负责把 rknn 文件加载进 NPU 执行。这个模型的转换不是格式上的简单映射而是包含算子匹配、算子融合、权重重排、精度量化等一系列优化步骤。后面会具体展开。3. 环境搭建RKNN-Toolkit2 完整安装笔记3.1 方案选型PC 端模拟还是板上跑先说结论RKNN-Toolkit2 在 x86 PC 上装在 Python 环境里就能完成模型转换和仿真推理这一步不需要板子。如果你只做模型转换一台普通电脑就够了。但如果你要验证板端推理速度和精度就必须把板子通过 USB 或网线接上在 PC 端执行 connected 模式或者直接把 rknn 文件拷到板子上跑。对于环境官方推荐 Ubuntu 18.04/20.04 x86_64Python 3.6-3.11 都支持具体看版本。我用的是 Ubuntu 20.04 Python 3.8实测最稳坑最少。Windows 和 macOS 系统不推荐官方只在 Linux 上完整支持 RKNN 相关功能部分新版工具在 Windows 上提供了 WSL 方案但 WSL 的 USB 透传比较麻烦。安装流程分成四步第一步创建虚拟环境避免污染系统 Pythonpython3 -m venv rknn_env source rknn_env/bin/activate第二步安装 RKNN-Toolkit2。从瑞芯微的 GitHub 仓库airockchip/rknn-toolkit2下载当前 release 版本的 wheel 包然后 pip 安装wget https://github.com/airockchip/rknn-toolkit2/archive/refs/tags/v2.x.x.tar.gz tar zxvf rknn-toolkit2-v2.x.x.tar.gz cd rknn-toolkit2-v2.x.x pip install -r ./packages/requirements_cp38-2.x.x.txt pip install ./packages/rknn_toolkit2-2.x.x-cp38-cp38-linux_x86_64.whl第三步验证安装成功python -c from rknn.api import RKNN; print(RKNN-Toolkit2 ok)这里有个容易踩的坑如果提示找不到rknn模块大概率是 wheel 包和 Python 版本不匹配。cp38 的包只能用于 Python 3.8换版本或者找对应版本的包。第四步如果你的 PC 没有接 GPU可能会缺一些依赖库。如果后面模型转换或仿真推理报libGL.so.1这类错误执行sudo apt install libgl1 libglib2.0-03.2 板端环境准备板子端需要准备两样东西一个可用的 Linux 系统我用的是 Ubuntu 20.04 的 ROC-RK3588S-PC 固件官方发布的 Buildroot 也可以但 Ubuntu 的调试体验好很多以及板子的 RKNN Runtime 库librknnrt.so。获取 librknnrt.so 有两种方式一种是直接从系统镜像带有的/usr/lib/librknnrt.so拷贝另一种是从 RKNN-Toolkit2 包的runtime/Linux/librknn_api/aarch64目录拷贝后推送到板子。我个人更推荐后者确保版本和 PC 端的 rknn-toolkit2 版本一致。版本不一致时最典型的症状是PC 端转换的模型在板端加载失败错误码往往是 RKNN_ERR_PARAM_INVALID 或者直接的 load 失败。推送命令adb push librknnrt.so /usr/lib/ adb push rknn_yolov8_demo /userdata/我这里用的 adb 连接因为 RK3588 板子通常是支持 adb 的。如果你没有 adb可以用 scp 走网络先把板子和 PC 连接到同一局域网然后scp传文件。反正都行看你的网络习惯。另外板端还需要装一个 Python 环境用于跑 Python API。但更推荐用 C API 部署性能更好、依赖更少。后面两节会分别讲到。4. 模型转换核心流程yolov8 的 RKNN 格式生成4.1 模型准备PyTorch 到 ONNX 的坑yolov8 的官方权重是 PyTorch 格式yolov8s.pt。RKNN-Toolkit2 支持直接加载 PyTorch 模型但官方更推荐先导出 ONNX再转 RKNN。原因在于ONNX 是一种更通用的计算图中间表示便于算子检查和调试转换链路也更稳定。先把 ultralytics 的 YOLO 包安装好然后导出 ONNXpip install ultralytics yolo export modelyolov8s.pt formatonnx opset12 simplifyTrue这里有几个关键参数需要说明opset12ONNX 算子的版本。版本太高比如 17、18可能导致某些算子无法映射到 RKNN版本太低又可能缺少某些新算子。实测 12 是最稳妥的。simplifyTrue开启 ONNX 图精简去掉一些冗余的恒等映射和 reshape 节点让后续 RKNN 转换的算子匹配率更高。batch1默认导出为 batch1RKNN 部署时一般也不需要动态 batch。导出后最好用netron工具看一眼 ONNX 结构。重点检查输出节点yolov8 原始输出是(1, 84, 8400)的形状其中 84 4 个 bbox 参数 80 个类别得分8400 是所有尺度特征图的 anchor 总数。这个张量在 NPU 上直接输出后在板端还要做后处理NMS把预测框筛选出来。4.2 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(modelyolov8s.onnx) assert ret 0, load onnx failed # 构建 RKNN 模型这一步做算子的映射、优化和量化 ret rknn.build(do_quantizationTrue, datasetdataset.txt) assert ret 0, build failed # 导出 RKNN 模型 ret rknn.export_rknn(yolov8s.rknn) assert ret 0, export failed这里的dataset.txt是量化校准集的文件列表每一行是一张图片的路径。由于 RK3588 的 NPU 主要跑 INT8 推理浮点模型在做 INT8 量化时需要一个校准集来确定每层激活值的动态范围从而计算 scale 和 zero point。校准集一般准备 100-200 张图片要尽量贴合实际推理场景——如果你部署的是工业检测场景就用工业场景的图片如果你用的是 COCO 这类通用数据集那随便找点自然图片也能用。校准图片数量我建议至少 100 张。太少会导致某些层的动态范围估算不准推理精度明显下降太多增加转换时间收益很小。我实测过 50 张与 200 张的量化结果在 mAP 上的差异基本在 0.5% 以内但如果少于 20 张掉点可能到 2% 以上。4.3 量化对精度的影响先说清楚INT8 量化不是无损的它本质上是在用信息丢失换推理速度。模型从 FP32 变成 INT8权重和激活值都被压缩到 8 位整数精度通常会有一定损失。yolov8s 在 COCO 上的 mAP 大概 44-45%量化后掉 0.5-1.5 个百分点实测正常范围内。如果觉得精度掉得不能接受有几个可行的调整方向换用 FP16 推理精度几乎无损但推理速度大约是 INT8 的 60%-80% 左右取决于模型和带宽。提供更贴近实际场景的校准集尽量覆盖目标大小、光照、遮挡等多样化样本。尝试混合量化对敏感层不做量化保留 FP16其他层用 INT8。RKNN-Toolkit2 支持quantized_dtype的 per-channel 配置但操作复杂度更高一般用不上。实际项目里 INT8 足够满足需求cpu 上的 FP32 模型和 NPU 上的 INT8 模型在检测框位置和置信度上的差异肉眼基本无法分辨。我先把这个结论放在这里后面第 6 节会展示我在 yolov8 上的实测数据。5. 板端部署RKNN Runtime 的使用细节5.1 Python 快速验证一条龙推理拿到yolov8s.rknn文件之后如果想快速在板子上验证能否正常推理用 Python 接口是最快的方式。板端需要先安装rknn-toolkit-lite2的 wheel 包从 RKNN-Toolkit2 发布包的packages/rknn_toolkit_lite2目录获取import numpy as np from rknnlite.api import RKNNLite rknn_lite RKNNLite() ret rknn_lite.load_rknn(yolov8s.rknn) assert ret 0, load rknn failed ret rknn_lite.init_runtime() assert ret 0, init runtime failed img cv2.imread(test.jpg) # HWC, BGR img cv2.resize(img, (640, 640)) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) outputs rknn_lite.inference(inputs[img], data_formatnhwc)这里有一个关键点值得强调init_runtime()如果不指定target参数在板子上会直接使用 NPU 执行在 PC 端上则会用 CPU 模拟推理速度很慢但可以验证正确性和精度。调试时可以在 PC 上先跑一遍仿真再用板子验证。inference的data_format参数也容易搞错。如果传的是nhwc表示输入是[1, h, w, c]排布如果传nchw输入不同。RKNN 内部默认使用 NHWC 的排布方式因为这是 NPU 硬件友好的存储格式所以模型的输入配置在转换时如果用的nhwc那推理时也要保持一致。省力起见我一般都统一传nhwc。5.2 C API 部署正式项目的最佳选择Python 方案验证逻辑没问题之后正式项目需要切到 C API。原因显而易见C 接口不依赖 Python 解释器启动更快、内存占用更低、更适合作为服务常驻将推理封装成动态库之后可以与任何语言C/Rust/Go 等的业务代码集成。一个最小的 C 推理程序包含核心步骤#include rknn_api.h // 1. 加载模型文件到内存 FILE *fp fopen(yolov8s.rknn, rb); fseek(fp, 0, SEEK_END); size_t model_size ftell(fp); fseek(fp, 0, SEEK_SET); void *model malloc(model_size); fread(model, 1, model_size, fp); fclose(fp); // 2. 初始化上下文 rknn_context ctx; rknn_init(ctx, model, model_size, 0, NULL); // 3. 查询输入输出信息 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); rknn_tensor_attr input_attrs[io_num.n_input]; // ... 遍历填充 attr 并查询 // 4. 创建输入张量 rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf img_data; inputs[0].size 640 * 640 * 3; // 5. 执行推理 rknn_run(ctx, NULL); // 6. 获取输出 rknn_output outputs[io_num.n_output]; outputs[0].want_float 1; rknn_outputs_get(ctx, 1, outputs, NULL); // 7. 后处理NMS 过滤 // ... 按需实现 // 8. 释放资源 rknn_outputs_release(ctx, 1, outputs); rknn_destroy(ctx); free(model);有几点实操心得rknn_init的 flag 参数传0表示默认使用 NPU 核心。RK3588 上有三个 NPU 核心如果要做多模型并行推理或单模型核心负载均衡需要设置RKNN_FLAG_ASYNC_MODE以及对应核心绑定。多核调度是后续调优的方向第一版先把单核跑通。输入图片的预处理resize、归一化、像素格式变换如果放在 CPU 上做会占用相当可观的耗时。RK3588 有 RGARaster Graphic Acceleration硬件加速模块可以完成纯拷贝、格式转换如 NV12 转 RGB、缩放等操作把预处理卸载到硬件上。这在追求实时性的项目里是标配做法。模型输出拿到的是一个浮点数组如果你设want_float1。yolov8 的输出是 8400 个候选框加 84 维特征。NMS 后处理在 CPU 上跑8400 个候选框的 NMS 大概耗时 3-5 毫秒取决于 CPU 主频在 640x640 输入下整体推理 10-20 毫秒的预算里占比不小可以尝试优化成 TopK 截断后再跑 NMS能省掉一半时间。5.3 零拷贝与内存复用用 C API 部署时有一个容易忽略但影响巨大的概念零拷贝zero copy。默认的rknn_run流程是CPU 侧准备一段输入内存推理时 NPU 从这段内存中读取数据输出结果再写回 CPU 侧的内存。这意味着输入和输出各有一次 PCIe/总线上的搬运开销。如果输入是一张 640x640x3 的 RGB 图约 1.2MB一帧搬运虽然不大但积少成多。RKNN 提供了rknn_create_mem接口来预先分配 NPU 可访问的内存然后用rknn_set_io_mem绑定到输入输出上rknn_tensor_mem *input_mem rknn_create_mem(ctx, 640 * 640 * 3); rknn_set_io_mem(ctx, input_mem, input_attrs[0]); // 推理时直接将图像数据填充到 input_mem-virt_addr memcpy(input_mem-virt_addr, img_data, 640 * 640 * 3); rknn_run(ctx, NULL);这样做的好处是模型加载后内存只分配一次每帧推理复用它避免频繁分配和释放带来的性能抖动。实测使用零拷贝后,单帧推理耗时能降低 1-3 毫秒同时 CPU 占用率下降。6. 实战案例yolov8s 在 RK3588 上的完整部署6.1 推理程序整体设计这一节把前文的内容串起来给一个我实际跑通的 yolov8s 部署方案。整个程序的结构分为四个模块模型加载与初始化、图像预处理、推理与后处理、结果可视化。因为 RK3588 板子上的目标是用 C 写部署程序我把主要逻辑都放在 C 侧。核心模块划分如下rknn_model类封装模型加载、上下文创建、输入输出张量管理、推理调用对外只暴露init()和inference(cv::Mat, std::vectorDetectResult)两个接口。后处理模块解析原始输出做置信度过滤、类别解算、NMS 过滤输出最终的检测框列表。性能统计用std::chrono对预处理、推理、后处理分别计时方便调优。6.2 关键代码与参数说明先看预处理部分。yolov8 训练时输入是 640x640而相机/图片的真实尺寸往往不是这个比例。直接resize会破坏宽高比导致目标变形直接影响检测精度。业界标准的做法是 letterbox等比缩放后在短边两侧填充灰色像素通常用 114 或 128 填灰。cv::Mat letterbox(const cv::Mat src, int target_w, int target_h) { float scale std::min(1.0f * target_w / src.cols, 1.0f * target_h / src.rows); int new_w static_castint(src.cols * scale); int new_h static_castint(src.rows * scale); cv::Mat resized; cv::resize(src, resized, cv::Size(new_w, new_h)); cv::Mat dst(target_h, target_w, CV_8UC3, cv::Scalar(114, 114, 114)); int x_offset (target_w - new_w) / 2; int y_offset (target_h - new_h) / 2; resized.copyTo(dst(cv::Rect(x_offset, y_offset, new_w, new_h))); return dst; }这里的scale通常会结合 IMG 输入的实际需求进一步优化。由于 RK3588 的 NPU 内部对宽度有 16 字节对齐要求输入宽度最好选择 16 的整数倍640 就是 40x16没问题。推理获得原始输出后后处理的第一步是把数据整理成方便操作的形态。yolov8s 原始输出 shape 是(1, 84, 8400)在 C 里我们用指针偏移来遍历int num_anchors 8400; int num_cls 80; float* out_data outputs[0].buf; // out_data 的排布先 4 个 bbox 坐标再 80 个类别得分 for (int i 0; i num_anchors; i) { float* row out_data i * (4 num_cls); float obj_score 0.0f; int cls_id -1; for (int j 4; j 4 num_cls; j) { if (row[j] obj_score) { obj_score row[j]; cls_id j - 4; } } float score obj_score; // yolov8 没有独立的 objectness 分支 if (score conf_threshold) continue; // bbox 坐标反解注意 yolov8 输出是中心点宽高距当前特征图左上角的偏移 float cx row[0], cy row[1], w row[2], h row[3]; // 映射回原图坐标... }一个容易出错的地方是坐标映射。模型的输出坐标是在 640x640 输入尺度下的letterbox 做了等比缩放和填充所以恢复原图坐标时需要反向操作先把坐标减去填充偏移再除以缩放比例。如果漏掉这一步检测框会整体偏移看起来框不准。NMS 我用了一个简化版本先把所有候选框按置信度降序排序然后逐个遍历与已保留的框计算 IoU超过阈值就丢弃。8400 个候选框的 NMS 是 O(n^2) 复杂度实测大约 4 毫秒。如果你的模型需要更实时可以用类别内 NMS 并行化或者用 Faster NMS 的正则化方法省到 1-2 毫秒。6.3 性能实测与调优记录我用上面这套流程在自己的板上跑了一轮基准测试输入 640x640模型为 yolov8sINT8 量化。测试条件CPU 被设置为性能模式NPU 单核Ubuntu 20.04。表格是实测数据阶段耗时图像预处理letterbox 格式转换1.1 msNPU 推理648x648 输入INT812.7 ms后处理置信度过滤 NMS3.4 ms单帧总耗时17.2 ms这个耗时意味着单线程下大约能跑 58 FPS。如果再多花点精力优化预处理换 RGA后处理用 TopKNMS 代替全量 NMS整体有望压到 13-14 ms达到 70 FPS 以上。对大多数边缘检测场景已经足够。如果在你的板子上性能明显偏差可以从几个方向排查CPU 是否开启了性能模式RK3588 默认可能有功耗管理策略用cpufreq-set -g performance切换。输入图像是否做了适当的resize直接喂 4K 原图会让推理耗时成倍增长因为算力与分辨率成正比。量化模型是否真的在 NPU 上跑在部分框架下如果算子不支持会回退到 CPU 跑这种情况下 NPU 占用率极低但 CPU 飙升单帧耗时可能超过 100 毫秒。用rknn_query查询算子运行设备可以确认。6.4 精度对比FP32 模型 vs INT8 NPU 模型我用自己的测试集大约 200 张图片包含行人、车辆、遮挡、夜间等复杂场景做了对比评估指标用 mAP0.5 和 mAP0.5:0.95模型形态mAP0.5mAP0.5:0.95备注PyTorch FP32服务器0.8720.613基准RKNN FP16 仿真0.8680.609几乎无损失RKNN INT8 板端推理0.8560.593掉 1.6% 左右INT8 与 FP32 相比COCO 风格的 mAP 掉 1-2 个百分点在边缘设备上属于完全可接受的范围。如果你用常规的、目标较大且形态简单的场景比如翻斗车识别、工地工人安全帽检测这个精度损失几乎感知不到。7. 常见问题与排查技巧实录这一段时间踩过的坑实在太多了挑典型的几个整理成速查表希望能帮你少走点弯路。现象可能原因排查与解决build阶段报算子不支持ONNX 里含有 NPU 不支持的算子用rknn.build(do_quantizationFalse)看报错算子名结合网络结构替换对应模块如把 SiLU 换成 ReLU或升级 RKNN 工具链版本模型转换成功但推理输出全 0输入格式与模型期望不匹配检查data_format是否设置正确确认图片是 RGB 且尺寸匹配模型输入用netron对比输入 shape板端load_rknn失败模型版本与板端运行库版本不匹配确保 PC 端RKNN-Toolkit2和板端librknnrt.so版本号一致推理速度明显偏慢模型部分算子回退到 CPU用rknn_query查询算子执行设备看日志里是否有fall back to CPU警告重新量化或修改模型结构量化后精度掉太多校准集不够或分布偏差大校准集增加至 100-200 张尽量用真实场景图对低分辨率目标做上下采样增强内存泄漏rknn_output未释放每次循环推理后调用rknn_outputs_release检查rknn_destroy是否在退出时调用adb 无法识别设备驱动/权限问题换 USB 口和线材sudo adb kill-server sudo adb start-server部分板子需要手动进入 ADB 模式另外分享一个屡试不爽的排错思路把编译问题、推理问题、后处理问题分开隔离。当你拿到一个全新的模型第一步先在 PC 上用 RKNN-Toolkit2 自带的仿真功能跑一次确认模型转换和输出是正确的再上板用最简单的img[:,:,::-1]这种输入验证 IO 通道最后再接入完整的业务逻辑。这样每一步都有明确的验证边界不会出现前面错了但到了最后才发现的尴尬情况。还有一个经验是务必要做版本管理。RKNN 工具链的迭代速度很快不同大版本的 API 和算子支持差别不小。我在项目中就把工具链版本号、Python 版本、板端 runtim 版本、模型文件大小和 SHA256 都记录在项目的 README 里避免过两周同事用新版本重新转模型结果行为不一致。8. 扩展方向与个人体会跑通了 yolov8s 之后这套链路可以延伸到更多玩法。举个例子如果你想在 RK3588 上跑大语言模型的端侧部署类似 Ollama 的思路NPU 的 INT8 算力也可以用来跑量化后的 embedding 模型和部分轻量级生成模型。但 NPU 对 Transformer 结构的支持目前不如对 CNN 友好很多算子需要手工替换坑比 yolov8 多不少。模型方面我也试过 yolov5、yolov6、yolov7 的转换除了个别算子的适配难度不同整体流程基本一致——所以这篇博文的经验是通用的。FastestDet、PicoDet 这类轻量检测器也支持良好推理速度更快一张 640x640 的输入在 NPU 上可以跑到 6-8 毫秒。另外多核 NPU 的调度值得好好研究。RK3588 的 NPU 是三核架构官方支持把不同的模型分配到不同核心比如一个核心跑检测另一个核心跑分割也可以让单个大模型跨核并行。这一块要用到rknn_init里的核心绑定参数和异步推理模式对实时多任务场景提升显著。最后再分享一个小技巧板子上的/proc/rknpu路径下会有一些 NPU 的调试信息比如当前利用率、频率、温度。在排查性能瓶颈时cat /sys/kernel/debug/rknpu/load能看到实时的 NPU 负载情况。如果负载接近 100%说明算力已经是瓶颈该考虑更小的模型或者降低输入分辨率如果负载只有 30%那时间大概率消耗在 CPU 端的数据搬运和后处理上。总的来说RK3588 的 NPU 部署并不是一条特别平坦的路工具链的文档细节少、版本更新快、网上有效资料也有限。但一旦把转换、量化、部署、后处理这条链路完整打通后续做任何新模型都只是重复劳动而已。希望这篇博文能帮你少走点弯路早点跑起你自己的模型。