vLLM PD Serving 運行 Qwen3.8-2.4T 達到每 GPU 5K TPS 與每使用者 180 gen tok/s

TL;DR

vLLM 的 PD Serving 在運行 Qwen3.8-2.4T 模型時，於高吞吐量模式下達到 每 GPU 5,000 總 Token 吞吐量，並在低延遲模式下達到 每使用者 180 個生成 Token/秒，為該模型在 GB300 NVL72 叢集上建立了完整的帕累托前沿 (Pareto frontier)。

公告概述

本部落格文章詳細介紹了 vLLM 如何在 GB300 NVL72 叢集上使用 8K/1K 工作負載達到上述效能。文中提供了可重現的 srt‑slurm 配方、逐步調優方法論，以及一個平衡總 Token 吞吐量 (TPS) 與每使用者互動性 (每使用者生成 TPS) 的完整帕累托前沿。此方法論被認為比原始數據更有價值，因為它適用於任何模型。

最大化吞吐量：並發與 KV‑Cache 限制

結論

每 GPU 的總 Token 吞吐量主要受限於 KV‑cache 容量，而這又取決於每個請求的 GDN 狀態大小。

技術細節

  • 模型架構：Qwen3.8-2.4T 擁有 92 層（69 層 GDN，23 層 Full‑Attn），每層具有 512 個專家的 MoE 區塊。
  • 權重佔用：91 GiB 非專家權重，1,242 GiB 專家權重。
  • KV‑cache 組成：
    • Full‑Attn 狀態：每 Token 每層 2 KiB。
    • GDN 狀態（每個請求）：4 MiB (SSM) + 120 KiB (conv) ≈ 4.216 MiB。
  • 區塊大小設定：GDN 狀態佔主導地位，導致每個區塊可容納 2,112 個 Token（每個區塊 4.125 MiB）。
  • GPU 記憶體基準：GB300 提供 279 GB；扣除驅動程式、CUDA context 以及 8% 的安全預留後，約剩餘 254 GiB 用於權重、激活值、CUDA graphs 和 KV‑cache。
  • 峰值激活記憶體：依拓撲結構測量（例如，TP8 搭配 20 個序列使用 0.57 GiB，TP4DP4 搭配 272 個序列最高使用 2.24 GiB）。
  • CUDA‑graph 預留：估算較為保守；實際使用量通常較低，但預留可防止 OOM。
  • KV‑cache 可用性：在扣除非權重記憶體（約 20 GiB）後，剩餘記憶體決定了可同時處理的請求數量。TP4DP4 拓撲結構提供了最多的 KV‑cache 空間，從而實現了最高的並發性。

Prefill 效能測量

結論

對於低並發情況，TP4DP2+EP 拓撲結構產生最佳的 Prefill 吞吐量；在較高並發下，TP2DP4+EP 則佔據優勢。

結果

Prefill 吞吐量是在 ISL/OSL = 8192/2 的條件下測量的。曲線顯示了一個明顯的交叉點，隨著並發增加，TP2DP4+EP 超越了 TP4DP2+EP。

Decode 效能測量

結論

MTP（推測解碼）顯著提高了 Decode 吞吐量，直到 KV‑cache 成為瓶頸；整體最佳的 Decode 拓撲結構是 TEP8 搭配 MTP，其次是在極高並發下的 TP4DP4+EP。

結果

Decode 測試使用 ISL/OSL = 1/1000。啟用包含三個推測 Token 的 MTP 後，每 GPU 吞吐量有所提升，隨後 TEP8 拓撲（搭配 MTP）在達到 KV‑cache 限制前處於領先地位，之後則由 TP4DP4+EP 接手。

分離式帕累托前沿 (Disaggregated Pareto Frontier)

結論

結合最佳的 Prefill 與 Decode 配置，最終的帕累托前沿顯示該模型達到了 每 GPU 5K 總 Token 吞吐量 與 每使用者 180 個生成 Token/秒。

環境與可重現性

  • 硬體：GB300 叢集，NVLink72 互連。
  • 工作負載：ISL = 8192, OSL = 1024, 並發 1–2560。
  • 模型：來自 HuggingFace 的 Inferact/Qwen3.8-2.4T-A95B-NVFP4。
  • 軟體堆疊：
    • vLLM Docker 映像檔 vllm/vllm-openai:nightly-a9a17 (版本 v0.26.1rc1.dev1177+ga9a17e709)。
    • Dynamo 1.2.0.dev20260526。
    • srt‑slurm v1.0.98。
    • AIPerf v0.12.0。
  • 配方：所有啟動腳本皆位於 srt‑slurm‑recipes 儲存庫中的 recipes/multi-node/Qwen3.8/GB300/8k1k/vllm/disagg 路徑下。

準確度驗證

所有配置皆在 GSM8K 基準測試中進行了驗證，全面達到 95% 的準確度，證實效能提升並未犧牲模型品質。

效能視覺化

  • 圖 3 – 每個分離式配置的帕累托曲線（針對並發的個別掃描）。
  • 圖 4 – 顯示總 TPS 與每使用者生成速度之間最佳權衡的綜合帕累托前沿。

對從業者的啟示

結論

所提出的調優工作流程——估算 KV‑cache、測量激活值與 CUDA‑graph 開銷，以及針對工作負載選擇拓撲結構——使從業者能夠在 vLLM 上為任何大規模模型複製出前沿級別的效能。

實務要點

  1. KV‑cache 大小是主要限制因素；準確計算每個請求的 GDN 狀態以估算最大並發量。
  2. 預留足夠的 GPU 記憶體（預設 8% 安全邊際）以應對 CUDA‑graph 估算誤差。
  3. 根據 KV‑cache 餘裕選擇 Decode 拓撲：TP4DP4+EP 可最大化快取空間，而 TEP8 在快取充足時表現優異。
  4. 為 Decode 工作負載啟用 MTP 以提升吞吐量，直到 KV‑cache 飽和為止。
  5. 使用提供的 srt‑slurm 配方 來重現確切環境並在您自己的叢集上驗證結果。

致謝

感謝 Artem Perevedentsev (NVIDIA)、Vadim Gimpelson (NVIDIA)、Xin Li (NVIDIA) 以及更廣大的 vLLM 社群所做的貢獻與審閱。

Sources