AI 推理会不会堵住实时任务?MCU 上跑模型时,RTOS 和 DMA 该怎么配合?

大家好,我是贺老师,嵌入式 AI工程师,《嵌入式AI:让单片机学会思考》课程主理人,专注AI在MCU上的落地实践。

在 MCU 上跑模型,最难的问题可能不是"能不能推理出正确的结果"这么简单。其实最复杂和难搞的是:如何合理的调配比如ADC 、I2S、DCMI、控制任务、通信、日志等都在随时占用 CPU的各类任务。

今天贺老师带大家来搞清楚两个问题。AI 推理会不会堵住实时任务?MCU 上跑模型时,RTOS 和 DMA 该怎么配合?

AI 推理会不会堵住实时任务?

其实上面的问题应该算是一个"伪命题"。会不会堵,不能只看模型推理占用的时间;(一个模型跑 5 ms,不代表系统是安全的;一个模型跑 30 ms,也不一定会破坏整个系统的实时性)。

怎么定义"堵住"?

在实时系统里,"堵住"的定义应该是:任务错过了自己的截止时间。比如:采样任务本来每 1 ms 必须处理一次、控制任务每 2 ms 必须更新一次、通信接收缓冲区每隔50ms毫秒必须清空一次。如果模型推理让这些任务得不到 CPU,或者让它们等待某个资源释放,系统就会出现漏采样、控制抖动、串口溢出、帧数据错乱等问题。

几种常见的设计误区

(1)在设计中,最不推荐的写法,是把推理放进中断回调里。比如ADC 采样完成就在回调里计算采集数据的特征,这种写法的话,一旦采样频率提高、模型变大、通信任务变多,实时性就会很快失控。

中断服务函数应该短、确定、可预测,它适合做事件通知和缓冲区切换,不适合承载长时间计算。

(2)把 AI 推理任务设成很高优先级。

当AI推理的任务优先级很高时,表面上可以让模型尽快推理出结果,但实际可能让更重要任务(比如采样、控制、安全保护)得不到实际的运行的机会。

多数嵌入式 AI 判断允许几十毫秒级延迟,但采样周期和控制周期通常不允许被随意拉长。实时系统里,优先级应该服务截止时间,而不是服务"谁看起来更高级"。

(3)没有预留足够的缓冲时间

需要特殊注意的是:同一个模型,在数据不同时,占用的推理时间可能是不同的,这一点需要特殊注意,所以需要在设计验证阶段或者模型调优阶段就需要尽可能的模拟出来模型推理所占用的时间。在最终的设计定型时,给推理任务预留足够多的时间。(比如实验验证时的推理时间是30ms~40ms,在实际设计定型时,至少需要预留50ms的时间1)

如何判断AI推理是否会堵住实时任务?

判断 AI 推理是否会堵住实时任务,可以抓住三个数:

  • 数据块到达周期

  • 推理最坏耗时

  • 关键任务最大允许延迟

比如音频每 20 ms 形成一块输入,模型最坏推理 8 ms,并且推理运行在中等优先级任务里,采样由 DMA 保证,这种设计通常有余量。反过来,如果每 10 ms 来一块数据,预处理加推理最坏耗时已经接近 12 ms,队列还没有丢弃策略,系统迟早会积压。

结论很明确:AI 推理不会天然堵住实时任务,错误的上下文、错误的优先级、没有边界的阻塞等待,才是堵住实时任务的根源。模型可以慢一点,但采样和控制链路不能被它拖乱。

MCU 上跑模型时,RTOS 和 DMA 该怎么配合?

DMA 和 RTOS 正好解决的是数据(推理模型依赖于大量的数据采集与计算)和任务这两个的问题。

  • DMA 负责让数据按节奏进入内存,尽量不依赖 CPU 手工搬运;

  • RTOS 负责让不同任务按重要程度运行,避免一个耗时任务长期占住处理器。

两者配合得好,AI 推理就只是流水线里的一个阶段,而不是整机实时性的风险源。

两者应该如何配合?

(1)连续输入场景尤其需要 DMA

声音、振动、电流波形、IMU、摄像头数据都不是一次性输入,而是按固定节奏不断到达。比较稳的做法是使用双缓冲或环形缓冲:

DMA 正在写 A 缓冲区时,CPU 处理 B 缓冲区;DMA 切到 B 缓冲区时,CPU 再处理 A 缓冲区。

这样采样和计算可以重叠,CPU 忙于预处理或推理时,外设仍然可以继续把数据搬进内存。

(2)双缓冲真正要管住的是缓冲区所有权

正在被 DMA 写入的缓冲区,CPU 不应该读取;正在被 CPU 预处理或量化的缓冲区,DMA 不应该覆盖。

很多"模型输出乱跳"的问题,表面看像模型不准,实际是缓冲区还没写完就被读取,或者处理还没结束就被下一轮 DMA 覆盖。

(3)RTOS 这边,任务拆分不需要花哨,但边界要清楚。

  • 中断只做事件通知、缓冲区切换和少量状态记录;

  • 采样或数据管理任务负责接收 DMA 半满、全满事件;

  • 预处理任务负责滤波、FFT、MFCC、归一化、量化等操作;

  • 推理任务负责调用 TFLite Micro、STM32Cube.AI 或其他推理库;

  • 业务任务再根据结果做报警、控制、通信或记录。

(4)推荐的优先级设计原则

安全保护、硬实时控制、关键采样通常应该放在更高优先级;DMA 数据块管理和预处理触发次之;AI 推理任务通常放在中等优先级;日志、UI、非关键通信放在较低优先级。推理任务应该阻塞等待新数据,而不是空转轮询;日志应该异步输出,而不是在推理路径里大量打印;通信要有队列和超时,不能因为串口或网络拥塞反过来拖住推理和采样。

(5)提前做好资源冲突的预案,来不及处理时怎么办

实时系统里,错过一轮推理通常比破坏采样节奏更可接受。如果模型偶尔来不及处理,可以丢弃旧数据、只处理最新窗口、降低推理频率,或者在连续多次超时后进入降级模式。最不应该做的是让采样链路阻塞等待模型,因为采样节奏一乱,后面送进模型的数据分布也会跟着乱。

(6)必须做计时验证

至少要记录采样周期、DMA 半满和全满回调间隔、预处理最坏耗时、推理最坏耗时、队列积压长度、丢帧次数、控制任务最大响应延迟。只有这些数字都清楚,才能判断 RTOS 和 DMA 是否真的把 AI 推理关在了可控边界内。

MCU 上跑 AI,成熟的标志不是模型能打印出一个分类结果,而是模型推理不会破坏系统实时性。DMA 保证数据按节奏进入内存,RTOS 保证关键任务优先运行,缓存和内存策略保证数据一致,AI 推理只在合适的位置参与判断。

这也是标题两个问题的答案:AI 推理本身不会必然堵住实时任务,但错误的调度方式会;RTOS 和 DMA 的配合,不是为了让工程看起来复杂,而是为了让采样、计算和业务动作各自有边界、有优先级、有退路。

来源说明:相关信息来源于芯片原厂官网以及网络公开数据,若有侵权请联系删除,谢谢。

欢迎有不同意见的同学来评论区留言讨论......

相关推荐
张彦峰ZYF1 小时前
LangGraph 条件边:让 AI Agent 学会“做选择”
人工智能·大模型·langgraph
ZFSS1 小时前
BYOK(自带密钥)使用指南
运维·服务器·前端·人工智能·midjourney
装不满的克莱因瓶1 小时前
掌握典型卷积神经网络的搭建
人工智能·python·深度学习·神经网络·机器学习·ai·cnn
ting94520001 小时前
InsForge Backend Branching 后端全链路 Git 式分支技术原理、架构实现与底层源码剖析
人工智能·git·elasticsearch·架构
程序猿阿伟1 小时前
《扣子如何让OpenClaw技能开发提速》
人工智能·git·github
_Evan_Yao1 小时前
AI Agent下半场:模型能力过剩,Skill生态成为新壁垒
人工智能
圣殿骑士-Khtangc1 小时前
多智能体协作架构深度解析:MCP + A2A 协议栈,构建企业级 Multi-Agent 系统
人工智能