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 mithilfe einer Kombination aus Lastsignalen und Heuristiken zur Präfix-Cache-Affinität weiter. Beim auf der vorhergesagten Latenz basierenden Routing werden die statischen heuristischen Gewichtungen 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 das auf der vorhergesagten Latenz basierende Routing verwendet werden?

Diese Funktion ist am effektivsten, wenn die folgenden Bedingungen auf Ihre Arbeitslast zutreffen:

  • Hohe Varianz bei der Länge von Prompts und Vervollständigungen: Die Warteschlangentiefe allein ist ein schlechter Proxy für die Serverlast, wenn die Anfragengrößen erheblich variieren. Der Latenzvorhersager berücksichtigt die tatsächlichen Kosten für das Vorfü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, erzwingt der Scheduler diese Ziele während des Routings. Dazu wird der Spielraum (vorhergesagte Latenz minus SLO-Ziel) für jeden Kandidaten-Pod berechnet.
  • Fragile statische Gewichtungsabstimmung: Wenn Sie die Balance zwischen Cache-Affinität und Lastsignalen häufig neu abstimmen, wenn 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 Planungspipeline beschrieben, die beim auf der vorhergesagten Latenz basierenden Routing verwendet werden.

Architektur

Beim auf der vorhergesagten Latenz basierenden Routing werden zwei zusätzliche Sidecar-Container im EPP-Pod neben dem EPP selbst bereitgestellt:

Komponente Beschreibung
Trainingsserver Trainiert die XGBoost-Modelle für TTFT und TPOT kontinuierlich mit abgeschlossenen Anfragemustern, die vom EPP empfangen wurden. Verwendet eine geschichtete Bucket-Methode für ein gleitendes Fenster, damit seltene Trafficregime nicht vergessen werden. Schreibt aktualisierte Modelle in ein freigegebenes Volume.
Vorhersageserver Liefern TTFT- und TPOT-Vorhersagen für den EPP auf dem Hot Path der Anfrage. Lesen das zuletzt trainierte Modell aus dem freigegebenen Volume. Horizontal skalierbar: Jede Serverinstanz kann ungefähr 300 Abfragen pro Sekunde für Vorhersagen verarbeiten. Mehrere Instanzen werden von einem Go-Coalescing-Proxy im EPP mit Load-Balancing versehen, der gleichzeitige Vorhersageanfragen innerhalb eines 1-ms-Fensters zusammenfasst.

llm-d-EPP-Planungspipeline

Wenn die auf der vorhergesagten Latenz basierende Planung aktiviert ist, verarbeitet der EPP jede Anfrage mit der folgenden Sequenz zusammensetzbarer Plug-ins:

  1. predicted-latency-producer: Ruft den Vorhersageserver auf, um TTFT- und TPOT-Schätzungen für jeden Kandidaten-Pod im InferencePool abzurufen. Dabei werden die aktuelle KV-Cache-Auslastung, die Warteschlangentiefe, der Übereinstimmungswert des Präfix-Cache und die Merkmale der eingehenden Anfrage für jeden Pod berücksichtigt. Nachdem die Antwort an den Client zurückgegeben wurde, sendet der Producer die beobachtete TTFT und die Latenz zwischen den Tokens als neues Trainingsmuster an den Trainingsserver zurück.

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

  2. prefix-cache-affinity-filter: Dieser Filter beschränkt die Kandidaten auf Pods mit Cache-Warm-Status, wenn der Übereinstimmungswert des Präfix-Cache eines Pods den Affinitätsschwellenwert (Standardwert: 0,80) überschreitet. Dieser Schwellenwert trennt zwei in der Produktion beobachtete Populationen: Pods, für die bereits ein Unterhaltungsverlauf aus früheren Runden im Cache gespeichert ist, und Pods, für die das nicht der Fall ist. Dieser Filter implementiert eine Epsilon-Greedy-Strategie für Exploit und Explore:

    • Exploit (Standardpfad): Dieser Pfad leitet Anfragen an Pods mit Cache-Warm-Status weiter, sodass die Bewertung die Cache-Wiederverwendung auf diese Pods konzentriert.

    • Explore (geringe Wahrscheinlichkeit): Dieser Pfad umgeht den Filter für einen konfigurierbaren Teil der Anfragen vollständig , um Cache-Einträge auf kalten Pods zu erstellen und so eine Cache-Fragmentierung zu verhindern.

    • TTFT-Lastbegrenzung: Selbst auf dem Exploit-Pfad wird die Affinität unterbrochen und der vollständige Kandidatensatz verwendet, wenn die vorhergesagte TTFT des besten Pods mit Cache-Warm-Status 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 die Kandidaten-Pods in eine positive Ebene (voraussichtlich wird das SLO erfüllt) und eine negative Ebene (voraussichtlich wird das SLO verletzt) aufgeteilt.

  4. latency-scorer: Bewertet Kandidaten-Pods. Ohne SLO-Header wird der Pod mit der niedrigsten vorhergesagten Latenz ausgewählt. Mit SLO-Headern basiert der Wert auf dem Spielraum (SLO minus vorhergesagte Latenz) und verwendet die headroomSelectionStrategy:

    • least (Standard): Bin-Pack. Leitet Anfragen an den Pod mit dem kleinsten positiven Spielraum weiter, maximiert die Auslastung und hält weniger ausgelastete Pods für zukünftige Trafficspitzen kostenlos.
    • most: Spread. Leitet Anfragen an den Pod mit dem größten positiven Spielraum weiter, sodass mehr Spielraum für unerwartete Lastspitzen bleibt.

  5. latency-slo-admitter (nur SLO-Anfragen): Lehnt Anfragen ab, die verworfen werden können (Priorität kleiner als 0), wenn voraussichtlich kein Kandidaten-Pod das SLO erfüllt. So wird keine Kapazität für eine Anfrage verbraucht, die voraussichtlich ihr Ziel verfehlt. Dieser Filter hat keine Auswirkungen, wenn keine SLO-Header vorhanden sind oder wenn 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 Werte aus. So wird die Last verteilt, während Pods mit besseren Werten weiterhin bevorzugt werden.

Streamingmodus

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

  • streamingMode: false (Standard): Trainiert mit der End-to-End-Latenz (E2E) der Anfrage. Verwenden Sie diesen Modus, wenn Ihre Arbeitslast Streaming- und Nicht-Streaming-Antworten kombiniert oder wenn Sie nur ein latenzbewusstes Routing ohne SLO-Erzwingung 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 sinnvolle Erzwingung von x-slo-ttft-ms / x-slo-tpot-ms 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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

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

    Folgen Sie der Anleitung unter Zugriff auf APIs aktivieren.

  • Achten Sie darauf, dass Sie eine funktionierende GKE Inference Gateway-Bereitstellung haben. Weitere Informationen finden Sie unter GKE Inference Gateway bereitstellen.

  • Achten Sie darauf, dass Ihr InferencePool eine homogene Gruppe von Pods verwendet – identischer GPU-Typ, identische Modellgewichtungen und identische Bereitstellungskonfiguration.

  • Achten Sie darauf, dass Ihr GKE-Cluster Version 1.32.3 oder höher hat.

  • Installieren Sie Helm. Weitere Informationen finden Sie in der Helm-Installations anleitung.

Auf der vorhergesagten Latenz basierende Planung aktivieren

Die folgenden Schritte führen Sie durch die Aktivierung der auf der vorhergesagten Latenz basierenden Planung für Ihre GKE Inference Gateway-Bereitstellung.

Schritt 1: InferencePool mit aktivierter vorhergesagter Latenz installieren oder aktualisieren

Mit dem Flag latencyPredictor.enabled=true werden die Sidecars für den Trainingsserver und den Vorhersageserver im EPP-Pod bereitgestellt und die vollständige Pipeline für das Planungspug-in 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 Ihrer Modellserver-Pods verwendet wird.
  • LLM_D_VERSION: Die zu verwendende Helm-Chart-Version von llm-d.
  • LLM_D_REGISTRY_PATH: Der OCI-Registrierungspfad von llm-d.

Schritt 2: Bereitstellung ü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

Für den EPP-Pod sollten alle Container den Status „Wird ausgeführt“ oder „Bereit“ haben: der EPP selbst, der Trainingsserver und ein oder mehrere Vorhersageserver.

Schritt 3: Baseline-Anfrage senden

Senden Sie eine Standardvorhersageanfrage, um zu prüfen, ob 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 Gateway-Dienstes.
  • MODEL_NAME: Der Name des Modells, das für die Vorhersage verwendet werden soll.
  • PROMPT_TEXT: Der Eingabe-Prompt.
  • MAX_TOKENS: Die maximale Anzahl der zu generierenden Tokens.

Der Header x-prediction-based-scheduling: true fügt diese Anfrage der Planungspipeline für die vorhergesagte Latenz hinzu. Während der Warm-up-Phase des Vorhersagers greift der EPP auf das heuristische Routing zurück.

Schritt 4: SLO-bezogene Anfragen senden (optional)

Wenn Sie die SLO-Erzwingung pro Anfrage aktivieren möchten, fügen Sie Header für die TTFT- und TPOT-Latenzziele 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 Gateway-Dienstes.
  • MODEL_NAME: Der Name des Modells, das für die Vorhersage verwendet werden soll.
  • PROMPT_TEXT: Der Eingabe-Prompt.
  • MAX_TOKENS: Die maximale Anzahl der zu generierenden Tokens.

Anfrageheader:

  • x-prediction-based-scheduling: true: Fügt die Anfrage der Planungspipeline für die vorhergesagte Latenz hinzu.
  • x-slo-ttft-ms: Die maximal akzeptable Zeit bis zum ersten Token in Millisekunden.
  • x-slo-tpot-ms: Die maximal akzeptable Zeit pro Ausgabetoken in Millisekunden.

Auf der vorhergesagten Latenz basierende Planung überwachen

Wenn der Latenzvorhersager aktiviert ist, stellt der EPP zusätzliche Messwerte über Cloud Monitoring zur Verfügung.

Messwert Beschreibung
inference_objective_request_ttft_seconds Tatsächliche TTFT-Verteilung (oder E2E-Latenz, wenn streamingMode=false).
inference_objective_request_predicted_ttft_seconds Vorhergesagte TTFT-Verteilung (oder E2E-Latenz, wenn streamingMode=false).
inference_objective_request_tpot_seconds Tatsächliche TPOT-Verteilung.
inference_objective_request_predicted_tpot_seconds Vorhergesagte TPOT-Verteilung.
inference_objective_request_ttft_slo_violation_total Zähler für TTFT-SLO-Verstöße.

Vorhersageserver skalieren

Der EPP führt für jeden Kandidaten-Pod pro eingehender Anfrage einen Vorhersageaufruf aus. Jede Vorhersageserverinstanz kann ungefähr 300 Abfragen pro Sekunde für Vorhersagen verarbeiten.

Ungefähre Richtwerte für die Anzahl der Vorhersageserverinstanzen:

Cluster-Abfragen pro Sekunde (100 Pods) Erforderliche Vorhersageserver
Bis zu 1.000 Abfragen pro Sekunde 1 Server
Bis zu 5.000 Abfragen pro Sekunde 2 Server
Bis zu 10.000 Abfragen pro Sekunde 4 Server

Fügen Sie Vorhersageserverinstanzen hinzu, indem Sie den Helm-Wert latencyPredictor.predictionServerCount aktualisieren.

Beschränkungen

  • Homogener InferencePool erforderlich: Gemischte GPU-Typen, Modellvarianten, oder Bereitstellungskonfigurationen in einem einzelnen Pool werden nicht unterstützt.
  • Aufwärmphase: Das XGBoost-Modell benötigt ausreichend Live-Traffic-Muster, bevor Vorhersagen genau werden.
  • SLO-Erzwingung: Die Erzwingung erfolgt nur auf Routingebene. Der Modellserver beendet keine Anfragen, die das SLO-Ziel überschreiten, nachdem sie ausgewählt wurden.
  • Status: Diese Funktion befindet sich in der Vorschau. Sie wird für Produktionsarbeitslasten mit strengen SLA-Anforderungen ohne gründliche Tests nicht empfohlen.

Nächste Schritte