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 diffusion 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 chaque modèle. Au lieu de cela, les développeurs envoient des requêtes d'API OpenAI qui incluent le nom du modèle au point de terminaison de l'interface. Le système de l'architecture achemine les requêtes vers le backend qui héberge le modèle spécifié. L'équilibreur de charge d'interface de l'architecture fournit les fonctions d'administration centralisées suivantes :
- Point de terminaison d'interface unique pour tous les appels de modèle, quelle que soit la manière dont vous hébergez les modèles.
- Fonctionnalité de gestion des API.
- Point de contrôle pour les garde-fous d'IA.
- Extensions de service point d'insertion pour une 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 d'informations 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 des architectures de mise en réseau d'applications telles que Cross-Cloud Network pour les applications distribuées applications et avec d'autres conceptions.
Architecture
Le schéma suivant présente 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 d'instances dupliquées de modèle hébergés sur site ou par n'importe quel fournisseur. L'équilibreur de charge d'interface fournit des services consolidés pour tous les modèles hébergés.
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 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 d'interface est un équilibreur de charge d'application interne régional. L'équilibreur de charge d'interface achemine le trafic vers des pools d'instances dupliquées en fonction du nom de modèle spécifié dans la requête. Dans cette architecture, l'application cliente effectue des appels d'API OpenAI à l' équilibreur de charge. Si le serveur d'inférence 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.
- Service Extensions callouts : vous pouvez utiliser des appels pour ajouter un traitement supplémentaire à un équilibreur de charge d'application. L'architecture de cette conception utilise les appels suivants :
- **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 d'API OpenAI et l'écrit dans un champ
X-Gateway-Model-Namede l'en-tête. Le mappage d'URL de l'équilibreur de charge utilise le champ pour transférer la requête au service de backend approprié. Le déploiement Terraform fourni avec cette architecture de référence inclut la configuration du routeur basé sur le corps. - Apigee : gestionnaire d'API qui 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 de base de Model Armor.
- **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 d'API OpenAI et l'écrit dans un champ
- 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 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. Dans l'architecture, les instances dupliquées de modèle sont contenues dans un cluster Google Kubernetes Engine (GKE) derrière une GKE Inference Gateway, dans Gemini Enterprise Agent Platform, dans Cloud Run, dans un centre de données sur site ou dans un autre cloud, et derrière un point de terminaison sur Internet.
Configurations d'ensemble d'instances dupliquées de modèle
Dans l'architecture, l'équilibreur de charge d'interface dirige le trafic vers un service de backend particulier en fonction du nom du modèle. Les serveurs d'inférence du 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 dupliquées | Description | Équilibrage de charge des instances dupliquées |
|---|---|---|
| Agent Platform | Les instances dupliquées de modèle s'exécutent dans Agent Platform. Vous publiez un point de terminaison Agent Platform en tant que groupe de points de terminaison du réseau (NEG) Private Service Connect. L'équilibreur de charge d'interface utilise des NEG Private Service Connect comme backends pour chaque modèle distinct, chaque modèle étant structuré en tant que service de backend. | Agent Platform effectue un scaling et un équilibrage de charge en interne. Agent Platform effectue un équilibrage de charge pondéré basé sur les métriques et un routage basé sur le cache de préfixe, 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 d'instances dupliquées GKE. Plusieurs instances dupliquées de modèle dans GKE forment collectivement un backend unique derrière une Inference Gateway. L'Inference Gateway publie un point de terminaison Private Service Connect auquel l'équilibreur de charge d'interface accède à l'aide d'un NEG Private Service Connect. | L' Inference Gateway fournit un équilibrage de charge basé sur le modèle pour les backends d'inférence dans un cluster GKE. L'Inference Gateway utilise la correspondance de préfixe, le cas échéant. S'il n'y a pas de correspondance de préfixe, l'Inference Gateway 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 ajuste automatiquement le nombre d'instances dupliquées en fonction du trafic. Il est limité aux instances dupliquées à un seul nœud. |
| 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 d'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 d'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 :
- 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 de modèle de l'un des serveurs d'inférence hébergés.
- Le point de terminaison Private Service Connect transfère la requête à l'équilibreur de charge d'application interne d'interface.
- L'équilibreur de charge transfère la requête aux extensions de service.
- Le code de routage basé sur le corps des extensions de service 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. - L'équilibreur de charge utilise l'appel 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.
- L'équilibreur de charge utilise un appel d'extension de trafic Service Extensions pour envoyer le prompt à Model Armor à des fins de 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.
- 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 de modèle. Si nécessaire, le mappage d'URL réécrit l'URL et le chemin d'accès de la requête pour qu'ils correspondent à ce dont le backend a besoin.
- Le service de backend transfère la requête à l'équilibreur de charge de l'ensemble d'instances dupliquées associé.
- L'équilibreur de charge du service d'inférence spécifique attribue la requête à l'une de ses instances dupliquées.
- L'instance dupliquée traite la requête et renvoie une réponse.
- L'équilibreur de charge d'application interne régional d'interface envoie la réponse à Model Armor à des fins de filtrage.
- 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 présente une vue de routage d'un exemple de déploiement :
Dans cet exemple, les prompts sont gérés en fonction du modèle sélectionné par l'utilisateur :
- Gemma : tous les prompts sont acheminés vers l'ensemble d'instances dupliquées qui héberge le modèle Gemma.
- Llama : le système équilibre la charge de ces prompts de manière égale 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 Agent Platform 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.
Produits utilisés
L'architecture de référence de ce document utilise les produits suivants Google Cloud :
- 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 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 manière 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 manières alternatives :
- 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 autres qu'au point de terminaison du modèle, vous pouvez désactiver Model Armor au niveau de l'équilibreur de charge d'interface 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 de 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 des Service Extensions ne répond pas à vos besoins, vous devrez peut-être déployer un réseau client et un réseau d'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 solution pour Apigee, consultez Options de mise en réseau Apigee.
Se connecter à d'autres réseaux
L'architecture de 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 Cloud Armor à votre équilibreur de charge d'application interne régional d'interface.
- Pour ajouter une couche d'authentification commune à tous les backends, implémentez Identity-Aware Proxy (IAP) afin de vérifier l'identité et d'appliquer les règles d'autorisation.
- Lorsque vous acheminez le trafic d'une application Web vers un modèle Agent Platform, 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 Agent Platform à l'aide de l'identité de charge de travail des services (telle 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é quel prompt.
- Transmission directe de l'identité de l'utilisateur final (recommandée pour une auditabilité stricte) : l'application capture le jeton d'accès OAuth Google de l'utilisateur final et le transmet directement à Agent Platform dans l'en-tête
Authorization: Bearer. Cette implémentation fournit une journalisation intégrée des actions de l'utilisateur dans Cloud Audit Logs, mais elle nécessite que chaque utilisateur final dispose d'autorisations IAM (telles queroles/aiplatform.user). Google Cloud
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.
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
- Cloud Run : pour accélérer le démarrage des instances, vous pouvez stocker les pondérations du modèle dans l'image de conteneur.
- GKE : 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.
Pour savoir comment déployer des modèles d'IA, consultez les ressources suivantes :
Étape suivante
- Pour savoir comment ajouter une génération augmentée par récupération à votre déploiement, consultez Connectivité privée pour les applications d'IA générative compatibles avec RAG.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, explorez le Cloud Architecture Center.
Contributeurs
Auteur : Victor Moreno | Responsable produit, Mise en réseau cloud
Autres contributeurs :
- Mark Schlagenhauf | Rédacteur technique, Mise en réseau
- James Duncan | Responsable produit, Solutions
- Ammett Williams | Ingénieur relations avec les développeurs