前阵子我排查一个 TFLite 检测模型的内存暴涨问题，模型权重才 4MB，输入也就 640x640，理论上中间激活峰值撑死 5MB，结果在手机上跑起来 RSS 直接飙到几十 MB。顺着代码往下挖，发现很多人把推理引擎当黑盒在用，完全不关心里面的内存规划器。其实 TFLite 这类推理引擎里，内存管理从来不是“用多少申请多少”那么简单的，它靠一个藏在底层的“内存管家”统一规划——这就是标题里说的 TFLite 内存规划器。
这篇内容适合正在做移动端或端侧部署的工程师，也适合那些想搞清楚推理引擎内部实现的学习者。我会从“它到底解决什么问题”开始，讲清楚张量生命周期、Arena 分配的核心思路，再带你手动推演一遍分配过程，最后给出一套排查和调优的实操方法。读完你至少能回答三个问题：为什么模型文件小但运行时内存大、中间张量为什么能互相复用内存、以及当 arena 暴涨时该从哪里下手。
1. 推理引擎里的“隐形内存管家”
1.1 内存压力到底从哪来
很多人有一个直觉：模型文件 4MB，那推理时内存应该也就 4MB 出头。这个直觉在 PC 上误差不大，但在移动端完全不是一回事。模型文件里最多的是权重，属于只读数据；而推理过程中每一层都会产生中间张量，比如卷积的输出、激活函数的输出、每次 Pooling 后的特征图。一个 100 层的网络，逐层产生、持有、释放这些张量，如果没有统一规划，内存会变成所有层输出张量的大杂烩。
举个例子，一个普通的 MobileNetV2，输入一张 224x224 的图，中间特征图尺寸千变万化：有的是 112x112x32，有的是 14x14x1280。如果每个算子都独立 malloc 一块内存，那么总内存就是这些张量大小的简单叠加，峰值很容易到几十 MB。但仔细观察会发现，很多中间张量的生命周期根本不重叠——前一层算完，它的输出不会被后面所有层一直用，等某个节点执行完，这块内存其实就“死”了。
推理引擎的调度单位是算子节点，所有张量在计算图中都有自己的“出生点”和“死亡点”。内存规划器要做的，就是分析这些生命区间，把那些“死掉”又没人占用的内存腾出来，给后面的张量继续用。说白了，这就是一个“会上引座员”的角色：你走了，座位马上给下一批观众。
1.2 内存规划器具体管什么事
TFLite 把这件事交给了专门的模块，在源码里对应的是ArenaPlanner和SimpleMemoryArena。你可以把ArenaPlanner理解为“策略制定者”，它负责在真正执行模型之前，把所有张量的内存位置预先算好；SimpleMemoryArena则是“仓库管理员”，它维护一块连续的大内存，按规划器给出的偏移地址，把每个张量放进对应位置。
这里的关键词是“预先算好”。推理引擎不想在运行过程中频繁走 malloc / free 流程，那样既慢又容易产生碎片。TFLite 的做法是在AllocateTensors()阶段做一次性规划：先分析计算图，给每个中间张量分配一个相对 arena 首地址的偏移量，然后申请一大块连续内存，运行时所有张量都在这块内存里搬进搬出。执行一个算子时，只需要通过偏移量定位输入输出张量即可，完全没有动态分配的负担。
还有个容易被忽略的点：内存规划器不只是管“中间激活”，它还要区分不同类型的张量。比如模型的权重，TFLite 可以通过 mmap 直接映射模型文件，不占用额外内存；而 LSTM 内部的 state 是持久变量，跨时间步、跨推理调用都要保留，不能和普通中间张量一样用完就回收。这些分类决策也由规划器在AllocateTensors()时统一处理。
1.3 没有规划器会怎样
我在自研一个小型推理引擎的时候试过偷懒：每个算子执行完就把输出动态分配出去，下一个算子用完再释放。结果就是内存碎片严重、分配次数多到影响帧率，更麻烦的是内存不确定性——某次输入尺寸稍微变一下，峰值内存就会波动，甚至出现 OOM。嵌入式环境里 malloc 本身就有风险，频繁调用会让堆碎片越来越严重，跑一会儿就容易内存不足。
规划器的好处是“离线决策、在线执行”。所有内存决策在初始化阶段就定死，运行阶段不产生分配行为，时间和空间都是可预期的。这也是为什么 TFLite 在移动端能保持稳定的内存表现，而不是像某些通用框架那样动不动就浮点数秒级推理、内存却下不来。
2. 张量生命周期与可复用内存
2.1 看清 TFLite 的张量分类
理解内存规划器之前，得先认识 TFLite 里的张量分类。每个张量都有一个allocation_type字段，大致分成几类：
kTfLiteMmapRo：只读映射，通常是权重、偏置，直接从模型文件映射到内存，不参与中间内存规划。kTfLiteArenaRw：普通的可读写中间张量，生命周期完全在计算图内部，是 Arena 规划的核心对象。kTfLiteArenaRwPersistent：可读写但需要在多次推理或子图调用之间保留的张量，比如控制流里的循环变量、LSTM 的 state。kTfLiteDynamic：动态张量，运行时尺寸可能变化，无法提前规划，只能单独动态分配。kTfLiteMemNone：还没分配内存的张量，通常是一个占位。
从内存规划角度，kTfLiteArenaRw是最值得优化的对象。它只活在计算图内部，生命周期完全由节点顺序决定；kTfLiteArenaRwPersistent则因为要跨调用存活，会被放到另一块持久内存区域，不能被普通中间张量复用；而kTfLiteDynamic是规划器的“盲区”，无法离线决定位置。
实际调试时，我会在AllocateTensors()之后扫一遍所有 tensor，看它们的allocation_type分布。如果发现大量中间张量被标成了kTfLiteDynamic，那就得警惕了——这些张量内存是动态分配的，arena 想管也管不着。
2.2 张量的“出生”与“死亡”
内存规划器最核心的输入，是每个张量的生命周期。生命周期怎么定义？很简单：计算图里的每个算子节点都有一个编号，按执行顺序排；张量被某个节点“生产”出来，又被某些节点“消费”。它的出生点是生产它的节点编号，死亡点是最后一个消费它的节点编号。
用真实代码里的逻辑来表达，就是遍历每个节点，更新它的输入和输出张量的first_use与last_use：
// 生命周期收集伪代码，概念来自 TFLite ArenaPlanner 的 prepare 阶段 for (int node_id = 0; node_id < graph.nodes_size; ++node_id) { for (int input : graph.nodes[node_id].inputs) { if (first_use[input] == -1) first_use[input] = node_id; last_use[input] = node_id; } for (int output : graph.nodes[node_id].outputs) { if (first_use[output] == -1) first_use[output] = node_id; last_use[output] = node_id; } }注意，一个张量如果是某个节点的输入，又恰好是另一个节点的输出，那么它在这个节点上相当于“被消费后再被生产”。很多内存规划器会把这种情况当成寿命连续处理，但 TFLite 里有些算子支持原地更新（in-place），也就是输出直接复用输入的地址，此时生命周期标记要格外小心。
一旦有了first_use和last_use，每个张量就变成一条时间轴上的线段：[first_use, last_use]。这条线段是内存复用的基础。两个线段如果完全不重叠，它们对应的张量就可以共享同一块物理内存。这就是张量内存复用最朴素也最有效的判据。
2.3 什么条件下两个张量能共享内存
两个张量要共享内存，需要同时满足三个条件：
第一，生命周期不相交。张量 A 的last_use必须早于张量 B 的first_use，或者反过来。也就是说，没有任何一个节点需要同时用到 A 和 B。只要有一个算子既要读 A 又要写 B，它们就只能分占两块内存。
第二，尺寸匹配。共享内存时，物理块的大小是两者中的较大值。假设 A 是 100 字节，B 是 50 字节，A 释放后 B 可以放进 A 的位置，但反过来不行。这让分配器需要维护一个“可用空间列表”，按大小查找合适的内存块。
第三，对齐要求。TFLite 的 SIMD 算子（比如 ARM NEON）对内存地址有对齐要求，默认对齐通常是 64 字节。即使生命周期和尺寸都满足，偏移地址也要对齐到 64 字节边界，否则算子访存可能会触发 bus error 或性能回退。
拿生活里的例子类比：会议室要预约，同一个会议室可以给下午和晚上两拨人开会用，只要时间不撞车；但如果你要开一个要坐 100 人的大会，就得保证会议室容量足够，而且投影仪位置还得合适。内存复用就是这个道理，不是简单地把地址倒来倒去，而是要统筹时间、大小、对齐三个维度。
3. ArenaPlanner 的规划流程
3.1 第一步：建立全图张量生命表
真正构建生命表的代码要比上面的伪代码复杂一些，因为要考虑节点内部多个输入输出之间的关系。规划器会把每个临时张量包装成一个TensorUsage之类的结构，记录张量编号、尺寸、首次使用节点、最终使用节点、是否持久化等信息。
TFLite 里有一点很关键：它规划的是“算子执行顺序”下的生命周期，而这个顺序在 FlatBuffer 模型里基本是固定的，转换器生成模型时已经确定了节点的先后关系。也就是说，同样一份网络结构，因为算子存储顺序不同，张量生命周期就可能不同，最终 arena 大小也会不一样。这是很多人不知道的细节，我后面会再展开。
构建生命表时还有一个隐含步骤：确认哪些张量真正需要参与规划。输入张量、输出张量通常由外部提供，不需要在 arena 内分配；权重张量是MmapRo，也不参与；只有那些ArenaRw和ArenaRwPersistent类型的中间张量才会被纳入分配池。这一步看起来简单，但一旦模型里混入了控制流子图，张量的归属关系会变得复杂，需要在生命表里显式标记。
3.2 第二步：贪心打包与内存分配
有了生命表之后，ArenaPlanner 开始按“出生顺序”或“请求顺序”逐个处理中间张量。每一步做两件事：先回收已经死亡张量占用的内存块，再为当前张量找一个合适的空闲块。这里的贪心策略是：只要有空闲块且大小足够，就用；没有就去 arena 尾部追加。
为什么用贪心而不是全局最优？因为内存分配问题本质是一个装箱问题（bin packing），要求最优解是 NP-hard 的。TFLite 面对的是各种结构完全不同的模型，规划器必须在毫秒级完成计算，不能跑一个整数规划求解器。实践也证明贪心算法在神经网络这种生命周期比较规整的图上，已经能接近最优解，损失一般很小。
回收逻辑有个细节必须提醒你：不是在“新张量申请的节点开始时”统一释放，而是要精确到“上一个算子执行结束之后”。一个张量可能在节点 5 被最后一个算子消费，那么节点 5 执行完才能释放。但如果新张量也是节点 5 的产物，那么它和旧张量严格来说是在同一时刻完成交接，只要算子本身安全，它们可以复用同一地址。TFLite 的分配器允许这种“在同一节点边界交接”的复用，这也是很多手工分配时容易疏忽的地方。
3.3 手动推演：一个小图怎么分配内存
下面我用一个简化模型演示完整的偏移计算过程。假设有四个算子节点 0、1、2、3，每个节点产生一个中间张量，张量的大小和生命周期如下：
| 张量 | 尺寸（字节） | 生命周期（节点区间） |
|---|---|---|
| t1 | 64 | [0, 1] |
| t2 | 128 | [1, 2] |
| t3 | 64 | [2, 3] |
按贪心分配，同时要求 64 字节对齐：
第一步，处理 t1。它出生在节点 0，直接放到 arena 头部，偏移 0，占用 [0, 64)。此时 arena 尾部是 64。
第二步，处理 t2。t2 出生在节点 1，但 t1 要活到节点 1 结束，所以在 t2 出生时 t1 还占着 [0, 64)。不能用这块空间，只能放到 arena 尾部。因为 64 字节已经对齐，t2 偏移取 64，占用 [64, 192)。arena 尾部变成 192。
第三步，处理 t3。t3 出生在节点 2，此时 t1 已经在节点 1 结束后死亡。t3 的尺寸是 64，刚好可以放进 t1 留下的 [0, 64) 空洞。于是 t3 被放到偏移 0，arena 尾部仍然只有 192。
最终结果：arena 总大小 192 字节。如果不用内存规划，各自独立分配，那需要 64+128+64=256 字节。省下来的 64 字节来自 t1 和 t3 的生命周期复用。真实模型里这种复用的效果会被放大很多倍，因为中间张量动辄几百上千个，复用率往往能达到 50% 以上。
3.4 关键数据结构与分配伪代码
ArenaPlanner里主要维护两类东西：一个是“活跃张量”集合，记录当前还活着的张量和它们占用的内存块；另一个是“空闲块”集合，记录已经释放、可以被新张量复用的空间。
下面是分配阶段的概念性伪代码，基本反映了 TFLite 的设计思路：
struct Block { size_t offset; size_t size; }; // active_blocks: 当前活跃张量 -> 占用块 // free_blocks: 可用块列表，按 offset 排序 // tail: arena 已使用的尾部 void AllocateForNode(int node_id) { // 1. 先回收已经结束生命的张量 for (auto& tensor : active_tensors) { if (lifetime[tensor.id].last_use < node_id) { auto block = active_blocks[tensor.id]; free_blocks.push_back(block); active_tensors.erase(tensor); } } // 2. 分配当前节点的输出张量 for (int tensor_id : node.outputs) { if (allocation_type[tensor_id] != kTfLiteArenaRw) continue; size_t size = align_up(tensor_size[tensor_id], kAlignment); // 3. 找一块足够大的空闲块，否则追加到尾部 auto it = std::find_if(free_blocks.begin(), free_blocks.end(), [size](const Block& b) { return b.size >= size; }); if (it != free_blocks.end()) { active_blocks[tensor_id] = {it->offset, size}; free_blocks.erase(it); } else { active_blocks[tensor_id] = {tail, size}; tail += size; } active_tensors.push_back(tensor_id); } }为什么维护free_blocks而不是只记住“上一个结尾”？因为张量释放的顺序和申请顺序不一样，会产生碎片空洞。比如大块 A 释放后，小块 B 申请可能放进 A 的位置，但之后大块 C 申请又因为放不进 A 的残留而继续涨尾部。分配器通过维护空闲块列表来尽量利用空洞。TFLite 还做了一点优化：优先使用 offset 最小的空闲块，让尾部增长尽量慢，这样 arena 总大小更紧凑。
3.5 对齐问题：看起来小，踩到就崩
TFLite 默认对齐是 64 字节，这个值的来历主要照顾 ARM NEON 的向量访存需求。对齐不仅影响性能，还影响正确性。某些内核会直接加载 16 字节或者 32 字节的向量，如果内存地址没对齐，轻则速度暴跌，重则直接崩溃。
计算偏移时，实际使用的是align_up(offset + size, 64)之后的值。也就是说，每个张量块之后可能留下几十字节的碎片。不要小看这点浪费，如果模型有几百个中间张量，对齐碎片可能累计到几十 KB。但相对整体 arena 来说，这点代价是值得的。
调试时如果只在 x86 机器上跑，可能察觉不到对齐问题，因为 x86 对未对齐访问容忍度更高。一旦部署到 ARM 手机或者 Cortex-M 系列芯片上，问题就会暴露。所以我建议在内存规划器代码里显式打印每个张量的 offset 和 size，检查它们是否都满足 64 字节对齐，这个习惯能省去很多底层排查时间。
4. 实操：如何拿到 TFLite 的真实内存画像
4.1 用代码直接读 arena 信息
最理想的自然是调用公开 API 拿到内存统计。TFLite 在不同版本里提供的接口不完全一致，老版本在Interpreter上可以直接访问内部 arena，新版本把实现藏得更深了。一个稳妥的办法是在源码构建时给ArenaPlanner加日志，或者在调用AllocateTensors()之后，遍历所有张量查看它们的地址和大小。
给一个思路层面的参考代码，具体 API 以你用的源码版本为准：
// 伪代码：AllocateTensors 完成后统计每个 tensor 的内存信息 auto* interpreter = /* 你的 TFLite Interpreter 实例 */; interpreter->AllocateTensors(); size_t arena_total = 0; for (int i = 0; i < interpreter->tensors_size(); ++i) { TfLiteTensor* t = interpreter->tensor(i); if (t->allocation_type == kTfLiteArenaRw || t->allocation_type == kTfLiteArenaRwPersistent) { arena_total += align_up(t->bytes, 64); Printf("tensor %d: offset=%p, size=%zu, type=%d\n", i, t->data.data, t->bytes, t->allocation_type); } }这里有个小技巧：打印t->data.data指针，把所有中间张量的地址拿出来画成区间图。如果发现两个生命周期不相邻的张量地址一样，说明规划器成功复用了内存；如果地址完全分散且没有重叠，说明可能没有启用规划器，或者模型里大部分是动态张量。
如果你的设备环境不方便跑 C++，也可以在 Python 侧通过tf.lite.Interpreter的get_tensor_details()拿到每个 tensor 的 shape、dtype，但拿不到精确的 arena offset。这种情况下，我更推荐走 4.2 节的工具路线。
4.2 用 Benchmark 工具和系统命令交叉验证
TFLite 官方提供了一个 benchmark 工具，在tensorflow/lite/tools/benchmark目录下，支持把内存统计打到日志里。你可以在初始化阶段传入一个内存监控器，在AllocateTensors前后记录 malloc 统计。虽然具体参数每个版本有调整，但思路大同小异：跑一个空输入循环，记录峰值 RSS，再单独把 arena 大小算出来对比。
在 Android 设备上，我还会配合系统工具一起看。比如：
adb shell dumpsys meminfo <package_name>重点看 Native Heap 和 Graphics 内存。TFLite 的 arena 属于 Native Heap，如果 arena 规划得好，Native Heap 曲线应该很平稳，不会随着单次推理次数增长而持续上升。如果每隔几次推理 Native Heap 就涨几 MB，那大概率是存在动态张量没有走 arena，每次都触发新的分配。
另一个有用的方式是统计“单次推理触发的 malloc 次数”。在 TFLite 的执行循环里打桩，记录每个算子执行时的分配调用。正常情况下，AllocateTensors 之后，运行阶段不应该有任何 malloc。如果发现运行阶段还有分配，就顺着调用栈找到底是哪个算子在做动态内存申请，通常是自定义算子或者ResizeInputTensor导致的重规划。
4.3 改源码加日志，看每个张量的规划结果
最快的方案其实就是给arena_planner.cc加打印。你不需要理解全部算法，只要在PlanAllocations结束后，遍历分配的记录，把 tensor 编号、偏移、大小打印出来。
日志格式可以这样：
=== ArenaAlloc: tensor=12 size=12800 offset=512 === ArenaAlloc: tensor=37 size=25600 offset=0 === TotalArenaSize: 1048576把这些输出保存下来，用脚本画成泳道图——每个 tensor 一条横线，按生命周期排在时间轴上，纵轴表示 offset。一眼就能看出哪些区域被重复使用、哪些大块张量拉高了整体峰值。这个手段比任何高级 profiler 都直观，而且不依赖外部工具。
如果你不想修改官方源码，可以复制一份ArenaPlanner改成自定义 planner 挂进 interpreter，在自定义版本里加各种统计。TFLite 的InterpreterBuilder允许你传入自己的内存规划器，代价是要重新实现接口。对只是想排查问题的团队，我觉得临时加日志更划算。
5. 常见问题与调优实录
5.1 模型文件不大，arena 却暴涨
这种问题最常见的原因就是中间张量太多，或者生命周期重叠太严重。多分支结构的网络（比如 FPN、Attention 特征融合）会同时存活多个大张量，这些分支的输出都要保留到融合节点，导致同一时间活跃张量非常多。
排查步骤我一般这样走：先统计张量数量，再统计平均生命周期长度。如果一个图里有几百个中间张量，平均生命周期超过 10 个节点，那说明很多张量没有被及时释放，arena 被拉长是必然的。压缩手段优先级从高到低排列：
第一，量化。从 float32 降到 int8，中间张量直接缩小四倍，这是最暴力的降内存手段。第二，激活函数在算子内部原地更新，避免产生新的张量。第三，手工融合算子，比如 Conv+BN+ReLU 融合成单个算子，减少中间张量数量和生命周期。第四，在保证精度的前提下简化网络结构，减少分支宽度或特征图分辨率。
这里要特别提醒：量化之后很多中间张量仍然是 int8，但某些算子为了精度会暂时把数据转成 float32 再转回 int8，这种临时 buffer 不算在图张量里，却会额外占用内存。排查时不要只盯着 arena，还要关注算子内部申请的临时 buffer。
5.2 动态尺寸张量带来的麻烦
TFLite 对动态 shape 支持得比较弱，主要原因是内存规划器必须在运行前把所有位置定死。如果某个张量运行时尺寸变了，原来的偏移和大小就失效了，要么重新规划，要么走动态分配。重新规划的成本很高，而且会导致 arena 大小在新尺寸上重新计算，之前的紧凑布局全部作废。
我在项目里遇到过一个检测模型，输入尺寸有时候 320x320，有时候 640x640。TFLite 在每次ResizeInputTensor之后都要重新AllocateTensors，arena 按最大尺寸规划。问题是模型里如果有些分支依赖于输入尺寸，张量大小会成倍增长，arena 峰值按最坏情况预留，内存一下子膨胀好几倍。
解决思路有两个方向：一是固定输入尺寸，宁愿训练时做多尺度，也不要部署时随意改；二是把动态张量尽量控制在算子内部，比如用自定义算子在内部按需分配，不要让它成为计算图张量。如果自定义算子内部确实需要动态内存，尽量复用已有 buffer，像TfLiteContext提供的GetScratchBuffer那样，避免每次推理都重新分配。
5.3 同一个地址被两个张量复用后结果出错
这是个很隐蔽的坑。你启用了 arena，内存规划得很好，但程序变随机出错了。原因往往是某个算子在同一时刻引用了两个已经被规划到同一个偏移上的张量。正常情况下规划器不会让活跃区间重叠的张量复用同一地址，但边界情况处理不好就会出问题。
一个常见场景是 in-place 算子。比如某个算子声明自己可以原地执行，输出直接写到输入上，那么它的输出张量和输入张量可以共用一个偏移。如果这个算子其实并不完全支持原地操作，或者实现里有隐藏的逻辑依赖原始输入，复用就会导致数据被提前覆盖。
排查方法很简单：把输入张量和输出张量强制放到不同偏移，再看问题是否消失。如果不再出错，就是 in-place 声明和实现不一致。另一个场景是张量生命周期边界计算有误：当一个张量是节点 N 的输入，另一个张量是节点 N 的输出，如果生命表把前者标记为从 N 结束后才死亡、后者标记为 N 开始时就出生，它们就可能错误重叠。
遇到这类问题，我会在自定义算子上下文里禁用kAllowInPlace之类的优化开关，优先保证正确性。等内存优化做完之后，再认真审查每个算子的原地操作实现，逐步打开复用。
5.4 算子顺序对峰值内存的影响有多大
这个点不少人忽略。同一个计算图，可以把几个无关算子排在不同顺序，只要满足拓扑序就行。但算子顺序会直接改变张量的死亡时间，从而改变生命周期重叠程度。
举个简单的例子：一个网络先做两个独立分支，每个分支再各出一个结果，最后融合。如果两个分支的算子交叉执行，其中一个分支的中间张量一直存活，另一个分支的中间张量也在存活，峰值就高。如果先把一个分支完整算完再算另一个，前一个分支的中间张量早早就释放了，arena 可能更小。
TFLite 转换器大多时候会按模型原始定义的节点顺序生成执行顺序，但这个顺序不一定是最优的。你在转换前后对比 arena 大小时，如果发现同样结构不同版本的 TFLite 模型占用内存不同，很大原因就是算子顺序变了。想优化的话，可以考虑在模型图优化阶段做节点重排，把生命周期长的张量尽量往后放，让它们少跟其它大张量重叠。这个优化对内存的影响不输于量化，但实现起来需要动图优化代码。
5.5 多实例和子图之间如何共享内存
如果你的进程里同时跑多个 TFLite interpreter 实例，比如一个检测模型加一个分类模型，它们的 arena 是各自独立的，内存不会自动复用。想共享内存的话，要么把两个模型合并成一个大的计算图，要么自己做内存池，把两个 arena 放在同一个 buffer 里，分别计算偏移再错开分配。
子图的情况相对复杂。TFLite 支持控制流算子（比如 while 循环），子图会持有自己的张量集合。从执行角度看，子图和主图交替运行，如果每个子图都单独规划 arena，内存可能会有重复，但它们不是同时存活，理论上可以复用。具体实现里，子图的持久张量对接主图的持久 arena，而内部临时张量通常不跨子图共享，所以多子图模型的内存规划是偏保守的。
如果你在跑语音或流式模型，还会遇到跨推理调用的状态张量。这类张量必须存在持久区，不能走普通复用逻辑。规划器把ArenaRwPersistent单独管理，避免和一个推理内的临时张量混在一起被错误释放。对这类模型，我建议把状态张量显式连接成计算图的输入输出，让框架能识别它们跨调用存活，而不是依赖黑魔法。
6. 工程上的一些建议
6.1 把 arena 大小当作重要性能指标
我在部署流程里会把“arena 总大小”和“单次推理 malloc 次数”两个指标打进 CI 日志，每次更新模型或框架库时对比。模型转换后AllocateTensors()会输出一个 arena 大小，如果一次模型更新让 arena 暴涨 20%，即使精度没变，我也会警觉，去查张量生命周期是不是被打散了。
这个习惯帮我避免过好几次线上 OOM。很多团队只盯模型文件和推理耗时，忽视了内存峰值，结果一上真机就闪退。你不需要理解每一个底层细节，只要把 arena 大小纳入版本对比体系，就能提前发现问题。
TFLite 源码里我印象最深的注释，是关于为什么用 arena 而不是直接用 malloc：保持执行路径的确定性。这个思想我后来移植到了自己的引擎里，每次模型初始化时做一次离线规划，执行阶段零分配。看起来只是节省了一点 malloc 开销，但换来的是帧率曲线的平滑和内存的可预测性，这在实时音视频处理场景里非常值钱。
6.2 让算子尽量支持 in-place 更新
内存规划器虽然可以把生命周期不重叠的张量复用到同一块内存，但如果能让“输出直接覆盖输入”，那连生命周期重叠都不用担心了。像 ReLU、某些归一化算子，它的输入在计算完后就不再需要了，完全可以在原地改内存。
实现的时候要注意，in-place 不是简单的“输入输出索引相同”，还要考虑算子内部有没有额外的中间 buffer。比如某个算子需要把输入先搬一份再做计算，那它就不适合原地操作。我一般先让普通算子保证正确性，再逐个验证是否可以安全开启 in-place。这个收益在通常的 CNN 里可能只有百分之几，但在一些连续层很多的小模型上，能明显降低峰值。
6.3 自己写引擎时怎么参考这个设计
如果你也在写自己的推理引擎，不用照抄 TFLite 的代码，但可以抄它的设计思路：把“内存决策”和“执行”彻底分离。初始化阶段收集张量生命周期、计算偏移，运行阶段完全按预设地址执行。这样能保证执行路径没有动态分配，也方便做内存峰值预测。
实现时先从最朴素的贪心开始，不要一开始就想实现最优装箱算法。贪心在大多数图上表现足够好，而且实现简单，调试方便。等到内存成为瓶颈时，再考虑更复杂的策略，比如按生命周期区间图做最大重叠消除，或者引入重计算换内存的思路——那就完全是另一个话题了。
最后分享一个我常用的“土办法”：在加载模型后，把 arena 里每个张量的起始地址和大小输出，然后手工挑几个关键层对比。有一次我发现某个 14x14x512 的特征图被分配到了 arena 的开头，而 56x56x256 的特征图被分配到了末尾，结果中间空闲了一大段。原因就是生命周期算法把一个大尺寸张量排在了前面，小尺寸张量无法填满它留下的空洞。后来我把大尺寸张量优先分配，arena 又压下去一截。这种细节工具文档里不会写，但实际排查时帮助极大。希望这篇东西能帮你少走点弯路，也算是我跟内存规划器“过招”这么久的一点经验积累。
