嵌入式AI多任务为何抢占？隔离怎么做？

一个模型独占开发板时延迟很好，和通信、控制、存储一起跑却超时，说明冲突发生在系统资源而不是网络结构本身。嵌入式AI多任务部署要先回答谁能等、谁不能等。

抢占问题最明显地出现在加速器调度上。许多低功耗芯片的 NPU 并不支持真正的细粒度抢占，一个模型一旦提交，就会占住整段执行窗口；另一个看似更小的检测任务只能排队等待。若系统把人脸识别、缺陷检测和姿态估计都按平均时延规划，突发并发时就会出现队列堆积。控制任务需要的是最坏时延，而不是单模型基准测试里的漂亮均值。

调度还会被 DMA 和内存带宽放大。相机采集、网络传输、日志落盘和模型加载都可能同时占用总线，NPU 虽然在计算，但输入输出张量到不了片上缓冲，推理仍然被拖慢。嵌入式AI多模型系统应给每类任务设定时间预算和准入条件：关键模型保留固定窗口，非关键模型按队列水位降帧，后台任务在推理高峰主动让出 DMA 带宽。没有这些规则，所谓并发只是把冲突推迟到现场。

隔离的另一半是内存。多个模型如果共用同一运行时内存池，峰值激活和临时缓冲会互相挤压；一个异常任务申请大块内存失败，可能连带破坏另一个实时任务的输入队列。更可靠的做法，是按任务等级划分内存池和队列深度，关键模型的输入、输出和中间缓冲提前预留，不能被后台识别或上传任务借走。这样做牺牲了一点平均利用率，却换来故障边界清晰。

隔离还要覆盖错误路径。某个模型加载失败、返回异常或连续超时后，应只降级该任务，而不是重启整套推理服务。对可选功能，可以切到低分辨率、低帧率或云端补偿；对安全相关功能，则应进入保守动作，而不是继续等待 NPU 空闲。资源隔离的目标不是让所有任务都跑满，而是保证关键链路在拥塞时仍然有确定入口。

批处理也要谨慎使用。把多个小任务合成一批能提高吞吐，却会增加首个任务的等待时间；对报警、避障或质检剔除这类动作，等待凑批可能比单次推理慢更危险。可选模型可以共享批处理窗口，关键模型则应保留独立提交路径，并在队列超过阈值时丢弃过期输入。否则系统看似提高了平均利用率，实时任务却被平均策略拖住。

验证并发时，不能只把模型逐个跑一遍。应构造最坏组合：相机满帧率、网络重连、日志高峰、模型热切换和控制周期同时发生，再记录每个任务的排队时间、执行时间、丢帧策略和内存水位。还要观察异常恢复路径，确认后台任务超时不会占住加速器句柄或泄露缓冲，也不会让后续任务继承错误状态；长时间压力下还要看队列是否缓慢累积，以及是否出现优先级反转和周期漂移。只要关键任务在这些组合下仍有上界，系统并发才算真实成立。

所以，多任务部署先是资源契约问题，然后才是模型性能问题。把加速器窗口和内存池隔离清楚，嵌入式AI才能在复杂系统里稳定共存。