À propos de GKE Inference Gateway

---

Cette page présente la passerelle d'inférence Google Kubernetes Engine (GKE), une amélioration de la passerelle GKE pour une diffusion optimisée des applications d'IA générative. Il explique les concepts et fonctionnalités clés, ainsi que le fonctionnement de GKE Inference Gateway.

Cette page est destinée 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

Avant de lire cette page, assurez-vous de connaître les éléments suivants:

• Orchestration IA/ML sur GKE
• Glossaire de l'IA générative
• Concepts de mise en réseau GKE, y compris les services et l' API GKE Gateway.
• Équilibrage de charge dansGoogle Cloud, en particulier la façon dont les équilibreurs de charge interagissent avec GKE.

Présentation

GKE Inference Gateway est une extension de la passerelle GKE 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.

Fonctionnalités et avantages

Le GKE Inference Gateway fournit 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:

• Équilibrage de charge optimisé pour l'inférence: distribue les requêtes pour optimiser les performances de diffusion du modèle d'IA. Il utilise des métriques provenant de serveurs de modèles, tels que KVCache Utilization et queue length of pending requests, pour utiliser plus efficacement les accélérateurs (tels que les GPU et les TPU) pour les charges de travail d'IA générative.
• Diffusion de modèles affinés LoRA dynamiques: permet de diffuser des modèles affinés LoRA dynamiques sur un accélérateur commun. Cela réduit le nombre de GPU et de TPU requis 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'outil AHP (Horizontal Pod Autoscaler) de GKE utilise des métriques de 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èle 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 division du trafic et la mise en miroir des requêtes, pour gérer différentes versions de modèle et simplifier le déploiement des 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.
• Criticality de diffusion spécifique au modèle: vous permet de spécifier le Criticality de diffusion 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 donner la priorité aux requêtes d'applications sensibles aux temps de latence et abandonner les tâches moins urgentes lorsque les ressources sont limitées.
• Sécurité de l'IA intégrée: s'intègre à Google Cloud Model Armor, un service qui applique des vérifications de sécurité de l'IA aux requêtes et réponses au niveau de la passerelle. Model Armor fournit des journaux de requêtes, de réponses et de traitement pour l'analyse et l'optimisation rétrospectives. Les interfaces ouvertes du GKE Inference Gateway permettent aux fournisseurs tiers et aux développeurs d'intégrer des services personnalisés au processus de requête d'inférence.
• Observabilité des inférences: 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.

Comprendre les concepts clés

GKE Inference Gateway améliore l'GKE Gateway existant qui utilise des objets GatewayClass. GKE Inference Gateway introduit les nouvelles définitions de ressources personnalisées (CRD) de l'API Gateway suivantes, conformes à l'extension de l'API Kubernetes Gateway Open Source 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 de manière logique les ressources de diffusion de votre modèle 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é.
• Objet InferenceModel: spécifie le nom du modèle de diffusion à partir de InferencePool, conformément aux spécifications 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 priorité aux charges de travail classées comme Critical. Vous pouvez ainsi multiplexer des charges de travail d'IA critiques et tolérantes aux latences 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 le diffuse. Vous pouvez ainsi définir des règles de routage de passerelle, telles que la répartition du trafic et le mirroring des requêtes, et simplifier le déploiement des versions de modèle.

Le schéma suivant illustre la passerelle d'inférence GKE et son intégration à la sécurité, à l'observabilité et au service de modèle de l'IA dans un cluster GKE.

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

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 au modèle pour gérer les requêtes client envoyé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 explique 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ée 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. L'acheminement du corps de la requête est semblable à l'acheminement 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 stratégies de sécurité spécifiques au modèle, y compris 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. Cela permet à l'extension de sécurité de nettoyer et de consigner à la fois les requêtes et les réponses.
   3. Extension de sélecteur de point de terminaison: surveille les métriques clés des serveurs de modèles dans InferencePool. Il suit l'utilisation du cache clé-valeur (cache KV), la longueur de la file d'attente des requêtes en attente et les adaptateurs LoRA actifs sur chaque serveur de modèle. Il redirige 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 IA.
3. Le GKE Inference Gateway achemine la requête vers le réplica du modèle renvoyé par l'extension de sélecteur 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.

Fonctionnement de la répartition du trafic

GKE Inference Gateway distribue de manière dynamique 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èle le plus adapté 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.

• Mise en file d'attente et abandon: permet de gérer le flux de requêtes et d'éviter la surcharge de trafic. Le GKE Inference Gateway stocke les requêtes entrantes dans une file d'attente, hiérarchise les requêtes en fonction de critères définis et abandonne les requêtes 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 exécuté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 de 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 en 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 en streaming fournit des réponses par blocs ou segments incrémentiels, plutôt que sous la forme d'une seule sortie complète. Si une erreur se produit lors d'une réponse en streaming, le flux se termine et le client reçoit un message d'erreur. GKE Inference Gateway ne réessaye pas les réponses en streaming.

Découvrir des exemples d'applications

Cette section fournit des exemples pour répondre à divers scénarios d'application de l'IA générative à l'aide de la passerelle d'inférence GKE.

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 répondre à différentes charges de travail. Par exemple, il 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 diffusion optimales pour ces LLM.

Avec la passerelle d'inférence GKE, 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é Criticality.

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

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 des modèles optimisés pour chaque langue, mais doivent utiliser efficacement leur capacité de GPU et de TPU. Vous pouvez utiliser le GKE Inference Gateway 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 montre comment GKE Inference Gateway sert plusieurs adaptateurs LoRA sur un accélérateur partagé.

Étape suivante

• Déployer GKE Inference Gateway
• Personnaliser la configuration de GKE Inference Gateway
• Diffuser un LLM avec GKE Inference Gateway