3、实时推理概述：推理延迟、吞吐量、确定性、硬实时与软实时的区别，以及Cortex-M上的典型应用场景
在Cortex-M处理器上部署神经网络推理模型，与在PC或云端GPU上运行推理有着本质不同的评价体系。云端推理追求高吞吐量和低成本，而Cortex-M上的推理首先必须回答一个问题：这个推理结果在时间上是否可信？实时推理（Real-time Inference）并非简单地指“运行速度快”，而是指系统能够在明确的时间约束内完成推理并输出结果，且该时间约束的满足具有可验证性。本章将系统阐述实时推理的核心度量指标、硬实时与软实时的本质区别，以及这些概念在Cortex-M典型应用场景中的具体映射。
上图展示了实时推理评价体系的整体框架。在Cortex-M平台上，这三个指标并非孤立存在，而是相互制约：降低延迟通常意味着减少批处理大小，从而降低吞吐量；追求确定性则可能需要牺牲一定的平均性能。理解这些权衡关系，是进行实时推理系统设计的第一步。
3.1 核心原理：实时推理的三个基本度量
推理延迟（Inference Latency）定义为从触发信号（如传感器中断、定时器事件）到推理结果可供消费之间的总时间。在Cortex-M系统中，这个时间包含四个组成部分：数据采集时间（ADC转换或DMA传输）、预处理时间（归一化、滤波、重排）、推理计算时间（卷积、全连接等算子执行）以及后处理时间（阈值判断、输出编码）。值得注意的是，延迟的度量必须从系统角度出发，而非仅关注推理内核的执行时间。例如，一个使用CMSIS-NN优化的卷积层可能仅需0.5ms，但如果DMA传输数据需要2ms，则端到端延迟仍然高达2.5ms。
吞吐量（Throughput）衡量系统在单位时间内能够处理的推理任务数量。对于Cortex-M设备，吞吐量通常以“次/秒”或“FPS”（帧每秒）表示。吞吐量与延迟存在数学关系：在理想流水线情况下，最大吞吐量等于1/延迟。但实际系统中，由于中断处理开销、内存带宽竞争和任务切换，有效吞吐量往往低于理论值。例如，一个延迟为5ms的推理任务，理论最大吞吐量为200次/秒，但若系统还需处理其他中断，实际吞吐量可能降至150次/秒。
确定性（Determinism）是实时推理中最容易被忽视却最关键的属性。确定性包含两层含义：结果确定性——相同输入必然产生相同输出（这要求推理算子使用固定精度算法，避免浮点舍入差异）；时间确定性——推理执行时间在可接受的范围内波动，即抖动（Jitter）可控。Cortex-M处理器由于采用确定性的流水线设计（无乱序执行、无分支预测），天然比应用处理器更具时间确定性。但外部因素——如缓存命中率变化、DMA总线仲裁、中断优先级反转——仍可能导致执行时间波动。
核心权衡关系：在Cortex-M上，延迟、吞吐量和确定性构成一个“不可能三角”。追求极低延迟（如电机控制中的10μs响应）往往需要专用硬件加速器，牺牲吞吐量；追求高吞吐量（如连续振动采样分析）则可能引入批处理，增加延迟；而严格确定性（如安全气囊触发）通常要求禁用缓存、关闭中断，这会降低平均性能。设计者必须根据应用场景明确优先级。
3.2 判断方法：硬实时与软实时的判定标准与设计策略
区分硬实时与软实时，不能仅凭“应用是否重要”来主观判断，而应基于错过截止时间的后果严重性和系统对时间违约的容忍度两个维度进行量化评估。以下是工程实践中常用的判定流程：
- 后果分析：如果推理结果晚到，是否会导致设备损坏、人身伤害或不可逆的系统故障？若是，则属于硬实时范畴。例如，电机控制中的堵转检测推理若延迟超过1ms，可能导致功率管烧毁。
- 数据新鲜度要求：推理所基于的输入数据是否有“有效期”？如果传感器数据在10ms后即失效，而推理结果在15ms后才产出，则该结果已无意义。这种场景通常需要硬实时保证。
- 降级策略可行性：当推理超时时，系统是否可以采用备用方案（如使用上一帧结果、降低控制增益）？如果存在可接受的降级路径，则可能归类为软实时。
- 统计特性要求：硬实时要求最坏情况执行时间（WCET）必须小于截止时间，且需通过静态分析或测量验证；软实时则只需满足统计性要求，如99%的推理在截止时间内完成即可。
| 对比维度 | 硬实时（Hard Real-Time） | 软实时（Soft Real-Time） |
|---|---|---|
| 截止时间违约后果 | 灾难性：系统失效、安全风险 | 非灾难性：性能下降、体验受损 |
| 时间保证方式 | 静态WCET分析 + 资源预留 | 统计性保证（如P99延迟） |
| 中断处理策略 | 优先级天花板/立即响应 | 可延迟处理，允许排队 |
| 缓存/DMA使用 | 谨慎使用，需锁缓存或禁用 | 可正常使用，允许抖动 |
| 典型验证方法 | 形式化验证 + 最坏情况测试 | 压力测试 + 长时运行监控 |
| Cortex-M实现要点 | 关闭分支预测、使用确定性内存 | 合理配置中断优先级即可 |
在Cortex-M上实现硬实时推理，需要采用资源预留策略：为推理任务分配独占的定时器、专用的DMA通道，并设置最高的中断优先级。同时，推理代码应避免使用动态内存分配（malloc），因为堆管理的不确定性会破坏时间可预测性。对于软实时系统，则可以通过RTOS的任务调度（如固定优先级抢占式调度）来满足统计性延迟要求。
3.3 案例拆解：工业振动监测中的软实时推理与电机堵转检测中的硬实时推理
为了更具体地说明上述概念，我们分析两个在Cortex-M7（主频400MHz）上运行的典型场景。
案例A：工业振动监测（软实时）
背景与约束：一条自动化产线的减速机需要持续监测轴承振动。系统使用ADXL345加速度计（采样率3.2kHz），每次采集256个样本后执行一次1D CNN推理，判断轴承是否出现早期点蚀。要求：推理结果延迟不超过50ms，吞吐量不低于20次/秒，允许偶尔（<1%）的延迟超限。
初始指标：在裸机环境下，DMA传输256个样本（16位，3轴）耗时约0.8ms；CMSIS-NN优化的1D CNN推理耗时约4.2ms；后处理（阈值比较+特征提取）约0.3ms。端到端延迟约5.3ms，远低于50ms要求。但系统还需每10ms处理一次CAN通信中断（耗时0.2ms），每100ms处理一次LED刷新。
分析判断：由于延迟余量充足，该场景属于典型的软实时。设计重点转向吞吐量优化和抖动控制。通过将推理任务放在RTOS的独立任务中，优先级设为略高于CAN通信，可以保证推理不会被通信中断频繁抢占。
实际操作：使用FreeRTOS创建三个任务：采集任务（优先级3）、推理任务（优先级2）、通信任务（优先级1）。推理任务等待信号量，采集任务在DMA完成中断中释放信号量。实测结果：平均推理延迟5.4ms，P99延迟6.1ms，最大延迟7.8ms（发生在CAN总线错误帧处理时），吞吐量达到185次/秒，完全满足要求。
风险与代价：由于使用了RTOS，任务切换增加了约0.1ms的固定开销。但换来的好处是代码模块化程度提高，且未来增加新功能时不会影响推理时序。
案例B：电机堵转检测（硬实时）
背景与约束：伺服驱动器的电流环需要实时检测电机堵转。当电机堵转时，电流急剧上升，必须在1ms内检测到并触发保护动作（关断PWM输出）。系统使用Cortex-M4（168MHz），电流采样频率20kHz，每次采样后需执行一个轻量级神经网络（3层全连接，输入特征为最近8次电流值）判断是否堵转。
初始指标：单次推理计算量约1200次乘加运算，使用CMSIS-DSP的矩阵函数耗时约35μs。但系统还运行着FOC（磁场定向控制）算法，占用CPU约60%时间。若推理任务与FOC共享CPU，最坏情况下推理延迟可能达到200μs以上，加上中断响应时间，总延迟可能超过1ms。
分析判断：这是典型的硬实时场景。必须保证最坏情况延迟<1ms。由于FOC算法本身也是硬实时任务，两者不能互相阻塞。
实际操作：采用双缓冲策略——FOC使用定时器PWM中断驱动，推理任务使用独立的ADC注入通道触发。将推理任务的中断优先级设为高于FOC（但低于PWM故障保护）。推理代码全部使用静态内存分配，并锁定D-Cache（如果Cortex-M7）。关键优化：将神经网络权重存储在TCM（紧耦合内存）中，避免总线竞争。实测最坏情况延迟：ADC采样完成到推理输出为820μs，满足1ms要求。
复盘经验：硬实时系统的验证不能只测平均延迟，必须通过逻辑分析仪记录长时间运行中的最大延迟。该案例中，通过注入CAN总线错误帧和外部干扰，确认了最坏情况下的延迟边界。
常见误区警示：很多开发者将“CPU主频高”等同于“实时性好”。实际上，Cortex-M7虽然主频高，但其带有缓存和分支预测，时间确定性反而不如无缓存的Cortex-M0+。对于硬实时推理，选择M0+配合专用NPU（如Ethos-U55）往往比单纯提高主频更有效。
3.4 常见误区与总结复盘
在Cortex-M实时推理设计中，以下误区需要特别警惕：
- 误区一：将平均延迟当作设计指标。实时系统关注的是最坏情况延迟。一个平均延迟5ms但偶尔飙升至50ms的系统，在硬实时场景中是不可接受的。必须使用WCET分析工具（如aiT）或长时间示波器测量来获取真实的最坏情况。
- 误区二：忽视中断对推理时序的破坏。即使推理本身很快，频繁的中断（如UART接收、定时器）也会导致推理被反复抢占，实际完成时间远超预期。解决方法是使用中断优先级分组，将推理任务置于高优先级组，或使用DMA+轮询方式减少中断频率。
- 误区三：混淆吞吐量与延迟。在流水线设计中，高吞吐量并不意味着低延迟。例如，一个推理加速器可能每2ms产出一个结果（吞吐量500次/秒），但单个推理从输入到输出的延迟可能是10ms（因为内部有5级流水线）。对于交互式应用，延迟比吞吐量更重要。
- 误区四：在硬实时系统中使用RTOS的默认配置。大多数RTOS的定时器节拍（Tick）为1ms，这本身就会引入最多1ms的调度延迟。硬实时系统应将Tick设为0.1ms或使用事件驱动调度。
总结复盘：实时推理的本质是在确定的时间内，用确定的结果，完成确定的任务。在Cortex-M平台上，这意味着设计者必须从系统层面（而非仅算法层面）进行时间分析。关键行动清单如下：
- 明确应用属于硬实时还是软实时，并据此设定设计目标。
- 测量并记录推理各阶段（采集、预处理、推理、后处理）的延迟分布。
- 识别系统中的所有中断源，评估其对推理任务的最坏抢占时间。
- 对于硬实时系统，使用静态内存分配、禁用缓存或锁定关键代码到TCM。
- 使用逻辑分析仪或硬件跟踪（ETM）验证最坏情况延迟，而非仅依赖软件计时器。
- 在系统集成测试中，注入外部干扰（如总线错误、电源抖动）来验证时间鲁棒性。