Ce document fournit une architecture de référence pour vous aider à concevoir et à déployer un système d'IA agentive multitenant sur Google Cloud. À mesure que votre organisation étend ses déploiements d'IA générative, différentes unités commerciales ont besoin d'agents d'IA spécialisés qui accèdent à des outils uniques, suivent des règles opérationnelles spécifiques et traitent des données sensibles. Les unités commerciales peuvent développer des silos d'applications fragmentés au sein d'une organisation, ce qui peut entraîner des frais généraux opérationnels élevés, de graves lacunes en matière de gouvernance et un risque d'exposition des données. Cette architecture vous montre comment créer un système centralisé qui permet aux équipes décentralisées de bénéficier de fonctionnalités d'IA autonomes tout en conservant une sécurité et une conformité unifiées.
Ce document s'adresse aux architectes, aux développeurs et aux administrateurs qui créent et gèrent des systèmes multi-agents de niveau entreprise dans le cloud. Dans ce document, nous partons du principe que vous possédez des connaissances de base sur les concepts d'IA, de ML et de LLM, ainsi que sur l'IA agentique.
La section Déploiement de ce document fournit une stratégie d'implémentation pour vous aider à créer et à déployer un système d'IA agentique mutualisé.
Architecture
Le diagramme suivant illustre une architecture pour un système d'IA agentique mutualisé qui suit un modèle hub-and-spoke. Un modèle en étoile est une conception réseau dans laquelle un environnement central, appelé hub, se connecte à plusieurs environnements isolés, appelés spokes.
L'architecture se compose des éléments suivants :
| Composant | Description |
|---|---|
| VPC Service Controls | L'architecture utilise VPC Service Controls pour configurer un périmètre de service au niveau de l'organisation. Ce périmètre de service fournit une limite de sécurité stricte et empêche l'exfiltration de données. |
| Plate-forme de routage |
Le hub de routage sert de point d'entrée central pour l'architecture. Il comprend les composants suivants :
|
| Plate-forme centralisée de gouvernance et de sécurité |
Le hub central de gouvernance et de sécurité est un projet Google Cloud dédié qui fournit Identity and Access Management (IAM), une journalisation, une surveillance et une sécurité centralisées pour l'ensemble de la plate-forme. Ce hub comprend les composants suivants :
|
| Projets locataires |
Chaque projet locataire est un projet Google Cloud dédié à chaque unité commerciale. Les projets locataires individuels sont des environnements isolés qui incluent les composants suivants :
|
Flux agentique
L'exemple de système multilocataire de l'architecture précédente présente le flux suivant :
- La requête d'un utilisateur est acheminée via un équilibreur de charge d'application externe. Dans le hub de routage, ces vérifications sont effectuées pour s'assurer que seul le trafic authentifié et sécurisé atteint le portail d'interface :
- Cloud Armor applique des stratégies de sécurité pour absorber les attaques par déni de service distribué (DDoS) initiales basées sur le protocole réseau de couche 4. Cloud Armor inspecte la requête et filtre le trafic malveillant, comme les injection SQL (SQLi), les scripts intersites (XSS) et les signatures de robots connus.
- Model Armor intercepte la charge utile pour détecter et rejeter les attaques par injection de prompt ou les intentions malveillantes.
- Si l'une de ces couches détecte une menace ou un accès non autorisé, l'équilibreur de charge abandonne la requête à la périphérie du réseau.
- Si les couches de sécurité ne détectent aucune menace et valident l'accès de l'utilisateur, l'équilibreur de charge achemine le trafic vers le service de backend.
- Si la requête est validée par toutes les vérifications, l'équilibreur de charge l'achemine vers la plate-forme d'interface, qui effectue les actions suivantes :
- Extrait l'identité de l'utilisateur, comme son unité commerciale ou son ID de locataire.
- Utilise IAP pour vérifier l'identité professionnelle de l'utilisateur et l'état de l'appareil.
- Utilise un registre géré de manière dynamique pour identifier le locataire cible approprié.
- Le portail de l'interface transfère la requête au locataire. Pour s'assurer que l'agent ne peut pas accéder à d'autres projets de locataire ni à des services Google Cloudnon autorisés, Agent Runtime utilise une règle PAB pour limiter les ressources auxquelles l'agent peut accéder.
- Model Armor utilise Sensitive Data Protection pour inspecter et masquer dynamiquement les informations permettant d'identifier personnellement l'utilisateur ou le contenu soumis à restriction. Model Armor effectue une vérification supplémentaire des injections de prompt malveillantes à partir de la requête pour s'assurer que l'agent ne traite que des données sécurisées.
Gemini effectue les tâches suivantes pour générer une réponse :
- Effectue une première passe de raisonnement pour comprendre l'intention de l'utilisateur.
- Si Gemini détermine qu'il manque des faits spécifiques, il génère un plan pour appeler les outils de données spécifiques du locataire :
- Pour vérifier si un utilisateur est autorisé à accéder aux ressources de données, l'agent vérifie son identité et ses liaisons de rôle IAM.
- Pour récupérer le contexte, l'agent exécute un appel d'outil via le serveur MCP vers le datastore du locataire.
- L'agent crée une réponse ancrée en combinant sa logique interne avec les faits spécifiques au locataire nouvellement récupérés.
Si Gemini n'a pas besoin d'informations supplémentaires, il génère une réponse et l'envoie à Model Armor.
Model Armor inspecte et masque dynamiquement toute information permettant d'identifier personnellement l'utilisateur ou tout contenu soumis à restriction, puis envoie la réponse nettoyée à l'agent du locataire. Cette dernière inspection permet de s'assurer qu'aucune donnée sensible ne fuit dans le résultat.
La réponse est renvoyée à l'utilisateur depuis l'agent du locataire, en passant par la plate-forme d'interface, puis par l'équilibreur de charge.
Produits utilisés
Cette architecture de référence utilise les produits et outils Open Source suivants, choisis pour leur nature sans serveur, leur évolutivité et leurs fonctionnalités de sécurité : Google Cloud
- VPC Service Controls : fonctionnalité réseau gérée qui minimise les risques d'exfiltration de données pour vos ressources Google Cloud .
- Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
- Google Cloud Armor : service de sécurité réseau qui propose des règles de pare-feu d'application Web (WAF) et aide à se protéger contre les attaques DDoS et d'applications.
- 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.
- Identity-Aware Proxy (IAP) : service qui permet d'adopter un modèle d'accès zéro confiance pour vos applications et vos machines virtuelles.
- Identity and Access Management (IAM) : système qui vous permet de créer et de gérer des autorisations pour les ressources Google Cloud .
- Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
- Gemini Enterprise Agent Platform : une plate-forme complète qui vous permet de créer, de faire évoluer, de gérer et d'optimiser des agents IA de niveau entreprise.
- Gemini: famille de modèles d'IA multimodaux développés par Google.
- Model Context Protocol (MCP) : norme Open Source permettant de connecter des applications d'IA à des systèmes externes.
- Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
Cas d'utilisation
Les systèmes d'IA agentique mutualisés conviennent aux entreprises qui souhaitent étendre les déploiements d'IA générative au-delà d'une seule application. Pour identifier les cas d'utilisation auxquels cette architecture convient, analysez vos processus métier et identifiez les différentes équipes qui ont besoin de leurs propres agents d'IA spécialisés, qui accèdent à des outils uniques et à des données sensibles. Cette approche vous aide à donner aux équipes décentralisées des capacités d'IA autonomes tout en conservant une sécurité et une conformité d'entreprise unifiées.
Voici un exemple de cas d'utilisation pour un système d'IA agentique mutualisé.
Service client à l'échelle de l'entreprise
Vous pouvez adapter cette architecture de référence pour fournir un service client optimisé par l'IA dans différentes divisions commerciales. Par exemple, pour prendre en charge une division électronique et une division d'articles pour la maison, vous déployez un agent électronique et un agent d'articles pour la maison en tant qu'agents distincts dans des projets locataires distincts. Ces agents IA spécialisés agissent comme des assistants intelligents qui traitent les demandes d'assistance spécifiques à une division en accédant à des spécifications techniques, des garanties ou des conditions de retour uniques. Cette automatisation permet aux équipes d'assistance humaine de se concentrer sur les escalades client plus complexes.
Pour ce cas d'utilisation, l'architecture offre les avantages suivants :
- Isolation stricte des données : la conception mutualisée garantit que les connaissances sur l'assistance pour chaque division sont strictement isolées. Le règlement PAB fournit des garde-fous qui permettent de s'assurer qu'une identité d'agent dans un locataire ne peut pas accéder aux données d'un autre locataire.
- Connaissances spécialisées des agents : comme chaque agent réside dans un projet locataire isolé, il ne récupère le contexte que depuis son datastore spécifique à la division. Cette récupération ciblée garantit une grande précision et empêche l'agent de confondre les règles de différentes unités commerciales.
- Réduction des risques interdomaines : l'architecture permet d'éliminer le risque d'exposition des données entre les unités commerciales. Même si l'identité d'un agent est compromise, l'agent ne peut pas accéder aux ressources Google Cloud non autorisées.
Cette architecture est idéale pour les grandes entreprises et organisations commerciales qui gèrent plusieurs marques ou unités commerciales distinctes et qui ont besoin d'une souveraineté des données stricte.
Alternatives de conception
Cette section présente d'autres approches de conception que vous pouvez envisager pour votre déploiement d'IA agentique mutualisée dans Google Cloud.
Déploiement de l'accès privé
Dans l'architecture décrite dans ce document, les utilisateurs accèdent au système d'IA agentique multitenant sur l'Internet public via un équilibreur de charge d'application externe exposé de manière centralisée. Si votre organisation a besoin d'un système qui reste inaccessible depuis l'Internet public, vous pouvez adapter l'architecture pour utiliser l'une des stratégies d'accès privé suivantes.
Bloquer le trafic avec des règles de sécurité de périphérie
Pour autoriser le trafic uniquement à partir des adresses IP professionnelles validées de votre organisation, vous pouvez configurer des règles de sécurité Cloud Armor afin de refuser tout autre trafic. Cette règle de sécurité de haute priorité bloque toutes les requêtes non autorisées à la périphérie du réseau. Pour ajouter une couche de sécurité, vous pouvez utiliser IAP pour exiger une session d'identité d'entreprise valide et configurer les autorisations IAM pour tous les utilisateurs.
Cette approche vous permet de tirer parti des stratégies de sécurité périphériques Cloud Armor pour décharger l'atténuation des attaques DDoS et le filtrage WAF, comme SQLi et XSS, et offre une expérience Zero Trust. Toutefois, l'adresse IP d'interface de l'équilibreur de charge d'application externe reste publique et peut ne pas répondre aux exigences de conformité de certaines organisations.
Acheminer le trafic via un équilibreur de charge d'application interne
L'architecture décrite dans ce document utilise un équilibreur de charge d'application externe, qui fournit des règles Cloud Armor robustes, des fonctionnalités de sécurité plus avancées et une complexité opérationnelle moindre par rapport aux équilibreurs de charge internes. Toutefois, l'utilisation d'un équilibreur de charge externe signifie que le trafic transite par l'Internet public.
Pour que le trafic reste entièrement au sein du réseau Google privé, vous pouvez utiliser un équilibreur de charge d'application interne. L'utilisation d'un équilibreur de charge d'application interne est compatible avec IAP pour la validation de l'identité. Un équilibreur de charge d'application externe global évalue les règles IAP au niveau de la périphérie. En revanche, un équilibreur de charge d'application interne évalue les règles au niveau de la couche réseau interne. Comme le trafic ne transite jamais par l'Internet public, l'utilisation d'un équilibreur de charge d'application interne vous aide à répondre aux exigences strictes en matière de souveraineté des données et d'absence d'adresse IP publique.
Pour maintenir une faible latence et respecter les exigences régionales en matière de résidence des données, déployez un équilibreur de charge d'application interne régional dans chaque région principale. Avec un équilibreur de charge d'application interne régional, vous acheminez le trafic des environnements sur site via Cloud Interconnect ou Cloud VPN directement vers l'adresse IP interne de l'équilibreur de charge. Un équilibreur de charge d'application interne régional est compatible avec Cloud Armor régional pour la protection WAF interne. Toutefois, par rapport à un équilibreur de charge d'application externe, les équilibreurs de charge d'application internes régionaux sont compatibles avec un ensemble limité de règles de sécurité Cloud Armor, ne disposent pas de fonctionnalités de sécurité avancées et augmentent la complexité opérationnelle.
Pour minimiser davantage la latence et garantir une haute disponibilité afin de répondre à vos exigences de reprise après sinistre, vous pouvez déployer un équilibreur de charge d'application interne interrégional. Avec un équilibreur de charge d'application interne interrégional, vous utilisez Cloud DNS avec des règles de routage par géolocalisation pour résoudre l'URL interne de l'application en équilibreur de charge d'application interne interrégional dans la régionGoogle Cloud la plus proche de l'utilisateur. Toutefois, une configuration multirégionale n'est pas compatible avec l'intégration Cloud Armor.
Infrastructure de calcul
Pour privilégier une approche axée sur le sans serveur, qui facilite la gestion et réduit les frais opérationnels, l'architecture de ce document utilise Cloud Run pour son infrastructure de calcul. Vous pouvez également exécuter des applications conteneurisées sur des clusters GKE. Google Kubernetes Engine (GKE) est un moteur d'orchestration de conteneurs qui automatise le déploiement, le scaling et la gestion des applications conteneurisées. GKE est entièrement compatible avec les équilibreurs de charge d'application internes et externes. Pour savoir comment choisir un service de calcul pour vos charges de travail sur Google Cloud, consultez Héberger des applications surGoogle Cloud.
Serveurs MCP (Model Context Protocol)
Pour permettre aux composants de votre système agentique d'interagir, vous devez établir des protocoles de communication clairs. MCP est un protocole ouvert qui fournit une interface standardisée permettant aux agents d'accéder aux outils, aux données et aux autres services nécessaires, et de les utiliser.
Pour connecter vos agents locataires à votre datastore, tenez compte des exigences de votre application pour choisir parmi les options de déploiement de serveur MCP suivantes. Lorsque vous choisissez entre des déploiements MCP locaux et partagés, tenez compte des compromis entre l'isolement des données et l'efficacité opérationnelle.
Serveur MCP local : un serveur MCP local ou spécifique à un locataire est un serveur MCP que vous déployez dans chaque projet locataire et qui permet aux agents d'accéder aux datastores et aux outils spécifiques à cette unité commerciale.
Voici les principales caractéristiques et considérations concernant les serveurs MCP locaux :
- Réseau : un périmètre VPC Service Controls au niveau du projet et une règle PAB offrent une sécurité et une isolation intrinsèques, ce qui permet de s'assurer qu'aucun accès inter-locataire n'est possible.
- Gestion : les équipes de développement et d'opérations individuelles gèrent les projets de locataire de manière indépendante. Cette isolation permet à chaque unité commerciale d'être autonome.
- Sécurité : les limites IAM fixes du projet locataire permettent de minimiser les surfaces de risque latéral et ne nécessitent pas de mappages d'identité complexes.
Les serveurs MCP locaux offrent une isolation maximale et peuvent gérer l'accès aux données très sensibles ou réglementées. Toutefois, si vous déployez plusieurs serveurs MCP locaux, vous augmentez votre charge opérationnelle. Nous recommandons les serveurs MCP locaux pour les applications qui nécessitent un accès restrictif aux data stores pouvant contenir des informations sensibles.
Serveur MCP partagé : un serveur MCP partagé, ou un serveur MCP global, est un serveur MCP que vous déployez dans un projet de services partagés. Les serveurs MCP partagés permettent d'accéder à des outils et des systèmes communs à plusieurs locataires.
Voici les principales fonctionnalités et considérations concernant les serveurs MCP partagés :
- Réseau : pour s'assurer que le trafic ne transite pas par l'Internet public, les serveurs MCP partagés nécessitent une connectivité privée, telle que Private Service Connect ou l'appairage de réseaux VPC.
- Gestion : une équipe opérationnelle centralisée gère l'implémentation pour l'ensemble du système. Cette gestion consolidée optimise l'efficacité opérationnelle et élimine la nécessité de dupliquer les implémentations locales sur plusieurs locataires.
- Sécurité : vous propagez de manière sécurisée l'identité de l'utilisateur final depuis l'agent du projet locataire vers le serveur MCP partagé. Pour s'assurer que les utilisateurs ne peuvent accéder qu'aux données auxquelles ils sont autorisés ou les modifier, le serveur MCP partagé utilise l'identité utilisateur propagée pour appliquer un contrôle précis des accès sur le système backend.
Les serveurs MCP partagés centralisent la gestion des outils courants, ce qui réduit la duplication et optimise l'efficacité opérationnelle. Bien que les serveurs MCP partagés réduisent la charge de gestion, ils nécessitent une propagation d'identité et une logique d'autorisation robustes pour maintenir un accès sécurisé. Nous recommandons d'utiliser des serveurs MCP partagés pour les interactions avec les systèmes et outils d'entreprise courants, tels que les outils de gestion des notes de frais, les systèmes de ressources humaines (RH), les bases de connaissances à l'échelle de l'entreprise ou les gestionnaires de présence.
Dans cette architecture, vous utilisez des serveurs MCP pour standardiser la connexion entre vos agents de locataire et vos data stores. En fonction des exigences de votre charge de travail, vous pouvez utiliser d'autres types d'outils d'agent pour connecter vos agents à des API et systèmes externes spécifiques. Pour en savoir plus sur les interactions entre les outils de l'agent, consultez Outils de l'agent.
Considérations de conception
Les sections suivantes décrivent les facteurs de conception, les bonnes pratiques et les recommandations à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, de coût et de performances. Les conseils de cette section ne sont pas exhaustifs. En fonction des exigences de votre charge de travail et des produits et fonctionnalités que vous utilisez, il peut y avoir d'autres facteurs de conception et compromis à prendre en compte.
Sécurité, confidentialité et conformité
Cette section décrit les considérations et recommandations de conception pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité, de confidentialité et de conformité de votre charge de travail.
| Composant | Remarques et recommandations concernant la conception |
|---|---|
| Cloud privé virtuel (VPC) | Isolation des locataires : dans cette architecture, vous déployez chaque locataire dans un projet Google Cloud dédié. Pour créer une limite de sécurité stricte, combinez l'isolation au niveau du projet locataire avec la règle PAB et VPC Service Controls au niveau de l'organisation. |
| IAM | Contrôle des accès : pour appliquer le principe du moindre privilège, utilisez un modèle d'accès basé sur les personas. Par exemple, vous pouvez définir des rôles IAM personnalisés pour vous assurer qu'un développeur qui crée un agent dans un locataire ne peut pas accéder aux données d'un autre locataire. |
| Cloud Armor |
Protection WAF interne et en périphérie : Cloud Armor offre une protection WAF et de sécurité pour défendre le portail d'interface utilisateur contre les attaques DDoS et les failles Web. Un équilibreur de charge d'application externe global est compatible avec l'ensemble des fonctionnalités de périphérie avancées, telles que la gestion des robots et la protection adaptative Google Cloud Armor. Si vous déployez un équilibreur de charge d'application interne régional, Cloud Armor fonctionne avec un ensemble limité de règles WAF standards. L'ensemble de règles restreint est adapté aux limites du réseau interne. Il inclut des règles telles que la protection contre l'injection SQL et les scripts intersites (XSS). Pour en savoir plus, consultez Intégrer Cloud Armor à d'autres produits Google. |
| Agent Platform | Points de terminaison de modèle partagés : pour éviter les utilisations abusives et garantir une utilisation équitable des points de terminaison de modèle partagés, implémentez l'une des stratégies suivantes :
|
| Cloud Run | Rendu du contenu : pour améliorer la sécurité du portail frontend, privilégiez le rendu côté serveur (SSR) au rendu côté client (CSR). Par rapport au rendu côté client (CSR), le rendu côté serveur (SSR) offre les avantages suivants :
|
| Security Command Center | Surveillance centralisée de la sécurité : pour surveiller les menaces et appliquer des règles de sécurité telles que l'authentification multifacteur (MFA) et le chiffrement des données, utilisez les outils du Security Command Center. |
Autres recommandations de sécurité
- Google Cloud Well-Architected Framework : enjeux spécifiques à l'IA et au ML : sécurité
- L'approche de Google pour sécuriser les agents d'IA : présentation
Fiabilité
Cette section décrit les considérations de conception et les recommandations pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.
| Composant | Remarques et recommandations concernant la conception |
|---|---|
| Cloud Load Balancing | Routage mondial : un équilibreur de charge d'application externe mondial fournit une seule adresse IP Anycast qui achemine automatiquement le trafic utilisateur vers la périphérie Google la plus proche géographiquement. Cette configuration réduit la latence grâce à la terminaison Secure Sockets Layer (SSL) en périphérie. Il assure également une haute disponibilité si une région connaît une panne, car il redirige intelligemment le trafic vers des backends régionaux opérationnels. |
| Locataire | Tolérance aux pannes : pour tolérer ou gérer les échecs au niveau de l'agent, déployez les agents dans des projets locataires isolés. Cette isolation permet de garantir que les problèmes opérationnels ou les incidents de sécurité restent confinés à une seule unité commerciale et n'affectent pas les autres ressources ni unités commerciales. |
| Agent Platform | Planification de la capacité : si le nombre de requêtes adressées au modèle dépasse la capacité allouée, le modèle renvoie le code d'erreur 429. Pour les charges de travail critiques pour l'entreprise et qui nécessitent un débit élevé constant, vous pouvez réserver le débit à l'aide du débit provisionné. |
| Agent Runtime |
Évolutivité sans serveur : les agents déployés sur Agent Runtime évoluent de manière indépendante en fonction de la demande. Une augmentation soudaine de l'utilisation dans un locataire n'épuise pas les ressources de calcul ni n'affecte la disponibilité d'un agent dans un autre projet locataire. Gestion des erreurs : pour gérer les erreurs temporaires telles que les limites de fréquence du code d'erreur 429, la logique d'orchestration de l'agent utilise un intervalle exponentiel entre les tentatives. Si un délai de contexte est dépassé, l'agent effectue un arrêt progressif et renvoie une progression partielle à l'utilisateur. Par exemple, un délai de contexte peut être dépassé en raison de la lenteur des appels d'outils, de la latence des API tierces, du traitement d'ensembles de données volumineux ou d'un traitement nécessitant beaucoup de ressources de calcul. |
Pour obtenir des principes et des recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : fiabilité dans le framework Well-Architected.
Efficacité opérationnelle
Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir une topologie Google Cloud que vous pouvez exploiter efficacement.
| Composant | Remarques et recommandations concernant la conception |
|---|---|
| Google Cloud Observability | Surveillance centralisée : Logging et Monitoring vous permettent de surveiller l'état et les performances de l'ensemble de la plate-forme. Vous pouvez configurer des alertes pour détecter et résoudre les problèmes de manière proactive sans autoriser l'accès aux données sensibles. |
| Tous les produits de l'architecture | Déploiements standardisés : l'utilisation de la plate-forme d'agent dans un modèle d'architecture de locataire standardisé vous permet d'établir une base de référence cohérente lorsque vous intégrez de nouveaux locataires. Pour réduire la charge opérationnelle, automatisez le processus de déploiement à l'aide d'outils Infrastructure as Code (IaC) comme Terraform. Pour obtenir le code Terraform que vous pouvez utiliser pour créer et déployer un système d'IA agentique multitenant, consultez la section Déploiement de ce document. |
Pour obtenir des principes et des recommandations d'excellence opérationnelle spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : excellence opérationnelle dans le framework Well-Architected.
Optimisation des coûts
Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'une topologie Google Cloud que vous créez à l'aide de cette architecture de référence.
| Composant | Remarques et recommandations concernant la conception |
|---|---|
| Agent Platform |
Consommation de jetons : pour gérer les coûts et éviter que votre modèle d'IA ne dépasse les fenêtres de contexte, utilisez les stratégies suivantes pour gérer le contexte du modèle d'IA :
Points de terminaison de modèle : pour gérer les quotas d'API et l'utilisation des ressources, vous pouvez déployer des points de terminaison Agent Platform dans une configuration dédiée ou partagée :
Pour en savoir plus sur les coûts sur Agent Platform, consultez Coût de création et de déploiement de modèles d'IA dans Agent Platform. |
| Cloud Run | Instrumentation : l'instrumentation vous permet de surveiller les performances, de résoudre les problèmes et de suivre l'utilisation des ressources pour chaque locataire. Pour identifier le locataire de chaque requête, extrayez l'identité de l'utilisateur à partir du contexte fourni par IAP. Pour savoir comment instrumenter votre application, consultez Choisir une approche d'instrumentation. |
| Model Armor | Filtrage centralisé des requêtes : pour appliquer une gouvernance stricte et une posture zéro confiance, cette architecture déploie Model Armor à deux niveaux : dans le hub de routage et dans chaque projet locataire. Bien que cette approche à deux niveaux contribue à assurer la souveraineté des données, elle augmente la latence et les coûts opérationnels. Pour réduire les coûts et la complexité du système, filtrez tous les prompts et toutes les réponses en déployant Model Armor exclusivement dans le hub de routage. |
| Tous les produits de l'architecture |
Infrastructure partagée : les composants d'infrastructure de base partagés, tels que le portail d'interface utilisateur, le hub central de gouvernance et de sécurité, et Agent Platform, peuvent réduire les coûts par rapport à la création d'une pile personnalisée distincte pour chaque agent. Frais généraux de la plate-forme : pour répartir les coûts partagés du hub central de gouvernance et de sécurité, utilisez un modèle d'allocation adapté à vos capacités de suivi et à vos modèles d'utilisation. Nous vous recommandons d'utiliser l'un des modèles de répartition des coûts suivants :
Pour en savoir plus sur la répartition des coûts des services partagés, consultez FinOps cloud : répartition des coûts des services partagés. Gestion centralisée des coûts : pour suivre précisément le coût total de possession (TCO) de votre système d'IA agentique et attribuer les coûts à chaque unité commerciale, utilisez des libellés et les données d'exportation Cloud Billing. Pour en savoir plus sur l'utilisation des libellés pour la sensibilisation aux coûts, consultez Promouvoir une culture de sensibilisation aux coûts. |
Pour estimer le coût de vos ressources Google Cloud , utilisez le simulateur de coûtGoogle Cloud .
Pour obtenir des principes et des recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : optimisation des coûts dans le framework Well-Architected.
Déploiement
Pour déployer cette architecture de référence, utilisez l'exemple Terraform d'IA agentique multitenant disponible sur GitHub.
Étapes suivantes
- Découvrez comment créer un agent avec ADK et Agents CLI dans Agent Platform.
- Découvrez comment utiliser le serveur MCP distant Agent Platform.
- Découvrez les bonnes pratiques pour activer VPC Service Controls.
- Découvrez comment gérer les agents déployés sur Agent Runtime.
- Découvrez les bonnes pratiques pour le scaling et le trafic élevé.
- Pour mettre en œuvre des stratégies d'élévation juste à temps, découvrez comment utiliser Privileged Access Manager.
- Pour obtenir une présentation des principes et des recommandations d'architecture spécifiques aux charges de travail d'IA et de ML dans Google Cloud, consultez la perspective de l'IA et du ML dans le framework Well-Architected.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
Contributeurs
Auteurs :
- Shivank Awasthi | Architecte de solutions terrain
- Utkarsh Bhardwaj | Consultant en solutions techniques, IA agentique, applications, plates-formes cloud et infrastructure
Autres contributeurs :
- Adrian Corona | Responsable, Global Services Delivery, Sécurité
- Agnieszka Kołkiewicz | Responsable de l'IA GSD
- Anmol Sachdeva | Ingénieur en solutions publicitaires, Global Business
- Ashish Agarwal | Responsable EMEA Nord, Global Services Delivery
- Ashmita Kapoor | Responsable de l'équipe FSA pour l'IA générative et responsable de l'équipe CE pour l'IA appliquée dans la région JAPAC
- Ashutosh Gupta | Directeur, Global Service Delivery
- Aspen Sherrill | Architecte en sécurité cloud
- Chinmay Deshpande | Consultant en migration vers le cloud, Infrastructure
- Gaurav Taneja | Responsable de la livraison pour l'infrastructure, les données, l'IA et le GDC pour la région EMEA Sud
- Ishmeet Mehta | Spécialiste de la plate-forme Amérique du Nord, Apps CE
- Joanna Nowek | Consultante en transformation de l'IA
- Kumar Dhanagopal Développeur de solutions multiproduits
- Mark Schlagenhauf | Rédacteur technique, Mise en réseau
- Matthias Ziener | Responsable, Global Service Delivery
- Olu Akinrolabu | Consultant Cloud – sécurité
- Paweł Tokarski | EMEA South Infra, Data, AI, and GDC Delivery Lead
- Paweł Glica | Responsable de la pratique Core EMEA
- Prabha Arya | Ingénieur stratégique Cloud
- Samantha He | Rédactrice technique
- Suchit Puri | Responsable mondial de la pratique de l'IA
- Thomas Cliett | Directeur de delta AI
- Valentín Huerta | Ingénieur en IA