Gateway with Inference Extension流量管理和推理服務管理 - Container Service for Kubernetes

本文介紹Gateway with Inference Extension組件的主要特性、實現原理和功能優勢。

能力介紹

Gateway with Inference Extension組件是基於Kubernetes社區Gateway API及其Inference Extension規範實現的增強型組件，支援Kubernetes四層/七層路由服務，並提供面向產生式AI推理情境的一系列增強能力。它能夠簡化產生式AI推理服務的管理流程，並最佳化在多個推理服務工作負載之間的負載平衡效能。

組件特性

最佳化的模型推理服務負載平衡。
基於模型感知的路由：基於OpenAI API規範中定義的模型名稱對推理請求進行路由。您可以通過名稱對同一基本模型的不同LoRA模型進行流量灰階操作。
配置模型的關鍵性：通過指定不同模型的關鍵性等級，將請求不同模型的請求進行不同等級的優先處理。

資源說明

Gateway with Inference Extension通過基於Gateway API擴充的InferencePool和InferenceModel自訂資源來聲明和管理產生AI推理服務：

InferencePool：代表一組共用相同計算配置、加速器類型、基本模型和模型伺服器的Pod。在邏輯上對AI模型服務資源進行分組和管理。單個InferencePool對象可以包含跨越多個ACK節點上的多個Pod，提供可擴充性和高可用性。
InferenceModel：從InferencePool中指定模型伺服器Pod提供服務的模型的名稱。InferenceModel資源還定義了模型的服務屬性，如模型的關鍵性等級（Criticality），被分類為Critical的工作負載將優先處理。

以下為InferencePool、InferenceModel自訂資源與Gateway API資源之間的關聯關係。

下圖說明了Gateway with Inference Extension組件InferencePool、InferenceModel資源定義對推理請求的處理流程。

推理拓展負載平衡功能優勢

傳統HTTP路由

對於傳統的HTTP請求，經典負載平衡演算法可以將請求均勻地發送給不同的工作負載。然而，對於LLM推理服務來說，每個請求給後端帶來的負載是難以預測的。在推理過程中，請求處理包括以下兩個階段：

預填充階段：對輸入進行編碼。
解碼階段：分為若干步驟，每個步驟都會對先前的輸入進行解碼，並輸出新的Token（LLM資料處理的基本單位，可粗略對應LLM推理輸出的每個單詞）。

由於無法事先確定每個請求會輸出多少Token，如果將請求均勻發送到不同工作負載，將導致每個工作負載的實際工作量不一致，造成負載不均衡。

推理服務路由

通過推理伺服器多個維度指標來評估推理伺服器的內部狀態，並根據內部狀態對多個推理伺服器工作負載進行負載平衡。主要包括以下指標：

請求隊列長度（vllm: num_requests_waiting）：代表模型伺服器正在排隊等待處理的請求數量。排隊的請求數量越少，新請求被及時處理的可能性越大。
GPU Cache利用率（vllm: gpu_cache_usage_perc）：代表模型伺服器用於緩衝推理中間結果的KV Cache利用率百分比。利用率越低，代表GPU還有充足的空間將資源分派給新來的請求。

相對於傳統的負載平衡演算法，此方式可以更好地保證多個推理服務工作負載的GPU負載一致性，顯著降低LLM推理請求第一個Token的響應時延（TTFT），並提升LLM推理請求的輸送量。