vLLM Prefill-Decode 分散式架構與 MORI-IO

vLLM 為單節點部署引入了 Prefill-Decode（PD）分散式架構，使 8 GPU AMD Instinct MI300X 節點的 goodput 提升 2.5 倍。透過將計算受限的 prefill 階段與記憶體頻寬受限的 decode 階段分離，vLLM 消除了這些工作負載在同一 GPU 資源競爭時通常會出現的 Inter-Token Latency（ITL）峰值。

共置服務的瓶頸

在標準的單體部署中，prefill 與 decode 工作負載共用相同的 GPU 資源與排程器。由於 prefill 使用大型 GEMM 並行處理整個提示詞，它受限於計算，耗時遠超單一 decode 步驟。當一個 prefill 請求加入批次時，會阻塞所有正在進行的 decode 流，導致 Inter-Token Latency（ITL）出現不可預測的峰值。

單節點 PD 分散式架構

與普遍認為分散式需要多節點叢集的觀念相反，vLLM 在單一 8 GPU 節點內實現此架構。系統轉為微服務架構，包含三個元件：

• Prefill Instance（Prefill 實例）: 處理輸入提示詞並產生 KV 快取（例如使用 GPU 0–3）。
• Decode Instance（Decode 實例）: 使用已傳輸的 KV 快取產生輸出 token（例如使用 GPU 4–7）。
• Proxy Server（代理伺服器）: 作為入口點，將請求先導向 prefill 實例，再導向 decode 實例。

為了在這些實例之間傳輸數 GB 的 KV 快取資料，vLLM 使用 MORI-IO，這是一個基於 RDMA 的 KV 快取連接器，建構於開源的 MORI（Modular RDMA Interface）框架之上。

KV 快取傳輸模式：讀取 vs. 寫入

MORI-IO 支援兩種不同的傳輸模式，可透過 VLLM_MORIIO_CONNECTOR_READ_MODE 環境變數進行設定：

讀取模式 (VLLM_MORIIO_CONNECTOR_READ_MODE=1)

在讀取模式下，代理會串行分派請求。它會等待 prefill 實例完成並回傳 remote_block_ids 後，才將請求轉發給 decode 實例。decode 實例隨後透過 RDMA 從 prefill 實例的記憶體中拉取 KV 快取。

寫入模式（預設）

在寫入模式下，代理會同時向 prefill 與 decode 實例分派請求。當 prefill 實例計算每一層時，它會透過 RDMA WRITE 直接將 KV 資料寫入 decode 實例預先分配的記憶體。此方式消除了代理的序列化開銷，並使 decode 隊列的等待與 prefill 計算重疊。

Property（屬性）	Read Mode（讀取模式）	Write Mode（寫入模式）
RDMA Direction（RDMA 方向）	Decode 從 prefill 拉取	Prefill 推送至 decode
Proxy Dispatch（代理分派）	Serial (await prefill $\rightarrow$ dispatch decode)（串行（等待 prefill $\rightarrow$ 分派 decode））	Concurrent (prefill and decode in parallel)（同時（prefill 與 decode 並行））
Block ID Relay（Block ID 中繼）	需要透過代理	不需要
KV Cleanup（KV 清理）	Decode 通知 prefill 釋放區塊	Prefill 追蹤寫入完成

效能結果與 Goodput

在 8 GPU MI300X 節點上使用 Qwen3-235B-A22B-FP8 模型（2000 token 提示詞，1000 token 輸出），vLLM 以 goodput 來衡量效能——即在請求同時滿足首 token 時間 (TTFT) < 1 秒且 ITL < 50 毫秒的最大請求率。

主要發現

• 2.5 倍 Goodput 提升： 寫入模式在 8 req/s 的速率下，有 73/100 的請求符合 SLO，遠高於標準 TP8 服務的 26/100。
• 消除 ITL 峰值： 分散式模式完全消除了 ITL 違規，因為 decode 引擎與計算密集的 prefill 工作相互隔離。
• TTFT 折衷： 分散式會因額外的 RDMA 傳輸與代理開銷而提升 TTFT。寫入模式相較於讀取模式提供更佳的 TTFT，因為它消除了代理的序列化。

部署與設定

部署 PD 分散式需要在 vLLM 中設定 kv-transfer-config。兩個實例皆必須指定 MoRIIOConnector 並設定各自的角色（prefill 使用 kv_producer，decode 使用 kv_consumer）。

埠需求

• proxy_ping_port：用於實例向代理註冊的 ZMQ 端點。
• http_port：vLLM HTTP 伺服器的推論請求埠。
• handshake_port：一次性的 KV 快取布局元資料交換埠。
• notify_port：每個請求的同步訊號，指示 KV 區塊已就緒。

使用情境摘要

Situation（情境）	Recommendation（建議）
ITL p99 超過生產負載下的 SLO	分散式
TTFT 為主要限制因素	標準服務
高併發且提示詞較長	分散式
請求率低且提示詞較短	標準服務