開發生態
微軟發布 AKS 代理流量路由架構:結合 RouteLLM 與 GPU 狀態感知,最高可省 85% 成本
InfoQ 中國多家報導
尚未逐項核實
多個報導來源提及此事;未必是彼此獨立的證據。
微軟發布用於在 Azure Kubernetes Service (AKS) 上路由 AI 代理(agent)流量的參考架構,旨在解決代理任務在「規劃—行動—觀察」循環中產生大量 LLM 呼叫的成本與延遲問題。
該架構將問題拆分為三個層面,並由三個核心組件共同接入與 OpenAI 相容的端點:
1. **RouteLLM**:負責語義路由,檢查提示詞並預測較低成本模型能否達到強模型的回答品質。在測試組合中,其矩陣分解(mf)路由器能達到 GPT-4 在 MT-Bench 上約 95% 的品質,且僅將 26% 的呼叫發給 GPT-4,最高可節省 85% 成本。
2. **agentgateway**:開源代理,負責管理身分驗證、速率限制、成本追蹤與護欄等策略,過程中不檢查提示詞內容。
3. **Kubernetes Gateway API Inference Extension**:其 Endpoint Picker 會檢查 GPU 即時狀態,透過 KAITO 提供的 vLLM 指標(如 KV 快取占用率和佇列深度),決定由哪個 GPU 副本處理請求,避免將短請求排在繁忙 GPU 的長請求之後。
微軟提醒,提示詞快取會使成本計算複雜化,因為切換模型會導致兩邊的快取冷卻,這意味著強模型呼叫的真實成本可能低於表面價格。用戶需根據實際流量校準 RouteLLM 的升級閾值。
此外,架構中的開源組件仍在發展中,具體標誌和 CRD 欄位變動較快。微軟指出,Foundry 模型路由器可作為 RouteLLM 語義層的託管替代方案,但 Endpoint Picker 的 GPU 感知放置功能目前尚無託管選項,必須在叢集內運行。團隊可依需求分階段導入這些組件。
讀原始報導背景
KAITO(Kubernetes AI Toolchain Operator)採用經典的 Kubernetes 自訂資源定義(CRD)與控制器架構,可透過 Helm 安裝於任何 Kubernetes 叢集中。微軟此次發布的路由方案即利用 KAITO 來隨需提供 GPU 節點池並運行 vLLM,藉此優化 AI 代理(Agent)在執行大量推論任務時的底層資源分配。