NaN梯度在训练中期突然出现主要是因数值不稳定在反向传播中逐层放大，尤其在log(0)、softmax输入溢出等边界情况下产生且不可逆；应启用急切执行定位、裁剪输入、优先使用clipvalue而非clipnorm、合理设置batch size并搭配loss scaling，自定义损失函数须校验输入有限性。
为什么NaN梯度总在训练中期突然出现？
这不是初始化或学习率设得太高那么简单——多数情况是数值不稳定在反向传播中被逐层放大，尤其当模型含tf.nn.softmax、tf.math.log或自定义损失函数时，输入接近边界值（比如log(0)、softmax输入过大导致exp溢出）会直接产出NaN，且一旦出现就不可逆地污染整个计算图。
实操建议：
- 在
model.compile()后加run_eagerly=True临时启用急切执行，方便用tf.print定位哪一层输出首次变NaN - 检查所有
log类操作：把tf.math.log(x)换成tf.math.log(tf.clip_by_value(x, 1e-8, 1e8)) - 对
softmax前的 logits 做裁剪：logits = tf.clip_by_value(logits, -10.0, 10.0)，避免exp爆炸
tf.keras.optimizers.Adam的clipnorm和clipvalue怎么选？
二者作用不同，误用反而掩盖问题。如果梯度本身已含NaN，clipnorm会在归一化前就失效；而clipvalue直接截断梯度值，更适用于防止数值溢出但不解决源头。
实操建议：
- 优先用
clipvalue=1.0（而非clipnorm），因它对含NaN的梯度仍能生效（NaN会被clip_by_value转为inf再被优化器丢弃） - 若必须用
clipnorm，确保gradient_norm计算前无NaN：可在tf.GradientTape内手动检查tf.reduce_all(tf.is_finite(grad)) - 不要依赖
clipnorm掩盖数据异常——它只是“止血”，不是“消炎”
Batch size太小或太大都会诱发NaN？
小batch容易让梯度估计方差过大，单步更新剧烈；大batch则放大数值误差，尤其在混合精度训练中，float16下1e-5级梯度可能直接下溢为0，后续除法产生inf再变NaN。
实操建议：
- 从
batch_size=32起步，逐步加倍测试，同时监控tf.debugging.check_numerics输出 - 启用混合精度时，务必搭配
tf.keras.mixed_precision.LossScaleOptimizer，否则loss_scale默认为None会导致缩放失效 - 若用
tf.data.Dataset，确认prefetch和cache没引入隐式类型转换（如int64标签被转成float64再参与计算）
自定义损失函数里最容易漏掉的NaN陷阱
用户写的tf.keras.losses.Loss子类常忽略输入合法性校验，比如用tf.reduce_mean前未过滤NaN样本，或在tf.where条件中传入未裁剪的logit。
实操建议：
- 所有自定义损失函数开头加
tf.debugging.assert_all_finite(y_pred, 'y_pred contains NaN') - 避免
tf.math.divide_no_nan(a, b)这种“伪安全”写法——它只防0/0，不防inf/inf或NaN/b - 用
tf.where做掩码时，条件表达式必须先过tf.clip_by_value，例如：mask = tf.where(tf.abs(x)
真正棘手的是那些不报错但缓慢污染梯度的路径——比如某层BatchNormalization在training=False下用了过期的moving_mean，导致后续层输入分布偏移，几轮后才累积出NaN。这类问题只能靠逐层tf.print+梯度直方图观察，没法靠配置一步修复。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
