如果你剛學編程不久大概率見過這張流傳很廣的圖 0.1 0.2 0.30000000000000004很多人的第一反應是Python 的加法是不是有問題或者編譯器是不是有 bug還有人會專門寫篇文章吐槽“浮點數(shù)真垃圾”。但如果你真正去讀 IEEE 754 標準去理解浮點數(shù)在內(nèi)存里是怎么存放的就會發(fā)現(xiàn)這些“陷阱”不是異常而是必然。0.1 0.2 不等于 0.3恰恰說明這個標準設計得足夠通用只是它的通用性覆蓋不了“十進制小數(shù)恰好等于二進制小數(shù)”這種直覺。本文標題是“浮點數(shù)和陷阱”這里的“陷進”我就當它是“陷阱”來寫。我會從最底層的位布局講起講到精度丟失、大數(shù)吞小數(shù)、比較失敗、溢出下溢這些經(jīng)典問題再給出一套可以落地的規(guī)避方案。最后我會把視野拉高一點聊聊深度學習模型部署里 fp32、fp16、bf16、tf32 應該如何選型——這也是近兩年把“浮點數(shù)”話題重新推向熱門的真實場景。讀完這篇文章你至少能回答三個問題浮點數(shù)為什么會丟精度能丟多少寫業(yè)務代碼時哪些地方必須避開浮點數(shù)做模型推理時fp16、bf16、tf32 到底怎么選1. 這篇文字真正要解決的問題先說一個容易讓新手困惑的點浮點數(shù)在絕大部分編程語言里都是默認的小數(shù)類型。你用 Python 寫0.1用 Java 寫0.1f用 C 寫0.1語言都會自動把它當成浮點數(shù)來處理。這就造成了一個假象浮點數(shù)等于小數(shù)小數(shù)的一切運算規(guī)則都可以套在浮點數(shù)上。但事實是浮點數(shù)是一套非常底層的標準化二進制格式它追求的是用有限位表示盡量大范圍的數(shù)而不是“精確表示所有十進制小數(shù)”。這兩個目標之間存在根本沖突由此產(chǎn)生了大量開發(fā)中常見的“莫名其妙”的現(xiàn)象累加很多次之后結果比預期小了一點。兩個“相近”的數(shù)相減結果出現(xiàn)巨大誤差。浮點數(shù)直接和 0 比較永遠不相等。數(shù)據(jù)庫字段用 float 存儲金額對賬時賬目不平。串口打印浮點數(shù)時只輸出一堆科學計數(shù)法或者亂碼。深度學習模型訓練時loss 為 NaN原因可能只是梯度下溢。這些問題分散在不同語言、不同框架里但根源只有一個大家對 IEEE 754 底層機制不夠清楚。本文不是簡單列幾個“避坑技巧”而是把這些坑的成因串起來讓你以后遇到浮點數(shù)問題自己能推理出原因而不是靠搜答案碰運氣。2. IEEE 754 核心概念符號位、指數(shù)位、尾數(shù)位當前幾乎所有現(xiàn)代 CPU、GPU、編程語言都采用 IEEE 754 標準來表示浮點數(shù)。這個標準的核心思路是把一個數(shù)拆成符號、指數(shù)、尾數(shù)三個部分在有限的 bit 里存儲。最常見的兩種格式類型總位數(shù)符號位指數(shù)位尾數(shù)位約等于十進制精度float單精度3218237 位有效數(shù)字double雙精度641115215~16 位有效數(shù)字以 32 位 float 為例它的內(nèi)存布局是這樣的0 00000000 00000000000000000000000 ^ ^ ^ 符號 指數(shù) 尾數(shù)符號位0 表示正數(shù)1 表示負數(shù)。指數(shù)位用來表示數(shù)值的“范圍量級”但存儲的是經(jīng)過偏移后的值不是直接存指數(shù)。尾數(shù)位用來表示數(shù)值的“精度”存儲的是小數(shù)點后的二進制數(shù)字。這樣設計的直接好處是同樣 32 位你可以表示從很小很小的數(shù)到很大很大的數(shù)動態(tài)范圍遠超 32 位整數(shù)。但代價就是精度有限尾數(shù)只有 23 位超出部分必須舍入。這就是“浮點”兩個字的含義小數(shù)點不是固定的它會根據(jù)指數(shù)“浮動”從而用有限的位數(shù)覆蓋一個很大的數(shù)值范圍。2.1 規(guī)格化數(shù)與非規(guī)格化數(shù)IEEE 754 標準里大部分普通數(shù)都屬于規(guī)格化數(shù)。規(guī)格化數(shù)的尾數(shù)部分默認前面的整數(shù)位是 1所以尾數(shù)位實際上多了一位有效精度標準文檔里通常把這種隱藏的 1 稱為“隱式位”或“隱藏位”。比如單精度 float 的尾數(shù)雖然只有 23 位但加上隱藏位實際有效精度是 24 位二進制。所以我們在計算十進制有效數(shù)字時大約說 float 有 7 位有效數(shù)字double 有 15~16 位。當一個數(shù)非常接近 0指數(shù)部分已經(jīng)小到無法再表示規(guī)格化數(shù)時標準會轉(zhuǎn)入非規(guī)格化數(shù)模式。這時隱藏位不再生效精度會進一步下降但好處是數(shù)值可以無限接近 0不會突然跳到一個很大的“最低規(guī)格化數(shù)”。非規(guī)格化數(shù)的存在主要在數(shù)值計算中避免“突然下溢成 0”的尷尬。這個概念在普通業(yè)務開發(fā)里不常遇到但在科學計算、深度學習訓練里非常重要。很多人訓練模型時一旦梯度很小就會碰到非規(guī)格化數(shù)帶來的性能下降或精度問題。3. 為什么 0.1 0.2 不等于 0.3這是浮點數(shù)最經(jīng)典的入門問題。要理解它不能只看十進制要先把十進制小數(shù)轉(zhuǎn)成二進制小數(shù)。十進制整數(shù)轉(zhuǎn)二進制用除法十進制小數(shù)轉(zhuǎn)二進制用乘法十進制小數(shù) 0.125 轉(zhuǎn)二進制0.125 * 2 0.25整數(shù)位為 0 0.25 * 2 0.5 整數(shù)位為 0 0.5 * 2 1.0 整數(shù)位為 1結束所以 0.125 的二進制是0.001這是一個能精確表示的十進制小數(shù)。再看 0.10.1 * 2 0.2整數(shù)位為 0 0.2 * 2 0.4整數(shù)位為 0 0.4 * 2 0.8整數(shù)位為 0 0.8 * 2 1.6整數(shù)位為 1 0.6 * 2 1.2整數(shù)位為 1 0.2 * 2 0.4整數(shù)位為 0 ...到這里你會發(fā)現(xiàn)0.1 的二進制小數(shù)會一直循環(huán)下去是一個無限循環(huán)小數(shù)。0.2 也是無限循環(huán)小數(shù)0.3 也是。計算機只能用有限的 32 位或 64 位去存它所以必然要做舍入。這意味著0.1 本身在內(nèi)存里就不是精確的 0.1只是“最接近 0.1 的那個二進制浮點數(shù)”。兩個不精確的數(shù)相加結果自然也不精確于是就會產(chǎn)生0.30000000000000004這種結果。用代碼驗證一下print(0.1) print(0.2) print(0.1 0.2) print(0.1 0.2 0.3)輸出0.1 0.2 0.30000000000000004 False注意Python 打印 0.1 時顯示的是0.1不是0.10000000000000000555這是因為 Python 對浮點數(shù)做 repr 時會找到一個最短的十進制字符串保證它轉(zhuǎn)回來還是同一個浮點數(shù)。這是一種“友好顯示”策略不代表浮點數(shù)內(nèi)部就是精確的。Java 也會遇到同樣的問題public class FloatDemo { public static void main(String[] args) { double a 0.1; double b 0.2; System.out.println(a b); System.out.println(a b 0.3); } }輸出0.30000000000000004 false4. 浮點數(shù)的四大經(jīng)典陷阱理解了底層原理我們再回頭看開發(fā)中常見的四類問題就會覺得這些都是“活該”而不是“靈異事件”。4.1 精度丟失任何超出尾數(shù)位精度的數(shù)都無法精確表示。比如 0.1234567890123456789 0.12345678901234568 999999999999999999.0 # 太大用 double 也無法精確 1000000000000000000.0對于精確性要求極高的場景如金額計算、科學計算中的關鍵參數(shù)直接使用 float/double 是危險行為。4.2 大數(shù)吞小數(shù)當一個很大的數(shù)加上一個很小的數(shù)時小數(shù)可能直接被“吃掉”。因為浮點數(shù)表示法里絕對精度是跟指數(shù)相關的數(shù)越大相鄰兩個可表示數(shù)之間的間隔越大。 16777216.0 1.0 16777216.016777216 是 2 的 24 次方在單精度 float 中這個數(shù)附近的“步長”已經(jīng)大于 1所以加 1 等于沒加。double 里也會有類似問題只是閾值更大。這個陷阱在累加統(tǒng)計時非常危險。比如一個循環(huán)要往一個 double 變量里累加 0.1循環(huán)十億次結果不會是你期望的 1 億而可能差出一截。4.3 溢出與下溢指數(shù)位的位數(shù)決定了浮點數(shù)的表示范圍。單精度 float 的最大值大約 3.4e38超過這個值會發(fā)生上溢變成無窮大。單精度 float 的最小規(guī)格化正值大約 1.18e-38小于這個值會進入非規(guī)格化區(qū)間再小就變成 0。上溢后程序不一定報錯而是會得到一個inf繼續(xù)參與計算可能產(chǎn)生nan。 1e308 * 10.0 inf在深度學習訓練里下溢更常見。如果模型輸出經(jīng)過 softmax 后非常小然后在反向傳播中繼續(xù)傳遞梯度可能直接變成 0網(wǎng)絡就“學不動”了。4.4 比較判斷失敗這是業(yè)務代碼里最容易踩的坑。很多人寫代碼時會對浮點數(shù)做“相等”判斷if (score 0.5) { // do something }如果 score 是經(jīng)過多步加法計算出來的 0.5它很可能在二進制表示里并不是精確的 0.5比較結果就是 false。更危險的是有些場景下比較結果“大多數(shù)時候是對的”只在某些特殊輸入下出錯這種 bug 非常難排查。正確做法是使用誤差范圍abs(a - b) epsilon或者使用 Decimal、整數(shù)、字符串比較等替代方案。5. 不同編程語言的解決方案對比浮點數(shù)陷阱是所有語言共通的但不同語言提供了不同的解決工具。5.1 Python用 Decimal 做精確十進制運算Python 官方提供了decimal標準庫專門用于需要精確十進制表示的場景比如金額計算。from decimal import Decimal, getcontext # 設置精度 getcontext().prec 28 a Decimal(0.1) b Decimal(0.2) print(a b) # 0.3 print(a b Decimal(0.3)) # True注意Decimal(0.1)是從字符串構造而不是從 float 構造。如果寫成Decimal(0.1)它會把已經(jīng)丟失精度的 float 值原樣轉(zhuǎn)進去反而更糟from decimal import Decimal print(Decimal(0.1)) # 0.1000000000000000055511151231257827021181583404541015625 print(Decimal(0.1)) # 0.1這是很多初學者容易忽略的細節(jié)。使用 Decimal 時只要能保證輸入來自字符串或整數(shù)計算過程就是可控的。代價是 Decimal 運算比原生 float 慢不少不適合大規(guī)模數(shù)值計算。5.2 Java使用 BigDecimal并優(yōu)先使用字符串構造Java 的對應工具是BigDecimalimport java.math.BigDecimal; public class DecimalDemo { public static void main(String[] args) { BigDecimal a new BigDecimal(0.1); BigDecimal b new BigDecimal(0.2); BigDecimal sum a.add(b); System.out.println(sum); // 0.3 System.out.println(sum.compareTo(new BigDecimal(0.3)) 0); // true } }同樣建議使用字符串構造BigDecimal a new BigDecimal(0.1);避免使用new BigDecimal(0.1)因為 double 參數(shù)版本會把浮點數(shù)的二進制表示“如實”轉(zhuǎn)成 BigDecimal結果會是一長串錯誤值。BigDecimal 比較大小建議使用compareTo而不是equals因為equals會比較 scale1.0和1.00在equals下不相等但在數(shù)值上是相等的。5.3 金額計算場景使用最小單位整數(shù)除了 Decimal/BigDecimal還有一種非常工程化的做法金額不使用小數(shù)存儲而是使用“分”作為單位用整數(shù)存儲。比如 12.34 元存成 1234 分。后續(xù)所有加減乘除都在整數(shù)域進行不存在任何浮點數(shù)精度問題。只有在展示給用戶時才做一次除法這樣既簡單又高效。使用這種方式時要小心單位換算本身可能引入小數(shù)。比如費率是 0.003你算手續(xù)費時要先思考清楚精度規(guī)則避免出現(xiàn)“分”以下的舍入誤差。6. 深度學習模型部署中的浮點數(shù)選型fp32、fp16、bf16、tf32浮點數(shù)不只是編程語言里的一個坑它同時也是深度學習性能優(yōu)化的核心戰(zhàn)場。近年來GPU 硬件和深度學習框架都開始強調(diào)低精度計算fp16、bf16、tf32、int8。很多人以為“低精度就是會損失精度、讓模型變差”但實際情況要復雜得多。格式全稱指數(shù)位尾數(shù)位相對 fp32 的精度主要用途fp32單精度浮點823基準訓練、推理兜底精度fp16半精度浮點510較低范圍窄移動端推理、部分訓練加速bf16Brain Floating Point87范圍同 fp32精度較低大模型訓練、分布式訓練tf32Tensor Float 32810介于 fp16 和 fp32 之間NVIDIA Ampere 架構加速計算6.1 fp16范圍窄但速度確實快fp16 只有 16 位其中指數(shù)位只有 5 位可以表示的最大值大約是 65504最小規(guī)格化正數(shù)大約是 6.1e-5。如果訓練過程中出現(xiàn)了大于 65504 的中間結果fp16 會直接變成 inf。所以 fp16 訓練通常會配備“l(fā)oss scaling”機制把 loss 乘上一個大的縮放因子讓梯度不至于太小而下溢等計算完梯度后再反過來縮放。這套機制在混合精度訓練框架如 PyTorch AMP里已經(jīng)是標配。6.2 bf16為“大模型訓練”而生bf16 的設計很有意思它把 16 位里的 8 位留給了指數(shù)尾數(shù)只保留 7 位。這樣做的效果是bf16 的表示范圍和 fp32 幾乎一樣但精度大幅下降。對于大模型訓練來說末位誤差對參數(shù)更新的影響往往小于“梯度消失導致無法更新”的影響所以 bf16 非常受歡迎。用 bf16 訓練幾乎不需要擔心 overflow反而要擔心精度太低導致 loss 收斂不穩(wěn)定。實踐中通常結合 fp32 的 master weights主權重副本來做參數(shù)更新。6.3 tf32NVIDIA 專為 Ampere 架構設計的加速格式tf32 是 NVIDIA 在 Ampere 架構上主推的一種格式。它其實是 fp32 的“截斷版”保留 8 位指數(shù)和 10 位尾數(shù)但內(nèi)部會用 fp32 的位寬去做計算從而在矩陣乘法中實現(xiàn)約等于 fp32 精度的效果同時把計算速度提升到接近 fp16。在 PyTorch 中啟用 TF32 通常只需要設置一個環(huán)境變量或一行代碼torch.backends.cuda.matmul.allow_tf32 True torch.backends.cudnn.allow_tf32 True注意allow_tf32默認一般是關閉的因為它會犧牲一部分精度。如果你的模型對精度不太敏感可以開啟換取明顯加速。6.4 如何選擇給出一個比較務實的判斷場景推薦格式原因小規(guī)模訓練、模型調(diào)參fp32穩(wěn)定、不用操心精度問題大模型預訓練bf16 fp32 master weights動態(tài)范圍大無需 loss scaling顯存受限的推理fp16體積小、速度快、范圍夠用NVIDIA Ampere/Ada 架構 GPU 訓練tf32 可選開啟加速明顯性能下降有限嵌入式/邊緣設備int8 或 fp16需要額外量化校準選型沒有一個通用最優(yōu)解關鍵在于先理解模型的敏感度。對精度不敏感的模型例如某些視覺模型可以大膽嘗試低精度對文本生成這類對長尾細節(jié)敏感的任務最好先用 fp32 做 baseline再對比低精度的指標差異。7. 如何查看浮點數(shù)的底層位形式理解浮點數(shù)的一個好方法是直接看它在內(nèi)存里的二進制位。這樣你能直觀看到“1”和“0”是如何分布到符號位、指數(shù)位、尾數(shù)位上的。Python 可以用 struct 拿到 float 的原始 4 字節(jié)或 8 字節(jié)import struct def float_to_bin(f): # 打包成 IEEE 754 單精度 4 字節(jié) packed struct.pack(f, f) # 解包成整數(shù) as_int struct.unpack(I, packed)[0] # 轉(zhuǎn)換為 32 位二進制 return f{as_int:032b} def double_to_bin(f): packed struct.pack(d, f) as_int struct.unpack(Q, packed)[0] return f{as_int:064b} print(float_to_bin(0.1)) print(double_to_bin(0.1))輸出示例00111101110011001100110011001101 0011111110111001100110011001100110011001100110011001100110011010你可以看到0.1 的二進制表示并不是一個整整齊齊的有限序列而是經(jīng)過舍入后的近似值。把0.1 0.2的位形式打出來再和0.3對比就能明顯看出兩者最后幾位不同。Java 里可以這樣查看public class FloatBits { public static void main(String[] args) { float f 0.1f; int bits Float.floatToIntBits(f); System.out.println(Integer.toBinaryString(bits)); } }如果你在做嵌入式開發(fā)經(jīng)常需要把浮點數(shù)拆成字節(jié)通過串口發(fā)送這種位運算思路特別實用。比如把一個 float 轉(zhuǎn)成 4 個字節(jié)union float_bytes { float f; unsigned char bytes[4]; };這是一種省內(nèi)存、適合協(xié)議直傳的做法但要注意字節(jié)序問題。如果你不想寫代碼也可以在搜索引擎搜索“32位浮點數(shù)轉(zhuǎn)換工具”“浮點數(shù)轉(zhuǎn)換在線工具”等關鍵詞很多在線頁面可以直接輸入十進制小數(shù)輸出二進制位和十六進制。這類工具對快速驗證某個想法的幫助很大。8. 常見問題與排查思路問題現(xiàn)象可能原因排查方式解決方案0.1 0.2 不等于 0.3二進制無限小數(shù)尾數(shù)舍入打印多位小數(shù)或查看二進制表示使用 Decimal/BigDecimal/誤差比較兩個 double 數(shù)值相等判斷失敗浮點數(shù)計算產(chǎn)生微小誤差打印差值計算 abs(a-b)使用 epsilon 范圍比較累加結果越來越小大數(shù)吞小數(shù)重復舍入打印累加過程的相對誤差使用 Kahan 求和算法或 Decimalsoftmax 輸出為 0數(shù)值下溢檢查輸入范圍打印 logits使用 log_softmax 或在計算中減去最大值模型訓練 loss 出現(xiàn) NaN梯度上溢或下溢檢查 loss 值、梯度范數(shù)開啟 loss scaling使用 bf16串口打印浮點數(shù)亂碼字節(jié)序不一致或格式錯誤打印原始 hex 數(shù)據(jù)統(tǒng)一大小端確認發(fā)送和接收的字節(jié)順序數(shù)據(jù)庫對比金額不平float 字段精度不夠查看數(shù)據(jù)庫字段類型改用 DECIMAL/NUMERIC 類型Python Decimal 精度不對從 float 構造 Decimal打印 Decimal 對象內(nèi)部值使用字符串構造 Decimal9. 最佳實踐與工程建議9.1 能用整數(shù)不要用浮點金額、數(shù)量、序號、ID、百分比整數(shù)這些場景能不用浮點數(shù)就不要用。整數(shù)運算在二進制下是精確的語義清晰永遠不會出現(xiàn)“金額差一分”的問題。9.2 比較浮點數(shù)必須引入容差在需要判斷兩個浮點數(shù)是否相等時不要直接用而是定義 epsilondef almost_equal(a, b, eps1e-9): return abs(a - b) eps但在不同量級下固定 epsilon 也不一定合適。更通用的方式是“相對誤差絕對誤差”結合這里不展開只要記住epsilon 的選擇要與數(shù)值量級匹配。9.3 減少中間舍入多個數(shù)值累加時盡量把數(shù)先按大小排序從小到大累加或者使用更高精度的中間類型比如 Python 里用內(nèi)置高精度、Java 里用 BigDecimal 做中間計算。這能顯著降低累計誤差。9.4 輸出用戶可見內(nèi)容時再格式化在計算過程中保持浮點精度只在最后輸出時格式化print(f{value:.2f})Java 里可以用String.format(%.2f, value)或DecimalFormat。注意這只是“顯示格式化”不會改變內(nèi)部的值所以不能用來解決“比較相等”的問題。9.5 數(shù)據(jù)庫金額字段選對類型如果是 MySQL金額字段推薦DECIMAL(10, 2)這樣的小數(shù)類型不要使用FLOAT或DOUBLE。數(shù)據(jù)庫字段類型一旦選錯后續(xù)遷移成本很高。9.6 深度學習訓練要關注數(shù)值區(qū)間使用 bf16 和 fp16 時不要只盯著模型指標還要監(jiān)控中間數(shù)值的分布。PyTorch 中可以通過 hook 打印梯度范數(shù)如果發(fā)現(xiàn)大量 0 或 inf就說明數(shù)值區(qū)間已經(jīng)失控。合理的初始化、梯度裁剪、loss scaling 能解決大多數(shù)問題。9.7 保留可復現(xiàn)實驗環(huán)境浮點數(shù)在 CPU 和 GPU 上、不同編譯器優(yōu)化級別下運算順序可能不同導致微小差異。做論文實驗或精度對比時盡量固定環(huán)境記錄運行參數(shù)避免“結果差一點點但找不到原因”。10. 總結與后續(xù)學習方向這篇文章從 IEEE 754 的符號位、指數(shù)位、尾數(shù)位出發(fā)解釋了浮點數(shù)陷阱產(chǎn)生的底層原因然后給出了四類經(jīng)典問題的表現(xiàn)和規(guī)避方式最后把視角拉到深度學習模型部署討論了 fp32、fp16、bf16、tf32 的選型思路。核心就一句話浮點數(shù)不是“壞掉的小數(shù)”它是用有限二進制位近似所有實數(shù)的通用方案。你只能在“速度、范圍、精度”三者之間做權衡不可能全部都要。如果你想繼續(xù)深入建議往這幾個方向走閱讀 IEEE 754 標準原文中的舍入規(guī)則理解“四舍六入五成雙”在二進制里怎么實現(xiàn)。學習 Kahan 求和、牛頓迭代、數(shù)值穩(wěn)定的矩陣分解這些是數(shù)值計算里降低浮點誤差的經(jīng)典工具。了解 CUDA 混合精度訓練的實現(xiàn)細節(jié)讀 PyTorch AMP 和 NVIDIA 官方文檔對比不同精度設置下模型的 loss 收斂曲線。如果你做嵌入式開發(fā)可以研究一下定點數(shù)表示法很多 MCU 上定點數(shù)比浮點數(shù)更適合做穩(wěn)定控制。浮點數(shù)的坑并不神秘你花在理解底層原理上的每一分鐘都會在以后排查疑難 bug 時加倍還回來。建議順手收藏這篇文章下次遇到 0.1 0.2 相關的爭議直接把它轉(zhuǎn)給同事。