tensorflow默认预分配全部gpu显存，非bug而是设计行为；必须在import后立即调用tf.config.experimental.set_memory_growth(true)，且需在任何tf.*操作前执行，否则无效。
TensorFlow 默认会预分配全部可见 GPU 显存，而不是按需申请——这是它不自动释放显存的根本原因，不是 bug，而是设计行为。
tf.config.experimental.set_memory_growth(True) 必须在 import 后立即调用
这个配置必须在任何 tf.* 操作（包括模型构建、张量创建）之前执行，否则无效。一旦 TensorFlow 初始化了 GPU 设备，后续再调用就不起作用。
- 正确顺序：
import tensorflow as tf→ 立即调用set_memory_growth→ 再创建模型或数据 - 常见错误：先写了
model = tf.keras.Sequential(...)，再调set_memory_growth，此时显存早已被占满 - 验证是否生效：运行后观察
nvidia-smi，初始显存占用应很低（通常 100–300MB），而非直接跳到几 GB
多进程 DataLoader 会残留子进程显存
PyTorch 用户更常遇到这个问题，但 TensorFlow 的 tf.data.Dataset 若启用了 num_parallel_calls + prefetch，底层也可能 fork 子进程；主进程退出后，这些子进程仍持有 GPU 句柄，显存不会归还。
- 现象：
nvidia-smi显示 GPU Memory-Usage 不为 0，但ps aux | grep python找不到对应进程 - 排查命令：
fuser -v /dev/nvidia*，会列出所有持有 GPU 设备的 PID - 清理方式：
kill -9 PID（注意不要误杀其他任务），或重启 Python 进程前加os.system("fuser -k /dev/nvidia* 2>/dev/null")
Session 或 eager execution 上下文未清理干净
TF 2.x 默认启用 eager execution，但若代码中混用了 tf.function、tf.GradientTape 或显式创建了 tf.distribute.Strategy 实例（如 MirroredStrategy），其内部可能缓存 GPU 资源，仅靠 del model 或 gc.collect() 无法释放。
- 关键动作：
tf.keras.backend.clear_session()—— 它会重置默认图、清空层缓存、释放大部分 GPU 张量句柄 - 注意：该函数不保证 100% 归还显存，尤其当有未销毁的
tf.distribute.Strategy实例时，需先strategy._extended._rebuild_strategy()或直接避免复用 strategy 对象 - 建议模式：每个独立训练任务用全新 Python 进程（如用
subprocess.run启动脚本），从根本上隔离资源
真正难处理的不是单次显存泄漏，而是跨多个模型/任务时，GPU 句柄、CUDA 上下文、driver-level memory pool 的残留状态——它们往往不暴露在 Python 层，clear_session() 和 empty_cache() 都只是尽力而为。最稳妥的做法，仍是让每个任务独占一个进程，并在启动前用 set_memory_growth 锁死显存增长逻辑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
