TensorFlow模型推理中“内存泄漏”多因计算图累积未清理，需重置计算图；tf.function重复追踪致图缓存爆炸，应禁用自动追踪或统一input_signature；模型加载后长期持有graph引用需显式clear_session；tf.data迭代器未耗尽会滞留资源，须用try/finally确保释放。
TensorFlow模型推理中出现“内存泄漏”，绝大多数情况不是真的泄漏，而是计算图持续累积没被清理——重置计算图能直接切断根源。
tf.function 重复追踪导致图缓存爆炸
在 Eager 模式下用 @tf.function 加速推理时，TensorFlow 会为每种输入签名（shape/dtype 组合）生成并缓存一个独立的计算图。如果输入 shape 动态变化（比如 batch size 波动、文本长度不固定），每次都会新增一个图实例，而旧图不会自动释放。
- 现象：
nvidia-smi显存持续上涨，tf.config.list_physical_devices("GPU")正常，但tf.keras.backend.clear_session()无效 - 验证方式：打印
len(tf.get_default_graph().get_operations())或检查tf.autograph.trace日志，会发现操作数随请求次数线性增长 - 解决动作：显式禁用自动追踪，改用
input_signature强制统一签名，或对动态输入做 padding/clip 预处理
模型加载后长期持有 graph/session 引用
TF 2.x 虽默认 Eager，但底层仍依赖 Graph 执行机制。用 tf.keras.models.load_model() 或 tf.saved_model.load() 加载模型后，其内部 ConcreteFunction 和关联的 Graph 实例会被隐式持有。若模型对象被全局变量、类属性或闭包捕获，整个图结构就无法被 GC 回收。
- 常见错误：把
model = tf.keras.models.load_model(...)放在模块顶层，或赋值给self.model后未做生命周期管理 - 关键区别：调用
del model只删 Python 引用，不触发 C++ 层图释放；必须配合tf.keras.backend.clear_session()或重建进程 - 实操建议：在长周期服务中，改用函数级封装 + 显式
with tf.device("/CPU:0"):卸载模型到 CPU 再del，之后再clear_session()
tf.data.Dataset 迭代器未耗尽引发资源滞留
使用 tf.data.Dataset.from_generator() 或复杂 pipeline 构建数据集时，迭代器对象（Iterator）本身持有图节点和设备内存引用。如果只取部分 batch 就丢弃迭代器（比如异常中断、提前 return），底层 CUDA kernel 和缓冲区可能未被清理。
立即学习“Python免费学习笔记（深入）”；
- 典型场景：HTTP 推理接口中，用户请求中途断连，
for x in dataset.take(n):未跑完就退出 - 验证线索：反复调用同一接口后，
tf.data.experimental.cardinality(dataset)返回 -2（unknown），且显存不降 - 安全做法：始终用
try/finally包裹迭代逻辑，确保iterator = iter(dataset)后执行next(iterator, None)直至StopIteration；或改用dataset.batch().as_numpy_iterator()落到 CPU 再处理
真正难处理的不是“怎么清内存”，而是“哪些东西你根本没意识到它还活着”——比如一个被 tf.function 捕获的闭包变量，或一个被 tf.py_function 内部引用的 NumPy 数组，它们会让整张图卡在内存里不动声色地吃掉显存。
