The Pulse
AWS riprogetta AgentCore Runtime attorno a memoria elastica e snapshot
AWS ha rilasciato una nuova versione di Amazon Bedrock AgentCore Runtime che recupera la memoria inutilizzata delle sessioni e ripristina snapshot preparati, per rendere più prevedibili gli avvii a freddo. Secondo l’azienda, il runtime ragg
AI.info Team ·
AWS punta sui due costi che complicano AgentCore
AWS sta cambiando il modello di esecuzione alla base di Amazon Bedrock AgentCore Runtime per affrontare la tensione tra l’economia del serverless e i ritardi di avvio che possono verificarsi quando gli agenti in produzione usano container di grandi dimensioni o arrivano a raffiche.
Il nuovo runtime, annunciato il 18 settembre 2026, recupera memoria quando le sessioni smettono di usarla e avvia nuove istanze da snapshot preparate, invece di inizializzare ogni ambiente da zero. AWS afferma che le modifiche sono pensate per mantenere il modello di AgentCore con scalabilità fino a zero, riducendo al contempo la dipendenza degli avvii a freddo dalle dimensioni dei container e dalla concorrenza.
AgentCore Runtime offre già ambienti di esecuzione isolati, scalabilità automatica e fatturazione basata sul consumo. Il vecchio design poteva tuttavia trattenere la memoria fino alla fine di una sessione: di conseguenza, un agente con attività prolungate o a raffiche poteva continuare a pagare per il picco massimo di memoria anche dopo il calo del carico di lavoro. Inoltre, gli avvii a freddo diventavano più lenti man mano che le immagini crescevano e arrivavano più sessioni contemporaneamente.
Due secondi per immagini da 200 MB a 2 GB
AWS ha testato il runtime nuovo e quello originale con un agente echo vuoto, che restituiva il proprio input senza chiamare un modello o uno strumento. Il test ha usato un client Python su un’istanza Amazon Elastic Compute Cloud in us-west-2, che chiamava agenti in us-east-1 tramite Internet pubblico. AWS ha inviato 5.000 invocazioni a freddo per agente, con cinque dimensioni di immagine e entrambe le versioni del runtime.
In questa configurazione, il nuovo runtime ha registrato una latenza di avvio a freddo al 75° percentile di circa due secondi per immagini da 200 MB a 2 GB. AWS afferma che il runtime originale passava da circa 5,4 secondi per l’immagine più piccola a quasi 30 secondi per quella più grande.
Le misurazioni includono il tempo di andata e ritorno della rete tra le regioni, quindi non rappresentano una misurazione pura del tempo di avvio interno della piattaforma. AWS distingue inoltre l’avvio del runtime dal tempo che un agente impiega a ragionare e a chiamare modelli. Nel test echo, il codice dell’agente stesso è stato eseguito in circa 34 millisecondi al 75° percentile, facendo dell’avvio la principale fonte di ritardo in quello specifico benchmark.
Il risultato è una misurazione di AWS, non un confronto indipendente con altri servizi di hosting per agenti. Mostra però il problema specifico che AgentCore è progettato per affrontare: le dimensioni dell’immagine hanno un effetto molto minore sulla risposta iniziale del nuovo runtime.
AgentCore carica una volta, poi ripristina
Il nuovo runtime modifica il modo in cui AWS prepara ogni sessione. Quando un runtime viene creato o aggiornato, AgentCore avvia il container, attende che diventi operativo e acquisisce uno snapshot al termine dell’inizializzazione una tantum. Il caricamento degli artefatti del modello e il recupero della configurazione statica possono quindi avvenire prima dell’inizio di una singola sessione.
Le nuove istanze ripristinano lo stato preparato anziché ripetere l’intera sequenza di inizializzazione. AWS afferma inoltre di eliminare le cache e la memoria transitoria dallo snapshot, mantenendo il profilo ripristinato pressoché stabile al crescere dell’immagine del container.
L’approccio è simile all’avvio basato su snapshot descritto nella documentazione per sviluppatori di AgentCore. La documentazione afferma che la nuova piattaforma V2 avvia gli agenti da uno snapshot per mantenere costanti gli avvii a freddo a prescindere dai livelli di concorrenza e dalle dimensioni delle immagini.
La fatturazione della memoria si avvicina all’utilizzo effettivo
La gestione della memoria è l’altra modifica principale. Il nuovo runtime parte da un ingombro in memoria residente più contenuto, carica la memoria man mano che il carico di lavoro la utilizza e la recupera quando l’applicazione la rilascia o i dati memorizzati nella cache non vengono più usati.
Con il modello precedente, la memoria allocata restava associata alla sessione fino alla sua terminazione. AWS afferma che il nuovo modello tiene invece traccia delle variazioni nel corso della sessione. I clienti pagano una tariffa più alta per il servizio di memoria, ma AWS sostiene che un minore consumo di memoria può ridurre la spesa totale per gli agenti che restano inattivi a lungo o alternano raffiche e pause.
Questo compromesso dipenderà dal modo in cui un agente alloca la memoria. Un carico di lavoro costantemente attivo potrebbe avere meno memoria inutilizzata da recuperare, mentre un agente che attende tra una chiamata a uno strumento e l’altra o gestisce eventi irregolari ha maggiori possibilità di ridurre il proprio ingombro. AWS presenta il nuovo criterio di tariffazione come un modo per addebitare la memoria effettivamente in uso, anziché la quantità massima che una sessione ha raggiunto in precedenza.
V2 è disponibile ora, con altri controlli in programma
Gli sviluppatori possono abilitare il nuovo runtime impostando il parametro platformVersion su V2 quando creano o aggiornano un AgentCore Runtime. AWS ha inoltre pubblicato esempi e un test di carico per valutare il comportamento degli avvii a freddo nell’account del cliente.
Il rilascio non segna la fine della roadmap di AWS per AgentCore Runtime. Tra le funzionalità in programma, AWS elenca sconti di base garantiti per le sessioni stabili, configurazioni con più memoria e spazio di archiviazione, supporto per microVM x86, sessioni sospendibili e riprendibili con snapshot della memoria e identità con ambiti specifici per gli agenti non presidiati.
Queste aggiunte indicano una possibile differenziazione nell’uso del servizio da parte dei team che lavorano in produzione. Gli agenti con attività a raffiche possono continuare a usare la modalità di consumo con scalabilità fino a zero, mentre i carichi di lavoro stabili potrebbero in futuro scegliere un livello minimo di memoria riservata. I carichi di lavoro prolungati e specializzati possono anche usare le istanze runtime AgentCore, separate, che AWS ha reso disponibili a tutti in agosto per l’esecuzione gestita basata su EC2, sessioni della durata massima di 14 giorni e infrastruttura compatibile con le GPU.
Per il rilascio disponibile dal 18 settembre, la modifica concreta è più circoscritta: AgentCore Runtime V2 ripristina un ambiente preparato, recupera memoria durante una sessione e chiede agli sviluppatori di attivarlo tramite un’unica impostazione della versione della piattaforma.