做边缘AI视觉项目的人应该都有同感单跑一个模型的时候一切岁月静好一旦要同时运行检测、分类、OCR等多路任务RK3588这块6TOPS算力的芯片立刻就成了瓶颈。帧率掉到不忍直视、内存爆掉、任务之间互相抢占资源……我在自己的边缘AI视觉项目里也踩过不少这种坑。后来我把“同源多任务调度”这套思路真正落到RK3588上整个系统的稳定性和可用性才算提上来。这篇文章面向的读者有两类一类是已经在RK3588上跑过RKNN模型、想进一步把多路视觉任务工程化落地的开发者另一类是正在RK3588平台选型、想了解边缘AI多任务到底怎么组织的新手。核心会讲清楚三件事什么是同源多任务为什么调度是边缘AI视觉绕不开的命题以及RK3588上调度器怎么设计、怎么实现、怎么调优。1. 为什么要做同源多任务调度1.1 边缘AI视觉的算力天花板与现实需求RK3588的规格参数大家都熟悉8核CPU4×A76 4×A55、6TOPS NPUINT8、支持8K解码与多路MIPI-CSI输入。单看参数它确实是目前边缘AI设备里的“性价比之王”。但这个6TOPS是理论峰值实际跑到3TOPS都算不错了而且这个算力要分配给所有的视觉任务不是只给一个模型用。我做过一个园区的边缘智能盒子需求来了三路人员检测判断画面里有没有人用于人数统计安全帽检测算工地的刚需车辆识别区分小车、卡车、工程车联动道闸刚开始图省事直接起了三个线程、分别加载三个RKNN模型每个模型独立跑自己的推理循环。结果一上线就发现问题三个模型同时跑的时候NPU资源互相挤占推理耗时从正常的15ms直接飙到60ms以上而且CPU端做后处理的负载也堆上去了整机温度快速爬升。最要命的是安全帽检测这种高优先级任务反而因为和车辆识别抢资源出现周期性卡顿漏检率显著上升。这不是RK3588不行而是我压根没有做调度设计。边缘AI视觉项目里真正的复杂度往往不在模型本身而在于如何把多个模型有机组织起来让算力用在刀刃上。1.2 同源多任务的核心思想共享而不是叠加我在这个项目中逐步摸索出一套“同源多任务”的思路。什么叫同源站在工程角度看有三种“同源”形态同输入源。多路视觉任务处理的是同一路视频流、同一帧画面。人员检测和安全帽检测其实看的都是同一个摄像头画面。如果每个任务各自解帧、各自缩放、各自做预处理大量计算是浪费的。合理的方式是统一采集、统一做一次预处理然后分发给不同模型。同骨干网络。很多视觉任务的特征提取层是共通的。比如人员检测、安全帽检测、吸烟检测本质上都是目标检测前面的backbone思路完全一致只是检测头的类别不同。与其让三个模型各做一次完整的特征提取不如在一个模型里挂多个检测头或者至少复用同一套预处理和特征表示。同调度框架。多个任务即便模型不同也应该有一个统一的调度器来管理它们的执行周期、优先级和资源分配而不是各跑各的、互相干扰。系统性地想这件事是从“叠加思路”转向“调度思路”的关键。叠加思路是一个模型算力不够就想办法优化模型、剪枝、蒸馏把单模型的耗时降下来。但边缘盒子的任务是不断叠加的今天三个任务明天可能就要加一个烟火检测后天还有一个车牌识别。如果每个任务都靠压榨模型来“硬塞”进NPU最终一定会撞到算力天花板。调度思路则完全不同把NPU当成一个共享的计算池每个视觉任务按照其重要性、实时性需求动态分配算力比重。高优先级任务比如安全检测类抢占更多执行窗口低优先级任务比如统计类、非实时分析类在空闲时隙顺带执行。整体上系统总吞吐量不一定比“三个模型硬跑”低多少但每一帧的计算资源都花在了该花的地方。2. 系统架构与调度策略设计2.1 整体链路从采集到结果分发的完整设计一个成熟的RK3588边缘AI视觉系统从数据流角度看分四层采集层MIPI-CSI或RTSP接入视频流解码后得到YUV/RGB帧预处理层缩放、色彩空间转换、归一化、padding产出NPU输入张量推理层RKNN模型在NPU上执行得到原始输出张量后处理层解析输出NMS、分类、阈值过滤把结果合并成结构化数据很多新手只在“推理层”下功夫觉得模型跑得快就万事大吉。但实际排查性能瓶颈时你会发现经常是采集和预处理在拖后腿。RK3588虽然有强大的硬件解码器但如果你用CPU去做RGB转换、缩放CPU占用会泡到60%以上反过来又影响调度器的响应。我的方案是采集线程只做解码和帧缓存用RGARK3588自带的2D图形加速器做缩放和格式转换NPU只负责纯推理后处理放到独立的线程池。调度器则横跨预处理、推理、后处理三层统筹每一路任务的执行时机。2.2 单模型多任务与多模型调度的取舍这里要做一个关键决策多任务到底是放在一个模型里还是拆成多个模型我做一个对比表方便你根据项目实际情况选型维度单模型多任务multi-head多模型独立部署 调度骨干网络共享完全共享省算力各自独立有重复计算训练难度需要准备多任务标注数据调loss权重可复用已有单任务模型扩展灵活性新增任务要重训整个模型新增任务只增加一个模型文件部署复杂度一个rknn文件部署简单需要调度器统一管理典型场景固定几类强相关检测人员安全帽吸烟任务间关联弱且会持续增加我在园区那个项目里把人员检测、安全帽检测、吸烟检测合成一个多任务模型。因为这三个任务输入完全相同且检测头结构相似共享一个backbone之后单次推理耗时只比原版单任务YOLOv5s增加了约4ms左右在RK3588上大约从14ms涨到18ms。但车辆识别是另一个完全不同的模型差太大硬塞进同一个模型收益有限所以我单独部署由调度器统一管理。这就是“同源多任务”的落地形态强相关任务用单模型多任务头解决弱相关任务用多模型加调度器解决。2.3 调度策略优先级、周期与动态帧率调度器不能简单做成“先到先得”必须有明确的策略。我在这套系统里用了三层策略优先级分层。把任务分成实时型、准实时型、后台型。比如安全帽检测属于实时型必须每帧都做人数统计准实时即可每5帧做一个抽样车辆识别后台型频率可以更低。调度器的第一个工作是维护一个“可运行任务队列”队列按优先级排序高优先级任务永远先执行。周期控制。每个任务注册时都带上期望执行周期比如安全帽检测周期为1即每帧执行人数统计周期为5车辆识别周期为10。调度器以当前帧号为基准判断每个任务是否到期。到期的任务进入待执行集合再按优先级在NPU时间片上排队。动态帧率调节。这是最实用的一个机制。当NPU负载过高时调度器会监测每个任务近N次推理的平均耗时如果发现整体的推理队列积压超过阈值就主动降级低优先级任务的采样周期。例如车辆识别从每10帧一次降到每20帧一次保证高优先级任务不掉帧。反过来当负载下降时自动恢复采样周期。这套策略的好处是系统不会因为某个时刻的任务叠加而崩溃只会优雅地牺牲掉部分后台任务的精度和召回率。安全检测类任务始终有资源保障。3. RK3588上同源多任务调度的落地实现3.1 模型准备与NPU资源评估在写调度器之前先要把每个模型的资源占用摸清楚。RKNN-Toolkit2转换模型后真机初始化模型时可以用以下C API查询模型信息rknn_context ctx; rknn_init(ctx, model_path, 0, 0, NULL); rknn_sdk_version version; rknn_query(ctx, RKNN_QUERY_SDK_VERSION, version, sizeof(version)); printf(sdk version: %s\n, version.api_version); rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); printf(input num: %d, output num: %d\n, io_num.n_input, io_num.n_output);在做多任务规划时我会先跑一个基准测试单独加载每个模型分别推理100帧统计单次推理平均耗时、最大耗时、最小耗时以及NPU占用。下表是我在RK3588上的一个实测参考值INT8量化NPU频率默认模型输入分辨率推理平均耗时备注YOLOv5s多任务头3类640×64018ms人员安全帽吸烟YOLOv5s车辆检测640×64015ms独立模型ResNet18 分类224×2244ms用于二次过滤有了这些基准值就能估算多任务同时运行的耗时上限。比如希望系统整体帧率不低于15FPS那么一帧画面中所有任务的总推理时间必须控制在约66ms以内。上面两个YOLO模型叠加已经要33ms如果三个任务同时跑还绰绰有余但如果再加一个OCR模型就要认真考虑调度周期了。3.2 调度器代码实现任务注册与动态调度调度器本身不复杂核心是“维护一个任务表 按策略挑选任务”。我用C写了一个轻量级调度器框架核心数据结构如下#include queue #include vector #include thread #include mutex #include condition_variable #include chrono #include opencv2/opencv.hpp #include rknn_api.h enum class TaskPriority { HIGH 0, // 实时型每帧必跑 NORMAL 1, // 准实时可按周期降级 LOW 2 // 后台型空闲时跑 }; struct VisionTask { int id; std::string name; TaskPriority priority; int period; // 每period帧执行一次 int frameCounter 0; int videoChannel; // 关联的视频流通道 rknn_context ctx; // RKNN上下文 cv::Mat preprocessInput; // 预处理后的输入 }; class TaskScheduler { public: void registerTask(VisionTask task) { std::lock_guardstd::mutex lock(mtx_); if (task.priority TaskPriority::HIGH) { highPriorityTasks_.push_back(std::move(task)); } else if (task.priority TaskPriority::NORMAL) { normalPriorityTasks_.push_back(std::move(task)); } else { lowPriorityTasks_.push_back(std::move(task)); } } void onFrameArrived(int channel) { std::lock_guardstd::mutex lock(mtx_); // 按优先级顺序尝试调度 scheduleInGroup(highPriorityTasks_, channel); scheduleInGroup(normalPriorityTasks_, channel); scheduleInGroup(lowPriorityTasks_, channel); } private: void scheduleInGroup(std::vectorVisionTask tasks, int channel) { for (auto task : tasks) { if (task.videoChannel ! channel) continue; task.frameCounter; if (task.frameCounter % task.period 0) { // 将任务加入执行队列由推理线程取出执行 readyQueue_.push(task.id); } } } std::mutex mtx_; std::vectorVisionTask highPriorityTasks_; std::vectorVisionTask normalPriorityTasks_; std::vectorVisionTask lowPriorityTasks_; std::queueint readyQueue_; };这里我特意把调度和执行分离调度器只负责“决定哪些任务该执行”实际执行由独立的推理线程从readyQueue里取任务调用rknn_run完成推理。推理线程的核心循环void inferenceLoop() { while (running_) { int taskId; { std::unique_lockstd::mutex lock(mtx_); cv_.wait(lock, [this] { return !readyQueue_.empty() || !running_; }); if (!running_) break; taskId readyQueue_.front(); readyQueue_.pop(); } auto task findTaskById(taskId); if (task nullptr) continue; auto start std::chrono::high_resolution_clock::now(); // 设置RKNN输入 rknn_input inputs[1]; memset(inputs, 0, sizeof(inputs)); inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size task-preprocessInput.total() * task-preprocessInput.elemSize(); inputs[0].buf task-preprocessInput.data; rknn_inputs_set(task-ctx, 1, inputs); // RKNN推理 rknn_run(task-ctx, nullptr); // 获取输出 rknn_output outputs[3]; rknn_outputs_get(task-ctx, 3, outputs, nullptr); // ... 后处理解析输出这里省略 auto end std::chrono::high_resolution_clock::now(); float costMs std::chrono::durationfloat, std::milli(end - start).count(); updateAvgCost(taskId, costMs); } }这套框架跑起来后调度器的开销几乎可以忽略不计。它真正解决的是“多任务谁先谁后”的纠缠让每一个模型都清晰知道自己该什么时候跑。3.3 多路视频流的统一调度与帧率控制如果只是单路视频的多任务调度器其实相对好写。难的是多路视频流 多任务同时存在。比如一个边缘盒子接了4路摄像头每路画面都要做人形检测和车辆检测。在这种情况下逐路逐任务独立调度很容易失控。我的做法是引入“通道时间片”的概念每路视频流维护自己的frameID计数调度器在每一轮的全局循环中按通道权重复用NPU时间片。例如四路场景下安全检测通道占50%资源其他三路共享剩余50%每路内部的帧率控制依赖采样周期而不是依赖全局帧率伪代码思路void scheduleChannels() { // 假设4路通道通道0为关键通道 for (int round 0; round 4; round) { int channel roundMap[round]; // {0,1,0,2,0,3,...} 按权重分配 // 对该通道执行多任务调度 onFrameArrived(channel); } }在RK3588上实测4路1080p视频流、每路人形检测 车辆检测通过这种时间片调度关键通道能稳定跑25FPS其余通道跑15FPS左右。如果不用调度而让4路同时抢NPU整体全部掉到10FPS以下而且关键通道没有保障。4. 实测调优与常见问题排查4.1 性能摸底从单任务到多任务的耗时分布我把整个系统在RK3588上的实测数据整理成一张表供参考场景任务组合平均帧率推理耗时备注单任务仅人员检测55FPS18ms基准双任务硬跑人员 车辆22FPS45ms未调度互相抢占双任务调度人员 车辆34FPS人员18ms车辆30ms调度器统一分配三任务硬跑人员 安全帽 车辆12FPS70ms未调度系统过热三任务调度人员/安全帽/车辆 含动态降级28FPS高风险任务18ms低优先级降采样关键结论有两条多任务调度带来的提升不是“单个模型更快”而是“系统整体不卡死”。未调度时三个任务叠加70ms的推理耗时一旦NPU忙不过来CPU和内存也连锁飙升最终整个系统都会瘫。调度后虽然总耗时还是接近70ms毕竟活还是那么多但通过把车辆识别等任务压低采样频率高风险任务的响应时间完全不受影响。动态降采样对“感知类”任务影响较小。车辆识别从每5帧降到每10帧在应用层看来只是少了一半冗余检测实际效果几乎无感知。但安全帽检测如果少跑一半漏检率是肉眼可见的。4.2 高频问题与排查方法速查在调试多任务调度时我遇到过不少问题这里整理成排查速查表现象可能原因排查方法多任务后NPU推理耗时暴涨多个rknn上下文并行占用NPU导致NPU内部切换频繁用rknn_query查询各模型推理耗时观察调度器是否让同优先级任务同时挤入增加时间片间隔系统CPU占用过高输入图像缩放和RGB转换用了CPU而没用RGA检查是否调用imutils.resize或cv::resizeRK3588上要改用RGA做硬件加速画面卡顿但NPU占用不高视频解码线程阻塞或帧缓存队列设计不合理检查采集线程是否有ring buffer确认是否使用了硬件解码器MPP某个模型偶尔推理失败RKNN上下文被多线程并发调用RKNN上下文不是线程安全的确认同一个context只有同一个推理线程在调用调度器优先级形同虚设任务周期配置不当低优先级任务高频率凑进来把所有任务的period、priority打出来核对必要时打印每帧调度决策日志长时间运行内存持续增长输出张量未释放或后处理对象未回收检查rknn_outputs_release调用是否配对用/proc/meminfo和/proc/self/status监测RSS4.3 我踩过的坑与调优心得最后分享几条我自己反复踩过的坑希望你能少走弯路。坑一不要共用RKNN上下文。我一开始图省事让两个线程共用一个rknn_context想着反正都是同一个模型。结果推理结果偶尔是乱的时好时坏。查了很久才发现RKNN上下文不是线程安全的。正确的做法是要么一个任务独占一个context要么用互斥锁把rknn_inputs_set到rknn_outputs_get这个区间包起来。我用的是前者隔离性最好调起来也最省心。坑二预处理不要用CPU硬扛。刚做多路流时我用OpenCV的cv::resize和cvtColor做预处理4路1080p直接让A76核满载调度器本身反而没时间片跑了。后来把所有预处理切到RGARockchip的2D硬件加速器CPU占用从60%降到不到15%这一步是整个系统稳定性的关键转折。坑三动态降级要有“恢复”机制。早期我做了动态降级但只降不升——车辆识别降采样后即便NPU空闲了它也不自动恢复。导致后台任务的精度持续低下。后来在调度器里加了一个监控每次高优先级任务推理结束后如果NPU近500ms的平均占用率低于50%就逐步恢复低优先级任务的采样率。坑四一定要监控NPU温度与频率。RK3588的NPU在高负载下会降频且降频幅度可能很大从默认频率降到一半以下。我一度以为是调度器写错了导致推理变慢后来查/sys/class/thermal下的温度节点才发现NPU已经到85℃了。给设备加散热风扇同时让调度器监测NPU温度超过阈值就主动降低所有非关键任务的频率比被动降频要体面得多。坑五调度器要预留“耗时可观测”能力。每轮调度后把各任务近10次的平均耗时报出来开发阶段非常有用。它能帮你快速定位是某个模型本身变慢了还是调度策略导致的排队。我在调度器里加了一个dumpStats()函数定时打印各任务的执行次数、平均耗时、丢弃帧数。调优的时候盯着这个输出比靠感觉猜要高效得多。结语与一点个人体会我自己的体会是RK3588这类边缘AI芯片算力是真的够用的瓶颈几乎都在软件组织方式上。很多项目单跑一个模型跑得很欢一叠加任务就崩核心原因不是芯片太弱而是没有把算力当作一种需要精细调度的资源来对待。同源多任务调度的价值不在于榨干NPU每一分算力而在于让系统中真正重要的事情永远有资源可用。安全帽检测漏了可能会出事故车辆识别少跑几帧完全无所谓——调度器要做的事情本质上就是把这种业务优先级翻译成NPU的资源分配策略。如果你正准备在RK3588上做多路视觉任务建议从最小的调度框架入手先保证两个任务能有序跑起来再逐步加复杂度。调度逻辑本身不难难的是对每个任务的耗时、周期、优先级心里有数。把你自己的模型基准测清楚调度器写起来就水到渠成。最后再分享一个小技巧在RK3588上调多任务调度时强烈建议先固定NPU频率比如设置到最高档排除频率跳变的干扰把调度逻辑验证通过后再放开频率自适应。这样能大大缩短排错路径。等项目稳定后再根据温度策略动态调频整体系统就能又稳又能打了。