Utiliser le routage basé sur la latence prédite avec GKE Inference Gateway

Ce document explique comment activer et utiliser le routage basé sur la latence prédite fourni par llm-d dans GKE Inference Gateway. Par défaut, GKE Inference Gateway achemine les requêtes à l'aide d'une combinaison de signaux de charge et d'heuristiques d'affinité de cache de préfixe. Le routage basé sur la latence prédite remplace les pondérations heuristiques statiques par un modèle XGBoost entraîné en continu sur le trafic en direct. Il permet de prendre des décisions de routage plus précises à mesure que les schémas de charge de travail évoluent.

Quand utiliser le routage basé sur la latence prévue ?

Cette fonctionnalité est plus efficace lorsque les conditions suivantes s'appliquent à votre charge de travail :

  • Forte variance dans la longueur des requêtes et des réponses : la profondeur de la file d'attente seule est un mauvais indicateur de la charge du serveur lorsque la taille des requêtes varie considérablement. Le prédicteur de latence tient compte du coût réel de préremplissage et de décodage par requête.
  • SLO de latence par requête : lorsque vos applications spécifient des cibles de délai d'émission du premier jeton (TTFT) ou de délai par jeton de sortie (TPOT) sur des requêtes individuelles, le planificateur applique ces cibles lors du routage. Pour ce faire, il calcule la marge (latence prévue moins l'objectif de SLO) pour chaque pod candidat.
  • Réglage fragile du poids statique : si vous réglez fréquemment l'équilibre entre l'affinité du cache et les signaux de charge lorsque les schémas de trafic changent, le modèle entraîné en ligne s'adapte automatiquement.

Fonctionnement du routage basé sur la latence prédite

Cette section décrit en détail l'architecture et le pipeline de planification utilisés par le routage basé sur la latence prévue.

Architecture

La planification basée sur la latence prédite déploie deux conteneurs side-car supplémentaires dans le pod EPP, en plus de l'EPP lui-même :

Composant Description
Serveur d'entraînement Réentraîne en continu les modèles XGBoost TTFT et TPOT sur les exemples de requêtes terminées reçus de l'EPP. Utilise le bucketing stratifié sur une fenêtre glissante pour ne pas oublier les régimes de trafic rares. Écrit les modèles mis à jour dans un volume partagé.
Serveurs de prédiction Fournissez des prédictions TTFT et TPOT à l'EPP sur le chemin d'accès rapide des requêtes. Lisez le dernier modèle entraîné à partir du volume partagé. Évolutivité horizontale : chaque instance de serveur peut traiter environ 300 RPS de prédiction. Plusieurs instances sont équilibrées par un proxy de fusion Go dans l'EPP, qui regroupe les requêtes de prédiction simultanées dans une fenêtre de 1 ms.

Pipeline de planification EPP llm-d

Lorsque la planification basée sur la latence prédite est activée, l'EPP traite chaque requête selon la séquence de plug-ins composables suivante :

  1. predicted-latency-producer : appelle le serveur de prédiction pour obtenir des estimations TTFT et TPOT pour chaque pod candidat dans InferencePool, en fonction de l'utilisation actuelle du cache KV, de la profondeur de la file d'attente, du score de correspondance du cache de préfixes et des caractéristiques de la requête entrante de chaque pod. Une fois la réponse renvoyée au client, le producteur renvoie la latence TTFT et la latence entre les jetons observées au serveur d'entraînement en tant que nouvel exemple d'entraînement.

    • Comportement de secours : si le serveur de prédiction est inaccessible ou renvoie une erreur, l'EPP revient automatiquement à un score composite basé sur l'utilisation du cache KV, la profondeur de la file d'attente et la correspondance du cache de préfixes.

  2. prefix-cache-affinity-filter : ce filtre réduit l'ensemble de candidats aux pods de préchauffage du cache lorsque le score de correspondance du préfixe d'un pod dépasse le seuil d'affinité (0,80 par défaut). Ce seuil sépare deux populations observées en production : les pods qui ont déjà un historique de conversation mis en cache à partir des tours précédents et ceux qui n'en ont pas. Ce filtre implémente une stratégie d'exploration et d'exploitation epsilon-greedy :

    • Exploit (chemin par défaut) : ce chemin d'accès est associé aux pods de préchauffage du cache afin que la notation concentre la réutilisation du cache sur ces pods.

    • Explorer (faible probabilité) : ce chemin d'accès contourne entièrement le filtre sur une fraction configurable de requêtes pour amorcer les entrées de cache sur les pods froids afin d'éviter la fragmentation du cache.

    • Seuil de chargement TTFT : même sur le chemin d'exploitation, si le TTFT prédit du Pod le mieux préchauffé dépasse le TTFT du meilleur Pod global de plus d'un seuil configurable (5 000 ms par défaut), l'affinité est rompue et l'ensemble complet de candidats est utilisé.

  3. slo-headroom-tier-filter (requêtes SLO uniquement) : lorsque la requête inclut des en-têtes SLO, divise les pods candidats en un niveau positif (prévu pour respecter le SLO) et un niveau négatif (prévu pour le violer).

  4. latency-scorer : évalue les pods candidats. Sans en-têtes SLO, le pod avec la latence prédite la plus faible est sélectionné. Avec les en-têtes SLO, le score est basé sur la marge (SLO moins la latence prévue) à l'aide de headroomSelectionStrategy :

    • least (par défaut) : bin-pack. Les routes vers le pod avec la marge positive la plus faible, ce qui maximise l'utilisation et permet de libérer les pods moins chargés pour les futurs pics de trafic.
    • most : écart. Les routes vers le pod avec la marge positive la plus élevée, ce qui laisse plus de marge pour les pics de charge inattendus.

  5. latency-slo-admitter (requêtes SLO uniquement) : rejette les requêtes réductibles (priorité inférieure à 0) lorsqu'aucun pod candidat n'est censé répondre au SLO, au lieu de consommer de la capacité sur une requête qui ne devrait pas atteindre sa cible. Ce filtre n'a aucun effet lorsque les en-têtes SLO sont absents ou lorsqu'un pod répond au SLO.

  6. weighted-random-picker : sélectionne le pod final à l'aide d'une sélection aléatoire pondérée sur les scores. Cela répartit la charge tout en favorisant les pods ayant obtenu de meilleurs scores.

Mode de traitement en flux continu

Le plug-in predicted-latency-producer est compatible avec deux modes d'entraînement, configurés à l'aide du paramètre streamingMode :

  • streamingMode: false (par défaut) : entraîne sur la latence des requêtes de bout en bout. Utilisez ce mode si votre charge de travail mélange des réponses par flux et des réponses sans flux, ou si vous n'avez besoin que d'un routage tenant compte de la latence sans application de SLO par requête.
  • streamingMode: true : entraîne des modèles TTFT et TPOT distincts. Le TTFT est enregistré sur le premier bloc diffusé, tandis que le TPOT est échantillonné sur les jetons suivants. Utilisez ce mode si votre charge de travail est entièrement en streaming et que vous avez besoin d'une application significative de x-slo-ttft-ms / x-slo-tpot-ms.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Activez l'API Compute Engine, l'API Network Services et l'API Model Armor si nécessaire.

    Accédez à Activer l'accès aux API et suivez les instructions.

  • Assurez-vous de disposer d'un déploiement GKE Inference Gateway opérationnel. Consultez Déployer GKE Inference Gateway.

  • Assurez-vous que votre InferencePool utilise un ensemble homogène de pods (type de GPU, pondérations de modèle et configuration de diffusion identiques).

  • Assurez-vous que votre cluster GKE est de version 1.32.3 ou ultérieure.

  • Installez Helm. Consultez le guide d'installation de Helm.

Activer la planification basée sur la latence prévue

Les étapes suivantes vous guident pour activer la planification basée sur la latence prédite pour votre déploiement GKE Inference Gateway.

Étape 1 : Installez ou mettez à niveau InferencePool avec la latence prédite activée

L'indicateur latencyPredictor.enabled=true déploie les sidecars Training Server et Prediction Server dans le pod EPP et connecte l'intégralité du pipeline du plug-in de planification :

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

Remplacez les éléments suivants :

  • INFERENCE_POOL_NAME : nom de votre InferencePool, par exemple vllm-llama3-8b-instruct.
  • MODEL_SERVER_LABEL : clé d'étiquette utilisée pour sélectionner vos pods de serveur de modèle.
  • LLM_D_VERSION : version du chart Helm llm-d à utiliser.
  • LLM_D_REGISTRY_PATH : chemin d'accès au registre OCI llm-d.

Étape 2 : Vérifiez le déploiement

Vérifiez que le pod EPP est en cours d'exécution et que tous les conteneurs side-car sont prêts :

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

Le pod EPP doit afficher tous les conteneurs à l'état "Running" (En cours d'exécution) ou "Ready" (Prêt) : l'EPP lui-même, le serveur d'entraînement et un ou plusieurs serveurs de prédiction.

Étape 3 : Envoyez une demande de référence

Envoyez une requête d'inférence standard pour confirmer que le routage fonctionne avant d'activer les en-têtes 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"
 }'

Remplacez les éléments suivants :

  • GATEWAY_IP : adresse IP de votre service de passerelle.
  • PORT : numéro de port de votre service de passerelle.
  • MODEL_NAME : nom du modèle à utiliser pour l'inférence.
  • PROMPT_TEXT : requête d'entrée.
  • MAX_TOKENS : nombre maximal de jetons à générer.

L'en-tête x-prediction-based-scheduling: true permet d'inclure cette requête dans le pipeline de planification de la latence prédite. Pendant la période de préchauffage du prédicteur, l'EPP revient au routage heuristique.

Étape 4 : Envoyez des requêtes tenant compte des SLO (facultatif)

Pour activer l'application des SLO par requête, ajoutez les en-têtes d'objectif de latence TTFT et 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
  }'

Remplacez les éléments suivants :

  • GATEWAY_IP : adresse IP de votre service de passerelle.
  • PORT : numéro de port de votre service de passerelle.
  • MODEL_NAME : nom du modèle à utiliser pour l'inférence.
  • PROMPT_TEXT : requête d'entrée.
  • MAX_TOKENS : nombre maximal de jetons à générer.

En-têtes de requête :

  • x-prediction-based-scheduling: true : active le pipeline de planification de la latence prédite pour la requête.
  • x-slo-ttft-ms : temps de latence du premier jeton maximal acceptable, en millisecondes.
  • x-slo-tpot-ms : délai maximal acceptable par jeton de sortie, en millisecondes.

Surveiller la planification de la latence prédite

Lorsque le prédicteur de latence est activé, l'EPP expose des métriques supplémentaires via Cloud Monitoring.

Métrique Description
inference_objective_request_ttft_seconds Distribution réelle du TTFT (ou latence de bout en bout si streamingMode=false).
inference_objective_request_predicted_ttft_seconds Distribution du TTFT prédit (ou latence de bout en bout si streamingMode=false).
inference_objective_request_tpot_seconds Distribution réelle de TPOT.
inference_objective_request_predicted_tpot_seconds Distribution TPOT prédite.
inference_objective_request_ttft_slo_violation_total Compteur des violations du SLO TTFT.

Mise à l'échelle du serveur de prédiction

L'EPP effectue un appel de prédiction par pod candidat et par requête entrante. Chaque instance de serveur de prédiction peut traiter environ 300 RPS.

Voici des conseils approximatifs concernant le nombre d'instances de serveur de prédiction :

RPS du cluster (100 pods) Serveurs de prédiction requis
Jusqu'à 1 000 RPS 1 serveur
Jusqu'à 5 000 RPS 2 serveurs
Jusqu'à 10 000 RPS 4 serveurs

Ajoutez des instances Prediction Server en mettant à jour la valeur Helm latencyPredictor.predictionServerCount.

Limites

  • InferencePool homogène requis : les types de GPU, les variantes de modèles ou les configurations de diffusion mixtes au sein d'un même pool ne sont pas acceptés.
  • Période d'échauffement : le modèle XGBoost a besoin d'un nombre suffisant d'échantillons de trafic réel avant que les prédictions ne deviennent précises.
  • Application du SLO : l'application se fait uniquement au niveau de la couche de routage. Le serveur de modèle ne met pas fin aux requêtes qui dépassent l'objectif de SLO après la sélection.
  • État : cette fonctionnalité est disponible en version preview. Son utilisation n'est pas recommandée pour les charges de travail de production avec des exigences strictes en termes de SLA sans tests approfondis.

Étapes suivantes