AWS reconfigurează runtime-ul Bedrock AgentCore pentru memorie elastică și porniri reci rapide

Amazon Web Services a anunțat noul runtime AgentCore pe 18 septembrie 2026, o versiune reproiectată a stratului de calcul gestionat în Amazon Bedrock AgentCore pe care compania spune că recuperează memoria pe măsură ce sesiunile de agent o eliberează și oferă timpi de pornire rece consistenți, indiferent de dimensiunea imaginii containerului sau de concurență.

Runtime-ul AgentCore este stratul de calcul gestionat care oferă dezvoltatorilor un mediu complet gestionat pentru a implementa și rula agenți fără a construi sau întreține infrastructură. AWS a declarat că mii de echipe l-au folosit pentru a rula agenți de producție de la lansare și că prima versiune a stabilit o bază serverless cu izolare a sesiunilor, comportament de scalare la zero și tarifare pe utilizare. Acest model de consum se menține: facturarea urmează utilizarea resurselor fără cost pentru CPU inactiv în așteptarea I/O, iar platforma scalează complet la zero când un agent nu are sarcini.

Problemele pe care le abordează lansarea

În runtime‑ul original, o sesiune păstra memoria alocată de la momentul alocării până la încheierea sesiunii, deoarece nimic nu o recupera pe parcurs. AWS a afirmat că aceasta lăsa agenții cu rulare îndelungată sau cu trafic exploziv să plătească pentru nivelul maxim de memorie non‑stop, mult după ce memoria nu mai era utilizată, un gol specific pentru agenții care au vârfuri ocazionale, dar stau inactivi majoritatea zilei.

Comportamentul la pornire a fost a doua provocare. AWS a declarat că o sesiune care ajunge pe un mediu deja inițializat pornește în sub 100 de milisecunde, dar menținerea mediilor suficient încălzite pentru a garanta acest lucru implică păstrarea calculului în rezervă, astfel că majoritatea sesiunilor încep cu o pornire rece care inițializează un mediu nou, descarcă imaginea și inițializează agentul înainte de prima cerere. Această latență crește odată cu dimensiunea imaginii și cu concurența și este cea mai mare în trafic exploziv, când sosesc cele mai multe sesiuni și rămân cele mai puține medii pregătite. Conform AWS, clienții au rezolvat ambele probleme prin menținerea unor medii de rezervă, optimizarea alocării memoriei și reducerea capacității pentru a menține costurile sub control.

Ce a măsurat AWS

Pentru a izola ce adaugă platforma însăși la o pornire rece, AWS a testat un agent de ecou gol care returnează intrarea și nu apelează niciun model și niciun instrument. Un client Python pe o instanță Amazon EC2 în us-west-2 a invocat agenți în us-east-1 prin internet public fără interconectare VPC, utilizând SDK‑ul boto3, astfel încât fiecare măsurătoare de la client include drumul dus‑întors dintre cele două regiuni AWS pe lângă timpul de pornire al platformei. Compania a trimis 5.000 de invocări reci pe agent, pentru ambele versiuni de runtime și cinci dimensiuni de imagine, în limitele cotelor implicite ale contului.

Măsurat în acest fel, AWS a raportat că noul runtime a oferit o latență P75 de pornire rece de aproximativ 2 secunde pentru imagini de la 200 MB până la 2 GB, deoarece dimensiunea imaginii nu are efect, în timp ce latența runtime‑ului original a crescut odată cu dimensiunea imaginii, de la aproximativ 5,4 secunde la aproape 30 de secunde. În testul de ecou, codul agentului a rulat în aproximativ 34 de milisecunde la P75, astfel că aproape tot timpul măsurat a fost timpul de pornire al platformei. AWS sugerează ascunderea timpului de pornire pentru agenții interactivi prin începerea sesiunii imediat ce utilizatorul interacționează, de exemplu când deschide o conversație, astfel mediul se încălzește în timp ce tastează prima cerere.

Cum funcționează noul runtime

Noul runtime pornește fiecare sesiune dintr-un profil de memorie mic, în loc de o amprentă complet provisionată, apoi alocă și încarcă în memorie memorie suplimentară la cerere pe măsură ce sarcina o accesează. Când un agent eliberează buffere per‑cerere sau permite expirarea datelor în cache între cereri, platforma recuperează memoria în loc să o păstreze revendicată până la încheierea sesiunii. AWS a declarat că a ajustat comportamentul de recuperare pe baza unei analize a tiparelor de alocare în miliarde de sesiuni.

Pornirile reci se modifică deoarece fiecare agent se încarcă o singură dată și apoi rulează dintr-un snapshot. Când un runtime este creat sau actualizat, AgentCore lansează containerul, așteaptă să raporteze stare sănătoasă și capturează un snapshot al mediului în execuție, astfel încât inițializările unice, cum ar fi încărcarea artefactelor modelului și preluarea configurației statice, sunt deja finalizate. Fiecare instanță nouă restaurează acel snapshot în loc să inițializeze de la zero. AWS a declarat că runtime‑ul elimină cache‑urile și memoria tranzitorie din snapshot, astfel dimensiunea acestuia rămâne aproximativ constantă pe măsură ce imaginea containerului crește, menținând latența de restaurare stabilă pe o gamă largă de dimensiuni ale imaginii.

Facturarea se modifică odată cu modelul de memorie. Noul runtime taxează memoria pe care un agent o folosește activ, încărcată la cerere și recuperată când este inactivă, în loc să taxeze pentru menținerea întregii imagini a containerului în memorie pe durata unei sesiuni. AWS a caracterizat schimbarea ca un tarif mai mare aplicat la mult mai puține GB‑ore și a afirmat că pentru majoritatea agenților amprenta scade mai mult decât crește tariful, astfel factura scade.

Versiuni de platformă, regiuni și limite

Dezvoltatorii activează noul runtime setând câmpul platformVersion la V2 la crearea sau actualizarea unui runtime, conform Ghidul pentru dezvoltatori AgentCore. V1 este implicit: omiterea câmpului la creare produce un runtime V1, iar omiterea lui la o actualizare păstrează versiunea curentă a platformei runtime‑ului. V2 este disponibil în us-east-1, us-east-2, us-west-2, eu-west-1 și ap-northeast-1.

Deoarece o creare sau actualizare V2 pregătește și capturează instantaneu mediul, aceste operații durează câteva minute până când runtime‑ul ajunge în stare READY, în timp ce un runtime V1 devine gata în câteva secunde. AgentCore capturează instantaneul la primul răspuns sănătos de la endpoint‑ul /ping al containerului, iar dacă containerul nu raportează stare sănătoasă în decurs de 120 de secunde de la pornire, crearea eșuează cu o eroare de verificare a sănătății. Ghidul menționează, de asemenea, că V2 limitează în prezent dimensiunea totală a variabilelor de mediu la 1,5 KB pentru implementări directe de cod și la 2,5 KB pentru agenți în containere, comparativ cu 4 KB la V1, și că AWS CloudFormation și AWS CDK nu suportă în prezent setarea platformVersion.

Instantaneele urmează versiunile și endpoint‑urile runtime‑ului, în loc să fie gestionate direct. AgentCore pregătește un instantaneu când un endpoint indică o versiune și șterge unul când niciun endpoint nu îl indică, iar ștergerea poate dura până la 8 ore, durata maximă a sesiunii, deoarece sesiunile care rulează deja pe instantaneu continuă până la finalizare. Sesiunile rulează în microVM‑uri dedicate cu resurse izolate de CPU, memorie și sistem de fișiere, persistă până la 8 ore și se încheie după 15 minute de inactivitate, moment în care microVM‑ul este terminat și memoria este curățată.

Plan de dezvoltare și începutul utilizării

Dincolo de lansare, AWS a enumerat mai multe capabilități în curs de dezvoltare: reduceri de bază angajate care rezervă un nivel minim de memorie per sesiune, cu posibilitate de creștere on‑demand peste acest nivel, destinate sesiunilor permanente și active; memorie RAM, vCPU și stocare de sesiune mai mari; suport pentru microVM‑uri x86; suspendare‑și‑reluare cu capturarea instantaneului de memorie plus hook‑uri de runtime pentru serializarea stării înainte ca o sesiune activă să se încheie; și chei de context de sesiune care oferă fiecărei sesiuni o identitate delimitată pentru agenți fără supraveghere.

AWS a îndrumat dezvoltatorii către AgentCore Developer Guide, depozitul de mostre AgentCore de pe GitHub și un exemplu de testare a încărcării care demonstrează latența de pornire rece a noului runtime în contul AWS al utilizatorului.