AWS detaljerer open‑source HyperPod InstantStart kontrolplan for agent‑opgaver

Amazon Web Services har detaljeret HyperPod InstantStart, en open‑source kontrolplan, der kombinerer Amazon EKS‑orchestrering med de administrerede funktioner i Amazon SageMaker HyperPod, i et AWS Machine Learning Blogindlæg offentliggjort den 4. september 2026. Projektet parrer en webgrænseflade med en AI‑agent, der planlægger og udfører flertrins‑klyngeoperationer via Model Context Protocol‑værktøjer.

InstantStart kører som en enkelt out‑of‑band‑administrationscontainer i en brugers AWS‑konto, og kalder AWS‑service‑API’er samt Kubernetes‑API’en uden at ligge i datapathen for træningsjobs eller inferens‑anmodninger. Hver ressource, den opretter, er et standard AWS‑ eller Kubernetes‑objekt, som fortsat kan inspiceres med AWS Command Line Interface og kubectl. Web‑UI’et, en REST‑API og MCP‑værktøjerne, som agenten bruger, er tre ansigter af den samme container, så begge grænseflader går gennem den samme backend og underkastes de samme valideringer.

Én backend bag to grænseflader

Blogindlæggets centrale designargument er, at MCP‑værktøjerne indpakker kontrolplanens egne REST‑API’er i stedet for AWS‑CLI eller SDK, så en validering, der tilføjes én gang, beskytter både browseren og agenten. I webgrænsefladen er oprettelse af en klynge med installerede afhængigheder, automatisk node‑gendannelse aktiveret og monteret lager en formular og et fremdriftspanel; i en terminal er det en enkelt naturligt‑sproglig sætning til en agentkonfiguration kaldet hypd-inst-agent, bygget til Kiro CLI. Agenten sekventerer derefter arbejdet: oprettelse af EKS‑kontrolplan, valg af aktiv klynge, afstemning af afhængigheder, oprettelse af HyperPod‑klynge og opsætning af lager. AWS oplyser, at oprettelse af EKS‑kontrolplan afsluttes på cirka 8 til 12 minutter, og hver efterfølgende fase registrerer sin egen status og kan gentages uafhængigt.

Tre arbejdsflow‑regler er indkodet i projektets agent‑færdigheder, som blogindlægget beskriver som markdown‑playbooks versioneret i repository’et. Agenten poller hver langvarig operation til en terminaltilstand i stedet for at rapportere en indsendt anmodning. Den stiller kun beslutnings‑niveau spørgsmål, såsom tilgængelighedszone, instanstype og kapacitetstype, mens subnet‑CIDR‑er, routetabeller og sikkerhedsgrupper behandles som kontrolplan‑arbejde. Og den inspicerer inden den opretter, ved at liste eksisterende klynger og forespørge gyldige zoner og instanstyper, før den tilbyder valg.

Administrerede funktioner som afstemt tilstand

InstantStart opretter HyperPod‑klynger med automatisk node‑gendannelse aktiveret, hvorunder HyperPod kan genstarte eller erstatte fejlbehæftede noder baseret på sin sundhedsovervågnings‑agent, grundlæggende sundhedstjek og valgfrie dybe sundhedstjek, der stresstest‑kører GPU‑er og Elastic Fabric Adapter‑forbindelser, før noder accepterer arbejde. Når en bruger tilføjer en instansgruppe, fastlægges kapacitetstype, netværksgrænsefladetilstand og subnet‑placering som én oprettelsestid‑operation; kapacitetstype og kun‑EFA‑grænsefladetilstand forbliver faste gennem gruppens levetid. Kontrolplanen dirigerer hver kapacitetsti gennem en enkelt funktion, der provisionerer compute‑subnet‑er i størrelse /20 til store accelerator‑flåder.

HyperPod‑administrerede Karpenter‑baserede node‑autoskalering bestemmer, hvor meget af den kapacitet der kører på et givet tidspunkt, med AWS som driver Karpenter‑controlleren, og noder der startes fra HyperPod‑instansgrupper, som skaleres op fra nul. Blogindlægget bemærker en afgrænsningsgrænse: administreret Karpenter håndterer HyperPod‑instansgrupper, ikke generel Amazon EC2‑kapacitet.

Panelet for avancerede funktioner viser HyperPods administrerede funktioner, herunder trænings‑operatoren, inferens‑operatoren, administreret lagdelt checkpoint‑funktion og administreret autoskalering, hvor hver knap er knyttet til en afhængighedsbevidst backend‑operation. Aktivering af lagdelt checkpoint provisionerer en identitets‑kæde, der spænder over en Kubernetes‑service‑konto, en IAM‑rolle og -politik, et OpenID Connect‑tillidsforhold samt binding‑annoteringen, og deaktivering fjerner den samme kæde. Blogindlægget beskriver også en explicit‑diff‑kontrakt, der blev vedtaget efter en tidlig fejl: grænsefladen indsender kun felter, som brugeren faktisk har ændret, og backend læser den faktiske klynge‑tilstand og udfører ingen handling, når den anmodede og faktiske tilstand allerede stemmer overens.

Trænings‑ og inferens‑veje

Til træning tilbyder InstantStart to indsendelsesveje. HyperPod‑trænings‑operatoren, installeret som et EKS‑add‑on, tilføjer proces‑niveau fejlgendannelse, hængende‑job‑detektion gennem log‑mønster‑overvågning og outlier‑detektion, med arbejde indsendt som HyperPodPyTorchJob-ressourcer, der bærer et synligt gendannelsesbudget. Den anden vej er standard KubeRay, rettet mod Ray‑native arbejdsbelastninger såsom forstærknings‑læring. Over begge ligger et opskrift‑lag for rene PyTorch‑scripts, LLaMA‑Factory, MS‑Swift og VERL‑forstærknings‑læring, som alle deler én datakontrakt, hvor den samme Amazon S3‑bucket monteres i udviklingsmiljøet og i pods. Job‑logge strømmer til browseren via WebSocket, og opskrifter kan rapportere målinger såsom trænings‑gennemløb til administreret MLflow på Amazon SageMaker AI.

Inferens har på samme måde to veje. Den administrerede vej overdrager livscyklussen til HyperPod‑inferens‑operatoren, med administreret lagdelt KV‑caching og intelligente routingsstrategier angivet ved siden af endpointet. Den selv‑administrerede vej implementerer en betjeningscontainer efter brugerens valg, såsom vLLM eller SGLang, som en standard Kubernetes‑deployment, med service‑former inklusive en ekstern load balancer, en klynge‑intern service og en model‑pulje af varme GPU‑arbejdere, der kan omfordeles ved at ændre en label. For multi‑replica SGLang‑betjening kan kontrolplanen implementere SGLang‑routeren med cache‑bevidst routing og drive autoskalering via Kubernetes Event‑driven Autoscaling.

Agent‑værktøjer og grænser

MCP‑serveren udgiver 38 værktøjer, der dækker klynge‑livscyklus, instansgrupper, administrerede funktioner, lager, model‑download, inferens‑implementering, jobs og node‑operationer, ifølge blogindlægget. Hvert muterende værktøj navngiver status‑værktøjet, der bestemmer færdiggørelse, og operationer bevarer deres fase, inden pollingen starter, så et agent‑retry ikke kan gentage en mutation. projektets GitHub‑arkiv beskriver platformen som et trænings‑og‑inferens‑integreret system bygget på SageMaker HyperPod og standard EKS‑orchestrering, og dens README angiver, at MCP‑værktøjerne indpakker projekt‑backend‑API’er for at overholde bedste praksis, mens agent‑færdigheder orkestrerer end‑to‑end‑arbejdsflow med nul lokal opsætning udover agenten.

Blogindlægget tegner klare operationelle grænser. Samlede diagnostiske færdigheder for NCCL, node‑sundhed og klynge‑oprettelses‑fejl undersøger kun i læse‑kun‑tilstand, præsenterer tilstand‑ændrende kommandoer som forslag og eskalerer i rækkefølgen undersøge, genstarte, derefter erstatte. IAM, Kubernetes‑autorisation, netværkskontroller og backend‑validering forbliver de faktiske sikkerhedsgrænser; agenten udvider adgangen til kontrolplanen uden at udvide sine rettigheder. AWS rådgiver også, at elastisk træning i øjeblikket udelukker Spot‑instanser, administreret lagdelt checkpoint‑funktion og checkpoint‑fri træning, samt at SageMaker HyperPod‑klynge‑brugs‑kvoter og trænings‑plan‑reservationer for high‑end GPU‑typer skal arrangeres inden den første klynge.

Implementeringen starter fra en CloudFormation‑skabelon, der opretter administrationsmiljøet, en delt S3‑bucket og understøttende IAM‑roller, hvor webgrænsefladen leveres fra containeren på port 3099 og tilgås gennem en AWS Systems Manager‑port‑forwarding‑session.