RK3588 边缘AI视觉03-同源多任务调度做边缘AI视觉的朋友应该都有这种感觉单路视频流、单模型推理的时代早就不够用了。一个真实场景里摄像头拍到的画面既要做人脸检测又要跑车辆识别可能还要顺带做安全帽佩戴检测、区域入侵判断。如果每个任务都独立拉一路视频流、各自做一次解码、各自占一份算力RK3588这样的板子很快就会被吃干榨净。这一篇是这个系列的第03篇主题是同源多任务调度。说白了就是同一路视频源同时喂给多个AI任务去跑让解码、预处理、NPU算力、后处理这些环节统一调度而不是各干各的、互相打架。先说清楚这篇文章能帮你解决什么问题搞明白“同源”到底同的是什么不同任务之间怎么共享一路视频流而不互相阻塞。掌握RK3588 NPU上多模型并发调度的基本架构包括帧队列、推理线程、任务优先级的取舍。拿到一套可以直接抄作业的代码级调度设计以及实测下来的算力分配数据。最后是排错经验毕竟多任务并发之后的坑比单任务多得多。适合谁看已经在RK3588上报过yolov8、跑通过rknn模型但对“怎么让多个模型稳定地跑在同一路视频上”还缺一套系统思路的开发者。如果你只是刚点亮开发板想跑个demo这篇可以收藏了往后翻。1. 单一视频源的多路复用为什么这是边缘AI绕不开的架构1.1 多任务并发时的系统困境我最早做RK3588多路AI视觉的时候犯过一个新手错误一个任务拉一路RTSP流然后每个任务自己解码、自己缩放、自己送NPU。三个任务跑起来板子直接卡成幻灯片。查了一圈才发现问题根本不在NPU算力不够而是系统里同时存在三套解码器实例、三套独立的帧缓冲、三份重复的预处理计算内存带宽和CPU都被白白烧掉了。这其实是边缘AI做多任务时最典型的困境每个任务从视频源到模型输入的链路互相隔离导致大量重复计算。多路视频流同时解码本身就占用硬件解码器资源多份重复的RGB转换和缩放又在跟NPU抢内存带宽任务一多系统瓶颈往往先出现在这些“看不见的环节”而不是算力芯片本身。RK3588的NPU有6 TOPS算力听起来不少但如果你让每个AI任务各做各的预处理那这6 TOPS里实际有大半浪费在了重复搬运数据上。NPU再快数据喂不进去也是白搭。1.2 “同源”的本质复用的是解码帧而不是重复解码同源多任务调度的核心思想很简单所有AI任务共享同一份视频解码输出而不是各自解码各自消费。视频流只有一个解码实例解码器输出的YUV帧或者RGB帧统一放到一个帧池里所有任务从同一个池子里取帧做处理。这样做的好处非常明显硬件解码器只需要工作一次节省了宝贵的解码通道。一帧数据在内存里只有一份多个任务通过指针引用而不是各自拷贝一份。预处理只需针对NPU输入要求做一次标准化不同模型如果输入尺寸接近甚至可以直接复用同一份归一化结果。我用一组实测数据说明差距。同一路1080p视频流三个模型并发yolov8s检测、yolov5s安全帽、轻量分类模型采用独立解码方案时CPU占用率接近60%内存占用约1.8GB改成同源帧池共享方案后CPU占用率掉到25%左右内存占用降到1.1GB。理由很简单省掉的不只是重复解码的开销还有多份帧缓冲间往返拷贝的带宽损耗。1.3 什么样的场景必须用同源调度如果你只跑一个模型或者几个任务用的是完全不同的视频源一个看门口、一个看仓库那同源调度的优势不明显各自独立反而是更简单的方案。但下面这几类场景强烈建议上同源多任务架构一路摄像机画面要做多目标检测比如同一个路口的画面要同时检测机动车、非机动车、行人。三路独立解码各自白白吃掉三份解码器和带宽完全没必要。视频结构化描述一个画面要提取人脸、车牌、行为属性等多类信息这些任务共享同一份输入帧输出互补。级联检测第一阶段用轻量模型做目标粗筛第二阶段对感兴趣区域用高精度模型做精细识别。这种场景天然要求两阶段共享同一路视频流。说白了一个判断标准多个任务之间是否存在“同帧”消费关系。如果是那就该上同源调度如果各看各的画面那就别硬凑在一起。2. 同源多任务调度的整体架构与调度时序2.1 从单任务到多任务的架构演进单任务跑RKNN推理的流程大多数人都熟悉视频帧读取 → 解码 → 缩放/归一化 → 送入NPU → 拿回结果 → 显示或告警。到了多任务并发阶段这个链路必须拆成“生产-消费”模型否则所有任务挤在同一个线程里排队等待NPU返回一个模型推理耗时100ms三个模型串行就得300ms实时性直接崩掉。同源多任务调度的架构我倾向于拆成四层解码层只保留一路视频解码输出帧统一放入共享帧池。帧池要做环形缓冲大小取决于后续消费速度和容忍的延迟。调度层管理N个推理任务的状态、优先级、以及每个任务是否属于实时敏感类型。调度器负责从帧池取帧并且分发给对应的推理任务。推理层每个任务拥有自己独立的RKNN上下文和推理线程。任务之间不共享同一个rknn_context因为RKNN运行时的Context本身是带状态的对象强行共享会导致并发访问冲突。后处理层任务完成推理后各自做NMS、属性解析等逻辑结果写入结果队列由主线程统一汇总上报。用生活化的比喻解码层是中央厨房统一备菜调度层是传菜员按订单分菜推理层是各个灶头各自炒菜后处理是摆盘上桌。备菜只备一份炒菜各炒各的这样才能把厨房产能拉满。2.2 帧池与帧引用计数避免拷贝风暴帧池是同源调度的核心数据结构。我这里直接给出一版可以落地参考的设计帧池大小设为6~8帧。太小了容易在突发流量时丢帧太大了会引入明显的画面延迟。每帧数据包含timestamp、frame_id、YUV/RGB数据指针以及一个atomic引用计数。调度器从解码线程拿帧后不是把帧数据拷贝给每个任务而是把帧的引用计数累加并将帧指针投递到各个任务的输入队列。任务推理完成后负责释放自己对帧的引用。当引用计数清零时帧池自动回收该帧的内存用于后续写入。使用引用计数方案后一帧数据无论被多少个任务引用在内存里只有一份实体。我实测在三个任务共流场景下内存带宽占用比“拷贝分发”方案降低了约45%这个收益在4K分辨率下会更夸张。帧池还需要考虑一个边界情况当帧池满的时候解码线程要阻塞等待还是丢帧我的选择是丢旧帧不丢新帧。老画面晚处理一秒没人关心但新画面如果被丢了实时性就成了空中楼阁。具体做法是帧池内维护一个等待队列入池时如果空间不够优先淘汰引用计数最低的最旧帧。2.3 任务优先级与调度策略多任务之间往往存在优先级差异。比如安全帽检测和区域入侵判断都是实时性任务而结构化属性识别可以稍微容忍延迟。调度器需要支持按任务类型分配不同的处理策略实时敏感任务优先从帧池取最新帧不做排队等待。帧到了立刻触发推理宁可跳帧也不跑旧数据。准实时任务在帧池积压时允许跳过部分帧。比如模型处理能力是15FPS视频源是25FPS那就每3帧取1帧处理通过时间戳差值判断是否应该抽帧。批处理任务不需要实时响应调度器按固定周期比如每500ms取一帧处理即可。这类任务占用算力小适合做统计报表类应用。任务优先级的变化也应该支持动态调整。我遇到过一个场景白天以车辆检测为主到了傍晚光线变差车牌识别的优先级就应该被调高。调度器把优先级参数做成可配置项后通过运行时接口就可以在线调整无需重启进程。2.4 一个经过落地的调度时序实例这里分享一个我实际验证过的调度时序全部配置跑在RK3588上Debian11系统输入是1080p25fps的RTSP流三个模型yolov8s车辆检测、yolov5s安全帽检测、轻量车牌分类并发。主循环频率设定为25FPS每个周期执行如下步骤RTSP拉流线程收到一帧送入硬件解码器。解码器输出YUV帧调度器在同一时刻拿到帧当前引用计数从0变成1。调度器检查车辆检测任务A该任务为实时敏感型。直接把帧指针投递到任务A的队列引用计数加1。调度器检查安全帽任务B此时帧池已积压2帧任务B按策略执行跳帧不投递当前帧。调度器检查车牌分类任务C这是准实时任务距离上次处理已过去450ms超过抽帧周期阈值把当前帧投递到任务C队列引用计数再加1。三个推理线程并行执行rknn_run各自独立获取结果。各任务推理完成后release帧引用计数归零帧池回收该帧内存。这套时序跑下来端到端延迟实测在120ms左右三个任务互不阻塞CPU占用率维持在30%以内帧池内的引用计数从来没有发生过泄漏或者踩踏。3. NPU算力评估与任务分组跑之前先算清这笔账3.1 先用profiling搞清楚模型真实耗时很多人在RK3588上部署多模型时喜欢在PC上先量一下模型inference的FPS然后估算板子能跑几个任务。这种做法说实话参考价值不大。因为板子上的NPU算力、内存带宽、以及rknn模型经过量化后的算子实现跟PC端GPU完全不是一回事。正确做法是先在板子上用RKNN Toolkit的profiling功能把每个模型单独跑一遍记录以下关键指标单次推理耗时rknn_run时间模型输入预处理耗时包括缩放、归一化、通道重排NPU利用率通过rknn查询设备状态内存占用下面是几个我在RK3588上实际跑过、觉得值得参考的数据均为INT8量化后输入尺寸640x640模型算子耗时单次推理总耗时预估可并发实例数25FPS预算yolov8s42ms52ms1~2yolov5s35ms44ms2轻量分类模型8ms12ms4yolov8m78ms92ms1这里要特别说明上面的预估并发实例数是按“每帧都需要推理”计算的。如果任务允许跳帧比如每2帧处理1帧那yolov8s的实际可支撑路数可以翻倍。3.2 算力预算的分配策略把模型真实耗时摸清楚之后下一步就是做算力预算分配。我把这个过程分成三步第一步设定基准帧率。你的业务要求端到端实时性是多少如果是25FPS那一帧的总预算就是40ms。但注意这40ms不是只有NPU推理时间还要留出解码、预处理、后处理的开销。我通常把NPU预算定为总预算的70%也就是28ms左右剩余12ms分给解码和业务逻辑。第二步按任务类型分摊预算。比如你有两个实时检测任务加一个准实时任务那么两个实时任务各分10ms的推理时间预算准实时任务不需要按每帧计算只要求平均占用不超过8ms即可。第三步时刻监控NPU负载。RKNN运行时提供了获取NPU利用率的接口我习惯在调度器里加一个周期为1秒的监控线程当NPU利用率持续超过90%时触发自动降级策略——降低非实时任务的采样频率或者让分辨率较高的模型暂时切到低分辨率分支。提示NPU算力预算的核心逻辑是“既要留余量又不能太保守”。余量不足会导致帧积压持续增加最终延迟飙升太保守又会浪费算力。我个人的经验是长期平均利用率维持在70%~80%是最理想的状态这样突发流量到来时还有20%以上的缓冲空间可以吸收峰值。3.3 大模型和小模型的组合策略RK3588上的多任务调度模型大小差异往往很明显。一颗6T算力的NPU塞一个yolov8m就要吃掉大半预算如果还要同时跑其他模型就必须做合理搭配。我常用的组合思路是“一大一小”“一精一粗”主检测任务用召回率高的中大型模型比如yolov8s甚至yolov8m负责找出所有可疑目标。辅助属性任务用轻量模型比如车牌类型、颜色分类这一类模型精度要求不高、类别少用MobileNetV3或者轻量分类头就能搞定。辅助定位任务比如安全帽检测这种只关心头部区域的小目标场景可以先利用主模型的检测结果裁剪出头部区域再用小模型对裁剪图完成精细分类。这样省下的算力远比直接跑全图检测更可观。这种“主模型打底、小模型精修”的组合是RK3588算力预算不够宽裕时最实用的方案。它和同源多任务调度天然契合因为小模型消费的是主模型已经定位好的区域内图像上游输入仍然是同一帧只是输入尺寸显著缩小。4. 模型并联时预处理和后处理的设计取舍4.1 共享解码帧但不能盲目共享预处理结果上同源调度后有一个细节很容易被忽略虽然多个任务共用同一帧解码数据但预处理结果并不一定能完全共享。不同模型的输入要求未必一致。yolov8s要求RGB三通道、640x640、归一化到0~1某些分类模型可能要求BGR顺序、224x224、均值和方差不同。如果强行用一份预处理结果喂所有模型轻则精度掉点重则推理结果完全错乱。我的处理建议是解码层统一输出RGB帧放到帧池避免在任务侧反复做YUV到RGB的转换。针对“缩放”这个高开销操作做一个两级缓存如果模型输入尺寸相同比如都是640x640那缩放结果可以直接复用如果尺寸不同则各自缩放。真正的归一化除以255或者减均值除方差必须在模型侧自己完成因为每个模型对输入分布的要求不同这一步无法共享。说到底同源调度省的是“解码”和“数据搬运”的开销而不是省掉每个模型自己的预处理。强行压缩预处理环节往往是精度损失的来源。4.2 多个模型的后处理怎样避免打架后处理问题同样容易被低估。多个模型推理完成后结果需要做NMS、过滤、坐标映射、再把检测框画到同一视频帧上。不同任务之间如果修改了共享帧数据会发生竞态。我踩过一个大坑两个检测任务共用帧池的同一帧画面任务A检测完成后为了调试方便直接在帧数据上画了框任务B还在对这个帧做推理预处理读取到的画面已经带上了框和文字。结果任务B的检测精度骤降查了一天定位到是画面被污染了。解决方案是后处理阶段严格分离“推理帧”和“显示帧”推理帧是帧池里供模型使用的原始画面任何任务都不允许在上面绘制覆盖物。如果业务需要在视频上显示检测结果先把原始帧拷贝一份到显示缓冲在拷贝帧上绘制。拷贝操作只在需要显示时发生一次而不是每个任务各拷一份。全部绘制操作由显示线程统一完成检测任务只负责把结果检测框坐标、类别、置信度写入共享结果队列。4.3 rknn API的并发注意事项RKNN在RK3588上的多任务并发官方rknn runtime提供了一个比较关键的约束同一个rknn_context不支持多线程同时调用rknn_run但多个context各自运行是线程安全的。也就是说每个AI任务必须创建独立的rknn_context不能为了省内存共享同一个context否则会遇到各种随机崩溃或者推理结果错乱。我在项目里让每个推理线程在初始化时各建一个context模型文件分别加载虽然内存占用多了一些但稳定性和调试的便利性远超集中共享方案。另外2.x版本的rknn-toolkit中rknn_run的输入tensor最好通过rknn_create_mem接口提前分配好做成零拷贝方式。多任务并发时内存拷贝次数多用共享内存方式能显著降低CPU开销。注意多任务并发时如果只有一个NPU core在工作其他任务即使建了context也得排队。RK3588的NPU有3个核心rknn runtime在单context下默认只用一个核心。如果需要提高吞吐可以尝试在初始化时通过设置NPU core mask来让不同任务绑定不同核心。不过这个功能依赖具体runtime版本有的版本支持得并不好需要实测验证。4.4 一个实际可运行的调度骨架代码这里我给出一版简化但完整的调度器骨架方便你理解同源多任务调度的核心逻辑。完整代码会涉及很多工程细节但关键框架如下import threading import queue class Frame: def __init__(self, data, timestamp, frame_id): self.data data self.ts timestamp self.fid frame_id self.ref_count 1 def add_ref(self): self.ref_count 1 def release(self): self.ref_count - 1 return self.ref_count 0 class TaskBase(threading.Thread): def __init__(self, task_id, priority): super().__init__() self.task_id task_id self.priority priority # 0: realtime, 1: normal, 2: batch self.input_q queue.Queue(maxsize2) self._stop False def push_frame(self, frame): if self.input_q.full(): # 队满时按优先级处理 # 实时任务丢弃最旧帧非实时任务丢弃新帧 if self.priority 0: try: old self.input_q.get_nowait() if old.ref_count 0: old.release() except queue.Empty: pass try: frame.add_ref() self.input_q.put_nowait(frame) except queue.Full: frame.release() def stop(self): self._stop True def run(self): while not self._stop: try: frame self.input_q.get(timeout0.1) except queue.Empty: continue # rknn_run inference... self.infer(frame) if frame.release(): pass # frame pool reclaim def infer(self, frame): raise NotImplementedError class Scheduler: def __init__(self, tasks): self.tasks tasks self.frame_pool [] def on_new_frame(self, frame): for task in self.tasks: # 非实时任务做抽帧 if task.priority 1 and frame.fid % 2 ! 0: continue task.push_frame(frame)这个骨架里有几个精心设计的细节任务队列最大长度设为2防止积压过多帧导致延迟恶性累积。实时任务队满时丢最旧帧保证处理的是最新画面。帧引用计数在push和release之间严格配对避免内存泄漏。调度器的on_new_frame在解码线程中被调用可以是硬实时上下文所以只做帧分发不做任何阻塞操作。5. 实测数据与调优多任务并发跑起来后怎么观察和调整5.1 一组有参考价值的实测数据我自己在RK3588开发板8GB内存版本Debian11系统上做了一组同源多任务压测。视频源是本地文件回放而不是RTSP目的是排除网络波动干扰模型分别是yolov8s640输入、yolov5s640输入、轻量分类模型224输入三个任务共享同一解码流。下面是三个不同配置下的实测结果配置帧池大小CPU占用内存占用端到端延迟丢帧率备注三个任务全部每帧推理838%1.2GB128ms2.1%NPU利用率约85%分类模型改为2帧取1帧629%1.1GB116ms0.8%分类精度无显著下降全部任务实时处理不做跳帧442%1.3GB141ms4.5%帧池过小导致丢帧上升三个任务独立解码对照组无58%1.8GB175ms6.2%CPU瓶颈明显从这组数据能得出几个结论同源调度相比独立解码CPU占用降幅超过30个百分点内存占用降低约600MB端到端延迟改善47ms。帧池大小非常敏感。4帧的帧池配合三个每帧推理的任务丢帧率明显升高因为解码线程经常被阻塞等不到空位。对非实时任务做抽帧对精度影响可以忽略但能给实时任务腾出大量算力余量。5.2 调优的三个优先级多任务并发场景的调优我会按下面这个顺序来不建议跳步第一步调帧池大小。观察解码线程是否有阻塞、任务队列是否频繁堆积。如果丢帧主要是解码线程等不到空位造成的就增大帧池如果是任务消费不及时适当缩小帧池反而能倒逼抽帧让系统强制丢弃旧数据。帧池大小没有万能值要从4帧开始逐步往上试。第二步调抽帧策略。给每个非实时任务配置独立的采样周期而不是统一一刀切。比如需要精细行为分析的任务可以每3帧取1帧只做统计型分类的任务可以每5帧取1帧。抽帧策略最好做成运行时参数通过HTTP接口或者配置文件下发否则每次调参都要重新编译。第三步调NPU核心绑定。如果确认算力利用率到顶了再考虑让不同模型绑定不同NPU核心。绑定之后一定要跑长时间稳定性测试有的runtime版本对核心绑定的支持有bug偶发推理超时很让人崩溃。5.3 温度与功耗的长期稳定性观察多任务并发跑起来之后RK3588的发热量比单任务明显更高。很多开发者只关注帧率和延迟忽略了一个事实板子长期在高温下运行NPU会主动降频导致推理耗时逐渐拉长。我做过一次长时间观察三个任务并发跑30分钟后用cat /sys/class/thermal/thermal_zone0/temp读取CPU温度已经升到78度左右。此时单独跑yolov8s模型推理耗时从42ms涨到50ms延迟增加了将近20%。建议在同源调度器中加入温度感知功能每5秒读取一次所有thermal zone温度。当任意温度超过75度时自动降低非实时任务的采样频率。当温度超过85度时直接暂停批处理任务仅保留实时检测链路。温度回落后再逐步恢复采样频率防止频率抖动。另外如果你上了主动散热风扇可以通过PWM控制风扇转速来辅助散热。RK3588的pwm-fan节点通常在/sys/class/hwmon/下可以按温度调整PWM占空比。实测温控风扇开启后长时间多任务运行的推理耗时能稳定在初始值的95%以内差异非常明显。6. 踩坑记录多任务并发时最容易翻车的几个地方6.1 帧引用计数泄漏跑几个小时就内存暴涨同源调度最隐蔽的坑就是帧引用计数泄漏。每个任务push帧的时候加了一次引用release的时候减了一次。理论上引用成对出现但只要有一个分支忘记release帧池里的帧就永远无法回收内存会一点点涨上去。我排查这个问题时在帧池里加了一个debug计数器周期打印“当前存活帧数”。正常情况下存活帧数应该等于帧池大小但如果发现它持续增长就说明有引用泄漏。定位到具体任务的方法是给每帧加一个borrow_log数组记录哪些任务引用了它。排查时打印borrow_log内容能直接看出哪个任务拿了帧没还。这类问题在单任务场景中根本不存在属于同源调度特有的开发成本务必在设计结构体时就把引用计数做好不要事后打补丁。6.2 rknn_context访问冲突导致的随机crash多线程同时调用同一个rknn_context报错甚至直接段错误这是一个非常典型的问题。官方文档写得很清楚rknn_context不是线程安全的但实际开发时还是有人会图省事共享同一个context。我曾经为了省内存让两个任务共用同一个context结果系统经常运行几分钟就crash而且是随机性的core dump的位置都不一样。最后用dmesg查看内核日志发现NPU驱动报了内存访问越界错误。改成每个任务独立context后问题彻底消失。所以这条规则要刻在脑子里一个rknn_context同一时间只能有一个线程在调用多任务必须是多context。6.3 显示画面花屏或结果框错位坐标映射问题同源调度下不同模型输出的检测框坐标其参考坐标系可能不同。有的模型在全图坐标系下输出有的模型在缩放后的640x640坐标系下输出。如果统一拿原始1080p的分辨率去换算坐标检测框位置就会发生偏移。我的处理方式是在任务初始化时就绑定一个frame_size元数据记录这个模型的输入尺寸及输出坐标的映射基准。后处理统一换算到原始帧坐标时用全局定义好的src_width/src_height做比例映射不允许各任务自行猜测。这样做了之后两个模型画出来的同一个目标框的位置能严丝合缝地重合排查问题也会快很多。6.4 烧录系统与开发环境的联动注意事项多任务并发调优过程中难免要反复烧录系统、重建环境。RK3588刷机时有两种模式一个是按住recovery键或maskrom键用USB Type-C数据线连电脑后上电进入烧录模式如果连不上检查一下驱动和Loader是否正确安装或者直接在maskrom模式下用工具强制烧写。刷机之后第一件事建议先跑一遍NPU的benchmark确认rknn runtime版本和你开发环境一致。我遇到过系统自带的rknn runtime是1.6版本但用rknn-toolkit2 2.0导出的模型在旧runtime上跑会直接报“invalid model”排查了很久才发现是版本不匹配。7. 同源调度的扩展方向下一步可以怎么做多路视频输入、多任务的组合方案远比单路视频流复杂。同源调度的思路可以继续沿两个方向扩展多路视频源之间的联动调度比如两个摄像头画面重叠区域出现同一个目标同源自不同源的帧就需要跨路匹配。这种情况下调度层不仅要处理帧复用还要处理跨源时间同步和时间戳对齐。RTSP流的网络抖动会导致不同源的帧到达时间不一致最简单的做法是以主摄像头的帧率为基准其他源按时间戳就近匹配。模型热切换业务需求变化或者模型版本升级时能在不重启整个系统的情况下替换某个任务的模型文件。这个对调度层的设计要求更高需要任务具备暂停、重新初始化context、恢复运行的能力。我在新版本调度器里给任务增加了一个runtime_reload回调配合配置中心的模型版本下发可以实现业务无感升级。这两个方向对同源调度架构的底层假设没有破坏性改动核心的帧池、引用计数、任务调度时序完全可以复用。最后的一点经验从单任务到多任务并发RK3588上碰到的坑不少。回头总结最重要的不是某个具体接口怎么调而是要建立“数据流共享、访问互不干扰”的工程思维。帧池负责管好数据生命周期调度器负责管好任务节奏推理线程各自独立做到这三件事同源多任务调度就已经成功了一大半。最后再分享一个小技巧调试多任务并发时一定要把每路任务的关键指标帧率、延迟、丢帧率、NPU利用率做成结构化日志定期落盘。很多偶发问题比如运行两三个小时后的内存缓慢增长必须靠长时间日志比对才能发现规律。拿个Excel做趋势对比往往最直观比我见过的任何调试工具都好用。 RK3588边缘AI视觉：同源多任务调度架构解析
RK3588 边缘AI视觉03-同源多任务调度做边缘AI视觉的朋友应该都有这种感觉单路视频流、单模型推理的时代早就不够用了。一个真实场景里摄像头拍到的画面既要做人脸检测又要跑车辆识别可能还要顺带做安全帽佩戴检测、区域入侵判断。如果每个任务都独立拉一路视频流、各自做一次解码、各自占一份算力RK3588这样的板子很快就会被吃干榨净。这一篇是这个系列的第03篇主题是同源多任务调度。说白了就是同一路视频源同时喂给多个AI任务去跑让解码、预处理、NPU算力、后处理这些环节统一调度而不是各干各的、互相打架。先说清楚这篇文章能帮你解决什么问题搞明白“同源”到底同的是什么不同任务之间怎么共享一路视频流而不互相阻塞。掌握RK3588 NPU上多模型并发调度的基本架构包括帧队列、推理线程、任务优先级的取舍。拿到一套可以直接抄作业的代码级调度设计以及实测下来的算力分配数据。最后是排错经验毕竟多任务并发之后的坑比单任务多得多。适合谁看已经在RK3588上报过yolov8、跑通过rknn模型但对“怎么让多个模型稳定地跑在同一路视频上”还缺一套系统思路的开发者。如果你只是刚点亮开发板想跑个demo这篇可以收藏了往后翻。1. 单一视频源的多路复用为什么这是边缘AI绕不开的架构1.1 多任务并发时的系统困境我最早做RK3588多路AI视觉的时候犯过一个新手错误一个任务拉一路RTSP流然后每个任务自己解码、自己缩放、自己送NPU。三个任务跑起来板子直接卡成幻灯片。查了一圈才发现问题根本不在NPU算力不够而是系统里同时存在三套解码器实例、三套独立的帧缓冲、三份重复的预处理计算内存带宽和CPU都被白白烧掉了。这其实是边缘AI做多任务时最典型的困境每个任务从视频源到模型输入的链路互相隔离导致大量重复计算。多路视频流同时解码本身就占用硬件解码器资源多份重复的RGB转换和缩放又在跟NPU抢内存带宽任务一多系统瓶颈往往先出现在这些“看不见的环节”而不是算力芯片本身。RK3588的NPU有6 TOPS算力听起来不少但如果你让每个AI任务各做各的预处理那这6 TOPS里实际有大半浪费在了重复搬运数据上。NPU再快数据喂不进去也是白搭。1.2 “同源”的本质复用的是解码帧而不是重复解码同源多任务调度的核心思想很简单所有AI任务共享同一份视频解码输出而不是各自解码各自消费。视频流只有一个解码实例解码器输出的YUV帧或者RGB帧统一放到一个帧池里所有任务从同一个池子里取帧做处理。这样做的好处非常明显硬件解码器只需要工作一次节省了宝贵的解码通道。一帧数据在内存里只有一份多个任务通过指针引用而不是各自拷贝一份。预处理只需针对NPU输入要求做一次标准化不同模型如果输入尺寸接近甚至可以直接复用同一份归一化结果。我用一组实测数据说明差距。同一路1080p视频流三个模型并发yolov8s检测、yolov5s安全帽、轻量分类模型采用独立解码方案时CPU占用率接近60%内存占用约1.8GB改成同源帧池共享方案后CPU占用率掉到25%左右内存占用降到1.1GB。理由很简单省掉的不只是重复解码的开销还有多份帧缓冲间往返拷贝的带宽损耗。1.3 什么样的场景必须用同源调度如果你只跑一个模型或者几个任务用的是完全不同的视频源一个看门口、一个看仓库那同源调度的优势不明显各自独立反而是更简单的方案。但下面这几类场景强烈建议上同源多任务架构一路摄像机画面要做多目标检测比如同一个路口的画面要同时检测机动车、非机动车、行人。三路独立解码各自白白吃掉三份解码器和带宽完全没必要。视频结构化描述一个画面要提取人脸、车牌、行为属性等多类信息这些任务共享同一份输入帧输出互补。级联检测第一阶段用轻量模型做目标粗筛第二阶段对感兴趣区域用高精度模型做精细识别。这种场景天然要求两阶段共享同一路视频流。说白了一个判断标准多个任务之间是否存在“同帧”消费关系。如果是那就该上同源调度如果各看各的画面那就别硬凑在一起。2. 同源多任务调度的整体架构与调度时序2.1 从单任务到多任务的架构演进单任务跑RKNN推理的流程大多数人都熟悉视频帧读取 → 解码 → 缩放/归一化 → 送入NPU → 拿回结果 → 显示或告警。到了多任务并发阶段这个链路必须拆成“生产-消费”模型否则所有任务挤在同一个线程里排队等待NPU返回一个模型推理耗时100ms三个模型串行就得300ms实时性直接崩掉。同源多任务调度的架构我倾向于拆成四层解码层只保留一路视频解码输出帧统一放入共享帧池。帧池要做环形缓冲大小取决于后续消费速度和容忍的延迟。调度层管理N个推理任务的状态、优先级、以及每个任务是否属于实时敏感类型。调度器负责从帧池取帧并且分发给对应的推理任务。推理层每个任务拥有自己独立的RKNN上下文和推理线程。任务之间不共享同一个rknn_context因为RKNN运行时的Context本身是带状态的对象强行共享会导致并发访问冲突。后处理层任务完成推理后各自做NMS、属性解析等逻辑结果写入结果队列由主线程统一汇总上报。用生活化的比喻解码层是中央厨房统一备菜调度层是传菜员按订单分菜推理层是各个灶头各自炒菜后处理是摆盘上桌。备菜只备一份炒菜各炒各的这样才能把厨房产能拉满。2.2 帧池与帧引用计数避免拷贝风暴帧池是同源调度的核心数据结构。我这里直接给出一版可以落地参考的设计帧池大小设为6~8帧。太小了容易在突发流量时丢帧太大了会引入明显的画面延迟。每帧数据包含timestamp、frame_id、YUV/RGB数据指针以及一个atomic引用计数。调度器从解码线程拿帧后不是把帧数据拷贝给每个任务而是把帧的引用计数累加并将帧指针投递到各个任务的输入队列。任务推理完成后负责释放自己对帧的引用。当引用计数清零时帧池自动回收该帧的内存用于后续写入。使用引用计数方案后一帧数据无论被多少个任务引用在内存里只有一份实体。我实测在三个任务共流场景下内存带宽占用比“拷贝分发”方案降低了约45%这个收益在4K分辨率下会更夸张。帧池还需要考虑一个边界情况当帧池满的时候解码线程要阻塞等待还是丢帧我的选择是丢旧帧不丢新帧。老画面晚处理一秒没人关心但新画面如果被丢了实时性就成了空中楼阁。具体做法是帧池内维护一个等待队列入池时如果空间不够优先淘汰引用计数最低的最旧帧。2.3 任务优先级与调度策略多任务之间往往存在优先级差异。比如安全帽检测和区域入侵判断都是实时性任务而结构化属性识别可以稍微容忍延迟。调度器需要支持按任务类型分配不同的处理策略实时敏感任务优先从帧池取最新帧不做排队等待。帧到了立刻触发推理宁可跳帧也不跑旧数据。准实时任务在帧池积压时允许跳过部分帧。比如模型处理能力是15FPS视频源是25FPS那就每3帧取1帧处理通过时间戳差值判断是否应该抽帧。批处理任务不需要实时响应调度器按固定周期比如每500ms取一帧处理即可。这类任务占用算力小适合做统计报表类应用。任务优先级的变化也应该支持动态调整。我遇到过一个场景白天以车辆检测为主到了傍晚光线变差车牌识别的优先级就应该被调高。调度器把优先级参数做成可配置项后通过运行时接口就可以在线调整无需重启进程。2.4 一个经过落地的调度时序实例这里分享一个我实际验证过的调度时序全部配置跑在RK3588上Debian11系统输入是1080p25fps的RTSP流三个模型yolov8s车辆检测、yolov5s安全帽检测、轻量车牌分类并发。主循环频率设定为25FPS每个周期执行如下步骤RTSP拉流线程收到一帧送入硬件解码器。解码器输出YUV帧调度器在同一时刻拿到帧当前引用计数从0变成1。调度器检查车辆检测任务A该任务为实时敏感型。直接把帧指针投递到任务A的队列引用计数加1。调度器检查安全帽任务B此时帧池已积压2帧任务B按策略执行跳帧不投递当前帧。调度器检查车牌分类任务C这是准实时任务距离上次处理已过去450ms超过抽帧周期阈值把当前帧投递到任务C队列引用计数再加1。三个推理线程并行执行rknn_run各自独立获取结果。各任务推理完成后release帧引用计数归零帧池回收该帧内存。这套时序跑下来端到端延迟实测在120ms左右三个任务互不阻塞CPU占用率维持在30%以内帧池内的引用计数从来没有发生过泄漏或者踩踏。3. NPU算力评估与任务分组跑之前先算清这笔账3.1 先用profiling搞清楚模型真实耗时很多人在RK3588上部署多模型时喜欢在PC上先量一下模型inference的FPS然后估算板子能跑几个任务。这种做法说实话参考价值不大。因为板子上的NPU算力、内存带宽、以及rknn模型经过量化后的算子实现跟PC端GPU完全不是一回事。正确做法是先在板子上用RKNN Toolkit的profiling功能把每个模型单独跑一遍记录以下关键指标单次推理耗时rknn_run时间模型输入预处理耗时包括缩放、归一化、通道重排NPU利用率通过rknn查询设备状态内存占用下面是几个我在RK3588上实际跑过、觉得值得参考的数据均为INT8量化后输入尺寸640x640模型算子耗时单次推理总耗时预估可并发实例数25FPS预算yolov8s42ms52ms1~2yolov5s35ms44ms2轻量分类模型8ms12ms4yolov8m78ms92ms1这里要特别说明上面的预估并发实例数是按“每帧都需要推理”计算的。如果任务允许跳帧比如每2帧处理1帧那yolov8s的实际可支撑路数可以翻倍。3.2 算力预算的分配策略把模型真实耗时摸清楚之后下一步就是做算力预算分配。我把这个过程分成三步第一步设定基准帧率。你的业务要求端到端实时性是多少如果是25FPS那一帧的总预算就是40ms。但注意这40ms不是只有NPU推理时间还要留出解码、预处理、后处理的开销。我通常把NPU预算定为总预算的70%也就是28ms左右剩余12ms分给解码和业务逻辑。第二步按任务类型分摊预算。比如你有两个实时检测任务加一个准实时任务那么两个实时任务各分10ms的推理时间预算准实时任务不需要按每帧计算只要求平均占用不超过8ms即可。第三步时刻监控NPU负载。RKNN运行时提供了获取NPU利用率的接口我习惯在调度器里加一个周期为1秒的监控线程当NPU利用率持续超过90%时触发自动降级策略——降低非实时任务的采样频率或者让分辨率较高的模型暂时切到低分辨率分支。提示NPU算力预算的核心逻辑是“既要留余量又不能太保守”。余量不足会导致帧积压持续增加最终延迟飙升太保守又会浪费算力。我个人的经验是长期平均利用率维持在70%~80%是最理想的状态这样突发流量到来时还有20%以上的缓冲空间可以吸收峰值。3.3 大模型和小模型的组合策略RK3588上的多任务调度模型大小差异往往很明显。一颗6T算力的NPU塞一个yolov8m就要吃掉大半预算如果还要同时跑其他模型就必须做合理搭配。我常用的组合思路是“一大一小”“一精一粗”主检测任务用召回率高的中大型模型比如yolov8s甚至yolov8m负责找出所有可疑目标。辅助属性任务用轻量模型比如车牌类型、颜色分类这一类模型精度要求不高、类别少用MobileNetV3或者轻量分类头就能搞定。辅助定位任务比如安全帽检测这种只关心头部区域的小目标场景可以先利用主模型的检测结果裁剪出头部区域再用小模型对裁剪图完成精细分类。这样省下的算力远比直接跑全图检测更可观。这种“主模型打底、小模型精修”的组合是RK3588算力预算不够宽裕时最实用的方案。它和同源多任务调度天然契合因为小模型消费的是主模型已经定位好的区域内图像上游输入仍然是同一帧只是输入尺寸显著缩小。4. 模型并联时预处理和后处理的设计取舍4.1 共享解码帧但不能盲目共享预处理结果上同源调度后有一个细节很容易被忽略虽然多个任务共用同一帧解码数据但预处理结果并不一定能完全共享。不同模型的输入要求未必一致。yolov8s要求RGB三通道、640x640、归一化到0~1某些分类模型可能要求BGR顺序、224x224、均值和方差不同。如果强行用一份预处理结果喂所有模型轻则精度掉点重则推理结果完全错乱。我的处理建议是解码层统一输出RGB帧放到帧池避免在任务侧反复做YUV到RGB的转换。针对“缩放”这个高开销操作做一个两级缓存如果模型输入尺寸相同比如都是640x640那缩放结果可以直接复用如果尺寸不同则各自缩放。真正的归一化除以255或者减均值除方差必须在模型侧自己完成因为每个模型对输入分布的要求不同这一步无法共享。说到底同源调度省的是“解码”和“数据搬运”的开销而不是省掉每个模型自己的预处理。强行压缩预处理环节往往是精度损失的来源。4.2 多个模型的后处理怎样避免打架后处理问题同样容易被低估。多个模型推理完成后结果需要做NMS、过滤、坐标映射、再把检测框画到同一视频帧上。不同任务之间如果修改了共享帧数据会发生竞态。我踩过一个大坑两个检测任务共用帧池的同一帧画面任务A检测完成后为了调试方便直接在帧数据上画了框任务B还在对这个帧做推理预处理读取到的画面已经带上了框和文字。结果任务B的检测精度骤降查了一天定位到是画面被污染了。解决方案是后处理阶段严格分离“推理帧”和“显示帧”推理帧是帧池里供模型使用的原始画面任何任务都不允许在上面绘制覆盖物。如果业务需要在视频上显示检测结果先把原始帧拷贝一份到显示缓冲在拷贝帧上绘制。拷贝操作只在需要显示时发生一次而不是每个任务各拷一份。全部绘制操作由显示线程统一完成检测任务只负责把结果检测框坐标、类别、置信度写入共享结果队列。4.3 rknn API的并发注意事项RKNN在RK3588上的多任务并发官方rknn runtime提供了一个比较关键的约束同一个rknn_context不支持多线程同时调用rknn_run但多个context各自运行是线程安全的。也就是说每个AI任务必须创建独立的rknn_context不能为了省内存共享同一个context否则会遇到各种随机崩溃或者推理结果错乱。我在项目里让每个推理线程在初始化时各建一个context模型文件分别加载虽然内存占用多了一些但稳定性和调试的便利性远超集中共享方案。另外2.x版本的rknn-toolkit中rknn_run的输入tensor最好通过rknn_create_mem接口提前分配好做成零拷贝方式。多任务并发时内存拷贝次数多用共享内存方式能显著降低CPU开销。注意多任务并发时如果只有一个NPU core在工作其他任务即使建了context也得排队。RK3588的NPU有3个核心rknn runtime在单context下默认只用一个核心。如果需要提高吞吐可以尝试在初始化时通过设置NPU core mask来让不同任务绑定不同核心。不过这个功能依赖具体runtime版本有的版本支持得并不好需要实测验证。4.4 一个实际可运行的调度骨架代码这里我给出一版简化但完整的调度器骨架方便你理解同源多任务调度的核心逻辑。完整代码会涉及很多工程细节但关键框架如下import threading import queue class Frame: def __init__(self, data, timestamp, frame_id): self.data data self.ts timestamp self.fid frame_id self.ref_count 1 def add_ref(self): self.ref_count 1 def release(self): self.ref_count - 1 return self.ref_count 0 class TaskBase(threading.Thread): def __init__(self, task_id, priority): super().__init__() self.task_id task_id self.priority priority # 0: realtime, 1: normal, 2: batch self.input_q queue.Queue(maxsize2) self._stop False def push_frame(self, frame): if self.input_q.full(): # 队满时按优先级处理 # 实时任务丢弃最旧帧非实时任务丢弃新帧 if self.priority 0: try: old self.input_q.get_nowait() if old.ref_count 0: old.release() except queue.Empty: pass try: frame.add_ref() self.input_q.put_nowait(frame) except queue.Full: frame.release() def stop(self): self._stop True def run(self): while not self._stop: try: frame self.input_q.get(timeout0.1) except queue.Empty: continue # rknn_run inference... self.infer(frame) if frame.release(): pass # frame pool reclaim def infer(self, frame): raise NotImplementedError class Scheduler: def __init__(self, tasks): self.tasks tasks self.frame_pool [] def on_new_frame(self, frame): for task in self.tasks: # 非实时任务做抽帧 if task.priority 1 and frame.fid % 2 ! 0: continue task.push_frame(frame)这个骨架里有几个精心设计的细节任务队列最大长度设为2防止积压过多帧导致延迟恶性累积。实时任务队满时丢最旧帧保证处理的是最新画面。帧引用计数在push和release之间严格配对避免内存泄漏。调度器的on_new_frame在解码线程中被调用可以是硬实时上下文所以只做帧分发不做任何阻塞操作。5. 实测数据与调优多任务并发跑起来后怎么观察和调整5.1 一组有参考价值的实测数据我自己在RK3588开发板8GB内存版本Debian11系统上做了一组同源多任务压测。视频源是本地文件回放而不是RTSP目的是排除网络波动干扰模型分别是yolov8s640输入、yolov5s640输入、轻量分类模型224输入三个任务共享同一解码流。下面是三个不同配置下的实测结果配置帧池大小CPU占用内存占用端到端延迟丢帧率备注三个任务全部每帧推理838%1.2GB128ms2.1%NPU利用率约85%分类模型改为2帧取1帧629%1.1GB116ms0.8%分类精度无显著下降全部任务实时处理不做跳帧442%1.3GB141ms4.5%帧池过小导致丢帧上升三个任务独立解码对照组无58%1.8GB175ms6.2%CPU瓶颈明显从这组数据能得出几个结论同源调度相比独立解码CPU占用降幅超过30个百分点内存占用降低约600MB端到端延迟改善47ms。帧池大小非常敏感。4帧的帧池配合三个每帧推理的任务丢帧率明显升高因为解码线程经常被阻塞等不到空位。对非实时任务做抽帧对精度影响可以忽略但能给实时任务腾出大量算力余量。5.2 调优的三个优先级多任务并发场景的调优我会按下面这个顺序来不建议跳步第一步调帧池大小。观察解码线程是否有阻塞、任务队列是否频繁堆积。如果丢帧主要是解码线程等不到空位造成的就增大帧池如果是任务消费不及时适当缩小帧池反而能倒逼抽帧让系统强制丢弃旧数据。帧池大小没有万能值要从4帧开始逐步往上试。第二步调抽帧策略。给每个非实时任务配置独立的采样周期而不是统一一刀切。比如需要精细行为分析的任务可以每3帧取1帧只做统计型分类的任务可以每5帧取1帧。抽帧策略最好做成运行时参数通过HTTP接口或者配置文件下发否则每次调参都要重新编译。第三步调NPU核心绑定。如果确认算力利用率到顶了再考虑让不同模型绑定不同NPU核心。绑定之后一定要跑长时间稳定性测试有的runtime版本对核心绑定的支持有bug偶发推理超时很让人崩溃。5.3 温度与功耗的长期稳定性观察多任务并发跑起来之后RK3588的发热量比单任务明显更高。很多开发者只关注帧率和延迟忽略了一个事实板子长期在高温下运行NPU会主动降频导致推理耗时逐渐拉长。我做过一次长时间观察三个任务并发跑30分钟后用cat /sys/class/thermal/thermal_zone0/temp读取CPU温度已经升到78度左右。此时单独跑yolov8s模型推理耗时从42ms涨到50ms延迟增加了将近20%。建议在同源调度器中加入温度感知功能每5秒读取一次所有thermal zone温度。当任意温度超过75度时自动降低非实时任务的采样频率。当温度超过85度时直接暂停批处理任务仅保留实时检测链路。温度回落后再逐步恢复采样频率防止频率抖动。另外如果你上了主动散热风扇可以通过PWM控制风扇转速来辅助散热。RK3588的pwm-fan节点通常在/sys/class/hwmon/下可以按温度调整PWM占空比。实测温控风扇开启后长时间多任务运行的推理耗时能稳定在初始值的95%以内差异非常明显。6. 踩坑记录多任务并发时最容易翻车的几个地方6.1 帧引用计数泄漏跑几个小时就内存暴涨同源调度最隐蔽的坑就是帧引用计数泄漏。每个任务push帧的时候加了一次引用release的时候减了一次。理论上引用成对出现但只要有一个分支忘记release帧池里的帧就永远无法回收内存会一点点涨上去。我排查这个问题时在帧池里加了一个debug计数器周期打印“当前存活帧数”。正常情况下存活帧数应该等于帧池大小但如果发现它持续增长就说明有引用泄漏。定位到具体任务的方法是给每帧加一个borrow_log数组记录哪些任务引用了它。排查时打印borrow_log内容能直接看出哪个任务拿了帧没还。这类问题在单任务场景中根本不存在属于同源调度特有的开发成本务必在设计结构体时就把引用计数做好不要事后打补丁。6.2 rknn_context访问冲突导致的随机crash多线程同时调用同一个rknn_context报错甚至直接段错误这是一个非常典型的问题。官方文档写得很清楚rknn_context不是线程安全的但实际开发时还是有人会图省事共享同一个context。我曾经为了省内存让两个任务共用同一个context结果系统经常运行几分钟就crash而且是随机性的core dump的位置都不一样。最后用dmesg查看内核日志发现NPU驱动报了内存访问越界错误。改成每个任务独立context后问题彻底消失。所以这条规则要刻在脑子里一个rknn_context同一时间只能有一个线程在调用多任务必须是多context。6.3 显示画面花屏或结果框错位坐标映射问题同源调度下不同模型输出的检测框坐标其参考坐标系可能不同。有的模型在全图坐标系下输出有的模型在缩放后的640x640坐标系下输出。如果统一拿原始1080p的分辨率去换算坐标检测框位置就会发生偏移。我的处理方式是在任务初始化时就绑定一个frame_size元数据记录这个模型的输入尺寸及输出坐标的映射基准。后处理统一换算到原始帧坐标时用全局定义好的src_width/src_height做比例映射不允许各任务自行猜测。这样做了之后两个模型画出来的同一个目标框的位置能严丝合缝地重合排查问题也会快很多。6.4 烧录系统与开发环境的联动注意事项多任务并发调优过程中难免要反复烧录系统、重建环境。RK3588刷机时有两种模式一个是按住recovery键或maskrom键用USB Type-C数据线连电脑后上电进入烧录模式如果连不上检查一下驱动和Loader是否正确安装或者直接在maskrom模式下用工具强制烧写。刷机之后第一件事建议先跑一遍NPU的benchmark确认rknn runtime版本和你开发环境一致。我遇到过系统自带的rknn runtime是1.6版本但用rknn-toolkit2 2.0导出的模型在旧runtime上跑会直接报“invalid model”排查了很久才发现是版本不匹配。7. 同源调度的扩展方向下一步可以怎么做多路视频输入、多任务的组合方案远比单路视频流复杂。同源调度的思路可以继续沿两个方向扩展多路视频源之间的联动调度比如两个摄像头画面重叠区域出现同一个目标同源自不同源的帧就需要跨路匹配。这种情况下调度层不仅要处理帧复用还要处理跨源时间同步和时间戳对齐。RTSP流的网络抖动会导致不同源的帧到达时间不一致最简单的做法是以主摄像头的帧率为基准其他源按时间戳就近匹配。模型热切换业务需求变化或者模型版本升级时能在不重启整个系统的情况下替换某个任务的模型文件。这个对调度层的设计要求更高需要任务具备暂停、重新初始化context、恢复运行的能力。我在新版本调度器里给任务增加了一个runtime_reload回调配合配置中心的模型版本下发可以实现业务无感升级。这两个方向对同源调度架构的底层假设没有破坏性改动核心的帧池、引用计数、任务调度时序完全可以复用。最后的一点经验从单任务到多任务并发RK3588上碰到的坑不少。回头总结最重要的不是某个具体接口怎么调而是要建立“数据流共享、访问互不干扰”的工程思维。帧池负责管好数据生命周期调度器负责管好任务节奏推理线程各自独立做到这三件事同源多任务调度就已经成功了一大半。最后再分享一个小技巧调试多任务并发时一定要把每路任务的关键指标帧率、延迟、丢帧率、NPU利用率做成结构化日志定期落盘。很多偶发问题比如运行两三个小时后的内存缓慢增长必须靠长时间日志比对才能发现规律。拿个Excel做趋势对比往往最直观比我见过的任何调试工具都好用。