RK3588 NPU多模型视觉部署实战：从YOLO转换到并发调度

1. 项目概述：为什么要把三个视觉任务塞进同一块 RK3588

近几年边缘计算设备在安防和物联网场景里越来越“卷”，单颗芯片往往要同时承担多路视频分析。这次的项目背景很简单：一台 RK3588 工控机，接入一路RTSP摄像头画面，要在 NPU 上同时完成人员入侵检测、烟火检测、垃圾分类三个视觉任务，而且不能明显掉帧。听起来像是在给算法工程师出难题，但实际做下来，RK3588 的 6 TOPS NPU 应付这三个模型是有余量的，关键在于任务划分和调度设计。

先说结论：单块 RK3588 跑三个检测模型完全可行，实测稳定在 25~30 FPS，CPU 占用率控制在 30% 以内。这个成绩的前提是——模型要选对、量化要做足、多路推理要串行复用同一块 NPU，而不是简单粗暴地开多个进程抢算力。

如果你正打算在 RK3588（或者 RK3568、RK3576）上部署多模型视觉任务，这篇文章可以帮你少踩不少坑。我会从模型选型、RKNN 转换、NPU 并发调度、内存带宽优化这几个维度完整走一遍，最后附上调试过程中记录的问题和排查思路。

2. 整体设计与算力预估算

2.1 三个任务的共性特征分析

人员入侵检测、烟火检测（烟雾和火焰）、垃圾分类，这三个任务看起来跨度很大，但从视觉算法角度有非常多的共性：

• 都是基于目标检测框架，不需要实例分割或关键点检测这类重输出头；
• 输入分辨率要求都不高，640x640 已经是“顶配”，实际部署甚至可以降到 416 或 320；
• 都属于可离线推理的任务，对延迟敏感度中等（200ms 以内可接受）；
• 后处理逻辑相似，都是 NMS + 类别过滤。

这些共性决定了我们的技术路线：统一采用 YOLO 系列检测模型，通过 RKNN Toolkit 转换成 RK3588 NPU 能识别的 rknn 格式，然后在一个应用进程里串行调用三个模型实例。

2.2 为什么选 RK3588 而不是外挂 GPU 或多芯片

RK3588 的 NPU 算力标称 6 TOPS（INT8），单看数字不算夸张，但它在端侧设备里的优势非常明显——四核 A76 + 四核 A55 CPU、自带 8K 视频解码单元、支持多路 MIPI/RGB 输入、功耗控制在 5~12W，这些能力让它天然适合做“一台设备八个功能”的集中式方案。

对比其他方案：

综合评估下来，RK3588 是“单板多任务”场景下性价比最高的选择。关键是 RKNN 工具链经过几个版本迭代，现在对 YOLO 系列的支持已经相当完善，从 PyTorch 到 rknn 几乎一条龙。

2.3 算力预算与任务拆解的数学基础

在做具体开发前，先把账算清楚：

假设三个模型都采用 YOLOv5s 结构，输入 640x640，INT8 量化后的单次推理耗时在 RK3588 NPU 上大约是 45~55ms。如果三个任务串行跑，一帧的总耗时约为 150ms，对应帧率只有 6~7 FPS，显然不行。

所以算力预算是这样拆的：

• 人员入侵检测：模型输入降到 320x320，单次推理约 25ms；
• 烟火检测：保持 640x640 提高小目标召回，单次推理约 50ms；
• 垃圾分类：输入 320x320，类别数多，单次推理约 35ms；

如果完全串行，一轮总耗时 110ms，约 9 FPS。但因为三个任务的输入源都是同一路视频流，完全没必要“逐帧串行”，而是可以用多线程并发提交不同的帧给 NPU，让 NPU 的 MAC 阵列始终保持忙碌，这样整条管线可以达到 25~30 FPS。这个思路后面会详细展开。

3. 模型选型与 RKNN 转换实操

3.1 模型选型的取舍

RK3588 的 NPU 虽然支持主流的 CNN 结构，但不同模型的算子拆解效率差很多。我的实际经验是：

• YOLOv5s是 RKNN 工具链优化最好的检测模型之一，算子全部映射到 NPU，几乎不会回退到 CPU；
• YOLOv8s在 RKNN 上也能跑，但 DFL 解码头的后处理如果处理不当，耗时会有明显增加；
• YOLOX的解耦头在 NPU 上稍逊，需要跑 RKNN Toolkit 时额外配置；
• PP-YOLO系列不建议，部分算子不支持 INT8 量化，会掉精度。

这次项目里，人员入侵和垃圾分类我选了 YOLOv5s，烟火检测选了 YOLOv8s（因为烟火目标形状不规则，YOLOv8 的 anchor-free 设计召回更好）。

3.2 RKNN Toolkit 环境搭建与转换完整流程

如果你用的 RKNN-Toolkit2 是 1.6 版本，转换过程大概是这样：

# 安装依赖（Python 3.8 + 宿主机建议 Ubuntu 20.04） pip install rknn-toolkit2==1.6.0 # 转换脚本核心部分 from rknn.api import RKNN rknn = RKNN() # 配置模型输入，这里用 onnx 作为中间格式 rknn.config(mean_values=[[0,0,0]], std_values=[[255,255,255]], target_platform='rk3588') # onnx 模型加载 rknn.load_onnx(model='./yolov5s_320.onnx') # 量化数据集（推荐用 100~200 张真实场景图） rknn.build(do_quantization=True, dataset='./dataset.txt') # 导出 rknn 文件 rknn.export_rknn('./yolov5s_320.rknn') rknn.release()

几个值得注意的参数：

• target_platform必须指定rk3588，否则工具链会默认按 rk3568 优化，某些算子的排布会差一截；
• mean_values和std_values要和训练时保持一致。如果训练用的是归一化到 0~1 的流程，配置应该是mean_values=[[0,0,0]], std_values=[[1,1,1]]；
• 量化数据集不要只用公开图片，最好从实际部署环境的摄像头里抽帧。烟火这类带颜色特征的目标对量化敏感，数据集里必须包含火灾、烟雾的样张，否则量化后掉点特别明显。

3.3 混精度量化：烟火检测不掉点的关键

INT8 量化默认是全量化，遇到烟火模型会导致小目标漏检率上升 15% 以上。解决办法是混精度量化——让部分对量化敏感的层保持 FP16。

在 RKNN Toolkit 2 里，可以通过rknn.config的quantized_dtype参数做逐层指定，或者在rknn.build之后调用rknn.quantize配合quantized_algorithm来设置。实际操作中我列出了烟火模型的敏感层清单（主要是浅层输出通道少的卷积层），只对这几个层用 FP16，其余 INT8，模型体积只增大 15%，但小目标的召回率基本恢复到浮点水平。

注意：不要整个模型都用 FP16，那会失去 NPU 的 INT8 加速优势，推理速度直接翻倍下降。混精度的目标是“代价可控、精度可控”。

4. NPU 调度与多任务并发设计

4.1 RK3588 NPU 的真实工作模式

很多人在 RK3588 上做多路推理时，第一个想法是“开三个线程，每个线程各自调用 rknn_run”。这其实是常见的误解——单块 RK3588 的 NPU 不能同时并行执行三个独立模型，它的计算核心（两个 NPU core）共享一组 MAC 阵列资源，任务调度由 NPU 驱动内部的硬件调度器完成。多个线程同时调用 rknn_run 时，NPU 实际是把指令流排队执行，而每个模型切换时需要重新配置权重和激活缓冲区，切换开销如果控制不好，效率反而比串行还低。

正确的做法是串行提交、异步查询、帧流水线并行。

4.2 代码实现：固定大小输入 + 单独句柄

我用的 RKNN Python 接口版本是 1.6.0，核心代码如下：

import numpy as np import cv2 from rknnlite.api import RKNNLite # 初始化三个 RKNNLite 实例 rknn_person = RKNNLite() rknn_fire = RKNNLite() rknn_garbage = RKNNLite() rknn_person.load_rknn('./yolov5s_320.rknn') rknn_fire.load_rknn('./yolov8s_640.rknn') rknn_garbage.load_rknn('./yolov5s_320.rknn') rknn_person.init_runtime(core_mask=RKNNLite.NPU_CORE_0_1) rknn_fire.init_runtime(core_mask=RKNNLite.NPU_CORE_0_1) rknn_garbage.init_runtime(core_mask=RKNNLite.NPU_CORE_0_1)

注意我在初始化时指定了core_mask=RKNNLite.NPU_CORE_0_1，即使用两个 NPU core。实测三个模型都开到双核心时，NPU 利用率最高，而且不容易死锁。

推理阶段不要直接连续调用三个rknn.inference，因为那是同步阻塞的。我的做法是：

# 用三个线程分别从同一个视频帧队列取帧，各自推理 def infer_loop(model, input_queue, output_queue): while True: frame = input_queue.get() img = cv2.resize(frame, (model.input_size, model.input_size)) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) outputs = model.inference(inputs=[img]) output_queue.put(outputs) # 视频采集线程 def capture_loop(cap, person_q, fire_q, garbage_q): while True: ret, frame = cap.read() if not ret: break person_q.put(frame) fire_q.put(frame) garbage_q.put(frame)

这样采集帧是同一个 Frame 对象，三个推理线程各自 resize 和预处理，NPU 底层通过 RKNNLite 的排队机制串行跑，但因为是三路流水线，采集一帧的同时另外两个模型可能正在跑上一帧或上上帧，整体 FPS 就上来了。

4.3 帧队列深度和丢帧策略

队列长度建议固定为 3，不要用无界队列。否则当 NPU 处理不过来时，内存里堆积大量待处理帧，延迟越来越高，最终画面卡顿甚至 OOM。

丢帧策略我选择“队列满直接丢弃旧帧，保留最新帧”。这个策略对检测类任务尤其重要——宁可偶尔跳一帧，也不能把延迟拉大。因为入侵检测、烟火检测本质上都是做“告警”，时间响应比连续检测更重要。

4.4 是否建议使用多进程

我的答案是：同一个应用里用多线程就够了，不要多进程。

多进程会带来三个问题：

• 每个进程都要 Load 一次 rknn 模型，RK3588 的 NPU 内存占用会翻倍；
• 进程间通信传递视频帧需要用共享内存或者编码传输，效率低；
• RKNNLite 的底层驱动对多进程并发支持不太友好，有时会出现莫名的推理失败或 NPU 卡死。

所以正确姿势是单进程 + 多线程 + RKNNLite 句柄隔离。

5. 内存带宽与预处理优化

5.1 RK3588 内存架构对多模型的影响

RK3588 是统一内存架构，NPU 和 CPU 共享同一片 LPDDR4X/5 内存。三个模型同时加载后，权重和激活值总共占用的 NPU 内存大约在 1.5~2GB 左右（取决于模型精度配置），如果用 8GB 版本，剩余空间还能跑系统和其他应用，但如果是 4GB 版本就必须做好内存预算。

你可以在代码里通过rknn.get_sdk_version()和rknn.get_mem_info()查看 NPU 内存分配，实时调整模型尺寸。

5.2 图像缩放和色彩转换的加速

每帧要做 640x640 和 320x320 两种 resize，加上 RGB 转换，如果用 Python 的cv2.resize+cv2.cvtColor实时做，CPU 占用会飙到 50% 以上。这块的优化空间非常大。

两个方案：

• 方案 A：直接在采集线程把一帧 RGB 图像转成 640x640 的 blob，再用cv2.resize从 640 resize 到 320，省去一次解码和色彩转换；
• 方案 B：用 NPU 的RKNNLite.inference里自带的预处理参数（inputs传一个带layout='nhwc'的 numpy 数组），让 RKNN 库内部做 resize 和量化，但这个方式灵活性差、输出尺寸限制死。

我最终采用的是方案 A：视频帧先解码为 BGR，cvtColor转一次 RGB 后，基于 640 尺寸做一次双线性插值，320 的输入直接从 640 缩放过来。这样三个模型共享一次色彩转换，CPU 占用显著下降。

5.3 后处理逻辑解耦

三个模型的后处理（NMS、坐标还原）不要在 NPU 推理线程里做。正确做法是推理线程只负责inference拿到原始输出，然后丢给另一个线程做 NMS 和业务逻辑。因为 NPU 推理是重负载，后处理是轻负载，混在一起会导致推理队列阻塞时间增加，整体吞吐下降。

6. 常见问题与排查技巧实录

6.1 打开/dev/rknpu报错或初始化失败

这是 RK3588 新手最容易遇到的坑。三个RKNNLite.init_runtime()同时执行时，偶发会出现ERROR: failed to open device /dev/rknpu: Device or resource busy。

原因：RKNNLite 默认会占用全部 NPU 资源，多个实例同时 init 时驱动内部会发生资源竞争。

解决办法：

• 确保内核驱动版本是 rknn_server 1.6 以上（RKNPU2 的固件都会带）；
• 初始化时统一用core_mask=RKNNLite.NPU_CORE_0_1，避免某个模型单独占用单核；
• 如果仍然偶发，在 init 前加一个 500ms 的随机延时，实测能显著降低冲突概率。

import time time.sleep(0.5) # 在 init 前加延时

6.2 NPU 推理速度突然变成 CPU 速度

模型转换时如果算子没有被 NPU 完全支持，RKNN Toolkit 会自动把部分算子回退到 CPU。表现就是单次推理 cpu 占用高、耗时翻好几倍。

排查方法：

# 在 convert 阶段打印 rknn.build(do_quantization=True, dataset='./dataset.txt') rknn.list_support_ops()

如果发现某些操作不在支持列表里，优先换模型结构。比如用 YOLOv5s 而不是 YOLOv5m，后者的某些大卷积可能回退到 CPU。另外注意 RKNN Toolkit2 对 PyTorch 模型要求先导出为 ONNX，且 ONNX opset 版本最好用 11~12，版本太高容易生成 NPU 不支持的算子。

6.3 三个模型同时跑导致 NPU 崩溃或驱动死锁

这个问题在多线程并发时容易遇到，通常不是代码逻辑问题，而是 RKNNLite 的驱动调度 bug 或者内存越界。

我遇到的情况是：连续跑 24 小时后inference突然超时，接着rknn_run返回错误码 -1，最终整个线程异常退出。

排查思路：

• 第一步，抓 dmesg：dmesg | grep rknpu，看有没有reset或timeout日志；
• 第二步，检查是不是某个模型的输入尺寸不固定。RKNN 模型一旦 load 后，inference的输入张量尺寸必须保持严格对齐，如果 resize 时出现边界情况导致尺寸不匹配，驱动底层会认为调用非法；
• 第三步，确认三个模型每个都创建了独立的 RKNNLite 实例后，init_runtime的core_mask不要混用，统一NPU_CORE_0_1稳定些。

最后我加了看门狗线程，如果连续 5 秒没有新的输出，就重建整个 NPU 相关实例——虽然听起来很糙，但端侧设备上非常实用。

6.4 后处理卡顿导致整体延迟升高

三个模型的后处理如果都在 Python 里用纯 for 循环跑 NMS，当画面上目标数量多时会突然卡几百毫秒。

我的做法是：

• 把后处理改为向量化操作（numpy 操作替代 for 循环）；
• 利用多线程并行处理三路后处理结果；
• 如果追求极限性能，后处理代码可以拆出来用 Cython 或 C 写，绑定到 Python。

实测前后对比：最坏情况下后处理耗时从 180ms 降到 30ms，体感非常明显。

6.5 RK3588 温度过高导致性能下降

这是最后一个容易被忽略的坑。RK3588 在满载 NPU 的场景下，SoC 温度很快能到 80°C 以上，这时 NPU 会主动降频，推理速度从 50ms 飙升到 80ms。

解决方法是：

• 散热：如果使用开发板，至少加装主动散热风扇；如果是嵌入式整机，确认外壳有足够散热开孔；
• 系统层面开启温度监控，当 NPU 温度超过 85°C 时，主动丢弃部分非紧急推理帧（比如垃圾检测可以降低采样率到每 3 帧一次）。

7. 实测数据与后续改进空间

用同一路 1080p RTSP 视频流做最终验证，完整管线（解码、三路推理、后处理）稳定运行 72 小时无重启，关键指标如下：

这个结果已经满足项目现场要求。如果想进一步压榨性能，可以考虑三个方向：

• 优化输入尺寸：烟火检测在 640 下效果更好，但人员入侵和垃圾分类降到 256 甚至 224，可以显著减少 NPU 占用；
• 用 C++ 重写整个管线，Python 版本在解码和后处理上还有提升空间；
• 对后处理结果做时间戳合并，把三个模型的检测结果统一到同一个时间帧上，避免出现同一时刻不同推理时间戳导致的上层业务混乱。

最后分享一个我踩过多次坑之后的体会：在 RK3588 这类端侧 NPU 上做多任务部署，真正困难的不是把单个模型跑起来，而是如何把三路推理的节奏调理清楚。很多时候你盯着单模型性能看每一项都合格，一并发就出各种问题，根源往往是 NPU 资源竞争的细节没有处理好。建议新上手的同学先把单模型跑通，再用串行方式跑通三模型，最后才上并发优化，一步一步来，少走弯路。