PyTorch训练中NaN损失常源于前向过程，需在loss.backward()前用torch.isnan(loss).any()检查；常见原因包括log(0/负数)、除零未加eps、输入含NaN/Inf，以及CrossEntropyLoss标签越界或非long型。
PyTorch训练中出现NaN损失，先检查loss是否在反向传播前就已是NaN
很多情况下，loss刚算出来就是nan，而不是反向传播后才崩。用torch.isnan(loss).any()在loss.backward()前立刻检查——如果为True，说明问题出在前向逻辑或输入数据，和梯度无关。
常见诱因包括：
-
log(0)或log(negative)：比如自定义交叉熵时直接对未归一化的logits做torch.log()，或softmax输出有零值（极小概率，但torch.nn.CrossEntropyLoss内部已规避） - 除零：如手动实现Dice Loss、IoU Loss时分母没加
eps=1e-7 - 输入含NaN/Inf：从
DataLoader读入的tensor本身就有nan（例如预处理时用了np.nan_to_num但没设nan=0，或图像读取失败返回全零再做归一化导致除零）
排查torch.nn.CrossEntropyLoss中的隐式除零与标签越界
torch.nn.CrossEntropyLoss本身不会除零，但它对输入和标签有强约束：标签必须是long型且每个值在[0, num_classes - 1]范围内。越界会导致内部log_softmax输出-inf，后续计算产生nan。
实操建议：
立即学习“Python免费学习笔记（深入）”；
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 在送入loss前加断言：
assert labels.dtype == torch.long and 0 - 若标签来自文件或外部API，打印
labels.unique()确认无异常值（如-1、255等占位符未被过滤） - 不用
ignore_index时别乱设——设了但标签里没这个值，不影响；但设错（如设成-100而实际标签含-1），会把不该忽略的也干掉，间接导致类别分布异常，增大数值不稳风险
启用torch.autograd.set_detect_anomaly(True)定位具体哪层崩了
该开关会让backward()在遇到NaN/Inf时抛出完整栈追踪，指出是哪个forward输出首次引入异常。但它有性能开销，只应在调试时开启。
关键点：
- 必须在
loss.backward()前设置，且只对当次反向传播生效 - 它捕获的是“梯度流中的NaN”，不是前向输出的NaN——所以要配合前向检查才能闭环
- 常见报错位置：自定义
Module里的torch.sqrt()没防负数、torch.pow(x, 0.5)输入为负、LayerNorm输入方差为0（全同特征）导致除零
批量检查输入张量是否含NaN/Inf，避免问题扩散
在DataLoader迭代开头插入简易校验，比等loss爆了再查快得多：
for batch in dataloader:
if torch.isnan(batch["image"]).any() or torch.isinf(batch["image"]).any():
print("NaN/Inf in image")
continue
if torch.isnan(batch["label"]).any():
print("NaN in label")
continue
# ... forward更彻底的做法是封装一个NaNChecker类，在__getitem__末尾或collate_fn里统一检查。注意：torch.isnan对非浮点类型（如uint8图像）返回全False，务必确认张量dtype。
容易被忽略的一点：GPU上torch.isnan可能略慢，若校验影响训练速度，可只在device="cpu"时开启，或每100个batch检查一次。
