tf.keras.backend.clear_session()是唯一可靠释放gpu上下文的操作，需在训练/推理后立即调用；tf.data.cache()若无filename参数会常驻显存；多层资源释放需分层处理，不能依赖单一方法。
TensorFlow模型执行后显存不降，不是Python没删变量，而是底层C++运行时和GPU驱动根本没释放资源——del model或gc.collect()对它基本无效。
tf.keras.backend.clear_session() 是唯一可靠起点
这是TensorFlow 2.x中真正能重置GPU上下文、释放计算图节点和CUDA内存的操作。它会销毁当前默认的tf.keras.backend.get_session()（即使你没显式创建），并清空全局状态。
- 必须在模型训练/推理结束后立即调用，不能等脚本自然退出
- 若用
tf.distribute.MirroredStrategy，需在strategy scope外调用，否则报错RuntimeError: Cannot clear session inside a strategy scope - 多次调用无副作用，但不能替代正确的缓存策略——它救不了
.cache()塞满的显存
tf.data.cache() 是最隐蔽的显存钉子户
只要链式操作里出现.cache()，且没加filename参数，数据就会被常驻在GPU显存（或CPU内存）中，跨epoch不释放。这不是bug，是设计行为。
- 错误写法：
.batch(32).cache()→ 缓存的是32倍尺寸的batch张量，显存占用直接翻几十倍 - 危险组合：
.map(..., num_parallel_calls=tf.data.AUTOTUNE).cache()→ 并行预取提前加载大量样本，全被锁死在缓存里 - 验证方式：注释掉
.cache()，跑相同轮数，用nvidia-smi对比Memory-Usage曲线是否陡升
显存“看起来没释放”的真实原因不止一个
你看到tf.config.experimental.get_memory_info('GPU:0')['current']持续上涨，可能混合了三种独立机制：
- TensorFlow内存增长模式未关闭：默认
set_memory_growth(True)允许动态增长，但不自动收缩；应配合set_memory_limit()硬限显存上限 - 底层CUDA Context未销毁：即使clear_session()成功，某些驱动版本（如CUDA 12.2+ + driver 535）仍残留context，需重启Python进程才能彻底清理
- Python对象引用残留：比如把
model.predict()结果存进全局list，或日志模块持有了tensor，导致GC无法回收底层buffer
真正难处理的从来不是单次显存暴涨，而是多轮训练+缓存+分布式策略混用时，不同层级的资源释放时机错位——clear_session()只管Keras层，tf.data缓存要自己截断，CUDA context得靠进程级隔离。别指望一个函数搞定全部。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
