AWS detaljerer åpen kildekode HyperPod InstantStart kontrollplan for agent‑operasjoner

Amazon Web Services har detaljert HyperPod InstantStart, en åpen kildekode‑kontrollplan som kombinerer Amazon EKS‑orkestrering med de administrerte funksjonene i Amazon SageMaker HyperPod, i et AWS Machine Learning Blog‑innlegg publisert 4. september 2026. Prosjektet kobler et nettgrensesnitt med en AI‑agent som planlegger og utfører flertrinns klyngeoperasjoner via Model Context Protocol‑verktøy.

InstantStart kjører som en enkelt out‑of‑band‑administrasjonscontainer i en brukers AWS‑konto, og kaller AWS‑tjeneste‑API‑er samt Kubernetes‑API‑en uten å ligge i dataprosessen for treningsjobber eller inferens‑forespørsler. Hver ressurs den oppretter er et standard AWS‑ eller Kubernetes‑objekt som fortsatt kan inspiseres med AWS Command Line Interface og kubectl. Web‑UI‑et, et REST‑API og MCP‑verktøyene som agenten bruker, er tre ansikter av samme container, slik at begge grensesnittene går gjennom ett backend og gjennomgår de samme valideringene.

Én backend bak to grensesnitt

Postens sentrale designargument er at MCP‑verktøyene omslutter kontrollplanens egne REST‑API‑er i stedet for AWS CLI eller SDK, slik at en validering som legges til én gang beskytter både nettleseren og agenten. I nettgrensesnittet er opprettelse av en klynge med installerte avhengigheter, automatisk node‑gjenoppretting aktivert og lagring montert et skjema og et fremdriftspanel; i et terminalvindu er det en enkelt setning på naturlig språk til en agentkonfigurasjon kalt hypd-inst-agent, bygget for Kiro CLI. Agenten sekvenserer deretter arbeidet: opprettelse av EKS‑kontrollplan, valg av aktiv klynge, avhengighetsavstemming, opprettelse av HyperPod‑klynge og oppsett av lagring. AWS oppgir at opprettelse av EKS‑kontrollplan fullføres på omtrent 8 til 12 minutter, og hvert påfølgende trinn registrerer sin egen status og kan prøves på nytt uavhengig.

Tre arbeidsflytregler er kodet inn i prosjektets agent‑ferdigheter, som innlegget beskriver som markdown‑spillbøker versjonert i depotet. Agenten poller hver langvarige operasjon til en terminaltilstand i stedet for å rapportere en innsendt forespørsel. Den stiller kun beslutnings‑nivå spørsmål, som tilgjengelighetssone, instanstype og kapasitets‑type, mens subnett‑CIDR‑er, rutetabeller og sikkerhetsgrupper behandles som kontrollplan‑arbeid. Og den inspiserer før den oppretter, ved å liste eksisterende klynger og forespørre gyldige soner og instanstyper før den tilbyr valg.

Administrerte kapasiteter som avstemt tilstand

InstantStart oppretter HyperPod‑klynger med automatisk node‑gjenoppretting aktivert, der HyperPod kan starte på nytt eller erstatte feilaktige noder basert på sin helsesporings‑agent, grunnleggende helsesjekker og valgfrie dype helsesjekker som stresstester GPU‑er og Elastic Fabric Adapter‑tilkobling før noder godtar arbeid. Når en bruker legger til en instansgruppe, blir kapasitets‑type, nettverksgrensesnitt‑modus og subnett‑plassering fastsatt som én opprettelsestid‑operasjon; kapasitets‑type og kun‑EFA‑grensesnittmodus er faste for gruppens levetid. Kontrollplanen ruter hver kapasitets‑vei gjennom en enkelt funksjon som oppretter beregnings‑subnett på /20 for store akselerator‑flåter.

HyperPod‑administrert Karpenter‑basert node‑autoskalering bestemmer hvor mye av den kapasiteten som kjører til enhver tid, med AWS som driver Karpenter‑kontrolleren selv og noder som starter fra HyperPod‑instansgrupper som skaleres opp fra null. Innlegget bemerker en avgrensnings‑grense: administrert Karpenter styrer HyperPod‑instansgrupper, ikke generell Amazon EC2‑kapasitet.

Panelet for avanserte funksjoner viser HyperPods administrerte kapasiteter, inkludert trenings‑operatoren, inferens‑operatoren, administrert lagdelt sjekkpunkt‑lagring og administrert autoskalering, der hver bryter er knyttet til en avhengighets‑bevisst backend‑operasjon. Aktivering av lagdelt sjekkpunkt‑lagring oppretter en identitets‑kjede som spenner over en Kubernetes‑tjenestekonto, en IAM‑rolle og -policy, et OpenID Connect‑tillitsforhold og bind‑annotasjonen, og deaktivering fjerner samme kjede. Innlegget beskriver også en eksplisitt‑diff‑kontrakt som ble innført etter en tidlig feil: grensesnittet sender kun feltene brukeren faktisk endret, og backend leser den faktiske klyngestatusen og gjør ingenting når den forespurte og faktiske tilstanden allerede stemmer overens.

Trenings‑ og inferensveier

For trening tilbyr InstantStart to innsending‑veier. HyperPod‑trenings‑operatoren, installert som en EKS‑add‑on, legger til feil‑gjenoppretting på prosessnivå, oppdagelse av hengende jobber gjennom loggmønster‑overvåking og avvik‑deteksjon, med arbeid sendt inn som HyperPodPyTorchJob-ressurser som har et synlig gjenopprettingsbudsjett. Den andre veien er standard KubeRay, rettet mot Ray‑native arbeidsbelastninger som forsterkende læring. Over begge ligger et oppskrifts‑lag for vanlige PyTorch‑skript, LLaMA‑Factory, MS‑Swift og VERL‑forsterkende læring, som alle deler én datakontrakt hvor den samme Amazon S3‑bøtten er montert i utviklingsmiljøet og i podder. Jobblogger strømmer til nettleseren via WebSocket, og oppskrifter kan rapportere målinger som trenings‑gjennomstrømning til administrert MLflow på Amazon SageMaker AI.

Inferens har på samme måte to veier. Den administrerte veien overlever livssyklusen til HyperPod‑inferens‑operatoren, med administrert lagdelt KV‑caching og intelligente rutingsstrategier deklarert ved siden av endepunktet. Den selv‑administrerte veien distribuerer en server‑container etter brukerens valg, som vLLM eller SGLang, som en standard Kubernetes‑distribusjon, med tjeneste‑former som en ekstern lastbalanserer, en klynge‑intern tjeneste og en modell‑pool med oppvarmede GPU‑arbeidere som kan omfordeles ved å endre en etikett. For fler‑replika SGLang‑tjeneste kan kontrollplanen distribuere SGLang‑routeren med cache‑bevisst ruting og drive autoskalering gjennom Kubernetes Event‑driven Autoscaling.

Agent‑verktøy og grenser

MCP‑serveren publiserer 38 verktøy som dekker klynge‑livssyklus, instansgrupper, administrerte funksjoner, lagring, modell‑nedlasting, inferens‑distribusjon, jobber og node‑operasjoner, ifølge innlegget. Hvert muterende verktøy navngir statusverktøyet som bestemmer fullføring, og operasjoner lagrer sin fase før polling starter slik at en agent‑retry ikke kan gjenta en mutasjon. Prosjektets GitHub‑depot beskriver plattformen som et trenings‑ og inferens‑integrert system bygget på SageMaker HyperPod og standard EKS‑orkestrering, og README‑filen oppgir at MCP‑verktøyene omslutter prosjektets backend‑API‑er for overholdelse av beste praksis, mens agent‑ferdigheter orkestrerer ende‑til‑ende‑arbeidsflyter med null lokal oppsett utover agenten.

Innlegget trekker frem eksplisitte operasjonelle grenser. Inkluderte diagnostikk‑ferdigheter for NCCL, node‑helse og klynge‑opprettings‑feil undersøker kun lesetilgang på egen hånd, presenterer tilstand‑endrende kommandoer som forslag, og eskalerer i rekkefølgen undersøke, starte på nytt, deretter erstatte. IAM, Kubernetes‑autorisering, nettverkskontroller og backend‑validering forblir de faktiske sikkerhetsgrensene; agenten utvider tilgangen til kontrollplanen uten å utvide sine privilegier. AWS råder også at elastisk trening for øyeblikket ekskluderer Spot‑instanser, administrert lagdelt sjekkpunkt‑lagring og trening uten sjekkpunkt, og at SageMaker HyperPod‑klynge‑bruks‑kvoter og trenings‑plan‑reservasjoner for høykvalitets‑GPU‑typer må ordnes før den første klyngen.

Distribusjonen starter fra en CloudFormation‑mal som oppretter administrasjonsmiljøet, en delt S3‑bøtte og støttende IAM‑roller, med nettgrensesnittet levert fra containeren på port 3099 og nås gjennom en AWS Systems Manager‑port‑videresending‑sesjon.