tf.config.experimental.set_memory_growth必须在import tensorflow as tf之后、任何模型构建或tf.device之前立即调用，否则因GPU显存已被独占而静默失效。
为什么tf.config.experimental.set_memory_growth必须在导入后立即调用
因为TensorFlow默认一启动就独占所有GPU显存，后续再设内存增长策略已无效。这个调用必须放在import tensorflow as tf之后、任何模型构建或tf.device之前，否则会静默失效。
常见错误是把它写在训练循环里，或者等tf.keras.Model实例化完才调用——这时显存早已被分配完毕。
- 正确顺序：
import tensorflow as tf→gpus = tf.config.experimental.list_physical_devices('GPU')→for gpu in gpus: tf.config.experimental.set_memory_growth(gpu, True) - 如果用多卡，每张卡都要单独调用
set_memory_growth - 该设置对
tf.function内代码也生效，但无法回收已分配的显存块，只影响后续分配行为
batch_size不是唯一瓶颈：检查tf.data.Dataset预处理是否泄漏显存
显存溢出常被误判为模型太大或batch_size过高，但实际可能是tf.data.Dataset.map中用了tf.py_function或未关闭prefetch缓冲区导致显存持续累积。
尤其当map里调用NumPy操作并转回tf.Tensor时，容易触发隐式GPU拷贝；而prefetch(tf.data.AUTOTUNE)若数据管道本身有阻塞，缓冲区会无限堆积张量。
- 临时排查：把
dataset.prefetch注释掉，看OOM是否消失 - 避免在
map中做np.array(...).astype(np.float32)再转tf.convert_to_tensor，改用纯tf操作如tf.cast、tf.image.resize - 显式限制缓存：
dataset.cache().take(1000)比全量cache()更安全
混合精度训练下tf.keras.mixed_precision.Policy配置不当会翻倍显存占用
启用mixed_precision.Policy('mixed_float16')本应降低显存，但如果没配合tf.keras.mixed_precision.LossScaleOptimizer，或模型中有未适配的tf.float32层（如某些自定义tf.keras.layers.Layer），梯度计算反而会以float32保留中间结果，导致显存不降反升。
- 必须包裹优化器：
opt = tf.keras.mixed_precision.LossScaleOptimizer(opt) - 检查模型中是否有硬编码
dtype=tf.float32的tf.Variable，应改为dtype=None或跟随policy - 验证是否生效：打印
model.layers[0].dtype，应为float16；若仍是float32，说明policy未正确传播
tf.keras.backend.clear_session()不能解决训练中的OOM，但能防止Jupyter反复运行累积显存
这个函数只重置默认图和释放当前会话资源，在单次训练过程中调用无效；但它对交互式环境（如Jupyter）非常关键——每次重新运行训练单元格前若不清理，旧模型权重、中间张量、甚至tf.function编译缓存都会滞留在GPU上。
- 建议在训练脚本开头加：
import os; os.environ['TF_CPP_MIN_LOG_LEVEL'] = '2'，避免日志干扰判断 - Jupyter中每次运行前手动执行：
tf.keras.backend.clear_session()+ 重启内核（仅当clear_session无效时） - 注意：
clear_session()不会释放tf.data.Dataset已加载的缓存，需手动del dataset再重建
显存问题本质是GPU内存生命周期管理，不是单纯调小batch_size就能绕过的。最易忽略的是tf.data管道与混合精度策略之间的隐式耦合，以及交互式环境中会话残留。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
