关于nan, 梯度爆炸，loss爆炸 不完全总结笔记（自用）

1. 加自动监测函数找异常值

import torch
# 正向传播时：开启自动求导的异常侦测
torch.autograd.set_detect_anomaly(True)

# 反向传播时：在求导时开启侦测
with torch.autograd.detect_anomaly():
	loss.backward()

2. 自定义的loss注意除法时分母不是0

注意分母加eps保证计算稳定性

3. log(0), sqrt(0) 会导致nan，0 * inf也会变成nan

判断nan不能用 == 或 is, 要用numpy.isnan() / torch.isnan()

4. 脏数据

有可能只有某些input会导致nan，一开始就先shuffle=False保证每次读取数据的顺序是一样的，方便定位

5. fp16

曾经gradient & loss上来就是nan，求助万票，一条评论问我有没有用fp16, 当时还不理解这跟半精度有什么关系。后来发现bug还真的跟半精度有关。args.fp16没有控制到一层LayerNorm的初始化，导致我明明args.fp16=False，仍然用了半精度的FusedLayerNorm，然后当时我的batch_size又很小，所以假如batch内的divergence不够的话，有可能两个差异很小的数半精度了之后差异就变成0了，那如果某个地方需要divide by variance就直接nan了。。。

6. BatchNorm的坑

这点我还没遇到，看别人总结的。

BatchNorm会用到running_mean & running_variance. 假如batch_size过小或者数据shuffle的不好会导致running_mean & running_variance严重偏离数据实际的值，导致loss跌宕起伏，梯度变化异常，weight也变化异常，最终导致下一个batch继续往错误的方向偏离。可考虑加大batch_size或者计算好数据集的mean/var将其freeze.

还看到一个觉得有点东西：如果最后一个batch刚好只剩下一个sample，再用BatchNorm就会报错： ValueError: Expected more tham 1 value per channel when training, got input size 1. 解决办法貌似只能提前看一下 num_of_samples % batch_size会不会余数恰好是1？？

7. loss.item()

这也是在csdn上看的先记下来。记录每个batch返回的loss时一定要取loss.item()， 否则会记录产生loss的计算图内存占用暴增

8. optimizer weight_decay隐藏bug

这条依旧是从千奇百怪的csdn中搬运。假如某一个forward pass并没有用到某些层的参数，那么backprop loss时这些参数并不会得到gradients，然而如果有weight_decay，那么对于这些没有用到的参数，就只有weight_decay在发挥作用。假如持续这样，那就会导致参数趋近于0… 谨慎在有weight_decay的情况下，forward没有用到的参数，暂时不要传给optimizer。（感觉这个坑适用于我的情况诶，就是同一个model要handle多种任务）

9. 无则加勉：交叉熵前面要有负号。。。否则会往无穷方向优化平地垂直起飞。。。

10. Pooling里面stride > kernel_size会出现nan

11. 多GPU处理机制

就这两天应该会继续研究这个问题，搞不好能发一篇单独的博文

1）在各个GPU上初始化模型
2）Forward时把一个batch分配到各个GPU上计算
3）Forward输出在main GPU上汇总，计算loss并backprop，更新main GPU上的weights
4）把main GPU上的weights复制到其他GPU上