Vorhersagebasierte Latenzrouten mit GKE Inference Gateway verwenden

In diesem Dokument wird beschrieben, wie Sie das auf der vorhergesagten Latenz basierende Routing aktivieren und verwenden, das von llm-d im GKE Inference Gateway bereitgestellt wird. Standardmäßig leitet das GKE Inference Gateway Anfragen anhand einer Kombination aus Lastsignalen und Heuristiken für die Präfix-Cache-Affinität weiter. Beim latenzbasierten Routing werden die statischen heuristischen Gewichte durch ein XGBoost-Modell ersetzt, das kontinuierlich mit Live-Traffic trainiert wird. So können genauere Routingentscheidungen getroffen werden, wenn sich die Arbeitslastmuster ändern.

Wann sollte die latenzbasierte Routenplanung verwendet werden?

Diese Funktion ist am effektivsten, wenn die folgenden Bedingungen für Ihre Arbeitslast gelten:

• Hohe Varianz bei der Länge von Prompts und Vervollständigungen: Die Warteschlangentiefe allein ist ein schlechter Proxy für die Serverlast, wenn die Anfragedimensionen erheblich variieren. Der Latenz-Vorhersagealgorithmus berücksichtigt die tatsächlichen Kosten für das Vorabfüllen und Decodieren pro Anfrage.
• SLOs für die Latenz pro Anfrage: Wenn Ihre Anwendungen Ziele für die Zeit bis zum ersten Token (Time-to-First-Token, TTFT) oder die Zeit pro Ausgabetoken (Time-per-Output-Token, TPOT) für einzelne Anfragen angeben, setzt der Scheduler diese Ziele beim Routing durch. Dazu wird der Headroom (vorhergesagte Latenz minus SLO-Ziel) für jeden Kandidaten-Pod berechnet.
• Anfällige statische Gewichtungsoptimierung: Wenn Sie die Balance zwischen Cache-Affinität und Lastsignalen häufig neu anpassen, weil sich die Trafficmuster ändern, passt sich das online trainierte Modell automatisch an.

Funktionsweise des auf der vorhergesagten Latenz basierenden Routings

In diesem Abschnitt werden die Architektur und die Scheduling-Pipeline beschrieben, die für das latenzbasierte Routing mit Vorhersage verwendet werden.

Architektur

Beim latenzbasierten Scheduling werden zwei zusätzliche Sidecar-Container im EPP-Pod bereitgestellt, neben dem EPP selbst:

llm-d EPP scheduling pipeline

Wenn die latenzbasierte Planung aktiviert ist, verarbeitet das EPP jede Anfrage in der folgenden Reihenfolge von zusammensetzbaren Plug-ins:

1. predicted-latency-producer: Ruft den Prediction Server auf, um TTFT- und TPOT-Schätzungen für jeden Kandidaten-Pod in InferencePool abzurufen, basierend auf der aktuellen KV-Cache-Auslastung, der Warteschlangentiefe, dem Prefix-Cache-Übereinstimmungswert und den Funktionen der eingehenden Anfrage jedes Pods. Nachdem die Antwort an den Client zurückgegeben wurde, sendet der Producer die beobachtete TTFT und die Latenz zwischen den Tokens als neues Trainingsbeispiel an den Trainingsserver zurück.

   • Fallback-Verhalten: Wenn der Prediction Server nicht erreichbar ist oder einen Fehler zurückgibt, greift das EPP automatisch auf einen zusammengesetzten Wert zurück, der auf der Nutzung des KV-Cache, der Warteschlangentiefe und der Übereinstimmung des Präfix-Cache basiert.

2. prefix-cache-affinity-filter: Mit diesem Filter wird die Kandidatengruppe auf Pods mit Cache-Warm-Status eingegrenzt, wenn der Prefix-Cache-Abgleichswert eines beliebigen Pods den Affinitätsschwellenwert (Standardwert: 0,80) überschreitet. Dieser Schwellenwert trennt zwei in der Produktion beobachtete Populationen: Pods, die bereits einen Konversationsverlauf aus früheren Durchläufen im Cache haben, und Pods, die keinen haben. Dieser Filter implementiert eine Epsilon-Greedy-Strategie für Exploitation und Exploration:

   • Exploit (Standardpfad): Dieser Pfad wird zu Pods mit warmem Cache weitergeleitet, sodass die Bewertung die Cache-Wiederverwendung auf diese Pods konzentriert.

   • Erkunden (geringe Wahrscheinlichkeit): Bei diesem Pfad wird der Filter bei einem konfigurierbaren Bruchteil der Anfragen vollständig umgangen, um Cache-Einträge auf kalten Pods zu erstellen und so eine Cache-Fragmentierung zu verhindern.

   • TTFT-Lade-Gate: Selbst auf dem Exploit-Pfad wird die Affinität unterbrochen und der vollständige Kandidatensatz verwendet, wenn die vorhergesagte TTFT des besten Pods mit warmem Cache die TTFT des besten Pods insgesamt um mehr als einen konfigurierbaren Schwellenwert (Standardwert: 5.000 ms) überschreitet.

3. slo-headroom-tier-filter (nur SLO-Anfragen): Wenn die Anfrage SLO-Header enthält, werden infrage kommende Pods in eine positive Stufe (voraussichtlich wird das SLO eingehalten) und eine negative Stufe (voraussichtlich wird das SLO nicht eingehalten) unterteilt.

4. latency-scorer: bewertet infrage kommende Pods. Ohne SLO-Header wird der Pod mit der niedrigsten vorhergesagten Latenz ausgewählt. Bei SLO-Headern basiert der Score auf dem Headroom (SLO minus vorhergesagte Latenz) mit der folgenden Formel:headroomSelectionStrategy

   • least (Standard): Bin-Packing. Routen zum Pod mit dem geringsten positiven Headroom, um die Auslastung zu maximieren und weniger ausgelastete Pods für zukünftige Trafficspitzen freizuhalten.
   • most: Spread. Routen zum Pod mit dem größten positiven Headroom, um mehr Spielraum für unerwartete Lastspitzen zu lassen.

5. latency-slo-admitter (nur SLO-Anfragen): lehnt abwerfbare Anfragen (Priorität unter 0) ab, wenn kein Kandidaten-Pod das SLO voraussichtlich erfüllen kann. So wird keine Kapazität für eine Anfrage verbraucht, die das Ziel voraussichtlich nicht erreichen wird. Dieser Filter hat keine Auswirkungen, wenn keine SLO-Header vorhanden sind oder ein Pod vorhanden ist, der das SLO erfüllt.

6. weighted-random-picker: Wählt den endgültigen Pod mithilfe einer gewichteten Zufallsauswahl anhand der Punktzahlen aus. So wird die Last verteilt, während Pods mit besseren Ergebnissen weiterhin bevorzugt werden.

Streamingmodus

Das predicted-latency-producer-Plug-in unterstützt zwei Trainingsmodi, die mit dem Parameter streamingMode konfiguriert werden:

• streamingMode: false (Standard): Das Training erfolgt anhand der End-to-End-Anfragelatenz. Verwenden Sie diesen Modus, wenn Ihre Arbeitslast Streaming- und Nicht-Streaming-Antworten kombiniert oder wenn Sie nur latenzbewusstes Routing ohne SLO-Durchsetzung pro Anfrage benötigen.
• streamingMode: true: Trainiert separate TTFT- und TPOT-Modelle. TTFT wird für den ersten gestreamten Chunk aufgezeichnet. TPOT wird für nachfolgende Tokens erfasst. Verwenden Sie diesen Modus, wenn Ihre Arbeitslast vollständig auf Streaming basiert und Sie eine aussagekräftige x-slo-ttft-ms-/x-slo-tpot-ms-Durchsetzung benötigen.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

• Aktivieren Sie bei Bedarf die Compute Engine API, die Network Services API und die Model Armor API.

  Rufen Sie Zugriff auf APIs aktivieren auf und folgen Sie der Anleitung.

• Prüfen Sie, ob Sie ein funktionierendes GKE Inference Gateway-Deployment haben. Weitere Informationen finden Sie unter GKE Inference Gateway bereitstellen.

• Achten Sie darauf, dass für Ihre InferencePool eine homogene Gruppe von Pods verwendet wird – identischer GPU-Typ, identische Modellgewichte und identische Bereitstellungskonfiguration.

• Ihr GKE-Cluster muss Version 1.32.3 oder höher haben.

• Installieren Sie Helm. Weitere Informationen finden Sie im Helm-Installationsleitfaden.

Planung basierend auf der vorhergesagten Latenz aktivieren

In den folgenden Schritten wird beschrieben, wie Sie die planmäßige Ausführung auf Grundlage der vorhergesagten Latenz für Ihre GKE Inference Gateway-Bereitstellung aktivieren.

Schritt 1: InferencePool mit aktivierter vorhergesagter Latenz installieren oder aktualisieren

Mit dem Flag latencyPredictor.enabled=true werden die Sidecars für den Trainings- und den Vorhersageserver im EPP-Pod bereitgestellt und die gesamte Pipeline des Scheduling-Plug-ins wird eingerichtet:

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

Ersetzen Sie Folgendes:

• INFERENCE_POOL_NAME: Der Name Ihres InferencePool, z. B. vllm-llama3-8b-instruct.
• MODEL_SERVER_LABEL: Der Labelschlüssel, der zum Auswählen der Pods Ihres Modellservers verwendet wird.
• LLM_D_VERSION: Die zu verwendende llm-d-Helm-Chart-Version.
• LLM_D_REGISTRY_PATH: Der OCI-Registrierungspfad für llm-d.

Schritt 2: Deployment überprüfen

Prüfen Sie, ob der EPP-Pod ausgeführt wird und alle Sidecar-Container bereit sind:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

Im EPP-Pod sollten alle Container den Status „Running“ (Wird ausgeführt) oder „Ready“ (Bereit) haben: der EPP selbst, der Trainingsserver und mindestens ein Vorhersageserver.

Schritt 3: Baseline-Anfrage senden

Senden Sie eine Standardanfrage für die Inferenz, um zu bestätigen, dass das Routing funktioniert, bevor Sie SLO-Header aktivieren:

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"
 }'

Ersetzen Sie Folgendes:

• GATEWAY_IP: die IP-Adresse Ihres Gateway-Dienstes.
• PORT: die Portnummer Ihres Gatewayservices.
• MODEL_NAME: Der Name des Modells, das für die Inferenz verwendet werden soll.
• PROMPT_TEXT: Die Eingabeaufforderung.
• MAX_TOKENS: Die maximale Anzahl der zu generierenden Tokens.

Mit dem Header x-prediction-based-scheduling: true wird diese Anfrage in die Pipeline für die Planung der vorhergesagten Latenz aufgenommen. Während der Warm-up-Phase des Predictors wird für die EPP auf heuristisches Routing zurückgegriffen.

Schritt 4: SLO-basierte Anfragen senden (optional)

Wenn Sie die SLO-Durchsetzung pro Anfrage aktivieren möchten, fügen Sie die folgenden Header für die Latenzziele für TTFT und TPOT hinzu:

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
  }'

Ersetzen Sie Folgendes:

• GATEWAY_IP: die IP-Adresse Ihres Gateway-Dienstes.
• PORT: die Portnummer Ihres Gatewayservices.
• MODEL_NAME: Der Name des Modells, das für die Inferenz verwendet werden soll.
• PROMPT_TEXT: Die Eingabeaufforderung.
• MAX_TOKENS: Die maximale Anzahl der zu generierenden Tokens.

Anfrageheader:

• x-prediction-based-scheduling: true: Aktiviert die Anfrage für die Pipeline zur Planung der vorhergesagten Latenz.
• x-slo-ttft-ms: Die maximal zulässige Zeit bis zum ersten Token in Millisekunden.
• x-slo-tpot-ms: Die maximal zulässige Zeit pro Ausgabetoken in Millisekunden.

Planung der vorhergesagten Latenz überwachen

Wenn die Latenzvorhersage aktiviert ist, werden über Cloud Monitoring zusätzliche Messwerte für die EPP bereitgestellt.

Vorhersageserver skalieren

Das EPP führt pro Kandidaten-Pod und eingehender Anfrage einen Vorhersageaufruf aus. Jede Prediction Server-Instanz kann ungefähr 300 QPS an Vorhersagearbeit bewältigen.

Ungefähre Richtwerte für die Anzahl der Prediction Server-Instanzen:

Fügen Sie Prediction Server-Instanzen hinzu, indem Sie den Helm-Wert latencyPredictor.predictionServerCount aktualisieren.

Beschränkungen

• Homogene InferencePool erforderlich: Gemischte GPU-Typen, Modellvarianten oder Bereitstellungskonfigurationen in einem einzelnen Pool werden nicht unterstützt.
• Aufwärmphase: Das XGBoost-Modell benötigt genügend Live-Traffic-Stichproben, bevor die Vorhersagen genau werden.
• SLO-Durchsetzung: Die Durchsetzung erfolgt nur auf der Routing-Ebene. Der Modellserver beendet Anfragen, die das SLO-Ziel überschreiten, nicht nach der Auswahl.
• Status: Dieses Feature befindet sich in der Vorschau. Es wird nicht für Produktionsarbeitslasten mit strengen SLA-Anforderungen ohne gründliche Tests empfohlen.

Nächste Schritte

• GKE Inference Gateway-Konfiguration anpassen
• Rollout-Vorgänge für das GKE Inference Gateway ausführen