NaN loss and grad encoutered at first epoch

Jeff1: <p>Encounter Gradient overflow and the model performance are really weird.</p>
<p>At about 1600 steps, the Mask language modeling loss became NaN, and after a few more steps everything crashed down to NaN. At first, I think it was a trivial coding problem and after a week of debugging I can’t really figure out how this occurs.</p>
<p>After utilizing <code>torch.autograd.detect_anomaly</code> it returns LogBackward returns with “Function ‘LogBackward0’ returned nan values in its 0th output.” I’ve already added a large eps=1e-3 to <code>torch.log</code> so this shouldn’t really happen, weird.</p>
<p>Things that have tried:</p>
<ul>
<li>Change the AMP from Apex to torch official ;</li>
<li>Self-made Cross Entropy Loss with larger eps to fit fp16 dynamic range ;</li>
<li>Fit with lower learning rate (from 1e-4 to 5e-5 to 1e-5) and also lower multiple ratios (for new layers);</li>
<li>Narrow down the interval of bp scaling (from 32768 to 256) ;</li>
<li>Utilize gradient clipping (unscaled gradient to 1.0) ;</li>
<li>Check the data for invalid input.</li>
</ul>
<p>Interesting fact:</p>
<p>I found that the minimum scaling threshold will affect when the model fails. Code snippet:</p>
<pre><code class="lang-auto">if scaler._scale &lt; min_thresh:
    scaler._scale = torch.tensor(min_thresh).to(scaler._scale)
</code></pre>
<p>when min_thresh is set to 256, it crashes at about 600 steps; to 128, 900 steps; 64, 1150 steps; 32, 1450 steps; not setting, 1650 steps (all under 5e-5 learning rate).</p>
<p>Hope someone can give me some further advice <img src="https://discuss.pytorch.org/images/emoji/apple/smiling_face_with_tear.png?v=12" title=":smiling_face_with_tear:" class="emoji" alt=":smiling_face_with_tear:" loading="lazy" width="20" height="20">  Thanks a lot</p>

ptrblck: <aside class="quote no-group" data-username="Jeff1" data-post="1" data-topic="163525">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/jeff1/48/46315_2.png" class="avatar"> Jeff1:</div>
<blockquote>
<p>I found that the minimum scaling threshold will affect when the model fails</p>
</blockquote>
</aside>
<p>Note that it is expected to see invalid gradients in a few iterations when amp in <code>float16</code> is used. If such an iteration is seen, the <code>GradScaler</code> will reduce its internal scaling factor and will skip the <code>optimizer.step()</code> call so that no parameters will be updated with these invalid gradients. It is not expected to see invalid outputs computed in the forward pass and if you are seeing such a behavior I would recommend to try to narrow down where exactly this invalid output is created.</p>

Jeff1: <p>Thanks for your kind advice and sorry for my late update.</p>
<p>It is a dual-stream model, XLM-roberta + BERT with no cross attention. I utilized <code>forward_hook</code> to check the forward process as well as gradients and parameters.</p>
<p>The parameters and the forward process seem to be fine now, except for some Infinity gradients detected at the contrastive loss temperature, the model’s gradient seems to gradually fail from superficial to deep layers. At first some NaN values were reported to be found at like <code>roberta_encoder.layer.0.query.weight</code> and some embedding layers, after a couple of hundred steps, NaN values were caught in deeper layers like <code>roberta_encoder.layer.3.dense.weight</code>, finally the whole model’s gradient became NaN, I can’t figure out how this could happen since the model works just fine in FP32 and a lot of efforts has been made to prevent any number getting out of fp16’s range.</p>
<p>Any further ideas?<br>
Thanks again!</p>

ptrblck: <p>No, I don’t have further ideas as it’s still unclear if the observed NaN gradients are expected and caused by a high loss scaling factor or if something else causes them. Your follow up just explains that you are still observing invalid gradients, which might be expected.</p>

Jeff1: <p>Oh, maybe I misunderstood your early advice <img src="https://discuss.pytorch.org/images/emoji/apple/frowning.png?v=12" title=":frowning:" class="emoji" alt=":frowning:" loading="lazy" width="20" height="20"></p>
<p>I have tried not to set the minimum scaling factor and the model just kept on skipping steps and shrinking the scaling factor until an error is raised. I also tried to set the init_scale to 2048.0 or smaller but it seems not working. Is this what you advise me to do?</p>
<p>Thanks a lot.</p>

Jeff1: <p>I finally figured out the problem.</p>
<p>Putting the division of <code>math.sqrt(self.head_dim)</code> after Query instead of after the matmul of Query and Key fixes the bug.</p>
<pre><code class="lang-auto">q = self.split_heads(self.q_proj(x)) / math.sqrt(self.head_dim)
k = self.split_heads(self.k_proj(x))
v = self.split_heads(self.v_proj(x))

attn_score = torch.matmul(q, k.transpose(-1, -2))
attn_probs = self.softmax(attn_score)
</code></pre>
<p>instead of</p>
<pre><code class="lang-auto">q = self.split_heads(self.q_proj(x))
k = self.split_heads(self.k_proj(x))
v = self.split_heads(self.v_proj(x))

attn_score = torch.matmul(q, k.transpose(-1, -2)) / math.sqrt(self.head_dim)
attn_probs = self.softmax(attn_score)
</code></pre>
<p>Do you know why this causes gradient overflow? I can’t figure out the reason, thanks.</p>