Présentation du déploiement d'agents dans OCI Generative AI
Vous pouvez déployer des agents à l'aide des applications OCI Generative AI, qui fournissent une exécution gérée pour les charges globales d'agent en conteneur.
Pour déployer un agent, packagez-le en tant qu'image de conteneur, téléchargez-le vers Oracle Cloud Infrastructure Registry (OCIR) et déployez-le à l'aide de la console, de l'API ou de l'interface de ligne de commande OCI.
Au cours du déploiement, configurez :
- Redimensionnement
- Stockage
- Mise en réseau
- Authentification
Après le déploiement, le service provisionne une adresse (par exemple, une URL HTTP) que les clients ou d'autres agents peuvent utiliser pour appeler l'agent.
Fonctionnement
Après avoir développé un agent localement (par exemple, en utilisant LangGraph ou des structures similaires), vous créez une application d'IA générative pour définir la configuration d'exécution.
Vous créez ensuite un déploiement en sélectionnant une image de conteneur. Le déploiement actif traite les demandes via l'adresse d'application. Une fois le déploiement provisionné, l'adresse devient disponible pour l'appel de l'agent.
Visite virtuelle
Utilisez les applications d'IA générative pour déployer des agents en tant qu'applications en conteneur gérées dans OCI Generative AI.
Avec les applications d'IA générative, vous créez une image de conteneur, la téléchargez vers Oracle Cloud Infrastructure Registry (OCIR) et déployez cette image en tant qu'application d'IA générative à l'aide de la console, de l'API ou de l'interface de ligne de commande OCI.
Lorsque vous déployez un agent, vous pouvez configurer le mode d'exécution de l'application et la manière dont les clients y accèdent, notamment :
- Redimensionnement
- Stockage
- Mise en réseau
- Authentification
Une fois le déploiement provisionné, OCI Generative AI fournit une adresse, telle qu'une URL HTTP, que les clients peuvent utiliser pour appeler l'agent déployé.
Le déploiement d'un agent est utile lorsque vous voulez une exécution gérée pour une application d'agent en conteneur, avec une configuration de déploiement gérée par OCI et un provisionnement d'adresse.
Pour plus d'informations, reportez-vous aux rubriques sur les applications d'IA générative et le déploiement d'applications d'agent en conteneur.
Comparer des applications avec d'autres options de déploiement de conteneur OCI
Comparez les applications d'IA générative avec les instances de conteneur OCI et Oracle Kubernetes Engine (OKE).
Les applications OCI Generative AI fournissent une option de déploiement géré pour les applications agentiques et les serveurs MCP. Les tableaux suivants les comparent à d'autres solutions de déploiement de conteneurs OCI.
Comparaison des applications d'IA générative avec les instances de conteneur OCI
| Capacité | Applications d'IA générative | Instances de conteneur OCI |
|---|---|---|
| Utilisation principale | Services Web, en particulier les applications agentiques et les serveurs MCP | Travaux par lots, scripts et salariés |
| Modèle de déclencheur | HTTP ou orienté événement | Manuel, orienté API ou programmé |
| Redimensionnement | Redimensionnement automatique de 0 à plusieurs instances | Pas de redimensionnement automatique intégré |
| Redimensionner à zéro | Oui | Non automatique |
| Equilibrage de charge | Intégré | Géré par l'utilisateur |
| Niveau d'abstraction | Déploiement de niveau supérieur sans serveur | Exécution de conteneurs de niveau inférieur |
| Modèle de démarrage | Démarrage rapide, basé sur les demandes | Commence comme une petite machine virtuelle |
| Fonctions de réseau | Adresses HTTPS gérées | Contrôle au niveau du VCN |
Comparer les applications d'IA générative avec OKE
| Capacité | Applications d'IA générative | OKE |
|---|---|---|
| Frais généraux des opérations | Bas | Haut |
| Redimensionnement | Mise à l'échelle automatique de 0 à N | Configurable avec le HPA et le redimensionnement automatique de cluster |
| Redimensionner à zéro | Oui | Non natif |
| Déploiement | Simple, en poussant une image de conteneur | Plus complexe, avec des manifestes et des graphiques Helm |
| Contrôle | Limité | Contrôle total |
| Fonctions de réseau | Entièrement géré | Entièrement personnalisables |
| Cas d'emploi | API et services sans état | Systèmes distribués complexes |
Protocoles de transport pris en charge
Dans OCI Generative AI, une fois qu'un agent est déployé, les clients peuvent l'appeler via l'adresse provisionnée. Le protocole de transport dépend de l'implémentation du serveur d'agent et du modèle d'interaction requis (demande/réponse, transmission en continu ou sessions bidirectionnelles).
Les protocoles pris en charge incluent :
protocole HTTP
HTTP est le modèle d'appel le plus pris en charge.
- Modèle d'interaction : demande/réponse sans conservation de statut
- Transport : HTTP/1.1 ou HTTP/2 sur TLS
- Cas d'utilisation : appels d'API synchrones et demandes d'inférence de courte durée
Dans ce mode, le client envoie une demande HTTP (généralement POST avec une charge utile JSON). Le serveur renvoie une seule réponse une fois le traitement terminé.
SSE (événements envoyés par le serveur)
Server-Sent Events (SSE) est un protocole de transmission en continu unidirectionnel basé sur HTTP.
- Modèle d'interaction : client à serveur (demande unique), serveur à client (réponse en flux)
- Transport : HTTP avec
Content-Type: text/event-stream - Cas d'utilisation : réponses Streaming (par exemple, sortie jeton par jeton)
Dans ce mode, le client envoie une demande et le serveur garde la connexion ouverte tout en diffusant les résultats incrémentiels en tant qu'événements.
Socket Web (diffusion en continu duplex intégral)
WebSocket fournit une communication bidirectionnelle persistante entre le client et le serveur.
- Modèle d'interaction : duplex complet (le client et le serveur peuvent envoyer des messages à tout moment)
- Transport : protocole WebSocket (
wss://) - Cas d'utilisation : agents interactifs, exécution d'outils en temps réel et sessions multi-tours
Après l'établissement de liaison de mise à niveau HTTP initial, la connexion reste ouverte, ce qui permet l'échange de messages bidirectionnel sur un canal persistant.
Authentification
Configurez l'authentification entrante pour contrôler l'accès aux agents et l'authentification sortante pour accéder en toute sécurité aux ressources OCI.
Les applications prennent en charge l'authentification OAuth 2.0 via un domaine d'identité. Reportez-vous à Configuration de l'authentification pour la prise en charge d'Agentic
Authentification entrante
L'authentification entrante contrôle qui peut accéder à vos agents en validant les jetons des fournisseurs d'identités avant d'acheminer les demandes vers les agents hébergés.
OCI Generative AI prend en charge OAuth 2.0 pour l'authentification entrante, intégrée à des fournisseurs d'identités tels qu'Oracle Identity Cloud Service (IDCS). Reportez-vous à Configuration de l'authentification pour la prise en charge Agentic.
Authentification sortante
Grâce à l'authentification sortante, les applications d'agent déployées peuvent accéder en toute sécurité à d'autres ressources OCI au sein d'une location.
L'accès est accordé en définissant des stratégies OCI IAM qui autorisent l'application d'agent (en tant que principal de ressource) à effectuer des actions spécifiques sur les ressources indiquées. Ces stratégies déterminent la portée de l'accès en fonction du principe du moindre privilège.
Après le déploiement, la plate-forme provisionne automatiquement un jeton de session de principal de ressource (RPST) pour la charge globale de l'agent. Le RPST est injecté en toute sécurité dans l'exécution de conteneur, ce qui permet à l'application de s'authentifier auprès des services OCI sans utiliser d'informations d'identification de longue durée telles que des clés d'API ou des jetons utilisateur.
Dans le conteneur, l'agent utilise le kit SDK OCI avec le fournisseur d'authentification du principal de ressource. Le kit SDK extrait et actualise automatiquement le RPST, ce qui permet un accès sécurisé aux services OCI autorisés tels qu'Object Storage, Autonomous Database, Vault et Streaming.
Mise en réseau pour les déploiements
Dans OCI Generative AI, par défaut, les applications déployées disposent d'un accès sortant à l'Internet public. Cela permet aux charges de travail des agents d'accéder à des ressources externes telles que des serveurs MCP publics, des API tierces, des adresses de modèle de base et d'autres services hébergés sur Internet.
Pour la mise en réseau privée, vous pouvez activer le mode de mise en réseau client. Dans ce mode, vous indiquez un sous-réseau cible dans un VCN de votre location. La plate-forme établit une connexion sécurisée entre la charge globale de l'agent et le sous-réseau à l'aide d'une adresse privée/d'une adresse de connexion inverse (PE/RCE).
Lorsque cette option est activée, tout le trafic sortant (sortant) de l'agent est acheminé via le sous-réseau indiqué. Cela permet :
- Accès sécurisé aux ressources privées du réseau (par exemple, bases de données, instances de calcul et services internes)
- Trafic restant dans les limites du réseau privé
- Contrôles de sécurité réseau tels que les groupes de sécurité réseau, les tables de routage et les pare-feu pour régir la connectivité sortante
- Restriction ou désactivation de l'accès Internet public, en fonction de vos exigences de sécurité
Ce modèle prend en charge à la fois les charges de travail Internet et les déploiements privés intégrés à l'entreprise, tout en maintenant une isolation réseau claire entre la plate-forme et votre environnement.
Stockage géré
Les charges de travail des agents nécessitent souvent des services avec conservation de statut pour prendre en charge la mémoire à court terme, les points de reprise, la mise en cache et le stockage contextuel. Pour simplifier les opérations, OCI Generative AI fournit des services de stockage entièrement gérés pour les agents déployés.
Lors du déploiement d'un agent, vous pouvez sélectionner une ou plusieurs des options de stockage géré suivantes :
- PostgreSQL
- OCI Cache
- Oracle Autonomous Database
Ces services sont provisionnés et configurés automatiquement pour votre application.
Fonctionnement du stockage géré
Le stockage géré diffère du stockage que vous provisionnez dans votre propre location :
-
Déploiement géré par le service
Le stockage est provisionné dans la location de service et n'est pas exposé pour un accès externe direct (par exemple, via des clients de base de données ou des adresses publiques).
-
Accès de portée application
Seule l'application déployée associée peut accéder à son stockage. L'accès est géré par la plate-forme. Aucune configuration manuelle des informations d'identification ou de réseau n'est donc requise.
-
Intégration du cycle de vie
Le stockage est lié au cycle de vie de l'agent :- Créé lors du déploiement de l'agent
- Evolue avec l'application (si elle est prise en charge)
- Supprimé lorsque l'agent est supprimé
-
Aucune gestion administrative
La plate-forme gère l'infrastructure de stockage. Vous ne disposez pas d'un accès ou d'un contrôle de niveau DBA sur les ressources sous-jacentes.
Lorsqu'un agent est supprimé, son stockage géré est définitivement enlevé et ne peut pas être récupéré.
Quand utiliser le stockage géré par le client
Utilisez le stockage géré par le client lorsque vous en avez besoin :
- Cycle de vie du stockage indépendant
- Contrôle administratif complet
- Accès direct à partir de systèmes ou d'outils externes
- Configuration personnalisée, extensions ou accès partagé entre les applications
Dans ce cas, provisionnez le stockage dans votre propre VCN et location, et configurez l'agent pour qu'il se connecte à l'aide du mode de mise en réseau client.
Cette approche offre une plus grande flexibilité et un meilleur contrôle sur votre infrastructure.