容器應用閘道 - 推論閘道

AI 推論工作負載的行為不像傳統的無狀態 HTTP 應用程式。 請求通常依模型而異，執行時間長，服務成本高昂，且對執行時訊號（如加速器可用性、佇列深度、請求優先權、令牌預算及模型伺服器容量）敏感。

容器應用閘道推論閘道透過整合 Kubernetes Gateway API 推論擴充，支援這些工作負載，該擴充套件為閘道 API 模型新增推理感知資源。 透過推論閘道，你可以透過容器適用的應用程式閘道（Application Gateway for Containers）對外公開自架模型伺服器，並提供模型感知和負載感知的路由功能。

推論閘道專為大型語言模型（LLM）及其他推論工作負載設計。 它會依據模型伺服器訊號來路由要求，而不是採用通用的負載平衡方式，從而縮短首個權杖產出時間 (TTFT)、減少高負載下的逾時，並提升 GPU 效率。 該推論閘道建立在 Application Gateway for Containers 的入口功能之上，也能將 AI 工作負載與網頁應用防火牆（WAF）等功能結合，確保流量在抵達模型伺服器前的安全。

許多自行託管的推論執行階段（包括 vLLM）提供與 OpenAI 相容的 HTTP API，例如 /v1/chat/completions、/v1/completions 和 /v1/models。 OpenAI 相容指的是 API 格式，而非僅限於 OpenAI 託管模型。 若透過使用此格式的執行階段或 Proxy 伺服器服務其他模型系列，適用於容器的應用程式閘道可在 JSON 要求本文中使用 model 欄位進行基於本文的路由。

Important

容器推論閘道應用閘道目前處於預覽階段。
請參閱Microsoft Azure 預覽的補充使用條款，以了解適用於 Azure 測試版、預覽版或其他尚未正式發布的功能的法律條款。

Gateway API 推論擴充所提供的是什麼

Gateway API Inference Extension 透過加入推理專屬的後端與排程概念，將 Gateway API 實作轉變為推理閘道。

擴充介紹了以下主要資源與元件：

  • InferencePool：一種後端資源，代表一組模型伺服器 pod 和用於為每個推理請求選取 pod 的端點選取器。
  • InferenceObjective：代表請求服務目標（如優先權）的資源，適用於共享推理池的請求。
  • 端點選擇器（Endpoint Picker，EPP）：客戶提供的擴充功能，運行於叢集中並實現推論排程。 EPP 接收請求中繼資料，透過可設定的外掛程式（例如佇列深度、KV 快取使用率，以及前綴快取親和性）為候選模型伺服器 Pod 評分，並回傳所選的端點。 因為端點選擇是在 EPP 中執行，可用的路由行為取決於你 EPP 啟用的計分器插件。
  • 主體式路由（BBR）：一種請求處理器，能檢查與 OpenAI 相容的請求主體、擷取模型名稱，並將其作為 X-Gateway-Model-Name 標頭提供給閘道，以進行模型感知路由。

容器應用閘道（Application Gateway for Containers）將 BBR 處理器作為閘道的管理部分運行，因此沒有獨立的實體路由層級可供部署、擴展或修補。 它與客戶提供的 EPP 整合，以支援請求時的路由決策。 推論閘道支援閘道 API 推論擴展 API，因此你透過標準閘道 API 資源配置這些功能，平台團隊可使用 Kubernetes 原生的 API 模型來處理推論流量，而不必引入獨立的入口配置模型。

容器應用閘道如何使用推論資源

容器應用閘道持續使用標準閘道 API 資源進行入口配置。 當 HTTPRoute 後端參照指向 InferencePool 而非 Kubernetes Service 時，會啟用推斷行為。

對於非推論路由，容器應用閘道保留現有的閘道 API 行為。 針對 Kubernetes Service 後端的路由不會呼叫推理處理器，也不會接收推理專屬的路由行為。

對於推論路由，控制平面會調和閘道 API 與推論資源，並對資料平面進行程式設計，使得：

  • HTTPRoute 會選擇 InferencePool 後端。
  • InferencePool 會選取屬於該集區的模型伺服器 Pod。
  • 與池相關的 EPP 會被調用以選擇端點。
  • 所選模型伺服器端點會接收請求。
  • 可選的模型感知路由則使用 BBR 擷取的請求模型名稱。

請求流程

典型的推論請求會遵循此路徑。 編號步驟對應到下圖中的標籤：

  1. 用戶端請求：用戶端向容器應用閘道前端發送相容 OpenAI 的請求，閘道監聽器會接受該請求。
  2. 基於實體路由（Body-based route，BBR）：對於模型感知路由，受管理的 BBR 處理器會檢查請求體，擷取模型名稱並注入 X-Gateway-Model-Name 標頭。 HTTPRoute 接著可根據該值進行比對，以選取適當的 InferencePool。
  3. 端點選擇：當匹配的路由指向 InferencePool時，容器應用閘道會呼叫 EPP，該 EPP 會評估請求與模型伺服器遙測資料，並回傳所選端點。
  4. 導引至推論池：容器應用閘道會將請求轉發至所選模型伺服器莢艙，模型伺服器的回應則透過閘道回傳給用戶端。

一張顯示容器用應用程式閘道透過 BBR 處理要求，並根據 EPP 的結果做出路由決策的圖表。

路由能力

推論閘道支援這些路由模式，適用於自架 AI 工作負載。 端點選擇是在 EPP 中執行的，因此載入感知和快取感知的行為取決於你 EPP 啟用的評分器插件。

  • 模型感知路由：根據 OpenAI 相容要求本文中的型號名稱路由要求，並由受控 BBR 處理器擷取。
  • 流量分割與推出：使用標準 HTTPRoute 加權 backendRefs 方式將流量拆分到 InferencePool 各個後端，用於推出 Canary 或藍綠模型。
  • 具負載感知與快取感知能力的端點選擇：EPP 根據模型伺服器遙測資料（例如佇列深度與 KV 快取使用率）為端點評分。 當 EPP 啟用前綴快取感知評分時，具有相同提示前綴的請求會被導向同一個副本，以提高快取命中率並降低 TTFT。
  • 請求優先權與過載保護：利用 InferenceObjective 資源與 x-gateway-inference-objective 請求標頭來分配服務優先權。 當模型伺服器飽和時，EPP 會先拋棄優先權較低的請求，以保護對延遲至關重要的流量。
  • 彈性端點選擇：視集區是更重視可用性還是嚴格的端點選擇而定，使用 FailOpen 或 FailClose 來設定 EPP 失敗行為。
  • 閘道 API 相容性：繼續使用 Gateway、HTTPRoute、ReferenceGrant 及標準閘道 API 狀態條件來設定入口。

安全推論

將模型伺服器私有地設在受管理閘道後方，並應用平台的安全能力來推論流量。

  • 網頁應用防火牆（WAF）：推論閘道可與 容器應用閘道現有的 WAF 功能原生配對，對 AI 流量在請求抵達模型伺服器前，套用 OWASP 對齊的保護措施。
  • 保護昂貴後端：由於政策在受管理邊緣執行，錯誤或濫用請求可在耗用稀缺 GPU 容量前被檢查並阻擋。

範例情境

以下情境展示了使用推理閘道的常見方式：

  • 提供模型版本並推出：依模型名稱將相容 OpenAI 的要求路由至 InferencePool，然後使用加權的 HTTPRoute backendRefs，將一定比例的流量轉移至新模型版本進行 Canary 測試，再完成推出。
  • 優先處理延遲敏感流量：在共用集區上，為高優先順序和低優先順序工作負載定義 InferenceObjective 資源。 互動式聊天要求採用高優先順序目標，而批次作業則使用較低的優先順序；當集區處於飽和狀態時，批次作業會優先被捨棄。

InferencePool 與服務的比較

Kubernetes Service 仍然是標準應用程式流量的適當後端抽象層。 當後端是一組需要針對推論進行特定端點選擇的模型伺服器 Pod 時，請使用 InferencePool

後端類型 用途 路由行為
Service 標準 HTTP、gRPC 與應用後端 閘道器透過標準負載平衡行為路由至服務端點。
InferencePool 自我託管的模型伺服器 Pod Gateway 會呼叫已設定的 EPP，然後路由到所選的模型伺服器端點。

InferencePool 包含 Pod 選擇器、目標連接埠資訊，以及端點選擇器參考。 EPP 負責選擇請求的端點。 單一 EPP 與單一集區相關聯。

故障行為

推論路由是請求時的行為，因此端點選擇器的失敗模式很重要。

InferencePool 端點選擇器參考支援以下故障模式：

  • FailOpen：若 EPP 無法使用或沒有回應，閘道仍可繼續對該集區進行標準的端點選取。 此選擇保留可用性，但可能降低路由品質。
  • FailClose：若 EPP 無法使用或未回應，閘道器會拒絕該請求。 此選擇可防止流量在未完成終端選擇決策前被傳送。

對於依賴請求體解析的模型感知路由，容器應用閘道偏好正確性。 如果無法提取需要 BBR 的路由的型號名稱，請求會被拒絕，而不是靜默地路由到錯誤的模型後端。

作業考量

在適用於容器的應用程式閘道後方執行推論工作負載時，請規劃下列考量事項：

  • EPP 容量：EPP 位於後端的請求路徑 InferencePool 上。 像對待關鍵應用程式元件一樣，評估並監控它。
  • 模型伺服器遙測：EPP 需要新的模型伺服器指標來做出高品質的路由決策。 確認你的模型伺服器是否支援 EPP 設定所期望的指標。
  • GPU 容量與排程：模型伺服器 Pod 通常需要 GPU 節點池、裝置外掛及模型下載憑證。
  • 自動調整：利用水平 Pod 自動調整器 (KEDA) 根據推論訊號 (如佇列深度與 KV 快取利用率) 進行模型伺服器 Pod 的調整。 自動調整會隨著需求增加增加容量，而 EPP 則會繞過已經飽和的複本。
  • 串流回應：許多聊天完成工作負載使用伺服器發送的事件。 在測試端到端延遲與逾時設定時，請確認串流行為。
  • 可觀察性：監控閘道器與 HTTPRoute 狀態、InferencePool 狀態、EPP 健康狀態、模型伺服器準備度，以及模型伺服器指標如主動請求與佇列深度。

Limitations

推論閘道器專注於運行於 Kubernetes 上的自架推論工作負載。 直接路由至公共或受管理模型提供者端點，並不屬於此整合的範圍。

Gateway API 推論擴充功能獨立於容器應用閘道（Application Gateway for Containers）演進。 使用與叢集上推論擴充 CRD 相符的 API 版本和清單。

下一步

  • 上次更新時間：