返回首頁

推論系統

llm-d 發布 1.0,以多租戶流量控制與穩定 API 強化分散式推論維運

llm-d 於 10 月 20 日發布 1.0,將多租戶服務品質、協調升級與代理會話路由納入推論堆疊。新版提供穩定的 v1 設定 API,但優先權政策仍須主動配置,故障移轉能力也有後續開發項目。

Diego Delso · CC BY-SA 3.0 · Image source
zh-Hant

llm-d 專案於 10 月 20 日宣布推出 1.0,把分散式推論的重點推向部署後的維運:如何讓互動請求與突發代理流量共用叢集,以及如何協調多個推論元件升級。這套 Kubernetes 原生開源堆疊位於 vLLM、SGLang 等引擎之上,負責跨副本路由與資源協調。IBM 的發布說明指出,前綴快取路由、KV 快取卸載及 prefill/decode 分離等技術早已存在,這次強化的是整合與操作成熟度。IBM 發布說明

多租戶控制是新版的實質變化。路由器依租戶或工作負載識別碼及優先等級建立佇列,先按優先權派送,再於同級租戶間公平輪替。後端飽和時,請求可留在路由層等待,避免大量工作先塞進模型伺服器。這有助於保護互動延遲,但預設仍近似先到先服務,部署者須自行啟用政策。專案技術公告

升級方面,Endpoint Picker 加入熱備援;DisaggregatedSet 則把提示處理與逐 token 生成副本視為同一邏輯單位,依版本與就緒狀態選擇相容配對。設定 API 同時升至穩定的 v1,讓平台團隊有較明確的整合介面。專案技術公告

對代理應用,會話路由會優先把後續請求送回保有 KV 快取的副本,待其飽和後再重新分配。技術上的價值在於減少每輪重算相同程式碼、文件與歷史內容,而實際收益仍取決於上下文重用率及負載分布。IBM 技術說明

工程團隊接下來應驗證混合流量的尾端延遲與升級期間錯誤率。官方仍把主動/主動路由器、請求故障移轉及遷移列為後續工作,因此「零停機」宣稱須依部署條件測試,不能直接推及所有故障情境。專案後續規畫

來源

  1. llm-d v1.0: State-of-the-art inference, ready for Day 2
  2. llm-d 1.0 hardens open-source AI inference for day 2 production operations