4、arena内存布局：张量、算子、中间结果、临时缓冲区的布局规划，对齐与填充规则

TFLite Micro 的编译期 arena 预算表设计，本质上是在回答一个问题：在静态内存池中，如何为张量、算子工作区、中间结果和临时缓冲区安排位置，使得整体内存占用最小且运行期零动态分配？ 这不仅是内存大小的估算问题，更是布局策略问题。arena 的布局规划直接决定了模型能否在资源受限的 MCU 上成功部署。本章将深入剖析 arena 内部的内存分区逻辑、对齐与填充规则，并通过一个完整的案例拆解，帮助你掌握从张量生命周期分析到最终布局生成的完整方法。

4.1 核心原理：生命周期驱动的内存复用

arena 布局的核心不是“按顺序摆放”，而是基于张量生命周期的重叠分析。一个张量从被某个算子写入开始，到被最后一个消费者读取完毕为止，这段时间称为它的“活跃区间”。如果两个张量的活跃区间不重叠，它们就可以共享同一块内存区域。TFLite Micro 的 arena 布局引擎正是利用这一原理，将原本需要数百 KB 的模型内存压缩到几十 KB。

具体来说，布局引擎会遍历模型图中的每个算子，为每个张量记录其“首次使用”和“最后使用”的算子索引。然后，它按照一定的策略（通常是贪心算法）对张量进行排序，并尝试将新张量放入已释放的内存空洞中。这个过程完全在编译期完成，运行期只是简单地根据预算表访问固定的偏移地址。

4.2 判断方法：张量生命周期分析与排序策略

要正确规划布局，必须掌握以下操作流程：

1. 构建生命周期表：遍历模型中的所有算子，为每个张量记录 first_op_index 和 last_op_index。例如，输入张量的生命周期从第 0 个算子开始，到最后一个使用它的算子结束。
2. 按生命周期排序：通常按照 last_op_index 升序排列，优先释放生命周期短的张量，以便尽早腾出空间。
3. 分配与回收：遍历排序后的张量列表，维护一个“空闲块列表”。当分配新张量时，查找第一个足够大的空闲块；当张量生命周期结束时，将其占用的块标记为空闲。
4. 对齐修正：每个张量根据其数据类型（如 float32 需要 4 字节对齐，int8 需要 1 字节对齐）进行对齐调整。如果空闲块的起始地址不满足对齐要求，则向后偏移并产生填充。

下表展示了典型张量生命周期与内存复用的关系：

注意 conv2_out 复用了 conv1_out 的空间，因为它们的生命周期不重叠。这种复用是 arena 节省内存的关键。

4.3 案例拆解：一个 CNN 模型的 arena 布局实战

假设我们有一个简单的 CNN 模型：Input(1x32x32x1) → Conv2D(8 filters, 3x3) → MaxPool(2x2) → Conv2D(16 filters, 3x3) → MaxPool(2x2) → Flatten → Dense(10)。目标平台是 Cortex-M4，arena 起始地址要求 8 字节对齐。

初始现象与目标：模型原始权重约 15KB，但若为每个张量单独分配内存，总内存需求将超过 40KB，超出 MCU 的 RAM 预算（32KB）。目标是通过 arena 布局将总内存压缩到 25KB 以内。

关键输入数据：

• Conv1 输出大小：1x30x30x8 = 7200 Bytes
• Pool1 输出大小：1x15x15x8 = 1800 Bytes
• Conv2 输出大小：1x13x13x16 = 2704 Bytes
• Pool2 输出大小：1x6x6x16 = 576 Bytes
• Flatten 输出：576 Bytes（与 Pool2 共享）
• Dense 输出：10 Bytes

分析判断过程：首先绘制生命周期图。Conv1_out 从 Op1 产生，被 Op2 消费；Pool1_out 从 Op2 产生，被 Op3 消费；Conv2_out 从 Op3 产生，被 Op4 消费。由于 Pool1_out 的生命周期（Op2-Op3）与 Conv2_out 的生命周期（Op3-Op4）在 Op3 处重叠，它们不能共享。但 Conv1_out（Op1-Op2）与 Conv2_out（Op3-Op4）不重叠，可以共享。

实际操作步骤：

1. 将 Conv1_out 分配到偏移 0（8 字节对齐），占用 7200 Bytes。
2. Pool1_out 分配到偏移 7200，占用 1800 Bytes。
3. Conv2_out 尝试分配时，发现 Conv1_out 已释放（生命周期结束），因此复用到偏移 0，占用 2704 Bytes。
4. Pool2_out 分配到偏移 2704（因为 Conv2_out 仍活跃），占用 576 Bytes。
5. Dense 输出分配到偏移 3280，占用 10 Bytes。

结果对比：最终 arena 总大小为 3290 Bytes（加上对齐填充约 3304 Bytes），远小于原始估算的 40KB。实际节省了约 90% 的内存。

风险与代价：这种复用策略要求算子执行顺序严格固定，且不能有异步操作。如果某个算子需要保留中间结果供后续反向传播使用（训练场景），则不能复用。此外，调试时内存内容会被覆盖，需要额外的 dump 工具辅助。

4.4 对齐与填充规则：细节决定成败

对齐是 arena 布局中最容易出错的地方。Cortex-M 内核通常要求 4 字节对齐访问，部分 DSP 指令甚至要求 8 字节对齐。如果张量地址未对齐，轻则性能下降，重则触发 HardFault。

对齐规则：

• 基础对齐：所有张量的起始地址必须是其元素大小的整数倍（如 float32 为 4，int16 为 2，int8 为 1）。
• 架构对齐：如果启用了 FPU 或 DSP 扩展，建议所有张量至少 4 字节对齐，最好 8 字节对齐。
• 算子特殊要求：某些算子（如 CMSIS-NN 的卷积）要求输入/输出张量 4 字节对齐，且行偏移（row stride）也需对齐。

填充规则：当分配器找到一个空闲块，但其起始地址不满足对齐要求时，需要将地址向上取整到对齐边界，并在前面插入填充字节。填充字节不计入张量大小，但计入 arena 总大小。

// 对齐宏示例
#define ALIGN_UP(x, align) (((x) + (align) - 1) & ~((align) - 1))

// 分配时计算填充
size_t aligned_offset = ALIGN_UP(current_offset, required_alignment);
size_t padding = aligned_offset - current_offset;
current_offset = aligned_offset + tensor_size;

常见误区：

• 误区一：认为对齐只影响性能不影响正确性。实际上，在 Cortex-M0 上非对齐访问会直接 HardFault。
• 误区二：忽略算子内部的临时缓冲区对齐。例如，某些量化算子需要临时存储中间累加结果，这些缓冲区也需要对齐。
• 误区三：在运行期动态计算对齐。正确做法是在编译期预算表中预先计算好所有偏移，运行期直接使用常量。

4.5 临时缓冲区与算子工作区的布局策略

除了张量，arena 还需要容纳算子运行时的临时缓冲区。这些缓冲区包括：卷积的 im2col 缓冲区、深度可分离卷积的中间累加器、量化算子的缩放因子数组等。它们的生命周期通常只覆盖单个算子，因此可以放在一个共享的“临时区”中。

布局策略：

1. 静态分配：对于大小固定的临时缓冲区（如 im2col 缓冲区），在编译期计算其大小，并分配在张量区之后。
2. 动态复用：对于大小可变的缓冲区（如某些算子根据输入尺寸调整），使用“最大需求”策略，即取所有算子中最大的临时缓冲区大小，统一分配一块内存。
3. 对齐考虑：临时缓冲区通常需要 4 字节或 8 字节对齐，因为它们可能存储 float32 或 int32 数据。

下表对比了不同临时缓冲区的处理方式：

实战建议：在布局时，建议将临时缓冲区放在张量区之后，并确保其起始地址满足最严格的对齐要求（通常是 8 字节）。如果临时缓冲区与张量共享内存，务必在预算表中明确标注，避免运行期冲突。