MCU与Edge AI基础：硬件架构与推理框架全景
在深入排查MCU端侧推理内存占用之前，必须先建立对硬件底座的清晰认知。MCU（微控制器）与PC或服务器端的CPU/GPU在设计哲学上截然不同：它追求的是在极低功耗、极低成本与确定性实时响应之间取得平衡。本章将拆解MCU的存储与计算架构，对比主流Edge AI芯片的选型逻辑，并梳理TFLite Micro、CMSIS-NN、Glow等推理框架的适配原理，为后续内存排查提供“硬件-软件”映射的坐标系。
MCU架构核心：Flash、SRAM与总线瓶颈
MCU的存储架构直接决定了AI模型能否部署以及如何优化。与PC的冯·诺依曼或哈佛架构不同，绝大多数MCU采用改进型哈佛架构，即指令总线与数据总线物理分离，但允许数据存放在Flash中。这意味着：
- Flash（非易失存储）：存放程序代码、常量表、模型权重（若支持XIP，即片上执行）。读取速度慢于SRAM，且写入寿命有限（通常10k~100k次）。在内存排查中，Flash占用对应
.text段、.rodata段以及模型权重数组。 - SRAM（易失存储）：存放全局变量、调用栈、堆（动态分配）以及推理时的中间张量（activation buffer）。SRAM容量是MCU端AI最稀缺的资源，通常仅为Flash的1/4到1/8。
- 总线矩阵与DMA：CPU通过AHB/APB总线访问外设和内存。当DMA与外设交互时，会占用总线带宽，影响CPU从Flash取指的速度，进而影响推理延迟。
.bss（未初始化全局变量）、.data（已初始化全局变量）以及堆栈的使用峰值。许多工程师只关注Flash剩余空间，却忽略了SRAM溢出导致的HardFault。
典型Edge AI芯片选型对比
不同MCU在AI能力上的差异主要体现在：是否有FPU（浮点单元）、是否有DSP指令、是否集成NPU或向量扩展。下表对比了四款主流芯片的关键参数：
| 芯片型号 | 内核 | Flash | SRAM | AI加速特性 | 典型应用场景 |
|---|---|---|---|---|---|
| STM32F746 | Cortex-M7 @216MHz | 1MB | 320KB | 双精度FPU，无NPU | 工业视觉、音频分类 |
| ESP32-S3 | Xtensa LX7 @240MHz | 8MB (外部) | 512KB | 向量指令 (PIE) | 智能家居、语音唤醒 |
| RP2040 | Cortex-M0+ @133MHz | 2MB (外部) | 264KB | 无FPU，无DSP | 教育、简单传感器分类 |
| MAX78000 | Cortex-M4F + CNN加速器 | 3MB | 512KB | 硬件CNN引擎 | 电池供电的视觉唤醒 |
选型时需注意：FPU能加速浮点运算，但会显著增加SRAM中栈的消耗（因为浮点寄存器上下文保存）。而NPU虽然推理快，但通常要求权重以特定格式存放，且中间结果可能无法直接访问，这给内存排查带来新的复杂度。
推理框架的内存管理哲学
推理框架决定了模型在MCU上如何被解析和执行，其内存策略分为两大流派：
- 解释型框架（TFLite Micro）：运行时解析模型结构，通过
tflite::MicroInterpreter动态规划张量内存。它使用“内存池”预分配机制，在初始化时计算所有中间张量的内存布局，避免运行时的malloc。排查重点在于arena_size的设置是否足够。 - 静态编译型框架（Glow/TVM）：在编译期将模型转换为C代码，所有张量在编译时确定地址，生成
static数组。这种方式内存占用最可预测，但灵活性差，模型结构变化需重新编译。
案例拆解：ESP32-S3部署关键词唤醒模型
背景与约束：某智能家居产品需在ESP32-S3上部署一个20KB的语音唤醒模型（基于DS-CNN），要求推理延迟小于50ms，且不能影响蓝牙音频播放的实时性。初始方案直接使用TFLite Micro默认配置，结果设备在唤醒后出现音频卡顿。
初始现象与排查：通过heap_caps_get_free_size()打印发现，推理期间SRAM剩余不足10KB，而蓝牙音频栈需要至少15KB的连续缓冲区。进一步分析MicroInterpreter的arena分配，发现默认的tensor_arena_size设为40KB，但实际模型中间张量峰值仅需18KB。
分析判断：问题不在于模型本身，而在于框架为所有算子预留了最大可能的内存，且未考虑音频DMA缓冲区的连续性要求。ESP32-S3的SRAM分为内部和外部（PSRAM），TFLite Micro默认使用内部SRAM，导致内部SRAM耗尽。
操作步骤：
- 将
tensor_arena从40KB缩减至20KB，并启用TF_LITE_STATIC_MEMORY宏，强制使用静态内存规划。 - 将音频DMA缓冲区迁移至PSRAM（通过
heap_caps_malloc指定MALLOC_CAP_SPIRAM），释放内部SRAM。 - 在
model_settings.h中调整输入特征图大小，将MFCC特征从40维降至20维，减少第一层卷积的输入通道。
结果对比：优化后，推理期间内部SRAM剩余28KB，音频卡顿消失，延迟从45ms降至38ms。但代价是模型精度从97.2%降至96.5%，在可接受范围内。
复盘经验：MCU端内存排查不能只看模型大小，必须结合外设DMA、协议栈、RTOS任务栈等系统级内存消费者。框架的arena大小并非越大越好，过大的arena会挤压其他关键任务的空间。
常见误区与总结
- 误区一：只关注Flash剩余，忽略SRAM峰值。模型权重可以放Flash，但中间激活值必须放SRAM。一个100KB的模型可能需要200KB的SRAM来跑推理。
- 误区二：认为所有框架都支持动态形状。TFLite Micro要求所有输入维度在初始化时固定，动态输入会导致内存规划失败。
- 误区三：忽略对齐问题。CMSIS-NN要求张量数据按4字节或16字节对齐，否则会触发HardFault或性能骤降。排查时需检查
__ALIGNED属性。 - 误区四：混淆Flash与SRAM的读写速度。频繁从Flash读取权重会拖慢推理，可考虑将部分权重预加载到SRAM，但需权衡SRAM占用。
理解MCU的硬件边界与框架的内存策略，是进行内存占用排查的前提。下一层级的排查将聚焦于具体工具链（如arm-none-eabi-size、map文件分析）和运行时监控手段，但所有分析都必须回归到本章所述的“Flash存模型、SRAM跑数据、总线定延迟”这一基本物理约束上。