揭秘老黃演講中關鍵技術：PD分離！UCSD華人團隊力作，LLM吞吐量躍升4倍

作者：新智元 2025-03-20 09:00:00

人工智能新聞

老黃GTC重點展示的PD分離技術為何成兵家必爭之地？UCSD全華人團隊力作，創新性地提出預填充-解碼分離技術。在嚴格的延遲約束下，相比現有最先進的服務系統，可實現高達4.48倍的有效產出率或10.2倍更嚴格的SLO達成率。

現在，PD分離已經成為兵家必爭之地。

前有Mooncake/DeepSeek等公司采用這種技術來優化大模型的推理服務，后有Nvidia/PyTorch基于該技術孵化下一代LLM服務系統。

甚至最近，黃仁勛也在2025 GTC的舞臺上提到了PD分離（Prefill-Decode Disaggregation）技術，進一步證明了這一技術獲得的廣泛關注。

去年，來自UCSD的一個華人團隊發布的一篇博客，就深入剖析了這一技術的原理和它的應用場景。

博客地址：https://hao-ai-lab.github.io/blogs/distserve/

如今，大語言模型應用有著不同的延遲需求。

例如，聊天機器人需要快速響應（比如低于0.2秒），而解碼速度可以較為適中，僅需與人類閱讀速度相匹配；代碼補全則要求快速生成，以便實時提供代碼建議。

文章中展示了現有的優化吞吐量的服務系統，在延遲標準下并不理想。

作者提議使用「有效吞吐量」（goodput）作為大模型服務性能的改進衡量標準，它不僅關注每秒完成請求的數量，而且符合服務級目標（SLO），更好地平衡成本和用戶體驗。

為了提升有效吞吐量，文章提出了「預填充-解碼分離」（prefill-decode disaggregation），即將預填充和解碼分配到不同的GPU上。

通過這個方法，作者搭建了一個系統原型DistServe，在保持嚴格的延遲約束下，達到了比現有系統高出4.48倍的有效吞吐量，或者10.2倍更嚴格的SLO。

一個請求通過一個具有分離預填充和解碼的LLM服務引擎

吞吐量與有效吞吐量

LLM正在改變行業對AI的應用，但LLM服務成本仍然很高。

為了降低成本，很多公司專注于提升LLM系統的吞吐量，即每秒處理的請求數（rps），作為每個請求成本（$/req）的替代指標。

大多數流行的LLM服務引擎，如vLLM和TensorRT-LLM，都用吞吐量來衡量性能。

然而，實際應用對延遲的要求各不相同，因此服務級目標（SLO）也不同。常見的SLO包括：

首次token延遲（TTFT）：測量LLM生成第一個token的時間
每個輸出token的時間（TPOT）：測量兩個連續生成的token之間的平均延遲

應用程序有著多樣的SLO要求

吞吐量只關注處理的請求或token數，卻忽視了這些延遲需求。作者引入了有效吞吐量（goodput），它衡量每秒完成的符合SLO的請求數（同時滿足TTFT和TPOT要求）。這比吞吐量更能反映服務質量，因為它考慮了成本和用戶體驗。

那么，到底什么是有效吞吐量？假設一個應用要求90%的請求TTFT小于200毫秒，TPOT小于50毫秒，那么有效吞吐量就是每秒能完成的最大請求數，且至少90%的請求同時滿足這兩個條件。

一個高吞吐量的應用可能有低的有效吞吐量。雖然吞吐量是10個請求每秒，但因為延遲約束，只有3個請求符合SLO，最終的有效吞吐量只有每秒3個請求。可以想象，盡管這種系統的吞吐量很高，但它的用戶服務將很差。

高吞吐量≠高有效吞吐量

以下是在本小節中引入的術語：

有效吞吐量：衡量LLM服務系統效能的指標，考慮了成本和用戶滿意度。它定義為每秒系統可以完成的請求數量，同時滿足指定的服務級目標（SLO）。
吞吐量：LLM服務系統每秒處理的已完成請求數量。
服務級目標（SLO）：LLM服務系統必須滿足的目標，以提供令人滿意的用戶體驗。常見的SLO包括首次token延遲（TTFT）、每個輸出token時間（TPOT）、端到端延遲（E2E）和指數加權平均（EMA）延遲。
預填充：LLM推理的第一階段，處理所有輸入token，填充KV緩存，并生成第一個輸出token。
解碼：隨后的階段，通過自回歸方式生成token，直到完成。
首次token延遲（TTFT）：LLM服務系統響應用戶請求時，生成第一個token所需的時間。
每個輸出token的時間（TPOT）：LLM服務系統響應用戶請求時，生成后續token所需的平均時間。

為什么現有系統無法實現高有效吞吐量？

在深入分析之前，需要回顧一下LLM服務請求的流程。

下圖展示了這個過程：請求進入LLM推理引擎，系統首先處理用戶輸入生成的第一個token（預填充），然后通過自回歸生成后續token（解碼）。一個請求通常包括一個預填充步驟和多個解碼步驟，直到生成完成。

傳統LLM服務系統中請求的處理過程

LLM服務系統通常將預填充和解碼一起批處理，使用迭代調度或連續批處理技術，使GPU能盡量大批量處理，從而提高吞吐量（每秒token數），vLLM和TensorRT-LLM等系統都廣泛采用這一方法。

然而，預填充和解碼在計算上有非常不同的特點。

預填充非常依賴計算，意味著即使是一個小批量的預填充，或者僅僅是一個足夠長的預填充，也會迅速飽和GPU計算資源。

另一方面，解碼需要更大的批量來達到計算瓶頸，且更容易受到GPU內存帶寬限制的影響。

不過，預填充和解碼在計算上差異很大：預填充計算密集型，容易迅速飽和GPU；而解碼則需要更大批量才能達到計算瓶頸，同時也更受GPU內存帶寬的限制。

由于它們的計算模式和SLO目標差異巨大，將這兩者一起處理并不有利于優化有效吞吐量，原因有二：

預填充和解碼之間會互相干擾，導致性能下降
預填充和解碼的資源分配及并行策略會相互耦合，難以優化

預填充和解碼的干擾

下圖展示了預填充和解碼之間的干擾。

左：把兩個請求批量到一個GPU，結果看到解碼（R1）延遲顯著增加，預填充（R2）延遲稍微上升。
右：穩定請求流中，每次解碼遇到預填充請求時就會被「卡住」，解碼延遲因此意外增加。

連續批處理導致的干擾

這種干擾導致下圖中展示的情況：為了滿足TTFT和TPOT的SLO，系統必須過度配置資源以滿足延遲目標，尤其當某個SLO特別嚴格時。

為了滿足SLO，預填充和解碼共同處理的系統需要過度配置資源

此外，預填充和解碼的資源分配和并行策略是耦合的。由于計算模式和延遲目標不同，最優的并行策略也不一樣。

比如，當TTFT要求嚴格時，預填充階段適合用張量并行（TP）來滿足緊湊的延遲目標，而解碼則更傾向于數據并行或流水線并行來提升吞吐量。

分離預填充和解碼

直覺很簡單：將預填充（Prefill）和解碼（Decode）分配到不同的GPU，并為每個階段定制并行策略。

這自然解決了上面提到的兩個問題：

預填充和解碼之間沒有干擾，使得兩個階段都可以更快完成，并更容易滿足各自的SLO（服務水平目標）
資源分配和并行策略解耦，優化可以針對預填充和解碼分別進行

下圖展示了在這種分離系統中請求的處理方式。

預填充/解碼分離時請求的處理過程

當請求到達系統時：

首先進入預填充工作節點并完成預填充階段
然后，系統將其中間狀態（主要是KV緩存）遷移到解碼工作節點，并進行多個解碼步驟以生成后續token
請求在生成完成后離開系統

通過一個簡單的實驗，即可驗證Prefill-Decode分離的效果。

在單個A100-80GB GPU上運行一個13B的LLM，使用一個輸入長度為512、輸出長度為64的合成工作負載，并假設請求按泊松分布到達。

逐漸增加請求速率（x軸），并測量這兩種延遲（P90 TTFT和P90 TPOT，y軸）中的變化。

假設將SLO設置為P90 TTFT小于0.4秒，P90 TPOT小于0.04秒，作者觀察到，現有系統使用1個GPU時，大約支持3個rps（Request rate per second），而TPOT則支持1.6個rps。

由于需要同時滿足這兩個約束，現有共同處理系統的有效吞吐量為：有效吞吐量（同時滿足） = min(3, 1.6) = 1.6 rps（每個GPU）。

共同處理（a）相較于分離（b），后者在為預填充分配2個GPU、為解碼分配1個GPU（2P1D）時更具靈活性

分離后，性能顯著提升。

預填充工作節點和解碼工作節點在僅處理單個階段時，可以分別達到比之前更好的rps——預填充工作節點大約可以達到5.6 rps，解碼工作節點大約可以達到10 rps。

更重要的是，現在我們可以靈活地分配2個預填充工作節點與1個解碼工作節點（記作2P1D），總共使用3個GPU。此時的有效吞吐量變為：

有效吞吐量（2P1D） = min(5.6 x 2, 10) = 10 reqs/s / 3 GPUs ≈ 3.3 reqs/s（平均每個GPU）。

這個實驗表明，簡單的分離方法在沒有任何并行化的情況下就能實現2倍的有效吞吐量（3.3rps VS 1.6rps）。

額外的好處是，預填充與解碼的分離還能夠為每個階段選擇最佳的并行策略來優化有效吞吐量（作者稱之為「定制并行tailored parallelism」）。

KV緩存傳輸

分離的一個代價是需要在預填充和解碼GPU之間傳輸中間狀態（即KV緩存）。

乍一看，KV緩存是LLM推理中一個大的內存開銷，而在GPU之間傳輸KV緩存似乎是一個瓶頸。

但相反，通過合理的放置，KV緩存傳輸的開銷可以被有效地最小化，低至小于一個解碼步驟的時間，這得益于今天高速的網絡技術，如NVLink和PCI-e 5.0。

為了驗證這一點，假設有8通道PCIe 5.0 x 16（每個鏈路64GB/s）作為GPU之間的節點內網絡。

給定一個2048token的請求，可以估算在服務OPT-175B（OPT，即Open Pre-trained Transformer由Meta AI開發）時，傳輸KV緩存的延遲為：

延遲 = 2048token *（4.5 MB/token）/（64GB/s * 8） = 17.6毫秒

這個延遲小于OPT-175B的單個解碼步驟的時間（約30-50毫秒，使用A100）。

對于更大的模型、更長的序列或更先進的網絡（例如，具有600GB/s帶寬的A100-NVLink），如下圖所示，KV緩存傳輸的比較開銷與單個解碼步驟相比變得更加微不足道。

KV緩存傳輸開銷可以被有效最小化，低于一個解碼步驟的時間

精心放置預填充和解碼工作節點以利用高帶寬網絡，可以有效地隱藏KV緩存傳輸的開銷。

DistServe：評估分離的效果

作者在一個名為DistServe的系統原型中實現了所提出的技術，并在三個具有不同延遲約束的工作負載和數據集上與現有系統進行了比較：聊天機器人、代碼補全和摘要，詳細信息見下表。

下圖展示了DistServe與vLLM的對比結果：

在各種數據集上評估DistServe與vLLM的表現

聊天機器人：DistServe的有效吞吐量比vLLM高2.0倍到3.41倍。
代碼補全：DistServe的有效吞吐量比vLLM高3.2倍，并且SLO比vLLM嚴格1.5倍。作為實時編碼助手，代碼補全任務比聊天機器人要求更低的TTFT，這使得兩個系統最終都受到TTFT要求的限制。然而，通過消除解碼任務的干擾，并為預填充定制張量并行策略，DistServe減少了預填充任務的平均延遲，從而滿足更多請求的TTFT要求。
摘要：DistServe的有效吞吐量比vLLM高4.48倍，并且SLO比vLLM嚴格10.2倍。如預期的那樣，由于vLLM將預填充和解碼放在一起，它在解碼階段的減速更大，未能滿足TPOT要求。