優化大型語言模型效能：解決長提示阻塞與解碼延遲問題

TL;DR

長提示在 LLM 服務中會阻塞預填佇列，導致同時請求的 token 生成變慢。為了緩解此問題，請求平行預填可減少短提示的首次 token 時間（TTFT），而分離式預填則將預填與解碼階段分配至不同 GPU，消除相互干擾，穩定延遲。

長提示阻塞的挑戰

在標準 LLM 服務中，預填階段（處理初始提示）計算密集，可能飽和 GPU 使用率；而解碼階段（生成後續 token）計算需求較低。vLLM 使用的預設分塊預填策略會將不同請求的預填區塊依序排程。

當排程到一個提示非常長的請求時，會阻塞預填佇列。任何後續請求必須等到這個長預填完成後才能開始自己的預填階段，從而大幅提升這些請求的首次 token 時間（TTFT）。

請求平行預填

為了解決佇列阻塞，vLLM 實作了一種策略，允許多個請求同時進行平行預填，但對同時處理的長提示數量設有限制（例如允許四個平行預填，但僅允許一個超過 10,000 token）。

  • 對短提示的影響： 短提示現在可以透過「fast lane」繞過長預填，顯著降低其 TTFT。
  • 對長提示的影響： 長提示仍會依序處理，以避免若多個計算密集的預填同時批次執行而導致的系統嚴重緩慢。
  • 限制： 雖然 TTFT 已降低，但每個輸出 token 的時間仍偏高，因為同時的預填仍佔用 GPU 資源，減慢現有請求的解碼步驟。

基本缺陷：預填與解碼的干擾

在同一 GPU 操作中同時執行不同請求的預填與解碼會導致 token 生成變慢。單一長提示的請求就足以降低所有先前排程且正處於解碼階段的請求效能。

緩解策略

  1. 優先權懲罰： 長提示可以被迫等待高優先權或短請求完成。這會增加長提示的延遲，且在長提示實際排程後仍無法解決干擾問題。
  2. 專屬推論伺服器： 將長提示請求導向獨立伺服器。這需要複雜的路由器與額外的 GPU 資源，儘管短上下文伺服器可部署在較少的 GPU 上（例如 Llama-3.3-70B 需要四顆 H100 以支援 130k 上下文，但在 <10k 上下文時僅需兩顆 H100）。
  3. 分離式預填： 為預填與解碼使用分離的推論引擎。此架構包含多個 vLLM 部署，其中一個工作者僅負責預填，另一個僅負責解碼。預填完成後，KV 快取會轉移至解碼工作者。

分離式預填以優化延遲

分離式預填消除因同時預填而直接干擾解碼階段的情況，是穩定 token 生成延遲的最有效策略。

折衷與現況

  • 資源成本： 此方法需要為每個角色部署獨立的完整 vLLM（例如 Llama-3.3-70B 需要八顆 H100：四顆用於預填，四顆用於解碼）。
  • GPU 使用率： 使用率常常不均衡，因為預填比解碼更耗算力。然而，大型叢集可依負載模式調整預填與解碼工作者的比例以取得平衡。
  • 目標： 主要目的是提升「goodput」（符合延遲目標的請求速率），而非總體原始吞吐量。
  • 實驗狀態： 截至 vLLM v0.7.3，此功能仍屬實驗性。現有限制包括較低的上下文長度上限，以及解碼工作者對 CUDA graph 的使用不一致，可能導致解碼速度較整合部署慢。

Sources