引爆國產算力芯片的 UE8M0 FP8 是什麼？

隨着深度學習模型參數規模的擴張，對高效計算與存儲方案的需求增加。降低數據類型位寬是一種有效途徑，但保持準確度是挑戰。NVIDIA Blackwell GPU 引入的 Microscaling 格式提升了 GPU 效率。DeepSeek V3.1 使用 UE8M0 FP8 scale，推動國產芯片概念短線大漲。部分國產 GPU/NPU 宣稱支持 FP8/MX，強化軟硬協同敍事。2023 年 OCP 發佈 Microscaling v1.0，2025 年 NVIDIA 將 MXFP8 作為原生數據類型，提升訓練效率。

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

在預訓練過程中，用更少的比特來表示模型參數以及相關張量，已成為在不犧牲準確度的前提下提升 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），進一步提升 “通用感知”。

它具體解決了什麼？

動態範圍不過載：整張量一次縮放常照顧不了 “大值/小值” 同時存在，容易溢出或壓成 0；按塊縮放能 “就近對齊”，信息損失更小。
帶寬/顯存壓力小：元素 8 bit，每 32 個只加 1 字節尺度元數據；相比 “每塊存 FP32 尺度”，元數據流量省 75%。
硬件代價低：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）結果差距通常來自哪幾件 “最傷” 的事？

數值細節不一致（尺度取整、梯度格式）：訓練不穩或需要更保守的超參 → 有效吞吐下降。
沒有 “內建 MX” 的張量核：尺度處理/轉置重量化落在軟件 → GEMM 旁路開銷變大。
存儲/通信瓶頸：雙副本顯存 + 邊帶尺度 + 跨卡通信不足 → MX 的帶寬節省兑現不了。
工具鏈與 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 為主的國產芯片，是一條現實且漸進的增量路線。

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

本文來源：貝葉斯之美，原文標題：《重磅深度：引爆國產算力芯片的 UE8M0 FP8 是什麼？》。

風險提示及免責條款

市場有風險，投資需謹慎。本文不構成個人投資建議，也未考慮到個別用户特殊的投資目標、財務狀況或需要。用户應考慮本文中的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。