2、TFLite Micro内存基础：理解Tensor Arena、算子中间张量、持久内存和临时内存的分配原理，以及Arena大小估算方法

TFLite Micro 面向的是 Flash 与 RAM 均受限的 MCU 级硬件，其内存管理策略与标准 TFLite 有本质差异。标准 TFLite 依赖操作系统动态分配内存，而 TFLite Micro 在加载模型时便通过一次性的内存规划（Memory Planning），将所有张量数据、算子工作区、中间结果统一放入一个预先分配的连续字节数组——即 Tensor Arena。理解 Arena 的内部结构、分配规则与估算方法，是进行低内存模型改造的前提。本章将拆解 Arena 的组成、分配流程与估算公式，并给出一个完整的案例闭环。

上图展示了 Tensor Arena 的两大核心分区。持久内存区（Persistent Memory）在模型初始化时一次性分配，存放权重、量化参数等不可变数据；临时内存区（Transient Memory）则根据算子执行顺序动态规划，允许不同生命周期的张量复用同一块物理内存。这种设计使得 Arena 总大小远小于所有张量大小之和，但也带来了理解上的复杂性——开发者必须清楚哪些数据占用持久区、哪些占用临时区，以及峰值内存出现在哪个执行阶段。

2.1 核心原理：Arena 的两级分配机制

TFLite Micro 的内存分配并非简单的"按需 malloc"，而是采用 两级规划：第一级在模型加载时完成，第二级在首次推理时完成。这种机制避免了运行时的动态分配开销，也保证了内存使用的确定性。

• 持久内存（Persistent Memory）：由 AllocatePersistentBuffer() 分配，用于存储模型权重、量化参数、算子注册信息等。这些数据从模型加载到卸载始终保持有效，因此分配后不再移动或释放。持久内存的分配策略是"顺序追加"，即每次分配都在当前末尾偏移量上继续，不做碎片整理。
• 临时内存（Transient Memory）：由 AllocateTempBuffer() 分配，用于存储推理过程中的中间张量（如卷积输出、激活值）和算子工作区（如 im2col 缓冲区）。临时内存的分配策略是"生命周期感知复用"——两个张量如果生命周期不重叠，则共享同一块内存区域。

理解两级分配的关键在于：持久内存的大小是静态可计算的，而临时内存的峰值大小取决于计算图的拓扑结构。例如，一个链式网络（A→B→C）的临时内存峰值可能只是最大单层输出的大小，而一个并行分支网络（A→B和A→C同时执行）则可能需要同时容纳多个分支的输出。

2.2 判断方法：如何计算 Arena 大小

估算 Arena 大小是低内存改造的第一步。虽然 TFLite Micro 提供了自动规划工具，但开发者仍需掌握手动估算方法，以便在模型设计阶段预判内存瓶颈。以下是标准估算流程：

1. 列出所有张量：从模型输入开始，遍历计算图，记录每个中间张量的数据类型（float32/int8/uint8）和形状（shape）。
2. 计算每个张量的字节数：字节数 = 各维度乘积 × 数据类型大小。例如，一个 [1, 32, 32, 16] 的 int8 张量占用 1×32×32×16×1 = 16384 字节。
3. 确定生命周期：为每个张量标注"首次使用算子"和"最后使用算子"的索引。生命周期从首次使用开始，到最后一次使用结束。
4. 构建生命周期重叠图：将生命周期重叠的张量分组，每组内取最大张量大小作为该组的临时内存需求。
5. 累加持久内存：将所有权重、偏置、量化参数的大小相加，得到持久内存需求。
6. 加上算子工作区：某些算子（如卷积的 im2col）需要额外的工作区，其大小通常与输入尺寸和卷积核大小相关。
7. 加上对齐填充：TFLite Micro 默认按 16 字节对齐，因此每个分配块的末尾可能有多余的填充字节。

内存类别	包含内容	分配时机	估算公式
持久内存	权重、偏置、量化参数、算子配置	模型加载时	Σ(各权重张量字节数) + Σ(量化参数字节数)
临时张量	中间激活值、输入/输出张量	首次推理前	max(生命周期重叠组内张量大小之和)
算子工作区	im2col 缓冲区、深度卷积临时区	首次推理前	Σ(各算子工作区大小，取峰值)
对齐填充	内存对齐产生的空隙	每次分配时	约 5%~10% 的额外开销

实际工程中，更推荐使用 TFLite Micro 提供的 MicroAllocator::GetExpectedTotalSize() 接口，它会基于模型结构自动计算所需 Arena 大小。但手动估算的价值在于：它能让开发者直观地看到哪些层是内存大户，从而指导网络结构改造。

2.3 案例拆解：一个 3 层 CNN 的 Arena 规划

假设我们有一个简单的 3 层 CNN 模型，输入为 [1, 8, 8, 1] 的 int8 数据，结构如下：

输入: [1, 8, 8, 1] int8
Conv1: 3x3 卷积, 输出通道 4, 输出尺寸 [1, 8, 8, 4] (padding=SAME)
ReLU: 逐元素激活, 输出尺寸不变
Conv2: 3x3 卷积, 输出通道 8, 输出尺寸 [1, 8, 8, 8] (padding=SAME)
ReLU: 逐元素激活
Flatten: 展平为 [1, 512]
Dense: 全连接, 输出 [1, 10]

我们逐步计算 Arena 需求：

• 持久内存：Conv1 权重 3×3×1×4 = 36 字节，Conv2 权重 3×3×4×8 = 288 字节，Dense 权重 512×10 = 5120 字节，加上偏置和量化参数，总计约 5.5 KB。
• 临时张量生命周期：
  • 输入张量：生命周期为算子 0 到算子 5（整个推理过程），大小 8×8×1 = 64 字节。
  • Conv1 输出：生命周期为算子 1 到算子 2，大小 8×8×4 = 256 字节。
  • ReLU1 输出：生命周期为算子 2 到算子 3，大小 256 字节（与 Conv1 输出重叠，但 ReLU 是逐元素操作，可复用同一块内存）。
  • Conv2 输出：生命周期为算子 3 到算子 4，大小 8×8×8 = 512 字节。
  • ReLU2 输出：生命周期为算子 4 到算子 5，大小 512 字节。
  • Flatten 输出：生命周期为算子 5 到算子 6，大小 512 字节（与 ReLU2 输出重叠，可复用）。
  • Dense 输出：生命周期为算子 6 到结束，大小 10 字节。
• 峰值临时内存：在算子 3（Conv2）执行时，需要同时保留输入张量（64B）、Conv1/ReLU1 输出（256B）和 Conv2 输出（512B），峰值约为 64 + 256 + 512 = 832 字节。但 TFLite Micro 的规划器会进一步优化——输入张量在整个推理期间都需要保留，而 Conv1 输出在 Conv2 开始后不再需要，因此实际峰值可能更低。
• 算子工作区：Conv1 和 Conv2 使用 im2col 时，工作区大小约为 输入通道 × 卷积核大小 × 输出像素数。对于 Conv2，工作区约为 4 × 9 × 64 = 2304 字节。

最终 Arena 总大小估算为：持久内存 5.5KB + 临时内存峰值 0.8KB + 工作区 2.3KB + 对齐填充约 0.5KB ≈ 9.1KB。而如果使用标准 TFLite 的动态分配，实际峰值可能达到 5.5 + 0.8 + 2.3 + 额外碎片 ≈ 12KB 以上。TFLite Micro 的静态规划节省了约 25% 的内存。

2.4 常见误区与总结复盘

在实际项目中，开发者对 Tensor Arena 的理解常存在以下误区：

• 误区一：认为 Arena 大小等于所有张量大小之和。实际上，由于生命周期复用，Arena 大小通常只有所有张量总和的 30%~60%。
• 误区二：忽略算子工作区。卷积、深度卷积、LSTM 等算子需要额外的工作区，这部分内存往往被低估。一个 3×3 卷积的 im2col 工作区可能是输出张量的 2~4 倍。
• 误区三：混淆持久内存与临时内存。权重必须放在持久区，但某些框架实现中，如果权重在推理过程中被修改（如微调），则需要额外拷贝到临时区，导致内存翻倍。
• 误区四：忽视对齐填充。MCU 通常要求 4 字节或 8 字节对齐，TFLite Micro 默认 16 字节对齐。当张量大小不是对齐倍数时，会产生填充开销。例如，一个 10 字节的张量在 16 字节对齐下实际占用 16 字节，浪费 37.5%。