本頁面說明 Google Kubernetes Engine (GKE) Inference Gateway 的重要概念和功能。GKE Inference Gateway 是 GKE Gateway 的擴充功能，可最佳化生成式 AI 應用程式的提供程序。
本頁面假設您已瞭解下列事項：
- GKE 中的 AI/機器學習自動化調度管理機制
- 生成式 AI 術語
- GKE 網路概念，包括服務和 GKE Gateway API
- 負載平衡 Google Cloud，特別是負載平衡器與 GKE 的互動方式
本頁面適用於下列角色：
- 機器學習 (ML) 工程師、平台管理員和操作員，以及有興趣使用 Kubernetes 容器自動化調度管理功能，提供 AI/機器學習工作負載的資料和 AI 專家。
- 與 Kubernetes 網路互動的雲端架構師和網路專家。
總覽
GKE Inference Gateway 是 GKE Gateway 的擴充功能，可提供最佳化的轉送和負載平衡功能，用於提供生成式人工智慧 (AI) 工作負載。可簡化 AI 推論工作負載的部署、管理和觀測作業。GKE Inference Gateway 無須額外付費。您只需為使用的基礎 Google Cloud 資源付費。
如要為 AI/機器學習工作負載選擇最佳負載平衡策略，請參閱「選擇 GKE AI 推論的負載平衡策略」。
特色與優點
GKE Inference Gateway 提供下列重要功能，可有效率地為 GKE 上的生成式 AI 應用程式提供生成式 AI 模型：
- 支援的指標：
KV cache hits：鍵/值 (KV) 快取中成功查詢的次數。- GPU 或 TPU 使用率：GPU 或 TPU 主動處理作業的時間百分比。
- 要求佇列長度：等待處理的要求數量。
- 推論負載平衡最佳化：分配要求，盡量提升 AI 模型服務效能。這項功能會使用模型伺服器的指標 (例如
KV cache hits和queue length of pending requests)，更有效率地使用加速器 (例如 GPU 和 TPU)，處理生成式 AI 工作負載。這會啟用前置字元快取感知轉送，這項重要功能會分析要求主體，找出具有共用內容的要求，並盡可能提高快取命中率，將要求傳送至相同的模型副本。這種做法可大幅減少多餘的運算，並縮短首個詞元生成時間，因此非常適合用於對話式 AI、檢索增強生成 (RAG) 和其他範本式生成式 AI 工作負載。 - 動態 LoRA 微調模型服務：支援在共用加速器上提供動態 LoRA 微調模型。這項技術可在通用基礎模型和加速器上多工處理多個 LoRA 微調模型，減少提供模型所需的 GPU 和 TPU 數量。
- 最佳化推論自動調度資源：GKE 水平 Pod 自動調度資源 (HPA) 會使用模型伺服器指標自動調度資源，確保有效率地使用運算資源，並最佳化推論效能。
- 模型感知轉送：根據 GKE 叢集內
OpenAI API規格中定義的模型名稱，轉送推論要求。您可以定義閘道轉送政策 (例如流量分割和要求鏡像)，管理不同模型版本並簡化模型推出程序。舉例來說，您可以將特定模型名稱的要求，導向至不同的 InferencePool 物件，每個物件都提供不同版本的模型。如要進一步瞭解如何設定這項功能，請參閱「設定以主體為準的路由」。 - 整合式 AI 安全防護和內容篩選：GKE Inference Gateway 與 Google Cloud Model Armor 整合，可在閘道對提示和回覆套用 AI 安全檢查和內容篩選。您也可以使用 NVIDIA NeMo Guardrails。Model Armor 提供要求、回覆和處理作業的記錄，方便您進行回溯分析及最佳化。GKE Inference Gateway 的開放式介面可讓第三方供應商和開發人員將自訂服務整合至推論要求程序。
- 模型專屬服務
Priority：可指定 AI 模型的服務Priority。優先處理對延遲敏感的要求，而非可容忍延遲的批次推論工作。舉例來說，您可以優先處理對延遲時間敏感的應用程式要求，並在資源受限時捨棄時效性較低的工作。 - 根據預測延遲時間轉送：使用持續以即時流量訓練的 XGBoost 模型轉送推論要求，盡可能縮短每個要求的第一個詞元生成時間 (TTFT) 和每個輸出詞元生成時間 (TPOT)。在高變異工作負載下，比靜態經驗法則更準確。請參閱「搭配使用預測延遲時間轉送與 GKE Inference Gateway」。
- 推論觀測能力：提供推論要求的觀測能力指標，例如要求比率、延遲時間、錯誤和飽和度。透過 Cloud Monitoring 和 Cloud Logging 監控推論服務的效能和行為，並運用預先建構的專用資訊主頁取得詳細洞察資訊。詳情請參閱「查看 GKE Inference Gateway 資訊主頁」。
- CORS 設定：支援
HTTPRoute資源的跨源資源共享 (CORS)。CORS 可協助在不同網域執行的網頁應用程式，安全存取推論端點。單一叢集閘道支援 CORS。 - 使用 Apigee 進行進階 API 管理：與 Apigee 整合，透過 API 安全性、頻率限制和配額等功能，強化推論閘道。如需詳細操作說明，請參閱「設定 Apigee 進行驗證和 API 管理」。
- 擴充性：建構於可擴充的開放原始碼 Kubernetes Gateway API 推論擴充功能，支援使用者管理的 llm-d 端點挑選器 (EPP) 演算法，由 llm-d 提供技術支援。llm-d 端點挑選器 (EPP) 演算法由 llm-d 提供技術支援，為這項擴充功能提供核心轉送智慧。
- 多埠支援：支援公開多個通訊埠的模型伺服器，這對資料平行注意力機制等進階服務情境至關重要。
- 網路端點群組 (NEG) 限制：每個Google Cloud 後端服務最多可有 50 個 NEG。使用多埠 InferencePool 時，每個可用區中的每個埠都會建立專屬 NEG。舉例來說，在一般區域叢集 (三個可用區) 中，具有八個通訊埠的 InferencePool 會產生 24 個 NEG。因此，多叢集閘道最多只能從兩個叢集匯總這類 InferencePool (兩個叢集 × 24 個 NEG = 48 個 NEG)，然後達到 50 個 NEG 的上限。
瞭解重要概念
GKE Inference Gateway 強化了使用 GatewayClass 物件的現有 GKE Gateway。GKE Inference Gateway 推出下列新的 Gateway API 自訂資源定義 (CRD)，與推論適用的 OSS Kubernetes Gateway API 擴充功能一致：
- InferencePool 物件：代表一組 Pod (容器)，共用相同的運算設定、加速器類型、基礎語言模型和模型伺服器。這項資源會以邏輯方式將 AI 模型服務資源分組及管理。單一 InferencePool 物件可橫跨不同 GKE 節點的多個 Pod，並提供擴充性和高可用性。您最多可以在 InferencePool 資源中指定八個
targetPorts，以支援需要多個通訊埠的模型伺服器。 - InferenceObjective 物件：根據
OpenAI API規格，指定 InferencePool 的服務模型名稱。InferenceObjective 物件也會指定模型的服務屬性，例如 AI 模型的Priority。GKE Inference Gateway 會優先處理優先順序值較高的工作負載。您可以在 GKE 叢集上多工處理著重延遲時間和容許延遲時間的 AI 工作負載。您也可以設定 InferenceObjective 物件，提供經過 LoRA 微調的模型。
下圖說明 GKE Inference Gateway，以及其與 GKE 叢集內 AI 安全性、觀測能力和模型提供功能的整合。
下圖說明資源模型，著重於兩個新的推論角色及其管理的資源。
llm-d 路由器
llm-d路由器是智慧要求轉送元件，Inference Gateway 會使用這個元件，針對每個要求做出端點決策。這個公式由兩個子元件組成：
| 子元件 | 說明 |
|---|---|
| `L7 Proxy` | 任何符合規範的業界標準 L7 Proxy (通常是 Envoy)，可處理資料平面：連線管理、TLS 終止和要求轉送。在 GKE Inference Gateway (閘道模式) 中，Proxy 是 GKE Gateway。 |
| `llm-d Endpoint Picker (EPP)` | Proxy 會使用 ext-proc 通訊協定，針對每項要求諮詢這項專門服務。EPP 包含轉送情報。這項功能會使用模型伺服器的即時信號 (KV 快取使用率、佇列長度、前置字元快取狀態和 LoRA 轉接器相似度)，為每項要求選取最佳模型伺服器 Pod。 |
閘道模式
GKE Inference Gateway 是以閘道模式運作的 llm-d Router。在閘道模式中，Proxy 是正式的 Kubernetes 閘道，與 EPP 服務分開佈建及管理。閘道會透過 ext-proc 呼叫 EPP，做出轉送決策，然後將要求直接轉送至所選模型伺服器 Pod。
將閘道 (資料層) 與 EPP (轉送智慧) 分開，可帶來以下優勢：
- 共用基礎架構：單一 GKE Gateway 可與標準 Kubernetes Service 一併為多個 InferencePool 提供服務。
- 進階流量管理：
HTTPRoute政策支援加權分割、逐步推出及要求鏡像。 - 獨立調度資源：EPP 服務會獨立於閘道調度資源。
- 雲端原生整合：可與 GKE 的代管閘道控制器、Cloud Load Balancing 和現有觀測工具搭配使用。
GKE Inference Gateway 的運作方式
GKE Inference Gateway 會使用 Gateway API 擴充功能和模型專屬的轉送邏輯，處理用戶端對 AI 模型的要求。以下步驟說明要求流程。
要求流程的運作方式
GKE Inference Gateway 會將用戶端要求從初始要求轉送至模型執行個體。本節說明 GKE Inference Gateway 如何處理要求。所有用戶端都適用這個要求流程。
- 用戶端會將要求傳送至 GKE 中執行的模型，要求的格式符合 OpenAI API 規格。
GKE Inference Gateway 會使用下列推論擴充功能處理要求：
- 以主體為依據的路由擴充功能：從用戶端要求主體擷取模型 ID，並傳送至 GKE Inference Gateway。接著，GKE Inference Gateway 會使用這個 ID，根據 Gateway API
HTTPRoute物件中定義的規則轉送要求。要求主體路由與根據網址路徑的路由類似。兩者的差異在於要求主體路由會使用要求主體的資料。 - 安全性擴充功能：使用 Model Armor、NVIDIA NeMo Guardrails 或支援的第三方解決方案，強制執行模型專屬安全政策，包括內容篩選、威脅偵測、清理和記錄。安全擴充功能會將這些政策套用至要求和回應處理路徑。
- llm-d 端點選擇器 (EPP)：監控 InferencePool 中模型伺服器的重要指標，並將要求轉送到最佳模型副本。詳情請參閱「llm-d Router」。
- 以主體為依據的路由擴充功能：從用戶端要求主體擷取模型 ID，並傳送至 GKE Inference Gateway。接著，GKE Inference Gateway 會使用這個 ID，根據 Gateway API
GKE Inference Gateway 會將要求轉送至端點挑選器擴充功能傳回的模型副本。
下圖說明用戶端透過 GKE Inference Gateway 將要求傳送至模型執行個體的流程。
流量分配的運作方式
GKE Inference Gateway 會將推論要求，動態分配給 InferencePool 物件中的模型伺服器。這有助於最佳化資源使用率，並在不同負載條件下維持效能。GKE Inference Gateway 會使用下列兩種機制管理流量分配：
端點選擇：動態選取最適合的模型伺服器，處理推論要求。這項服務會監控伺服器負載和可用性，然後結合多項最佳化經驗法則，為每部伺服器計算
score，做出最佳轉送決策：- 前置字元快取感知轉送：GKE Inference Gateway 會追蹤每個模型伺服器上可用的前置字元快取索引，並為前置字元快取比對結果較長的伺服器提供較高分數。
- 負載感知轉送：GKE Inference Gateway 會監控伺服器負載 (KV 快取使用率和待處理佇列深度)，並為負載較低的伺服器提供較高分數。
- LoRA 感知路徑：啟用動態 LoRA 服務時，GKE Inference Gateway 會監控每個伺服器的有效 LoRA 轉接器，並為有效 LoRA 轉接器或額外空間的伺服器提供較高分數，以便動態載入要求的 LoRA 轉接器。系統會挑選上述所有分數總和最高的伺服器。
佇列和捨棄：管理要求流程，防止流量過載。GKE Inference Gateway 會將傳入的要求儲存在佇列中，並根據定義的優先順序排定要求優先順序。
GKE Inference Gateway 會使用數字 Priority 系統 (又稱
Criticality) 管理要求流程，並防止過載。這個 Priority 是選用的整數欄位，由使用者為每個 InferenceObjective 定義。值越大，表示要求越重要。當系統負載過重時，Priority 小於 0 的要求會視為優先順序較低，並優先捨棄，傳回 429 錯誤，以保護更重要的工作負載。Priority 預設為 0。只有在明確將要求的 Priority 設為小於 0 的值時，系統才會因優先順序而捨棄要求。這個系統可讓您優先處理對延遲時間較敏感的線上推論流量，而非對時間較不敏感的批次工作。
GKE Inference Gateway 支援串流推論，適用於需要持續或近乎即時更新的應用程式，例如聊天機器人和即時翻譯。串流推論會以遞增區塊或片段的形式提供回覆，而非單一完整輸出。如果串流回應期間發生錯誤，串流會終止，且用戶端會收到錯誤訊息。GKE Inference Gateway 不會重試串流回應。
探索應用程式範例
本節提供範例，說明如何使用 GKE Inference Gateway 解決各種生成式 AI 應用程式情境。
範例 1：在 GKE 叢集上提供多個生成式 AI 模型
某公司想部署多個大型語言模型 (LLM)，處理不同的工作負載。舉例來說，他們可能想為聊天機器人介面部署 Gemma3 模型，並為推薦應用程式部署 DeepSeek 模型。公司必須確保這些 LLM 的服務效能達到最佳狀態。
使用 GKE Inference Gateway，您可以在 InferencePool 中，以所選的加速器設定，將這些 LLM 部署至 GKE 叢集。接著，您可以根據模型名稱 (例如 chatbot 和 recommender) 和 Priority 屬性轉送要求。
下圖說明 GKE Inference Gateway 如何根據模型名稱和 Priority，將要求轉送至不同模型。
這張圖表說明 GKE Inference Gateway 如何處理 example.com/completions 上生成式 AI 服務的要求。要求會先傳送至 Infra 命名空間中的 Gateway。這個 Gateway 會將要求轉送至 GenAI Inference 命名空間中的 HTTPRoute，該命名空間已設定為處理聊天機器人和情緒模型的要求。如果是聊天機器人模型，HTTPRoute 會分割流量：90% 導向執行目前模型版本 (由 {pool: gemma} 選取) 的 InferencePool，10% 則導向執行較新版本 ({pool: gemma-new}) 的集區，通常用於初期測試。這兩個集區都連結至 InferenceObjective，該物件會將聊天機器人模型要求的 Priority 指派為 10，確保這些要求會視為高優先順序。
範例 2：在共用加速器上提供 LoRA 轉接器
某公司想使用 LLM 分析文件，並鎖定多種語言 (例如英文和西班牙文) 的目標對象。他們已針對每種語言微調模型，但需要有效運用 GPU 和 TPU 容量。您可以使用 GKE Inference Gateway，在通用基礎模型 (例如 llm-base) 和加速器上，為每種語言 (例如 english-bot 和 spanish-bot) 部署動態 LoRA 微調轉接器。這樣一來，您就能在一般加速器上密集封裝多個模型，減少所需的加速器數量。
下圖說明 GKE Inference Gateway 如何在共用加速器上，提供多個 LoRA 轉接器。
後續步驟
- 部署 GKE Inference Gateway
- 自訂 GKE Inference Gateway 設定
- 使用 GKE Inference Gateway 提供 LLM
- 搭配 GKE Inference Gateway 使用預測延遲時間轉送(預先發布版)