AWS ha introdotto una nuova versione di Amazon Bedrock AgentCore Runtime, il livello di elaborazione gestito della piattaforma AgentCore utilizzato per distribuire ed eseguire agenti AI senza dover costruire o mantenere direttamente l’infrastruttura sottostante. Il nuovo runtime modifica soprattutto la gestione della memoria e il meccanismo di avvio delle sessioni, con l’obiettivo di adattare meglio le risorse ai carichi degli agenti di lunga durata o caratterizzati da picchi intermittenti. La piattaforma mantiene il modello serverless già utilizzato da AgentCore, con isolamento delle sessioni, riduzione automatica delle risorse fino a zero e fatturazione basata sul consumo effettivo, senza addebiti per la CPU inattiva durante le operazioni di input/output. AWS afferma che migliaia di team utilizzano già AgentCore Runtime per agenti in produzione.
Nella versione precedente, una sessione conservava la memoria allocata fino alla propria conclusione anche quando parte di quella memoria non era più necessaria. Un agente che raggiungeva temporaneamente un elevato utilizzo di RAM poteva quindi continuare a mantenere allocato quel picco per tutto il resto della sessione. Il problema risultava particolarmente evidente per agenti di lunga durata o con carichi irregolari, che possono utilizzare molta memoria in alcuni momenti e rimanere quasi inattivi per periodi prolungati. Il nuovo runtime parte invece da un profilo di memoria più ridotto e porta in memoria ulteriori pagine solo quando il carico ne richiede l’utilizzo. Quando l’agente libera buffer legati a una richiesta oppure quando dati memorizzati nella cache non vengono più utilizzati, AgentCore può recuperare quella memoria senza attendere la chiusura della sessione. AWS ha messo a punto questo comportamento analizzando i modelli di allocazione osservati in miliardi di sessioni.
La seconda modifica riguarda i cold start, cioè l’avvio di un nuovo ambiente quando non è già disponibile un’istanza inizializzata. Una sessione eseguita su un ambiente già pronto può partire in meno di 100 millisecondi, ma mantenere continuamente ambienti disponibili richiede capacità di calcolo riservata. Nella maggior parte dei casi è quindi necessario creare un nuovo ambiente, recuperare l’immagine del container e inizializzare l’agente prima di elaborare la prima richiesta. Nel runtime precedente la latenza tendeva ad aumentare con le dimensioni dell’immagine e con il numero di sessioni avviate contemporaneamente, soprattutto durante improvvisi picchi di traffico. Alcuni utenti compensavano questa situazione mantenendo capacità inutilizzata pronta all’uso, ottimizzando manualmente l’allocazione della memoria o eliminando capacità in eccesso quando non era più necessaria.
Nel nuovo sistema AgentCore prepara invece l’ambiente una volta, ne crea uno snapshot e utilizza successivamente quello stato per avviare nuove istanze. Quando viene creato o aggiornato un runtime, AgentCore avvia il container, attende che superi il controllo di integrità e acquisisce uno snapshot dell’ambiente già in esecuzione. Le operazioni necessarie soltanto durante l’inizializzazione, come il caricamento di artefatti del modello o il recupero di configurazioni statiche, risultano quindi già completate. Le nuove istanze vengono avviate ripristinando lo snapshot anziché ripetendo l’intera procedura di inizializzazione. AWS elimina inoltre dallo snapshot cache e memoria transitoria non necessarie al ripristino, mantenendone le dimensioni relativamente stabili anche quando aumenta la dimensione complessiva dell’immagine del container.
AWS ha misurato il comportamento dei due runtime utilizzando un agente echo privo di chiamate a modelli o strumenti esterni, in modo da isolare il tempo introdotto dall’infrastruttura. Un client Python eseguito su un’istanza Amazon EC2 nella regione us-west-2 ha inviato richieste agli agenti distribuiti in us-east-1 tramite Internet pubblico, senza VPC peering e utilizzando l’SDK boto3. I tempi misurati comprendono quindi anche il round trip di rete tra le due regioni. Il test ha previsto 5.000 invocazioni a freddo per agente, eseguite sulle due versioni del runtime e su cinque differenti dimensioni delle immagini, mantenendosi entro le quote predefinite degli account AWS.
Secondo i risultati pubblicati da AWS, il nuovo runtime ha registrato una latenza P75 del cold start di circa 2 secondi sia con immagini da 200 MB sia con immagini fino a 2 GB. Nello stesso test la versione precedente è passata da circa 5,4 secondi con le immagini più piccole a quasi 30 secondi con quelle più grandi. L’esecuzione effettiva del codice dell’agente echo ha richiesto circa 34 millisecondi al P75, per cui quasi tutto il tempo osservato nel test era riconducibile all’avvio della piattaforma. AWS suggerisce inoltre, per applicazioni interattive come le chat, di creare la sessione non appena l’utente apre l’interfaccia, prima ancora che invii il primo messaggio: l’ambiente può così iniziare a prepararsi mentre l’utente digita la richiesta.
Anche il modello di fatturazione cambia insieme alla gestione della memoria. Il nuovo runtime contabilizza la memoria utilizzata effettivamente dall’agente, caricata quando serve e recuperata quando rimane inutilizzata, invece di mantenere contabilizzata per l’intera sessione la memoria associata al massimo utilizzo raggiunto dal container. AWS indica che la tariffa applicata alla memoria è più elevata rispetto alla versione precedente, ma viene calcolata su un numero inferiore di GB-ora. Secondo l’azienda, nella maggior parte dei carichi il calo della quantità di memoria fatturata dovrebbe superare l’aumento della tariffa unitaria, riducendo quindi il costo complessivo.
Gli sviluppatori possono utilizzare il nuovo runtime impostando il parametro platformVersion su V2 durante la creazione o l’aggiornamento di un runtime. La versione V1 rimane quella predefinita: se il parametro viene omesso durante una nuova creazione viene utilizzata V1, mentre durante un aggiornamento viene mantenuta la versione già associata al runtime. V2 è attualmente disponibile nelle regioni us-east-1, us-east-2, us-west-2, eu-west-1 e ap-northeast-1. Poiché durante la creazione o l’aggiornamento della V2 è necessario preparare l’ambiente e generarne lo snapshot, queste operazioni possono richiedere alcuni minuti prima che il runtime raggiunga lo stato READY, mentre per V1 il processo richiede normalmente pochi secondi.
Lo snapshot viene acquisito alla prima risposta valida fornita dal container all’endpoint /ping. Se il container non supera il controllo di integrità entro 120 secondi dall’avvio, la creazione del runtime viene interrotta con un errore di health check. La V2 presenta inoltre, allo stato attuale, limiti più bassi per le variabili d’ambiente: la dimensione complessiva può raggiungere 1,5 KB nelle distribuzioni dirette del codice e 2,5 KB per gli agenti basati su container, rispetto ai 4 KB consentiti dalla V1. Al momento AWS CloudFormation e AWS CDK non supportano inoltre l’impostazione del parametro platformVersion.
Gli snapshot non devono essere gestiti direttamente dagli sviluppatori, perché seguono automaticamente le versioni e gli endpoint del runtime. AgentCore prepara uno snapshot quando un endpoint viene associato a una determinata versione e lo elimina quando nessun endpoint punta più a quella versione. La rimozione può richiedere fino a otto ore, corrispondenti alla durata massima di una sessione, perché le sessioni già in esecuzione possono continuare a utilizzare lo snapshot fino alla loro conclusione. Le sessioni vengono eseguite all’interno di microVM dedicate con CPU, memoria e filesystem isolati, possono durare fino a otto ore e vengono terminate dopo 15 minuti di inattività; al termine, la microVM viene eliminata e la memoria viene sanificata.
AWS prevede di aggiungere ulteriori opzioni al nuovo runtime. Tra queste figurano una modalità con capacità di memoria minima prenotata e scontata, sulla quale poter aggiungere risorse a consumo durante i picchi, pensata soprattutto per sessioni costantemente attive; configurazioni con più RAM, vCPU e spazio di archiviazione per sessione; il supporto alle microVM x86; la possibilità di sospendere e riprendere le sessioni tramite snapshot della memoria; e hook del runtime utilizzabili per serializzare lo stato prima della terminazione di una sessione attiva. Sono inoltre previste chiavi di contesto della sessione che permetteranno di assegnare un’identità circoscritta a ciascun agente, così da definire con maggiore precisione le autorizzazioni degli agenti che operano senza supervisione continua. Per effettuare test sul nuovo runtime, AWS mette a disposizione la documentazione di AgentCore, un repository di esempi su GitHub e un esempio di load test con cui misurare i cold start direttamente all’interno del proprio account AWS.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)