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 Weiterleitung 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 Tiefe der Warteschlange allein ist ein schlechter Proxy für die Serverlast, wenn die Anfragengrößen 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 in Ihren Anwendungen TTFT- (Time-to-First-Token) oder TPOT-Ziele (Time-per-Output-Token) für einzelne Anfragen angegeben werden, setzt der Scheduler diese Ziele beim Routing durch. Dazu wird der Headroom (prognostizierte Latenz minus SLO-Ziel) für jeden Kandidaten-Pod berechnet.
  • Feinabstimmung des statischen Gewichts: Wenn Sie die Balance zwischen Cache-Affinität und Lastsignalen häufig neu abstimmen, weil sich die Traffic-Muster ändern, passt sich das online trainierte Modell automatisch an.

Funktionsweise des latenzbasierten Routings mit Vorhersagen

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

Architektur

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

Komponente Beschreibung
Trainingsserver Die XGBoost-Modelle für TTFT und TPOT werden kontinuierlich mit abgeschlossenen Anfragebeispielen neu trainiert, die vom EPP empfangen werden. Verwendet die geschichtete Aufteilung in Buckets über ein gleitendes Fenster, damit seltene Traffic-Regimes nicht vergessen werden. Schreibt aktualisierte Modelle in ein freigegebenes Volume.
Vorhersageserver TTFT- und TPOT-Vorhersagen für den EPP auf dem Hot Path der Anfrage bereitstellen. Das zuletzt trainierte Modell aus dem freigegebenen Volume lesen. Horizontal skalierbar: Jede Serverinstanz kann etwa 300 Abfragen pro Sekunde für Vorhersageaufgaben verarbeiten. Mehrere Instanzen werden durch einen Go-Coalescing-Proxy im EPP mit Load-Balancing versehen, der gleichzeitige Vorhersageanfragen innerhalb eines 1-ms-Fensters in Batches zusammenfasst.

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 eingehenden Anforderungs-Features 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 EPP automatisch auf einen zusammengesetzten Wert zurück, der auf der Nutzung des KV-Cache, der Warteschlangentiefe und dem Prefix-Cache-Abgleich 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 Pods den Affinitätsschwellenwert (Standardwert: 0,80) überschreitet. Dieser Grenzwert 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.

    • Explore (geringe Wahrscheinlichkeit): Bei einem konfigurierbaren Teil der Anfragen wird der Filter vollständig umgangen, um Cacheeinträge auf kalten Pods zu erstellen und so eine Cachefragmentierung 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 Cache-warm-Pods die TTFT des besten Gesamt-Pods 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 infrage kommenden 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 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 Traffic-Spitzen 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 löschbare Anfragen (Priorität unter 0) ab, wenn kein Kandidaten-Pod das SLO voraussichtlich erfüllen wird, anstatt Kapazität für eine Anfrage zu verbrauchen, die das Ziel voraussichtlich nicht erreichen wird. 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: Der endgültige Pod wird durch gewichtete zufällige Auswahl anhand der Punktzahlen ausgewählt. 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 Modell wird anhand der End-to-End-Anfragelatenz trainiert. 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 gestreamt wird und Sie eine aussagekräftige x-slo-ttft-ms- und 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 diese Aufgabe 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 in der Helm-Installationsanleitung.

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 Trainingsserver 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 Version des Helm-Charts „llm-d“.
  • LLM_D_REGISTRY_PATH: der OCI-Registrierungspfad für 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

Im EPP-Pod sollten alle Container im Status „Running“ oder „Ready“ angezeigt werden: 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 Gateways.
  • 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 mit vorhergesagter Latenz aufgenommen. Während der Warm-up-Phase des Vorhersagemodells 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 Latenzziel-Header 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 Gateways.
  • 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: maximal akzeptable Time-to-First-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, stellt EPP zusätzliche Messwerte über Cloud Monitoring bereit.

Messwert Beschreibung
inference_objective_request_ttft_seconds Tatsächliche TTFT-Verteilung (oder E2E-Latenz, wenn „streamingMode“ = „false“).
inference_objective_request_predicted_ttft_seconds Die vorhergesagte TTFT-Verteilung (oder E2E-Latenz, wenn „streamingMode“ auf „false“ gesetzt ist).
inference_objective_request_tpot_seconds Tatsächliche TPOT-Verteilung.
inference_objective_request_predicted_tpot_seconds Prognostizierte TPOT-Verteilung.
inference_objective_request_ttft_slo_violation_total Zähler für SLO-Verstöße bei der Zeit bis zum ersten Token.

Vorhersageserver skalieren

Das EPP führt pro Kandidaten-Pod und eingehender Anfrage einen Vorhersageaufruf aus. Jede Prediction Server-Instanz kann etwa 300 Vorhersageanfragen pro Sekunde verarbeiten.

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

Cluster-QPS (100 Pods) Prognoseserver erforderlich
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 Instanzen des Vorhersageservers 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 ausreichend 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. Für Produktionsarbeitslasten mit strengen SLA-Anforderungen wird es ohne gründliche Tests nicht empfohlen.

Nächste Schritte