企业官网建设流程全解析

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系统，输入是1080p@25fps的RTSP流，三个模型（yolov8s车辆检测、yolov5s安全帽检测、轻量车牌分类）并发。

主循环频率设定为25FPS，每个周期执行如下步骤：

1. RTSP拉流线程收到一帧，送入硬件解码器。
2. 解码器输出YUV帧，调度器在同一时刻拿到帧，当前引用计数从0变成1。
3. 调度器检查车辆检测任务A：该任务为实时敏感型。直接把帧指针投递到任务A的队列，引用计数加1。
4. 调度器检查安全帽任务B：此时帧池已积压2帧，任务B按策略执行跳帧，不投递当前帧。
5. 调度器检查车牌分类任务C：这是准实时任务，距离上次处理已过去450ms，超过抽帧周期阈值，把当前帧投递到任务C队列，引用计数再加1。
6. 三个推理线程并行执行rknn_run，各自独立获取结果。
7. 各任务推理完成后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）：

这里要特别说明，上面的预估并发实例数是按“每帧都需要推理”计算的。如果任务允许跳帧，比如每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(maxsize=2) 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(timeout=0.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，目的是排除网络波动干扰，模型分别是yolov8s（640输入）、yolov5s（640输入）、轻量分类模型（224输入），三个任务共享同一解码流。

下面是三个不同配置下的实测结果：

从这组数据能得出几个结论：

• 同源调度相比独立解码，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做趋势对比往往最直观，比我见过的任何调试工具都好用。