À propos de GKE Inference Gateway optimisé par llm-d

Cette page présente les concepts et les fonctionnalités clés de Google Kubernetes Engine (GKE) Inference Gateway, une extension de GKE Gateway qui permet de mettre en service de manière optimisée des applications d'IA générative.

Cette page suppose que vous connaissez les éléments suivants :

Cette page s'adresse aux profils suivants :

  • Ingénieurs en machine learning (ML), administrateurs et opérateurs de plate-forme, et spécialistes des données et de l'IA qui souhaitent utiliser les fonctionnalités d'orchestration de conteneurs Kubernetes pour mettre en service des charges de travail d'IA/ML.
  • Architectes cloud et spécialistes de la mise en réseau qui interagissent avec la mise en réseau Kubernetes.

Présentation

GKE Inference Gateway est une extension de GKE Gateway qui fournit un routage et un équilibrage de charge optimisés pour la mise en service de charges de travail d'intelligence artificielle (IA) générative. Elle simplifie le déploiement, la gestion et l'observabilité des charges de travail d'inférence d'IA.

Pour choisir la stratégie d'équilibrage de charge optimale pour vos charges de travail d'IA/ML, consultez Choisir une stratégie d'équilibrage de charge pour l'inférence d'IA sur GKE.

Fonctionnalités et avantages

GKE Inference Gateway fournit les fonctionnalités clés suivantes pour mettre en service efficacement des modèles d'IA générative pour les applications d'IA générative sur GKE :

  • Métriques compatibles:
    • KV cache hits: nombre de recherches réussies dans le cache de paires clé-valeur (KV).
    • Utilisation du GPU ou du TPU : pourcentage de temps pendant lequel le GPU ou le TPU traite activement les données.
    • Longueur de la file d'attente des requêtes : nombre de requêtes en attente de traitement.
  • Équilibrage de charge optimisé pour l'inférence : distribue les requêtes afin d'optimiser les performances de mise en service des modèles d'IA. Il utilise des métriques provenant des serveurs de modèles, telles que KV cache hits et la queue length of pending requests, pour consommer plus efficacement les accélérateurs (tels que les GPU et les TPU) pour les charges de travail d'IA générative. Cela permet d'activer le routage tenant compte du cache de préfixes, une fonctionnalité clé qui envoie les requêtes avec un contexte partagé, identifié en analysant le corps de la requête, à la même réplique de modèle en maximisant les accès au cache. Cette approche réduit considérablement les calculs redondants et améliore le délai d'émission du premier jeton, ce qui la rend très efficace pour l'IA conversationnelle, la génération augmentée par récupération (RAG) et d'autres charges de travail d'IA générative basées sur des modèles.
  • Mise en service dynamique de modèles affinés LoRA : permet de mettre en service des modèles affinés LoRA dynamiques sur un accélérateur commun. Cela réduit le nombre de GPU et de TPU nécessaires pour mettre en service des modèles en multiplexant plusieurs modèles affinés LoRA sur un modèle de base et un accélérateur communs.
  • Autoscaling optimisé pour l'inférence : l'autoscaler horizontal de pods (AHP) GKE utilise des métriques de serveur de modèles pour effectuer un autoscaling, ce qui permet d'assurer une utilisation efficace des ressources de calcul et des performances d'inférence optimisées.
  • Routage tenant compte des modèles : achemine les requêtes d'inférence en fonction des noms de modèles définis dans les OpenAI API spécifications de votre cluster GKE. Vous pouvez définir des règles de routage Gateway, telles que la répartition du trafic et la mise en miroir des requêtes, pour gérer différentes versions de modèles et simplifier les déploiements de modèles. Par exemple, vous pouvez acheminer les requêtes d'un nom de modèle spécifique vers différents objets InferencePool, chacun mettant en service une version différente du modèle. Pour en savoir plus sur la configuration, consultez Configurer le routage basé sur le corps.
  • Sécurité de l'IA et filtrage de contenu intégrés : GKE Inference Gateway s'intègre à Google Cloud Model Armor pour appliquer des vérifications de sécurité de l'IA et un filtrage de contenu aux prompts et aux réponses au niveau de la passerelle. Vous pouvez également utiliser NVIDIA NeMo Guardrails. Model Armor fournit des journaux des requêtes, des réponses et du traitement pour l'analyse et l'optimisation rétrospectives. Les interfaces ouvertes de GKE Inference Gateway permettent aux fournisseurs et aux développeurs tiers d'intégrer des services personnalisés au processus de requête d'inférence.
  • **`Priority` spécifique au modèle**Priority : vous permet de spécifier la mise en service Priority des modèles d'IA. Priorisez les requêtes sensibles à la latence par rapport aux tâches d'inférence par lot tolérantes à la latence. Par exemple, vous pouvez prioriser les requêtes provenant d'applications sensibles à la latence et supprimer les tâches moins sensibles au temps lorsque les ressources sont limitées.
  • Routage basé sur la latence prédite : achemine les requêtes d'inférence à l'aide d'un modèle XGBoost entraîné en continu sur le trafic en direct, en optimisant les objectifs de délai d'émission du premier jeton (TTFT) et de délai par jeton de sortie (TPOT) par requête. Plus précis que les heuristiques statiques dans les charges de travail à forte variance. Consultez Utiliser le routage basé sur la latence prédite avec GKE Inference Gateway.
  • Observabilité de l'inférence : fournit des métriques d'observabilité pour les requêtes d'inférence, telles que le taux de demandes, la latence, les erreurs et la saturation. Surveillez les performances et le comportement de vos services d'inférence via Cloud Monitoring et Cloud Logging, en tirant parti des tableaux de bord prédéfinis spécialisés pour obtenir des insights détaillés. Pour en savoir plus, consultez Afficher le tableau de bord GKE Inference Gateway.
  • Gestion avancée des API avec Apigee : s'intègre à Apigee pour améliorer votre passerelle d'inférence avec des fonctionnalités telles que la sécurité des API, la limitation du débit et les quotas. Pour obtenir des instructions détaillées, consultez Configurer Apigee pour l'authentification et la gestion des API management.
  • Extensibilité : repose sur une extension d'inférence d'API Kubernetes Gateway Open Source extensible qui prend en charge un algorithme de sélection de point de terminaison (EPP) llm-d géré par l'utilisateur, alimenté par llm-d. L'algorithme llm-d Endpoint Picker (EPP), alimenté par llm-d, fournit l'intelligence de routage de base pour cette extension.
  • Prise en charge de plusieurs ports : prend en charge les serveurs de modèles qui exposent plusieurs ports, ce qui est essentiel pour les scénarios de mise en service avancés tels que l'attention parallèle des données.
  • Limites des groupes de points de terminaison du réseau (NEG) : limite de 50 NEG par Google Cloud service de backend. Lorsque vous utilisez un InferencePool multiport, chaque port de chaque zone crée un NEG dédié. Par exemple, un InferencePool avec huit ports dans un cluster régional typique (trois zones) génère 24 NEG. Par conséquent, une passerelle multiclusters ne peut agréger un tel InferencePool que depuis deux clusters au maximum (deux clusters × 24 NEG = 48 NEG) avant d'atteindre la limite de 50 NEG.

Comprendre les concepts clés

GKE Inference Gateway améliore le GKE Gateway existant qui utilise GatewayClass objets. GKE Inference Gateway introduit les nouvelles définitions de ressources personnalisées (CRD) de l'API Gateway suivantes , alignées sur l'extension d'API Kubernetes OSS Gateway pour l' inférence :

  • Objet InferencePool : représente un groupe de pods (conteneurs) qui partagent la même configuration de calcul, le même type d'accélérateur, le même modèle de langage de base et le même serveur de modèles. Cela regroupe et gère logiquement vos ressources de mise en service de modèles d'IA. Un seul objet InferencePool peut s'étendre sur plusieurs pods sur différents nœuds GKE et offre une évolutivité et une haute disponibilité. Vous pouvez spécifier jusqu'à huit targetPorts dans une ressource InferencePool pour prendre en charge les serveurs de modèles qui nécessitent plusieurs ports.
  • Objet InferenceObjective : spécifie le nom du modèle de mise en service à partir de InferencePool conformément à la spécification OpenAI API. L'objet InferenceObjective spécifie également les propriétés de mise en service du modèle, telles que la Priority du modèle d'IA. GKE Inference Gateway privilégie les charges de travail avec une valeur de priorité plus élevée. Cela vous permet de multiplexer les charges de travail d'IA critiques et tolérantes à la latence sur un cluster GKE. Vous pouvez également configurer l'objet InferenceObjective pour mettre en service des modèles affinés LoRA.

Le schéma suivant illustre GKE Inference Gateway et son intégration à la sécurité de l'IA, à l'observabilité et à la mise en service de modèles dans un cluster GKE.

Relation entre les objets InferencePool et InferenceObjective de GKE Inference Gateway
Figure : Modèle de ressources GKE Inference Gateway

Le schéma suivant illustre le modèle de ressources qui se concentre sur deux nouveaux personas axés sur l'inférence et les ressources qu'ils gèrent.

Modèle de ressources pour les personas axés sur l'inférence et leurs ressources
Figure : Modèle de ressources GKE Inference Gateway avec des profils axés sur l'inférence

Routeur llm-d

Le routeur llm-d est le composant de routage intelligent des requêtes qu'Inference Gateway utilise pour prendre des décisions de point de terminaison par requête. Il se compose de deux sous-composants :

Sous-composant Description
L7 Proxy Tout proxy L7 conforme de qualité industrielle (généralement Envoy) qui gère le plan de données : gestion des connexions, terminaison TLS et transfert des requêtes. Dans GKE Inference Gateway (mode Gateway), le proxy est le GKE Gateway.
llm-d Endpoint Picker (EPP) Service spécialisé que le proxy consulte pour chaque requête à l'aide du ext-proc protocole. L'EPP contient l'intelligence de routage. Il utilise des signaux en temps réel provenant des serveurs de modèles (utilisation du cache KV, longueur de la file d'attente, état du cache de préfixes et affinité de l'adaptateur LoRA) pour sélectionner le pod de serveur de modèles optimal pour chaque requête.

Mode Gateway

GKE Inference Gateway est le llm-d Router fonctionnant en mode Gateway. En mode Gateway, le proxy est un Kubernetes Gateway formel provisionné et géré séparément du service EPP. Le Gateway appelle l'EPP via ext-proc pour prendre des décisions de routage, puis transfère la requête directement au pod de serveur de modèles sélectionné.

Cette séparation du Gateway (plan de données) de l'EPP (intelligence de routage) permet :

  • Infrastructure partagée : un seul GKE Gateway dessert plusieurs InferencePools en plus des services Kubernetes standards.
  • Gestion avancée du trafic : les règles HTTPRoute prennent en charge la répartition pondérée , les déploiements progressifs et la mise en miroir des requêtes.
  • Scaling indépendant : le service EPP évolue indépendamment du Gateway.
  • Intégration cloud native : fonctionne avec le contrôleur Gateway géré de GKE, Cloud Load Balancing et les outils d'observabilité existants.

Fonctionnement de GKE Inference Gateway

GKE Inference Gateway utilise des extensions d'API Gateway et une logique de routage spécifique aux modèles pour gérer les requêtes client adressées à un modèle d'IA. Les étapes suivantes décrivent le flux de requêtes.

Fonctionnement du flux de requêtes

GKE Inference Gateway achemine les requêtes client de la requête initiale vers une instance de modèle. Cette section décrit comment GKE Inference Gateway gère les requêtes. Ce flux de requêtes est commun à tous les clients.

  1. Le client envoie une requête, mise en forme comme décrit dans la spécification de l' API OpenAI, au modèle exécuté dans GKE.

  2. GKE Inference Gateway traite la requête à l'aide des extensions d'inférence suivantes :

    1. Extension de routage basé sur le corps : extrait l'identifiant du modèle du corps de la requête client et l'envoie à GKE Inference Gateway. GKE Inference Gateway utilise ensuite cet identifiant pour acheminer la requête en fonction des règles définies dans l'objet HTTPRoute de l'API Gateway. Le routage du corps de la requête est semblable au routage basé sur le chemin de l'URL. La différence est que le routage du corps de la requête utilise les données du corps de la requête.
    2. Extension de sécurité : utilise Model Armor, NVIDIA NeMo Guardrails, ou des solutions tierces compatibles pour appliquer des règles de sécurité spécifiques aux modèles, qui incluent le filtrage de contenu, la détection des menaces, la désinfection et la journalisation. L'extension de sécurité applique ces règles aux chemins de traitement des requêtes et des réponses.
    3. llm-d Endpoint Picker (EPP) : surveille les métriques clés des serveurs de modèles dans l'InferencePool et achemine la requête vers la réplique de modèle optimale. Pour en savoir plus, consultez Routeur llm-d.

  3. GKE Inference Gateway achemine la requête vers la réplique de modèle renvoyée par l'extension de sélection de point de terminaison.

Le schéma suivant illustre le flux de requêtes d'un client vers une instance de modèle via GKE Inference Gateway.

Flux de requête d'un client vers une instance de modèle via GKE Inference Gateway
Figure : Flux de requêtes GKE Inference Gateway

Fonctionnement de la répartition du trafic

GKE Inference Gateway distribue dynamiquement les requêtes d'inférence aux serveurs de modèles dans l'objet InferencePool. Cela permet d'optimiser l'utilisation des ressources et de maintenir les performances dans des conditions de charge variables. GKE Inference Gateway utilise les deux mécanismes suivants pour gérer la distribution du trafic :

  • Sélection de point de terminaison : sélectionne dynamiquement le serveur de modèles le plus approprié pour gérer une requête d'inférence. Il surveille la charge et la disponibilité du serveur, puis prend des décisions de routage optimales en calculant un score pour chaque serveur combinant un certain nombre d'heuristiques d'optimisation :

    • Routage tenant compte du cache de préfixes : GKE Inference Gateway suit les index de cache de préfixes disponibles sur chaque serveur de modèles et attribue un score plus élevé à un serveur avec une correspondance de cache de préfixes plus longue.
    • Routage tenant compte de la charge : GKE Inference Gateway surveille la charge du serveur (utilisation du cache KV et profondeur de la file d'attente en attente) et attribue un score plus élevé à un serveur avec une charge inférieure.
    • Routage tenant compte de LoRA : lorsque la mise en service dynamique de LoRA est activée, GKE Inference Gateway surveille les adaptateurs LoRA actifs par serveur et attribue un score plus élevé à un serveur avec l'adaptateur LoRA demandé actif ou un espace supplémentaire pour charger dynamiquement l'adaptateur LoRA demandé. Un serveur avec le score total le plus élevé de tous les éléments précédents est sélectionné.

  • Mise en file d'attente et suppression : gère le flux de requêtes et empêche la surcharge du trafic. GKE Inference Gateway stocke les requêtes entrantes dans une file d'attente et les priorise en fonction de la priorité définie.

GKE Inference Gateway utilise un système Priority numérique, également appelé Criticality, pour gérer le flux de requêtes et éviter la surcharge. Cette Priority est un champ entier facultatif défini par l'utilisateur pour chaque InferenceObjective. Une valeur plus élevée signifie une requête plus importante. Lorsque le système est sous pression, les requêtes dont la Priority est inférieure à 0 sont considérées comme moins prioritaires et sont supprimées en premier, renvoyant une erreur 429 pour protéger les charges de travail plus critiques. Par défaut, la Priority est 0. Les requêtes ne sont supprimées en raison de leur priorité que si leur Priority est explicitement définie sur une valeur inférieure à 0. Ce système vous permet de prioriser le trafic d'inférence en ligne sensible à la latence par rapport aux tâches par lot moins sensibles au temps.

GKE Inference Gateway prend en charge l'inférence de streaming pour les applications telles que les chatbots et la traduction en direct, qui nécessitent des mises à jour continues ou en temps quasi réel. L'inférence de streaming fournit des réponses par blocs ou segments incrémentaux, au lieu d'une seule sortie complète. Si une erreur se produit lors d'une réponse de streaming, le flux se termine et le client reçoit un message d'erreur. GKE Inference Gateway ne retente pas les réponses de streaming.

Explorer des exemples d'applications

Cette section fournit des exemples d'utilisation de GKE Inference Gateway pour répondre à différents scénarios d'application d'IA générative.

Exemple 1 : Mettre en service plusieurs modèles d'IA générative sur un cluster GKE

Une entreprise souhaite déployer plusieurs grands modèles de langage (LLM) pour mettre en service différentes charges de travail. Par exemple, elle peut vouloir déployer un modèle Gemma3 pour une interface de chatbot et un modèle DeepSeek pour une application de recommandation. L'entreprise doit garantir des performances de mise en service optimales pour ces LLM.

Avec GKE Inference Gateway, vous pouvez déployer ces LLM sur votre cluster GKE avec la configuration d'accélérateur de votre choix dans un InferencePool. Vous pouvez ensuite acheminer les requêtes en fonction du nom du modèle (par exemple, chatbot et recommender) et de la propriété Priority.

Le schéma suivant illustre comment GKE Inference Gateway achemine les requêtes vers différents modèles en fonction du nom du modèle et de la Priority.

Acheminement des requêtes vers différents modèles en fonction du nom et de la priorité du modèle
Figure : Mise en service de plusieurs modèles d'IA générative sur un cluster GKE à l'aide de GKE Inference Gateway

Ce schéma illustre la manière dont une requête adressée à un service GenAI sur example.com/completions est gérée par GKE Inference Gateway. La requête atteint d'abord un Gateway dans l'espace de noms Infra. Ce Gateway transfère la requête vers un HTTPRoute dans l'espace de noms GenAI Inference, qui est configuré pour gérer les requêtes pour les modèles de chatbot et d'analyse des sentiments. Pour le modèle de chatbot, le HTTPRoute répartit le trafic : 90% sont dirigés vers un InferencePool exécutant la version actuelle du modèle (sélectionnée par {pool: gemma}) et 10% vers un pool avec une version plus récente ({pool: gemma-new}), généralement pour les tests Canary. Les deux pools sont liés à un InferenceObjective qui attribue une Priority de 10 aux requêtes pour le modèle de chatbot, ce qui garantit que ces requêtes sont traitées comme prioritaires.

Exemple 2 : Mettre en service des adaptateurs LoRA sur un accélérateur partagé

Une entreprise souhaite mettre en service des LLM pour l'analyse de documents et se concentre sur des audiences dans plusieurs langues, telles que l'anglais et l'espagnol. Elle a affiné des modèles pour chaque langue, mais doit utiliser efficacement sa capacité GPU et TPU. Vous pouvez utiliser GKE Inference Gateway pour déployer des adaptateurs affinés LoRA dynamiques pour chaque langue (par exemple, english-bot et spanish-bot) sur un modèle de base commun (par exemple, llm-base) et un accélérateur. Cela vous permet de réduire le nombre d'accélérateurs requis en regroupant plusieurs modèles sur un accélérateur commun.

Le schéma suivant illustre comment GKE Inference Gateway met en service plusieurs adaptateurs LoRA sur un accélérateur partagé.

Mettre en service plusieurs adaptateurs LoRA sur un accélérateur partagé
Figure : Mise en service d'adaptateurs LoRA sur un accélérateur partagé

Étape suivante