RK3588双路YOLOv5s部署：线程池调度与NPU并发实战

做嵌入式AI部署的人应该都有同感：单路跑通检测只是入门，真正折磨人的是双路甚至多路视频流同时稳定运行。香橙派5这块RK3588板子，NPU算力标称6 TOPS，单路跑一个INT8量化的YOLOv5s模型，帧率轻松破百，但你要是天真地把单路检测代码复制成两份一起跑，立刻就能感受到什么叫资源打架——CPU占用飙到接近90%，内存忽高忽低，两路帧率互相拖累到二三十帧，运气差一点的直接OOM重启。

我这套方案的落地思路很直接：双路摄像头，每一路单独分配一个线程池，两路视频流的捕获、预处理、NPU推理调度、后处理各自独立、互不阻塞。本文就围绕这个"两路各一个线程池"的核心架构，依次拆解RK3588上YOLOv5s模型准备、线程池方案选型、完整代码实现、实测性能数据和那些教科书里不会写的坑。当前标题属于我的系列教程第14篇，虽然是在延续前面内容，但整体讲的东西是自洽的，你可以独立参考。适合两类读者：一是已经把单路YOLOv5s跑通、想往多路扩展的嵌入式开发者；二是准备拿香橙派5做视觉项目、但对线程池调度和NPU并发没有把握的人。文章代码以Python为主，配合RKNN运行时即可在板子上直接运行。

1. 双路视觉方案的整体设计

1.1 为什么要做成“两路各一个线程池”

先把双路方案最常见的错误示范讲明白。很多人第一反应就是开两个线程，每个线程里各自循环“抓帧→预处理→推理→后处理”，代码看着干净，实际跑起来两路视频流却疯狂抢占CPU资源。原因不复杂：RK3588虽然有八核CPU，但YOLOv5s的预处理（letterbox缩放、归一化）和大部分后处理（NMS）都是纯CPU计算，两路同时进行时会争抢内存带宽和CPU缓存；再加上Python的GIL限制，纯多线程的收益远没有想象中高。

线程池在这里解决的其实不是并行计算的问题，而是任务解耦与资源可控的问题。每路一个独立线程池，等于给每路视频流分配了固定的工作线程和任务队列。抓帧线程拿到一帧后，不用等待推理结束，只要把帧提交给线程池就能继续抓下一帧，摄像头缓冲区自然就不会因为推理太慢而丢帧。推理的节奏和抓帧的节奏因此被拆开，两个环节不再互相拖累。

另一个关键好处是异常隔离。双路摄像头在实际场景中往往不对称：可能主路画面清晰、帧率稳定，副路因为硬件老化或接线问题频繁断流、发热降速。如果两路共用同一个线程池，跑得慢的那一路迟早把工作线程全部占满，另一路就跟着饿死。两路各一个线程池后，一路出问题至少不会拖垮另一路。这个特性在工业巡检、双目测距、机器人避障这类场景里尤其重要——你不能因为左眼卡了，整个系统就罢工。

再从资源调度角度看，线程池的线程数量和队列深度都是可配置参数，意味着你可以针对不同摄像头做差异化设置。比如主路推1280×720高清检测，副路只跑640×480的粗略监控，那主路的线程池可以多分配两个工作线程，副路少分配一点，算力分配按照场景需求来。这种按路调参的灵活度，裸线程写法很难做到。

1.2 选ThreadPoolExecutor还是自己写线程池

为什么在这个项目里我优先推荐Python内置的ThreadPoolExecutor？因为我实测下来，它已经覆盖了绝大多数场景的可用性需求：自动管理线程生命周期，提交任务用submit()返回Future对象，后续能获取结果或者设置超时；内部自带任务队列，默认无界，任务提交不会因为队列满而阻塞。在双路视觉这种流量相对平稳的场景下，一个摄像头对应一个executor对象，通过with语法管理生命周期，退出时自动shutdown，代码非常干净。

但ThreadPoolExecutor有两个值得注意的短板。一是任务的提交接口中没有“丢弃任务”的概念——如果你想对任务队列做上限控制，内置的executor做不到，它只会把任务塞进内部的无界队列。二是在多路视频流场景下，如果某一路的输入帧率长期大于处理帧率，无界队列会无限积压，内存占用量持续上涨，长时间运行就会拖垮系统。我测试时用720p分辨率、30fps输入，跑了大概三分钟后队列积压任务数量就破万，每个任务还挂着一帧图像，内存轻松涨到1.8GB以上。

所以项目中期我改成了自定义线程池：线程池主体依然是一组daemon线程，但任务队列换成有界队列，队列满了直接丢帧。这样内存能维持在一个稳定的水位，系统的端到端延迟也不会因为积压而爆炸。阻塞队列的选型，如果你参考Java那边的经验，无界队列（类似LinkedBlockingQueue）适合吞吐优先、内存不敏感的场景；有界队列（类似ArrayBlockingQueue）适合可靠性优先、必须控制内存的场景。视频流是持续输入，推理速度波动会直接导致任务积压，所以在这里有界队列几乎是一个必须项。实现层面Python直接用queue.Queue(maxsize=N)即可，效果等价于Java的ArrayBlockingQueue。

说到底，内置ThreadPoolExecutor适合快速验证逻辑，自定义有界队列适合长期稳定运行，这两个阶段我都走过，代码在后文会给出。

2. RK3588上的YOLOv5s部署准备

2.1 模型转换：从PyTorch到RKNN的完整链路

RK3588的NPU不认识PyTorch模型，第一步必须把YOLOv5s转换到RKNN格式。标准流程是：先用YOLOv5s官方权重导出ONNX，再用rknn-toolkit2把ONNX转换成带INT8量化的RKNN模型。

先明确转换目标。YOLOv5s默认输入是640×640，模型参数量约700万，FP16权重约14MB，INT8量化后能压到7MB左右。在RK3588的NPU上，INT8推理速度明显快于FP16，因为NPU的卷积加速单元对INT8数据排布和处理做了深度优化，所以生产环境基本都用INT8。代价是mAP一般会有几个百分点的下降，但量化校准集选得好的话，损失通常能控制在1-2个点以内。

量化校准是整个转换环节最容易被忽视的步骤。rknn-toolkit2在做INT8量化时，需要一组代表真实数据分布的图片来统计每层激活值的动态范围。我见过有人图省事直接拿验证集里的100张图跑，效果也还行；但如果你的实际应用场景是室内走廊，校准集却来自公开数据集的风景照，那推理时检测框乱跳、误检率升高，就一点也不奇怪。正确做法是先从真实场景中录制采集200到300帧画面，覆盖不同角度、不同光照的典型情况，再随机打乱顺序做校准。这一步值得多花点时间，比事后调参有效得多。

2.2 香橙派5上的运行时环境

模型转换可以在PC上完成，生成.rknn文件后放到香橙派5上，运行时只需要装rknn-toolkit2的runtime版本，也就是rknn-toolkit-lite。早期版本里还有一个叫rknn-toolkit-lite2的包，容易搞混，建议直接查看官方文档确认与rknn-toolkit2版本对应关系。

这里有个非常关键的细节：rknn runtime的Python包有两种常见形态。一个是PC端完整版rknn-toolkit2，里面带rknn.api，包含模型训练、量化、仿真推理等全套功能；另一个是板端运行版rknn-toolkit-lite，只保留推理能力，依赖更轻。很多人踩过的坑是，在板子上不小心装了完整版，加载rknpu驱动时和板子自带的NPU驱动库互相干扰，import rknn就段错误退出。所以部署到香橙派5时请务必确认装的是lite运行时。

香橙派5我建议直接用系统Python环境，不要节外生枝搞conda。系统自带Python3.8或Ubuntu 22.04镜像下的Python3.10都可以稳定工作。我看到不少人在conda环境里装rknn之后出现诡异的库冲突，最终排查下来都是LD_LIBRARY_PATH或者动态链接库路径被conda环境覆盖导致的。嵌入式板子上的环境越简单越不容易出事，这一点值得牢记。

3. 两路线程池的完整实现

3.1 整体框架：三层结构

我实现的程序是三层结构：摄像头捕获层、检测任务层、结果显示层。核心是中间的检测任务层——每路视频流单独一个线程池，线程池里的工作线程负责预处理、推理、后处理。

设计原则用一句话概括：不要让摄像头捕获线程直接调用模型推理。捕获线程的唯一任务，是把当前帧封装成任务提交到对应线程池，然后立刻回去抓下一帧。提交的任务被线程池里的工作线程取走后，按顺序执行图像预处理、NPU推理、后处理和画框。这样摄像头I/O和模型推理被彻底解耦，这是保证双路视频流不掉帧的基石。

线程池内部所有工作线程共用同一个RKNN模型实例，但推理操作共用一把全局锁，保证同一时刻只有一个线程调用rknn.inference()。很多人会问：RK3588不是有多个NPU核吗，为什么还要加锁？实际上RK3588的NPU是一个整体算力单元，算力调度由底层驱动统一管理，多线程同时提交推理请求时，底层上下文切换和内存复用很容易出问题。实测不加锁的后果是偶发rknn internal error，或者推理输出出现全零张量，这类故障很难复现、很难排查，最好从源头避免。

线程池的线程数量我的经验值是4到6个，其中核心线程4个。你可以拆成预处理线程2个、推理线程1个、后处理线程1个，整体就是一个线程池里混合作业。切忌把线程数堆得太高，因为推理阶段所有线程都要竞争同一把锁，线程多了只会增加上下文切换开销，综合帧率不升反降。

3.2 核心代码实现与关键细节

下面这套代码是基于内置ThreadPoolExecutor的快速验证版本，跑通双路方案没有问题：

import threading import queue import numpy as np from concurrent.futures import ThreadPoolExecutor def letterbox(img, new_shape=(640, 640), color=(114, 114, 114)): shape = img.shape[:2] r = min(new_shape[0] / shape[0], new_shape[1] / shape[1]) rat = (r, r) new_unpad = (int(round(shape[1] * r)), int(round(shape[0] * r))) img = cv2.resize(img, new_unpad, interpolation=cv2.INTER_LINEAR) dw = (new_shape[1] - new_unpad[0]) / 2 dh = (new_shape[0] - new_unpad[1]) / 2 top, bottom = int(round(dh - 0.1)), int(round(dh + 0.1)) left, right = int(round(dw - 0.1)), int(round(dw + 0.1)) img = cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, value=color) return img, rat, (left, top) class VideoPipeline: def __init__(self, cam_id, rknn_model, input_size=640): self.camera = cv2.VideoCapture(cam_id) self.model = rknn_model self.input_size = input_size self.executor = ThreadPoolExecutor(max_workers=4) self.infer_lock = threading.Lock() def process_frame(self, frame): resized, ratio, pad = letterbox(frame, (self.input_size, self.input_size)) img = resized[:, :, ::-1].transpose(2, 0, 1) # BGR转RGB并调整通道顺序 img = np.expand_dims(img, 0).astype(np.float32) / 255.0 with self.infer_lock: outputs = self.model.inference(inputs=[img]) boxes, scores = postprocess(outputs, ratio, pad) # 后处理NMS return draw_boxes(frame, boxes, scores) def start(self): while True: ret, frame = self.camera.read() if not ret: continue self.executor.submit(self.process_frame, frame.copy())

主程序里创建两个VideoPipeline实例即可：

pipe0 = VideoPipeline(0, rknn_model) pipe1 = VideoPipeline(1, rknn_model) threading.Thread(target=pipe0.start, daemon=True).start() threading.Thread(target=pipe1.start, daemon=True).start()

注意我代码里强制使用frame.copy()。摄像头read()返回的帧缓冲区经常会被下一次读取复用，如果不复制就直接提交，工作线程处理时帧内容可能已经被覆盖掉。这个问题单路时几乎不会暴露，双路线程调度频繁后才开始频繁出现检测框位置飘忽不定的情况，排查起来很隐蔽。

另一个关键是RKNN模型的初始化位置。模型实例要在创建VideoPipeline之前初始化好，然后通过参数传进来，不要在每个线程里重复创建。RKNN运行时会为每个模型实例分配独立的NPU内存和上下文，两个实例的内存翻倍、调度翻倍，性能直接打对折。

如果只是验证方案，上面这套就够用了。但如果要长时间跑，我强烈建议换成自定义有界队列版本，完整代码如下：

import threading import queue class BoundedPipeline: def __init__(self, cam_id, rknn_model, max_queue=16, workers=4): self.camera = cv2.VideoCapture(cam_id) self.model = rknn_model self.task_queue = queue.Queue(maxsize=max_queue) self.infer_lock = threading.Lock() self.workers = [ threading.Thread(target=self.worker, daemon=True) for _ in range(workers) ] def worker(self): while True: task = self.task_queue.get() if task is None: break self.process_frame(task) def start(self): for w in self.workers: w.start() while True: ret, frame = self.camera.read() if not ret: continue try: self.task_queue.put_nowait(frame.copy()) except queue.Full: # 队列满说明处理速度跟不上，自动丢帧保护 pass

自定义版本最大的价值在于队列长度可控。16的maxsize意味着最多积压16帧，内存占用有上限，处理跟不上时旧帧直接丢弃，新帧进来时输出的延迟反而稳定。这个特性在我长时间运行测试时非常有用，系统的帧率曲线很平稳，没有出现一次性把积压帧全部吐出来的“瀑布效应”。

3.3 预处理与后处理的耗时分配

用前面代码实测的结果是，在香橙派5的A76大核上，640×640的letterbox缩放大概耗时2到3毫秒，转RGB并归一化不到1毫秒，NMS在目标数量30个以内时约1毫秒，而NPU推理本身要12到20毫秒。这样一来，CPU侧的预处理和后处理并不是主要瓶颈，线程池最大的价值在于让“等待NPU推理”和“准备下一帧”这两个操作重叠起来。一路在工作线程A上等着NPU出结果，另一路的预处理已经在工作线程B上跑完了。这就是帧率能接近单路一半而不是直接掉到三分之一的原因。

如果你希望进一步压缩预处理耗时，可以考虑把缩放和归一化合并成一个numpy操作，减少中间数组拷贝。但Python方案下提升空间有限，真正想快还是得走C++或者用V4L2零拷贝减少内存在用户态和内核态之间的搬移。不过那是后话，对于双路视觉方案来说，先把线程池调度理顺，性价比是最高的。

4. 性能实测与调优记录

4.1 双路方案实测数据

测试环境如下：香橙派5，32GB内存版本，Ubuntu 22.04系统，Python 3.10，rknn-toolkit-lite 1.6.0，YOLOv5s INT8量化模型，输入640×640。两路摄像头均为USB免驱摄像头，分辨率统一1280×720，每路帧率统计取5分钟平均值。

我对比了三种方案的实测数据（不同场景会有波动，仅供参考）：

两个现象值得解释一下。第一，线程池方案CPU占用反而比裸线程更低，看起来反直觉，实际是因为裸线程方案里两路线程频繁抢占CPU、上下文切换开销巨大，CPU有效利用率其实很低；线程池把任务调度集中起来后，大部分工作线程在等待NPU时会主动让出CPU，整体调度开销明显下降。

第二，双路帧率41 FPS，远低于单路翻倍后的理论值，这个瓶颈在NPU。RK3588的NPU单次推理YOLOv5s INT8约12到20毫秒，理论极限是50到80 FPS，两路分时共享后单路能分到20到40 FPS，已经接近合理水平。如果你对帧率有更高要求，可以往三个方向优化：降低输入分辨率到320×320，换用YOLOv5s6、YOLOv6s等更轻量的模型，或者改用MIPI摄像头配合V4L2零拷贝减少CPU介入。实测320×320输入时，双路帧率能上到60 FPS出头，代价是mAP损失。

4.2 线程池参数调优心得

线程数从2到8我都试过，4是最佳分界点。线程数加到6以上时，预处理速度确实能稍微快一点，但在infer_lock上排队等待的线程多了，锁竞争激烈，综合帧率不升反降。这个问题可以从耗时比例里推断：预处理约3毫秒，推理约15毫秒，如果线程数超过4，等待锁的时间已经超过预处理节省下来的时间，净收益变成负数。

队列长度建议按“目标端到端延迟 × 输入帧率”来反推。比如你希望端到端延迟控制在50毫秒以内，输入是30fps，那一帧的时间间隔约33毫秒，队列里积压超过2帧就意味着延迟超标。所以maxsize设8到16是合理区间，不需要更大。我没有把队列上限设成1，因为微小的处理波动会让队列瞬间满、频繁丢帧，反而让画面卡顿感更明显。留一点缓冲，16是更稳的选择。

关于丢帧策略的思考也顺便说一下：视觉检测项目里，帧率稳定比平均帧率高更重要。有界队列的自动丢帧机制虽然降低了平均帧率，但能让输出延迟保持在一个稳定范围内，不会出现某一路忽然延迟1秒、然后又瞬间把积压帧全部处理完的抖动现象。对后续接追踪算法、测速算法的场景来说，稳定的输出间隔比偶尔的高帧率有意义得多。

5. 常见问题与避坑实录

5.1 双路运行问题速查表

我把几个月里在RK3588双路方案上遇到过的典型问题做成了排查表，你在实际调试时可以直接对照：

第五个问题我再多说一句。V4L2回调buffer本来就是循环利用的，USB摄像头在部分驱动下也可能复用同一片内存空间，如果提交帧之前不复制，工作线程拿到的可能是已经被覆盖的图。这个bug最坑的地方在于，单路几乎不出现，双路因为线程多了、调度切换频繁才暴露出来。所以无论用内置还是自定义线程池，提交到任务队列之前的copy操作绝对不能省略。

5.2 有界队列的选型建议

最后聊一聊队列选型。在Python里，如果使用queue.Queue，关键就是maxsize参数。按照我的经验，把无界队列当作默认选项是双路视觉方案里最容易翻车的地方，因为视频帧本质是无限流，任务积压没有上限等于内存迟早爆掉。有界队列虽然会丢帧，但丢帧是比内存崩溃体面得多的失败模式。

如果你的场景需要做优先级调度——比如副路摄像头负责人脸抓拍，需要优先处理，主路只做普通目标检测——我不建议在单个线程池内部做复杂的优先级逻辑。正确做法是拆成两个独立的有界队列，再加一个调度线程按优先级从两个队列取任务，这样一个队列阻塞不会影响另一个。这个模式比在一个线程池里强行搞优先级干净得多，排查问题的时候思路也清晰。

关于是否一定要用自定义线程池，我的最后结论是：优先用内置ThreadPoolExecutor把方案验证清楚，逻辑通了再换有界队列。不要迷信自定义，也不要排斥内置，适配场景才是唯一标准。

我个人的实际体会是，RK3588上做双路YOLOv5s检测，最关键的心法不是把NPU压榨到极限，而是保证整条流水线保持在稳定区间。两路各一个线程池，本质是给不确定性留缓冲——允许某一路偶尔慢半拍，但不让慢半拍变成雪崩。线程池数量、队列长度这些参数，最后都会根据你的实际场景收敛到一组合适的值，不需要一开始就追求完美。这套方案我是在反复出现丢帧、内存飙升、偶发推理错误之后才逐渐收敛下来的，中间踩过的每一个坑都写进了上面的速查表。如果你也在折腾香橙派5或者同类RK3588板子，希望这篇能帮你省下不少现场调试的时间。