AWS Details Open‑Source HyperPod InstantStart Steuerungsebene für Agenten‑Operationen

Amazon Web Services hat HyperPod InstantStart vorgestellt, ein Open‑Source‑Control‑Plane, das die Orchestrierung von Amazon EKS mit den verwalteten Fähigkeiten von Amazon SageMaker HyperPod kombiniert, in einem AWS Machine Learning Blog‑Beitrag vom 4. September 2026. Das Projekt verbindet eine Weboberfläche mit einem KI‑Agenten, der mehrstufige Cluster‑Operationen über Model‑Context‑Protocol‑Werkzeuge plant und ausführt.

InstantStart läuft als ein einzelner Out‑of‑Band‑Management‑Container im AWS‑Konto eines Nutzers, ruft AWS‑Service‑APIs und die Kubernetes‑API auf, ohne im Datenpfad von Trainingsjobs oder Inferenz‑Anfragen zu liegen. Jede von ihm erstellte Ressource ist ein standardmäßiges AWS‑ oder Kubernetes‑Objekt, das mit der AWS Command Line Interface und kubectl einsehbar bleibt. Die Web‑UI, eine REST‑API und die vom Agenten genutzten MCP‑Tools sind drei Facetten desselben Containers, sodass beide Schnittstellen über ein Backend gehen und dieselben Validierungen durchlaufen.

Ein Backend hinter zwei Schnittstellen

Das zentrale Designargument des Beitrags ist, dass die MCP‑Tools die eigenen REST‑APIs der Control Plane umhüllen statt die AWS‑CLI oder das SDK zu verwenden, sodass eine einmal hinzugefügte Validierung sowohl den Browser als auch den Agenten schützt. In der Weboberfläche ist das Erstellen eines Clusters mit installierten Abhängigkeiten, aktivierter automatischer Knoten‑Wiederherstellung und angebundenem Speicher ein Formular und ein Fortschritts‑Panel; in einem Terminal ist es ein einzelner natürlichsprachlicher Satz an eine Agenten‑Konfiguration namens hypd-inst-agent, die für Kiro CLI gebaut wurde. Der Agent ordnet dann die Arbeit: Erstellung der EKS‑Control‑Plane, Auswahl des aktiven Clusters, Abhängigkeitsabgleich, Erstellung des HyperPod‑Clusters und Einrichtung des Speichers. AWS gibt an, dass die Erstellung der EKS‑Control‑Plane etwa 8 bis 12 Minuten dauert und jede nachfolgende Phase ihren eigenen Status protokolliert und unabhängig wiederholbar ist.

Im Projekt sind drei Workflow‑Regeln in den Agenten‑Skills kodiert, die im Beitrag als im Repository versionierte Markdown‑Playbooks beschrieben werden. Der Agent pollt jede langlaufende Operation bis zu einem Endzustand, anstatt nur eine eingereichte Anfrage zu melden. Er stellt ausschließlich entscheidungsrelevante Fragen, wie Verfügbarkeitszone, Instanztyp und Kapazitätstyp, während Subnetz‑CIDRs, Routentabellen und Sicherheitsgruppen als Control‑Plane‑Arbeit behandelt werden. Und er prüft, bevor er erstellt, listet vorhandene Cluster auf und fragt nach gültigen Zonen und Instanztypen, bevor er Auswahlmöglichkeiten anbietet.

Verwaltete Fähigkeiten als abgeglichener Zustand

InstantStart erstellt HyperPod‑Cluster mit aktivierter automatischer Knoten‑Wiederherstellung, wobei HyperPod fehlerhafte Knoten basierend auf seinem Gesundheits‑Monitoring‑Agenten, einfachen Gesundheitsprüfungen und optionalen tiefgreifenden Gesundheitschecks, die GPUs und die Konnektivität des Elastic Fabric Adapter unter Last testen, neu starten oder ersetzen kann, bevor die Knoten Arbeit annehmen. Wenn ein Nutzer eine Instanzgruppe hinzufügt, werden Kapazitätstyp, Netzwerk‑Schnittstellenmodus und Subnetz‑Platzierung als ein einziger Erstellvorgang festgelegt; Kapazitätstyp und reiner EFA‑Schnittstellenmodus bleiben für die gesamte Lebensdauer der Gruppe unverändert. Die Control Plane leitet jeden Kapazitätsweg über eine einzige Funktion, die Compute‑Subnetze der Größe /20 für große Beschleuniger‑Flotten bereitstellt.

Das von HyperPod verwaltete, Karpenter‑basierte Node‑Autoscaling entscheidet, wie viel dieser Kapazität zu einem beliebigen Zeitpunkt genutzt wird, wobei AWS den Karpenter‑Controller selbst betreibt und Knoten aus HyperPod‑Instanzgruppen, die von null hochskaliert werden, gestartet werden. Der Beitrag weist auf eine Eingrenzungs‑Beschränkung hin: verwaltetes Karpenter verwaltet HyperPod‑Instanzgruppen, nicht die allgemeine Amazon‑EC2‑Kapazität.

Das Panel „Advanced Features“ stellt HyperPods verwaltete Fähigkeiten bereit, darunter den Training‑Operator, den Inference‑Operator, verwaltetes gestuftes Checkpointing und verwaltetes Autoscaling, wobei jeder Schalter einer abhängigkeitssensiblen Backend‑Operation zugeordnet ist. Das Aktivieren des gestuften Checkpointings stellt eine Identitätskette bereit, die ein Kubernetes‑Service‑Account, eine IAM‑Rolle und -Richtlinie, eine OpenID‑Connect‑Vertrauensbeziehung und die Bindungs‑Annotation umfasst; das Deaktivieren entfernt dieselbe Kette. Der Beitrag beschreibt zudem einen expliziten Diff‑Vertrag, der nach einem frühen Bug eingeführt wurde: die Oberfläche übermittelt nur Felder, die der Nutzer tatsächlich geändert hat, und das Backend liest den tatsächlichen Cluster‑Zustand und führt ein No‑Op aus, wenn der angeforderte und der aktuelle Zustand bereits übereinstimmen.

Trainings‑ und Inferenzpfade

Für das Training bietet InstantStart zwei Einreichungswege. Der HyperPod‑Training‑Operator, als EKS‑Add‑on installiert, fügt prozessbezogene Fehlertoleranz, Erkennung von hängenden Jobs durch Log‑Muster‑Monitoring und Ausreißer‑Erkennung hinzu, wobei die Arbeit als HyperPodPyTorchJob‑Ressourcen mit einem sichtbaren Wiederherstellungsbudget übermittelt wird. Der zweite Weg ist das Standard‑KubeRay, das auf Ray‑native Workloads wie Reinforcement Learning abzielt. Über beiden liegt eine Rezept‑Schicht für einfache PyTorch‑Skripte, LLaMA‑Factory, MS‑Swift und VERL Reinforcement Learning, die alle denselben Datenvertrag teilen, bei dem derselbe Amazon‑S3‑Bucket sowohl in der Entwicklungsumgebung als auch in Pods eingebunden wird. Job‑Logs werden über WebSocket an den Browser gestreamt, und Rezepte können Metriken wie das Training‑Durchsatz an verwaltetes MLflow auf Amazon SageMaker AI melden.

Auch die Inferenz verfügt über zwei Wege. Der verwaltete Weg übergibt den Lebenszyklus an den HyperPod‑Inference‑Operator, mit verwaltetem gestuftem KV‑Caching und intelligenten Routing‑Strategien, die zusammen mit dem Endpunkt deklariert werden. Der selbstverwaltete Weg stellt einen Serving‑Container nach Wahl des Nutzers bereit, etwa vLLM oder SGLang, als Standard‑Kubernetes‑Deployment, mit Service‑Varianten einschließlich eines externen Load‑Balancers, eines clusterinternen Services und eines Modell‑Pools aus warmen GPU‑Worker‑Instanzen, die durch Ändern eines Labels neu zugewiesen werden können. Für das Serving von SGLang mit mehreren Replikaten kann die Control Plane den SGLang‑Router mit cache‑bewusstem Routing bereitstellen und Autoscaling über Kubernetes Event‑driven Autoscaling steuern.

Agenten‑Tools und Grenzen

Der MCP‑Server veröffentlicht laut Beitrag 38 Werkzeuge, die den Cluster‑Lebenszyklus, Instanzgruppen, verwaltete Funktionen, Speicher, Modell‑Download, Inferenz‑Bereitstellung, Jobs und Knoten‑Operationen abdecken. Jedes mutierende Werkzeug benennt das Status‑Werkzeug, das den Abschluss bestimmt, und Operationen speichern ihre Phase, bevor das Polling beginnt, sodass ein Agenten‑Retry keine Mutation erneut ausführen kann. Das GitHub‑Repository des Projekts beschreibt die Plattform als ein Trainings‑ und Inferenz‑integriertes System, das auf SageMaker HyperPod und standardisierter EKS‑Orchestrierung aufbaut, und das README erklärt, dass die MCP‑Tools die Backend‑APIs des Projekts umhüllen, um Best‑Practice‑Konformität zu gewährleisten, während Agenten‑Skills End‑to‑End‑Workflows ohne lokale Einrichtung jenseits des Agenten orchestrieren.

Der Beitrag zieht klare betriebliche Grenzen. Bündelte Diagnose‑Skills für NCCL, Knoten‑Gesundheit und Cluster‑Erstellungs‑Fehler untersuchen im Nur‑Lese‑Modus eigenständig, präsentieren zustandsändernde Befehle als Vorschläge und eskalieren in der Reihenfolge untersuchen, neu starten, dann ersetzen. IAM, Kubernetes‑Autorisierung, Netzwerk‑Kontrollen und Backend‑Validierung bleiben die tatsächlichen Sicherheitsgrenzen; der Agent erweitert den Zugriff auf die Control Plane, ohne seine Privilegien zu erweitern. AWS weist zudem darauf hin, dass elastisches Training derzeit Spot‑Instanzen, verwaltetes gestuftes Checkpointing und checkpoint‑loses Training ausschließt und dass SageMaker‑HyperPod‑Cluster‑Nutzungs‑Quoten sowie Trainings‑Plan‑Reservierungen für High‑End‑GPU‑Typen vor dem ersten Cluster geregelt werden müssen.

Die Bereitstellung beginnt mit einer CloudFormation‑Vorlage, die die Management‑Umgebung, einen gemeinsamen S3‑Bucket und unterstützende IAM‑Rollen erstellt, wobei die Weboberfläche aus dem Container auf Port 3099 bereitgestellt wird und über eine AWS‑Systems‑Manager‑Port‑Forwarding‑Sitzung erreichbar ist.