Panoramica della distribuzione degli agenti in OCI Generative AI
Puoi distribuire gli agenti utilizzando OCI Generative AI Applications, che forniscono un runtime gestito per i carichi di lavoro degli agenti containerizzati.
Per distribuire un agente, inserirlo nel package come immagine del contenitore, caricarlo in Oracle Cloud Infrastructure Registry (OCIR) e distribuirlo utilizzando la console, l'API o l'interfaccia CLI OCI.
Durante la distribuzione, configurare:
- Ridimensionamento
- Storage
- Networking
- Autenticazione
Dopo la distribuzione, il servizio esegue il provisioning di un endpoint (ad esempio, un URL HTTP) che i client o altri agenti possono utilizzare per richiamare l'agente.
Funzionamento
Dopo aver sviluppato un agente localmente, ad esempio utilizzando LangGraph o framework simili, è possibile creare un'applicazione AI generativa per definire la configurazione runtime.
È quindi possibile creare una distribuzione selezionando un'immagine contenitore. La distribuzione attiva gestisce le richieste tramite l'endpoint dell'applicazione. Dopo il provisioning della distribuzione, l'endpoint diventa disponibile per il richiamo dell'agente.
Procedura dettagliata
Utilizza le applicazioni AI generative per distribuire agenti come applicazioni gestite in container in OCI Generative AI.
Con le applicazioni di intelligenza artificiale generativa, crei un'immagine contenitore, la carichi in Oracle Cloud Infrastructure Registry (OCIR) e distribuisci quell'immagine come applicazione di intelligenza artificiale generativa utilizzando la console, l'API o l'interfaccia CLI OCI.
Quando si distribuisce un agente, è possibile configurare la modalità di esecuzione dell'applicazione e il modo in cui i client vi accedono, tra cui:
- Ridimensionamento
- Storage
- Networking
- Autenticazione
Dopo il provisioning della distribuzione, OCI Generative AI fornisce un endpoint, ad esempio un URL HTTP, che i client possono utilizzare per richiamare l'agente distribuito.
La distribuzione di un agente è utile quando si desidera un runtime gestito per un'applicazione agente containerizzata, con configurazione di distribuzione gestita da OCI e provisioning degli endpoint.
Per ulteriori informazioni, vedere gli argomenti relativi alle applicazioni AI generativa e alla distribuzione di applicazioni agente containerizzate.
Confronta le applicazioni con altre opzioni di distribuzione dei container OCI
Confronta le applicazioni di AI generativa con istanze di container OCI e Oracle Kubernetes Engine (OKE).
Le applicazioni OCI Generative AI forniscono un'opzione di distribuzione gestita per applicazioni e server MCP agenti. Le tabelle seguenti le confrontano con altre soluzioni di distribuzione dei container OCI.
Confronta le applicazioni di intelligenza artificiale generativa con le istanze di container OCI
| Funzionalità | Applicazioni GenAI | Istanze contenitore OCI |
|---|---|---|
| Uso principale | Servizi Web, in particolare applicazioni e server MCP | Processi batch, script e lavoratori |
| Avvia modello | HTTP o basato sugli eventi | Manuale, basato su API o schedulato |
| Ridimensionamento | Scalabilità automatica da 0 a molte istanze | Nessuna scalabilità automatica integrata |
| Ridimensiona a zero | Sì | Non automatico |
| Bilanciamento del carico | Built-in | Gestito dall'utente |
| Livello di astrazione | Implementazione di livello superiore in stile serverless | Esecuzione container di livello inferiore |
| Modello di avvio | Avvio rapido e basato sulle richieste | Inizia come una piccola VM |
| Networking | Endpoint HTTPS gestiti | Controllo a livello di VCN |
Confronta le applicazioni di intelligenza artificiale generativa con OKE
| Funzionalità | Applicazioni GenAI | OKE |
|---|---|---|
| Costi indiretti operazioni | Basso | Alto |
| Ridimensionamento | Ridimensionamento automatico da 0 a N | Configurabile con HPA e ridimensionamento automatico del cluster |
| Ridimensiona a zero | Sì | Non nativo |
| Distribuzione | Semplice, spingendo un'immagine contenitore | Più complesso, con file manifesto e grafici Helm |
| Controllo | Limitato | Controllo completo |
| Networking | Completamente gestito | Completamente personalizzabili |
| Caso d'uso | API e servizi senza stato | Sistemi distribuiti complessi |
Protocolli di trasporto supportati
In OCI Generative AI, dopo la distribuzione di un agente, i client possono richiamarlo tramite l'endpoint di cui è stato eseguito il provisioning. Il protocollo di trasporto dipende dall'implementazione del server agente e dal modello di interazione richiesto (sessioni di richiesta/risposta, streaming o bidirezionale).
I protocolli supportati includono:
HTTP;
HTTP è il modello di richiamo più supportato.
- Modello di interazione: richiesta/risposta senza stato
- Trasporto: HTTP/1.1 o HTTP/2 su TLS
- Caso d'uso: chiamate API sincrone e richieste di inferenza di breve durata
In questa modalità, il client invia una richiesta HTTP (in genere POST con un payload JSON). Il server restituisce una sola risposta al termine dell'elaborazione.
SSE (eventi server-inviati)
Server-Sent Events (SSE) è un protocollo di streaming unidirezionale basato su HTTP.
- Modello di interazione: da client a server (richiesta singola), da server a client (risposta in streaming)
- Trasporto: HTTP con
Content-Type: text/event-stream - Caso d'uso: risposte di streaming (ad esempio, output token per token)
In questa modalità, il client invia una richiesta e il server mantiene la connessione aperta durante lo streaming di risultati incrementali come eventi.
WebSocket (streaming duplex completo)
WebSocket fornisce una comunicazione bidirezionale e persistente tra client e server.
- Modello di interazione: Full duplex (client e server possono inviare messaggi in qualsiasi momento)
- Trasporto: protocollo WebSocket (
wss://) - Caso d'uso: agenti interattivi, esecuzione degli strumenti in tempo reale e sessioni a più turni
Dopo l'handshake di aggiornamento HTTP iniziale, la connessione rimane aperta, consentendo lo scambio bidirezionale di messaggi su un canale persistente.
Autenticazione
Impostare l'autenticazione in entrata per controllare l'accesso agli agenti e l'autenticazione in uscita per accedere in modo sicuro alle risorse OCI.
Le applicazioni supportano l'autenticazione OAuth 2.0 utilizzando un dominio di Identity. Vedere Impostazione dell'autenticazione per il supporto Agentic
Autenticazione in entrata
L'autenticazione in entrata controlla chi può accedere agli agenti convalidando i token dai provider di identità prima di instradare le richieste agli agenti ospitati.
OCI Generative AI supporta OAuth 2.0 per l'autenticazione in entrata, integrata con provider di identità come Oracle Identity Cloud Service (IDCS). Vedere Impostazione dell'autenticazione per il supporto Agentic.
Autenticazione in uscita
Con l'autenticazione in uscita, le applicazioni agente distribuite possono accedere in modo sicuro ad altre risorse OCI all'interno di una tenancy.
L'accesso viene concesso definendo i criteri IAM OCI che autorizzano l'applicazione agente (come principal risorsa) a eseguire azioni specifiche sulle risorse specificate. Questi criteri decidono l'ambito dell'accesso in base al principio di privilegio minimo.
Dopo la distribuzione, la piattaforma esegue automaticamente il provisioning di un Resource Principal Session Token (RPST) per il carico di lavoro dell'agente. L'RPST viene inserito in modo sicuro nel runtime del contenitore, consentendo all'applicazione di eseguire l'autenticazione ai servizi OCI senza utilizzare credenziali di lunga durata come chiavi API o token utente.
All'interno del contenitore, l'agente utilizza l'SDK OCI con il provider di autenticazione del principal risorsa. L'SDK recupera e aggiorna automaticamente l'RPST, consentendo l'accesso sicuro ai servizi OCI autorizzati come Object Storage, Autonomous Database, Vault e Streaming.
Networking per le distribuzioni
In OCI Generative AI, per impostazione predefinita, le applicazioni distribuite hanno accesso in uscita alla rete Internet pubblica. Ciò consente ai carichi di lavoro degli agenti di accedere a risorse esterne come server MCP pubblici, API di terze parti, endpoint del modello di base e altri servizi ospitati su Internet.
Per le reti private, è possibile abilitare la modalità di rete dei clienti. In questa modalità, puoi specificare una subnet di destinazione in una VCN all'interno della tua tenancy. La piattaforma stabilisce una connessione sicura tra il carico di lavoro dell'agente e la subnet utilizzando un endpoint di connessione privata / endpoint di connessione inversa (PE/RCE).
Quando l'opzione è abilitata, tutto il traffico in uscita (in uscita) dall'agente viene instradato tramite la subnet specificata. Ciò consente di:
- Accesso sicuro alle risorse private nella rete (ad esempio, database, istanze di computazione e servizi interni)
- Traffico per rimanere entro i confini della rete privata
- Controlli di sicurezza di rete quali i gruppi di sicurezza di rete (NSG), le tabelle di instradamento e i firewall per gestire la connettività in uscita
- Limitazione o disabilitazione dell'accesso a Internet pubblico, in base ai requisiti di sicurezza
Questo modello supporta sia i carichi di lavoro che le distribuzioni private e integrate nelle aziende, mantenendo un chiaro isolamento della rete tra la piattaforma e l'ambiente.
Storage gestito
I carichi di lavoro degli agenti spesso richiedono servizi con conservazione dello stato per supportare memoria a breve termine, checkpoint, inserimento nella cache e storage di contesto. Per semplificare le operazioni, OCI Generative AI fornisce servizi di storage completamente gestiti per gli agenti distribuiti.
Quando si distribuisce un agente, è possibile selezionare una o più delle opzioni di storage gestito riportate di seguito.
- PostgreSQL
- Cache OCI
- Oracle Autonomous Database
Questi servizi vengono forniti e configurati automaticamente per l'applicazione.
Come funziona lo storage gestito
Lo storage gestito differisce dallo storage di cui si esegue il provisioning nella propria tenancy:
-
Distribuzione gestita dal servizio
Il provisioning dello storage viene eseguito nella tenancy del servizio e non viene esposto per l'accesso esterno diretto (ad esempio, tramite client di database o endpoint pubblici).
-
Accesso con ambito applicativo
Solo l'applicazione distribuita associata può accedere al relativo storage. L'accesso è gestito dalla piattaforma, pertanto non è richiesta alcuna configurazione manuale di rete o credenziali.
-
Integrazione del ciclo di vita
Lo storage è legato al ciclo di vita dell'agente:- Creato quando l'agente viene distribuito
- Scalabilità con l'applicazione (se supportata)
- Eliminato quando l'agente viene eliminato
-
Nessuna gestione amministrativa
La piattaforma gestisce l'infrastruttura di storage. Non si dispone dell'accesso o del controllo a livello di DBA sulle risorse di base.
Quando un agente viene eliminato, lo storage gestito viene rimosso definitivamente e non può essere recuperato.
Quando utilizzare lo storage gestito dal cliente
Utilizza lo storage gestito dal cliente quando hai bisogno di:
- Ciclo di vita dello storage indipendente
- Controllo amministrativo completo
- Accesso diretto a sistemi o strumenti esterni
- Configurazione personalizzata, estensioni o accesso condiviso tra le applicazioni
In questi casi, esegui il provisioning dello storage nella tua VCN e tenancy e configura l'agente in modo che si connetta ad esso utilizzando la modalità di rete del cliente.
Questo approccio offre maggiore flessibilità e controllo sull'infrastruttura.