使用 GKE Inference Gateway 根據預測延遲時間進行路由

本文說明如何啟用及使用 GKE Inference Gateway 中 llm-d 提供的預測延遲時間轉送。根據預設，GKE Inference Gateway 會結合負載信號和前置字元快取親和性啟發式方法，將要求轉送至模型伺服器。以預測延遲時間為依據的轉送功能，會以根據即時流量持續訓練的 XGBoost 模型，取代靜態啟發式權重，在工作負載模式變化時，做出更準確的轉送決策。

使用預測延遲時間路徑的時機

如果工作負載符合下列條件，這項功能就能發揮最大效益：

• 提示和完成長度差異很大：如果要求大小差異很大，單靠佇列深度無法準確反映伺服器負載。延遲時間預測工具會考量每個要求的實際預填和解碼費用。
• 每個要求的延遲時間 SLO：當應用程式在個別要求中指定第一個權杖生成時間 (TTFT) 或每個輸出權杖的時間 (TPOT) 目標時，排程器會在轉送期間強制執行這些目標。方法是計算每個候選 Pod 的預留空間 (預測延遲時間減去 SLO 目標)。
• 靜態權重微調容易出錯：如果流量模式改變，您經常需要重新微調快取親和性和負載信號之間的平衡，線上訓練模型就會自動調整。

以預測延遲為準的路由運作方式

本節將詳細說明預測延遲時間型路徑轉送使用的架構和排程管道。

架構

以預測延遲時間為準的排程，會在 EPP Pod 內部署兩個額外的補充資訊容器，與 EPP 本身並列：

llm-d EPP 排程管道

啟用以預測延遲時間為準的排程後，EPP 會透過下列可組合外掛程式序列處理每項要求：

1. predicted-latency-producer：呼叫預測伺服器，根據每個 Pod 目前的 KV 快取使用率、佇列深度、前置字元快取比對分數和傳入的要求特徵，取得 InferencePool 中每個候選 Pod 的 TTFT 和 TPOT 估計值。回應傳回給用戶端後，製作人會將觀察到的 TTFT 和權杖間延遲時間傳回訓練伺服器，做為新的訓練樣本。

   • 備援行為：如果無法連線至預測伺服器或伺服器傳回錯誤，EPP 會自動改用根據 KV 快取使用率、佇列深度和前置字元快取比對結果計算的綜合分數。

2. prefix-cache-affinity-filter：當任何 Pod 的前置字元快取相符分數超過親和性門檻 (預設為 0.80) 時，這個篩選器會將候選項目集縮小至快取暖機 Pod。這個門檻會區分兩種在正式環境中觀察到的族群：一種是已從先前的輪次快取對話記錄的 Pod，另一種則否。這個篩選器會實作 epsilon-greedy 探索和開發策略：

   • 利用 (預設路徑)：這個路徑會將流量導向快取暖機 Pod，因此評分會著重於這些 Pod 的快取重複使用率。

   • 探索 (機率較小)：這個路徑會完全略過可設定比例的要求篩選器，在冷 Pod 上植入快取項目，避免快取片段化。

   • TTFT 載入閘道：即使在利用路徑上，如果最佳快取暖機 Pod 的預測 TTFT 超過最佳整體 Pod 的 TTFT，且超過可設定的門檻 (預設為 5,000 毫秒)，就會中斷親和性並使用完整候選項目集。

3. slo-headroom-tier-filter (僅限 SLO 要求)：要求包含 SLO 標頭時，會將候選 Pod 分成正向層級 (預計符合 SLO) 和負向層級 (預計違反 SLO)。

4. latency-scorer：為候選 Pod 評分。如果沒有 SLO 標頭，系統會選取預測延遲時間最短的 Pod。使用 SLO 標頭時，分數會根據預留空間 (SLO 減去預測延遲時間) 採用以下公式計算：headroomSelectionStrategy：

   • least (預設)：將項目裝入箱子。前往正向空間最小的 Pod，盡量提高使用率，並讓負載較低的 Pod 可供未來流量爆增時使用。
   • most：擴散。前往 Pod 的路徑，且有最正向的預留空間，可因應非預期的負載尖峰。

5. latency-slo-admitter (僅限服務等級目標要求)：如果預測沒有候選 Pod 能達到服務等級目標，則拒絕可卸除的要求 (優先順序小於 0)，而不是在預測會錯過目標的要求上耗用容量。如果沒有服務水準目標標頭，或有符合服務水準目標的 Pod，這項篩選條件就不會生效。

6. weighted-random-picker：使用加權隨機選取方式，根據分數選取最終 Pod。這樣可分散負載，同時優先處理評分較高的 Pod。

串流模式

predicted-latency-producer 外掛程式支援兩種訓練模式，可使用 streamingMode 參數設定：

• streamingMode: false (預設值)：根據端對端 (E2E) 要求延遲時間進行訓練。如果工作負載混合使用串流和非串流回應，或只需要延遲感知型路徑，而不需要強制執行每個要求的 SLO，請使用這個模式。
• streamingMode: true：訓練個別的 TTFT 和 TPOT 模型。TTFT 會記錄在第一個串流區塊中，TPOT 則會在後續的權杖中取樣。如果工作負載完全是串流，且需要有意義的 x-slo-ttft-ms / x-slo-tpot-ms 強制執行，請使用這個模式。

事前準備

開始之前，請務必先完成下列工作：

• 啟用 Google Kubernetes Engine API。
啟用 Google Kubernetes Engine API
• 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update 指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文件中的指令。

• 視需要啟用 Compute Engine API、Network Services API 和 Model Armor API。

  前往「啟用 API 存取權」，然後按照操作說明操作。

• 確認您已部署可正常運作的 GKE Inference Gateway。請參閱「部署 GKE Inference Gateway」。

• 請確保 InferencePool 使用同質的 Pod 組合，也就是相同的 GPU 類型、模型權重和服務設定。

• 確認 GKE 叢集為 1.32.3 以上版本。

• 安裝 Helm。請參閱 Helm 安裝指南。

啟用以預測延遲時間為準的排程

下列步驟會引導您為 GKE Inference Gateway 部署作業啟用以預測延遲為準的排程。

步驟 1：安裝或升級 InferencePool，並啟用預測延遲功能

latencyPredictor.enabled=true 標記會在 EPP Pod 內部署 Training Server 和 Prediction Server Sidecar，並設定完整的排程外掛程式管道：

helm upgrade --install INFERENCE_POOL_NAME \
  --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set inferenceExtension.latencyPredictor.enabled=true \
  --version LLM_D_VERSION \
  oci://LLM_D_REGISTRY_PATH

更改下列內容：

• INFERENCE_POOL_NAME：InferencePool 的名稱，例如 vllm-llama3-8b-instruct。
• MODEL_SERVER_LABEL：用於選取模型伺服器 Pod 的標籤鍵。
• LLM_D_VERSION：要使用的 llm-d Helm 資訊套件版本。
• LLM_D_REGISTRY_PATH：llm-d OCI 登錄路徑。

步驟 2：驗證部署作業

確認 EPP Pod 正在執行，且所有 Sidecar 容器均已準備就緒：

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

EPP Pod 應會顯示所有處於「執行中」或「就緒」狀態的容器：EPP 本身、訓練伺服器，以及一或多個預測伺服器。

步驟 3：傳送基準要求

傳送標準推論要求，確認路由正常運作，再啟用 SLO 標頭：

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
 -H 'x-prediction-based-scheduling: true' \
 -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0"
 }'

更改下列內容：

• GATEWAY_IP：閘道服務的 IP 位址。
• PORT：閘道服務的通訊埠編號。
• MODEL_NAME：用於推論的模型名稱。
• PROMPT_TEXT：輸入提示。
• MAX_TOKENS：要產生的權杖數量上限。

x-prediction-based-scheduling: true 標頭會將這項要求加入預測延遲排程管道。在預測器暖機期間，EPP 會改用啟發式路徑。

步驟 4：傳送 SLO 感知要求 (選用)

如要啟用依要求強制執行的 SLO，請新增 TTFT 和 TPOT 延遲目標標頭：

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
  -H 'x-prediction-based-scheduling: true' \
  -H 'x-slo-ttft-ms: 500' \
  -H 'x-slo-tpot-ms: 50' \
  -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0",
    "stream": true
  }'

更改下列內容：

• GATEWAY_IP：閘道服務的 IP 位址。
• PORT：閘道服務的通訊埠編號。
• MODEL_NAME：用於推論的模型名稱。
• PROMPT_TEXT：輸入提示。
• MAX_TOKENS：要產生的權杖數量上限。

要求標頭：

• x-prediction-based-scheduling: true：要求加入預測延遲時間排程管道。
• x-slo-ttft-ms：可接受的「首次權杖時間」上限 (以毫秒為單位)。
• x-slo-tpot-ms：可接受的個別輸出詞元時間上限 (以毫秒為單位)。

監控預測延遲排程

啟用延遲預測器後，EPP 會透過 Cloud Monitoring 公布其他指標。

擴充預測伺服器

針對每個候選 Pod，EPP 會對每個傳入要求發出一次預測呼叫。每個 Prediction Server 執行個體可維持約 300 QPS 的預測工作。

預測伺服器執行個體數量的概略指引：

更新 latencyPredictor.predictionServerCount Helm 值，新增 Prediction Server 執行個體。

限制

• 需要同質性 InferencePool：不支援單一集區內的混合 GPU 類型、模型變體或服務設定。
• 暖機期：XGBoost 模型需要足夠的即時流量樣本，預測結果才會準確。
• 服務等級目標強制執行：強制執行只會在路由層級進行。模型伺服器不會在選取後終止超出服務等級目標的要求。
• 狀態：這項功能為預先發布版。如未經過完整測試，不建議將其用於服務水準協議要求嚴格的正式環境工作負載。

後續步驟

• 自訂 GKE Inference Gateway 設定。
• 為 GKE Inference Gateway 執行推出作業。