Amazon Bedrock AgentCore Runtime V2 sprawia, że zimne starty są przewidywalne, ale rachunek wciąż wymaga potwierdzenia
Amazon wprowadził Amazon Bedrock AgentCore Runtime V2 z odważną deklaracją: zimne starty utrzymują się na poziomie około dwóch sekund dla obrazów kontenerów o rozmiarze od 200 MB do 2 GB.
Wynik ten podważa znany kompromis w środowiskach bezserwerowych. Zespoły mogą skalować agenta do zera i oszczędzać pieniądze, lecz kolejny użytkownik często czeka na uruchomienie jego środowiska. Utrzymywanie instancji w gotowości skraca to opóźnienie, ale zachowuje też zasoby, które mogą pozostawać bezczynne.
Runtime V2 atakuje obie strony tego kompromisu. AWS twierdzi, że przywraca przygotowane migawki zamiast odtwarzać każde środowisko od podstaw. Odzyskuje też nieużywaną pamięć, gdy sesja nadal trwa, zamiast naliczać opłaty według wcześniejszego maksimum zużycia sesji.
Ogłoszenie ma znaczenie, ponieważ agenci produkcyjni działają inaczej niż konwencjonalne procedury obsługi żądań. Mogą czekać na modele, wywoływać narzędzia, przetwarzać pliki i utrzymywać stan roboczy w długiej sekwencji żądań. Środowisko wykonawcze zaprojektowane wokół krótkich transakcji webowych może marnować zasoby, gdy takie przerwy dominują w sesji.
AWS pozycjonuje V2 jako odpowiedź na tę niedopasowaną infrastrukturę, a nie jedynie wobec kolejnego frameworka agentowego. Główna rywalizacja dotyczy wykonania opartego na migawkach i wrażliwego na użycie, w zestawieniu ze środowiskami utrzymywanymi w gotowości lub zachowującymi szczytowe przydziały dla przewidywalnej wydajności.
Microsoft i Google oferują już własne odpowiedzi na opóźnienia uruchamiania kontenerów. Microsoft korzysta z wcześniej rozgrzanych pul sesji, a Google zaleca minimalną liczbę instancji i przyspieszenie CPU podczas startu. Nowy argument Amazonu brzmi: zespoły nie powinny potrzebować stale utrzymywanej, gotowej pojemności, by uzyskać spójne zachowanie przy uruchamianiu.
Liczby są obiecujące, lecz pochodzą z własnego benchmarku AWS. Kupujący nadal potrzebują dowodów na poziomie rzeczywistych obciążeń, obejmujących faktyczny kod inicjalizacyjny, ruch skokowy, presję na pamięć, pojemność regionalną i całkowite opóźnienie aplikacji.
Co faktycznie zmienia Amazon Bedrock AgentCore Runtime V2
Runtime V2 zmienia moment, w którym środowiska agentowe wykonują inicjalizację, oraz czas, przez jaki przydzielona pamięć pozostaje rozliczana.
Amazon Bedrock AgentCore Runtime to zarządzana warstwa obliczeniowa w ramach AgentCore. Hostuje agenta lub narzędzie w izolowanej microVM, czyli lekkiej maszynie wirtualnej z oddzielnymi zasobami CPU, pamięci i systemu plików.
AWS ogłosił V2 18 września 2026 roku. Deweloperzy mogą go wybrać, ustawiając platformVersion na V2 podczas tworzenia lub aktualizowania środowiska wykonawczego. Według aktualnej architektury środowiska wykonawczego V1 pozostaje wersją domyślną.
Pierwsza istotna zmiana dotyczy inicjalizacji. Gdy deweloper tworzy lub aktualizuje środowisko V2, AgentCore uruchamia kontener i czeka na jego kontrolę kondycji. Następnie platforma przechwytuje przygotowaną migawkę tego działającego środowiska.
Przyszłe instancje przywracają migawkę zamiast powtarzać całą sekwencję uruchamiania. Jednorazowe zadania, takie jak ładowanie bibliotek, pobieranie statycznej konfiguracji czy przygotowywanie artefaktów modeli, mogą zatem zostać wykonane przed nadejściem pierwszego rzeczywistego żądania.
Tworzenie migawek samo w sobie nie jest nowością. AWS Lambda SnapStart również przywraca zainicjalizowane środowiska wykonawcze, aby ograniczać opóźnienia uruchamiania. AgentCore stosuje to podejście do dłużej żyjących, izolowanych sesji agentowych z własnymi kontenerami i interakcjami zachowującymi stan.
Druga zmiana dotyczy rozliczania pamięci. V1 utrzymywał przydzieloną pamięć do zakończenia sesji, nawet gdy agent zwalniał bufory lub przestawał używać danych w pamięci podręcznej. Zużycie mogło więc odpowiadać najwyższemu przydziałowi pamięci osiągniętemu w trakcie sesji.
V2 zaczyna z mniejszym rezydentnym śladem pamięci i stronicuje pamięć w miarę jej używania przez obciążenie. AWS twierdzi, że platforma odzyskuje pamięć po zwolnieniu jej przez aplikację lub gdy dane stają się nieaktywne.
Aktualne zasady użycia wskazują, że bezczynna pamięć w V2 jest odzyskiwana automatycznie po 120 sekundach. W rozliczaniu pamięci obowiązuje minimum 128 MB, a narzut systemowy również jest uwzględniany w mierzonym użyciu.
CPU już wcześniej działało według modelu zorientowanego na zużycie. Gdy agent czeka na model, narzędzie, bazę danych lub zewnętrzne API, opłaty za CPU mogą spaść do zera, jeśli żaden proces w tle nie pozostaje aktywny. V2 rozszerza tę elastyczność w bardziej znaczący sposób na pamięć.
Zmiany te są najważniejsze, gdy jedna sesja przechodzi przez wyraźnie różne fazy. Agent do obsługi dokumentów może przydzielić pamięć podczas analizowania dużego pliku, zwolnić te bufory, a następnie przez kilka minut czekać na wywołania modelu.
W modelu opartym na maksymalnym poziomie zużycia faza analizy może kształtować użycie pamięci do końca sesji. W V2 AWS twierdzi, że późniejsze zużycie może spaść po zniknięciu tego tymczasowego przydziału.
Sesje AgentCore nadal wymagają starannego zarządzania cyklem życia. MicroVM może działać do ośmiu godzin, a domyślny limit nieaktywności może wcześniej zatrzymać jej zasoby obliczeniowe. Aplikacje muszą również przechowywać trwałe informacje poza efemeryczną pamięcią sesji.
Wprowadzenie tej wersji nie zmienia więc kontenera agenta w nieograniczoną, trwałą infrastrukturę. Zmienia wydajność i zachowanie zarządzanego środowiska przy uruchamianiu, zachowując granice sesji AgentCore.
To rozróżnienie tworzy rzeczywiste napięcie. AWS obiecuje responsywność kojarzoną z przygotowaną pojemnością, przy zachowaniu ekonomiki wykonania skalowanego do zera.
Dlaczego obciążenia agentowe przełamały stary model pamięci
Stary model stał się nieefektywny, ponieważ sesje agentów pozostają aktywne podczas naprzemiennych okresów obliczeń, wzrostu zużycia pamięci i oczekiwania na zewnętrzne usługi.
Konwencjonalne żądanie webowe zwykle ma krótki, łatwy do zrozumienia cykl życia. Przychodzi, uruchamia kod aplikacji, uzyskuje dostęp do bazy danych, zwraca odpowiedź i zwalnia środowisko wykonawcze.
Agent może działać bardziej jak tymczasowy pracownik. Otrzymuje cel, wywołuje model, uruchamia kilka narzędzi, pobiera materiały, tworzy pliki pośrednie, czeka na zatwierdzenia i później wznawia pracę.
Etapy te stawiają środowisku wykonawczemu różne wymagania. Wywołania narzędzi mogą pozostawić CPU niemal bezczynne. Przetwarzanie dokumentów może tworzyć krótkotrwałe szczyty zużycia pamięci. Interaktywne rozmowy źle znoszą opóźnienia startowe, podczas gdy zadania bez nadzoru przedkładają koszt nad natychmiastową odpowiedź.
V1 już oferował izolację sesji, zachowanie skalowania do zera i rozliczanie CPU zależne od zużycia. Jego obsługa pamięci utrzymywała jednak przydziały po zakończeniu użytecznej fazy ich wykorzystania.
Rozważmy agenta programistycznego analizującego duże repozytorium. Może załadować indeks, sprawdzić dane wyjściowe kompilacji, przechować kilka odpowiedzi narzędzi, a następnie zwolnić większość tych danych przed oczekiwaniem na model.
W szczytowym momencie zużycie pamięci nadal wpływało na późniejsze użycie w pierwotnym środowisku wykonawczym. Dłuższe sesje potęgowały ten skutek, ponieważ wczesny przydział mógł pozostać przypisany do śladu sesji.
AWS twierdzi, że podczas dostrajania V2 analizował wzorce alokacji w miliardach sesji. To stwierdzenie wskazuje na szeroką telemetrię wewnętrzną, ale firma nie opublikowała rozkładu, metodologii ani reprezentatywnej mieszanki obciążeń stojących za analizą.
Odzyskiwanie nieaktywnej pamięci lepiej dopasowuje licznik do zmieniającego się obciążenia agenta. Rodzi jednak także nowe pytanie operacyjne: jak szybko dane odłączone od pamięci mogą wrócić, gdy agent niespodziewanie znów ich potrzebuje?
AWS opisuje pamięć jako ładowaną na żądanie, odzyskiwaną po zwolnieniu i odzyskiwaną, gdy staje się nieaktywna. Publiczne ogłoszenie nie podaje szczegółowych opóźnień błędów strony ani progów dla każdego wzorca obciążenia.
To pominięcie ma znaczenie dla agentów z dużymi cache’ami wielokrotnego użytku. Odzyskanie pamięci podręcznej może obniżyć mierzone użycie pamięci, lecz jej późniejsze odbudowanie może zużywać CPU, zwiększać opóźnienia albo powtarzać transfery sieciowe.
Deweloperzy będą musieli oddzielić alokacje rzeczywiście zbędne od danych, które poprawiają kolejne tury. Niższy wykres użycia pamięci nie oznacza automatycznie szybszego ani tańszego kompletnego przepływu pracy.
Architektura zwiększa również znaczenie zachowania aplikacji. Oprogramowanie, które zwalnia tymczasowe bufory, daje platformie możliwość odzyskania pamięci. Proces, który bezterminowo utrzymuje referencje, nie może oczekiwać, że środowisko wykonawcze rozpozna, iż dane nie są potrzebne.
Długie sesje agentowe czynią tę dyscyplinę wartościową. Dokumentacja AWS mówi, że każda sesja microVM otrzymuje izolowane zasoby obliczeniowe, pamięć i system plików. Zatrzymana sesja może później otrzymać nowe zasoby obliczeniowe, lecz stan efemeryczny znika, chyba że aplikacja korzysta z trwałego magazynu sesji lub innej trwałej usługi.
Taka konstrukcja chroni separację użytkowników, ale uniemożliwia deweloperom traktowanie pamięci procesu jako trwałego magazynu wiedzy. Zapisy rozmów, wyuczone preferencje i fakty do ponownego użycia wymagają trwałego magazynu poza microVM.
To rozróżnienie jest szczególnie istotne dla agentów intensywnie korzystających z wiedzy. Zespoły potrzebują również przeszukiwalnego rejestru operacyjnego obejmującego prompty, dokumenty źródłowe, wyniki testów i zmiany środowiska wykonawczego. Utrzymywana baza wiedzy inżynieryjnej może zachować ten kontekst poza pojedynczą sesją wykonawczą.
Runtime V2 nie usuwa tych obowiązków architektonicznych. Czyni tymczasową warstwę obliczeniową bardziej elastyczną, co zwiększa wartość oddzielania przejściowych danych roboczych od trwałej wiedzy organizacyjnej.
Przywracanie migawek zmienia kompromis związany z zimnym startem
Główna poprawa wynika z przywracania odchudzonej, zainicjalizowanej migawki, której rozmiar pozostaje względnie stabilny wraz ze wzrostem obrazu kontenera.
Zimny start to okres, zanim nowo utworzone środowisko stanie się gotowe do obsługi pracy aplikacji. Może obejmować pobranie obrazu, udostępnienie zasobów obliczeniowych, uruchomienie procesu, załadowanie zależności i wykonanie kodu inicjalizacyjnego.
Zimne starty stają się szczególnie widoczne, gdy ruch pojawia się po przeskalowaniu usługi do zera. Występują też podczas nagłych skoków ruchu, gdy istniejące środowiska nie mogą obsłużyć każdej nowej sesji.
Duże kontenery agentowe mogą pogłębiać ten problem. Mogą zawierać środowiska uruchomieniowe języków, zależności przeglądarkowe, frameworki agentowe, parsery dokumentów, biblioteki uczenia maszynowego i narzędzia wewnętrzne.
Runtime V2 zmienia tę ścieżkę. AgentCore inicjalizuje środowisko podczas przygotowywania wersji środowiska wykonawczego, przechwytuje jego stan i przywraca go dla przyszłych instancji.
AWS twierdzi również, że platforma usuwa cache’e i pamięć przejściową, których przywrócona instancja nie potrzebuje. To odchudzanie ma zapobiegać wzrostowi rozmiaru migawki wraz z pełnym rezydentnym śladem większego kontenera.
Firmowy benchmark uruchomieniowy objął 5 000 zimnych wywołań na agenta w V1 i V2. Test obejmował pięć rozmiarów obrazów przy domyślnych limitach konta.
V2 osiągnął opóźnienie zimnego startu P75 na poziomie około dwóch sekund dla obrazów od 200 MB do 2 GB. P75 oznacza, że 75 procent mierzonych uruchomień zakończyło się w czasie równym raportowanemu wynikowi lub krótszym.
V1 zachowywał się inaczej w tym samym teście AWS. Jego wynik P75 wzrósł z około 5,4 sekundy dla najmniejszego obrazu do niemal 30 sekund dla największego.
Liczby te czynią mechanizm ciekawszym niż zwykła procentowa poprawa. AWS twierdzi, że rozmiar obrazu przestaje być istotnym czynnikiem opóźnienia przywracania w badanym zakresie.
Test porównawczy wykorzystywał również aplikację echo, której kod wykonywał się w około 34 milisekundy na poziomie P75. Taka konfiguracja izoluje uruchamianie infrastruktury, ale nie przypomina pełnej ścieżki wykonania zaawansowanego agenta.
Rzeczywiste agenty często poświęcają kilka sekund na każde wywołanie modelu. Mogą też kontaktować się ze zdalnymi narzędziami, pobierać kontekst, uwierzytelniać użytkowników lub ustanawiać połączenia sieciowe po przygotowaniu środowiska.
Dwusekundowy start platformy nie oznacza dwusekundowej odpowiedzi. Oznacza, że infrastruktura wnosi mniejsze i bardziej przewidywalne opóźnienie, zanim kod agenta otrzyma pierwsze żądanie.
Ta przewidywalność może być ważniejsza niż średnia. Zespoły produktowe mogą z większą pewnością projektować stany ładowania, limity czasu i oczekiwania dotyczące pierwszego tokenu, gdy opóźnienie uruchomienia pozostaje w wąskim zakresie.
AWS sugeruje uruchamianie sesji, gdy użytkownik otwiera interfejs, zanim wyśle pierwszy prompt. Tekst powitalny i czas pisania mogą wtedy ukryć znaczną część pozostałego czasu uruchamiania.
Ta taktyka jest praktyczna, ale zmienia też charakter zapotrzebowania. Otwarcie interfejsu może tworzyć sesje, które nigdy nie otrzymają wiadomości, dlatego zespoły powinny mierzyć porzucone sesje i niepotrzebne tworzenie środowisk.
Migawki wprowadzają również kwestie związane z wdrożeniem. Inicjalizacja zapisana przed utworzeniem migawki nie powinna zawierać wygasłych poświadczeń, niebezpiecznej losowości ani stanu specyficznego dla użytkownika.
Statyczna konfiguracja może dobrze się sprawdzić. Sekrety zależne od czasu i tożsamość poszczególnych sesji powinny być pozyskiwane za pomocą mechanizmów bezpiecznych przy odtwarzaniu. Kontrole kondycji muszą także odzwierciedlać rzeczywiście przygotowane środowisko, a nie jedynie port sieciowy nasłuchujący połączeń.
Model migawek przenosi więc część pracy z czasu obsługi żądania do czasu wdrożenia. Zespoły zyskują szybsze tworzenie instancji, ale muszą audytować to, co staje się częścią przechwyconego stanu.
AWS Wywiera Presję na Model Wstępnie Rozgrzanych Pul
Konkurencyjna teza Amazonu nie dotyczy po prostu szybszych kontenerów; chodzi o spójne uruchamianie bez konieczności finansowania przez każdy zespół stale rozgrzanej pojemności.
Dostawcy chmurowi oferują już kilka sposobów ograniczania opóźnień związanych z zimnym startem. Większość podejść wymienia bezczynne zasoby, dostrajanie operacyjne lub ograniczenia aplikacji na szybsze odpowiedzi.
Azure Container Apps firmy Microsoft oferuje dynamic sessions. Korzystają one z pul wstępnie rozgrzanych środowisk, które mogą przydzielać izolowane sesje w milisekundach.
Model ten pasuje do interpreterów kodu i obciążeń wymagających jednorazowych piaskownic. Jego szybkość wynika z dostępności gotowych środowisk przed nadejściem żądania.
Google Cloud Run przyjmuje szersze podejście kontenerowe. Programiści mogą skonfigurować minimum instances, aby utrzymywać kontenery w gotowości, a zwiększenie CPU podczas uruchamiania może przyspieszyć inicjalizację.
Utrzymywanie minimalnej liczby instancji zmniejsza ryzyko zimnych startów, lecz bezczynne instancje mogą podnosić koszty. Zwiększenie CPU podczas uruchamiania usprawnia ścieżkę inicjalizacji, nie eliminując potrzeby załadowania i uruchomienia aplikacji.
Projekt V2 firmy Amazon zajmuje inne miejsce na tej skali. Jednorazowo przygotowuje migawkę środowiska wykonawczego, usuwa niepotrzebny stan i odtwarza izolowane instancje wraz z napływającymi sesjami.
Porównanie nie jest bezwzględne. Wstępnie rozgrzane pule mogą zapewnić mniejsze opóźnienie przydziału niż około dwusekundowy wynik P75 raportowany przez AWS. Mogą także zapewnić wyraźniejszy minimalny poziom pojemności przy przewidywalnym popycie.
Migawki lepiej zachowują ekonomikę skalowania do zera, gdy ruch jest sporadyczny. Ich wartość rośnie, gdy zespół ma wiele agentów nieużywanych przez długie okresy, które jednak muszą odpowiadać konsekwentnie po wywołaniu.
Ta rywalizacja odzwierciedla od dawna obecne pytanie dotyczące serverless. Czy klienci powinni płacić za utrzymywanie gotowej pojemności, czy też platforma powinna sprawić, by tworzenie na żądanie było na tyle przewidywalne, że rozgrzana pojemność stanie się opcjonalna?
Obciążenia agentowe czynią to pytanie bardziej wyrazistym. Firma może obsługiwać setki wyspecjalizowanych agentów, podczas gdy w danym momencie pracę wykonuje tylko niewielka ich część. Utrzymywanie każdego środowiska w gotowości byłoby marnotrawstwem zasobów.
Ruch skokowy rodzi przeciwną obawę. Jeśli wiele sesji uruchamia się jednocześnie, platforma musi szybko odtwarzać migawki, nie wprowadzając kary za współbieżność.
AWS twierdzi, że V2 utrzymuje spójne opóźnienie zimnego startu niezależnie od współbieżności. Opublikowany opis testu porównawczego podkreśla jednak rozmiary obrazów i domyślne limity. Nie ujawnia wszystkich poziomów współbieżności ani warunków regionalnych.
Zespoły oceniające AgentCore powinny porównywać pełne cele dotyczące poziomu usług, a nie jedną wartość uruchomienia. Przydatne miary obejmują opóźnienie ogonowe, czas do pierwszego tokenu modelu, zachowanie odtworzonego cache’u, nieudane starty oraz wydajność podczas nagłych skoków ruchu.
Powinny także porównać całkowite zużycie zasobów. Wstępnie rozgrzana pula ma widoczną bezczynną pojemność, podczas gdy usługa oparta na migawkach może ukrywać koszty w odtwarzaniu, stronicowaniu pamięci, sieci lub powtarzanej inicjalizacji po zmianach we wdrożeniu.
Przenośność pozostaje kolejnym czynnikiem. AgentCore akceptuje aplikacje konteneryzowane i obsługuje frameworki, w tym LangGraph, CrewAI i Strands Agents. Jednak jego kontrolki środowiska wykonawczego, API sesji, warstwa tożsamości i model rozliczeń są specyficzne dla AWS.
Microsoft i Google również zachęcają do integracji z otaczającymi ich usługami tożsamości, monitorowania, pamięci masowej i AI. Decyzja konkurencyjna wykracza więc poza zimne starty.
Przedsiębiorstwo już ustandaryzowane na jednej chmurze może bardziej cenić spójność operacyjną niż przewagę w benchmarku. Zespół budujący platformę agentową wrażliwą na opóźnienia może natomiast bezpośrednio przetestować każde środowisko wykonawcze.
AWS nadal zyskuje istotny argument sprzedażowy. V2 pozwala mu twierdzić, że skalowanie do zera nie wymaga już wzrostu opóźnienia uruchomienia wraz z rozmiarem obrazu kontenera.
Jeśli niezależne obciążenia odtworzą ten wynik, nabywcy usług chmurowych będą oczekiwać, że konkurencyjne platformy wyjaśnią, dlaczego w przypadku porównywalnych aplikacji nadal potrzebne są rozgrzane pule lub minimalna liczba instancji.
Benchmark Jest Mocny, lecz Wąski
AWS pokazał wiarygodne usprawnienie infrastruktury, lecz nie wykazał jeszcze niższego całkowitego kosztu ani przewidywalnego opóźnienia aplikacji dla każdego agenta produkcyjnego.
Pierwszym ograniczeniem jest niezależność źródła. AWS zaprojektował środowisko wykonawcze, wybrał konfigurację testową, przeprowadził benchmark i opublikował wyniki.
Towarzyszący kod testowy pozwala klientom odtworzyć eksperyment na ich kontach. Jest to użyteczne, lecz odtwarzalność nadal zależy od regionu, limitów, projektu kontenera, charakterystyki ruchu i momentu każdego uruchomienia.
Drugim ograniczeniem jest wybór percentyla. P75 daje lepszy obraz niż średnia, lecz usługi wrażliwe na opóźnienia często planuje się wokół wyników P95 lub P99.
Stabilne dwie sekundy na poziomie P75 mogą współistnieć z wolniejszymi zdarzeniami ogonowymi. Ogłoszenie nie przedstawia pełnego rozkładu potrzebnego do oceny rygorystycznych celów zorientowanych na użytkownika.
Trzecim ograniczeniem jest prostota obciążenia. Test echo pomaga izolować uruchomienie platformy, ale kontenery produkcyjne wykonują więcej inicjalizacji i nawiązują więcej zewnętrznych połączeń.
Przechwycenie migawki może utrwalić część inicjalizacji. Nie może zagwarantować, że każde połączenie z bazą danych, wymiana poświadczeń, trasa sieciowa lub zewnętrzna zależność będzie natychmiast użyteczna po odtworzeniu.
Czwarta kwestia dotyczy interpretacji kosztów. AWS twierdzi, że V2 nalicza wyższą stawkę za zasoby niż V1, podczas gdy większość agentów powinna zużywać wystarczająco mniej pamięci, aby obniżyć całkowity rachunek.
To prognoza firmy, a nie uniwersalny rezultat. Agent o stabilnym wykorzystaniu pamięci, który rzadko zwalnia przydziały, może uzyskać ograniczone oszczędności, płacąc jednocześnie wyższą stawkę V2.
Agent z tymczasowymi skokami zużycia pamięci ma silniejsze uzasadnienie. Oszczędności powinny rosnąć, gdy duże bufory znikają wcześnie, a pozostała sesja spędza znaczną część czasu przy niewielkim zapotrzebowaniu na pamięć.
Zespoły powinny testować obie wersje na identycznych śladach. Powinny rejestrować zużycie pamięci w każdej sekundzie, zużycie CPU, czas trwania sesji, opóźnienie odtworzenia, koszty modeli, koszty pamięci masowej i transfer sieciowy.
Telemetria rozliczeniowa również wymaga ostrożności. AWS twierdzi, że dane monitorujące mogą być opóźnione i różnić się od autorytatywnych danych rozliczeniowych z powodu agregacji i uzgadniania.
Piąta obawa dotyczy rotacji cache’u. Jeśli V2 odzyska dane, których agent wkrótce znów potrzebuje, obciążenie może poświęcić dodatkowy czas na ich odtworzenie.
Widoczny próg zapewnia zasada AWS dotycząca odzyskiwania bezczynnej pamięci po 120 sekundach, ale nie wyjaśnia ona w pełni zachowania każdej kategorii pamięci. Programiści powinni testować odstępy między turami przekraczające ten próg.
Szósta obawa dotyczy poprawności migawek. Aplikacje często podczas uruchamiania inicjalizują generatory liczb losowych, poświadczenia, klientów sieciowych, pliki tymczasowe i wątki w tle.
Odtworzony proces nie może ponownie wykorzystywać niebezpiecznego stanu między izolowanymi sesjami. Zespoły powinny zweryfikować zachowanie swoich bibliotek po odtworzeniu oraz zapewnić, aby tożsamość sesji była przekazywana po granicy migawki.
AgentCore zapewnia izolowane mikroVM, ale aplikacja nadal odpowiada za mapowanie użytkowników na sesje. Backend klienta musi uniemożliwić jednemu użytkownikowi podanie lub ponowne użycie identyfikatora sesji innego użytkownika.
Nadal możliwe są również awarie operacyjne. Limity, pojemność regionalna, niezdrowe kontenery, wadliwe kontrole kondycji oraz ograniczenia usług zależnych mogą zdominować doświadczenie użytkownika.
Żadne z tych pytań nie podważa benchmarku V2. Określają one lukę między obiecującym wynikiem platformy a decyzją produkcyjną.
Właściwy wniosek jest warunkowy. V2 wygląda szczególnie atrakcyjnie dla agentów o skokowym ruchu, dużych obrazach, kosztownej inicjalizacji, tymczasowych szczytach zużycia pamięci i długich okresach oczekiwania na model lub narzędzie.
Agenty o stałym wykorzystaniu pamięci, nieprzerwanie aktywnym popycie, wyspecjalizowanych procesorach lub rygorystycznych wymaganiach poniżej sekundy potrzebują szerszego porównania. Sam AWS przygotowuje większe opcje obliczeniowe i zobowiązania bazowe dla części takich obciążeń.
Trzy Sygnały, Które Zdecydują, Czy V2 Wygra
Kolejnym testem będzie to, czy pomiary klientów potwierdzą stabilne opóźnienie uruchomienia, niższe całkowite rachunki i bezpieczne zachowanie migawek poza kontrolowanym benchmarkiem AWS.
Pierwszym sygnałem jest kształt niezależnych wyników opóźnień. Programiści powinni publikować wyniki zimnych startów P50, P75, P95 i P99 w kilku regionach i dla różnych wzorców ruchu.
Rozmiar obrazu powinien pozostać częścią tych testów, ale współbieżność ma równie duże znaczenie. Użyteczna ocena uruchamiałaby nagłe fale izolowanych sesji po przeskalowaniu środowiska wykonawczego do zera.
Jeśli opóźnienie ogonowe pozostanie stabilne wraz ze wzrostem rozmiaru obrazu i współbieżności, główna teza AWS stanie się znacznie silniejsza. Duże kontenery nie będą już zmuszać zespołów do utrzymywania działających zapasowych środowisk.
Jeśli wyniki P95 i P99 będą znacznie się różnić, dwusekundowy nagłówek P75 będzie miał mniejszą wartość operacyjną. Zespoły korzystające z interaktywnych agentów nadal będą potrzebować rozgrzanej pojemności lub agresywnego wcześniejszego tworzenia sesji.
Drugim sygnałem jest zmierzony koszt w pełnych sesjach. Wyższa stawka za zasoby V2 oznacza, że wynik ekonomiczny zależy od tego, ile pamięci środowisko wykonawcze rzeczywiście odzyskuje.
Zespoły powinny odtwarzać obciążenia o znanych fazach. Reprezentatywny test mógłby przetworzyć duży dokument, zwolnić jego bufory, wykonać kilka wywołań modelu, odczekać ponad 120 sekund, a następnie wznowić działanie.
Jeśli rozliczana pamięć spadnie po fazie przetwarzania i pozostanie niska, V2 wesprze argument AWS dotyczący kosztów. Jeśli zużycie pozostanie bliskie wcześniejszemu szczytowi, oczekiwane oszczędności osłabną.
Porównanie powinno obejmować więcej niż opłaty Runtime. Wnioskowanie modeli, obserwowalność, pamięć masowa, transfer sieciowy, pamięć kontenera, sesje przeglądarki i usługi narzędziowe mogą dominować końcowy rachunek.
Szersze spojrzenie zapobiega przedstawianiu niewielkiej oszczędności środowiska wykonawczego jako dramatycznej redukcji na poziomie aplikacji. Ujawnia także, czy szybsze uruchamianie zachęca zespoły do tworzenia niepotrzebnych sesji.
Trzecim sygnałem jest dostarczenie przez AWS możliwości wymienionych jako nadchodzące. Plan rozwoju obejmuje rabaty za zakontraktowaną pojemność bazową, większą moc obliczeniową i pamięć masową, obsługę mikroVM x86, większą kontrolę cyklu życia oraz tożsamość w zakresie sesji.
Każdy element dotyczy obecnego ograniczenia. Większe środowiska zwiększają zakres obsługiwanych obciążeń. Wsparcie dla x86 zmniejsza trudności migracyjne w przypadku zależności, których nie da się łatwo przenieść na inną architekturę.
Mechanizmy wstrzymywania i wznawiania pomogłyby agentom działać dłużej niż przez jeden cykl obliczeniowy. Tożsamość o ograniczonym zakresie sprecyzowałaby, do czego mogą uzyskać dostęp nienadzorowani agenci, gdy żadna osoba aktywnie ich nie monitoruje.
Jeśli AWS udostępni te możliwości wraz z jasną dokumentacją i stabilnym działaniem, Runtime V2 stanie się szerszą platformą, a nie tylko ukierunkowaną optymalizacją cold startów.
Opóźnienia uwidoczniłyby ograniczenia obecnej wersji. Część trwałych, wyspecjalizowanych lub nienadzorowanych obciążeń nadal wymagałaby innych opcji obliczeniowych AgentCore albo zewnętrznej infrastruktury.
Deweloperzy mogą rozpocząć od kontrolowanego testu przejścia z V1 na V2. Powinni zachować bez zmian kod agenta, wywołania modeli, ślad ruchu, region oraz ustawienia obserwowalności.
Decyzja powinna opierać się na pięciu wynikach: percentylach uruchamiania, wskaźniku awarii sesji, zużyciu pamięci w czasie, pełnym opóźnieniu przepływu pracy oraz końcowym rachunku za chmurę.
Produkty interaktywne powinny również przetestować taktykę AWS dla wczesnej fazy sesji. Uruchamianie środowiska w chwili, gdy użytkownik otwiera czat, może ukryć czas startu, lecz porzucone sesje muszą pozostać widoczne w analizie.
Agenci produkcyjni coraz więcej czasu spędzają na oczekiwaniu, utrzymywaniu stanu i koordynowaniu narzędzi, a nie na ciągłym wykonywaniu pracy CPU. To sprawia, że tradycyjna ekonomika kontenerów słabo pasuje do wielu obciążeń.
Amazon Bedrock AgentCore Runtime V2 oferuje technicznie spójną odpowiedź. Przygotowuje pracę tylko raz, odtwarza mniejszą migawkę i zwalnia pamięć, gdy potrzeby sesji maleją.
Pozostaje pytanie empiryczne: czy Amazon Bedrock AgentCore Runtime V2 zachowuje te zalety w warunkach właściwych dla Twoich kontenerów, skoków ruchu, zależności i mechanizmów kontroli bezpieczeństwa?
Uruchom to samo obciążenie na obu wersjach platformy, zachowaj pełny rozkład opóźnień i sprawdź rachunek po uzgodnieniu rozliczeń. To właśnie te dane, a nie nagłówek informacji o premierze, powinny przesądzić o migracji.
