Firma AWS wprowadziła Lambda MicroVMs, nową opcję obliczeń bezserwerowych, umożliwiającą uruchamianie kodu generowanego przez użytkowników i sztuczną inteligencję w odizolowanych, stanowych środowiskach wirtualnych.
Maszyny Lambda MicroVM wykorzystują wirtualizację AWS Firecracker, aby zapewnić oddzielne środowisko wykonawcze dla każdego użytkownika, zadania lub sesji agenta AI. Każda maszyna MicroVM otrzymuje dedykowany HTTPS punkt końcowy i może zachować jego pamięć oraz stan dysku po wstrzymaniu.
AWS pozycjonuje usługę jako usługę przeznaczoną dla agentów kodujących AI, interaktywnych narzędzi programistycznych, platform analizy danych, skanerów bezpieczeństwa, systemów CI/CD i innych aplikacji, które wykonują kod, którego operator platformy nie napisał.
Od HostScoreZ perspektywy… to ogłoszenie ma większe znaczenie niż kolejna premiera AWS Compute. Sugeruje, że hosting AI wykracza poza wdrażanie modeli i… GPU pojemność. W miarę jak agenci AI zaczynają uruchamiać kod, korzystać z narzędzi i zarządzać plikami, środowisko, w którym te działania są wykonywane, staje się oddzielną częścią stosu hostingowego.
Co tak naprawdę ogłosił AWS?
Rozwiązanie AWS Lambda MicroVMs zapewnia odizolowane środowiska wykonawcze, które programiści mogą tworzyć wokół poszczególnych użytkowników, zadań lub sesji agentów.
Programiści pakują swoją aplikację i plik Dockerfile, a następnie proszą Lambdę o utworzenie obrazu MicroVM. AWS inicjuje aplikację i tworzy migawkę przygotowanego środowiska. Nowe maszyny MicroVM są następnie uruchamiane z tej migawki, zamiast powtarzać cały proces konfiguracji.
Każda maszyna MicroVM otrzymuje swój własny HTTPS punkt końcowy. AWS obsługuje połączenia HTTP/2, gRPC i WebSocket, umożliwiając środowisku hostowanie interaktywnych narzędzi programistycznych, usług wykonywania kodu i innych aplikacji wymagających ciągłej komunikacji.
Maszyna MicroVM może również zawiesić się w stanie bezczynności. AWS zachowuje stan pamięci i dysku i przywraca je po powrocie ruchu lub gdy aplikacja zażąda wznowienia. Maksymalny skonfigurowany cykl życia maszyny MicroVM, wliczając czas działania i zawieszenia, wynosi osiem godzin.
Firma AWS ogłosiła wprowadzenie Lambda MicroVMs 22 czerwca 2026 r. i opublikowała bardziej szczegółowy wpis techniczny dotyczący premiery 10 lipca. Pierwsza wersja jest dostępna w Północnej Wirginii, Ohio, Oregonie, Tokio i Irlandii.
Czytaj Ogłoszenie uruchomienia AWS oraz Wpis o uruchomieniu technicznym AWS.
Zatem Lambda MicroVM rozszerza możliwości Lambdy poza krótkie wykonywanie oparte na zdarzeniach. Zapewniają one środowisko o dłuższym czasie życia, które zachowuje stan roboczy, podczas gdy AWS zarządza procesem wirtualizacji, sieci, zawieszania i kończenia.
Dlaczego agenci AI potrzebują środowisk wykonawczych z obsługą stanu?
Agenci AI potrzebują środowisk wykonawczych z uwzględnieniem stanu, ponieważ ich zadania mogą obejmować wiele powiązanych ze sobą działań wykonywanych w trakcie dłuższej sesji.
Agent może wygenerować skrypt, zainstalować pakiet, przetworzyć plik, uruchomić przeglądarkę, wywołać API, sprawdzić wynik, a następnie zmienić następną akcję. Pliki, zależności i stan aplikacji utworzone na wczesnym etapie mogą być nadal potrzebne później.
Ponowne tworzenie środowiska po każdej akcji powodowałoby opóźnienia i zmuszałoby system do wielokrotnego odtwarzania stanu roboczego agenta.
Kod generowany przez sztuczną inteligencję wymaga granicy izolacji
Kod generowany przez sztuczną inteligencję wymaga granicy izolacji, ponieważ platforma nie może zakładać, że każde polecenie będzie zachowywać się zgodnie z oczekiwaniami.
Nieprawidłowy lub zmodyfikowany kod może uzyskać dostęp do poufnych plików, ujawnić dane uwierzytelniające, połączyć się z niepożądanymi systemami lub zakłócić pracę innego użytkownika. Maszyny Lambda MicroVM wykorzystują wirtualizację sprzętową, aby zapewnić każdej sesji osobne środowisko gościa, zamiast uruchamiać każde zadanie w ramach tego samego procesu aplikacji.
Izolacja na poziomie maszyny wirtualnej nie decyduje jednak o tym, co agent może robić.
Wstępny wydruk przeglądu z lipca 2026 r. „Agenci AI z potencjałem cybernetycznym: luki w zabezpieczeniach, powstrzymywanie oceny i reakcja obronna” autorstwa Abu Bakara Siddika (źródło), bada granicę między zdolnymi agentami AI a środowiskami używanymi do ich ochrony. Identyfikuje zagrożenia związane z ujawnieniem danych uwierzytelniających, trwałym dostępem, konfliktami z ograniczeniami sandboxa oraz szybkością zautomatyzowanych działań.
AWS zaleca również programistom odświeżenie danych uwierzytelniających i weryfikację połączeń sieciowych po wznowieniu działania MicroVM. Haki cyklu życia umożliwiają aplikacjom zamykanie połączeń przed zawieszeniem, przywracanie zatwierdzonych połączeń po wznowieniu oraz czyszczenie zasobów przed zakończeniem działania.
Lambda MicroVM izoluje środowisko wykonawcze. Właściciele aplikacji nadal muszą ograniczać narzędzia, uprawnienia, pliki, sieci i usługi zewnętrzne dostępne w tym środowisku.
Retencja stanu obsługuje wieloetapową pracę agenta
Przechowywanie stanu umożliwia agentowi wstrzymanie działania bez utraty plików, pamięci, zainstalowanych zależności i wyników pośrednich.
AWS tworzy każdą maszynę MicroVM z przygotowanej migawki. Środowisko pozostaje aktywne podczas działania agenta, zawiesza się po konfigurowalnym okresie bezczynności i wznawia po otrzymaniu kolejnego żądania.
Ten model redukuje wielokrotną inicjalizację, ale wznawianie nie jest natychmiastowe w każdej sytuacji. AWS twierdzi, że pierwsze żądanie po zawieszeniu oczekuje, aż platforma przywróci stan pamięci i dysku oraz uruchomi hak wznawiania aplikacji. Większe zapisane stany i bardziej złożone procesy wznawiania mogą wydłużyć to opóźnienie.
Retencja stanu pozwala również zachować materiał, który może wymagać odświeżenia lub usunięcia. Zawieszone środowisko może zawierać tokeny uwierzytelniające, sesje przeglądarki, wygenerowane skrypty, pliki tymczasowe lub nieaktualne połączenia sieciowe.
Serwer bezstanowy z obsługą stanu poprawia ciągłość działań agentów, ale wymaga więcej zarządzania cyklem życia i dostępem niż jednorazowa funkcja bezstanowa.
Czy stanowe mikromaszyny wirtualne zastąpią tradycyjny hosting?
Maszyny MicroVM z funkcją Stateful nie zastępują tradycyjnego hostingu. Wykonują one tymczasowe zadania agenta, podczas gdy serwery chmurowe, hosting VPS, serwery dedykowane i systemy bare metal nadal obsługują trwałe usługi związane z tymi zadaniami.
SpecBox Pokazuje, dlaczego szybkość piaskownicy ma znaczenie
Najnowsze badania wskazują, że przygotowanie środowiska testowego może mieć istotny wpływ na wydajność agenta AI.
Dokument z lipca 2026 r. „SpecBox:Spekulacyjne planowanie piaskownicy dla efektywnej obsługi agentów LLM"(źródło) zbadali kompromis między uruchamianiem piaskownic na żądanie a utrzymywaniem ich w ciągłej aktywności. Uruchamianie środowiska tylko na żądanie agenta może powodować opóźnienia przy zimnym starcie. Utrzymywanie wszystkich możliwych piaskownic w stanie aktywnym zmniejsza te opóźnienia, ale zużywa więcej pamięci.
SpecBox Przewiduje, którego środowiska testowego może potrzebować agent, gdy model językowy wciąż generuje dane wyjściowe. Następnie system rozpoczyna przygotowywanie tego środowiska przed zakończeniem wywołania narzędzia.
W testach autorów SpecBox Zmniejszyło opóźnienie między serwerami P99 nawet 2.9-krotnie w porównaniu z bazową wersją piaskownicy na żądanie. Zmniejszyło również szczytowe zużycie pamięci o 45.9% w porównaniu z wdrożeniami piaskownicy z rezerwacją stałą (zrzut ekranu poniżej).
SpecBox To prototyp badawczy, który nie testował maszyn AWS Lambda MicroVM. Jego wyniki wciąż pokazują, dlaczego szybkość uruchamiania, wznawiania i przełączania w środowisku testowym może stać się istotnym wskaźnikiem hostingu AI.
Szybko GPU nie gwarantuje szybkiego działania agenta, gdy środowisko wykonawcze opóźnia każde wywołanie narzędzia.
Trwały hosting nadal obsługuje platformę AI
Tradycyjny hosting obejmuje systemy, które muszą być dostępne przed, w trakcie i po każdej tymczasowej sesji agenta. Te trwałe systemy mogą obejmować aplikacje. APIs, relacyjne bazy danych, przechowywanie danych wektorowych, orkiestracja agentów, kolejki komunikatów, usługi monitorowania, bramy modelowe i długotrwałe procesy robocze. Dedykowane GPU infrastruktura może również obsługiwać stałe obciążenia związane z wnioskowaniem o modelu lub szkoleniem.
Atlantic.Net, na przykład, zapewnia infrastrukturę dla tej trwałej części architektury. Jej obecne usługi obejmują wirtualne serwery w chmurze, serwery dedykowane, systemy bare metal, zarządzaną infrastrukturę oraz chmurę lub serwery dedykowane. GPU hosting. Dostawca hostingu obecnie wymienia NVIDIA Opcje L40S i H100 NVL dla zadań związanych ze sztuczną inteligencją, uczeniem maszynowym, wnioskowaniem i przyspieszonymi obliczeniami.
Platforma AI mogłaby używać maszyn MicroVM z funkcją stanu do izolowania tymczasowego wykonywania kodu podczas działania aplikacji, bazy danych, pamięci masowej i zasobów prywatnych APIslub GPU obciążenia na trwałej infrastrukturze z Atlantic.Net lub innego dostawcy serwera.
Te modele hostingu rozwiązują różne części tej samej architektury. Mikromaszyny wirtualne zarządzają wykonywaniem opartym na sesjach, podczas gdy VPS, dedykowane, bare metal i GPU Serwery obsługują usługi, które muszą być dostępne online.
HostScore Weź: Hosting AI staje się czymś więcej niż GPUs
Hosting AI rozszerza się poza GPU Specyfikacje, obsługa modeli i szybkość wnioskowania. Te atrybuty nadal decydują o tym, czy dostawca może uruchamiać wymagające modele. Jednak AWS Lambda MicroVM podkreśla inną część stosu infrastruktury: środowisko, w którym agent AI wykonuje swoje działania.
Podczas badania naszych ostatnich Najlepszy hosting AI oraz Najlepsze przewodniki po hostingu LLModkryliśmy, że dostawcy usług hostingowych wyróżniają się przede wszystkim dostępnością akceleratorów, obsługiwanymi modelami, elastycznością wdrażania, usługami zarządzanymi i kontrolą nad stosem oprogramowania.
Ogłoszenie AWS sugeruje, że środowiska wykonawcze mogą stać się kolejnym czynnikiem różnicującym.
Dostawcy infrastruktury AI mogą coraz częściej konkurować ze sobą pod względem szybkości uruchamiania środowisk testowych, efektywności zapamiętywania stanu roboczego, stopnia izolacji sesji oraz stopnia kontroli dostępu do sieci i narzędzi.
Może to również spowodować zmianę jednostki, wokół której są przydzielane zasoby hostingowe.
Hosting współdzielony przydziela zasoby wokół konta. Hosting VPS przydziela serwer wirtualny. Platformy kontenerowe przydzielają instancje aplikacji. Funkcje bezserwerowe przydzielają moc obliczeniową wokół żądań lub zdarzeń.
Platformy agentów AI mogą alokować infrastrukturę wokół sesji agenta. Sesja agenta uruchamia odizolowane środowisko, uruchamia narzędzia, zmienia pliki, wstrzymuje działanie, wznawia je i kończy działanie po zakończeniu zadania. Ten wzorzec mieści się pomiędzy krótkotrwałymi funkcjami bezstanowymi a trwale działającymi serwerami wirtualnymi.
Nie oczekujemy, że infrastruktura oparta na sesjach agentów zastąpi dotychczasowe kategorie hostingu. Bardziej prawdopodobne jest, że stanie się kolejną warstwą w ramach mieszanego stosu AI.
Trwała chmura, VPS, dedykowana i serwery bare metal będzie nadal hostować aplikacje i usługi związane z danymi. GPU Infrastruktura będzie wykonywać obciążenia modelowe. Stateful MicroVM i inne technologie sandbox będą obsługiwać tymczasowe działania agentów.
AWS sygnalizuje szerszą zmianę w infrastrukturze AI
Rozwiązanie AWS Lambda MicroVMs pokazuje, że agenci AI generują zapotrzebowanie na odizolowane środowiska wykonawcze z tymczasowym przechowywaniem stanu i kontrolą cyklu życia zarządzaną przez dostawcę.
Usługa nie obejmuje serwerów w chmurze, hostingu VPS, serwerów dedykowanych, infrastruktury bare metal ani GPU Hosting przestarzałych systemów. Systemy te będą nadal obsługiwać bazy danych, aplikacje, usługi orkiestracji i obciążenia modeli związane z każdą sesją agenta.
Szerszą zmianą jest sposób oceny hostingu AI.
GPU Pojemność i szybkość modelu pozostaną kluczowe. Dostawcy hostingu mogą również konkurować pod względem szybkości i bezpieczeństwa uruchamiania, zawieszania, przywracania i zamykania odizolowanych środowisk wykonawczych.
To jest ważniejszy sygnał hostingowy stojący za AWS Lambda MicroVMs.