NVIDIA 公布 DGX Spark 上 Ling-3.0-flash MoE 推論優化三法，GSM8K 吞吐量提升 42.5%

背景

Ling-3.0-flash 是由 Inclusion AI 開發的混合專家（MoE，Mixture-of-Experts，一種將模型參數分散到多個專家子網路，每次僅啟用部分專家的架構）模型。該模型總參數為 124 billion，每個 token 的活躍參數為 5.1 billion，包含 42 層結構，其中 35 層為 Kimi Delta Attention (KDA) 線性注意力層，7 層為多頭潛在注意力（MLA，Multi-head Latent Attention，一種透過低維潛在向量來壓縮注意力計算的架構）層。每個 MoE 層將每個 token 路由至 512 個路由專家中的 8 個，以及 1 個共享專家。模型原生支援 256K token 的上下文視窗，可擴展至 1M token，並提供推理模式開關以適應不同任務需求。 官方原文・NVIDIA Developer Blog

發生什麼事

NVIDIA 發布技術指南，說明如何在 NVIDIA DGX Spark 上提升 Ling-3.0-flash 的推論效能。在 batch-size-1 的評估中，分析顯示解碼階段受限於記憶體頻寬，主要瓶頸在於讀取模型權重，特別是 MoE 計算與輸出層投影（LM head）。NVIDIA 提出了三種優化技術：使用 Humming MXFP4 MoE 核心、對 LM head 進行 Online FP8 量化，以及使用 NEXTN 進行多 token 預測（MTP，Multi-Token Prediction，一種投機解碼技術，先預測多個 token 再一次性驗證）投機解碼。 官方原文・NVIDIA Developer Blog

重點內容

第一種優化是將 MoE 執行後端從 flashinfer_mxfp4 替換為 Humming。Humming 是一個獨立的 kernel 庫，透過 humming-kernels pip 套件提供。不同於 FlashInfer CUTLASS 路徑，Humming 使用 NVIDIA CUDA Runtime Compilation (NVRTC) 在執行時針對實際的 M/N/K 維度、資料類型和 GPU 架構生成並編譯 CUBINs，並快取於 ~/.humming/cache。這使得 kernel 能針對 Ling-3.0-flash 的特定形狀（如 moe_intermediate_size 為 768）進行最佳化。實測顯示，僅啟用 Humming MoE 後端可將 TPOT（Time Per Output Token，每個輸出 token 的時間）從基準的 27.71 ms 降至 25.35 ms，解碼吞吐量從 36.09 tok/s 提升至 39.45 tok/s，相對於基準提升 9.3%。 官方原文・NVIDIA Developer Blog

第二種優化是對 LM head 進行 Online FP8 量化。在檢查點中，LM head 以 BF16 儲存且未被量化，其詞彙表 GEMM 維度為 157,184 × 2,560，每個生成 token 都需讀取整個權重區塊。透過設定 SGLANG_ENABLE_FP8_LM_HEAD=1，僅在構建 LM head 時應用動態 FP8 量化，將權重從 BF16 轉為 FP8，使該層的讀取量減半。此設定與基準的 --enable-fp32-lm-head 選項互斥。啟用此優化後，TPOT 進一步降至 22.76 ms，吞吐量提升至 43.94 tok/s，相對於基準提升 21.7%。 原文

第三種優化是利用 Ling-3.0-flash 內建的 NEXTN 預測層進行 MTP 投機解碼。該層可直接作為草稿模型，無需額外訓練。配置為 3 個草稿步驟和 4 個 token 的驗證視窗。在合成工作負載中，此優化使 TPOT 降至 9.72 ms，吞吐量達 102.88 tok/s，相對於基準提升 185.1%。然而，在 GSM8K 真實任務評估中，由於輸出重複性較低且採樣參數不同，接受長度從合成的 3.90 降至 2.68。當同時啟用 Online FP8 LM head 量化與 MTP 時，草稿模型必須與目標模型共享整個 LM head 模組，否則會因權重解釋錯誤導致效能下降至低於基準。 原文

對使用者的意義

開發者可在 NVIDIA DGX Spark 上部署 Ling-3.0-flash 時，透過啟用這三種優化來提升效能。在 GSM8K 全量評估中，三種優化結合使解碼吞吐量提升 42.5%，平均端到端延遲降低 24.5%，且準確率僅從 96.89% 微降至 96.82%（差異 0.08 個百分點），在統計上無顯著變化。這意味著在保持模型品質的同時，可顯著改善代理工作流（agentic workflows）的響應速度。開發者可參考 Ling cookbook 中的 MXFP4 部署筆記本進行設定。 官方原文・NVIDIA Developer Blog

限制與未定事項

合成工作負載的效能增益（185.1%）不能直接套用於其他工作負載，因為合成輸出重複性高且採樣方式不同。在部署時，必須驗證每個優化在啟動時是否正確啟用，特別是 MTP 與 FP8 LM head 的整合需要特定的介面支援，否則系統會無聲地降級至比未優化基準更慢的狀態。 官方原文・NVIDIA Developer Blog