Mise en réseau pour la diffusion de modèles d'inférence d'IA sur tous les backends

Last reviewed 2026-05-20 UTC

Ce document fournit une architecture de référence pour créer une interface unifiée pour plusieurs modèles d'IA hébergés sur site ou par n'importe quel fournisseur, y compris des tiers et Google Cloud. Si tous vos serveurs d'inférence sont hébergés dans Google Kubernetes Engine (GKE), consultez Mise en réseau pour la mise en service de modèles d'inférence d'IA sur GKE.

Cette architecture est conçue pour permettre à vos développeurs de sélectionner des modèles sans avoir à spécifier d'adresses IP individuelles pour chacun d'eux. Au lieu de cela, les développeurs envoient des requêtes à l'API OpenAI qui incluent le nom du modèle au point de terminaison du frontend. Dans l'architecture, le système achemine les requêtes vers le backend qui héberge le modèle spécifié. L'équilibreur de charge de l'interface dans l'architecture fournit les fonctions d'administration centralisées suivantes :

  • Point de terminaison frontend unique pour tous les appels de modèle, quelle que soit la façon dont vous hébergez les modèles.
  • Fonctionnalité de gestion des API.
  • Point de contrôle pour les garde-fous de l'IA.
  • Point d'insertion Service Extensions pour l'extensibilité future.

Ce document s'adresse aux administrateurs réseau et aux administrateurs d'applications d'IA générative qui souhaitent placer des modèles d'IA générative nouveaux ou existants derrière un point de terminaison d'inférence unique. 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, telles que Cross-Cloud Network pour les applications distribuées, ainsi qu'avec d'autres conceptions.

Architecture

Le schéma suivant montre une architecture avec un point de terminaison dans un réseau consommateur qui pointe vers une interface d'équilibreur de charge d'application interne régional. Cet équilibreur de charge utilise le nom du modèle spécifié pour acheminer les requêtes vers des ensembles de répliques de modèle hébergés sur site ou par n'importe quel fournisseur. L'équilibreur de charge de frontend 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 de cloud privé virtuel (VPC) consommateur. Vous pouvez héberger des points de terminaison dans plusieurs réseaux VPC ou dans un réseau VPC de services partagés.
  • Équilibreur de charge d'application interne régional : dans cette architecture, l'équilibreur de charge de l'interface est un équilibreur de charge d'application interne régional. L'équilibreur de charge de frontend achemine le trafic vers les pools de répliques en fonction du nom du modèle spécifié dans la requête. Dans cette architecture, l'application cliente effectue des appels à l'API OpenAI vers l'équilibreur de charge. Si le serveur d'inférence de backend est compatible avec l'API OpenAI, tout fonctionne de manière transparente. Si le serveur d'inférence n'est pas compatible avec l'API OpenAI, vous devez implémenter un traducteur d'API à l'aide des extensions de service. Cette architecture de référence n'inclut pas l'implémentation d'un traducteur d'API.
  • Appels d'extension de service : vous pouvez utiliser des appels pour ajouter un traitement supplémentaire à un équilibreur de charge d'application. L'architecture de cette conception utilise les légendes suivantes :
    • Routeur basé sur le corps : Le routeur basé sur le corps est déployé dans Cloud Run. Il lit le nom du modèle à partir du corps de la requête API OpenAI et l'écrit dans un champ X-Gateway-Model-Name de l'en-tête. Le mappage d'URL de l'équilibreur de charge utilise le champ pour transférer la requête vers le service de backend approprié. Le déploiement Terraform fourni avec cette architecture de référence inclut la configuration du routeur basée sur le corps.
    • Apigee : gestionnaire d'API qui 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.
  • Services de backend : l'équilibreur de charge achemine les requêtes vers les services de backend en fonction du nom du modèle dans la requête. Le service de backend contient un groupe de points de terminaison du réseau (NEG).
  • Ensembles de répliques de modèles : 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. Dans l'architecture, les instances répliquées de modèle sont contenues dans un cluster Google Kubernetes Engine (GKE) derrière une passerelle d'inférence GKE, dans Vertex AI, dans Cloud Run, dans un centre de données sur site ou autre, et derrière un point de terminaison sur Internet.

Configurations de l'ensemble de répliques du modèle

Dans l'architecture, l'équilibreur de charge de frontend dirige le trafic vers un service de backend spécifique en fonction du nom du modèle. Les serveurs d'inférence pour le modèle spécifié peuvent être hébergés dans l'une des configurations décrites dans le tableau suivant.

Type d'ensemble d'instances répliquées Description Équilibrage de charge des répliques
Vertex AI Les répliques de modèle s'exécutent dans Vertex AI. Vous publiez un point de terminaison Vertex AI en tant que groupe de points de terminaison du réseau (NEG) Private Service Connect. L'équilibreur de charge de frontend utilise des NEG Private Service Connect comme backends pour chaque modèle distinct, chaque modèle étant structuré en tant que service de backend. Vertex AI est mis à l'échelle et équilibré en charge en interne. Vertex AI effectue un équilibrage de charge pondéré basé sur les métriques et un routage basé sur le cache de préfixes, ce qui optimise l'utilisation des ressources et accélère l'inférence. Pour en savoir plus, consultez la section Déployer un modèle sur un point de terminaison.
GKE Les serveurs d'inférence s'exécutent en tant que pods dans un cluster GKE du réseau VPC de l'ensemble de répliques GKE. Plusieurs répliques de modèle dans GKE forment collectivement un backend unique derrière une passerelle d'inférence. La passerelle d'inférence publie un point de terminaison Private Service Connect auquel l'équilibreur de charge du frontend accède à l'aide d'un NEG Private Service Connect. La passerelle d'inférence fournit un équilibrage de charge tenant compte des modèles pour les backends d'inférence dans un cluster GKE. La passerelle d'inférence utilise la correspondance de préfixe, le cas échéant. S'il n'y a pas de correspondance de préfixe, la passerelle d'inférence distribue les requêtes en fonction des métriques GPU ou TPU. Cette configuration est compatible avec l'autoscaling horizontal des pods.
Cloud Run Les serveurs d'inférence s'exécutent dans Cloud Run. Cloud Run publie un point de terminaison auquel l'équilibreur de charge d'interface accède à l'aide d'un NEG sans serveur. Cloud Run adapte automatiquement le nombre de répliques en fonction du trafic. Elle est limitée aux répliques à nœud unique.
Hybride Les serveurs d'inférence s'exécutent sur site ou dans un autre cloud. Vous configurez un équilibreur de charge réseau proxy interne régional dans un réseau VPC de routage. Cet équilibreur de charge publie un point de terminaison Private Service Connect auquel l'équilibreur de charge de l'interface accède à l'aide d'un NEG Private Service Connect. L'équilibreur de charge interne du réseau VPC de routage possède à son tour un backend NEG hybride qui pointe vers l'adresse IP d'un équilibreur de charge sur site ou dans un autre cloud, devant les serveurs d'inférence sur site. Le mécanisme d'équilibrage de charge de l'équilibreur de charge externe est configuré par les administrateurs de l'installation externe.
Internet Serveurs d'inférence accessibles à partir d'adresses IP Internet publiques. L'équilibreur de charge de l'interface possède un backend NEG Internet qui pointe vers l'adresse IP d'un modèle hébergé sur Internet. Le fournisseur de services gérés gère le scaling.

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 à l'équilibreur de charge d'application interne du frontend.
  3. L'équilibreur de charge transmet la requête à Service Extensions.
  4. Le code de routage basé sur le corps des Service Extensions lit le nom du modèle à partir du corps de la requête et l'écrit dans un en-tête X-Gateway-Model-Name.
  5. L'équilibreur de charge utilise le point d'extension de trafic des Service Extensions pour envoyer la requête au système de gestion des API pour tous les services de gestion des API nécessaires.
  6. L'équilibreur de charge utilise un callout d'extension de trafic Service Extensions pour envoyer la requête à Model Armor à des fins d'analyse.
    • Si la requête 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 transmet la requête.
  7. Si la requête est autorisée par Model Armor, l'équilibreur de charge consulte le mappage d'URL et transfère la requête à un service de backend en fonction de l'en-tête personnalisé du nom du modèle. Si nécessaire, le mappage d'URL réécrit l'URL et le chemin d'accès de la requête pour correspondre à ce dont le backend a besoin.
  8. Le service de backend transfère la requête à l'équilibreur de charge de son ensemble de répliques associé.
  9. L'équilibreur de charge du service d'inférence spécifique attribue la requête à l'un de ses réplicas.
  10. La réplique traite la requête et renvoie une réponse.
  11. L'équilibreur de charge d'application interne régional du frontend envoie la réponse à Model Armor pour qu'elle soit examinée.
  12. L'équilibreur de charge d'application 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 :

  • Gemma : toutes les requêtes sont acheminées vers l'ensemble de répliques qui héberge le modèle Gemma.
  • Llama : le système équilibre la charge de ces requêtes de manière égale 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 Vertex AI et l'autre 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.

Produits utilisés

L'architecture de référence de ce document utilise les produits Google Cloud suivants :

  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
  • 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 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 hypothèses de base de cette architecture.

Garde-fous de l'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 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 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 Cloud Armor à votre équilibreur de charge d'application interne régional de frontend.
  • Pour ajouter une couche d'authentification commune à tous les backends, implémentez Identity-Aware Proxy (IAP) pour vérifier l'identité et appliquer les règles d'autorisation.
  • Lorsque vous routez le trafic d'une application Web vers un modèle Vertex AI, vous devez choisir un modèle d'identité pour l'authentification :
    • Identité du compte de service (recommandée pour les applications Web générales) : l'application authentifie l'utilisateur final via IAP, mais elle appelle Vertex AI à l'aide de l'identité de charge de travail des services (tels que Cloud Run, GKE ou à l'aide d'une identité tierce). Cette implémentation extrait Identity and Access Management (IAM) de l'utilisateur final, mais elle nécessite une journalisation au niveau de l'application pour suivre quel utilisateur a généré quelle requête.
    • Transmission de l'identité de l'utilisateur final (recommandée pour une auditabilité stricte) : l'application capture le jeton d'accès Google OAuth de l'utilisateur final et le transmet directement à Vertex AI dans l'en-tête Authorization: Bearer. Cette implémentation fournit une journalisation intégrée des actions utilisateur dans Cloud Audit Logs, mais elle nécessite que chaque utilisateur final soit provisionné avec des autorisations IAM Google Cloud(telles que roles/aiplatform.user).

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'archétype de déploiement multirégional.Google Cloud

Efficacité opérationnelle

  • Pour surveiller les flux de trafic afin d'identifier et de résoudre rapidement les problèmes, utilisez les journaux Cloud Logging pour votre équilibreur de charge d'application interne régional.
  • Pour faciliter la découverte des modèles compatibles avec votre organisation, implémentez une liste interrogeable pour renvoyer les modèles disponibles. Par exemple, vous pouvez créer une liste sur un serveur qui répond à l'appel d'API list models.

Optimisation des performances

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.

Pour savoir comment déployer des modèles d'IA, consultez les ressources suivantes :

Étapes suivantes

Contributeurs

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

Autres contributeurs :