動態精度切換真的能落地嗎？Layer Sensitivity、Routing與Fallback

動態精度不是一個開關，而是一個帶狀態的決策系統

把 FP16、BF16、FP8、MXFP8、NVFP4 或 INT4 寫在設定檔裡，只能說明候選格式，不能說明系統會不會在執行時安全切換。真正的 dynamic precision switching 必須同時處理四個問題：何時做決策、誰保存縮放因子、哪一個 kernel 接手、以及切換後如何確認品質沒有越過門檻。若只在每次請求前改一個 dtype，卻沒有同步 scale、graph、cache 和 fallback，得到的往往是不可預測的延遲，而不是可控的成本下降。

實務上可以把決策分成 operation、layer、request 和 token／activation 四個層級。operation-level 讓 GEMM 採低精度而把 softmax、normalization 或 reduction 留在較高精度；layer-level 在部署前建立 precision map；request-level 依任務風險或 context 長度選擇 profile；token／activation-level 則在 runtime 依 amax、saturation 或 outlier 作細粒度決策。越接近 token 的層級越精細，但也越容易付出判斷、轉換、同步與 graph cache 的成本。

FP8 的關鍵不是位元數，而是 scale 如何跟著資料分布走

NVIDIA Transformer Engine FP8／FP4 Primer 說明 FP8 的 E4M3 與 E5M2 在可表示範圍和 mantissa 精度之間有不同取捨。forward 的 activation 與 weight 常需要較好的精度，gradient 則可能更重視 dynamic range；因此一個 profile 可能使用 HYBRID，而不是把所有 tensor 粗暴地轉成同一種 FP8。這也是為什麼「模型使用 FP8」不足以描述實際數值路徑。

縮放因子通常由 tensor 的最大絕對值 amax 推導。若每次都先完整產生高精度輸出、再掃描 amax、再重新量化，會多出一次 pass，可能抵銷低精度 GEMM 的收益。delayed scaling 會保存一段 amax history，在下一個 iteration 使用歷史統計；current scaling 則使用目前 tensor 的統計。兩者各有反應速度、穩定性、額外狀態與跨 rank 同步的取捨。

當輸入分布突然改變，舊 scale 可能讓值飽和或把有效值壓到零附近。系統應記錄 amax、scale、saturation rate、overflow／underflow、quantization error 與 profile version；不要只記錄最後選到的 dtype。遇到 scale 失配時，安全做法可以是暫時升到 BF16、重新 warm-up history、降低 batch 或回到已驗證的 static profile。

MXFP8 與 NVFP4：block size 會改變切換與驗收方式

MXFP8 官方文件描述以每 32 個連續值共用一個 E8M0 scaling factor 的 blockwise scaling；這比整個 tensor 共用一個 scale 更能處理局部 dynamic range。NVFP4 官方文件則使用每 16 個值的 local scaling，再配合 per-tensor global scaling；weight 又可能採 16×16 的 2D block。這些不是單純的 bit width 差異，而是資料佈局、轉置、scale metadata 與 kernel contract 的差異。

TensorRT Quantization Schemes也把 MXFP8 的動態 per-block activation quantization 與 NVFP4 的 per-block quantization 分開描述。當模型在 layer 之間切換格式時，router 必須知道 block dimension、tensor shape、最後一維是否符合條件、scale 的 dtype、rowwise／columnwise 方向與實際支援的 SM。只檢查 dtype 名稱，無法保證下一個 GEMM 能正確消費 tensor。

Layer Sensitivity 不是一次校準就結束

建立 precision map 時，應先固定 BF16 或 FP16 baseline，再逐 layer 或逐 operation 做受控替換。每次替換都要在多種輸入分布上觀察 task quality、logit divergence、activation saturation、throughput、memory、p95 latency 和錯誤率。聊天、數學、coding、長 context、工具呼叫與結構化輸出對數值誤差的容忍度不同，不能用一個平均分數替所有工作負載背書。

敏感度也可能來自位置而不只是 layer 名稱。embedding、首尾 projection、attention score、normalization、residual merge、router、loss 或最後幾層常有不同的誤差放大方式；同一 layer 在 batch size、sequence length、tensor parallel degree 改變後，使用的 kernel 與 reduction 順序也可能改變。要把 layer id、shape、parallelism、profile、資料集版本與 calibration seed 一起版本化，避免一張過期 map 被套到新模型。

對每個候選 profile 建立三個門檻：品質下限、效能收益下限與回退條件。若品質沒有下降但 latency 也沒有改善，profile 不必上線；若吞吐提升但 p99、GPU idle 或錯誤重試變差，也不應只報平均速度。只有在基線、候選與 fallback 的端到端結果都可重現時，才算找到可落地的精度切換點。

Request-level Routing 比 token-level 切換更容易治理

如果目標是讓高風險請求使用較高精度，request-level routing 往往是第一個可落地版本。router 可以在 admission 時使用任務類型、context 長度、租戶、延遲預算、工具權限與歷史品質選擇 BF16、FP8 或 FP4 profile；請求一旦進入 model replica，就不必在每個 token 重新編譯或切換 kernel。這種設計也較容易做 A/B、quota、容量預估與回滾。

router 的輸入不能直接使用未驗證的使用者字串作為高低精度決策。應將任務分類、風險規則、模型版本、precision profile 與 rollout percentage 寫入可追蹤的 policy。每次輸出保留 run id、profile id、scale policy、model hash、fallback reason 與 quality check 結果；遇到品質異常時，才能重現「當時為何選了這個精度」。

Token／Activation-level 切換的工程成本

每個 activation 都做 precision decision，會引入額外 reduction、rank synchronization、scale broadcast、requantize、dequantize 和 kernel dispatch。batch 內不同 token 若選不同格式，可能需要分桶或拆 batch；拆分後雖然數值更精細，卻可能降低矩陣乘法的形狀效率。若使用 CUDA Graph 或編譯器做 shape／dtype specialization，profile 組合過多還會造成 compile cache explosion。

動態切換還要處理 hysteresis。若 threshold 只設定單一邊界，amax 在邊界附近抖動時，系統可能在 FP4、FP8、BF16 間來回切換，產生 latency jitter 和 scale 震盪。可使用升級與降級兩個不同門檻、最小 hold time、profile cooldown、滑動視窗與 request-level sticky routing。這些控制規則要在壓力測試中驗證，不能只在離線 notebook 中觀察平均誤差。

if error_rate > quality_limit or saturation > high_limit:
    upgrade_profile(request, hold_steps=min_hold)
elif stable_steps > cooldown and saturation < low_limit:
    consider_downgrade(request)
else:
    keep_current_profile()

Fallback 要保護資料與副作用，不只是換回 BF16

最簡單的 fallback 是重跑高精度 model，但真實服務還要保留 input、tool state、streaming cursor、idempotency key、random seed 與已發出的副作用狀態。若低精度版本已經呼叫付款、寄信、寫資料庫或提交 job，直接重跑可能造成重複操作。高精度 fallback 應先檢查上一輪是否已 commit，再決定 resume、compensate 或人工 review。

監控應把精度與結果放在同一條 trace：profile、layer map、scale version、amax、saturation、quantization error、retry、fallback、quality evaluator、p50／p95／p99 latency、GPU memory 與 energy。不要把「沒有 exception」當成品質通過；結構化 JSON、tool call schema、引用、拒答、安全 policy 與長 context retrieval 都需要各自的驗收器。

一套可重現的導入順序

1. 保存 BF16／FP16 baseline，包含輸出、品質、延遲、記憶體與硬體環境。
2. 先上固定 operation／layer mixed precision，將敏感操作留在高精度。
3. 建立 amax、scale、saturation、logit divergence 與資料分布報表。
4. 在同一模型 hash 與 shape 矩陣下比較 FP8、MXFP8、NVFP4 與 fallback。
5. 用 request-level routing 做小流量 canary，保留明確的升級與回滾條件。
6. 只有當判斷與 kernel 成本可量測時，才試 token／activation-level switching。
7. 每次 driver、CUDA、Transformer Engine、TensorRT、模型或 topology 更新都重跑相容性與品質矩陣。

動態精度真正的價值不是把每個數字都壓到最小，而是把高精度留給會放大誤差的地方，把低精度用在可以量化收益的路徑。能被觀測、能回退、能重現的 static mixed precision，通常比沒有治理的 per-token switching 更接近 Production。

數值驗收：先驗證誤差，再談節省多少記憶體

每個 precision profile 都應有固定的 reference tensor、reference output 與誤差報告。對 GEMM 可以比較 absolute error、relative error、cosine similarity、max error 與 saturation；對 Transformer 則要再觀察 attention score、residual、logit、top-k 穩定性與整體 task score。reference 必須固定模型 hash、資料版本、seed、shape、batch、sequence length 與 parallelism，否則每次輸入差異都可能被誤判成量化誤差。

Scale 的驗收要涵蓋 cold start、warm-up、資料分布突變與長時間穩態。cold start 沒有 amax history 時，應使用安全初始值或高精度 warm-up；warm-up 期間要記錄 scale 是否快速震盪；分布突變時要檢查 delayed scaling 的反應時間與 saturation；長時間運行則要確認 history、scale cache、profile cache 與 checkpoint 不會無限成長。對分散式訓練，還要驗證各 rank 使用的 metadata 是否一致，避免某一 rank 靜默使用另一套 scale。

品質回歸不應只用總平均分數。要把不同任務切片，至少包含一般聊天、數學、coding、長文引用、結構化輸出、工具呼叫、安全拒答與多語內容。若某個 profile 只在平均分數上通過，卻讓 JSON 解析、工具參數或引用正確率下降，仍應視為不合格。對高風險請求，可把高精度 profile 設為預設，讓低精度只在有獨立品質閘門和人工抽查時使用。

效能回歸也要分離「算子更快」與「服務更快」。記錄 quantize、dequantize、requantize、scale reduction、kernel launch、graph lookup、queue wait、model compute、streaming first token、inter-token latency、p99、GPU memory、CPU usage 與 energy。若動態判斷節省了 GEMM 時間，卻增加了 graph miss 或 batch split，端到端可能反而變慢。只有在相同品質門檻下，端到端延遲、吞吐或容量確實改善，才應把 profile 標為 candidate。

最後要做故障注入：故意讓 scale metadata 過期、profile cache miss、某一 rank 回報不支援的格式、kernel compilation timeout、quality evaluator 失敗與高精度 replica 滿載。每一個故障都應產生明確 trace、保留原始輸入狀態、避免重複副作用，並回到可驗證的 baseline。這套測試才是 dynamic precision 能否落地的證據，而不是一張漂亮的 precision map。

驗收報告還應保留 profile 的建立日期、模型與 tokenizer 版本、校準資料範圍、硬體架構、驅動與框架版本，以及被排除的輸入類型。當結果不符時，先判斷是數值誤差、資料分布改變、shape 不相容、拓樸改變還是路由 policy 漂移，再決定修正 scale、重新校準、升級 precision 或撤回 profile。把這些原因分開，才能讓下一次切換有可重複的修復路徑，而不是重新猜 threshold。

這也代表 precision map 是版本化資產，不是埋在程式裡的常數。每次調整 threshold、block policy 或 fallback，都應產生新版本與差異摘要，並能從 trace 反查到當時的 map 與 scale 規則。

沒有這些版本資訊，就無法判斷品質回退究竟來自模型、資料、硬體或切換規則，也無法可靠回滾。

版本化讓每次切換都能被追蹤、比較、審核、重現、回溯、解釋與復原。

每次實際新部署也要保留完整差異與理由。

這是可追蹤的數值治理要求。

官方資料與圖片來源

本文依據 NVIDIA Transformer Engine FP8／FP4 Primer、Transformer Engine MXFP8、Transformer Engine NVFP4、NVIDIA TensorRT Quantization Schemes與 Transformer Engine Common API整理。格式支援、block size、scale、kernel、GPU architecture 與 framework integration 會隨版本與硬體改變，本文提供設計與驗收框架，不把官方文件內容宣稱成任一模型的通用準確率或效能保證。圖片使用 NVIDIA Transformer Engine 官方 MXFP8 圖，保留來源頁與原始圖片 URL，不主張超出 NVIDIA 文件的授權範圍。

__DYNAMIC_PRECISION_SWITCHING_26517_SOURCE_IMAGE_RECONCILE_20260816__