AWS przebudowuje środowisko wykonawcze Bedrock AgentCore pod kątem elastycznej pamięci i szybkich zimnych startów

Amazon Web Services ogłosił nowy runtime AgentCore 18 września 2026 r., przebudowaną wersję zarządzanej warstwy obliczeniowej w Amazon Bedrock AgentCore, którą firma twierdzi, że odzyskuje pamięć w miarę zwalniania jej przez sesje agentów oraz zapewnia spójne czasy zimnych startów niezależnie od rozmiaru obrazu kontenera czy współbieżności.

Runtime AgentCore jest zarządzaną warstwą obliczeniową, która zapewnia deweloperom w pełni zarządzane środowisko do wdrażania i uruchamiania agentów bez konieczności budowania lub utrzymywania infrastruktury. AWS poinformował, że tysiące zespołów korzystało z niego do uruchamiania agentów produkcyjnych od momentu uruchomienia, a pierwsza wersja ustanowiła bezserwerową podstawę z izolacją sesji, zachowaniem skalowania do zera oraz rozliczaniem w modelu pay‑per‑use. Ten model konsumpcji się utrzymuje: rozliczenia są oparte na zużyciu zasobów, bez opłat za bezczynny CPU oczekujący na I/O, a platforma skaluje się do zera, gdy agent nie ma pracy.

Problemy, które rozwiązuje wprowadzenie

W pierwotnym runtime sesja utrzymywała przydzieloną pamięć od momentu przydzielenia aż do zakończenia sesji, ponieważ nic jej nie odzyskiwało po drodze. AWS stwierdził, że powodowało to, że długotrwale działające lub o zmiennym obciążeniu agenty płaciły za swój maksymalny poziom pamięci przez całą dobę, nawet po tym, jak pamięć przestała być używana – szczególna luka dla agentów, które sporadycznie wykazują szczytowe obciążenie, a przez większość dnia pozostają bezczynne.

Zachowanie przy uruchamianiu było drugim wyzwaniem. AWS poinformował, że sesja, która trafia do już zainicjowanego środowiska, rozpoczyna się w czasie krótszym niż 100 milisekund, ale utrzymanie środowisk w stanie gotowości, aby to zagwarantować, wymaga rezerwowania mocy obliczeniowej, więc większość sesji zaczyna się od zimnego startu, który uruchamia nowe środowisko, pobiera obraz i inicjalizuje agenta przed pierwszym żądaniem. Ta latencja rośnie wraz z rozmiarem obrazu i współbieżnością i jest największa przy nagłym natężeniu ruchu, gdy przychodzi najwięcej sesji, a najwięcej środowisk jest zajętych. Według AWS klienci obejśli oba problemy, utrzymując gotowe zapasowe środowiska, optymalizując przydział pamięci oraz zmniejszając pojemność, aby kontrolować koszty.

Co AWS zmierzyło

Aby odizolować wpływ samej platformy na zimny start, AWS przetestował pustego agenta echo, który zwraca swoje wejście i nie wywołuje żadnego modelu ani narzędzi. Klient Pythona działający na instancji Amazon EC2 w regionie us-west-2 wywoływał agentów w us-east-1 przez publiczny internet bez połączenia VPC, korzystając z SDK boto3, więc każde pomiar po stronie klienta obejmuje podróż tam i z powrotem między dwoma regionami AWS, oprócz samego czasu uruchomienia platformy. Firma wysłała 5 000 zimnych wywołań na agenta w obu wersjach runtime oraz pięciu rozmiarach obrazu, mieszcząc się w domyślnych limitach konta.

Mierząc w ten sposób, AWS podał, że nowy runtime zapewniał latencję zimnego startu na poziomie P75 wynoszącą około 2 sekund przy obrazie od 200 MB do 2 GB, ponieważ rozmiar obrazu nie ma na nią wpływu, podczas gdy latencja pierwotnego runtime rosła wraz z rozmiarem obrazu z około 5,4 sekundy do niemal 30 sekund. W teście echo kod samego agenta działał w około 34 milisekundy przy P75, więc prawie cały zmierzony czas stanowił czas uruchomienia platformy. AWS sugeruje ukrycie czasu uruchomienia dla interaktywnych agentów, rozpoczynając sesję natychmiast po zaangażowaniu użytkownika, np. gdy otworzy czat, tak aby środowisko ogrzało się podczas wpisywania pierwszego żądania.

Jak działa nowy runtime

Nowy runtime rozpoczyna każdą sesję od małego profilu pamięci, a nie od w pełni przydzielonego rozmiaru, a następnie przydziela i wczytuje dodatkową pamięć na żądanie, gdy obciążenie ją potrzebuje. Gdy agent zwalnia bufor per‑request lub pozwala wygasnąć pamięci podręcznej między żądaniami, platforma odzyskuje tę pamięć zamiast pozostawiać ją przydzieloną do końca sesji. AWS poinformował, że dostroił zachowanie odzyskiwania na podstawie analizy wzorców alokacji w miliardach sesji.

Zimne starty zmieniają się, ponieważ każdy agent ładuje się raz, a następnie działa z migawki. Gdy runtime jest tworzony lub aktualizowany, AgentCore uruchamia kontener, czeka, aż zgłosi stan zdrowia, i tworzy migawkę działającego środowiska, więc jednorazowa inicjalizacja, taka jak ładowanie artefaktów modelu i pobieranie statycznej konfiguracji, jest już wykonana. Każda nowa instancja przywraca tę migawkę zamiast inicjalizować od zera. AWS poinformował, że runtime usuwa pamięci podręczne i pamięć przejściową z migawki, dzięki czemu jej rozmiar pozostaje w przybliżeniu stały w miarę rosnącego obrazu kontenera, co utrzymuje stałą latencję przywracania w szerokim zakresie rozmiarów obrazów.

Rozliczenia zmieniają się wraz z modelem pamięci. Nowy runtime pobiera opłatę za pamięć, której agent aktywnie używa, ładowaną na żądanie i odzyskiwaną w stanie bezczynności, zamiast za przechowywanie całego obrazu kontenera w pamięci przez cały czas trwania sesji. AWS określił tę zmianę jako wyższą stawkę zastosowaną do znacznie mniejszej liczby GB‑godzin i stwierdził, że dla większości agentów ślad pamięci spada szybciej niż rośnie stawka, więc rachunek maleje.

Wersje platformy, regiony i limity

Deweloperzy włączają nowy runtime, ustawiając pole platformVersion na V2 podczas tworzenia lub aktualizacji runtime, zgodnie z Przewodnikiem dewelopera AgentCore. V1 jest domyślną wersją: pominięcie pola przy tworzeniu powoduje runtime V1, a pominięcie go przy aktualizacji zachowuje bieżącą wersję platformy runtime. V2 jest dostępny w regionach us-east-1, us-east-2, us-west-2, eu-west-1 oraz ap-northeast-1.

Ponieważ tworzenie lub aktualizacja V2 przygotowuje i tworzy migawkę środowiska, te operacje trwają kilka minut, zanim środowisko osiągnie stan READY, podczas gdy środowisko V1 staje się gotowe w ciągu kilku sekund. AgentCore tworzy migawkę przy pierwszej zdrowej odpowiedzi z endpointu /ping kontenera, a jeśli kontener nie zgłosi stanu zdrowia w ciągu 120 sekund od uruchomienia, tworzenie kończy się niepowodzeniem z błędem kontroli zdrowia. W przewodniku zaznaczono również, że V2 obecnie ogranicza całkowity rozmiar zmiennych środowiskowych do 1,5 KB dla bezpośrednich wdrożeń kodu i 2,5 KB dla agentów kontenerowych, w porównaniu z 4 KB w V1, oraz że AWS CloudFormation i AWS CDK nie obsługują jeszcze ustawiania platformVersion.

Migawki podążają za wersjami i endpointami środowiska, a nie są zarządzane bezpośrednio. AgentCore przygotowuje migawkę, gdy endpoint wskazuje na wersję, i usuwa ją, gdy żaden endpoint nie wskazuje na tę wersję; usunięcie może trwać do 8 godzin, czyli maksymalny czas trwania sesji, ponieważ sesje już uruchomione na migawce kontynuują działanie aż do zakończenia. Sesje działają w dedykowanych mikro‑VM z odizolowanymi zasobami CPU, pamięci i systemu plików, utrzymują się do 8 godzin i kończą po 15 minutach nieaktywności, po czym mikro‑VM jest zamykana, a pamięć jest oczyszczana.

Plan rozwoju i rozpoczęcie pracy

Po uruchomieniu AWS wymieniło kilka funkcji, które będą dostępne w przyszłości: zobowiązujące zniżki bazowe, które rezerwują minimalną pamięć na sesję z możliwością dynamicznego przydziału powyżej tego limitu, przeznaczone dla stałych, zawsze aktywnych sesji; większa ilość RAM, vCPU i pamięci sesji; wsparcie mikro‑VM x86; zawieszanie i wznawianie z migawką pamięci oraz haki środowiskowe umożliwiające serializację stanu przed zakończeniem aktywnej sesji; oraz klucze kontekstu sesji, które nadają każdej sesji odrębną tożsamość dla agentów pracujących bez nadzoru.

AWS skierowało programistów do przewodnika AgentCore Developer Guide, repozytorium przykładów AgentCore na GitHub oraz do towarzyszącego przykładu testu obciążeniowego, który demonstruje opóźnienie zimnego startu nowego środowiska w ramach własnego konta AWS użytkownika.