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 cette architecture, les pools d'inférence hébergés sur GKE sont placés derrière une GKE Inference Gateway. Cette architecture présente les avantages suivants :

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

Ce document est destiné aux architectes réseau chargés d'unifier le déploiement des serveurs d'inférence qui s'exécutent dans GKE. Si tous vos serveurs d'inférence ne sont pas hébergés dans GKE, consultez la section 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 la section 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 d'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 schéma 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 (cloud privé virtuel) consommateur. Vous pouvez héberger des points de terminaison dans plusieurs réseaux VPC ou dans un réseau VPC de services partagés.
  • Passerelle d'inférence : la passerelle d'inférence améliore la passerelle GKE pour optimiser la façon dont GKE diffuse les applications et les charges de travail d'IA générative. Elle achemine le trafic vers les pools d'inférence des instances dupliquées de modèle en fonction du nom du modèle. La passerelle utilise la correspondance de préfixe pour acheminer le trafic dans le pool d'instances dupliquées. S'il n'y a pas de correspondance de préfixe, le processeur d'inférence de la passerelle utilise les métriques Prometheus du GPU ou du TPU pour choisir l'instance dupliquée la moins chargée 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 d'API OpenAI pour accéder aux modèles via la passerelle. La passerelle est déployée en fonction d'un équilibreur de charge d'application interne régional (gke-l7-rilb), de sorte qu'elle n'est pas directement accessible depuis Internet.
    • Gestion des API : un gestionnaire d'API fournit l'authentification, la sécurité, la limitation du débit, le 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 prompts d’inférence avant qu’ils 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 d'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 instances dupliquées du même modèle. Lorsque la passerelle reçoit un prompt, elle utilise une HTTPRoute recherche 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 d'instances dupliquées de modèle : une instance dupliquée de modèle est une copie d'un serveur d'inférence déployée sur un ou plusieurs GPU ou TPU. Une instance dupliquée de modèle peut être à un ou plusieurs nœuds. Un ensemble d'instances dupliquées est un groupe uniforme d'instances dupliquées de modèle qui est précédé d'un équilibreur de charge. Si l'ensemble d'instances dupliquées comporte plusieurs nœuds, les GPU se connectent entre eux via un réseau VPC RDMA de backend. Le réseau fournit une mise en réseau inter-GPU sans perte à faible latence et 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 d'API OpenAI au point de terminaison Private Service Connect. Cette requête contient les éléments suivants :
    • Le prompt.
    • Le 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 transfère la requête au système de gestion des API pour les services de gestion des API nécessaires.
  5. La passerelle envoie le prompt à Model Armor pour filtrage.
    • Si le prompt contient des informations sensibles qui ne peuvent pas être expurgées, il est bloqué et Model Armor renvoie une réponse indiquant qu'une violation de règle a été détectée.
    • Si le prompt contient des informations sensibles qui peuvent être expurgées ou s'il ne présente aucun problème, Model Armor expurge les informations sensibles et transfère le prompt.
  6. La passerelle consulte HTTPRoute pour obtenir la liste des pools d'inférence qui correspondent au modèle de la requête. Dans cette liste, la passerelle en choisit un en fonction d'une priorité.
  7. La passerelle consulte le cache de préfixe et la charge actuelle de toutes les instances dupliquées du pool, puis utilise ces informations pour choisir une instance dupliquée.
  8. L'instance dupliquée 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 de routage d'un exemple de déploiement.

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

Dans cet exemple, les prompts sont gérés en fonction du modèle sélectionné par l'utilisateur :

  • Llama : le système équilibre la charge de ces prompts selon un ratio de 90/10 entre deux ensembles d'instances dupliquées qui hébergent tous deux le modèle Llama. Ces deux ensembles d'instances dupliquées ne doivent pas nécessairement être hébergés de la même manière. Par exemple, un ensemble d'instances dupliquées peut être hébergé dans Vertex AI et l'autre dans GKE.
  • LoRA-1-gemma ou LoRA-2-gemma : le système envoie tous les prompts au même ensemble d'instances dupliquées, qui peut gérer les deux modèles.

Dans tous les cas, la passerelle utilise une combinaison de correspondance de préfixe et de charge minimale pour choisir une instance dupliquée dans le pool approprié.

Produits utilisés

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

  • 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.
  • Passerelle d'inférence GKE : extension de la passerelle Google Kubernetes Engine qui fournit un routage et un équilibrage de charge optimisés pour la diffusion de charges de travail d'IA générative. Elle simplifie le déploiement, la gestion et l'observabilité des charges de travail d'inférence d'IA.
  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos Google Cloud charges de travail. 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 offre un contrôle précis sur la façon dont vos API sont accessibles et utilisées. Il fournit sécurité, limitation du débit, application des quotas et analyses.
  • Model Armor : service qui protège vos ressources d'IA générative et d'IA agentique 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 des hypothèses de base de cette architecture.

Garde-fous d'IA

Nous vous recommandons d'utiliser Model Armor pour les garde-fous d'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 de l'instance dupliquée.

Si vous implémentez des garde-fous d'IA ailleurs qu'au point de terminaison du modèle, vous pouvez désactiver Model Armor au niveau de l'équilibreur de charge de frontend si vous n'en avez pas besoin. Si vous ne souhaitez pas utiliser Model Armor, vous pouvez utiliser des 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 des extensions de service pour déployer un autre service de gestion des API.

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

Connexion à 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 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 Well-Architected Framework.

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 protéger 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 GKE, consultez la section 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 de passerelle d'inférence à l'aide du tableau de bord de la passerelle d'inférence. 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 section 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 la diffusion de modèles d'inférence d'IA disponible sur GitHub.

Étape suivante

Contributeurs

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

Autres contributeurs :