vLLM Kimi K3 支援

vLLM Kimi K3 支援

vLLM 已宣布對 Kimi K3 提供高效的 day-0 支援，這是一個擁有 2.8 兆參數的開源權重多模態 Mixture-of-Experts (MoE) 模型。此整合實現了 Kimi K3 獨特混合架構的高性能推理，在使用 16 個 NVIDIA GB300 NVL72 GPU 並搭配 DSpark 投機解碼（speculative decoding）時，每位用戶可達到高達 370 tokens/s 的速度。

Kimi K3 架構概覽

Kimi K3 是一個 2.8T 參數的模型，每個 token 會激活 896 個專家中的 16 個。它專為長文本效率而設計，透過幾項關鍵創新支持高達 100 萬 token 的窗口：

  • Kimi Delta Attention (KDA): 一種混合堆疊，將線性注意力層（維持固定大小的遞歸狀態）與週期性的全注意力層交錯排列，以保留全局召回率。
  • Attention Residuals (AttnRes): 一種機制，使用學習到的偽查詢（pseudo-queries）來加權來自前一個區塊的殘差狀態，取代標準的殘差累加。
  • Stable LatentMoE: 一種設計，將激活值投影到較窄的隱層維度進行路由專家計算，並利用 Quantile Balancing 根據路由分數的分位數來分配專家。
  • Native MXFP4: 該模型在 MoE 路徑上使用原生的 4-bit 權重，以減少頻寬需求。

vLLM 為 Kimi K3 進行的推理優化

為了處理 Kimi K3 對標準 Transformer 架構的偏離，vLLM 實現了幾種專門的推理機制：

混合 KV-Cache 管理

vLLM 使用單一混合 KV-cache 管理器來處理用於全注意力層的 paged KV blocks 以及用於 KDA 層的緊湊遞歸狀態區塊。為了在這種混合設計中實現前綴緩存（prefix caching），vLLM 將物理 KDA 狀態區塊與細粒度前綴匹配解耦，允許共享提示詞同時重用 KDA 狀態和 paged KV。

融合算子與元數據優化

  • Attention Residuals: vLLM 使用融合的 Triton 和 CUDA 算子在單次操作中計算深度注意力 logits、softmax 和隱層狀態聚合，減少了記憶體傳輸。
  • KDA Decode: 一個專門的 CUDA 算子將因果卷積、遞歸更新和 RMSNorm 融合到單次啟動中，以避免中間張量和重複的狀態傳輸。
  • KDA Prefill: vLLM 整合了 FlashKDA 及隨後的社群優化（Flash-Flash-KDA）來加速預填充（prefill）階段。
  • Metadata Builder: 專用的 Kimi K3 KDA 元數據生成器取代了即時（eager）PyTorch 操作，改用融合的 Triton 算子，在 batch size 為 1 時將元數據準備延遲降低了 96%（從 870°s 降至 34°s）。

低延遲計算

vLLM 在低 batch size 設定下採用 skinnyGEMM，繞過共享記憶體數據暫存，將端到端延遲降低約 10%。此外，LatentMoE 尾部融合（tail-fusion）優化減少了線性投影階段的冗餘計算，帶來了 7°8% 的端到端加速。

生產能力與性能

使用 DSpark 的投機解碼

vLLM 支持 DSpark，這是一種塊擴散（block-diffusion）投機解碼算法。使用透過 vLLM 和 TorchSpec 訓練的 DSpark 投機器，vLLM 在單用戶請求下實現了 3.14 倍的加速，將吞吐量從 118 tok/s 提高到 370 tok/s。接受率範圍從低熵任務（編碼）的每步 4.73 tokens 到高熵任務（創意寫作）的每步 2.61 tokens。

Prefill/Decode 分離 (Disaggregation)

對於高吞吐量環境，vLLM 支持 prefill/decode (PD) 分離。NIXL 連接器負責在獨立的 prefill 和 decode 副本之間管理 token 級別的 MLA cache 和請求級別的 KDA 狀態的傳輸。

代理式緩存保留策略 (Agentic Cache Retention Policies)

為了管理長文本代理工作負載中 KDA 狀態的記憶體佔用，vLLM 實現了兩種保留策略：

  • 基於間隔的保留： 以固定間隔（例如每 32K tokens）和提示詞邊界處自動檢查點化 KDA 狀態。
  • Marconi 風格的選擇性保留： 一種需求驅動的方法，僅在第二次命中前綴時緩存 KDA 狀態，確保只有頻繁共享的前綴會消耗緩存容量。

基準測試與硬體需求

性能指標

在 GB300 NVL72 GPU 上，vLLM 實現了以下單用戶解碼吞吐量 (batch size 1)：

配置 標準解碼 DSpark 投機解碼
TP8 111 tok/s 331 tok/s
TP16 118 tok/s 370 tok/s

準確度

vLLM 上的 Kimi K3 在最大推理強度下，於 GSM8K 得分 0.976，GPQA-Diamond 得分 0.939，OCRBench 得分 0.889，MMMU Pro Vision 得分 0.818。

硬體需求

部署 Kimi K3 最少需要 8× B300 (或 GB300 NVL72) GPU 或 16× B200 GPU。支援 NVIDIA (Hopper 和 Blackwell) 和 AMD (MI355X) 硬體。

部署指南摘要

若要運行 Kimi K3，vLLM 建議使用以下配置：

  • Prefix Caching: 必須透過 --enable-prefix-caching 明確啟用。
  • MoE Backend: 在分離/專家並行 (DEP) 環境中使用 deep_gemm_mega_moe，在 TP > 1 時使用 flashinfer_trtllm。
  • All-to-all Backend: NVLink 使用 flashinfer_nvlink_one_sided，RDMA 使用 deepep_v2。
  • Rust Frontend: 透過 VLLM_USE_RUST_FRONTEND=1 啟用。

Sources