關於 GKE 推論閘道

本頁面介紹 Google Kubernetes Engine (GKE) Inference Gateway，這是 GKE Gateway 的強化功能，可最佳化生成式 AI 應用程式的服務。本文將說明重要概念、功能，以及 GKE Inference Gateway 的運作方式。

本頁面適用於下列對象：

  • 有興趣使用 Kubernetes 容器自動化調度管理功能，提供 AI/機器學習工作負載服務的機器學習工程師、平台管理員和營運人員，以及資料和 AI 專家。
  • 與 Kubernetes 網路互動的雲端架構師和網路專員。

閱讀本頁面之前，請先熟悉下列概念：

總覽

GKE 推論閘道是 GKE 閘道的擴充功能，可為提供生成式人工智慧 (AI) 工作負載服務，提供最佳化的路由和負載平衡。可簡化 AI 推論工作負載的部署、管理和可觀測性。

特色與優點

GKE 推論閘道提供下列主要功能，可有效率地為 GKE 上的生成式 AI 應用程式提供生成式 AI 模型：

  • 最佳化推論負載平衡：分配要求，盡量提升 AI 模型服務效能。這項服務會使用模型伺服器的指標 (例如 KVCache Utilization 和 queue length of pending requests)，更有效率地將加速器 (例如 GPU 和 TPU) 用於生成式 AI 工作負載。
  • 動態 LoRA 微調模型服務：支援在通用加速器上提供動態 LoRA 微調模型。這項功能可在通用基礎模型和加速器上多工處理多個 LoRA 微調模型，減少提供模型服務所需的 GPU 和 TPU 數量。
  • 推論最佳化自動調度：GKE 水平 Pod 自動調度器 (HPA) 會使用模型伺服器指標自動調度，確保有效運用運算資源，並提升推論效能。
  • 模型感知型轉送：根據 GKE 叢集OpenAI API規格中定義的模型名稱，轉送推論要求。您可以定義 Gateway 轉送政策 (例如流量分割和要求鏡像)，管理不同模型版本並簡化模型推出作業。舉例來說，您可以將特定模型名稱的要求，傳送至不同的 InferencePool 物件，每個物件會提供不同版本的模型。
  • 模型專屬服務 Criticality：可指定 AI 模型的服務 Criticality。優先處理對延遲時間較為敏感的要求，而非對延遲時間容許度較高的批次推論工作。舉例來說，您可以優先處理延遲時間敏感型應用程式的要求，並在資源受限時捨棄對時間敏感度較低的工作。
  • 整合式 AI 安全性：與 Google Cloud Model Armor 整合，這項服務會在閘道對提示和回覆套用 AI 安全性檢查。 Model Armor 會提供要求、回應和處理作業的記錄，供您回溯分析及最佳化。GKE Inference Gateway 的開放式介面可讓第三方供應商和開發人員將自訂服務整合至推論要求程序。
  • 推論可觀測性：提供推論要求的可觀測性指標，例如要求率、延遲時間、錯誤和飽和度。監控推論服務的效能和行為。

瞭解重要概念

GKE 推論閘道會使用 GatewayClass 物件，強化現有的 GKE 閘道。GKE 推論閘道導入下列新的 Gateway API 自訂資源定義 (CRD)，與 OSS Kubernetes Gateway API 推論擴充功能保持一致：

  • InferencePool 物件：代表一組共用相同運算設定、加速器類型、基礎語言模型和模型伺服器的 Pod (容器)。這項功能會以邏輯方式分組及管理 AI 模型服務資源。單一 InferencePool 物件可以跨越多個 Pod，分布在不同的 GKE 節點，並提供擴充性和高可用性。
  • InferenceModel 物件：根據 OpenAI API 規格，從 InferencePool 指定服務模型的名稱。InferenceModel 物件也會指定模型的服務屬性，例如 AI 模型的 Criticality。GKE 推論閘道會優先處理分類為 Critical 的工作負載。這樣一來，您就能在 GKE 叢集上多工處理延遲時間關鍵和延遲時間容許的 AI 工作負載。您也可以設定 InferenceModel 物件，提供 LoRA 微調模型。
  • TargetModel 物件：指定目標模型名稱和提供模型的 InferencePool 物件。您可以藉此定義 Gateway 路由政策，例如流量分割和要求鏡像，並簡化模型版本推出作業。

下圖說明 GKE Inference Gateway，以及該閘道在 GKE 叢集內與 AI 安全性、可觀測性和模型服務的整合。

GKE Inference Gateway `InferencePool` 和 `InferenceModel` 物件之間的關係
圖： GKE Inference Gateway 資源模型

下圖說明資源模型，著重於兩個新的推論導向角色，以及這些角色管理的資源。

以推論為主的目標對象及其資源的資源模型
圖： GKE Inference Gateway 資源模型

GKE 推論閘道的運作方式

GKE Inference Gateway 會使用 Gateway API 擴充功能和模型專屬的路由邏輯，處理用戶端對 AI 模型的要求。以下步驟說明要求流程。

要求流程的運作方式

GKE Inference Gateway 會將用戶端要求從初始要求轉送至模型執行個體。本節說明 GKE Inference Gateway 如何處理要求。所有用戶端都會使用這個常見的要求流程。

  1. 用戶端會將要求傳送至 GKE 中執行的模型，要求格式如 OpenAI API 規格所述。
  2. GKE Inference Gateway 會使用下列推論擴充功能處理要求：
    1. 以主體為準的轉送擴充功能：從用戶端要求主體擷取模型 ID，並傳送至 GKE Inference Gateway。接著，GKE Inference Gateway 會根據 Gateway API HTTPRoute 物件中定義的規則，使用這個 ID 轉送要求。要求主體轉送與根據網址路徑轉送類似。不同之處在於要求主體路由會使用要求主體的資料。
    2. 安全性擴充功能：使用 Model Armor 或支援的第三方解決方案，強制執行模型專屬的安全政策，包括內容篩選、威脅偵測、清理和記錄。安全性擴充功能會將這些政策套用至要求和回應處理路徑。這樣一來，安全性擴充功能就能清除並記錄要求和回應。
    3. 端點挑選器擴充功能：監控 InferencePool 內模型伺服器的重要指標。這項指標會追蹤每個模型伺服器上的鍵/值快取 (KV 快取) 使用率、待處理要求的佇列長度，以及作用中的 LoRA 配接器。接著，系統會根據這些指標將要求傳送至最佳模型副本，盡量縮短延遲時間，並提高 AI 推論的處理量。
  3. GKE Inference Gateway 會將要求轉送至端點選擇器擴充功能傳回的模型副本。

下圖說明從用戶端到模型執行個體的請求流程，該流程會經過 GKE Inference Gateway。

從用戶端到模型執行個體的要求流程 (透過 GKE Inference Gateway)
圖： GKE Inference Gateway 要求流程

流量分配的運作方式

GKE Inference Gateway 會將推論要求動態分配至 InferencePool 物件中的模型伺服器。這有助於盡量減少資源用量，並在不同負載條件下維持效能。GKE Inference Gateway 使用下列兩種機制管理流量分配：

  • 端點挑選：動態選取最合適的模型伺服器，處理推論要求。並監控伺服器負載和可用性，然後做出路由決策。

  • 佇列和卸除：管理要求流程，防止流量過載。GKE Inference Gateway 會將連入要求儲存在佇列中，根據定義的條件排定要求優先順序，並在系統超載時捨棄要求。

GKE 推論閘道支援下列 Criticality 層級：

  • Critical：系統會優先處理這些工作負載。即使資源受限，系統也會確保這些要求獲得處理。
  • Standard：資源可用時，系統會提供這些工作負載。如果資源有限，系統會捨棄這些要求。
  • Sheddable：系統會視情況處理這些工作負載。如果資源不足，系統會捨棄這些要求，以保護 Critical 工作負載。

當系統資源不足時，Standard 和 Sheddable 要求會立即遭到捨棄，並傳回 429 錯誤碼，以保護 Critical 工作負載。

串流推論

GKE Inference Gateway 支援串流推論，適用於需要持續或近乎即時更新的應用程式，例如聊天機器人和即時翻譯。串流推論會以遞增的區塊或片段形式提供回覆，而非單一完整輸出內容。如果在串流回應期間發生錯誤，串流會終止，且用戶端會收到錯誤訊息。GKE 推論閘道不會重試串流回應。

查看應用程式範例

本節提供範例，說明如何使用 GKE Inference Gateway 解決各種生成式 AI 應用情境。

範例 1：在 GKE 叢集上提供多個生成式 AI 模型

某公司想部署多個大型語言模型 (LLM)，以處理不同的工作負載。舉例來說，他們可能想為聊天機器人介面部署 Gemma3 模型，並為推薦應用程式部署 Deepseek 模型。公司必須確保這些 LLM 的放送成效達到最佳狀態。

使用 GKE Inference Gateway，您可以在 InferencePool 中，以所選的加速器設定，將這些 LLM 部署至 GKE 叢集。然後，您可以根據模型名稱 (例如 chatbot 和 recommender) 和 Criticality 屬性轉送要求。

下圖說明 GKE Inference Gateway 如何根據模型名稱和 Criticality，將要求傳送至不同模型。

根據模型名稱和重要性，將要求轉送至不同模型
圖： 使用 GKE Inference Gateway 在 GKE 叢集上提供多個生成式 AI 模型

範例 2：在共用加速器上提供 LoRA 適應器

某公司想提供大型語言模型服務，用於文件分析，並專注於多種語言的目標對象，例如英文和西班牙文。他們已針對每種語言微調模型，但需要有效運用 GPU 和 TPU 容量。您可以使用 GKE 推論閘道，在通用基礎模型 (例如 llm-base) 和加速器上，為每種語言 (例如 english-bot 和 spanish-bot) 部署動態 LoRA 微調介面卡。您可以在共用加速器上密集封裝多個模型，藉此減少所需的加速器數量。

下圖說明 GKE Inference Gateway 如何在共用加速器上提供多個 LoRA 配接器。

在共用加速器上提供多個 LoRA 適應器
圖： 在共用加速器上提供 LoRA 適應器

後續步驟