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 句柄,显存不会归还。
调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强,支持文件上传与图片 URL 输入。
- 现象:
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() 无法释放。
立即学习“Python免费学习笔记(深入)”;
- 关键动作:
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 锁死显存增长逻辑。

















