RK3588双路视觉QoS严格优先：从CPU绑核到NPU调度的完整实践

做到方案二的双路视觉，已经是我在香橙派RK3588上折腾yolov5s的第四轮了。前面三个阶段，采集、模型转换、双路推理全都串通了，主路识别和副路检测都能出结果，但稍微跑久一点就会发现不对劲——两路摄像头一旦同时满载，帧率就开始互相打架。主路从稳定的30帧掉到15帧，副路后排队的图像越积越多，后台抓日志和SSH操作也卡得厉害。这个阶段的核心任务就一个：给双路视觉链路建立一套可落地的QoS机制，而且用的是严格优先。

这篇文章不会跟你聊“为什么QoS很抽象”这种话题，我会直接把我调通的细节、踩过的坑、改过的配置全部摊开。适合已经跑通双路推理、正要处理资源打架问题的人阅读，同时也给刚接触RK3588的人一条完整的参考路径：从模型量化、线程绑核，到tc网络调度、NPU推理排队，一层一层把优先级理顺。

1. 双路视觉方案二的整体设计与阶段四的目标

既然已经走到阶段四，有必要先把方案二的整体思路捋一遍。所谓“方案二”，是相对于一开始的单路方案说的——单路把所有算力都压在一路摄像头上，双路则要同时处理两路画面，一套yolov5s模型在同一个芯片上跑两份推理任务，输出独立的检测结果。方案二的优点是可以一板两用，主路用来做前向检测，副路做侧向或环视感知，硬件的利用率高。缺点也非常明显：RK3588就算有6 TOPS的NPU，资源也不是无限可分，两路同时跑，必定有竞争。

阶段四要解决的，就是竞争下的确定性问题了：哪一路检测结果先出，哪一路的画面优先被处理，哪一路的帧率可以被牺牲，这些都得在系统层面定下来。严格优先（Strict Priority）在这里的含义不是“两路都很快”，而是“关键路径上的任务永远先执行，直到它不再需要资源为止”。

1.1 方案二的前三阶段跑了什么

把这个阶段放在前面说，是因为阶段四不是凭空冒出来的功能，它是前三个阶段留下的“历史债”。

阶段一做的事是环境适配。香橙派RK3588这套板子，跑的是Linux系统（我用的Debian系镜像），先解决的是NPU驱动、RKNN-Toolkit2库、多路MIPI/USB摄像头接入这些底层问题。阶段二做的是yolov5s模型到RKNN格式的转换，包括只保留必要的输出层、量化成INT8、在PC上验证推理精度。阶段三做的是双路视频流的软件架构：两个采集线程、两个推理线程、两套后处理和显示逻辑，最终在屏幕上同时看到两个摄像头的检测框叠加画面。

前三个阶段搞定之后，功能没问题，性能的问题就暴露出来了。双路同时推理时，RK3588的CPU大核、NPU算力、内存带宽、甚至网卡出口的收发带宽都会争抢。阶段四的QoS严格优先，就是把“谁该抢、谁该让”的规则硬化下来。

1.2 为什么双路视觉必须引入QoS

有人会问，既然NPU有6 TOPS，跑两个yolov5s按理说绰绰有余，为什么要做调度？实际跑起来你就知道，瓶颈往往不在NPU本身的峰值算力，而在“访问路径”。

yolov5s单路模型量化成INT8之后，一次推理大概只要十几毫秒，看起来很快，但如果两路摄像头同时上来，采集线程、ISP处理、RGA缩放、模型推理、后处理NMS这些任务全都在竞争CPU核心和内存控制器资源。而且yolov5s里含有不少小算子，比如上采样、拼接、卷积后的激活操作，这些算子在NPU上不是全都能算的，一部分要回落到CPU上，CPU大核一旦被采集线程占满，推理延迟立刻升高。

没有QoS的时候，系统调度器按默认策略分配资源，谁先到谁先用，看起来很“公平”，但对视觉系统来说公平往往意味着关键路径失控。我们需要的不是公平，是“主路永远不被副路拖垮”。这就是严格优先的核心动机。

2. QoS严格优先：先搞清楚给谁优先、优先什么

进入实操之前，先把任务的优先级梳理清楚。很多教程上来就贴tc命令，说你这样配就对了。但那样配完你根本不知道自己在给谁优先，出了问题也没法改。我建议你先画一张实时链路图，把两路摄像头的数据流标出来，然后逐段打优先级标签。

2.1 双路视觉链路中的资源瓶颈拆解

以我的实际环境为例：主路摄像头是前向视角，负责障碍物检测，检测结果要实时反馈给上层控制逻辑；副路摄像头是侧向视角，负责环境记录，检测结果可以容忍几百毫秒的延迟。两条链路可以拆成下面几个资源点：

• 摄像头采集：主路的采集线程和副路采集线程都会触发DMA传输，抢占内存带宽。
• ISP/RGA处理：图片缩放、格式转换、去畸变，在RK3588上通常走RGA硬件，但调度的优先级是可配置的。
• NPU推理：两路共用同一个NPU，RKNN会话之间需要排队，谁先提交谁先执行。
• CPU后处理：NMS、坐标映射、绘制检测框，这里全是CPU计算，最容易互相干扰。
• 结果显示/推流：如果要把检测结果通过网络传给上位机，网卡队列也会冲突。

注意，这里的QoS不仅仅是“网络QoS”。很多开发者一提QoS就想到tc命令控制带宽，但在双路视觉里，QoS是一个系统级的概念——它需要覆盖CPU调度、NPU会话调度、内存带宽分配、网络队列调度四个层面。你只有把每一层的优先级都设定成同一个方向，严格优先才算真正落地。

2.2 严格优先和加权轮询怎么选

QoS调度里最常见的两种模式是严格优先（Strict Priority / Priority queuing）和加权轮询（WRR / Weighted Fair Queuing）。它们的区别决定这套方案的走向：

严格优先的逻辑是：只要高优先级队列里有任务，低优先级队列就必须等待。低优先级相当于“可运行但随时被抢占”。优点是关键路径时延极低且可预测，缺点是高优先级持续繁忙时，低优先级可能一直得不到执行——这就是所谓的“饿死”。

加权轮询的逻辑是：按照权重在多个队列之间轮流执行，高优先级获得更多时间片，但低优先级总能分到一部分带宽。好处是公平，坏处是延迟抖动不可控，关键路径上可能出现一个完整的调度周期等待。

双路视觉这种场景，主路需要的是“确定性时延”，而不是“平均带宽”。所以方案二选择严格优先是合理的。实现上，既可以采用网络设备中常见的classful qdisc，也可以在Linux线程调度里使用SCHED_FIFO实时优先级，这两者在RK3588的Linux系统里都支持得很不错。

3. 在RK3588上实现QoS严格优先的完整步骤

这一节是文章的重头戏。我按系统调度、NPU会话调度、网络队列三个层次来写，每一个层次都有可以直接照抄的配置方法。说明一下：以下配置基于我的实际环境，你的板子系统版本、内核配置可能有差异，但原理和步骤是通用的。

3.1 第一层：系统CPU调度与线程优先级隔离

首先是CPU层面的严格优先。RK3588是8核架构，4个Cortex-A76大核加4个Cortex-A55小核。A76处理能力明显强于A55，在做任务分配时，理想状态是把主路推理线程钉在A76大核上，把副路和后台任务赶到A55小核上，物理隔离，互不抢占。

我用的辅助工具是taskset和chrt。taskset用来设定CPU亲和性，chrt用来修改实时调度策略。启动主路推理进程时，这样操作：

# 查看哪个进程是主路推理线程 ps -eLo pid,tid,comm,psr | grep infer_main # 将pid为12345的主路推理线程锁定到CPU4-5（A76核） taskset -pc 4,5 12345 # 副路线程锁定到CPU0-1（A55核） taskset -pc 0,1 23456

仅仅绑核还不够，CPU调度器还会在同一个核上切换线程，所以要用chrt把主路线程的调度策略改成SCHED_FIFO，并给一个较高的实时优先级。SCHED_FIFO是真正的严格优先：一旦主路线程就绪，它会立即抢占同核上所有普通调度线程。

# 查看当前调度策略 chrt -p 12345 # 将主路线程设置成SCHED_FIFO，实时优先级85 chrt -f -p 85 12345

这里需要特别提醒：实时优先级不是越高越好。RK3588上如果多个线程都设置成SCHED_FIFO，同优先级的FIFO线程之间不会互相抢占，这会导致后到的推理请求排队时间过长。我实操下来主路给85、副路给50比较合适，主路被副路抢断的概率几乎为零，而副路也不至于完全饿死。

如果你不想每次启动都手工敲命令，可以直接在代码里用pthread API：

#include <sched.h> struct sched_param param; param.sched_priority = 85; pthread_setschedparam(thread_handle, SCHED_FIFO, &param);

这种方式的优点是不依赖外部工具，应用启动时自动完成配置。再配合一个systemd service文件，在服务启动时给进程授予实时调度权限，整个系统重启后也能自动生效。

还有一个容易被忽略的系统参数：/proc/sys/kernel/sched_rt_runtime_us。Linux内核默认会限制RT调度占用的总CPU时间（通常是95%），如果主路推理线程占用的CPU时间超限，内核会产生节流，导致明明设置了FIFO却还是出现卡顿。做严格优先部署时，需要把这个限制放宽：

echo -1 > /proc/sys/kernel/sched_rt_runtime_us

这一条我调试时查了很久，最终确定是它在偷偷限制RT线程的CPU时间。系统日志里看不到任何报错，但主路推理延迟就是不稳定，时好时坏，罪魁祸首就是RT预算被消耗完毕。

3.2 第二层：NPU会话调度与推理请求排队管理

CPU层面的严格优先只能解决CPU资源分配，但双路推理拼的是NPU资源。RK3588的NPU虽然有三个核心，但驱动层面的调度仍然遵循“先到先服务”——谁先调用rknn_run，谁先占用NPU。三路会话同时提交时，内部的调度行为对应用层是不可见的，因此需要应用实现自己的“请求优先级队列”。

我的做法是在应用层实现一个简单的优先级队列：主路推理请求进入高优先级队列，副路推理请求进入低优先级队列。一个调度线程负责从高优先级队列取请求提交给NPU，如果高优先级队列为空，再处理低优先级队列。伪代码如下：

import queue import threading high_queue = queue.Queue() low_queue = queue.Queue() def npu_scheduler(): while True: if not high_queue.empty(): req = high_queue.get() elif not low_queue.empty(): req = low_queue.get() else: time.sleep(0.001) continue run_inference(req)

严格来说，这个调度器是“非抢占式严格优先”——一旦副路推理已经开始执行，主路请求需要等待本次推理结束。要对到毫秒级别，需要进一步做时间片切分：把单次推理请求切分为多个子任务，每个子任务执行一段固定时间后检查高优先级队列。不过我实测下来，在yolov5s这种单次推理十几毫秒的场景下，非抢占式队列的时延已经足够可控，不必过度设计。

关于双路推理的提交时机，我还做过一个优化：把主路的预推理处理（图像归一化、色彩通道调整）提前到采集线程里完成。这样主路一旦拿到NPU占用权，不需要再做数据预处理，可以节省大约3-5毫秒。

另外，使用RKNN-Toolkit2的API时，建议为两路各建一个独立的RKNN上下文，不要共用同一个上下文。我在一开始共用上下文的时候，遇到了主路图像进入副路推理缓冲区的串数据问题，排查了很久才确认是上下文状态干扰。独立上下文虽然多占一点内存，但双路隔离干净，调试也方便。

3.3 第三层：网络出口QoS与结果推流优先控制

双路视觉系统如果只显示在本机屏幕上，网络层面的QoS可以不配。但如果你的系统像我的应用一样，需要把主路检测结果实时推给上位机，副路画面只做低优先级留存，那么网络出口就必须做严格优先。

Linux流量控制的经典做法是使用classful qdisc，先用prio或htb建立多个优先级class，再通过iptables在mangle表里给不同流打上分类标记，最后由filter把对应标记丢进不同class。严格优先模式下使用htb并配合prio参数是最常见的方案：

# 创建根句柄 tc qdisc add dev eth0 root handle 1: htb default 20 # 创建两个class：高优先级带宽保证80M，低优先级带宽保证20M tc class add dev eth0 parent 1: classid 1:10 htb rate 80mbit prio 0 tc class add dev eth0 parent 1: classid 1:20 htb rate 20mbit prio 1 # 设置filter，匹配DSCP标记为EF(46)的包进入高优先级队列 tc filter add dev eth0 parent 1: protocol ip prio 1 handle 0x2e fw flowid 1:10

注意到这里的关键是htb的prio参数：prio 0表示严格优先执行该class的流量，只有当1:10的流量没有超过rate限制时，低优先级class才会被服务。这就是“严格优先”，它不是简单的带宽切分，而是高优先级class占绝对主导地位。

~/ 再用iptables把主路推流的UDP端口打上fwmark，也就是在mangle表的POSTROUTING链上把目的端口8300的包标记为0x2e，让上边的filter能够识别:

iptables -t mangle -A POSTROUTING -p udp --dport 8300 -j MARK --set-mark 0x2e

这套配置是标准的tc网络QoS方法，在嵌入式Linux上一样生效。我唯一踩过的坑是，RK3588板端网卡的队列把htb的处理结果又分发了一次，导致优先级效果不明显。后来我在板卡的网络驱动里确认了网卡本身只有单队列，才排除了这个隐患。

4. 双路视觉下yolov5s的模型适配与推理链路优化

QoS调度只是把资源的分配规则定下来了，但yolov5s模型本身在RK3588上要怎么适配双路场景，同样有讲究。这里单独拿出来讲，是因为模型部署层面如果做得不好，就算QoS调度再严格，推理时延也降不下来。

4.1 yolov5s轻量化处理与RKNN转换细节

yolov5s这个模型，原始权重是FP32的，直接转成RKNN格式能跑，但推理效率不高。要发挥RK3588 NPU的INT8算力，必须做量化。量化后的模型体积可以从原来的几十MB降到十几MB左右，推理速度明显提升。

用RKNN-Toolkit2转换时，量化数据集的选取非常关键。我建议不要随便抓几张图就量化，而是从实际应用场景里截取覆盖不同光照、不同角度、不同目标的图像，至少准备几百张，跑一次完整的量化校准。理由很朴素：量化校准集决定了激活值浮点范围的统计，范围没取准，低比特量化误差会非常大。

转换过程中还有两个容易被忽略的选项。第一个是目标平台要明确指定为rk3588，让工具链针对RK3588的NPU指令做优化。第二个是开启模型的后训练优化，让工具自动把某些不适合NPU的算子替换成更高效的实现方式。这些选项都是在RKNN-Toolkit2里通过config函数配置的。

from rknn.api import RKNN rknn = RKNN(verbose=True) rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588' ) rknn.load_onnx(model='yolov5s.onnx') rknn.build(do_quantization=True, dataset='dataset.txt') rknn.export_rknn('yolov5s.rknn')

4.2 双路摄像头取流的帧率均衡策略

有了模型，下一件事是让两路摄像头稳定取流。双路视觉的帧率不均衡是很多人的老大难问题，QoS严格优先正好可以通过帧分配策略来解决。

我使用的方案是分别给两路摄像头开独立的v4l2设备节点，主路设置为640x480@60FPS，副路设置为1280x720@30FPS。你可能会奇怪，为什么副路分辨率反而更高？因为副路的应用是留存画面，更看重分辨率，不看重帧率；主路需要高帧率来降低运动模糊，所以分辨率低一点反而合理。这也是QoS分配思想在取流层面上的体现——不是平均分配资源，而是按业务价值分配。

取流线程使用内存映射（mmap）方式读取缓冲区，并设置足够的缓冲区数量。我主路设置了6个缓冲区，副路设置了4个缓冲区。缓冲区太少了容易丢帧，太多了又会增加延迟，这个比例需要根据实际帧率调整。主路因为是关键路径，宁可多占内存也要保证不丢帧。这一步本身没有任何特殊之处，但配合后面的“帧入场排队”，就能让两路取流的优先级固化下来。

4.3 帧同步与推理请求路由的实现

双路视觉很难避免一个问题：主路的推理已经完成，但副路因为处理慢，导致主路的下一次推理被迫等待同步。所以双路不能做全局帧同步，帧同步的边界必须清晰——只有主路内部需要同步（采集帧与推理结果一致），副路完全异步运行。

我在代码里用了一个帧路由表来记录双路帧的状态：主路帧进入高优先级推理队列，副路帧进入低优先级队列。调度线程每轮从高队列采样一帧，立即提交推理；如果高队列为空，才从低队列取帧。这样“高优先级队列”就等同于严格优先里最高优先级的那个band。

为了避免低队列长期饥饿，我还增加了一个防饿死机制：如果低队列的积压帧数超过30帧，调度线程会主动从低队列中抽出一帧处理，即使此时高队列有少量积压。这个机制是对纯严格优先的一种修正，适合生产环境的实际需求。副路虽然相对次要，但也不能让它完全卡死。

5. 常见问题与调试排查实录

把方案完整跑通是一回事，能让它稳定持续运行是另一回事。第四阶段我实际踩的坑比前面三个阶段加起来都多。下面是几条最有价值的排查记录，对你大概率会有帮助。

5.1 QoS配置不生效的典型原因

网络上配了tc严格优先之后，我用iperf3压测主路UDP推流和副路TCP回传，发现两个流的时延几乎没有差别，说明严格优先没起作用。

排查过程是这样的：先用tc -s -d qdisc show dev eth0查看队列统计，发现高优先级class的发送包计数变化很小，而default class的包一直在走。问题就出在iptables的MARK动作没有和fw classifier对上。iptables打上的fwmark是0x2e，但tc filter用的是handle标记，二者必须一一对应。我最初把handle写成了0x2e，其实应该是0x46才对，因为fw classifier匹配的是mark值，不是DSCP值。

修正后效果立刻出来。另一个常见原因是iptables规则加在PREROUTING链上，出方向流量根本不会经过它。一定要加在POSTROUTING，或者OUTPUT链。

5.2 两路推理在NPU上的“绕道”现象

双路推理跑起来之后，我观察到主路帧率偶尔会抖动一下，副路帧率则出现周期性的停滞。抓了线程状态之后发现，主路线程在调用rknn_run的时候，经常被调度器切出去，导致实际推理的总时延被拉长。

这其实是RKNN底层驱动的线程做了一次内部同步，NPU推理结束后需要唤醒等待线程，这个唤醒动作在Android/Linux系统里会走一次内核调度队列，如果CPU负载高，唤醒延迟会变大。即便我主路线程设置了高优先级，等待唤醒期间它也是睡眠状态，无法强制CPU立刻处理唤醒。

最终解决方法是把主路推理线程和采集线程同时绑定到同一对A76核心上，这样唤醒延迟能降低不少。原因是同一个核心上的线程唤醒不涉及跨核缓存同步，内核唤醒路径缩短了。实测下来，P99延迟从原先的50毫秒降到了32毫秒左右。

5.3 线程锁导致的隐式优先级反转

优先级反转这个词很多人只在操作系统课里见过，真到双路视觉系统里就会遇到。我的应用里主路线程和显示线程共用同一个图像缓存队列，主路往队列里写结果，显示逻辑从中取数据画框。正常情况下没问题，但副路后处理偶尔会占用同一个显示队列的锁，主路拿不到锁只能阻塞等待。

严格优先调度遇到这种情况就是典型的优先级反转：高优先级任务等待低优先级任务持有的锁，反而被低优先级阻塞。处理方案有两个，一个是给显示队列加多个缓冲区，尽最大可能避免竞争；另一个是使用可冲入锁配合超时机制，主路等待锁超过2毫秒就直接放弃绘制缓冲，保证推理线程不被卡死。

这种问题在压测时特别容易暴露，单路跑时几乎不可能出现，双路共同访问共享资源后，各种隐式竞争就都冒出来了。

5.4 严格优先影响下的副路饿死处理

前面提到防饿死机制，单独拿出来详细说明一下。最长的一次压测跑了大概40分钟，副路检测框的显示直接冻结，进程还在，但画面完全不更新。我下了一个结论：副路的帧队列满了，而调度线程一直优先处理主路请求，副路推理线程拿不到NPU执行机会。

严格优先的代价就是低优先级在重负载下可能完全得不到服务。我的对策不是把调度策略改回WRR，而是在调度器层面增加一个“低压保护条件”：低队列积压帧数超过阈值时，把副路的推理请求优先级临时提升一级，插入高优先级队列的尾部。这保留严格优先的主干逻辑，同时避免了完全饿死的极端情况。生产系统中这种修正很有价值。

6. 双路QoS严格优先的实测参考数值

理论说得再多，不如看一组实测数据。以下是我在一台香橙派5系列板子上，使用相同模型、相同场景、相同负载条件下采集的指标，对比未开QoS与严格优先开启后的表现。

一眼就能看出，严格优先之后，主路体验获得了质的提升，代价是副路部分帧被主动丢弃。这正是方案二要的效果：资源总量有限，那就把确定性给关键业务。

测试时有一个需要注意的点：端到端延迟要打上时间戳，不要用简单的FPS平均值作为唯一指标。FPS平均值掩盖了抖动，P99才是判断“严格优先是否生效”的核心指标。我每次调整配置，都会同时盯着P99和掉帧率看，前者反映调度质量，后者反映资源分配偏向。

7. 写在最后的阶段总结

方案二的阶段四做完了，但严格优先这件事并没有结束。实际使用中我还有一个感受：QoS配置是一个持续修正的过程，不是把一组命令跑完就能一劳永逸。实时系统的负载特征会随场景变化，比如夜间画面的像素分布不一样，副路的检测任务复杂度也不一样，优先级参数需要动态调整。我的做法是在应用层预留一个配置接口，通过配置文件改线程优先级、CPU亲和性、队列阈值，改完不用重启，热加载即可生效。

最后一个建议：如果你也准备在RK3588上做双路甚至多路视觉，一定要把QoS管理模块从一开始就设计进去，别像我一样跑通了功能才回来补资源调度的课。严格优先的底层逻辑很简单，但真正跑顺，需要你对系统里每一处资源竞争点做到心里有数。把链路图画出来、把优先级标上去、把每个队列的行为测清楚，你也能做出稳定可靠的双路视觉方案。