在 NVIDIA B300 GPU 上使用 vLLM 服務 GLM-5.2

vLLM 已成功在 24 顆 NVIDIA B300 GPU（三台 8-GPU 伺服器）上使用分離的 Prefill/Decode（P/D）拓撲部署 GLM-5.2-NVFP4。透過為服務等級協議（SLA）合規而非峰值吞吐量進行優化，團隊將平均每輸出標記時間（TPOT）從近 40 ms 降至 17 ms，滿足了在 16K 至 256K 標記的上下文長度下，平均 TTFT ≤ 2.5 s 和平均 TPOT ≤ 20 ms 的生產目標。

優先考量 SLA 合規而非峰值吞吐量

在共置服務中，prefill 區塊可能與 decode 批次交錯，導致長提示增加現有請求的間標記延遲。vLLM 利用 P/D 分離將 prefill 工作從 decode 關鍵路徑中移除，確保 TPOT 完全由 decode 批次組成決定。

此部署的生產需求包括：

• 上下文長度： 16K–256K 標記。
• 平均 TTFT（Time to First Token）： ≤ 2.5 s。
• 平均 TPOT（Time Per Output Token）： ≤ 20 ms（約 50 標記/秒）。
• 吞吐量： 僅在滿足兩個延遲限制後才最大化。

GLM-5.2 是一個具有 40B 活躍參數的 744B 參數 MoE 模型，採用 DSA 稀疏注意力和 MTP 投機解碼。

優化 Decode 效能

初始配置導致 16K 標記輸入的平均 TPOT 接近 40 ms。以下優化被實施以將此控制在 SLA 範圍內：

混合批次的投機填充

分析顯示，當請求從 Prefill 節點轉移到 Decode 節點時，其第一個 Decode 步驟僅需要一個標記，而使用 Multi-Token Prediction（MTP）的現有請求需要 1 + N 個標記。此不匹配會產生混合批次，迫使系統從快速 CUDA Graph 路徑回退到昂貴的逐段或急切執行。

為解決此問題，vLLM 在 Decode 端實作了投機填充，為新請求的第一步添加虛擬標記以匹配 1 + N 形狀。此優化（已合併至 PR #45237）使平均 TPOT 從 40 ms 降至 22 ms。

Model Runner V2 (MRV2)

啟用 Model Runner V2 (VLLM_USE_V2_MODEL_RUNNER=1) 提供了 TPOT 的 11% 減少。主要改進包括：

• 預熱核心： GLM-5.2 DSA 編目器 prefill-metadata 核心被加入啟動預熱（PR #47285）以防止冷啟動延遲尖峰。
• 局部 Argmax 減少： 多 GPU MTP 現在使用局部 Argmax 減少（PR #46448），將 TP 通信量從完整詞彙 logits 減少至約 2 × TP 大小。
• 動態投機長度： 完整 CUDA Graphs 現在支援動態投機長度（PR #45953），減少急切回退。

通訊與圖形配置

• All-to-All 後端： 將預設 EP 後端替換為 flashinfer_nvlink_two_sided 後端使 TPOT 減少 4%。
• CUDA Graph 模式： Decode 實例使用 FULL_DECODE_ONLY 模式並搭配 --max-num-batched-tokens 1024，這提供完整圖形覆蓋同時降低啟動編譯時間。
• MTP 配置： Decode 端使用 num_speculative_tokens=3 以攤銷執行成本，而 Prefill 端使用 num_speculative_tokens=1 以優先快速 KV 快取交接。

Prefill 並行性與容量權衡

在評估 Prefill 的並行策略時，團隊比較了 TGS（每 GPU 吞吐量）。雖然 TP1 DP4 EP 每 GPU 的效率不是最高（TP1 DP2 EP 高 8%），但選擇 TP1 DP4 EP 是為了確保 GLM-5.2 的 1M 標記上下文能力具有足夠的 KV 快取容量。

穩定 MTP 接受率

為確保在高併發下投機解碼仍然有效，vLLM 實作了 IndexerCache（PR #44420）。此機制重複使用 DSA 編目器產生的 Top-K 稀疏索引，防止系統為每個 MTP 草稿步驟重新執行編目器。

其他穩定性修復包括：

• Indexer 初始化： 改進了在跳過 Top-K 層時的歸一化迴路和初始化（PR #45895）。
• 共享 Index 緩衝區： 優化了批次請求的佈局，僅保留最終查詢標記的索引（PR #47238）。
• Post-Final-Norm 隱藏狀態： 確保 MTP 迴圈重複使用 post-final-norm 隱藏狀態（PR #47448）。

在 AIME 2025（86.67）、GPQA (92.89) 和 LongBench V2 (64.01) 上的準確度驗證確認，這些優化未降低輸出品質。

生產可觀測性與穩定性

對於分離的 P/D 部署進行監控需要追蹤兩個資源池的指標。關鍵指標包括每個池的 TTFT/TPOT 百分位數、MTP 接受率以及 KV 傳輸延遲。

在長期穩定性測試期間，團隊發現主機記憶體洩漏，vLLM 處理程式的 RSS 在數十小時內線性增長。根本原因是 SingleTypeKVCacheManager.new_block_ids 中不一致的閘機制（PR #35219），它為非 Mamba 模型記錄了區塊分配但從未清除。此問題透過在每個排程步驟無條件排空 take_new_block_ids() 得以修復。

部署配方

硬體與拓撲

• 硬體： 3 × 8 B300 GPU（共 24 顆）。
• 模型： GLM-5.2-NVFP4。
• 拓撲： 4 個 Prefill 節點（TP1 DP4 EP，16 GPU）和 1 個 Decode 節點（TP1 DP8 EP，8 GPU）。
• KV 傳輸： NIXL。

配置指令

Prefill 節點：

export VLLM_USE_V2_MODEL_RUNNER=1
vllm serve /mnt/model/glm/GLM-5.2-NVFP4 --trust-remote-code --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_producer"}' --chat-template-content-format=string -ep -tp 1 -dp 4 --tool-call-parser glm47 --enable-auto-tool-choice --reasoning-parser glm45 --gpu-memory-utilization 0.92 --enable-prompt-tokens-details --speculative-config='{"method":"mtp","num_speculative_tokens":1}' --shutdown-timeout 300 --fingerprint-mode=none

Decode 節點：

export VLLM_USE_V2_MODEL_RUNNER=1
vllm serve /mnt/model/glm/GLM-5.2-NVFP4 --trust-remote-code --chat-template-content-format=string --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_consumer"}' --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' --max-num-batched-tokens 1024 -ep -tp 1 -dp 8 --tool-call-parser glm47 --enable-auto-tool-choice --reasoning-parser glm45 --gpu-memory-utilization 0.90 --enable-prompt-tokens-details --all2all-backend=flashinfer_nvlink_two_sided --speculative-config='{"method":"mtp","num_speculative_tokens":3}' --shutdown-timeout 300 --fingerprint-mode=none