做端侧推理部署的人，应该都遇到过这种场景：模型权重明明只有几十MB，一跑起来App的内存却暴涨到两三百MB，动不动就被系统低内存回收。以前我排查这类问题，第一反应是换更小的模型、降输入分辨率，后来才意识到，真正的元凶往往是推理引擎内部中间 tensor 的内存管理。而 TFLite（TensorFlow Lite）里专门负责这件事的组件，就是本文要聊的内存规划器（Memory Planner）。它是推理引擎里不折不扣的"内存管家"。
这篇文章不是源码逐行注释，而是我基于 TFLite 推理引擎做端侧部署优化时，对内存规划器从原理到实践的理解总结。我会讲清楚它到底解决了什么问题、内部是怎么工作的、如何验证它真的在帮你省内存，以及我踩过的一些坑。适合正在做移动端或者嵌入式设备 AI 部署、对推理引擎底层优化感兴趣的朋友。
1. 推理引擎的内存难题：为什么非规划不可
1.1 没有内存规划，一次推理要吃多少内存？
先说个基本的认知：神经网络推理过程不只是把权重算一遍那么简单。
模型在运行时，每一层算子都需要读取输入 tensor，计算后产生输出 tensor。这个输出 tensor 又会作为下一层的输入继续往下传。那些在层与层之间传递、只为了支撑计算过程而存在的临时数据，就是"中间 tensor"（也叫激活 tensor，activation tensor）。
举个简单的例子。一个输入为 224x224x3 的分类模型，第一层卷积输出特征图可能是 112x112x32，单这一层输出就占 11211232*4 字节，约 1.5MB。整个模型几十层算下来，如果把每一层的中间 tensor 都单独完整地保存在内存里，累加总量很容易超过 100MB，甚至更大。
这里要区分两个概念：权重 tensor和中间 tensor。权重是模型的一部分，生命周期从推理开始到结束，必须一直在；中间 tensor 则完全不同——某一层算完之后，它的输出 tensor 只对下一层有意义，等下一层算完，这个 tensor 理论上就已经"死掉"了，所占的内存完全可以释放出来给后面的层用。
如果推理引擎不去规划这些中间 tensor 的内存，而是"每遇到一个 tensor 就分配一块独立内存"，那峰值内存就是所有活跃中间 tensor 的简单叠加。我曾经用 naive 方式跑过一个 YOLO 系列的检测模型，中间 tensor 的理论总和接近 200MB，在手机上根本跑不动。
1.2 内存规划器解决的三个核心问题
TFLite 引入内存规划器，本质上是为了解决三件事，这三个问题在端侧场景里都是命门。
第一，降低峰值内存占用。端侧设备的内存是硬约束，iPhone 和旗舰 Android 还好，很多嵌入式 Linux 设备或者 MCU 上，可用内存可能只有几十 MB。峰值内存如果能从 200MB 压到 60MB，决定了一个模型能不能在这个设备上跑起来。内存规划器的核心工作，就是分析所有中间 tensor 的生命周期，让不重叠的 tensor 共享同一块内存，从而把峰值压到"最大活跃区间"而不是"总和"。
第二，减少运行时的分配开销。移动端开发常见的一个性能杀手就是频繁 malloc/free。推理是循环执行的过程，如果每帧都重新分配、释放几百块内存，系统调用和内存碎片会让单帧延迟变得极不稳定。TFLite 的做法是提前规划好所有 tensor 在内存池中的偏移量，推理真正执行时，tensor 只是指向这块大内存里的某个位置，几乎不做动态分配。这也是很多推理引擎性能稳定的原因之一。
第三，保证内存访问的正确性和可预测性。内存复用听起来简单，但不同 tensor 的生命周期可能横跨不同算子，如果分配错乱，前面的 tensor 还没读完就被后面的覆盖了，推理结果直接错掉。规划器需要严格基于算子执行顺序做生命周期分析，保证复用一定是安全的。
1.3 为什么不同 tensor 可以共享同一块内存？
这里的关键思想，用生活中的例子特别好解释：酒店房间。
一间客房不可能同时住两个互不认识的客人，但如果客人 A 上午退房、客人 B 下午入住，那这间房完全可以接待两个人。内存规划器就是那个酒店前台，它知道每个"客人"（中间 tensor）的入住时间（从哪个算子开始被创建）和退房时间（到哪个算子结束不再需要）。只要两个 tensor 的存活时间段不重叠，它们就可以用同一个房间（同一块内存地址）。
实际推理过程中，每一层计算都是"读取输入 -> 产生输出 -> 不再需要输入"这样的节奏，相邻层之间的中间 tensor 生命周期天然就是交错开来的，所以复用潜力极其巨大。
2. 内存规划器的工作原理拆解
2.1 两个内存池：持久内存和 Arena
TFLite 的 Interpreter 在内存管理上大致分两个池子。一个是persistent buffer（持久缓冲区），专门放权重、常量、以及一些需要在整个推理过程里一直存在的 tensor。另一个是arena buffer（竞技场缓冲区），也就是内存规划器重点管的那部分——存放中间激活 tensor。arena 这个名字很形象，它就像一块公共竞技场，所有的中间 tensor 都在这块场地里分地盘，不用的地盘立刻让出来给下一个用。
这两个池子的分配策略完全不一样。persistent buffer 在解释器初始化时一次性分配好，生命周期跟解释器绑定。arena 则在第一次推理前根据规划结果分配，之后的推理循环只是不断复用已有的布局，不会再反复分配释放。
我当时第一次看这部分的源码时，最大的启发点是：TFLite 并不是在推理过程中"动态规划"内存，而是提前算好了一张静态的内存布局表。推理引擎执行的时候，每个 tensor 的 data 指针直接指向 arena 里的固定偏移，整个过程是零分配、纯复用的。
2.2 生命周期分析：TensorRecord 和 begin/end node
规划器要先回答一个问题：每个中间 tensor 到底在哪个算子被创建、在哪个算子之后就不再需要？
TFLite 源码里使用了一个叫 TensorRecord 的结构来记录这个信息，每个 tensor 对应两条关键信息：
- begin_node：这个 tensor 第一次被作为输出产生时的算子序号。
- end_node：这个 tensor 最后一次被作为输入使用时的算子序号。
有了这两个序号，一个 tensor 的存活区间就明确了。规划器会按照推理引擎生成的执行计划（execution plan）遍历所有算子，逐个标记它们的输入输出 tensor 的 begin 和 end。
有一个容易被忽略的细节：某些算子具备"原地更新"（inplace）的能力，也就是输入输出共用同一块内存。这种算子会让生命周期分析变得微妙，因为输出 tensor 的存活区间可能从输入 tensor 的 begin 就开始了。不过 TFLite 在绝大多数标准算子实现里，对这个场景有单独的处理，不会因为原地更新导致内存踩踏。
2.3 分配算法：GetNextBuffer 与 deallocated 列表
有了每个 tensor 的生命周期，规划器接下来要做的，就是把存活区间不重叠的 tensor 尽量安排到同一块内存上。
TFLite 的 ArenaPlanner 在分配时的核心逻辑，我简单拆一下：
- 规划器按执行计划顺序逐个处理算子。
- 当算子执行结束后，它的输出 tensor 会进入"存活期"，需要分配内存。
- 分配时调用 GetNextBuffer，这个函数维护了一个deallocated buffer 列表——里面放的是之前某些 tensor 释放后空出来的内存块。
- GetNextBuffer 会从这个列表里寻找足够大的空闲块，直接复用；找不到合适的大小时，才从 arena 尾部新开一块内存。
- 同时，当一个 tensor 到了它的 end_node，意味着它彻底死掉了，它占用的 buffer 会被回收到 deallocated 列表里，等待后续复用。
这个"维护空闲列表 + 优先复用"的策略，和操作系统里的内存分配器思路很像，但针对性更强——因为它完全清楚每个 tensor 的生死时机，没有任何猜测成分。
关于 GetNextBuffer 的选择策略，还有一个小分支：当规划器的 preserve_order 标志为真时，它会更保守地复用内存，保持 tensor 的地址顺序和执行顺序一致；默认为 false，最大化复用效率。我们在调试和分析内存问题时，可以把 preserve_order 打开，让内存布局更可预期、问题更容易复现。
2.4 对齐、偏移量与最终内存布局
规划器最终的产出，是一个"tensor index -> arena 偏移量"的映射表。arena 本身是一块连续的大内存，每个 tensor 被安排在某个偏移位置上。
这里有一个很影响实际效果的细节：内存对齐。如果完全不考虑对齐，两个 tensor 前后紧挨着放，第二个 tensor 的起始地址大概率是非对齐的，一些硬件加速指令（比如 NEON 或者 GPU 传参）会出问题或者性能暴跌。TFLite 的做法是给 arena 设一个对齐粒度，通常默认 64 字节，每次分配 buffer 时，实际占用的空间是"所需字节数向上取整到对齐粒度"。这样每个 tensor 的起始偏移都是对齐的，虽然会浪费少量空间，但换来了访问效率和硬件兼容性。
还有一个细节是：arena 的总大小并不是所有 tensor 大小之和，而是所有被实际分配出去的 buffer 中，"当前分配指针"的最大值。因为大量 tensor 复用了同一块区域，arena 大小往往远远小于理论总和。
3. 实操：验证内存规划器真的在帮你省内存
3.1 获取 arena 大小：一条代码看穿内存占用
理解了原理，最想做的当然是看看自己手里的模型到底省了多少内存。
如果你在 C++ 环境里使用 TFLite，获取 arena 的大小非常直接：
// 假设 interpreter 已经创建完成，且已完成内存分配 auto* interpreter = ...; size_t arena_size = interpreter->arena_size(); size_t persistent_size = interpreter->persistent_size();在 Python 环境里，也有对应的方法：
import tensorflow as tf interpreter = tf.lite.Interpreter(model_path="model.tflite") interpreter.allocate_tensors() # 获取内存池大小（字节） arena_size = interpreter._interpreter.get_arena_size() persistent_size = interpreter._interpreter.get_persistent_size()注意一点：arena_size 是内存规划器实际申请出来的 arena 总大小。它跟"所有中间 tensor 字节数总和"是两个概念。你的优化目标，就是让 arena_size 尽可能小于理论总和。
3.2 一套完整的收益量化流程
要量化收益，得先算出"理论总和"这个对照组。我一般这么做：
第一步，用 Netron 打开 tflite 模型，或者写脚本解析模型文件，把所有非权重 tensor 的字节数累加。所谓非权重 tensor，就是在推理过程中会动态产生和消失的那些激活 tensor。这个总和就是 naive 方案下的峰值内存上界。
第二步，跑一次推理，打印 arena_size。
第三步，两者相减，就是内存规划器帮你省下来的量。
我实际做过的一个例子是某个工业缺陷检测模型，输入 512x512x3，中间有十来个卷积层。所有激活 tensor 的理论总和大约是 89MB，但 arena_size 只有 31MB。因为网络结构里很多层的特征图尺寸呈递减趋势，前半段的大特征图生命周期跟后半段的完全不重叠，规划器把它们的存储区域高度复用了。这个例子很典型，说明峰值内存永远取决于"生命周期重叠最大的那个区间"，而不是总工作量的累计。
3.3 影响收益的几个关键配置
内存规划器的收益不是固定的，有几个配置会直接影响最终效果。
第一个是arena 对齐粒度。默认 64 字节对齐，如果你觉得浪费太多，可以尝试改成 16 或者 32 字节。不过我不太建议为了省那几百字节去动这个参数，因为一旦边缘设备的加速库对对齐有要求，反而会引入性能问题。
第二个是preserve_order 标志。开启后规划器会让内存分配顺序和执行顺序保持一致，复用的自由度下降，通常 arena 体积会变大。它默认关闭，除非你在调试，否则保持默认就好。
第三个是tensor 的持久化属性。模型里有些中间 tensor 会被标记为 persistent（比如某些控制流场景下的变量），这些是不会参与 arena 复用的，规划器只能把它们放进 persistent buffer。如果模型设计不合理，把大量中间结果误标记成了 persistent，arena 规划的空间就会被压缩。在转换模型时可以观察一下是否有大量不必要的 persistent tensor。
在我做部署优化时，通常会把这一步当成"体检"：先跑出 arena_size 和 persistent_size 这两个数字，再类比理论总和，就已经能判断模型在内存维度上"健康不健康"了。
3.4 配合算子融合和量化进一步压缩
内存规划器是在算子层面做"内存复用"，但如果能减少中间 tensor 的数量，收益会更直接。TFLite 转换时默认会做一波算子融合，把可以合并的算子（比如 Conv + Relu）合并成一个，中间那个 Relu 的输入输出 tensor 就省掉了。
实际项目里，我建议这样组合优化：
- 转换模型时，保证 TFLite Converter 的优化开关是打开的（默认就是）。
- 优先使用 int8 量化。量化除了减小权重，中间 tensor 也会从 float32 变成 int8，字节数直接除以 4，这对"生命周期重叠较大"的模型效果尤其明显。
- 如果某些层是内存大户（特征图特别大），可以考虑手动调整网络结构，比如把大的 stride 提前，让特征图尽快缩小。
4. 常见问题和排查技巧实录
4.1 自定义算子导致内存复用失效
TFLite 支持注册自定义算子，但如果你注册的算子没有正确声明它对输入输出 tensor 的使用方式，规划器就没法准确计算生命周期。
这种情况的典型表现是：模型跑起来结果没错，但 arena_size 异常大，逼近理论总和。原因通常是自定义算子里，输入 tensor 被无条件地保留到最后，或者输出 tensor 的生命周期被规划器保守地延长了。
排查思路很简单：先注释掉自定义算子的调度路径，看 arena_size 是否回落。如果回落，就说明你的算子注册信息不完整。TFLite 里自定义算子需要实现 Prepare 和 Eval 两个函数，Prepare 阶段会声明对 tensor 的引用，一定要确保该声明的都声明了，别偷懒。
4.2 动态 shape 下的规划策略变化
还有一类模型的输入尺寸不固定，比如目标检测模型可能支持不同分辨率输入。这种情况下，interpreter 在每一组新尺寸首次推理前，需要重新调用内存规划流程。
重新规划的代价不算小，因为它要做完整的生命周期分析和 arena 重分配。如果你在视频流处理里每帧都 resize 输入，性能会明显劣化——不仅多了一次规划和分配，碎片化问题也会加剧。
我现在处理动态 shape 的模型，原则是：尽量固定输入尺寸，如果确实要支持多档分辨率，就在初始化时把所有可能用到的尺寸都跑一遍 warm-up，把 arena 布局提前稳定下来。别在热路径上做 resize。
4.3 delegate 参与时的内存边界
当你接入 GPU delegate 或者 NPU delegate 时，部分算子会被委托给硬件加速器执行。这里有一个隐藏的内存问题：delegate 通常会把自己的输入输出 tensor 拷贝到自己的内存区域，如果规划器不知道这件事，CPU 侧 arena 里还是会保留一份完整的中间 tensor，等于双份内存开销。
解决办法是让 delegate 在 Prepare 阶段向解释器声明：某些 tensor 的内存由我接管，不需要你分配。TFLite 的 delegate 接口里，可以检查 tensor 的 allocation type，如果被 delegate 接管，ArenaPlanner 会跳过这些 tensor 的分配。我经验是：接入 delegate 后立刻观测 arena_size，如果没降反升，十有八九是拷贝路径没有走对。
4.4 多实例场景下的内存冗余
如果你的 App 同时创建了多个 Interpreter 实例（比如同时跑两个模型），每个实例都有自己独立的 arena，内存无法共享。有些团队为了省内存，会频繁创建销毁 Interpreter，这其实比常驻两个实例更糟糕，因为每次创建都要重新规划、重新分配。
更优的做法是：如果多个模型不会同时推理，就用同一个 Interpreter 实例，加载不同模型后复用。TFLite 允许重新加载模型，并在这个过程里重新规划内存。这样整个 App 的推理内存峰值就只有一个模型的峰值，而不是两个模型都各自占一份。
4.5 内存问题的常规排查手法
最后分享一个我排查内存问题的固定套路。如果发现推理进程的常驻内存偏高，不要急着优化模型，先回答以下三个问题：
- 模型权重占多少？（这个是最容易算的，模型文件大小基本就是）
- persistent_size 是多少？（是不是有意外的高）
- arena_size 是多少？（跟理论总和比，复用率是否正常）
拿到这三个数字，问题基本定位了。如果 persistent_size 高，说明模型转换时有大量 tensor 被标记成了常量；如果 arena_size 高，说明算子层的内存复用没做透；如果两个都正常但进程内存还是高，那就要看看是不是某个 delegate 有自己的额外缓冲，或者推理框架里其他模块（比如图像预处理）吃了内存。
根据我个人的体会，内存规划器这种"静态规划 + 动态复用"的思路，不仅适合 TFLite，你去看其他推理引擎后也会发现类似的设计。理解了生命周期分析这一点，后续看 XNNPACK、看 GPU delegate 的内存池，都会变得通透很多。如果你现在正被端侧模型的内存问题困扰，不妨先别急着换模型，花点时间把你的 arena_size 和理论总和算一算，这个数字本身就会告诉你很多信息。
