3、TFLite Micro内存架构：Tensor Arena、Model Arena与算子缓冲区

TFLite Micro 的嵌入式部署与标准 TFLite 的最大差异在于内存管理策略。在 PC 或移动端，框架可以依赖操作系统动态分配内存，但在 MCU 上，没有 MMU、没有完整的堆管理，甚至有些平台禁止使用 malloc。因此，TFLite Micro 采用“预分配 + 静态规划”的内存架构，将模型权重、中间张量、算子临时数据全部纳入几个固定区域。理解这些区域（Tensor Arena、Model Arena、算子缓冲区）的边界与默认分配策略，是使用 PSRAM 或 SDRAM 扩展外部存储时的第一道风险关口。

TFLite Micro 内存区域划分与默认分配策略 Model Arena (模型权重/常量数据) 权重张量 (Weight) 只读，不可修改 偏置/量化参数 随模型打包 嵌入查找表 (LUT) 激活函数查表 默认：Flash/只读区 可重定位至 PSRAM Tensor Arena (中间张量/激活值) 输入/输出张量 固定地址，可被算子复用 中间激活值 生命周期短，频繁读写 临时缓冲区 算子间共享 默认：内部 RAM 可部分移至 PSRAM 算子缓冲区 (OpData/Scratch) 算子参数 (OpData) 量化/缩放因子 Scratch Buffer 算子内部临时存储 内核工作区 如 im2col 缓冲区 默认：Tensor Arena 内 或独立静态分配 只读 读写 默认策略：Model Arena 放 Flash，Tensor Arena 放内部 RAM，算子缓冲区从 Tensor Arena 划拨

上图展示了 TFLite Micro 运行时三大内存区域的典型布局。需要特别强调的是，Tensor Arena 是唯一在推理过程中被频繁读写的区域，而 Model Arena 在加载后几乎不再变化。这种“静态权重 + 动态激活”的分离设计，使得外部存储扩展时可以有明确的优先级：先考虑将 Model Arena 迁移到 PSRAM/SDRAM，再谨慎评估 Tensor Arena 的迁移风险。

3.1 核心原理：三大内存区域的职责边界

TFLite Micro 的内存规划并非随意划分，而是基于模型执行的生命周期和硬件访问特性。理解每个区域的本质，才能判断哪些数据可以安全地放到外部存储。

3.1.1 Model Arena：只读权重与不可变数据

Model Arena 存储的是模型转换后生成的权重张量、偏置项、量化参数（scale/zero_point）、嵌入查找表等。这些数据在模型编译时已经确定，推理过程中不会被修改。默认情况下，TFLite Micro 通过 MicroMutableOpResolver 和 Model 对象直接引用 flatbuffer 中的权重指针，这些指针指向的内存区域通常位于 Flash 或只读数据段。

关键特性：

  • 只读性：任何算子都不允许写入 Model Arena 中的数据。
  • 对齐要求：权重张量需要满足特定对齐（如 4 字节或 16 字节），否则部分内核（如 CMSIS-NN）会拒绝执行。
  • 生命周期：从解释器初始化到销毁，整个生命周期内数据必须有效。

当模型较大（如超过 1MB）时，内部 Flash 可能不足，此时将 Model Arena 重定位到 PSRAM 是常见做法。但需要注意，PSRAM 的读取速度通常比内部 Flash 慢 2-5 倍，且部分 MCU 的 PSRAM 控制器不支持缓存，导致每次权重访问都产生总线延迟。

3.1.2 Tensor Arena：动态张量的生命周期管理

Tensor Arena 是 TFLite Micro 内存规划的核心。它负责管理所有中间张量（包括输入、输出、隐藏层激活值）的内存分配。与标准 TFLite 不同，Micro 版本不使用 malloc/free，而是采用内存池 + 复用策略：在解释器初始化时，通过 arena_size 参数指定总大小，然后由 MicroAllocator 在池内进行线性分配。

默认分配策略包含两个阶段：

  1. 静态规划阶段：在 AllocateTensors() 调用时，遍历所有算子，计算每个张量的生命周期（从第一次被写入到最后一次被读取），然后通过图着色算法将不重叠的张量分配到同一块内存。
  2. 动态复用阶段：对于生命周期重叠但类型兼容的张量，允许算子间共享缓冲区。例如，卷积层的输出张量可以直接作为下一个池化层的输入，无需额外拷贝。

Tensor Arena 的默认位置是内部 RAM，因为其访问频率极高。一个典型的 MobileNetV1 模型，Tensor Arena 可能需要 200-500KB，而内部 RAM 往往只有 512KB 或更少。当 Arena 超出内部 RAM 容量时，开发者面临两个选择：缩小模型输入分辨率，或者将部分张量迁移到外部存储。

3.1.3 算子缓冲区：OpData 与 Scratch Buffer

每个算子（如 Conv2D、DepthwiseConv2D）在初始化时都会创建对应的 OpData 结构体，用于存储量化参数、卷积核尺寸、padding 策略等。这些 OpData 通常很小（几十到几百字节），但数量众多。此外，部分算子需要额外的临时工作区，称为 Scratch Buffer，例如 im2col 变换、矩阵转置、FFT 中间结果等。

默认情况下，算子缓冲区从 Tensor Arena 中划拨。TFLite Micro 的 MicroAllocator 会为每个算子预留 OpData 空间，并在执行阶段通过 GetScratchBuffer() 接口动态获取临时内存。这种设计的优点是内存利用率高，但缺点是如果某个算子需要大量 Scratch Buffer（如全连接层的大矩阵乘法），可能会挤压其他张量的可用空间。

内存区域对比表

区域内容默认位置访问频率可迁移至外部存储？
Model Arena权重、偏置、量化参数Flash/只读段低（每层一次）✅ 推荐，风险低
Tensor Arena中间激活值、输入输出张量内部 RAM极高（每个算子）⚠️ 需谨慎，性能影响大
算子缓冲区OpData、Scratch BufferTensor Arena 内中（算子初始化/执行）❌ 不建议，延迟敏感

3.2 判断方法：如何评估内存区域的迁移风险

在决定将哪个区域迁移到 PSRAM/SDRAM 之前，需要从访问频率、数据大小、硬件特性三个维度进行量化评估。以下是一套可操作的判断流程：

3.2.1 访问频率分析

使用 TFLite Micro 的 profiling 工具（如 MicroBenchmark）统计每个内存区域的读写次数。对于 Model Arena，每层推理只读取一次权重；对于 Tensor Arena，每个算子至少读写一次中间张量。如果模型有 50 层，Tensor Arena 的访问次数是 Model Arena 的 50 倍以上。因此，将 Tensor Arena 放在慢速存储上，性能损失会呈线性放大。

3.2.2 数据大小与对齐检查

使用 flatbuffer 工具导出模型的内存占用报告，确认 Model Arena 和 Tensor Arena 的峰值大小。同时检查目标 MCU 的 PSRAM 控制器是否支持非对齐访问。例如，STM32H7 系列的 FMC 接口支持 8/16/32 位访问，但 16 位访问会降低带宽。如果权重是 8 位量化，建议将 PSRAM 配置为 32 位模式，并确保数据起始地址 4 字节对齐。

3.2.3 硬件时序验证

在迁移前，编写一个简单的内存带宽测试程序：分别从内部 RAM 和 PSRAM 读取 1MB 数据，计算耗时。如果 PSRAM 读取速度低于内部 RAM 的 1/3，则不建议将 Tensor Arena 迁移过去。对于 Model Arena，只要 PSRAM 读取速度不低于内部 Flash 的 1/2，通常可以接受。

经验法则：当模型权重 > 1MB 且内部 Flash 不足时，优先迁移 Model Arena 到 PSRAM。只有当 Tensor Arena 超过内部 RAM 的 80% 且无法通过模型压缩解决时，才考虑将部分低频张量（如全连接层输出）迁移到外部存储。

3.3 案例拆解：将 MobileNetV2 部署到 STM32H743 + PSRAM

下面通过一个实际案例，展示如何分析内存区域并制定迁移策略。

3.3.1 背景与约束

目标平台：STM32H743（内部 RAM 512KB，内部 Flash 2MB，外部 PSRAM 8MB，FMC 接口 32 位）。模型：MobileNetV2 1.0，输入 224x224x3，量化后权重约 3.4MB，Tensor Arena 峰值约 1.2MB。初始现象：模型无法加载，因为内部 Flash 只有 2MB，而权重 3.4MB 超出限制。

3.3.2 分析过程

首先，通过 flatbuffer 工具导出模型内存报告：

Model size: 3.4MB
  - Weight tensors: 3.1MB
  - OpData: 120KB
  - Other: 180KB
Tensor Arena required: 1.2MB
  - Input tensor: 150KB (224x224x3)
  - Intermediate activations: 850KB
  - Output tensor: 4KB

内部 Flash 2MB 无法容纳 3.4MB 权重，因此必须将 Model Arena 迁移到 PSRAM。同时，Tensor Arena 的 1.2MB 也超过了内部 RAM 的 512KB，需要进一步处理。

3.3.3 实施步骤

  1. 迁移 Model Arena：在链接脚本中将模型权重段重定位到外部 PSRAM 地址（如 0xD0000000）。修改 MicroMutableOpResolver 的加载方式，使用 Model::CreateFromBuffer() 指向 PSRAM 中的 flatbuffer 数据。
  2. 压缩 Tensor Arena：将输入分辨率从 224x224 降至 160x160，Tensor Arena 峰值降至约 600KB。仍超出 512KB，但通过启用 TF_LITE_STRIP_REFERENCE_IMPL 和优化算子复用，最终降至 480KB。
  3. 部分张量迁移：将最后一个全连接层的输出张量（4KB）和部分低频中间张量（约 50KB）手动分配到 PSRAM。通过修改 MicroAllocator 的自定义分配器，为特定张量指定外部存储地址。

3.3.4 结果与复盘

指标迁移前迁移后变化
模型加载失败（Flash 不足）成功—
推理延迟—85ms基线
PSRAM 带宽占用—3.1MB/推理约 36MB/s
内部 RAM 占用—480KB94%

复盘发现，推理延迟 85ms 中约 30ms 消耗在 PSRAM 权重读取上。如果使用 8 位 FMC 模式，延迟会增加到 120ms。因此，PSRAM 的位宽配置直接影响性能。此外，Tensor Arena 迁移的部分张量虽然只占 50KB，但导致缓存命中率下降，增加了约 5ms 延迟。最终建议：保持 Tensor Arena 全部在内部 RAM，仅迁移 Model Arena。

风险提示：将 Tensor Arena 迁移到 PSRAM 时，必须确保 PSRAM 的访问延迟不会导致算子执行超时。对于实时性要求高的场景（如语音唤醒），建议使用 DMA 双缓冲或 PSRAM 的 memory-mapped 模式，并开启 MPU 的缓存属性。

3.4 常见误区与总结复盘

在实际项目中，开发者对内存区域的理解常存在以下偏差：

  • 误区一：所有内存都可以随意迁移。实际上，算子缓冲区（OpData）与内核实现强耦合，迁移到外部存储可能导致指针访问异常。
  • 误区二：PSRAM 速度足够快。PSRAM 的随机访问延迟通常在 70-100ns，而内部 RAM 只需 10-20ns。对于频繁访问的 Tensor Arena，性能差距可达 5 倍。
  • 误区三：只关注容量，忽略对齐。PSRAM 控制器对非对齐访问会拆分总线事务，导致带宽减半。必须确保所有张量起始地址按 4 字节（或 8 字节）对齐。
  • 误区四：忽略缓存一致性。如果 MCU 带有 D-Cache，且 PSRAM 映射为 cacheable，则需要在每次推理前执行 SCB_CleanDCache()，否则可能读到脏数据。
← 上一章 📖 返回目录 下一章 →