内存层次与预算：MCU内存层次（Flash、SRAM、Cache）、静态内存与动态内存、内存预算的制定方法

TinyML 模型部署到 MCU 上，最核心的约束并非算力，而是内存容量与带宽。与 PC 或服务器端动辄数 GB 的内存不同，一颗典型的 Arm Cortex-M 系列 MCU 可能仅有 512KB Flash 和 128KB SRAM，甚至更低。在这样的资源约束下，模型权重、中间特征图、运行时缓冲区以及操作系统/驱动开销必须精打细算。本章将深入剖析 MCU 的内存层次结构，厘清静态内存与动态内存的本质区别，并给出可落地的内存预算制定方法，帮助你在项目启动阶段就建立清晰的内存地图。

MCU 内存层次与预算制定流程 Flash（非易失） 模型权重（常量） 代码段 .text 只读数据 .rodata 容量：256KB ~ 2MB 读取速度：~30ns（直接映射） SRAM（易失） 中间特征图（激活值） 运行时缓冲区（Tensor Arena） 栈 + 堆 + 全局变量 容量：64KB ~ 512KB 读写速度：~5ns（零等待） Cache（可选） Cortex-M7/M33 可选 指令缓存（I-Cache） 数据缓存（D-Cache） 容量：4KB ~ 64KB 需处理一致性（DMA） 加载 缓存 内存预算制定流程 ① 模型结构分析 算子类型/张量维度 ② 内存占用估算 权重+激活+缓冲区 ③ 优化策略选择 量化/剪枝/内存复用 ④ 验证与调优 实测/Profiling/迭代 关键原则： • Flash 决定模型容量上限（权重+代码），SRAM 决定运行时峰值（激活+缓冲区） • 静态内存预分配避免碎片，动态内存需谨慎管理（TFLite Micro 的 Tensor Arena） • 延迟预算与内存占用呈反比关系：内存复用越激进，计算延迟越高

4.1 MCU 内存层次：Flash、SRAM 与 Cache 的协同

理解 MCU 内存层次是制定预算的前提。与 PC 的复杂多级缓存体系不同，MCU 的内存层次相对简洁，但每一层都有其独特的物理特性和访问成本。

核心原理：三种存储介质的角色分工

Flash（非易失性存储）是 MCU 的"硬盘"，用于存放程序代码（.text 段）、只读常量（.rodata 段）以及经过量化后的模型权重。其特点是断电不丢失，但写入速度慢（擦除以扇区为单位），读取速度受限于 Flash 接口频率（通常为 24~48MHz，即约 20~40ns 的随机读取时间）。在 TinyML 场景中，Flash 的主要压力来自模型权重：一个 100KB 的模型在 512KB Flash 的 MCU 上就占据了近 20% 的空间。

SRAM（静态随机存取存储器）是 MCU 的"内存条"，用于存放全局变量、栈、堆以及模型推理时的中间特征图（激活值）。SRAM 的访问速度极快（零等待周期），但容量通常只有 Flash 的 1/4 到 1/8。例如 STM32F746 拥有 1MB Flash 和 320KB SRAM。SRAM 是 TinyML 推理过程中最稀缺的资源，因为中间特征图的大小往往远超权重本身——一个 224x224x3 的输入图像在 Float32 下就需要 600KB，这直接决定了必须使用量化模型或更小的输入尺寸。

Cache（高速缓存）并非所有 MCU 都具备。Cortex-M7 和部分 Cortex-M33 内核集成了可配置的 I-Cache 和 D-Cache（通常 4KB~64KB）。Cache 的作用是缓存 Flash 或外部存储器的数据，减少 CPU 等待时间。但在 TinyML 场景中，Cache 的收益有限：因为模型推理是顺序访问权重和特征图的，空间局部性较好但时间局部性差，Cache 命中率可能并不理想。更关键的是，D-Cache 与 DMA 之间存在一致性问题——如果 DMA 将数据写入 SRAM 而 CPU 通过 Cache 读取，可能读到脏数据，必须进行 Cache 清理或无效化操作。

存储层次容量典型范围访问速度断电保持TinyML 主要用途成本/功耗
Flash256KB ~ 2MB~30ns（随机）是模型权重、代码、常量表低
SRAM64KB ~ 512KB~5ns（零等待）否中间特征图、Tensor Arena、栈中
Cache4KB ~ 64KB（可选）~2ns（命中）否加速 Flash 代码/数据读取低（但需一致性处理）
关键认知：Flash 决定你的模型能装多大，SRAM 决定你的模型能跑多快（或能否跑起来）。在预算制定时，必须将两者分开评估——一个 300KB 的模型可能轻松放入 1MB Flash，但如果推理时需要 200KB 的中间缓冲区，而 SRAM 只有 128KB，则模型无法运行。

判断方法：如何评估你的 MCU 内存层次是否够用

在项目选型阶段，可以通过以下三步快速判断：

  1. 计算模型权重体积：将模型参数量乘以量化位宽（如 Int8 为 1 字节/参数，Float32 为 4 字节/参数），加上约 10% 的元数据开销。
  2. 估算峰值激活内存：找出模型中最大的中间特征图（通常是第一个卷积层的输出或全连接层的输入），乘以位宽。例如 32x32x16 的 Int8 特征图需要 16KB。
  3. 叠加运行时开销：加上栈空间（通常 2~4KB）、全局变量（1~2KB）、Tensor Arena 的额外管理开销（约 1KB）。

如果上述总和超过 SRAM 容量的 80%，就需要考虑模型压缩或内存复用策略。

4.2 静态内存与动态内存：TinyML 中的内存管理哲学

在嵌入式系统中，内存管理方式直接决定了系统的稳定性和可预测性。TinyML 框架（如 TensorFlow Lite Micro）普遍采用静态内存分配策略，这与传统嵌入式开发中谨慎使用 malloc/free 的理念一脉相承。

核心原理：静态 vs 动态的本质差异

静态内存在编译期就确定了大小和地址，通常表现为全局数组或静态变量。在 TinyML 中，最典型的静态内存应用是 Tensor Arena——一个预先分配好的大缓冲区，所有中间张量都在这个 Arena 中通过内存池的方式分配和释放。这种方式的优势是：无碎片、分配时间恒定（O(1)）、内存使用可预测。缺点是：Arena 大小必须预先设定，如果设置过小则推理失败，设置过大则浪费 SRAM。

动态内存（malloc/free）在运行时从堆中分配。虽然灵活，但存在三个致命问题：一是碎片化——频繁分配释放会导致内存碎片，最终即使总空闲内存足够也无法分配大块连续内存；二是不可预测性——分配时间不确定，可能触发系统调度延迟；三是安全风险——内存泄漏或越界可能导致系统崩溃。在 TinyML 推理这种对实时性和稳定性要求极高的场景中，动态内存几乎不被使用。

风险提示：即使你的 MCU 支持动态内存（如 FreeRTOS 的 heap_4），也强烈建议在 TinyML 推理路径中禁用 malloc。一次意外的内存分配失败可能导致整个推理任务失败，且难以调试。TFLite Micro 的 MicroAllocator 就是专门为静态内存管理设计的。

操作流程：Tensor Arena 的配置与使用

以 TensorFlow Lite Micro 为例，内存预算的落地过程如下：

// 定义 Tensor Arena 大小（根据模型需求调整）
static uint8_t tensor_arena[128 * 1024]; // 128KB

// 初始化解释器
static tflite::MicroErrorReporter micro_error_reporter;
tflite::ErrorReporter* error_reporter = &micro_error_reporter;
const tflite::Model* model = tflite::GetModel(g_model);
tflite::MicroInterpreter interpreter(
    model, resolver, tensor_arena, sizeof(tensor_arena), error_reporter);

// 分配张量内存（在 Arena 内部分配）
TfLiteStatus allocate_status = interpreter.AllocateTensors();
if (allocate_status != kTfLiteOk) {
    // 处理内存不足错误
    return -1;
}

// 获取输入/输出张量指针
TfLiteTensor* input = interpreter.input(0);
TfLiteTensor* output = interpreter.output(0);

关键点在于 AllocateTensors() 调用时，框架会分析模型的计算图，为每个中间张量在 Arena 中分配内存。如果 Arena 过小，此调用会返回错误。因此，内存预算的核心工作就是确定这个 Arena 的合理大小。

案例拆解：一个 300KB 模型的 SRAM 预算实战

假设我们有一个 MobileNetV1 风格的图像分类模型，输入为 96x96x3，经过 Int8 量化后权重为 300KB。目标 MCU 为 STM32F746（1MB Flash，320KB SRAM）。

初始现象：直接使用默认的 128KB Tensor Arena 运行，发现 AllocateTensors() 返回错误，提示内存不足。

分析过程：通过打印 Arena 使用量（interpreter.arena_used_bytes()），发现实际需要 180KB。原因在于第一个卷积层输出为 48x48x32（Int8），需要 73KB；后续层虽然逐渐减小，但峰值出现在第 2 个卷积层（24x24x64 = 36KB）与第 3 层（12x12x128 = 18KB）的叠加。此外，框架还需要额外的 2KB 用于张量元数据。

优化操作：

  1. 将输入尺寸从 96x96 降至 64x64，峰值激活内存降至约 80KB。
  2. 启用内存复用（TFLite Micro 默认支持，但需确认算子支持 in-place 操作）。
  3. 将 Tensor Arena 调整为 96KB，并预留 4KB 余量。

结果对比：优化后 Arena 使用量为 92KB，总 SRAM 占用（Arena + 栈 + 全局）约 100KB，在 320KB SRAM 中占比 31%，留有充足余量。推理延迟从 180ms 降至 120ms（因为输入尺寸减小）。

复盘经验：内存预算不是一次性的，而是与模型结构、输入尺寸、量化方案强耦合的迭代过程。建议在项目初期就建立内存 Profiling 工具链，每次模型变更后自动检查内存占用。

4.3 内存预算的制定方法：从估算到验证的闭环

内存预算不是简单的加减法，而是一个需要结合模型结构、硬件特性、延迟要求进行综合权衡的系统工程。以下是一套经过验证的预算制定流程。

核心原理：预算的四个维度

一个完整的内存预算需要覆盖四个维度：权重存储（Flash）、激活内存（SRAM）、运行时开销（SRAM）、代码体积（Flash）。其中，激活内存是最难估算的部分，因为它取决于模型的计算图拓扑和内存复用策略。

预算维度存储位置估算方法优化手段
模型权重Flash参数量 × 量化位宽 + 10% 元数据量化（Int8/Int4）、剪枝、权重共享
激活内存SRAM计算图中最大活跃张量集之和内存复用、减少通道数、降低输入分辨率
运行时开销SRAM栈（2~4KB）+ 全局变量（1~2KB）+ Arena 管理（1KB）精简 RTOS 配置、使用静态分配
代码体积Flash编译后 .text 段大小（通常 50~200KB）编译器优化（-Os）、裁剪无用算子

操作流程：五步制定内存预算

  1. 模型结构分析：使用 Netron 或框架工具导出模型结构，列出所有算子的输入/输出张量维度。
  2. 峰值内存计算：模拟推理过程，记录每个时间点活跃的张量集合，找出最大活跃集。可使用 TFLite 的 arena_used_bytes() 或手动计算。
  3. 硬件约束匹配：将估算结果与 MCU 的 Flash/SRAM 容量对比，确定是否满足。若不满足，进入优化循环。
  4. 优化策略选择：优先考虑量化（Int8 可减少 75% 权重和激活内存），其次考虑输入尺寸调整，最后考虑模型结构替换（如 MobileNet 替换为 EfficientNet-Lite）。
  5. 实测验证：在目标硬件上运行，使用调试器读取实际内存占用（如 Keil 的 Memory Window 或 IAR 的 Live Watch），与预算对比，误差应控制在 10% 以内。
经验之谈：在预算中预留 15%~20% 的 SRAM 余量。原因有三：一是调试时可能需要额外的日志缓冲区；二是未来模型迭代可能增加内存需求；三是某些 MCU 的 SRAM 存在访问冲突（如同时被 DMA 和 CPU 访问），预留空间可降低风险。

常见误区与总结复盘

误区一：只关注权重大小，忽略激活内存。很多开发者认为模型 300KB，MCU 有 1MB Flash 就足够了，却忽略了推理时可能需要 200KB 的 SRAM。实际上，激活内存往往是 TinyML 部署失败的首要原因。

误区二：盲目使用动态内存。在 PC 上习惯使用 vector 或 new 的开发者，在 MCU 上容易犯此错误。一次 malloc 失败或碎片化就可能导致系统崩溃。

误区三：忽视 Cache 一致性问题。如果 MCU 有 D-Cache，且推理过程中使用了 DMA 搬运数据（如从外部 Flash 加载权重），必须确保在 DMA 写入后执行 Cache 清理操作，否则会读到脏数据。

误区四：内存预算与延迟预算割裂。激进的内存复用（如 in-place 操作）会降低内存占用，但可能增加计算延迟（因为需要额外的数据搬移）。例如，将 Conv2D 的输入和输出放在同一块内存时，可能需要先复制部分数据，导致延迟增加 10%~20%。

总结复盘：内存预算是一个动态平衡的过程。建议在项目启动时建立一份"内存预算表"，记录每个模块的估算值、实际值、优化措施和负责人。每次模型或硬件变更时，更新此表并重新验证。通过这种闭环管理，可以确保 TinyML 项目在资源受限的 MCU 上稳定运行，同时为后续迭代留出空间。

← 上一章 📖 返回目录 下一章 →