AWS: szczegóły otwarto‑źródłowego panelu kontrolnego HyperPod InstantStart dla operacji agenta

Amazon Web Services przedstawił HyperPod InstantStart, otwarto‑źródłowy panel kontrolny, który łączy orkiestrację Amazon EKS z zarządzanymi możliwościami Amazon SageMaker HyperPod, w poście na blogu AWS Machine Learning opublikowanym 4 września 2026 r. Projekt łączy interfejs webowy z agentem AI, który planuje i wykonuje wieloetapowe operacje klastra przy użyciu narzędzi Model Context Protocol.

InstantStart działa jako pojedynczy kontener zarządzania poza pasmem danych w koncie AWS użytkownika, wywołując API usług AWS oraz API Kubernetes, nie będąc częścią ścieżki danych zadań treningowych ani żądań inferencji. Każdy tworzony przez niego zasób jest standardowym obiektem AWS lub Kubernetes, który można przeglądać przy użyciu AWS Command Line Interface oraz kubectl. Interfejs webowy, REST API oraz narzędzia MCP używane przez agenta to trzy aspekty tego samego kontenera, więc oba interfejsy korzystają z jednego backendu i przechodzą te same weryfikacje.

Jedno zaplecze za dwoma interfejsami

Głównym argumentem projektowym wpisu jest to, że narzędzia MCP opakowują własne REST API panelu kontrolnego, a nie AWS CLI ani SDK, dzięki czemu jednorazowo dodana weryfikacja chroni zarówno przeglądarkę, jak i agenta. W interfejsie webowym tworzenie klastra z zainstalowanymi zależnościami, włączonym automatycznym przywracaniem węzłów i zamontowaną pamięcią jest formularzem i panelem postępu; w terminalu jest to pojedyncze zdanie w języku naturalnym skierowane do konfiguracji agenta o nazwie hypd-inst-agent, zbudowanej dla Kiro CLI. Agent następnie kolejkuje pracę: tworzenie kontrolnego płaszczyzny EKS, wybór aktywnego klastra, uzgadnianie zależności, tworzenie klastra HyperPod oraz konfigurację pamięci. AWS podaje, że tworzenie kontrolnego płaszczyzny EKS kończy się w przybliżeniu 8‑12 minut, a każdy kolejny etap zapisuje własny status i może być ponownie wywołany niezależnie.

Trzy zasady przepływu pracy są zakodowane w umiejętnościach agenta projektu, które wpis opisuje jako wersjonowane w repozytorium playbooki w formacie markdown. Agent monitoruje każdą długotrwałą operację aż do stanu końcowego, zamiast raportować złożone żądanie. Zadaje wyłącznie pytania decyzyjne, takie jak strefa dostępności, typ instancji i typ pojemności, traktując CIDRy podsieci, tablice routingu i grupy zabezpieczeń jako pracę panelu kontrolnego. Dodatkowo najpierw sprawdza, wymienia istniejące klastry i zapytuje o dostępne strefy oraz typy instancji, zanim zaproponuje wybory.

Zarządzane możliwości jako stan uzgodniony

InstantStart tworzy klastry HyperPod z włączonym automatycznym przywracaniem węzłów, dzięki czemu HyperPod może ponownie uruchomić lub wymienić uszkodzone węzły na podstawie swojego agenta monitorującego zdrowie, podstawowych kontroli stanu oraz opcjonalnych głębokich testów, które obciążają GPU i łączność Elastic Fabric Adapter przed przyjęciem zadań przez węzły. Gdy użytkownik dodaje grupę instancji, typ pojemności, tryb interfejsu sieciowego i umiejscowienie podsieci są ustalane jako jedna operacja tworzenia; typ pojemności i tryb interfejsu wyłącznie EFA są stałe przez cały okres życia grupy. Panel kontrolny kieruje każdą ścieżkę pojemności przez jedną funkcję, która przydziela podsieci obliczeniowe o rozmiarze /20 dla dużych flot akceleratorów.

Zarządzane przez HyperPod skalowanie automatyczne węzłów oparte na Karpenter decyduje, jaka część tej pojemności jest wykorzystywana w danym momencie, przy czym AWS obsługuje sam kontroler Karpenter, a węzły uruchamiane są z grup instancji HyperPod skalowanych od zera. Wpis zauważa jedno ograniczenie zakresu: zarządzany Karpenter zarządza grupami instancji HyperPod, a nie ogólną pojemnością Amazon EC2.

Panel Zaawansowanych funkcji udostępnia zarządzane możliwości HyperPod, w tym operatora treningu, operatora inferencji, zarządzane warstwowe punktowanie kontrolne oraz zarządzane skalowanie automatyczne, przy czym każdy przełącznik jest powiązany z operacją backendu świadomą zależności. Włączenie warstwowego punktowania kontrolnego tworzy łańcuch tożsamości obejmujący konto serwisowe Kubernetes, rolę i politykę IAM, relację zaufania OpenID Connect oraz adnotację wiązania, a wyłączenie usuwa ten sam łańcuch. Wpis opisuje także kontrakt explicit-diff przyjęty po wczesnym błędzie: interfejs przesyła tylko pola, które użytkownik rzeczywiście zmienił, a backend odczytuje rzeczywisty stan klastra i nie wykonuje operacji, gdy żądany i aktualny stan już się zgadzają.

Ścieżki treningu i inferencji

Do treningu InstantStart oferuje dwie ścieżki zgłaszania. Operator treningu HyperPod, zainstalowany jako dodatek EKS, dodaje odzyskiwanie błędów na poziomie procesu, wykrywanie zawieszonych zadań poprzez monitorowanie wzorców logów oraz wykrywanie odchyleń, przy czym praca jest zgłaszana jako zasoby HyperPodPyTorchJob zawierające widoczny budżet odzyskiwania. Druga ścieżka to standardowy KubeRay, skierowany do obciążeń natywnych dla Ray, takich jak uczenie ze wzmocnieniem. Nad obiema znajduje się warstwa przepisów dla zwykłych skryptów PyTorch, LLaMA-Factory, MS‑Swift i uczenia ze wzmocnieniem VERL, wszystkie korzystające z jednego kontraktu danych, w którym to samo wiadro Amazon S3 jest zamontowane w środowisku deweloperskim i wewnątrz podów. Logi zadań są przesyłane do przeglądarki przez WebSocket, a przepisy mogą raportować metryki, takie jak przepustowość treningu, do zarządzanego MLflow na Amazon SageMaker AI.

Inferencja również ma dwie ścieżki. Zarządzana ścieżka przekazuje cykl życia operatorowi inferencji HyperPod, z zarządzanym warstwowym buforowaniem KV oraz inteligentnymi strategiami routingu deklarowanymi razem z punktem końcowym. Ścieżka samodzielnie zarządzana wdraża kontener serwisowy wybrany przez użytkownika, np. vLLM lub SGLang, jako standardowe wdrożenie Kubernetes, z wariantami usług obejmującymi zewnętrzny load balancer, usługę wewnątrz klastra oraz pulę modeli z rozgrzanymi pracownikami GPU, które można ponownie przydzielić zmieniając etykietę. Dla wielokrotnych replik serwisu SGLang, panel kontrolny może wdrożyć router SGLang z routingiem świadomym cache i sterować skalowaniem automatycznym poprzez Kubernetes Event‑driven Autoscaling.

Narzędzia agenta i granice

Serwer MCP publikuje 38 narzędzi obejmujących cykl życia klastra, grupy instancji, zarządzane funkcje, pamięć, pobieranie modeli, wdrażanie inferencji, zadania i operacje węzłów, zgodnie z wpisem. Każde narzędzie modyfikujące podaje nazwę narzędzia statusowego, które określa zakończenie, a operacje zachowują swoją fazę przed rozpoczęciem monitorowania, dzięki czemu ponowna próba agenta nie może odtworzyć mutacji. Repozytorium GitHub projektu opisuje platformę jako zintegrowany system treningu i inferencji zbudowany na SageMaker HyperPod i standardowej orkiestracji EKS, a jego README stwierdza, że narzędzia MCP opakowują API backendu projektu w celu zapewnienia zgodności z najlepszymi praktykami, podczas gdy umiejętności agenta koordynują przepływy pracy od początku do końca bez żadnej lokalnej konfiguracji poza agentem.

Wpis wyznacza wyraźne granice operacyjne. Zestaw diagnostycznych umiejętności dla NCCL, zdrowia węzłów i niepowodzeń tworzenia klastra badają w trybie tylko do odczytu, prezentują polecenia zmieniające stan jako sugestie i eskalują w kolejności: badanie, restart, a następnie wymiana. IAM, autoryzacja Kubernetes, kontrola sieci i weryfikacja backendu pozostają rzeczywistymi granicami bezpieczeństwa; agent rozszerza dostęp do panelu kontrolnego bez zwiększania swoich uprawnień. AWS dodatkowo informuje, że elastyczny trening obecnie wyklucza Spot Instances, zarządzane warstwowe punktowanie kontrolne oraz trening bez punktów kontrolnych, a limity wykorzystania klastra SageMaker HyperPod oraz rezerwacje planów treningowych dla wysokowydajnych typów GPU muszą być ustalone przed pierwszym klastrem.

Wdrożenie rozpoczyna się od szablonu CloudFormation, który tworzy środowisko zarządzania, współdzielone wiadro S3 oraz wspierające role IAM, przy czym interfejs webowy jest udostępniany z kontenera na porcie 3099 i dostępny poprzez sesję przekierowania portów AWS Systems Manager.