FP8 可用於大型語言模型訓練，以降低計算與記憶體資料量，但是否能穩定取代或部分取代 BF16，仍須以特定模型、資料集、軟體版本與訓練配方驗證。來源指出，在支援 FP8 的新一代 GPU 上，對矩陣乘等計算密集型算子，NVIDIA TensorCores 的 FP8 峰值效能可為 BF16 的兩倍、TF32 的四倍；對訪存密集型算子，較小的資料量亦可能減輕訪存壓力。不過，FP8 的動態範圍與精度較 FP16、BF16、FP32 小，訓練團隊必須同時評估收斂、量化誤差及下游任務結果。
FP8 要解決的訓練問題與適用情境
大型模型訓練中的矩陣乘算子通常具有高計算需求，而張量讀寫亦可能成為瓶頸。FP8 透過較低精度表示，目標是在支援的硬體與軟體堆疊中縮短計算密集型算子的時間，並減少資料搬移量。若部署端也規劃採用低精度推論，FP8 訓練可作為串接低精度訓練與推論流程的一項評估路徑。
它較適合已有 BF16 基線、能持續觀察 Loss 與下游指標，並可進行分層回退測試的團隊。若模型對數值精度高度敏感、訓練流程尚未建立可重現的 BF16 基線，或推論端無法確認 FP8 張量與縮放參數的處理方式，應先完成基線與相容性驗證，再擴大 FP8 使用範圍。
訓練中常見的三類訊號
第一類是 Loss Spike。這不是 FP8 特有現象，BF16 訓練也可能出現。若 FP8 的 Spike 與 BF16 類似，可先視為通用訓練問題；若 FP8 發生更頻繁，或需多次迭代才能恢復，則應進一步檢查 FP8 設定與數值行為。
第二類是 Loss 上升或發散。若在訓練一開始即發散，來源建議先排查軟體問題，並使用 NVIDIA NeMo、Mcore（Megatron Core）或 TE（Transformer Engine）的適用版本。若設定啟用了 CPU offloading、FP8 parameters 等新增功能，可先關閉後比對。對數值問題，可測試以 FP8 tensor 作為輸入、但使用 BF16 GEMM 的路徑；若問題在訓練中期出現，則可評估 current scaling，或將部分層回退至 BF16。來源特別提到首層與末層可能較敏感，但其效果仍應在目標模型與資料上測試確認。
第三類是 Loss 正常、下游任務卻低於 BF16 基線。此時應先確認推論流程是否讀取正確的 scaling factor 與 weight。若只有部分任務落後，可調整 FP8 recipe 或對特定層採用 BF16 fallback；若訓練使用 FP8、推論改用 BF16，則需評估額外誤差，並比較 FP8 訓練搭配 FP8 inference 的結果。
FP8 Debug 工具可觀察的內容
來源描述的 FP8 Debug 工具用於分析訓練狀態，並稱可與 NVIDIA NeMo Megatron 的不同版本搭配使用，且不需修改框架內部程式碼。工具可記錄 BF16 與 FP8 間的 MSE 與餘弦相似度，以觀察量化誤差；也可統計 Tensor 的 Underflow 與 Overflow 比例，協助判斷較小動態範圍是否造成精度問題。
此外，工具可比較 Delayed Scaling 的 Scaling Factor 與依目前 Tensor 計算的 Current Scaling，並依層與 Tensor 名稱動態選擇 Dump 對象。可觀察的資料包括 forward 的 GEMM input、weight，以及反向傳播的 Dy，並以週期性輸出比較不同 step 的 AMin、AMax、縮放因子與量化誤差。來源中的內部構造案例顯示，訓練發散案例在部分 forward X 張量上出現較高 MSE 與 Underflow 比例；這類結果可協助團隊定位應調整縮放策略或回退至 BF16 的候選層，但不應視為所有模型皆適用的閾值。
建議的評估與導入路徑
- 以既有 BF16 訓練流程建立可重現基線，記錄 Loss 曲線、訓練步數與下游任務分數。
- 在相同模型、資料集與主要超參數下啟用 FP8，先比較是否出現早期發散、異常 Spike 或中期 Loss 上升。
- 針對異常 step 與層級張量，檢查 MSE、餘弦相似度、Underflow、Overflow、AMin、AMax 與縮放因子差異。
- 依觀察結果測試關閉新增功能、調整 scaling 策略、改用 BF16 GEMM，或將敏感層回退至 BF16。
- 以完整推論流程驗證下游任務，確認 weight 與 scaling factor 的讀取方式，並比較 FP8 inference 與 BF16 inference。
FP8 Debug 工具在來源發布時仍處於內部測試階段。其實際取得方式、支援範圍、版本相容性與使用條件，應向對接的 NVIDIA 技術團隊確認，並以當時的正式文件與專案測試結果為準。
常見問題
FP8 訓練出現 Loss Spike，是否代表必須停用 FP8？
不一定。Loss Spike 也可能在 BF16 中發生，應先以 BF16 基線比較頻率、幅度與恢復情況。若 FP8 的異常更頻繁或恢復明顯較慢，再檢查軟體版本、訓練設定、縮放策略及特定層的量化狀態。
Loss 正常但下游任務成績較差，應先檢查什麼？
先確認推論流程是否使用正確的 scaling factor 與 weight，並確認訓練和推論精度組合。之後可檢查是否僅部分任務或部分層受影響，再測試 current scaling、部分層 BF16 fallback，或 FP8 訓練搭配 FP8 inference。
結論
FP8 為大型語言模型訓練提供降低計算與資料搬移負擔的選項，但導入重點不在於單一峰值效能數字，而在於以 BF16 基線、Loss 行為、張量級量化指標與下游任務結果共同驗證。對模型、資料集、硬體、NeMo、Mcore、TE 版本與推論流程的適用性，均應以完整 SKU/BOM、正式技術文件及專案測試確認。
圍繞「FP8 大型語言模型訓練：效能優勢、除錯方法與評估重點」繼續瞭解 採購與選型問答。
WeChat
Profile