À propos de GKE Inference Gateway

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

Sur cette page, nous partons du principe que vous connaissez les éléments suivants :

Cette page s'adresse aux personas 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 diffuser des charges de travail d'IA/de 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 diffusion de charges de travail d'intelligence artificielle (IA) générative. Il simplifie le déploiement, la gestion et l'observabilité des charges de travail d'inférence de l'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 offre les principales fonctionnalités suivantes pour diffuser efficacement des modèles d'IA générative pour les applications d'IA générative sur GKE :

  • Métriques acceptées :
    • KV cache hits : nombre de recherches réussies dans le cache clé/valeur (KV).
    • Utilisation du GPU ou du TPU : pourcentage du 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 pour optimiser les performances de diffusion des modèles d'IA. Il utilise des métriques provenant des serveurs de modèles, telles que KV cache hits et queue length of pending requests, pour consommer des accélérateurs (tels que les GPU et les TPU) plus efficacement pour les charges de travail d'IA générative.
  • Diffusion de modèles LoRA dynamiques affinés : permet de diffuser des modèles LoRA dynamiques affinés sur un accélérateur commun. Cela réduit le nombre de GPU et de TPU nécessaires pour diffuser des modèles en multiplexant plusieurs modèles LoRA affinés sur un modèle de base et un accélérateur communs.
  • Autoscaling optimisé pour l'inférence : l'autoscaler horizontal de pods (HPA) GKE utilise les métriques du serveur de modèle pour l'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 spécifications OpenAI API de votre cluster GKE. Vous pouvez définir des règles de routage de passerelle, 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 pour un nom de modèle spécifique vers différents objets InferencePool, chacun servant une version différente du modèle.
  • 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 requêtes et aux réponses au niveau de la passerelle. 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 demande d'inférence.
  • Diffusion spécifique au modèle Criticality : vous permet de spécifier la diffusion Criticality des modèles d'IA. Priorisez les requêtes sensibles à la latence par rapport aux jobs d'inférence par lot tolérants à la latence. Par exemple, vous pouvez donner la priorité aux requêtes provenant d'applications sensibles à la latence et abandonner les tâches moins sensibles au temps lorsque les ressources sont limitées.
  • Observabilité de l'inférence : fournit des métriques d'observabilité pour les requêtes d'inférence, telles que le taux de requêtes, la latence, les erreurs et la saturation. Surveillez les performances et le comportement de vos services d'inférence à l'aide de Cloud Monitoring et Cloud Logging, en tirant parti des tableaux de bord prédéfinis spécialisés pour obtenir des informations détaillées. Pour en savoir plus, consultez Afficher le tableau de bord GKE Inference Gateway.
  • Extensibilité : s'appuie sur une extension d'inférence de l'API Kubernetes Gateway extensible et Open Source, qui prend en charge un algorithme de sélection de points de terminaison géré par l'utilisateur.

Comprendre les concepts clés

La passerelle d'inférence GKE améliore la passerelle GKE existante qui utilise des objets GatewayClass. GKE Inference Gateway introduit les nouvelles définitions de ressources personnalisées (CRD) de l'API Gateway suivantes, qui sont alignées sur l'extension de l'API Gateway Kubernetes OSS 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èle. Cela permet de regrouper et de gérer logiquement vos ressources de diffusion de modèles d'IA. Un seul objet InferencePool peut s'étendre sur plusieurs pods sur différents nœuds GKE et offre évolutivité et haute disponibilité.
  • Objet InferenceModel : spécifie le nom du modèle de diffusion à partir de InferencePool selon la spécification OpenAI API. L'objet InferenceModel spécifie également les propriétés de diffusion du modèle, telles que le Criticality du modèle d'IA. La passerelle d'inférence GKE donne la préférence aux charges de travail classées comme Critical. Cela vous permet de multiplexer les charges de travail d'IA critiques en termes de latence et tolérantes à la latence sur un cluster GKE. Vous pouvez également configurer l'objet InferenceModel pour diffuser des modèles LoRA affinés.
  • Objet TargetModel : spécifie le nom du modèle cible et l'objet InferencePool qui sert le modèle. Cela vous permet de définir des règles de routage de passerelle, telles que la répartition du trafic et la mise en miroir des requêtes, et de simplifier les déploiements de versions de modèles.

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

Relation entre les objets `InferencePool` et `InferenceModel` de la passerelle d'inférence GKE
Figure : Modèle de ressources GKE Inference Gateway

Le schéma suivant illustre le modèle de ressources axé sur deux nouvelles personnes axées sur l'inférence et les ressources qu'elles 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

Fonctionnement de la passerelle d'inférence GKE

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

Fonctionnement du flux de demande

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 traite les requêtes. Ce flux de requête 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. La passerelle d'inférence GKE 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 du client et l'envoie à GKE Inference Gateway. La passerelle GKE Inference 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 d'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 ou des solutions tierces compatibles pour appliquer des règles de sécurité spécifiques au modèle, y compris le filtrage de contenu, la détection des menaces, l'assainissement et la journalisation. L'extension de sécurité applique ces règles aux chemins de traitement des requêtes et des réponses. Cela permet à l'extension de sécurité d'assainir et de consigner les requêtes et les réponses.
    3. Extension de sélection de points de terminaison : surveille les métriques clés des serveurs de modèles dans InferencePool. Il suit l'utilisation du cache clé/valeur (KV-cache), la longueur de la file d'attente des requêtes en attente et les adaptateurs LoRA actifs sur chaque serveur de modèle. Elle achemine ensuite la requête vers la réplique de modèle optimale en fonction de ces métriques afin de minimiser la latence et de maximiser le débit pour l'inférence d'IA.
  3. La passerelle d'inférence GKE 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ête 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. La passerelle d'inférence GKE utilise les deux mécanismes suivants pour gérer la distribution du trafic :

  • Sélection du point de terminaison : sélectionne dynamiquement le serveur de modèle le plus adapté pour traiter une requête d'inférence. Il surveille la charge et la disponibilité du serveur, puis prend des décisions de routage.

  • 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, les hiérarchise en fonction de critères définis et les supprime lorsque le système est surchargé.

GKE Inference Gateway est compatible avec les niveaux Criticality suivants :

  • Critical : ces charges de travail sont prioritaires. Le système garantit que ces requêtes sont traitées même en cas de contraintes de ressources.
  • Standard : ces charges de travail sont traitées lorsque des ressources sont disponibles. Si les ressources sont limitées, ces requêtes sont abandonnées.
  • Sheddable : ces charges de travail sont traitées de manière opportuniste. Si les ressources sont rares, ces requêtes sont abandonnées pour protéger les charges de travail Critical.

Lorsque le système est soumis à une pression sur les ressources, les requêtes Standard et Sheddable sont immédiatement abandonnées avec un code d'erreur 429 pour protéger les charges de travail Critical.

Inférence par flux

GKE Inference Gateway est compatible avec l'inférence par flux 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 par flux fournit des réponses par blocs ou segments incrémentaux, plutôt que sous la forme d'une sortie unique et 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. La passerelle d'inférence GKE ne relance pas les réponses de streaming.

Explorer des exemples d'applications

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

Exemple 1 : Diffuser 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 traiter différentes charges de travail. Par exemple, ils peuvent 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 diffusion optimales pour ces LLM.

La passerelle d'inférence GKE vous permet de 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é Criticality.

Le diagramme suivant illustre la manière dont GKE Inference Gateway achemine les requêtes vers différents modèles en fonction du nom du modèle et de Criticality.

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

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

Une entreprise souhaite diffuser des LLM pour l'analyse de documents et se concentre sur des audiences dans plusieurs langues, comme l'anglais et l'espagnol. Ils ont affiné des modèles pour chaque langue, mais doivent utiliser efficacement leur capacité de GPU et de TPU. Vous pouvez utiliser la passerelle d'inférence GKE pour déployer des adaptateurs LoRA dynamiques affinés 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 la manière dont GKE Inference Gateway diffuse 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é

Étapes suivantes