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

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

預測延遲路徑的適用時機

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

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

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

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

架構

以預測延遲時間為準的排程會在 EPP Pod 內，與 EPP 本身一起部署兩個額外的 Sidecar 容器：

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，以及未快取對話記錄的 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 (僅限 SLO 要求)：如果預測沒有候選 Pod 能達到 SLO，則拒絕可卸除的要求 (優先順序低於 0)，而不是耗用容量來處理預測會錯過目標的要求。如果沒有 SLO 標頭，或是有符合 SLO 的 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 值，新增預測伺服器執行個體。

限制

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

後續步驟

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