螞蟻集團與 vLLM 社群聯合開源了量化推論核心函式庫 Humming，程式碼放在 vLLM 專案組織底下，可以直接用 pip install humming-kernels 安裝。從 vLLM 0.29.0 開始，CUDA 版安裝套件已經內建這項相依元件，使用者加上 --linear-backend humming 或 --moe-backend humming 即可切換。
部落格列出的螞蟻貢獻者有 Jinzhen Lin、Zekai Gu、Zhilin Huang，社群方面則有 Red Hat 的 Michael Goin 等人。
一個函式庫，涵蓋一長串格式
量化推論的老問題是格式太多：權重 4 位元、啟用值 16 位元是一套核心，換成 8 位元啟用值又是另一套，FP4、MXFP4、NVFP4 也各有各的寫法。Humming 的思路是把「量化如何描述」和「核心如何執行」拆開，再用共用元件組合出具體的核心，原文的說法是 "separating quantization descriptions from execution choices"。
目前支援的組合包括 WnA16、W8A8、W4A8、W4A4，資料型別從 INT1 到 INT8、FP4 到 FP8，另有 MXFP4、MXINT4、NVFP4。硬體方面涵蓋輝達 Turing 之後的所有架構，從 Hopper 的 H20、H200，到 Blackwell 的 B300 與消費級 SM120。
以下是幾組單層矩陣乘法的比較（均為專案方自行測試，條件請見原文圖表）：
| 情境 | 比較對象 | 加速幅度 |
|---|---|---|
| 稠密 W4A16，小批量 | cuBLAS | 多數裝置約 3-4 倍 |
| W4A8-MXFP4，H200 | DeepGEMM W8A8 | 約 4.5 倍 |
| MoE W4A16，B300 大批量 | Marlin | 約 5 倍 |
端對端測試使用的是 DeepSeek-V4.1-Flash，8 張 H20，張量平行 8。MoE 部分從 Marlin W4A16 換成 Humming W4A8 後，輸出吞吐量提升約 14% 到 43%，首個 token 延遲下降約 25% 到 32%，並行數越高，收益越大。
對中國大陸的部署方意味著什麼
這份部落格的測試平台，幾乎是照著中國大陸推論叢集的現實配置挑選的。H20 是輝達針對中國市場推出的特規卡，運算力被砍、記憶體頻寬保留，跑大型模型推論時，低位元量化幾乎是必選項。端對端測試用的又是 DeepSeek 自家的 MoE 模型，中國不少團隊手上正是這套組合。
另一個細節是相容 CUDA 的中國國產裝置：部落格把阿里巴巴平頭哥（T-Head）的真武 810E（Zhenwu 810E）列入支援清單，路線圖中還寫著要適配更多平頭哥 PPU 裝置，例如真武 M890。螞蟻與平頭哥同屬阿里體系，這條線後續能推進到什麼程度，要看上游合併的節奏。
對已經在用 vLLM 的團隊而言，遷移成本主要在驗證：Humming 能直接讀取的格式，不需要重新量化模型；vLLM 原生不支援的格式，例如 GPTQ INT3，可以走 --quantization humming 這條相容路徑。
明確寫出的短板
部落格把限制列得很清楚。B300 的新指令不再支援 INT8 運算，INT8 矩陣乘法只能走舊指令，效能明顯偏低；下一代 Rubin 不支援 Blackwell 上那兩種隱藏的 Tensor Core 格式。核心配置目前靠啟發式規則挑選，作者承認選不出全域最佳解，自動調校也還沒做完。
編譯速度是另一個賣點。在 H200 上關閉快取，單一 W4A16 核心用 Humming 加 NVRTC 編譯只要 1.88 秒；模型暖機時，涵蓋單層所有尺寸的核心大約 2 到 4 秒就能編完。對於經常更換模型、更換格式做實驗的團隊，這比吞吐量數字更能省時間。
參考來源：vLLM 官方部落格、Humming GitHub 儲存庫、CocoLoop；吞吐量、延遲與編譯耗時均以專案方公布的測試口徑為準。