重磅深度：引爆國產算力芯片的UE8M0 FP8是什麼？

　　來源：貝葉斯之美

　　隨着深度學習模型（尤其是大規模生成模型）參數規模的擴張，對更高效的計算與存儲方案的需求愈發強烈。降低數據類型位寬（精度）是一條行之有效的途徑，但如何在降低位寬的同時保持準確度是一大挑戰。

　　在預訓練過程中，用更少的比特來表示模型參數以及相關張量，已成為在不犧牲準確度的前提下提升 GPU 效率的必備技術。NVIDIA Blackwell 代 GPU 中引入的 Microscaling（MX）格式，將窄位寬浮點類型與更細粒度的按塊縮放因子相結合，是這一方向的重要進展；它讓更多張量可以被量化，並讓對這些張量的運算更高效。

　　deepseek一句話引爆國產算力芯片，國產芯片迎來突圍質變關鍵點？從產業角度來看，未來的工作遠不如看起來這麼簡單，前路依然慢慢修遠！

　　DeepSeek V3.1 公開點名用了 UE8M0 FP8 scale 並暗示「下一代國產芯片」協同，媒體集中報道后，A 股/港股里「國產芯片、FP8 概念」短線大漲，話題瞬間出圈。同期，部分國產 GPU/NPU 宣稱「原生 FP8 / Block FP8」或工具棧可支持 FP8/MX，進一步強化了「軟硬協同 → 釋放帶寬/功耗紅利」的敍事。

　　UE8M0/FP8（MX）不是新概念，早在2023 年 OCP 就發佈了 

　　Microscaling（MX）v1.0（塊大小 K=32、共享尺度 UE8M0 等），把「塊級縮放 + 窄位寬浮點」寫成了行業規範。而到了2025 年，AI芯片之王NVIDIA 

　　Blackwell 把 MXFP8/6/4 做成張量核原生數據類型，硬件里直接處理「每 32 個數一個 2^k 尺度」的邏輯（UE8M0），不再靠軟件拼。官方資料與開發者博客都強調了這點。有了原生支持后，MXFP8 訓練端到端吞吐≈BF16 的 2×，而不是隻在內核里「紙面提速」。（論文與官方文檔均有説明。）

　　特意把相關論文翻出來看了一下，內容不多，10多頁，最新論文把能穩定預訓練的大模型的可復現做法講清了：所有張量（含激活梯度）統一用 E4M3；尺度用 UE8M0，且對 log2（amax/destmax） 取「向上整」，避免因溢出導致的發散——這點明確區別於 OCP v1.0 的默認取整建議。並給出 8B/15T tokens 與 BF16 等精度的實證。

　　而其實最為關鍵的依然在底層的軟件與算子生態，Transformer Engine、cuDNN/cuBLAS 落地了 FP8/MX 的算子與數據流；NVIDIA NeMo、TE 用户手冊給出了工程路徑。

　　大模型側的真實案例越來越多：Nemotron-H、Llama 系列等公開材料都提到用 FP8 路線（早期多為按張量縮放，如今轉向更細的塊縮放/MX）。甚至有 vLLM 在線 FP8 生成的路徑。這些都把「訓練—推理—部署」的鏈條打通了。生態也在跨廠蔓延（例如 ROCm 側的 Transformer Engine），進一步提升「通用感知」。

　　它具體解決了什麼？

1. 動態範圍不過載：整張量一次縮放常照顧不了「大值/小值」同時存在，容易溢出或壓成 0；按塊縮放能「就近對齊」，信息損失更小。

2. 帶寬/顯存壓力小：元素 8 bit，每 32 個只加 1 字節尺度元數據；相比「每塊存 FP32 尺度」，元數據流量省 75%。

3. 硬件代價低：UE8M0 只編碼 2^k，移位即可，關鍵路徑短、功耗低；對沒有完整 FP8 乘加單元的芯片，落地門檻更低。

　　為什麼會給國產芯片帶來利好？在國產芯片多數仍以 FP16/BF16+INT8 通路為主的階段，引入塊級縮放 + 原生/近原生 FP8的存取與算子，可以在不犧牲精度的前提下顯著降帶寬、提吞吐，而UE8M0「冪次縮放」的硬件代價最低，因此是合適的過渡/長期方案，雖然遠達不到英偉達那樣的效果，只能退而求其次，在某些端側小場景尤其適用？

　　1）UE8M0 / FP8 / MXFP8 各自是什麼？

　　UE8M0不是「另一種FP8」，而是MX（Microscaling）格式里的「塊級縮放因子」——8 bit 全給指數（E8M0），只編碼2的冪，用於給同一小塊（典型 K=32）里的FP8元素統一定標；這樣解碼只需指數移位（shift），不必做浮點乘法，硬件關鍵路徑更短，帶寬/能耗也更友好。

　　常見誤區有哪些？

• 把 UE8M0 當成「第三種FP8」？不對。它是「縮放因子」的格式，元素依舊是 E4M3/E5M2。

• 認為「有了UE8M0就必然大幅提速」，收益取決於硬件是否原生MX、模型是否帶寬受限、以及通信/內存是否成為新瓶頸。

• 把「75%節省」理解為「總流量減少75%」，準確説是把「每塊的縮放元數據」從 32b（FP32）降為 8b（UE8M0）→ 元數據部分下降 75%；對「整體塊數據」的降幅更小，但仍有利好。

　　使用 UE8M0 FP8 scale，目的是與「微縮塊格式（MX）」生態兼容；官方在外媒與社區頁也提到與「新一代國產芯片」適配的取向。

　　一個 MX 格式由：塊大小 K、每塊共享的縮放因子 X、塊內元素的數據類型共同指定。K=32（適用於所有 MX 類型）。X 的類型是 UE8M0（8 位指數、無尾數、無符號），表示 NaN 或 2 的冪（範圍 2^（−127） 到 2^127）。

　　給定源格式（通常 FP32）的 K 個數據 V_i，轉換到 MX 格式時，需要計算 X 與 Q_i，使得 Q_i×X ≈ V_i。存儲時寫入 X 與 Q_i。Blackwell 的張量核心會消費 X 與兩側塊的 Q_i 來做點積；若累加輸出為 FP32，則在后續算子需要 MX 格式時再將其回量化為 MX。

• FP8（E4M3 / E5M2）

  8位浮點的兩種常用編碼（1符號 + 指數 + 尾數），業界已廣泛用於訓練/推理。E4M3精度更高、E5M2動態範圍更大。

• MX（Microscaling）

  把一個張量按固定小塊（典型 K=32）切分；每塊共享一個「縮放因子 X」（以冪次形式存放），塊內元素用低位寬格式（如FP8）存儲。這樣既保留8比特的低帶寬優勢，又靠更細顆粒的定標獲得更大的可用動態範圍與更穩的數值。MX 的塊尺度與元素格式相互獨立。

• UE8M0

  縮放因子的具體格式——無符號（U）、8位指數（E8）、0位尾數（M0），即只有指數，沒有符號/尾數；「ExMy」記法在 OCP 規格里明確：當 y=0（如E8M0）就不含符號位。它僅表示 2 的整數冪，因此硬件解碼是移位，不需浮點乘法。

• MXFP8

  指「元素為FP8」的MX格式集合；所有MX具體格式的共享縮放，統一採用 E8M0。常用的就是「UE8M0 + FP8（E4M3/E5M2），塊大小K=32」。

　　Blackwell 支持的 MX 格式

• MXFP8：E4M3（最大約 1.75×2^8，最小約 2^（−9），可覆蓋約 17.8 個 log2 桶），張量核相對 BF16 ~2× 吞吐。

• MXFP8：E5M2（更大動態範圍，約 31.8 桶），張量核相對 BF16 ~2× 吞吐。

• MXFP6：E2M3/E3M2（~2× 吞吐）。

• MXFP4：E2M1（~4× 吞吐）。

  注：E4M3 僅有一個 NaN 比特模式；E5M2 遵循 IEEE-754 特殊值語義。指數位越多→範圍越大；尾數位越多→給定範圍內的精度越高。

　　論文顯示在80 億參數、15T 詞元的預訓練中，觀察到 MXFP8 的驗證困惑度與 BF16 匹配（全程差異 <0.5%）。下游任務（MMLU、9 項推理基準）分數也相當。類似等價性在更小模型/數據上同樣成立，從而使 MXFP8 成為更高效的預訓練選項。

　　模型配置：32 層 Transformer，32 頭，隱藏 4096，GQA 組 8，KV 通道 128，預訓練序列長 8192。學習率 6e-4 余弦衰減至 6e-6；數據混合兩階段（先多樣性、后高質量），60% 處切換。

　　訓練平臺：Megatron-LM；3072 張 Hopper GPU；批量 768。MX 運算通過將 BF16 輸入在 GEMM 前轉換為 MXFP8、GEMM 后再轉回 BF16 來模擬。

　　評測：MMLU（5-shot）、9 項通用推理（1-shot）平均分。

　　MXFP8 維持 BF16/FP8 級準確度；在 Blackwell 上，MXFP8 張量核吞吐 ~2×BF16，端到端預訓練更快；與傳統 FP8 相比，MXFP8 配方更簡單（所有層均可量化，縮放由硬件處理），吞吐相當或更佳。

　　2）它究竟解決了什麼數值&硬件問題？

　　數值層面，傳統「整張量縮放」在子8位（<8b）或極端值分佈下容易溢出/壓成0；按塊縮放能「就近」匹配每塊的幅度分佈，更好覆蓋大/小值，減少飽和與下溢。實證表明在多項任務里，MX 直接替代 FP32 推理、甚至用於低比特訓練，也能接近/對齊 FP32/BF16 的精度。

　　E4M3 vs E5M2 的選型：在有了細顆粒塊縮放的前提下，實踐上經常統一用 E4M3（更高「採樣精度」）能得到更穩的訓練/下游表現；Blackwell 的 MX 訓練配方也給出類似建議。

　　硬件/系統層面

　　UE8M0 = 2^k→ 解碼只需移位；不必做浮點乘法、規格化或舍入，縮短關鍵路徑、利於高頻設計與能耗控制。

　　縮放元數據更輕：每塊只多 8 bit 的 scale。相較「每塊存一個 FP32 縮放」（32 bit），縮放元數據流量減少 75%；（整體塊數據從 256b→264b 對比 256b→288b，總流量也更低）。

　　生態對齊：NVIDIA Blackwell 已將 MXFP8/6/4 做成張量核原生數據類型（K=32、X=UE8M0），在其平臺上 MXFP8 相比 BF16 的矩陣核吞吐標稱 ~2×。這為上游模型與下游硬件的「共同語言」定了規。

　　3）為什麼説它「貼合下一代國產芯片」？

　　大多數已量產國產AI加速器仍以 FP16/BF16 + INT8 通路為主，對完整 FP8 FMA 的硬件棧支持不一；而 UE8M0 的移位解碼 + 塊級FP8存算，實現難度和代價更低，更符合階段性演進路徑。

　　帶寬/容量制約，更敏感的環境里，FP8+塊縮放能顯著降低 HBM/DDR 壓力；這正是國產芯片在功耗/能效/帶寬方面最希望「用算法/格式把水再擠出來」的方向。

　　國內媒體與機構報道里，摩爾線程 MUSA 架構宣稱原生 FP8 張量加速，並點名能很好支持 UE8M0 FP8 Scale；芯原 VIP9000 NPU 亦被多家產業媒體與高管採訪稿提到增加 FP8（E4M3/E5M2）支持，強調與主流框架/工具鏈的易部署性。

　　DeepSeek 明確採用 UE8M0 FP8 scale，把軟件側配方與國產硬件的「最佳工作點」對齊，實際上是在構建軟硬協同的一致座標系，降低生態碎片化成本。

注：具體廠商/型號是否「原生 FP8 張量核」或「Block FP8」要以官方規格書/驅動版本説明爲準；媒體稿件與三方文章的口徑可能滯后或存在表述差異。上文引用為公開報道與產業採訪。

　　4）它與「常規 FP8」的關係（怎麼搭配用）？

　　仍用 E4M3/E5M2（通常 E4M3 全程更穩），共享縮放用 UE8M0；典型塊大小 K=32。這就是MXFP8。訓練/推理常見做法：權重/激活/梯度在 GEMM/CONV 里用 MXFP8，歸一化/softmax/殘差等用 BF16/FP32；累加一般在 FP32，主權重常保一份 FP32 「母本」。縮放算法按塊取 amax 決定指數，向上取整以避免溢出，再做飽和式量化（超過上限則鉗位）。這類配方在 Blackwell 的 MX 論文里給了具體步驟與對比。

　　5）對模型精度與吞吐的「量化預期」

　　精度，在分類/語音/LLM 上，MX 直接投產/微調后能接近/對齊 FP32/BF16；對大模型的預訓練，MXFP8 在合適配方下可與 BF16 等價的困惑度/下游得分。

　　吞吐/成本，在原生支持 MX 的硬件上，矩陣核吞吐~2×BF16，端到端訓練/推理時間和顯存佔用相應下降（真實收益取決於是否算子/帶寬/通信受限）。

　　對國內生態的實質意義有哪些？

　　UE8M0 FP8（MX）把模型數值配方和硬件實現成本一起優化到了「兼容 & 高效」的均衡點：更穩的精度、更低的帶寬、更短的關鍵路徑。DeepSeek 把訓練/權重格式對齊到 MX 標準，等於在國產硬件側「放下對接道釘」。隨着更多芯片把 MXFP8 做成「一等公民」，軟硬協同的性價比纔會真正體現出來。

　　所以，我們可以看到，UE8M0 FP8（MX）是好「格式」，能顯著降低帶寬/功耗、擴大可量化範圍；但「效果」取決於系統工程：是否有原生 MX 張量核、是否搞定轉置重量化和雙副本開銷、是否站在 NVLink 級互聯上擴展、以及工具鏈是否把配方一把梭。在這些方面，NVIDIA 目前端到端更完整，所以你看到的「明顯差距」本質上是平臺差距，而不是「UE8M0/MX 這條路線不行」。

　　所以，國產芯片再一次沸騰，但是我們依然需要冷靜！

　　「有了 UE8M0 FP8（MX）格式是不是就等於立刻得到英偉達那樣的實際效果」？

　　答案是不能！差距往往不在「格式本身」，而在算子/內核、內存與互聯、框架與工具鏈、以及標準細節的一致性。從工程角度拆開講，可以看到哪些短板會直接吃掉我們在論文或宣傳里看到的收益。

　　1）數值與算法：標準一致性還沒「完全對齊」

　　MX 的定義（K=32、每塊共享 UE8M0 尺度、塊內元素用 FP8/FP6/FP4 等）是 OCP 標準的一部分；UE8M0 只編碼 2 的冪（−127…127），本身很輕量。問題是：「如何取整到 2 的冪」這件事，不同實現不完全一致。NVIDIA 的 MXFP8 訓練配方里明確把尺度取整改為向上取整（ceil（log2）），並給出消融：按 OCP v1.0 建議的「向下取整」在大規模預訓練里會更易溢出/發散。若硬件/軟件仍按 v1.0 來做，訓練穩定性就可能對不上。

　　E4M3 「全量化」選擇：NVIDIA 的結論是權重/激活/激活梯度都用 E4M3（塊縮放后需要的是精度而不是更大的指數範圍），這和很多「FP8=梯度用 E5M2」的老經驗不一樣。配方差一口氣，效果就會「看着像 MX，跑起來不像」。

　　2）算子與內核：沒「原生 MX」就有隱性開銷

　　MX 需要在張量核里處理很多「每塊一次」的尺度。在軟件里頻繁處理這些縮放，非常貴；Blackwell 在硬件層把尺度取整與量化塞進張量核指令路徑，才把這筆開銷吃掉。沒有這條硬件「捷徑」，你在別家芯片上用 MX，內核層面的額外讀改寫/重量化會吞掉收益。

　　轉置問題：Blackwell 的 MX 要求「沿歸約維的塊數據連續」，訓練時前后/反傳會頻繁換歸約維；普通 FP8 轉置是重排，MX 的轉置要「重量化」，這在沒做專門硬件/內核優化時會非常痛。

　　雙軸兩份量化副本：爲了同時服務行/列兩條歸約軸，訓練框架通常需要給每個張量保兩份 MX 量化版本；這既吃顯存也增加數據搬運。NVIDIA 的論文和 TE 的工程 issue 都點名了這一點。

　　3）內存與互聯：系統「地基」差異放大效果差距

　　NVLink / NVSwitch 的規模化優勢：Blackwell 代把 NVLink 帶寬拉到每 GPU 1.8 TB/s，並通過 NVLink Switch 把 72 GPU 拉進一個1.8 TB/s 保持的 NVLink 域，還能跨機櫃擴展；這直接決定了FP8/MX 的帶寬紅利能否真正轉化成集羣吞吐。如果替代平臺只有 PCIe 或傳統以太/IB，通信相對吃緊，同樣的 MX/FP8 算力優勢會被All-Reduce/張量並行通信抵消。

　　4）生態與通用性：工具鏈還在「接入期」

　　框架 dtype 與編譯工具支持未完全成熟：PyTorch 核心層面對 MX 的基礎類型（比如 E8M0、FP4）仍在推進中；Triton 也有「如何在語言里暴露 MX/轉置模式」的開放問題。沒有一線框架的原生一等支持，通用性就會打折。

　　跨廠商 FP8 的「細節不一致」：比如 AMD 文檔就明確寫到 MI300 的 FP8 編碼與 H100 不同；再疊加 MX 的尺度取整差異，你在多家硬件之間遷移「同名 FP8/MX」模型，可能需要重轉換/重校準才能穩定。

　　非英偉達平臺的 MX 現狀：

• AMD：公開資料已在教程/白皮書層面引入 OCP MX 概念與 FP8 支持，但是否有「原生 MX 塊縮放硬件管線」尚非標配，多為軟件路徑實驗/過渡。

• Intel Gaudi：官方強調 FP8 訓練/推理算力與推理教程，但並未宣稱 MX 原生塊縮放；若只是常規 FP8（按張量/軸縮放），與 MX 的落地複雜度與收益曲線不同。

　　5）結果差距通常來自哪幾件「最傷」的事？

1. 數值細節不一致（尺度取整、梯度格式）：訓練不穩或需要更保守的超參 → 有效吞吐下降。

2. 沒有「內建 MX」的張量核：尺度處理/轉置重量化落在軟件 → GEMM 旁路開銷變大。

3. 存儲/通信瓶頸：雙副本顯存 + 邊帶尺度 + 跨卡通信不足 → MX 的帶寬節省兑現不了。

4. 工具鏈與 op 覆蓋不全：某些層（嵌入/最終投影、BMM/softmax 等）仍高精度，若沒對齊好執行計劃，端到端收益會被「非 MX 區段」稀釋。

　　但對於夾縫中求存的國內芯片來説，這也是算是一種不多的求變模式，未來任重而道遠。

　　哪怕沒有「原生 FP8 張量核」，也能通過「FP8 存取 + 快速移位解碼 → 進 FP16/BF16 乘加」這條混合路徑拿到帶寬/顯存層面的實效；硬件只需加輕量的尺度表處理與移位單元。同樣的內存帶寬、同樣的功耗預算下，模型可以更大、批量可以更足，單位 TCO 的吞吐更好看。DeepSeek 等模型側明確用 UE8M0 的塊縮放範式，軟件棧（量化、校準、推理引擎）更容易在國產芯片上做統一適配，減少「各玩各的」的碎片化成本。相比「一步到位做全功能 FP8 FMA 核」，先把 MX（按塊縮放 + 移位解碼）打通更現實，屬於漸進式演進：

• 第一步：推理先行（權重 FP8 + 激活 BF16/FP16，累加 FP32）；

• 第二步：部分訓練鏈路 FP8 化（GEMM 主干 FP8，歸一化/Softmax 等保高精度）；

• 第三步：硬件代際升級，再做原生 MX/FP8 張量核。

　　「達不到英偉達效果，所以只是退而求其次、更適合端側小場景？」

　　U1S1，當前確實存在差距：沒有「原生 MX」張量核、沒有高帶寬互聯（NVLink/NVSwitch 同級）、算子/框架支持不全時，UE8M0/FP8 的紙面優勢會被內核開銷和通信瓶頸吃掉。這是當下不少平臺的現實。

　　但不等於「只能端側」：

• 數據中心也能受益，前提是把塊縮放和尺度處理放進內核，減少「量化—反量化」的來回；很多國產方案在推理端已能落地這條混合路徑。

• 端側/邊緣當然更「對味」——內存窄、功耗緊的地方，UE8M0+FP8 的帶寬/能耗收益會更直接、更穩定；比如嵌入式大語言模型、語音/視覺邊端模型、AI PC 的本地推理。

• 策略不是「退而求其次」，而是「先吃確定性紅利」：先把存取與帶寬這半邊紅利吃乾淨，再逐步把計算路徑FP8 化。

　　什麼時候用它「最划算」？

• 推理優先：LLM、ASR、CV 大模型的權重 FP8（塊縮放）+ 激活 16bit + FP32 累加；大幅降顯存與權重帶寬，延迟/吞吐普遍可見改善。

• 訓練試點：中小規模預訓練/繼續訓練（SFT/蒸餾/LoRA），GEMM 主干用 MXFP8，歸一化/Softmax 等保高精度，先跑穩定再擴規模。

• 帶寬/功耗受限：AI PC/邊緣盒子/嵌入式 SoC，壓住功耗同時把模型體量拉上去。

　　所以，UE8M0 FP8（MX）= 低帶寬 + 低實現門檻 + 足夠穩的數值，對當下仍以 FP16/BF16+INT8 為主的國產芯片，是一條現實且漸進的增量路線。

　　不是隻能端側，但端側/功耗敏感場景的「性價比提升」最立竿見影；數據中心要想接近頭部效果，需要算子級融合、塊縮放下沉到內核、以及更好的互聯帶寬。先把權重/存取的紅利吃到，再推進計算路徑與互聯，這條路能走通，而且短期就有肉吃。

　　全文完。

責任編輯：楊賜