NVIDIA 嘅 technical blog 喺 10 月 27 日出了一篇《3 Ways to Boost MoE Inference on NVIDIA DGX Spark》，示範點樣喺一台「桌面級」硬件上把 124B 參數嘅 MoE（Mixture-of-Experts，混合專家）模型推理跑快。模型係 Inclusion AI 嘅 Ling-3.0-flash-fp4，總參數 124B，每個 token 只激活 5.1B，42 層結構入面有 35 層 KDA 線性注意力加 7 層 MLA，每個 MoE 層把 token 路由去 512 個專家當入面嘅 8 個，另加一個共享專家。原生 context 256K，可以擴展到 1M。
呢篇文最誠實嘅位：佢哋寫咗 profiling 結果，batch-size-1 之下 decoding 係 memory-bound，即係讀入權重嘅時間佔咗執行時間嘅大部分。兩個熱點：MoE 計算同輸出層（LM head）嘅 projection。LM head 嘅 GEMM 係 157,184 × 2,560，每個 token 生成都要讀入呢塊權重，所以喺帶寬瓶頸下係瓶頸之一。
第一招：Humming MXFP4 MoE kernel。用 NVRTC（CUDA Runtime Compilation）喺 runtime 實時 compile 個 kernel，對住實際嘅 M/N/K shape、資料類型同 GPU 架構專門化，cache 喺 ~/.humming/cache。文章話 Humming 個個 kernel 幾秒完成，FlashInfer CUTLASS path 要 comp 97 個 target，要幾十分鐘。針對 Ling-3.0-flash 嘅 moe_intermediate_size 768 有專門優化。
第二招：LM head 嘅 online FP8 量化。原本 LM head 係 BF16，checkpoint 入面列喺 modules_to_not_convert 唔會 quantize。改成 FP8 之後，逐 token 嘅權重讀量由 2 byte 降到 1 byte，直接減半。
一次 verify 多於一個 token，攤薄每個 output token 嘅計算成本。
最罕有嘅位：佢哋直接出聲講明，三個優化同時開，可以令整體反而慢於 baseline。佢哋話係一個 integration issue，但冇進一步解釋係邊個 interaction 導致。基線配置係 cookbook 嘅 W4A8：FlashInfer MXFP4 MoE kernel、CUTLASS dense GEMM、-enable-fp32-lm-head。
模姐驗嚇貨
呢篇技術文嘅價值唔係三個優化本身——量化、kernel 專門化、speculative decoding 都唔係新概念——而係佢哋寫出咗「feature 疊埋會拖慢」呢個事實。業界多數廠商嘅 release note 同 benchmark 片會展示最好組合，唔會寫出邊個組合係壞嘅。NVIDIA 喺自家產品嘅自家 hardware 上面，寫出成個 combination 會令結果比 baseline 差，呢種透明度喺廠商技術文入面係罕有。
同時要留意：所有數據來自 NVIDIA 自家測，用自家模型（唔係——Ling 係 Inclusion AI 嘅），喺自家硬件 上面。冇獨立第三方覆核。Humming kernel library 嘅 pip package 同 cookbook 冇喺材料入面提供連結，部署指令指路去「Ling cookbook」但冇附 URL。對實際想跑呢個配置嘅工程師，可操作性仲有待確認。
