Mise en réseau pour la mise en service de modèles d'inférence d'IA sur GKE

Last reviewed 2026-05-20 UTC

Ce document fournit une architecture de référence pour créer un service d'inférence multimodèle à l'aide de Google Kubernetes Engine (GKE). Dans l'architecture, les pools d'inférence hébergés sur GKE sont placés derrière une GKE Inference Gateway. Cette architecture offre les avantages suivants :

  • Une interface unique pour toutes vos demandes d'inférence.
  • Un routage intelligent pour chaque requête vers le modèle et le serveur d'inférence qui peuvent la traiter le plus efficacement possible.
  • Autorisation, sécurité et autres services centralisés.

Ce document s'adresse aux architectes réseau chargés d'unifier le déploiement des serveurs d'inférence exécutés dans GKE. Si tous vos serveurs d'inférence ne sont pas hébergés dans GKE, consultez Mise en réseau pour la diffusion de modèles d'inférence d'IA sur tous les backends. Ce document ne fournit pas de conseils sur la conception d'une application ni sur le déploiement d'un modèle d'IA générative individuel. Pour obtenir des conseils sur le déploiement d'un modèle, consultez Créer et déployer des modèles d'IA générative et de machine learning dans une entreprise.

Cette architecture fonctionne avec les architectures de mise en réseau des applications Cross-Cloud Network pour les applications distribuées et d'autres conceptions.

Architecture

Le schéma suivant illustre une architecture contenant une passerelle d'inférence devant des serveurs d'inférence hébergés sur GKE. La passerelle fournit des services consolidés pour tous les modèles hébergés.

Présentation générale de la mise en réseau pour l'inférence d'IA.

L'architecture du diagramme comprend les composants suivants :

  • Point de terminaison d'inférence Private Service Connect : point de terminaison unifié pour tous les modèles hébergés. L'utilisateur final envoie des requêtes d'inférence à l'adresse IP du point de terminaison. Le schéma montre un point de terminaison Private Service Connect dans un seul réseau VPC (Virtual Private Cloud) consommateur. Vous pouvez héberger des points de terminaison dans plusieurs réseaux VPC ou dans un réseau VPC de services partagés.
  • Inference Gateway : Inference Gateway améliore GKE Gateway pour optimiser la façon dont GKE diffuse les applications et les charges de travail d'IA générative. Il achemine le trafic vers des pools d'inférence de répliques de modèles en fonction du nom du modèle. La passerelle utilise la correspondance de préfixe pour acheminer le trafic dans le pool de répliques. S'il n'y a pas de correspondance de préfixe, le processeur d'inférence Gateway utilise les métriques Prometheus GPU ou TPU pour choisir le réplica le moins chargé du pool. Le processeur d'inférence gère également la mise en cache des préfixes. Dans cette architecture, l'application destinée aux clients effectue des appels à l'API OpenAI pour accéder aux modèles via la passerelle. La passerelle est déployée sur la base d'un équilibreur de charge d'application interne régional (gke-l7-rilb). Elle n'est donc pas directement accessible depuis Internet.
    • Gestion des API : un gestionnaire d'API fournit des services d'authentification, de sécurité, de limitation du débit, de suivi des quotas et d'autres services de gestion des API. Cette architecture utilise Apigee, mais elle est compatible avec d'autres options. Pour appeler Apigee à partir de l'équilibreur de charge, l'architecture et le déploiement Terraform utilisent une extension de trafic Service Extensions pour appeler le processeur d'extension Apigee.
    • Model Armor : système de garde-fous d'IA qui effectue des contrôles de sécurité sur les requêtes d'inférence avant qu'elles n'atteignent le serveur d'inférence. Il effectue ensuite des contrôles de sécurité sur les réponses sortantes. Cette architecture utilise Model Armor pour les garde-fous de l'IA, mais elle est également compatible avec d'autres options telles que NVIDIA Nemo Guardrails. Le déploiement Terraform fourni avec cette architecture de référence inclut une configuration Model Armor de base.
  • Pools d'inférence : un pool d'inférence contient des répliques du même modèle. Lorsque la passerelle reçoit une requête, elle utilise une recherche HTTPRoute pour sélectionner un pool d'inférence en fonction de l'identifiant du modèle. Les pools ont une taille initiale, mais ils peuvent être configurés pour l'autoscaling.
  • Ensembles de répliques de modèle : une réplique de modèle est une copie d'un serveur d'inférence déployée sur un ou plusieurs GPU ou TPU. Une réplique de modèle peut être à un ou plusieurs nœuds. Un ensemble de répliques est un groupe uniforme de répliques de modèle qui est placé devant un équilibreur de charge. Si le groupe de réplicas est multinœud, les GPU se connectent les uns aux autres via un réseau VPC RDMA de backend. Le réseau fournit une mise en réseau inter-GPU sans perte et à faible latence alignée sur les rails.

Processus de requête

Le système achemine les requêtes d'inférence comme suit :

  1. Un utilisateur final envoie une requête API OpenAI au point de terminaison Private Service Connect. Cette requête contient les éléments suivants :
    • Le prompt.
    • Nom du modèle, qui doit correspondre au nom du modèle de l'un des serveurs d'inférence hébergés.
  2. Le point de terminaison Private Service Connect transfère la requête vers la version régionale de l'équilibreur de charge d'application interne de la passerelle d'inférence.
  3. La passerelle extrait le nom du modèle du corps de la requête et l'injecte dans l'en-tête de requête à l'aide du routage basé sur le corps.
  4. La passerelle transmet la requête au système de gestion des API pour les services de gestion des API nécessaires.
  5. La passerelle envoie la requête à Model Armor pour qu'elle soit examinée.
    • Si l'invite contient des informations sensibles qui ne peuvent pas être masquées, elle est bloquée et Model Armor renvoie une réponse indiquant qu'un non-respect des règles a été détecté.
    • Si la requête contient des informations sensibles qui peuvent être masquées ou si elle ne présente aucun problème, Model Armor masque les informations sensibles et la transmet.
  6. La passerelle consulte HTTPRoute pour obtenir la liste des pools d'inférence qui correspondent au modèle de la requête. La passerelle en choisit un dans cette liste en fonction d'une priorité.
  7. La passerelle consulte le cache de préfixes et la charge actuelle de toutes les instances répliquées du pool, puis utilise ces informations pour choisir une instance répliquée.
  8. La réplique traite la requête et la renvoie à la passerelle.
  9. La passerelle envoie la réponse à Model Armor pour approbation ou refus.
  10. La passerelle renvoie la réponse au point de terminaison Private Service Connect, puis à l'utilisateur final.

Le schéma suivant montre une vue du routage d'un exemple de déploiement.

Flux de requêtes pour échantillonner les ensembles de répliques.

Dans cet exemple, les requêtes sont traitées en fonction du modèle sélectionné par l'utilisateur :

  • Llama : le système équilibre la charge de ces requêtes selon un ratio de 90/10 entre deux ensembles de répliques qui hébergent tous les deux le modèle Llama. Ces deux ensembles de répliques ne doivent pas nécessairement être hébergés de la même manière. Par exemple, un ensemble de répliques peut être hébergé dans Gemini Enterprise Agent Platform et l'autre ensemble de répliques peut être hébergé dans GKE.
  • LoRA-1-gemma ou LoRA-2-gemma : le système envoie toutes les requêtes au même ensemble de répliques, qui peut gérer les deux modèles.

Dans tous les cas, la passerelle utilise une combinaison de correspondance de préfixe et de moindre charge pour choisir une réplique dans le pool concerné.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloudsuivants :

  • Google Kubernetes Engine (GKE) : service Kubernetes que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées à grande échelle, à l'aide de l'infrastructure de Google.
  • GKE Inference Gateway : extension de Google Kubernetes Engine Gateway qui fournit un routage et un équilibrage de charge optimisés pour la diffusion des charges de travail d'IA générative. Il simplifie le déploiement, la gestion et l'observabilité des charges de travail d'inférence de l'IA.
  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • Private Service Connect : fonctionnalité qui permet aux clients d'accéder à des services gérés en mode privé depuis leur réseau VPC.
  • Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
  • Apigee : outil de gestion des API qui vous permet de contrôler précisément l'accès à vos API et leur utilisation. Il fournit des fonctionnalités de sécurité, de limitation du débit, d'application des quotas et d'analyse.
  • Model Armor : service qui protège vos ressources d'IA générative et agentive contre l'injection de prompt, les fuites de données sensibles et les contenus nuisibles.

Alternatives de conception

Cette section décrit des alternatives à certaines hypothèses de base de cette architecture.

Garde-fous de l'IA

Nous vous recommandons d'utiliser Model Armor pour les garde-fous de l'IA. Pour centraliser l'administration, nous vous recommandons de l'appeler directement à partir de l'équilibreur de charge, comme dans cette architecture. Vous pouvez également implémenter Model Armor de ces autres manières :

  • Utilisez une règle de gestion des API pour appeler Model Armor.
  • Déployez Model Armor uniquement au niveau du réplica.

Si vous implémentez des garde-fous d'IA ailleurs qu'au niveau du point de terminaison du modèle, vous pouvez désactiver Model Armor au niveau de l'équilibreur de charge du frontend si vous n'en avez pas besoin. Si vous ne souhaitez pas utiliser Model Armor, vous pouvez utiliser les extensions de trafic pour déployer d'autres offres de garde-fous, telles que NVIDIA NeMo Guardrails.

Gestion des API

L'architecture décrite dans ce document utilise Apigee pour la gestion des API, qui est déployée à l'aide d'une extension de service d'équilibreur de charge. Si Apigee ne répond pas à vos besoins, vous pouvez utiliser les extensions de service pour déployer un autre service de gestion des API.

Si le déploiement de la gestion des API à l'aide des Service Extensions ne répond pas à vos besoins, vous devrez peut-être déployer un réseau orienté client et un réseau orienté API. Dans ce scénario, le service de gestion des API sert de pont entre les deux réseaux. Pour savoir comment déployer cette fonctionnalité pour Apigee, consultez Options de mise en réseau Apigee.

Se connecter à d'autres réseaux

L'architecture décrite dans ce document utilise un seul réseau VPC consommateur. Toutefois, vous pouvez partager le point de terminaison Private Service Connect avec de nombreux autres réseaux en utilisant un réseau VPC d'accès aux services dans un déploiement de réseau Cross-Cloud Network.

Considérations de conception

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations du Google Cloud Framework Well-Architected.

Sécurité, confidentialité et conformité

Pour ajouter une protection contre les attaques par déni de service distribué (DDoS), une fonctionnalité de pare-feu d'application Web (WAF) et une inspection des adresses IP à votre déploiement, ajoutez Google Cloud Armor à votre équilibreur de charge d'application interne régional de frontend.

Fiabilité

Pour vous prémunir contre les défaillances régionales, répliquez votre déploiement dans une deuxième région à l'aide de l'Google Cloud archétype de déploiement multirégional.

Optimisation des coûts

Pour obtenir des recommandations sur l'optimisation des coûts sur GKE, consultez Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.

Efficacité opérationnelle

Surveillez les performances de vos requêtes d'inférence Inference Gateway à l'aide du tableau de bord Inference Gateway. Le tableau de bord affiche les erreurs et les métriques telles que le taux de demandes, la latence et la saturation. Utilisez les résultats du tableau de bord pour optimiser votre déploiement.

Optimisation des performances

Suivez les recommandations de la présentation des bonnes pratiques d'inférence sur GKE.

Déploiement

Pour déployer un exemple d'implémentation de cette architecture, utilisez l'exemple de code Mise en réseau pour le service de modèles d'inférence d'IA disponible sur GitHub.

Étapes suivantes

Contributeurs

Auteur : Victor Moreno | Responsable produit, Mise en réseau cloud

Autres contributeurs :