vLLM 團隊今日（10 月 19 日）發表技術博客，解釋點樣透過非同步預備（asynchronous preparation）同 NIXL EP 將彈性地專家並行（Elastic Expert Parallelism，Elastic EP）部署嘅 GPU 擴縮停機時間，由重啟方式嘅 197 秒大幅壓縮至 0.82 秒，實現近零停機。
之前點做嘅，點解要咁做
傳統嚟講，想改 vLLM 服務用嘅 GPU 數量，要么加減成個模型副本，要么成個引擎重啟。模型越大，每個副本要嘅 GPU 越多，重啟代價就越高。vLLM 團隊嘅測試顯示，將 DeepSeek V4 Pro 由 16 張 GB200 擴到 20 張，重啟方式會令服務中斷 197 秒，呢段時間成批 GPU 喺度佔住資源但冇產生 token。
之前嘅第一版 Elastic EP 已經做到唔使重啟，但過程中仍要初始化新 worker、準備擴展咗嘅通訊組、載入模型權重、再跑 kernel warmup 同 CUDA graph capture。同一基準下，16 擴 20 張停 100 秒，縮返 16 張停 56 秒。
呢次改咗乜
今次嘅核心改動係將重構流程拆成「背景預備」同「短暫提交」兩階段。
現有 worker 會開獨立嘅 background thread，喺背景做四樣嘢：
- 初始化新 worker：啟動新加入嘅 GPU 嘅 process，分配模型同執行所需嘅記憶體。
- 準備通訊：建立目標通訊組，擴展 EP communicator。
- 傳輸模型權重：透過 NVLink 或者 RDMA，將所需權重由現有 worker 傳到新增 worker。
- 準備執行：喺新 worker 上完成編譯、kernel warmup、自動調優（autotuning）同 CUDA graph 捕獲。
呢幾樣嘢全部喺現有 worker 繼續處理請求嘅同時進行。提交階段，vLLM 只會短暫暫停調度器（scheduler），切換到預備好嘅拓撲，再恢復服務。
提交之後，異步 Expert Parallel Load Balancing（EPLB）會先讓新 worker 開始處理 attention 計算，舊 worker 繼續處理 expert 計算，然後喺背景逐步將 expert 重新分配到擴展後嘅通訊組。
另一項關鍵改動係引入 NIXL EP。之前嘅 EP 通訊後端係固定成員制，每次增減 rank 都要求建新 instance，舊新 instance 各要獨立嘅通訊 buffer 同記憶體註冊資源。NIXL EP 允許喺現有 instance 上就咁擴展通訊組，唔使另起爐灶。
結果
同一 DeepSeek V4 Pro 基準下：
| 操作 | 傳統重啟 | 第一版 Elastic EP | 今次（非同步 + NIXL EP） |
|---|---|---|---|
| 16 → 20 GPU | 197 秒 | 100 秒 | 0.82 秒 |
| 20 → 16 GPU | — | 56 秒 | 1.96 秒 |
模姐驗嚇貨：呢個係廠商自己嘅技術博客，數字來源係 vLLM 團隊嘅內部基準測試，冇第三方獨立複現。0.82 秒嘅停機喺實際生產環境會唔會受網路條件、權重傳輸距離、或者並發請求量影響，佢哋未交代。呢類基礎設施嘅改進對營運大規模 AI 推理集群嘅人，特別係用大量 GB200 跑 MoE 模型嘅團隊，係真金白銀嘅節省；但用細模型或者單卡部署嘅人，呢個基本同你無關。
模姐｜深度調教
