典型报错是resourceexhaustederror: oom when allocating tensor with shape...，本质是显存碎片化或预分配占满导致无法分配连续内存块，而非物理显存不足。
显存溢出（OOM）错误的典型报错是什么
TensorFlow 报 OOM 错误时，最常见的是这一行：ResourceExhaustedError: OOM when allocating tensor with shape...。它不是说 GPU 没电了，而是当前计算图尝试申请一块显存，但显存池里找不到连续、够大的空闲块——哪怕 nvidia-smi 显示还有几 GB 剩余。
关键点在于：TensorFlow 默认会预分配几乎全部可见 GPU 显存（尤其在 1.x 和 2.0–2.4 的 eager 模式下），导致后续模型加载或 batch 扩容直接失败。这不是模型太大，而是显存被“占着不用”。
常见诱因包括：
- 多个
tf.keras.Model实例未显式del或清图 - 训练中
tf.data.Dataset使用cache()且数据过大 - Jupyter 中反复运行 cell 导致旧图残留（
tf.keras.backend.clear_session()不总管用）
如何让 TensorFlow 按需分配显存（推荐方案）
从 TensorFlow 2.0 开始，最稳妥的方式是在导入 TensorFlow 后、创建任何模型前，立即配置内存增长策略：
import tensorflow as tf
<p>gpus = tf.config.experimental.list_physical_devices('GPU')
if gpus:
try:
for gpu in gpus:
tf.config.experimental.set_memory_growth(gpu, True)
except RuntimeError as e:
print(e)</p>
这会让每个 GPU 设备启用“按需增长”模式：初始只分配极小显存，后续随 tensor 创建逐步增加。注意两点：
- 必须在
tf.function、tf.keras.Model、甚至tf.random.normal等任何 GPU 操作之前调用 - 不能和
set_memory_limit混用；二者互斥 - 对多卡环境，需对每个
gpu单独设置
batch size 太大导致 OOM 怎么快速验证和调参
不要一上来就改模型结构。先确认是不是 batch size 过载：把 batch_size 从 32 降到 16 → 8 → 4，看是否仍报 OOM。如果 batch_size=1 都挂，说明问题不在 batch，而在模型本身或数据预处理逻辑。
更可靠的做法是用 tf.data.Dataset 的 prefetch + cache 组合做压力测试：
dataset = dataset.batch(8).prefetch(tf.data.AUTOTUNE) # 如果这里就 OOM，说明单个 batch 的 tensor 已超限（比如图像尺寸 1024×1024 三通道 × 8） # 改成 .batch(2) 再试
注意：cache() 会把整个数据集加载进显存（如果 map 后的数据已在 GPU 上），务必确认缓存的是 CPU 张量，或干脆去掉 cache 先跑通。
为什么 tf.keras.backend.clear_session() 有时无效
tf.keras.backend.clear_session() 只清理 Python 端的 Keras 图与变量引用，不释放已由 CUDA 分配的显存块。尤其在以下情况完全失效：
- 使用了
tf.function编译的模型（底层图已固化在 GPU 内存池） - 有未被 gc 回收的 tensor 引用（例如存在全局 list 存了中间输出）
- 用了
tf.distribute.MirroredStrategy，session 清理不触达子进程显存
真正释放显存的方法只有两个：重启 Python 进程（Jupyter 就是 “Kernel → Restart”），或在代码开头强制设好 set_memory_growth 避免预占。
TensorFlow 的显存管理不是黑盒，但它依赖你“在第一行就做对选择”。一旦预分配发生，后面所有技巧都只是打补丁。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
