vLLM 彈性專家並行 (Elastic Expert Parallelism)

vLLM 彈性專家並行 (Elastic Expert Parallelism)

vLLM 引入了彈性專家並行 (Elastic EP)，允許混合專家模型 (MoE) 部署在運行時擴展或縮減工作節點 (worker) 的數量。這消除了為了調整服務能力而必須重新啟動整個伺服器的需求，減少了需求波動期間的流量下降和維運開銷。

MoE 部署的運行時擴展

Elastic EP 使 vLLM 能夠在運行時重新配置數據並行 (DP) 工作節點的數量。由於專家並行 (EP) 組的大小是 DP 與張量並行 (TP) 的乘積，因此更改 DP 大小可以有效地擴展 EP 組，並將專家重新分配到新的工作節點集中。

操作人員可以透過單次 API 調用觸發調整大小：

curl -X POST http://localhost:8000/scale_elastic_ep \
  -H "Content-Type: application/json" \
  -d '{"new_data_parallel_size": 8}'

技術實現與狀態管理

在運行時擴展 DP 需要更新多個關鍵的運行時狀態以避免失效。vLLM 將擴展過程視為一個具有明確同步點的協調狀態機：

  • 分散式通訊組 (Distributed Communication Groups)： 必須更新 EP、DP 和 world groups 以反映新的 rank 集合。
  • 專家分配 (Expert Assignment)： 根據 EP 大小重新計算專家與特定 rank 的映射關係。
  • 模型權重 (Model Weights)： 新的 rank 必須接收必要的權重，而現有的 rank 可能需要更新的專家權重。
  • 編譯狀態 (Compiled State)： CUDA graphs 和 torch.compile 狀態將被重置並重新預熱 (re-warmed)，以匹配新的拓撲結構。

擴展 (Scale-Up) 工作流程

當從 DP=N 擴展到 DP=M（其中 M > N）時，vLLM 遵循六個階段的流程：

  1. 觸發與請求處理： 流程始於 /scale_elastic_ep。如果啟用了 VLLM_ELASTIC_EP_DRAIN_REQUESTS=1，vLLM 會等待進行中的工作完成（預設超時時間為 120 秒）後再繼續。
  2. 新引擎核心初始化： 使用 Ray DP backend，vLLM 會啟動額外的 DP workers。這些 ranks 使用佔位權重初始化模型並等待重新配置信號。
  3. 備用通訊組 (Standby Communication Groups)： 現有 ranks 使用 StatelessGroupCoordinator 創建備用組。這允許在舊配置繼續執行前向傳播 (forward passes) 的同時，準備新配置。
  4. 專家映射與權重傳輸： 非專家權重（注意力層、歸一化層、嵌入層）透過高速互連（NVLink 或 RDMA）從現有 ranks 廣播到新 ranks。專家權重則延遲到 EPLB 重排階段。
  5. 切換 (The Switch)： vLLM 釋放 CUDA graphs，將備用組提升為活動狀態，銷毀舊組，並重新預熱模型，使編譯路徑與新設置保持一致。
  6. EPLB 重排 (EPLB Reshuffle)： 專家並行負載均衡 (Expert Parallel Load Balancing, EPLB) 將專家重新分配到所有 M 個 ranks，並執行必要的專家權重移動。

縮減 (Scale-Down) 工作流程

從 DP=M 縮減到 DP=N 遵循類似的模式，但 EPLB 重排會先發生。這確保了屬於即將移除的 ranks 的專家，會在這些 ranks 被終止前，被遷移到倖存的 N 個 ranks 中。

透過兩階段屏障 (Two-Stage Barrier) 進行同步

為了防止由非同步 DP 引擎核心引起的死鎖，vLLM 採用了兩階段屏障。第一階段屏障使用超時機制；如果失敗，ranks 會推斷某些同伴仍在執行前向步驟，並返回引擎循環進行一次迭代。一旦所有 ranks 對齊，第二個沒有超時限制的屏障將允許它們共同進入重新配置階段。

對容錯能力的影響

Elastic EP 是 vLLM 容錯策略的基礎組件。透過提供運行時重新配置路徑，vLLM 可以在不重新啟動整個伺服器的情況下從 rank 故障中恢復：

  1. 檢測： 透過健康檢查或 backend 信號識別故障。
  2. 縮減： 移除故障的 rank 並重新分配其專家。
  3. 擴展： 一旦可用，增加替換容量。

NIXL EP 被強調為此流程中特別相關的通訊 backend，因為它可以檢測、報告並從 EP 端的故障中恢復，並透過 connect_ranks() 和 disconnect_ranks() API 增量地添加或移除 ranks。

目前限制與未來工作

雖然 Elastic EP 提供了核心重新配置路徑，但目前的支援僅限於 tensor_parallel_size=1 的 Ray DP 部署、單個 API server 且無 DBO。未來的開發領域包括：

  • 支援 tensor_parallel_size > 1 和更豐富的並行配置。
  • 與更多服務功能整合，包括 DBO 和 MoE draft/drafter 模型。
  • 透過改進重疊 (overlap) 和減少預熱成本來縮短重新配置窗口。
  • 與自動擴展策略連接（例如 Dynamo, llm-d）。
  • 支援 Ray 之外的其他 DP backends。

Sources