NaN梯度绝大多数源于前向计算中中间张量含NaN/inf，而非模型结构问题；需先用tf.debugging.check_numerics检查模型输出，再逐层拦截梯度并验证输入、权重初始化及硬件资源。
为什么tf.GradientTape里梯度突然变成NaN
绝大多数情况不是模型结构本身有问题，而是前向计算中某个中间张量已经含NaN或inf，导致反向传播时梯度污染。常见诱因包括：除零（如1 / 0）、对负数取对数（tf.math.log(-1.)）、softmax输入过大引发exp上溢、数值不稳定归一化（如方差接近0时做tf.nn.batch_normalization）。
关键判断点：先确认前向输出是否干净——在with tf.GradientTape() as tape:块内，对模型输出调用tf.debugging.check_numerics：
output = model(x) tf.debugging.check_numerics(output, "model output contains NaN/inf")
如果这行报错，问题就在前向；否则再检查梯度本身。
如何定位具体哪一层/哪个操作产生NaN梯度
不能只在最后用tape.gradient查结果，得逐层拦截梯度流。推荐在GradientTape中启用watch_accessed_variables=False，手动tape.watch()关注的变量，然后在gradient调用后立即检查：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 对每个可训练变量
v，拿到grad = tape.gradient(loss, v)后立刻加断言：tf.debugging.check_numerics(grad, f"grad w.r.t. {v.name}") - 若某层梯度出问题，回溯该层输入——在
call()里对inputs和outputs都插check_numerics - 特别注意自定义
tf.keras.layers.Layer中用了tf.math函数的地方，比如tf.math.rsqrt输入为0会直接产出inf
tf.debugging.check_numerics不生效？检查运行模式
这个调试工具默认只在tf.function图模式下生效，而 eager 模式需显式启用——如果你用tf.config.run_functions_eagerly(True)临时开启eager，check_numerics才能实时报错。但更稳妥的做法是：保持图模式，在@tf.function装饰的训练step里使用，并确保check_numerics没被优化掉（它不会被XLA或常量折叠删除，但要避免放在条件分支外侧）。
另一个常见疏漏：check_numerics只检查张量值，不检查tf.Variable初始值。务必检查权重初始化，比如tf.keras.initializers.RandomNormal(stddev=100)可能导致第一层激活爆炸。
绕过NaN继续训练？别这么做
有人用tf.where(tf.math.is_finite(grad), grad, 0.)掩盖问题，这只会让训练失效——梯度消失或方向错误，模型根本学不动。真正有效的临时缓解只有两个：
- 在损失函数前加
tf.clip_by_norm限制梯度模长，例如tf.clip_by_norm(gradients, 1.0)，仅用于快速验证是否梯度爆炸 - 把学习率降到极低（如
1e-6），看是否还出NaN——如果高学习率下稳定、低学习率反而出NaN，说明前向已有不稳定源，只是被放大了
最常被忽略的一点：GPU内存不足时，某些CUDA算子（尤其是tf.nn.softmax_cross_entropy_with_logits）可能静默返回NaN而非报错，换CPU设备复现能快速区分是算法问题还是硬件资源问题。
