应优先启用 tensorflow 内存增长模式而非直接调小 batch_size；tf 2.x 中需在 import 后、建模前调用 tf.config.experimental.set_memory_growth(gpu, true)，使显存按需分配而非预占。
显存溢出时，batch_size不是唯一解法
直接调小 batch_size确实能缓解显存压力，但常掩盖更深层问题：TensorFlow 默认会预分配几乎全部 GPU 显存。哪怕模型很小、batch_size=1，也可能报 ResourceExhaustedError: OOM when allocating tensor——这不是真没内存，而是被“锁死”了。
真正该优先做的，是让 TensorFlow 按需申请显存。在创建 tf.Session（TF 1.x）或初始化 tf.config（TF 2.x）时启用内存增长模式：
# TF 2.x 推荐方式（必须在 import tensorflow 之后、任何模型构建之前执行）
import tensorflow as tf
gpus = tf.config.experimental.list_physical_devices('GPU')
if gpus:
for gpu in gpus:
tf.config.experimental.set_memory_growth(gpu, True)
注意：set_memory_growth 不能和 set_memory_limit 同时用；一旦设了限制，增长模式就失效。
tf.config.experimental.set_memory_growth 的实际效果与限制
开启后，GPU 内存使用量会随训练逐步上升，而不是一上来就占满。这对多卡环境、共享 GPU 的场景特别有用。
- 它只影响新创建的
tf.device('/GPU:x')上下文，对已启动的进程无效（重启 Python 才生效） - 不解决模型本身参数量过大导致的单次前向/反向显存峰值问题
- 某些旧驱动（nvidia-smi，观察
Memory-Usage是否缓慢爬升而非瞬间打满 - TF 1.x 中对应的是
config.gpu_options.allow_growth = True，但必须通过tf.ConfigProto传给Session
调小 batch_size 时要注意的三个隐性代价
batch_size 不是越小越安全，也不是线性影响显存。它和梯度累积、BN 层行为、学习率缩放强相关。
- BN 层在
batch_size 时统计不稳定，可能导致收敛变慢甚至发散；可改用 <code>tf.keras.layers.BatchNormalization(fused=False)或换为 GroupNorm - 学习率通常需按
sqrt(batch_size)缩放（线性缩放法则），否则 loss 曲线抖动剧烈 - 过小的
batch_size（如 1 或 2）会让 GPU 利用率暴跌，训练时间反而显著延长——用nvidia-smi -l 1观察Util%，低于 30% 就值得怀疑是否“为省显存牺牲太多”
还有哪些操作会悄悄吃掉显存？
显存溢出常来自非模型主干的“配角”：数据加载、中间缓存、调试代码。
-
tf.data.Dataset.prefetch(tf.data.AUTOTUNE)默认缓存一个 batch，但如果map函数里做了高维图像增强（如随机旋转+裁剪），临时 tensor 可能比原始数据大数倍 - 在
@tf.function外打印tensor.shape或调用.numpy()，会强制同步并驻留 CPU/GPU 内存副本 - Jupyter 中反复运行同一 cell，若定义了新
tf.Variable或tf.keras.Model，旧变量不会自动释放——需手动del model+gc.collect()，或重启 kernel - TF 2.10+ 默认启用 XLA 编译，某些图结构会增加显存占用；临时关闭可验证：设置环境变量
TF_XLA_FLAGS="--tf_xla_auto_jit=0"
显存问题从来不是单一参数能兜底的。最有效的排查路径是：先开 set_memory_growth，再用 nvidia-smi 和 tf.debugging.set_log_device_placement(True) 定位具体哪步爆掉，最后针对性调 batch_size 或重写数据流水线。
