vLLM Humming 效能實測：加速效果在哪裡成立

如果你要在 Hopper 級硬體上，以高並行度部署量化 MoE 模型，vLLM Humming 確實值得優先測試；但目前公開的基準結果，還不足以把它視為通用的後端升級方案。H100 的 group-32 測試，以及 Ampere 上的 batch-1 decode，都說明了一件事：模型、GPU、量化格式和 batch 形狀，必須逐一實測。

先講結論：Humming 是有條件的升級

Humming 是一套針對量化推論的 JIT 編譯 GEMM kernel 函式庫，由 vLLM 社群與 Ant Group 共同推出，支援多種量化格式，以及不同世代的 NVIDIA GPU，涵蓋 dense 與 mixture-of-experts（MoE）工作負載。官方公告宣稱 kernel 最高可加速 5 倍，部分端到端 MoE 效能則提升 14%–43%；不過這些數字都來自特定的模型、硬體、量化格式與並行度組合（vLLM 公告）。

我的採用原則很簡單：

• 優先測試 Humming：如果你在支援的 Hopper 或更新架構上，以大 batch 或高並行度執行 W4A8/W4A16 MoE 服務。
• 不要預設一定會變快：尤其是 batch-1 decode、較舊的 Ampere GPU，或採用特殊 group-wise scaling 的情況。
• 保留 fallback：目前的 issue 回報已經包含形狀路由錯誤，以及特定後端觸發慢速路徑的問題。

一份獨立的 DeepSeek-V4.1-Flash 測試報告顯示，在單一四張 GH200 的節點上，調校後的 vLLM 基準版本達到每秒 5,856 個輸出 token；加入 data-parallel attention 後為 12,802；改用 Humming W4A8 kernel 後則達到 17,634（工程測試報告）。但這個結果同時需要 kernel 修正與調校，因此它證明的是某一類工作負載的潛力，而不是開箱即用的保證。

Humming 會改變 vLLM 部署的哪個環節？

Humming 將量化矩陣乘法移到更彈性的 JIT kernel 層，處理 dense 與 MoE GEMM 路徑。專案目標是支援從 Turing 開始的 NVIDIA 架構，以及多種低位元格式（Humming 儲存庫）。

在引用的 Hopper 測試中，Marlin 會先把 FP4 權重解量化成 BF16；Humming 則是在 SM 內將 FP4 權重提升為 FP8，再使用 FP8 tensor core 進行乘法。只有當 decode 工作負載轉為受計算能力限制時，這項差異才真正帶來幫助。否則，記憶體流量、形狀分塊、scale 處理、kernel 啟動開銷與暫存器壓力，都可能成為主要瓶頸。

哪些情境真的會加速？哪些情境反而消失？

與其把公開結果濃縮成一個醒目的百分比，不如把它們視為一張效能邊界地圖。

高並行度 MoE：目前最明確的優勢

官方 DeepSeek-V4.1-Flash 範例在八張 H20 GPU 上比較 Marlin W4A16 與 Humming W4A8，端到端 MoE 吞吐量提升 14%–43%，而且並行度越高，改善幅度越大。一名轉貼該基準測試的使用者提供了更具體的數字：並行度 64 時，輸出速度從每秒 442 個 token 提升到 634 個 token；不過他也指出，兩者使用的量化格式並不相同（使用者討論）。

這項結果支持 Humming 成為值得嘗試的服務路徑，但不能把它解讀成單純同格式 kernel 的倍數加速。

H100 group-32 W4A8：值得認真看待的警訊

Humming issue #38 在 H100 上測試 MXFP4 權重、MXFP8 activation 與 group-32 scale。所有比較路徑的數值結果都正確，但在報告中的矩陣形狀下，fused 路徑卻慢了非常多。在 (4096,3072,4096) 形狀中，fused Humming 耗時 4.969 ms，QDQ 基準則為 0.580 ms；在 (4096,14336,4096) 形狀中，兩者分別為 22.298 ms 與 1.256 ms（issue #38）。

該 issue 後續記錄了超過 500 TFLOPS 的本地調校結果；另一個實驗性實作則在額外前處理與權重儲存的配合下，達到約 580–665 TFLOPS。因此，scale 粒度、分塊選擇、暫存器壓力與前處理方式，都可能讓結果徹底改觀。

SM80 單請求 decode：不要從 Ampere 推論出普遍增益

Issue #72 回報 NVIDIA SM80 在 M=1 decode 下的 INT3 利用率偏低。在 CMP 170HX 上，實測 Humming kernel 約為 691 GB/s，相較於約 1,591 GB/s 的 HBM 峰值頻寬，利用率為 43.4%。作為對照，RTX 5070 Ti SM120 的測試約達 753 GB/s，峰值為 827 GB/s，利用率約 91%（issue #72）。

同一份報告也引用 A800 儲存庫中的結果：M=1 時為 692.4 GB/s，只達標示之 2,039.04 GB/s 峰值的 34.0%。在該比較中，純 BF16 則達到 1,232.3 GB/s。

「目前 SM80 的 INT3 Humming 路徑，是否不適合這類工作負載？」— yangfangyunyun，vLLM Humming issue #72

安裝方式，以及最安全的第一次測試

官方資料指出，從 vLLM 0.29.0 開始，CUDA 安裝會將 Humming 納入相依套件。MoE 路徑可使用 --moe-backend humming，支援的 linear layer 可使用 --linear-backend humming；針對特定模型，也可以採用文件所列的 Humming 量化設定（vLLM 量化文件）。不過，在不同架構之間複製參數前，務必先確認對應版本與模型文件。

第一次測試建議採用受控流程：

1. 記錄 vLLM、CUDA、PyTorch、GPU 架構、checkpoint 量化方式與模型形狀。
2. 固定 prompt 長度、輸出長度、並行度與重複測試次數。
3. 使用相同的服務啟動指令，再加上對應的 backend 參數，比較現有後端與 Humming。
4. 測量輸出 token/s、TTFT、token 間延遲、GPU 記憶體，以及啟動與 JIT warm-up 時間。
5. 等待 kernel cache 暖機後再次測試，接著分別測量 batch 1 與正式環境的並行度。
6. 針對不支援的形狀與選擇失敗情況，保留自動或手動 fallback。

單看吞吐量提升並不夠。如果 TTFT、尾端延遲、暖機成本或記憶體使用量變差，整體服務仍可能不適合上線。vLLM 的 perf-eval 專案建議使用 YAML 測試配方、重複執行、以中位數彙整結果，並固定輸入與輸出長度，讓測試具備可比性（perf-eval 儲存庫）。

後端路由可能讓可用的 Humming 設定無法啟動

另一個 vLLM issue 說明了為什麼 fallback 測試不可省略。在 issue #60700 中，一個 compressed-tensors W4A8 MoE checkpoint 的中間維度為 640。CUTLASS 要求維度必須對齊 256，Humming 卻能處理該測試形狀；但在選定後端載入前，程式就先執行了無條件 assertion，結果即使明確指定 --moe-backend humming 也會啟動失敗。

回報者提出的修補程式，將 assertion 限制在 CUTLASS 路徑內。套用後，兩張 H100 NVL GPU 成功載入全部 62 個 shards；測試結果顯示，相較於參考用的 CUTLASS 設定，TTFT 降低 12%–50%，系統吞吐量提升 2%–13%（issue #60700）。檢查時該 issue 仍未關閉，PR #60711 則被提出作為路由修正方案。

因此，Humming 啟動失敗不一定代表 kernel 本身有問題，也可能是 vLLM 的能力檢查出了問題。在放棄這組設定前，先確認實際選用的後端、形狀限制，以及相關修正的進度。

給營運者的決策表

常見問題

Humming 支援哪些 GPU？

該專案的目標是支援從 Turing 開始的 NVIDIA GPU，並記錄了多種量化路徑。不過，支援某個架構不代表所有格式與工作負載都經過同等程度的調校；SM80 以及特殊 scaling 情境，仍需要各自進行基準測試。

使用 Humming 是否需要預先量化的 checkpoint？

Humming 是推論 kernel 函式庫，不是通用量化工具。引用的工作流程使用了具備相容量化權重與 activation scheme 的 checkpoint，因此正式服務前，請先根據 vLLM 文件與儲存庫確認模型格式。

Humming 是否比其他 vLLM 後端都快？

不是。它在部分量化工作負載中更快，尤其是目前公開的高並行度 MoE 案例；但結果會受到架構、格式、維度、scale 分組方式與 batch size 影響。

實際取捨很明確：只要工作負載匹配，Humming 確實可能大幅提升量化 vLLM 服務的速度；但由於公開結果都高度依賴設定，採用前安排一次短時間、可重複的對照測試，是整個導入流程的一部分。