tf.keras.Model.fit()报OOM错误主因是TensorFlow默认预分配全部GPU显存，叠加batch过大、图像尺寸高、中间层未释放及tf.data.cache()缓存全量数据所致；应立即调用tf.config.experimental.set_memory_growth()启用动态显存分配，并同步调小batch size、降低输入分辨率、优化tf.data流水线与GradientTape使用。
为什么tf.keras.Model.fit()突然报ResourceExhaustedError: OOM when allocating tensor
这不是模型真的需要那么多显存，而是TensorFlow默认把整块GPU显存预分配满（尤其在1.x和2.x早期版本），再叠加batch过大、输入图像尺寸太高、模型中间层输出没及时释放，就直接触发OOM。常见于多卡环境没设CUDA_VISIBLE_DEVICES，或用了tf.data.Dataset.cache()把整个数据集缓存进显存。
用tf.config.experimental.set_memory_growth()动态分配显存
这是最常用也最有效的缓解手段，告诉TensorFlow“按需申请，别一口吞完”。注意它必须在导入tensorflow后**立即调用**，且只对当前GPU生效：
import tensorflow as tf
gpus = tf.config.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) # 初始化后不能再修改
- 不支持Windows上的CUDA 11.2+与TF 2.8+组合（会报
Failed to enable memory growth） - 若用
tf.distribute.MirroredStrategy，得在strategy创建前调用 - 设了这个之后，
nvidia-smi看到的显存占用会“缓慢上涨”，而非启动即占满
控制batch size和输入尺寸比调显存参数更直接
显存消耗≈batch_size × height × width × channels × model_depth × sizeof(float32)。很多用户花一小时调set_memory_limit()，不如把batch_size=32改成16，或把512×512图缩到384×384——立刻见效。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 用
tf.data.Dataset.batch(batch_size, drop_remainder=True)避免最后一个小batch导致形状不一致 - 训练时用
tf.image.random_crop()代替全图加载，能显著降低单步峰值显存 - 验证阶段可临时把
batch_size设为训练时的2–4倍（因无梯度计算），但要注意model.evaluate()内部仍会按batch分片，不是真省显存
tf.function里嵌套tf.GradientTape容易隐式累积显存
自定义训练循环中，如果在@tf.function装饰的函数里反复新建tf.GradientTape(persistent=False)，TensorFlow可能无法及时回收中间张量。尤其当tape包裹了model(x)又调了多次tape.gradient()，会把所有前向中间结果都留着。
立即学习“Python免费学习笔记（深入）”；
- 确保每个
tf.GradientTape只调一次gradient()，或明确设persistent=True并手动del tape - 避免在
@tf.function内做print()、tf.print()等副作用操作，它们可能阻止图优化，间接拖慢显存释放 - 怀疑是tape问题？先注释掉
@tf.function，用eager模式跑几轮看是否OOM消失——这是快速定位手段
TensorFlow的显存管理不是“开个开关就万事大吉”，set_memory_growth只是起点，真正稳住训练得同时压batch_size、砍输入分辨率、检查tf.data流水线有没有意外缓存，还有自定义训练逻辑里那些看不见的tape和variable引用。
