2、MCU端侧推理基础：MCU资源限制、典型推理框架（TFLite Micro、CMSIS-NN等）与栈使用特点

MCU（微控制器）端侧推理与服务器端或移动端AI推理有本质差异。MCU通常集成CPU、Flash、SRAM于单芯片，资源以KB为单位计量，无操作系统或仅运行RTOS，缺乏虚拟内存管理。理解MCU的资源边界、推理框架的调度方式以及栈（Stack）在推理过程中的行为，是进行峰值栈测量与裁剪的前提。本章将系统梳理MCU的资源限制、主流推理框架（TFLite Micro、CMSIS-NN）的架构特点，并深入分析栈在推理过程中的使用规律。

2.1 MCU资源限制：为什么栈是稀缺资源

MCU的典型资源规模决定了端侧推理的实现方式。以ARM Cortex-M系列为例，常见的STM32F4系列拥有128KB~1MB Flash、64KB~256KB SRAM，主频在168MHz~480MHz之间。而更小型的Cortex-M0+（如STM32G0）仅有16~64KB Flash、6~32KB SRAM。这些资源限制直接影响了推理框架的设计和栈的使用方式。

核心原理：MCU没有MMU（内存管理单元），所有内存访问都是物理地址直接映射。这意味着：

• 栈溢出不可恢复：栈指针越过栈底会直接写入相邻内存区域（通常是全局变量或堆），导致数据损坏或HardFault，系统无法像Linux那样通过缺页异常来扩展栈。
• 栈大小需静态确定：由于没有虚拟内存，栈空间必须在链接脚本中静态分配，且无法在运行时动态增长。开发者必须在编译期就确定栈的最大需求。
• SRAM总量有限：模型权重通常放在Flash中（只读），但激活值、中间缓冲区、算子临时数据必须放在SRAM中。一个典型的1D卷积模型，若输入为128个float32数据，第一层卷积核为3x3，激活缓冲区就需要128×4=512字节，加上中间结果，SRAM消耗迅速增长。

2.2 典型推理框架：TFLite Micro与CMSIS-NN的架构差异

MCU端推理框架主要分为两类：解释器型（如TFLite Micro）和库函数型（如CMSIS-NN）。两者的栈使用模式截然不同。

2.2.1 TFLite Micro：解释器模式

TFLite Micro采用解释器架构，模型被序列化为FlatBuffer格式，运行时由解释器逐层解析并调用对应的算子内核。其调用链为：

应用层调用 → tflite::MicroInterpreter::Invoke()
  → 遍历算子列表
    → 调用每个算子的Eval函数（如ConvEval）
      → 调用TFLM注册的kernel函数
        → 调用CMSIS-NN或参考实现

这种多层嵌套调用导致栈深度较大。每个调用帧包含返回地址、保存的寄存器、局部变量。在Cortex-M4上，一个函数帧通常占用32~64字节。若嵌套深度为6~8层，仅函数调用帧就需要200~500字节栈空间。

TFLite Micro的内存规划器（MemoryPlanner）负责在SRAM中分配张量缓冲区，但算子内部的临时变量（如im2col缓冲区、局部数组）仍然占用栈空间。例如，某些卷积实现会在栈上声明一个临时数组用于数据重排：

// 伪代码示例：栈上临时数组
void ConvEval(...) {
  int8_t temp_buffer[64];  // 64字节栈空间
  // ... 处理逻辑
}

2.2.2 CMSIS-NN：库函数模式

CMSIS-NN是ARM提供的优化算子库，直接以C函数形式提供卷积、池化、全连接等操作。它没有解释器，应用层直接调用算子函数。调用链为：

应用层调用 → arm_convolve_s8()
  → arm_convolve_s8_kernel3x3()
    → 内部循环处理

这种模式的栈深度较浅（通常3~4层），但CMSIS-NN的部分算子为了性能优化，会在栈上分配较大的临时缓冲区。例如，某些矩阵乘法实现会使用分块策略，在栈上声明16x16的int16_t块（512字节）。

2.3 栈使用特点：峰值如何产生

栈峰值（Stack Peak）是指程序执行过程中栈指针达到的最低地址（对于满递减栈）。在推理过程中，栈峰值通常出现在最大嵌套路径上，即所有调用帧和局部变量之和最大的时刻。

判断方法：要准确测量栈峰值，需要理解以下三个关键因素：

1. 调用路径：推理过程中最深的函数调用链是什么？例如，TFLite Micro的Invoke() → 算子Eval → 内核实现 → CMSIS-NN优化函数，这条路径上的每一层都会增加栈占用。
2. 局部变量大小：每个函数内部声明的局部变量（特别是数组）会占用栈空间。一个int8_t buffer[128]就占用128字节。
3. 中断嵌套：如果推理过程中发生中断，中断服务程序（ISR）会使用独立的栈（或共享栈）。若共享栈，ISR的栈使用必须计入峰值。

2.4 案例拆解：一个典型CNN模型的栈使用分析

假设我们有一个基于Cortex-M4F的MCU，运行TFLite Micro框架，模型为一个3层卷积神经网络（输入128x1x1，卷积核3x3，输出32通道）。我们分析其栈使用情况。

初始现象：系统在推理过程中偶尔出现HardFault，且复位后无法复现。通过调试器观察，发现栈指针在推理过程中接近栈底。

关键参数：

• 栈总大小：2048字节（链接脚本中分配）
• TFLite Micro解释器：Invoke()调用帧约48字节
• ConvEval函数：约64字节（含局部变量）
• CMSIS-NN arm_convolve_s8：约128字节（含临时缓冲区指针）
• 内部kernel函数：约96字节

分析过程：

栈占用估算：
Invoke()         48字节
  → ConvEval     64字节
    → arm_convolve_s8  128字节
      → kernel   96字节
      → 内部临时数组 int8_t buf[128]  128字节
      → 循环变量+地址寄存器  32字节
------------------------------------------
合计：约496字节（单层卷积）
3层卷积嵌套：496 × 3 = 1488字节（若逐层调用）
加上中断开销（假设ISR使用128字节）：
峰值栈 = 1488 + 128 = 1616字节

实际测量发现，栈峰值达到1780字节，接近2048字节的栈底。通过栈水印填充法（在栈底填充0xAA模式，周期性检查），确认峰值出现在第二层卷积的kernel函数中。

优化操作：

1. 将kernel函数中的临时数组从栈上移到静态缓冲区（static int8_t buf[128]），减少128字节栈占用。
2. 将TFLite Micro的Invoke()调用改为直接调用算子（绕过解释器），减少48字节调用帧。
3. 将中断栈与主栈分离，分配独立256字节中断栈，避免ISR占用主栈。

结果对比：优化后栈峰值降至约1100字节，系统稳定运行，HardFault消失。代价是静态缓冲区占用了128字节SRAM，且代码可移植性略有下降。

2.5 常见误区与总结

在MCU端侧推理的栈使用中，以下误区需要特别注意：

• 误区一：认为栈大小与模型大小成正比。实际上，模型权重存储在Flash中，不占用栈。栈只与代码执行路径和局部变量相关。
• 误区二：忽略编译器优化对栈的影响。不同优化级别（-O0 vs -O2）下，栈使用可能相差30%~50%。测量栈峰值必须在最终发布优化级别下进行。
• 误区三：将所有临时数据都放在栈上。对于较大的缓冲区（>64字节），应考虑使用静态分配或堆分配，但堆分配可能引入碎片问题，需权衡。
• 误区四：不区分主栈和中断栈。在RTOS环境中，每个任务有独立栈，中断使用系统栈。推理任务栈和中断栈必须分别测量。