AWS přepracovává Bedrock AgentCore Runtime pro elastickou paměť a rychlé starty z chladného stavu

Amazon Web Services oznámila nový runtime AgentCore dne 18. září 2026, přepracovanou verzi spravované výpočetní vrstvy v Amazon Bedrock AgentCore, o které společnost uvádí, že uvolňuje paměť, jakmile ji agentní relace uvolní, a poskytuje konzistentní časy startu z chladného stavu bez ohledu na velikost kontejnerového obrazu nebo souběžnost.

Runtime AgentCore je spravovaná výpočetní vrstva, která vývojářům poskytuje plně spravované prostředí pro nasazení a provoz agentů bez nutnosti budovat nebo udržovat infrastrukturu. AWS uvedla, že tisíce týmů jej od spuštění používají k provozu produkčních agentů, a že první verze vytvořila serverless základ s izolací relací, chováním škálování na nulu a cenovým modelem „platíš za použití“. Tento model spotřeby přetrvává: fakturace sleduje využití zdrojů bez poplatku za nečinný CPU čekající na I/O a platforma se škáluje až na nulu, když agent nemá žádnou práci.

Problémy, které řeší uvedené spuštění

V původním runtime si relace uchovávala přidělenou paměť od okamžiku alokace až do konce relace, protože během cesty nebyla uvolněna. AWS uvedla, že to způsobovalo, že dlouhodobě běžící nebo burstoví agenti platili za svůj maximální špičkový stav po celou dobu, i když paměť přestala být využívána, což představovalo zvláštní mezeru pro agenty, kteří občas zaznamenají špičku, ale většinu dne jsou nečinní.

Chování při startu bylo druhým problémem. AWS uvedla, že relace, která spadne do již inicializovaného prostředí, startuje za méně než 100 ms, ale udržování prostředí dostatečně „teplých“, aby to bylo zaručeno, znamená rezervování výpočetního výkonu, takže většina relací začíná chladným startem, který spustí čerstvé prostředí, stáhne obraz a inicializuje agenta před první žádostí. Tato latence roste s velikostí obrazu a souběžností a je nejhorší při burstovém provozu, kdy přichází nejvíce relací a zůstává nejméně připravených prostředí. Podle AWS zákazníci oba problémy řešili tím, že udržovali připravená rezervní prostředí, optimalizovali alokaci paměti a snižovali kapacitu, aby udrželi náklady pod kontrolou.

Co AWS měřilo

Aby oddělila, co platforma sama přidává k chladnému startu, AWS otestovala prázdného echo agenta, který vrací svůj vstup a nevolá žádný model ani nástroje. Python klient na instanci Amazon EC2 v us‑west‑2 volal agenty v us‑east‑1 přes veřejný internet bez VPC peeringu, pomocí SDK boto3, takže každé měření na straně klienta zahrnuje round‑trip mezi dvěma regiony AWS nad vlastní dobou startu platformy. Společnost odeslala 5 000 chladných volání na agenta napříč oběma verzemi runtime a pěti velikostmi obrazu, v rámci výchozích kvót účtu.

Měřeno tímto způsobem, AWS oznámila, že nový runtime dosáhl P75 latence chladného startu přibližně 2 sekundy u obrazu od 200 MB až do 2 GB, protože velikost obrazu nemá vliv, zatímco latence původního runtime rostla s velikostí obrazu z přibližně 5,4 sekundy až téměř 30 sekund. V echo testu běžel kód agenta přibližně 34 ms při P75, takže téměř veškerý měřený čas byl čas startu platformy. AWS navrhuje skrýt čas startu pro interaktivní agenty tím, že relaci zahájí, jakmile uživatel zahájí interakci, například otevřením chatu, takže se prostředí zahřeje, zatímco píší první požadavek.

Jak funguje nový runtime

Nový runtime spouští každou relaci z malého paměťového profilu místo plně přidělené stopy, pak alokuje a načítá další paměť na vyžádání, jakmile ji pracovní zátěž potřebuje. Když agent uvolní vyrovnávací paměti po jednotlivých požadavcích nebo nechá vypršet cacheovaná data mezi požadavky, platforma paměť vrátí zpět místo toho, aby zůstala přidělena až do konce relace. AWS uvedla, že chování uvolňování vyladila na základě analýzy alokačních vzorců napříč miliardami relací.

Chladné starty se mění, protože každý agent se načte jednou a poté běží ze snapshotu. Když je runtime vytvořen nebo aktualizován, AgentCore spustí kontejner, čeká, až nahlásí zdravý stav, a zachytí snapshot běžícího prostředí, takže jednorázová inicializace, jako načítání artefaktů modelu a získávání statické konfigurace, je již provedena. Každá nová instance obnoví tento snapshot místo inicializace od nuly. AWS uvedla, že runtime odstraňuje cache a přechodnou paměť ze snapshotu, takže jeho velikost zůstává přibližně konstantní i při růstu kontejnerového obrazu, což udržuje latenci obnovy stabilní napříč širokým rozsahem velikostí obrazu.

Fakturace se mění s paměťovým modelem. Nový runtime účtuje paměť, kterou agent aktivně používá, načítá na vyžádání a uvolňuje při nečinnosti, místo aby držel celý kontejnerový obraz v paměti po celou dobu trvání relace. AWS charakterizovala změnu jako vyšší sazbu u podstatně menšího počtu GB‑hodin a uvedla, že u většiny agentů se stopa sníží více, než sazba vzroste, takže účet klesá.

Verze platformy, regiony a limity

Vývojáři zapnou nový runtime nastavením pole platformVersion na V2 při vytváření nebo aktualizaci runtime, podle AgentCore Průvodce vývojáře. V1 je výchozí: vynechání pole při vytvoření vytvoří runtime V1 a vynechání při aktualizaci zachová aktuální verzi platformy runtime. V2 je dostupná v us‑east‑1, us‑east‑2, us‑west‑2, eu‑west‑1 a ap‑northeast‑1.

Protože vytvoření nebo aktualizace V2 připravuje a vytváří snímek prostředí, tyto operace trvají několik minut, než se runtime dostane do stavu READY, zatímco runtime V1 je připraven během několika sekund. AgentCore vytvoří snímek při první zdravé odpovědi z koncového bodu /ping kontejneru a pokud kontejner během 120 sekund od spuštění neoznámí zdravý stav, vytvoření selže s chybou kontrolního testu. Průvodce také uvádí, že V2 aktuálně omezuje celkovou velikost proměnných prostředí na 1,5 KB pro přímé nasazení kódu a 2,5 KB pro kontejnerové agenty, oproti 4 KB u V1, a že AWS CloudFormation a AWS CDK v současnosti nepodporují nastavení platformVersion.

Snímky sledují verze a koncové body runtime místo toho, aby byly spravovány přímo. AgentCore připraví snímek, když koncový bod ukazuje na verzi, a smaže jej, když na něj žádný koncový bod neukazuje, a smazání může trvat až 8 hodin, což je maximální životnost relace, protože relace již běžící na snímku pokračují až do svého konce. Relace běží v dedikovaných microVM s izolovanými prostředky CPU, paměti a souborového systému, přetrvávají až 8 hodin a ukončí se po 15 minutách neaktivity, poté je microVM ukončena a paměť je vyčištěna.

Plán vývoje a první kroky

Po spuštění AWS uvedla několik připravovaných funkcí: závazné základní slevy, které rezervují minimální množství paměti na relaci s možností dynamického navýšení nad tuto úroveň, zaměřené na stálé vždy aktivní relace; větší RAM, vCPU a úložiště relací; podpora microVM na architektuře x86; pozastavení a obnovení s vytvářením snímků paměti plus runtime háčky pro serializaci stavu před ukončením aktivní relace; a klíče kontextu relace, které každé relaci poskytují omezenou identitu pro neobsluhované agenty.

AWS nasměrovala vývojáře na AgentCore Developer Guide, repozitář vzorků AgentCore na GitHubu a přiložený příklad zátěžového testu, který ukazuje latenci studeného startu nového runtime v rámci vlastního AWS účtu uživatele.