Why to keep parameters in float32, why not in (b)float16?

AlbertZeyer: <p>I wonder if I should keep my model parameters in float16 or bfloat16?</p>
<p>This is probably an orthogonal aspect to automatic mixed precision / autocast, or maybe mixed precision does not make sense anymore then?</p>
<p>But leaving that aside, why would you not do this? Is there any downside? Wouldn’t you safe even more memory?</p>
<p>In all the documents on mixed precision training, I never really see this part addressed.</p>
<p>I also found this somewhat inconclusive post: <a href="https://discuss.pytorch.org/t/performance-training-speed-of-autocast-bfloat16/158183" class="inline-onebox">Performance (Training Speed) of Autocast Bfloat16</a></p>

AlbertZeyer: <p>Ah, I was just checking the original paper introducing <a href="https://arxiv.org/abs/1710.03740" rel="noopener nofollow ugc">automatic mixed precision training</a>, and it explains it (Sec 3.1):</p>
<blockquote>
<p>In mixed precision training, weights, activations and gradients are stored as FP16. In order to match the accuracy of the FP32 networks, an FP32 master copy of weights is maintained and updated with the weight gradient during the optimizer step. In each iteration an FP16 copy of the master weights is used in the forward and backward pass. …</p>
<p>While the need for FP32 master weights is not universal, there are two possible reasons why a number of networks require it. One explanation is that updates (weight gradients multiplied by the learning rate) become too small to be represented in FP16 - any value whose magnitude is smaller than 2^(−24) becomes zero in FP16. …</p>
<p>Another explanation is that the ratio of the weight value to the weight update is very large. In this case, even though the weight update is representable in FP16, it could still become zero when addition operation right-shifts it to align the binary point with the weight. …</p>
</blockquote>

J_Johnson: <p>This thread explains the difference:</p>
<aside class="quote" data-post="4" data-topic="176596">
  <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/j_johnson/48/55494_2.png" class="avatar">
    <a href="https://discuss.pytorch.org/t/why-bf16-do-not-need-loss-scaling/176596/4">Why bf16 do not need loss scaling?</a> <a class="badge-category__wrapper " href="/c/mixed-precision/27"><span data-category-id="27" data-drop-close="true" class="badge-category "><span class="badge-category__name">mixed-precision</span></span></a>
  </div>
  <blockquote>
    bfloat16 can go all the way down to ~10e-38 whereas float16s smallest value is ~6e-8. Does it make sense why that might be beneficial when many model parameters can often be below that threshold?
  </blockquote>
</aside>

<p>bfloat16 is more ML friendly. It gives a much wider range of values with just less precision in each stepwise difference.</p>
<p>Take any large model and print out your parameters:</p>
<pre><code class="lang-auto">for param in model.parameters():
    print(param)
</code></pre>
<p>If you’re in float32 and the model has in excess of 1 billion parameters, you will likely see many of the values are very small.</p>
<p>However, the smallest normal positive value float16 can have is 6.10 × 10−5. While bfloat16 can go down to 10-38. Hence float16 may require additional scaling.</p>
<p>Additionally, due to the nature of bfloat16 capping precision, it may act as an additional regularization to prevent some overfitting. Thus making models in bfloat16 better able to generalize.</p>

AlbertZeyer: <p>Sorry, I realize my question could be misinterpret.</p>
<p>I did not ask on float16 vs bfloat16.</p>
<p>I asked about float32 vs (b)float16. In AMP training, you still have parameters in float32, and then they are automatically casted. My question is, why is this casting needed? Why not directly store the params in (b)float16?</p>

ptrblck: <p>Your posted reference explains it already and master parameter/gradient copies would be needed. This mechanism was used in the legacy <code>apex.amp</code> as its <code>O2</code> style mixed-precision training.</p>