<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mixed Precision on Nalar</title>
    <link>https://nalar.dev/tags/mixed-precision/</link>
    <description>Recent content in Mixed Precision on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 10 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/mixed-precision/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Prevent FP16 Gradient Underflow with Dynamic Loss Scaling</title>
      <link>https://nalar.dev/prevent-fp16-gradient-underflow-with-dynamic-loss-scaling/</link>
      <pubDate>Thu, 10 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/prevent-fp16-gradient-underflow-with-dynamic-loss-scaling/</guid>
      <description>&lt;h1 id=&#34;prevent-fp16-gradient-underflow-with-dynamic-loss-scaling&#34;&gt;Prevent FP16 Gradient Underflow with Dynamic Loss Scaling&lt;/h1&gt;&#xA;&lt;p&gt;Mixed-precision training can reduce memory use and accelerate supported operations, but &lt;code&gt;float16&lt;/code&gt; introduces a numerical problem that is easy to miss: some gradients are too small to survive in FP16. They can round to zero before the optimizer gets a chance to use them.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Loss scaling&lt;/strong&gt; addresses that problem by multiplying the loss before backpropagation, which multiplies the resulting gradients by the same factor. The gradients are divided by that factor before the optimizer update, so the intended update is unchanged when the arithmetic remains finite. &lt;strong&gt;Dynamic loss scaling&lt;/strong&gt; adjusts the factor during training so you don&amp;rsquo;t have to guess one fixed value for the whole run.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
