RK3588同源多任务调度：帧分发与NPU资源竞争优化实践

一路视频画面进来上面同时挂着YOLOv8行人检测、人脸特征提取、车牌识别、区域入侵判断好几个任务每个任务都要GPU/NPU加速还要实时响应——这是我在RK3588上做边缘AI视觉项目时遇到的最典型场景。最开始的想法很简单每个模型一个线程各跑各的从同一个视频源各自取帧就行。结果一启动就发现帧率掉到4~5FPS四个模型的端到端延迟全部飙到500ms以上CPU占用直接拉满。问题不在模型本身而是出在同源多任务调度——多个视觉任务共享同一路视频源、同一块NPU、同一个CPU算力池时资源竞争和调度策略没理顺再强的芯片也会被拖垮。这篇文章是我这个系列的第3篇前两篇分别讲了RK3588平台的基础环境搭建和RKNN模型转换部署。这篇围绕同源多任务调度展开讲清楚同源多任务在RK3588上的资源竞争模型、帧分发策略、NPU推理调度方法、实测调优过程以及我在实际项目中踩过的坑和完整的排查链路。适合已经在RK3588上完成单模型部署、准备上多路多任务场景的朋友参考。1. 同源多任务调度在RK3588上要解决的真实问题1.1 什么是同源一路视频源驱动多个视觉任务先说清楚同源的含义。在边缘AI视觉场景里同一个视频源通常会被多个业务任务消费。举例来说一个智慧园区项目一台RK3588设备接了一路1080P摄像头需要同时实现行人检测YOLOv8s负责实时人流监控人脸特征提取MobileFaceNet负责重点人员识别车牌识别LPRNet负责出入口车辆管理区域入侵判断基于检测框的后处理逻辑依赖行人检测结果这四个任务共享同一个摄像头画面这就是同源。每个任务单独部署都很顺模型能跑到20~30FPS但组合到一起就乱套。我最初的做法是每个模型一个进程、每个进程独立读取视频流结果不仅CPU内存翻倍消耗还因为视频解码和格式转换重复做了四遍导致整体帧率崩盘。同源任务的核心矛盾在于数据源只有一个但消费数据的任务有多个。这不是简单的多线程并发问题而是要在帧分发、算力分配、优先级调度三个维度同时做设计。只解决并发不考虑资源竞争调度一定失败。1.2 RK3588的异构算力布局与任务划分RK3588的算力和各模块的职责分配是理解调度问题的前提:计算单元规格擅长任务调度中扮演的角色CPU4×Cortex-A76 4×Cortex-A55前后处理、业务逻辑、调度控制任务编排、数据搬运、后处理NPU6 TOPSINT83核神经网络推理模型推理算力竞争的核心RGA2D图像加速缩放、格式转换、旋转多模型输入尺寸统一处理VPU硬件编解码H.264/H.265视频编解码视频流解码、推流编码GPUMali-G610 MP4图形渲染、通用计算通常不参与AI推理可做可视化同源多任务调度要调度的绝不只是NPU。CPU的A76大核承担了大量工作视频帧读取、图像格式转换NV12转RGB、归一化、坐标映射、业务后处理。A55小核适合跑低优先级的轻量任务。RGA做缩放时如果多个任务同时提交请求也会排队。这些资源都是共享的任何一环成为瓶颈都会拖慢整条链路。1.3 调度问题的本质资源竞争而不是代码并发很多人在做同源多任务时犯的第一个错误是把问题当成并发编程来解——给每个任务开一个线程各自跑各自的推理以为只要加锁就能搞定。实际跑下来你会发现瓶颈根本不在线程竞争而在三个层面的资源竞争第一是数据竞争。多个任务各自解码、各自缩放、各自格式转换同一帧数据被反复处理CPU和内存带宽被白白浪费。第二是NPU排队。RKNN推理通过rknn_run提交给NPU多模型多线程同时提交时NPU驱动内部的调度策略是先来先服务没有优先级概念。低优先级任务可能把高优先级任务堵在后面导致高优任务延迟不可控。第三是内存带宽。RK3588的内存带宽虽然充裕但多路模型同时访问大块图像数据时cache miss率和DDR带宽占用会明显上升实测中推理耗时比单模型时增加20%~30%很正常。理解了这三层竞争才会明白同源多任务调度的核心目标让有限的计算资源服务好不同优先级、不同频率、不同时延要求的多个模型任务。调度设计要围绕这个目标展开而不是简单地把任务丢给线程池。2. 帧分发与推理频率控制先把喂数据这件事理顺2.1 视频采集线程与共享帧缓冲同源多任务调度的第一件事是把视频采集和任务消费解耦。我采用的方案是单采集线程 共享帧缓冲 多消费队列。采集线程负责从摄像头或RTSP流读取视频帧解码得到NV12格式的图像数据然后放进一个环形缓冲区。环形缓冲区存的是帧元数据FrameMeta而不是直接拷贝图像数据:struct FrameMeta { uint64_t frame_id; int64_t timestamp_us; int width; int height; uint8_t* data; // NV12数据 int data_size; std::atomicint ref_count; // 引用计数 };每个帧对象带一个引用计数多个任务可以同时引用同一帧而不用拷贝数据。采集线程每次写入新帧前检查引用计数只有引用计数为0时才允许覆盖该缓冲区。这个设计避免了多份图像数据在内存中被重复拷贝极大降低了内存带宽压力。为什么用环形缓冲而不是无界队列因为视频流是持续输入的如果消费者处理不过来无界队列会无限积压延迟持续膨胀。环形缓冲满了就丢旧帧保证系统永远消费最新数据这对实时视觉场景尤其重要。2.2 不同任务按需抽帧每帧跑还是隔N帧跑不同视觉任务对帧率的需求差异很大。行人检测需要实时响应可能希望每帧都跑人数统计每2秒跑一次就够了夜间才启用的车牌识别甚至可以降到0.5Hz。如果四个任务都每帧跑NPU和CPU负担直接翻四倍毫无必要。我在调度模块里为每个任务配置了抽帧策略用帧计数器取模来实现// 每个任务注册时指定抽帧间隔 struct TaskConfig { int task_id; int frame_interval; // 每隔多少帧推理一次1表示每帧都跑 int priority; // 优先级0最高 std::string model_path; };例如YOLOv8行人检测每帧跑frame_interval1人脸特征提取每5帧跑一次frame_interval5区域入侵判断直接复用行人检测结果做后处理不单独抽帧。这样设计后NPU的推理负载从每帧4次推理降为每帧约1.2次推理整体帧率立刻从4FPS恢复到20FPS以上。为什么不直接用时间间隔来控制抽帧因为视频源的帧率本身有抖动。如果用时间戳间隔控制采集的突发抖动会导致推理任务一会儿堆积一会儿空转。用帧计数器的模来控制逻辑简单且天然跟随视频源的节奏实测更稳。2.3 用队列条件变量实现多级消费采集线程负责投递推理线程负责消费中间用条件变量通知。我为每个任务维护一个独立消费队列采集线程根据抽帧策略把帧引用投递到对应任务的队列中class FrameDispatcher { public: void OnNewFrame(const std::shared_ptrFrameMeta frame) { for (auto task : tasks_) { if (frame-frame_id % task.config.frame_interval 0) { task.queue.Push(frame); task.cv.notify_one(); } } } std::shared_ptrFrameMeta WaitForFrame(int task_id) { // 任务线程阻塞等待超时则返回nullptr } };消费队列里存的是shared_ptrFrameMeta引用计数自动管理。推理线程拿到帧后先做RGA缩放和格式转换再交给RKNN推理。这里有一个关键细节队列长度要限制。理论上抽帧策略已经把投递频率压下来了但如果某个任务推理特别慢队列还是会积压。我给每个任务队列设置最大长度通常是8队列满了直接丢最老的帧。宁可丢帧也不能让延迟无限膨胀——这是实时视觉系统的铁律。3. NPU推理资源分配与优先级管理3.1 rknn_run同步模式下的排队真相帧分发理顺之后真正的瓶颈转移到NPU。RKNN推理默认是同步阻塞模式调用rknn_run时当前线程会一直等待NPU执行完成才返回。多个模型的多个线程同时调用rknn_run时它们都会向NPU驱动提交任务驱动内部按提交顺序排队执行。实测下来RK3588的NPU驱动确实有任务队列但调度策略很简单基本是先来先服务没有任务优先级的概念。这意味着一个低优先级的耗时模型比如输入分辨率很高的人脸检测一旦提交后面所有高优先级模型的推理都要等它跑完高优任务的延迟立刻恶化。这个问题的本质是NPU驱动无法感知业务层面的优先级。要解决它必须在应用层自己做限流和调度把什么任务在什么时间占用NPU这件事控制住。3.2 多模型线程池设计与优先级映射我的方案是每个模型一个独立推理线程线程内部维护自己的推理状态对外提供非阻塞的提交接口。调度器在每次投递帧之前先检查对应任务的上一次推理是否完成如果没完成就直接丢弃这一帧确保推理线程永远只处理最新的一帧而不是积压旧任务class InferWorker { public: bool TryInfer(const std::shared_ptrFrameMeta frame) { if (inferring_.load()) { return false; // 上一次推理未完成丢弃当前帧 } inferring_.store(true); // 拷贝必要的帧数据到模型输入buffer然后启动推理线程 thread_pool_.enqueue([this, frame]() { RunInfer(frame); inferring_.store(false); }); return true; } };这个有损限流机制是控制NPU负载的核心。它的作用相当于给每个任务设置了一个软性FPS上限任务跑得再快也就那么多跑得慢就直接丢帧绝不积压。实测下来高优先级任务的延迟从被低优任务堵到800ms降回稳定80ms左右。CPU核心的绑定和优先级分配上我是这样做的任务类型CPU核心调度策略视频采集线程A76 Core0绑定核心避免调度抖动YOLOv8检测线程A76 Core1Core2主检测任务高优先级人脸特征提取线程A76 Core3中等优先级车牌识别线程A55 Core0低优先级低频推理调度器主线程A55 Core1绑定核心轻负载做过对照实验把所有推理线程都放A76上CPU占用率到90%以上推理反而变慢。原因是A76核心频繁抢占切换cache抖动严重模型推理的耗时反而增加。把轻量任务放到A55小核后大核的cache命中率明显改善整体吞吐反而更高。3.3 异步推理与回调结果汇聚的边界条件RKNN也提供了异步推理的接口我把rknn_run_async和完成回调试了一遍。异步模式的优点是可以同时向NPU提交多个模型的推理任务NPU核心能更好地并行利用起来。但实测中遇到两个问题第一多个RKNN context的异步提交并不完全均衡。RK3588的NPU有3个核心但驱动层面的任务切分是黑盒无法精确控制哪个模型跑在哪个NPU核上。实测中有时低优先级任务占据了两个NPU核高优先级任务只能在剩下的一个核上跑高优任务延迟反而更高。第二异步模式下推理线程和结果汇聚线程之间的同步更复杂。多个模型的完成回调在不同线程触发如果回调里直接做后处理后处理的并行度会被推高CPU占用率明显上升还容易出现资源竞争。最终我放弃全面异步方案改回同步推理 有损限流 多线程隔离的组合。这套方案对上层的语义更清晰每个任务在自己的线程里同步跑推理调度器通过抽帧和有损限流控制NPU提交频率通过CPU绑定控制资源隔离。虽然没有让NPU三个核心都满负荷但换来了延迟稳定和调度可控。对边缘AI设备来说稳定比峰值性能重要得多。4. 实测调优帧率、延迟与CPU占用率的平衡4.1 先做单模型基线不摸清底数没法调调优的第一步是先把每个模型在RK3588上的单模型性能基线测清楚。我用rknn-toolkit2里的benchmark工具逐个测试了即将部署的模型记录了关键指标模型输入尺寸推理耗时(ms)单模型帧率(FPS)峰值内存(MB)YOLOv8s640×6404223380MobileFaceNet112×1128120210LPRNet160×486150120DeepSort特征提取128×128518090YOLOv8s是绝对的算力大头单次推理就占42ms。四个模型理论上都跑的话每帧总推理时间约61ms加上采集和前后处理每帧总耗时要到80ms左右极限帧率只有12FPS左右。这时候再按业务需求设计抽帧策略就非常有针对性了YOLOv8每帧跑人脸每5帧跑一次LPR每10帧跑一次DeepSort特征复用YOLOv8的检测结果只在检测到新id时触发。平均每帧推理耗时约44ms帧率可以稳定在20FPS以上。基线数据的价值在于它告诉你算力冗余在哪里瓶颈在哪里。没有基线调参就是盲人摸象。4.2 组合场景下的调度参数调整基于基线数据我按先帧率、后延迟、最后CPU占用的顺序做调优。整体流程如下第一步确认抽帧策略符合业务需求。YOLOv8每帧跑、人脸抽帧、LPR抽帧NPU单帧推理负载从四连跑降到约44ms帧率恢复。第二步处理RGA和格式转换的重复劳动。四个模型各自需要不同尺寸的输入原本每个任务自己调用RGA缩放。当多个任务同时提交RGA请求时RGA引擎排队前处理耗时暴增。我把缩放操作收敛到一个统一的前处理线程中相同目标尺寸的缩放结果复用同一块缓冲不同尺寸之间也尽量共享源码。实测前处理总耗时下降了约35%。第三步调整CPU核心绑定。一开始所有推理线程都跑A76CPU占用率85%以上后来把低优先级的LPR和特征提取挪到A55小核大核只留给YOLOv8采集和后处理。CPU占用率降到55%左右YOLOv8的推理耗时反而因为cache改善进一步缩短。第四步压测组合场景。四个模型同时开启、持续运行半小时观察帧率、延迟、内存三个指标。关键数据配置阶段帧率(FPS)YOLOv8端到端延迟(ms)CPU占用率各任务独立拉流555092%统一采集抽帧1416078%抽帧有损限流CPU绑定218255%再加统一RGA缩放237648%调优的核心方法论是每次只改一个变量用数据验证后再动下一个。我见过很多人调优时同时改抽帧间隔、线程优先级、输入分辨率结果出了问题根本定位不了是哪个改动引入的回归。4.3 长时间运行的稳定性验证边缘AI设备是7×24小时跑的短时间能跑通不代表长时间稳定。我在45分钟稳定运行后遇到过NPU推理耗时从45ms逐渐恶化到85ms的情况排查下来是设备温度问题RK3588满负荷跑NPU散热片温度到了85℃以上NPU和CPU集体降频推理性能就掉了。针对这个问题我做了一套简单的温控策略读取/sys/class/thermal/thermal_zone0/temp获取SoC温度温度超过70℃时主动降帧——优先降低低优先级任务的抽帧频率。同时通过PWM风扇接口做主动散热风扇转速根据温度阶梯调节而不是一直满转或者不转# 读取SoC温度单位毫摄氏度 cat /sys/class/thermal/thermal_zone0/temp # 设置PWM风扇转速0~255 echo 128 /sys/class/pwm/pwmchip0/pwm0/duty_cycle温度控制策略示例65℃以下风扇低速65~75℃中速75℃以上全速并触发降帧。这套温控逻辑配合调度系统后设备连续运行一周YOLOv8的端到端延迟始终稳定在80ms±10ms以内没有再出现性能雪崩。5. 踩坑实录调同源多任务时最容易翻车的三个环节5.1 延迟突然飙升谁在偷偷抢占NPU第一个让我印象深刻的坑是排查为什么运行半小时后YOLOv8延迟从80ms涨到500ms。最开始怀疑是内存泄漏用了top看内存一切正常怀疑是线程死锁跑了gdb也没发现异常。后来逐个关闭其他任务当关掉车牌识别任务时YOLOv8延迟立刻恢复正常。根因是车牌识别模型虽然抽帧频率极低每10帧一次但它的输入是1600×600的大分辨率图像单次推理要120ms。它在NPU上占用的执行时间太长把后面提交的YOLOv8任务全部堵住。解决办法是给NPU提交加上限流——通过有损限流机制限制每个模型每秒最多提交N次推理同时调度器主动避开大分辨率模型的提交时机错峰调度。加了这个逻辑后同源多任务下的延迟抖动从无规律200~500ms降到稳定80ms左右。这次排查给我的教训是低频率的大模型对高频率小模型的延迟影响往往比想象中大得多。调度设计时不能只看平均负载还要考虑每个模型在NPU上的单次执行时间。5.2 RGA缩放竞争导致的丢帧第二个坑出现在我统一RGA缩放之前。四个模型需要把1920×1080的原图缩放到640、112、160、128四种尺寸每个模型单独调RGA接口。运行后发现当四个任务同时提交缩放请求时RGA引擎的排队时间会超过1帧的采集间隔导致采集线程的环形缓冲频繁被覆盖部分模型拿到的帧不连续检测结果出现跳变。为了根治我把RGA缩放统一到一个前处理服务中所有模型不再自己调RGA而是向这个服务请求服务内部维护一个缩放队列和缓冲池。对相同目标尺寸的缩放请求直接复用缓冲对已经在处理的源帧可以合并缩放。改造后前处理丢帧率从5%降到0.1%以下。这个坑的本质是多个任务重复消费同一份数据时没有做资源层面的合并。RK3588的RGA是很宝贵的硬件加速器但它需要统一调度才能发挥价值多个线程各自抢占反而互相拖累。5.3 内存复用时踩到的buffer踩踏问题第三个坑和共享帧缓冲的引用计数有关。最初我实现环形缓冲时采集线程写入新帧前没有检查引用计数结果低帧率的人脸识别任务还在使用某一帧时采集线程已经把这块buffer覆盖成新数据了。表现出的症状很隐蔽人脸特征提取偶尔输出错误结果时好时坏这类bug极其难定位。排查确认后我给帧对象加上了引用计数逻辑采集线程只有在ref_count 0时才能覆盖该帧否则跳过当前采集周期等待下一轮。同时所有消费者拿到帧时递增引用计数处理完再递减。这块的教训是内存复用在边缘AI设备上几乎是必须的否则DDR带宽不够用但复用必须配合严格的引用计数和生命周期管理。图省事用裸指针共享buffer迟早踩踩踏的坑。还有一个容易被忽略的细节RKNN推理必须是同步等待结束才能释放输入buffer。我最初为了省内存在rknn_run返回前就复用了输入buffer结果NPU还在读数据已经变了推理结果随机出错。后来改为推理结束、结果输出拷贝完成之后才释放输入buffer问题消失。写在最后RK3588上的同源多任务调度本质上是在有限算力下做资源编排的艺术。一路视频源、多路视觉任务、多种计算单元这些资源单独看都够用但组合在一起就需要系统级的调度设计。我现在这套方案的骨架是统一采集减重复、抽帧策略控负载、有损限流稳延迟、CPU绑定防抖动、温控联动保长久。每一步都是踩坑踩出来的。如果你也在RK3588上做多路视觉任务建议先从单模型基线和业务帧率需求入手先把数据算清楚再动手写调度框架。调度方案没有银弹适合自己业务场景的才是最好的。后续我打算再深入一下RK3588 NPU多核的通道隔离能力看看能不能让高优先级模型独占一个NPU核心进一步降低推理延迟的抖动。等有新进展了再回来更新这个系列。