1分離式架構
1.1?DistServe
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving 講的是一個將prefill和decoding分離的實現。
論文地址： https://arxiv.org/pdf/2401.09670
代碼實現： https://github.com/LLMServe/DistServe
DistServe通過分離預填充和解碼計算來提高大型語言模型（LLM）的性能。現有的LLM服務系統將這兩個階段放在一起，并批量處理所有用戶和請求的預填充和解碼計算。我們發現，這種策略不僅會導致強烈的預填充-解碼干擾，還會將兩個階段的資源分配和并行計劃耦合在一起。LLM應用程序通常強調每個階段的個體延遲：預填充階段的首個token時間（TTFT）和解碼階段每個請求的每個輸出token時間（TPOT）。在嚴格的延遲要求下，現有系統必須優先考慮一個延遲，或者過度配置計算資源以同時滿足兩者。DistServe將預填充和解碼計算分配給不同的GPU，從而消除了預填充-解碼干擾。根據應用程序的TTFT和TPOT要求，DistServe為每個階段定制了資源分配和并行策略的共同優化策略。DistServe還根據服務集群的帶寬將這兩個階段放置在一起，以最小化由分解引起的通信。結果，DistServe在每個GPU上在TTFT和TPOT約束下提高了LLM服務性能的最大速率。我們的評估結果顯示，在各種流行的LLM、應用程序和延遲要求上，與現有技術系統相比，DistServe可以提供7.4倍的請求量或12.6倍的更嚴格的SLO(Service Level Objective)，并且仍然在90%以上的請求中滿足延遲約束。
一個有效的LLM服務系統應該平衡這些需求，并最大化每個GPU的吞吐量，即在滿足SLO達成目標（例如90%）的前提下可以提供的最大請求速率-更高的每個GPU吞吐量直接轉化為更低的每個查詢成本。由于預填充和解碼階段共享LLM權重和工作內存，現有的LLM服務系統通常將這兩個階段放在一起并通過批量處理預填充和解碼步驟來最大化整個系統的吞吐量-跨所有用戶和請求生成的token數每秒。然而，為了滿足延遲要求，我們發現這些系統必須過度配置計算資源。為了看到這一點，圖1說明了在使用現有系統[27]為13B LLM提供服務時，隨著請求率的增加，P90 TTFT和TPOT如何變化，其中工作負載模式和兩個延遲約束設置以模擬使用LLM為文章生成簡短摘要。在滿足90%的SLO達成率的情況下，單個A100 GPU的最大可實現吞吐量，受到TTFT和TPOT要求中較嚴格要求的限制，約為1.6個請求每秒（rps）。當每個階段在不同的GPU上獨立進行時，性能有顯著差異，如橙色和綠色曲線所示，預填充階段的每個GPU吞吐量為5.6 rps，解碼階段為10 rps。理想情況下，通過為預填充分配2個GPU和解碼分配1個GPU，我們可以有效地提供模型的總體吞吐量為10 rps，或者每個GPU平均為3.3 rps，比現有系統高2.1倍。吞吐量差距主要源于預填充和解碼的共同放置-兩個具有非常不同計算特征和延遲要求的階段。
?
也就是說在實現相同的TTFT的要求下，一個GPU單獨prefill的情況下可以實現每秒5.6 個請求，而prefilling和decode都在一個GPU的llm 系統，只能達到1.6個rps.
在實現相同的TPOT的要求下，一個GPU單獨decode的情況下可以實現每秒10 個請求，而prefilling和decode都在一個GPU的llm 系統，只能達到1.6個rps.
-
首先，放置在一起會導致強烈的預填充-解碼干擾。預填充步驟通常比解碼步驟花費更長的時間。當批量處理在一起時，批處理中的解碼步驟會被預填充步驟延遲，顯著延長其TPOT；同樣，解碼步驟的包含導致TTFT的顯著增加，如圖2所示。即使我們將它們分別安排，問題仍然存在，因為它們開始競爭資源。等待GPU執行的解碼任務由于正在進行的預填充任務而增加了排隊延遲，反之亦然。優先安排一個階段可能會導致無法滿足另一個階段的延遲。
2.? 預填充和解碼計算在延遲要求和對不同形式并行性的偏好上有所不同。然而，放置預填充和解碼，會耦合它們的資源分配，并阻止實現更適合滿足每個階段特定延遲要求的不同并行性策略。
通過將LLM推理的預填充和解碼階段分離，將它們分配給不同的GPU。我們的方法有兩個好處。
-
首先，將每個階段獨立地在不同的GPU上運行可以消除預填充-解碼干擾。
-
其次，它允許根據各自的延遲要求，通過量身定制的資源分配和模型并行性策略，獨立地擴展每個階段。雖然分解會導致在GPU之間通信中間狀態，但我們展示了在現代GPU集群中，適當管理時，通信開銷是微不足道的，并且分解顯著提高了每個GPU的吞吐量。
作者構建了DistServe，一個通過分離預填充和解碼階段來優化吞吐量的LLM服務系統。給定TTFT和TPOT要求:
-
DistServe首先通過共同優化預填充和解碼階段的GPU分配和并行性策略，假設只提供單個模型副本，來獨立地擴展每個階段。這種優化確保最大化每個GPU的吞吐量，并根據各自的延遲要求可能為每個階段分配不同數量的GPU和并行性策略。
-
DistServe通過復制將此分配擴展到多個實例，直到滿足用戶所需的流量率。
-
DistServe還具有一種算法，根據其分配方案和集群的帶寬，將預填充和解碼計算放置在一起，以最小化階段之間通信的開銷。
-
DistServe實現為LLM推理引擎的編排層。我們使用各種LLM對DistServe進行評估，根據三個重要的現實世界LLM應用程序調整工作負載：聊天機器人、編程助手和文檔摘要。與現有解決方案相比，DistServe在延遲約束下可以提供高達4.48倍的請求量。
-
使用術語"實例"來表示管理完整模型權重副本的資源單元。當應用模型并行性時，一個實例可以對應多個GPU。需要注意的是，當我們將兩個階段分離到不同的GPU上時，每個階段管理其自己的模型權重副本，從而產生prefilling實例和decode實例。prefilling實例在接收到請求后，僅執行該請求的prefilling計算以生成第一個輸出令牌。然后，它將中間結果（主要是KV緩存）發送到decode實例，decode實例負責后續的解碼步驟。由于decode計算通常具有較低的GPU利用率，我們可以為decode實例分配多個prefilling實例。這樣可以批處理更多的解碼作業，以實現更高的GPU利用率。分離預填充和解碼自然地解決了兩個階段之間的干擾，并使每個階段都能專注于其優化目標 - TTFT或TPOT。
調度策略：
DistServe的運行時架構如上圖所示。DistServe采用簡單的FCFS調度策略運行。所有傳入的請求都到達一個集中式控制器，然后根據prefilling處理隊列的最短的原則，分派到相應的prefilling實例進行處理，然后再分派到最負載最輕的解碼實例進行解碼。盡管這種設置簡單，但是它經過了幾個關鍵的增強，以適應現實世界工作負載的特點。
?
?
