首頁(yè) > 科技要聞 > 科技> 正文

揭秘老黃演講中關(guān)鍵技術(shù)：PD分離！UCSD華人團(tuán)隊(duì)力作，LLM吞吐量躍升4倍

新智元 整合編輯：太平洋科技 發(fā)布于：2025-03-20 16:36

現(xiàn)在，PD分離已經(jīng)成為兵家必爭(zhēng)之地。

前有Mooncake/DeepSeek等公司采用這種技術(shù)來(lái)優(yōu)化大模型的推理服務(wù)，后有Nvidia/PyTorch基于該技術(shù)孵化下一代LLM服務(wù)系統(tǒng)。

甚至最近，黃仁勛也在2025 GTC的舞臺(tái)上提到了PD分離（Prefill-Decode Disaggregation）技術(shù)，進(jìn)一步證明了這一技術(shù)獲得的廣泛關(guān)注。

去年，來(lái)自UCSD的一個(gè)華人團(tuán)隊(duì)發(fā)布的一篇博客，就深入剖析了這一技術(shù)的原理和它的應(yīng)用場(chǎng)景。

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

如今，大語(yǔ)言模型應(yīng)用有著不同的延遲需求。

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

文章中展示了現(xiàn)有的優(yōu)化吞吐量的服務(wù)系統(tǒng)，在延遲標(biāo)準(zhǔn)下并不理想。

作者提議使用「有效吞吐量」（goodput）作為大模型服務(wù)性能的改進(jìn)衡量標(biāo)準(zhǔn)，它不僅關(guān)注每秒完成請(qǐng)求的數(shù)量，而且符合服務(wù)級(jí)目標(biāo)（SLO），更好地平衡成本和用戶(hù)體驗(yàn)。

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

通過(guò)這個(gè)方法，作者搭建了一個(gè)系統(tǒng)原型DistServe，在保持嚴(yán)格的延遲約束下，達(dá)到了比現(xiàn)有系統(tǒng)高出4.48倍的有效吞吐量，或者10.2倍更嚴(yán)格的SLO。

一個(gè)請(qǐng)求通過(guò)一個(gè)具有分離預(yù)填充和解碼的LLM服務(wù)引擎

吞吐量與有效吞吐量

LLM正在改變行業(yè)對(duì)AI的應(yīng)用，但LLM服務(wù)成本仍然很高。

為了降低成本，很多公司專(zhuān)注于提升LLM系統(tǒng)的吞吐量，即每秒處理的請(qǐng)求數(shù)（rps），作為每個(gè)請(qǐng)求成本（$/req）的替代指標(biāo)。

大多數(shù)流行的LLM服務(wù)引擎，如vLLM和TensorRT-LLM，都用吞吐量來(lái)衡量性能。

然而，實(shí)際應(yīng)用對(duì)延遲的要求各不相同，因此服務(wù)級(jí)目標(biāo)（SLO）也不同。常見(jiàn)的SLO包括：

首次token延遲（TTFT）：測(cè)量LLM生成第一個(gè)token的時(shí)間

每個(gè)輸出token的時(shí)間（TPOT）：測(cè)量?jī)蓚�(gè)連續(xù)生成的token之間的平均延遲

應(yīng)用程序有著多樣的SLO要求

吞吐量只關(guān)注處理的請(qǐng)求或token數(shù)，卻忽視了這些延遲需求。作者引入了有效吞吐量（goodput），它衡量每秒完成的符合SLO的請(qǐng)求數(shù)（同時(shí)滿(mǎn)足TTFT和TPOT要求）。這比吞吐量更能反映服務(wù)質(zhì)量，因?yàn)樗紤]了成本和用戶(hù)體驗(yàn)。

那么，到底什么是有效吞吐量？假設(shè)一個(gè)應(yīng)用要求90%的請(qǐng)求TTFT小于200毫秒，TPOT小于50毫秒，那么有效吞吐量就是每秒能完成的最大請(qǐng)求數(shù)，且至少90%的請(qǐng)求同時(shí)滿(mǎn)足這兩個(gè)條件。

一個(gè)高吞吐量的應(yīng)用可能有低的有效吞吐量。雖然吞吐量是10個(gè)請(qǐng)求每秒，但因?yàn)檠舆t約束，只有3個(gè)請(qǐng)求符合SLO，最終的有效吞吐量只有每秒3個(gè)請(qǐng)求�？梢韵胂螅M管這種系統(tǒng)的吞吐量很高，但它的用戶(hù)服務(wù)將很差。

高吞吐量≠高有效吞吐量

以下是在本小節(jié)中引入的術(shù)語(yǔ)：

有效吞吐量：衡量LLM服務(wù)系統(tǒng)效能的指標(biāo)，考慮了成本和用戶(hù)滿(mǎn)意度。它定義為每秒系統(tǒng)可以完成的請(qǐng)求數(shù)量，同時(shí)滿(mǎn)足指定的服務(wù)級(jí)目標(biāo)（SLO）。

吞吐量：LLM服務(wù)系統(tǒng)每秒處理的已完成請(qǐng)求數(shù)量。

服務(wù)級(jí)目標(biāo)（SLO）：LLM服務(wù)系統(tǒng)必須滿(mǎn)足的目標(biāo)，以提供令人滿(mǎn)意的用戶(hù)體驗(yàn)。常見(jiàn)的SLO包括首次token延遲（TTFT）、每個(gè)輸出token時(shí)間（TPOT）、端到端延遲（E2E）和指數(shù)加權(quán)平均（EMA）延遲。

預(yù)填充：LLM推理的第一階段，處理所有輸入token，填充KV緩存，并生成第一個(gè)輸出token。

解碼：隨后的階段，通過(guò)自回歸方式生成token，直到完成。

首次token延遲（TTFT）：LLM服務(wù)系統(tǒng)響應(yīng)用戶(hù)請(qǐng)求時(shí)，生成第一個(gè)token所需的時(shí)間。

每個(gè)輸出token的時(shí)間（TPOT）：LLM服務(wù)系統(tǒng)響應(yīng)用戶(hù)請(qǐng)求時(shí)，生成后續(xù)token所需的平均時(shí)間。

為什么現(xiàn)有系統(tǒng)無(wú)法實(shí)現(xiàn)高有效吞吐量？

在深入分析之前，需要回顧一下LLM服務(wù)請(qǐng)求的流程。

下圖展示了這個(gè)過(guò)程：請(qǐng)求進(jìn)入LLM推理引擎，系統(tǒng)首先處理用戶(hù)輸入生成的第一個(gè)token（預(yù)填充），然后通過(guò)自回歸生成后續(xù)token（解碼）。一個(gè)請(qǐng)求通常包括一個(gè)預(yù)填充步驟和多個(gè)解碼步驟，直到生成完成。

傳統(tǒng)LLM服務(wù)系統(tǒng)中請(qǐng)求的處理過(guò)程

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

然而，預(yù)填充和解碼在計(jì)算上有非常不同的特點(diǎn)。

預(yù)填充非常依賴(lài)計(jì)算，意味著即使是一個(gè)小批量的預(yù)填充，或者僅僅是一個(gè)足夠長(zhǎng)的預(yù)填充，也會(huì)迅速飽和GPU計(jì)算資源。

另一方面，解碼需要更大的批量來(lái)達(dá)到計(jì)算瓶頸，且更容易受到GPU內(nèi)存帶寬限制的影響。

不過(guò)，預(yù)填充和解碼在計(jì)算上差異很大：預(yù)填充計(jì)算密集型，容易迅速飽和GPU；而解碼則需要更大批量才能達(dá)到計(jì)算瓶頸，同時(shí)也更受GPU內(nèi)存帶寬的限制。

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

預(yù)填充和解碼之間會(huì)互相干擾，導(dǎo)致性能下降

預(yù)填充和解碼的資源分配及并行策略會(huì)相互耦合，難以?xún)?yōu)化

預(yù)填充和解碼的干擾

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

左：把兩個(gè)請(qǐng)求批量到一個(gè)GPU，結(jié)果看到解碼（R1）延遲顯著增加，預(yù)填充（R2）延遲稍微上升。

右：穩(wěn)定請(qǐng)求流中，每次解碼遇到預(yù)填充請(qǐng)求時(shí)就會(huì)被「卡住」，解碼延遲因此意外增加。

連續(xù)批處理導(dǎo)致的干擾

這種干擾導(dǎo)致下圖中展示的情況：為了滿(mǎn)足TTFT和TPOT的SLO，系統(tǒng)必須過(guò)度配置資源以滿(mǎn)足延遲目標(biāo)，尤其當(dāng)某個(gè)SLO特別嚴(yán)格時(shí)。

為了滿(mǎn)足SLO，預(yù)填充和解碼共同處理的系統(tǒng)需要過(guò)度配置資源

此外，預(yù)填充和解碼的資源分配和并行策略是耦合的。由于計(jì)算模式和延遲目標(biāo)不同，最優(yōu)的并行策略也不一樣。

比如，當(dāng)TTFT要求嚴(yán)格時(shí)，預(yù)填充階段適合用張量并行（TP）來(lái)滿(mǎn)足緊湊的延遲目標(biāo)，而解碼則更傾向于數(shù)據(jù)并行或流水線(xiàn)并行來(lái)提升吞吐量。

分離預(yù)填充和解碼

直覺(jué)很簡(jiǎn)單：將預(yù)填充（Prefill）和解碼（Decode）分配到不同的GPU，并為每個(gè)階段定制并行策略。

這自然解決了上面提到的兩個(gè)問(wèn)題：

預(yù)填充和解碼之間沒(méi)有干擾，使得兩個(gè)階段都可以更快完成，并更容易滿(mǎn)足各自的SLO（服務(wù)水平目標(biāo)）

資源分配和并行策略解耦，優(yōu)化可以針對(duì)預(yù)填充和解碼分別進(jìn)行

下圖展示了在這種分離系統(tǒng)中請(qǐng)求的處理方式。

預(yù)填充/解碼分離時(shí)請(qǐng)求的處理過(guò)程

當(dāng)請(qǐng)求到達(dá)系統(tǒng)時(shí)：

首先進(jìn)入預(yù)填充工作節(jié)點(diǎn)并完成預(yù)填充階段

然后，系統(tǒng)將其中間狀態(tài)（主要是KV緩存）遷移到解碼工作節(jié)點(diǎn)，并進(jìn)行多個(gè)解碼步驟以生成后續(xù)token

請(qǐng)求在生成完成后離開(kāi)系統(tǒng)

通過(guò)一個(gè)簡(jiǎn)單的實(shí)驗(yàn)，即可驗(yàn)證Prefill-Decode分離的效果。

在單個(gè)A100-80GB GPU上運(yùn)行一個(gè)13B的LLM，使用一個(gè)輸入長(zhǎng)度為512、輸出長(zhǎng)度為64的合成工作負(fù)載，并假設(shè)請(qǐng)求按泊松分布到達(dá)。

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

假設(shè)將SLO設(shè)置為P90 TTFT小于0.4秒，P90 TPOT小于0.04秒，作者觀察到，現(xiàn)有系統(tǒng)使用1個(gè)GPU時(shí)，大約支持3個(gè)rps（Request rate per second），而TPOT則支持1.6個(gè)rps。

由于需要同時(shí)滿(mǎn)足這兩個(gè)約束，現(xiàn)有共同處理系統(tǒng)的有效吞吐量為：有效吞吐量（同時(shí)滿(mǎn)足） = min(3, 1.6) = 1.6 rps（每個(gè)GPU）。

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

分離后，性能顯著提升。

預(yù)填充工作節(jié)點(diǎn)和解碼工作節(jié)點(diǎn)在僅處理單個(gè)階段時(shí)，可以分別達(dá)到比之前更好的rps——預(yù)填充工作節(jié)點(diǎn)大約可以達(dá)到5.6 rps，解碼工作節(jié)點(diǎn)大約可以達(dá)到10 rps。

更重要的是，現(xiàn)在我們可以靈活地分配2個(gè)預(yù)填充工作節(jié)點(diǎn)與1個(gè)解碼工作節(jié)點(diǎn)（記作2P1D），總共使用3個(gè)GPU。此時(shí)的有效吞吐量變?yōu)椋?/span>

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

這個(gè)實(shí)驗(yàn)表明，簡(jiǎn)單的分離方法在沒(méi)有任何并行化的情況下就能實(shí)現(xiàn)2倍的有效吞吐量（3.3rps VS 1.6rps）。

額外的好處是，預(yù)填充與解碼的分離還能夠?yàn)槊總�(gè)階段選擇最佳的并行策略來(lái)優(yōu)化有效吞吐量（作者稱(chēng)之為「定制并行tailored parallelism」）。

KV緩存?zhèn)鬏?/strong>

分離的一個(gè)代價(jià)是需要在預(yù)填充和解碼GPU之間傳輸中間狀態(tài)（即KV緩存）。

乍一看，KV緩存是LLM推理中一個(gè)大的內(nèi)存開(kāi)銷(xiāo)，而在GPU之間傳輸KV緩存似乎是一個(gè)瓶頸。

但相反，通過(guò)合理的放置，KV緩存?zhèn)鬏數(shù)拈_(kāi)銷(xiāo)可以被有效地最小化，低至小于一個(gè)解碼步驟的時(shí)間，這得益于今天高速的網(wǎng)絡(luò)技術(shù)，如NVLink和PCI-e 5.0。

為了驗(yàn)證這一點(diǎn)，假設(shè)有8通道PCIe 5.0 x 16（每個(gè)鏈路64GB/s）作為GPU之間的節(jié)點(diǎn)內(nèi)網(wǎng)絡(luò)。

給定一個(gè)2048token的請(qǐng)求，可以估算在服務(wù)OPT-175B（OPT，即Open Pre-trained Transformer由Meta AI開(kāi)發(fā)）時(shí)，傳輸KV緩存的延遲為：

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

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

對(duì)于更大的模型、更長(zhǎng)的序列或更先進(jìn)的網(wǎng)絡(luò)（例如，具有600GB/s帶寬的A100-NVLink），如下圖所示，KV緩存?zhèn)鬏數(shù)谋容^開(kāi)銷(xiāo)與單個(gè)解碼步驟相比變得更加微不足道。

KV緩存?zhèn)鬏旈_(kāi)銷(xiāo)可以被有效最小化，低于一個(gè)解碼步驟的時(shí)間

精心放置預(yù)填充和解碼工作節(jié)點(diǎn)以利用高帶寬網(wǎng)絡(luò)，可以有效地隱藏KV緩存?zhèn)鬏數(shù)拈_(kāi)銷(xiāo)。

DistServe：評(píng)估分離的效果

作者在一個(gè)名為DistServe的系統(tǒng)原型中實(shí)現(xiàn)了所提出的技術(shù)，并在三個(gè)具有不同延遲約束的工作負(fù)載和數(shù)據(jù)集上與現(xiàn)有系統(tǒng)進(jìn)行了比較：聊天機(jī)器人、代碼補(bǔ)全和摘要，詳細(xì)信息見(jiàn)下表。

下圖展示了DistServe與vLLM的對(duì)比結(jié)果：

在各種數(shù)據(jù)集上評(píng)估DistServe與vLLM的表現(xiàn)

聊天機(jī)器人：DistServe的有效吞吐量比vLLM高2.0倍到3.41倍。

代碼補(bǔ)全：DistServe的有效吞吐量比vLLM高3.2倍，并且SLO比vLLM嚴(yán)格1.5倍。作為實(shí)時(shí)編碼助手，代碼補(bǔ)全任務(wù)比聊天機(jī)器人要求更低的TTFT，這使得兩個(gè)系統(tǒng)最終都受到TTFT要求的限制。然而，通過(guò)消除解碼任務(wù)的干擾，并為預(yù)填充定制張量并行策略，DistServe減少了預(yù)填充任務(wù)的平均延遲，從而滿(mǎn)足更多請(qǐng)求的TTFT要求。

摘要：DistServe的有效吞吐量比vLLM高4.48倍，并且SLO比vLLM嚴(yán)格10.2倍。如預(yù)期的那樣，由于vLLM將預(yù)填充和解碼放在一起，它在解碼階段的減速更大，未能滿(mǎn)足TPOT要求。

團(tuán)隊(duì)成員介紹

以上研究出自加州大學(xué)圣地亞哥分校的Hao AI實(shí)驗(yàn)室，全部來(lái)自于華人研究者。

Junda Chen

2023年秋季入學(xué)的計(jì)算機(jī)科學(xué)博士生。研究興趣：高效的LLM服務(wù)系統(tǒng)、推理系統(tǒng)和算法。

Yinmin Zhong

北京大學(xué)計(jì)算機(jī)系統(tǒng)研究組的一名三年級(jí)博士生，導(dǎo)師是金鑫。在此之前，在北京大學(xué)獲得了計(jì)算機(jī)科學(xué)學(xué)士學(xué)位。對(duì)構(gòu)建高效的系統(tǒng)來(lái)訓(xùn)練和提供深度學(xué)習(xí)模型有廣泛的興趣，目前主要關(guān)注大語(yǔ)言模型。

Hao Zhang

加州大學(xué)圣地亞哥分校計(jì)算機(jī)科學(xué)與工程系的助理教授。在UCSD領(lǐng)導(dǎo)Hao AI實(shí)驗(yàn)室，對(duì)設(shè)計(jì)強(qiáng)大、高效和安全的機(jī)器學(xué)習(xí)模型和算法，以及構(gòu)建可擴(kuò)展、實(shí)用的分布式系統(tǒng)以支持現(xiàn)實(shí)世界的機(jī)器學(xué)習(xí)工作負(fù)載感興趣。

本文來(lái)源：新智元

網(wǎng)友評(píng)論

聚超值•精選

推薦 手機(jī) 筆記本 影像 硬件 家居 商用 企業(yè) 出行 未來(lái)
    • 二維碼 回到頂部