AWS detaljerar öppen källkod HyperPod InstantStart kontrollplan för agent‑operationer

Amazon Web Services har detaljerat HyperPod InstantStart, en öppen källkod kontrollplan som kombinerar Amazon EKS‑orkestrering med de hanterade funktionerna i Amazon SageMaker HyperPod, i ett AWS Machine Learning‑blogginlägg publicerat den 4 september 2026. Projektet parar ihop ett webbgränssnitt med en AI‑agent som planerar och utför flerstegsklusteroperationer via Model Context Protocol‑verktyg.

InstantStart körs som en enda out‑of‑band‑hanteringscontainer i en användares AWS‑konto, och anropar AWS‑tjänst‑API:er samt Kubernetes‑API utan att befinna sig i datapathen för träningsjobb eller inferensförfrågningar. Varje resurs den skapar är ett standard‑AWS‑ eller Kubernetes‑objekt som kan inspekteras med AWS Command Line Interface och kubectl. Webb‑UI‑t, ett REST‑API och MCP‑verktygen som agenten använder är tre ansikten av samma container, så båda gränssnitten går via samma backend och genomgår samma valideringar.

Ett backend bakom två gränssnitt

Inläggets centrala designargument är att MCP‑verktygen omsluter kontrollplanens egna REST‑API:er snarare än AWS‑CLI eller SDK, så en validering som läggs till en gång skyddar både webbläsaren och agenten. I webbgränssnittet är skapandet av ett kluster med installerade beroenden, automatisk nodåterhämtning aktiverad och lagring monterad ett formulär och en förloppspanel; i en terminal är det en enda naturlig språk‑mening till en agentkonfiguration kallad hypd-inst-agent, byggd för Kiro CLI. Agenten sekvenserar sedan arbetet: skapande av EKS‑kontrollplan, val av aktivt kluster, avstämning av beroenden, skapande av HyperPod‑kluster och lagringsuppsättning. AWS uppger att skapandet av EKS‑kontrollplan tar ungefär 8 till 12 minuter, och varje efterföljande steg registrerar sin egen status och kan återförsökas oberoende.

Tre arbetsflödesregler är kodade i projektets agentskickligheter, som inlägget beskriver som markdown‑handböcker versionerade i repot. Agenten pollar varje långvarig operation tills den når ett terminaltillstånd snarare än att rapportera en inskickad begäran. Den ställer endast beslutskriterie‑frågor, såsom tillgänglighetszon, instanstyp och kapacitetstyp, medan subnet‑CIDR:er, routetabeller och säkerhetsgrupper behandlas som kontrollplansarbete. Och den inspekterar innan den skapar, listar befintliga kluster och frågar efter giltiga zoner och instanstyper innan den erbjuder val.

Hanterade funktioner som avstämt tillstånd

InstantStart skapar HyperPod‑kluster med automatisk nodåterhämtning aktiverad, där HyperPod kan starta om eller ersätta felaktiga noder baserat på sin hälsomonitoreringsagent, grundläggande hälsokontroller och valfria djupa hälsokontroller som stress‑testar GPU:er och Elastic Fabric Adapter‑anslutning innan noderna accepterar arbete. När en användare lägger till en instansgrupp, fastställs kapacitetstyp, nätverksgränssnittsläge och subnet‑placering som en enda skapandeoperation; kapacitetstyp och endast‑EFA‑gränssnittsläge är fasta under gruppens livstid. Kontrollplanen dirigerar varje kapacitetsväg genom en enda funktion som provisionerar beräknings‑subnet med storlek /20 för stora acceleratorflottor.

HyperPod‑hanterad Karpenter‑baserad nod‑autoskalning bestämmer hur mycket av den kapaciteten som körs vid varje given tidpunkt, med AWS som driver Karpenter‑kontrollern själv och noder som startas från HyperPod‑instansgrupper som skalas upp från noll. Inlägget påpekar en avgränsningsgräns: hanterad Karpenter hanterar HyperPod‑instansgrupper, inte generell Amazon EC2‑kapacitet.

Panelen Avancerade funktioner visar HyperPods hanterade funktioner, inklusive träningsoperatören, inferensoperatören, hanterad lagrad checkpointning i nivåer och hanterad autoskalning, där varje växel är kopplad till en beroende‑medveten backend‑operation. Aktivering av nivåindelad checkpointning provisionerar en identitetskedja som sträcker sig över ett Kubernetes‑servicekonto, en IAM‑roll och -policy, ett OpenID Connect‑förtroenderelation och bindnings‑annotation, och inaktivering tar bort samma kedja. Inlägget beskriver också ett explicit‑diff‑avtal som antogs efter ett tidigt fel: gränssnittet skickar endast fält som användaren faktiskt ändrat, och backend läser det faktiska klustertillståndet och gör ingen operation när begärd och faktisk status redan matchar.

Tränings‑ och inferensvägar

För träning erbjuder InstantStart två inlämningsvägar. HyperPod‑träningsoperatören, installerad som ett EKS‑tillägg, lägger till felåterhämtning på processnivå, upptäckt av hängande jobb genom loggmönster‑övervakning och avvikelse‑detektering, med arbete som skickas som HyperPodPyTorchJob-resurser som bär en synlig återhämtningsbudget. Den andra vägen är standard‑KubeRay, avsedd för Ray‑inhemska arbetsbelastningar såsom förstärkningsinlärning. Ovanför båda finns ett receptlager för rena PyTorch‑skript, LLaMA‑Factory, MS‑Swift och VERL‑förstärkningsinlärning, som alla delar ett datakontrakt där samma Amazon S3‑bucket är monterad i utvecklingsmiljön och i pods. Jobb‑loggar strömmar till webbläsaren via WebSocket, och recept kan rapportera mätvärden såsom träningsgenomströmning till hanterad MLflow på Amazon SageMaker AI.

Inferens har på samma sätt två vägar. Den hanterade vägen överlämnar livscykeln till HyperPod‑inferensoperatören, med hanterad nivåindelad KV‑cachning och intelligenta routingsstrategier deklarerade tillsammans med slutpunkten. Den själv‑hanterade vägen distribuerar en serveringscontainer efter användarens val, såsom vLLM eller SGLang, som en standard‑Kubernetes‑distribution, med tjänstetyper inklusive en extern lastbalanserare, en kluster‑intern tjänst och en modellpool av varma GPU‑arbetare som kan omfördelas genom att ändra en etikett. För fler‑replika SGLang‑servering kan kontrollplanen distribuera SGLang‑routern med cache‑medveten routing och driva autoskalning via Kubernetes Event‑driven Autoscaling.

Agentverktyg och gränser

MCP‑servern publicerar 38 verktyg som täcker klustrets livscykel, instansgrupper, hanterade funktioner, lagring, modellnedladdning, inferensdistribution, jobb och nodoperationer, enligt inlägget. Varje muterande verktyg namnger statusverktyget som avgör slutförandet, och operationer bevarar sin fas innan pollning påbörjas så att en agents återförsök inte kan återupprepa en mutation. Projektets GitHub‑repo beskriver plattformen som ett tränings‑ och inferensintegrerat system byggt på SageMaker HyperPod och standard‑EKS‑orkestrering, och dess README anger att MCP‑verktygen omsluter projektets backend‑API:er för bästa praxis‑efterlevnad medan agentskickligheter orkestrerar end‑to‑end‑arbetsflöden med noll lokal konfiguration utöver agenten.

Inlägget drar tydliga operativa gränser. Inkluderade diagnostiska färdigheter för NCCL, nodhälsa och kluster‑skapningsfel undersöker endast i läsläge, presenterar tillståndsändrande kommandon som förslag och eskalerar i ordningen undersök, starta om, sedan ersätt. IAM, Kubernetes‑auktorisation, nätverkskontroller och backend‑validering förblir de faktiska säkerhetsgränserna; agenten breddar åtkomsten till kontrollplanen utan att bredda sina privilegier. AWS rekommenderar också att elastisk träning för närvarande exkluderar Spot‑instanser, hanterad nivåindelad checkpointning och checkpoint‑fri träning, samt att SageMaker HyperPod‑kluster‑användningskvoter och träningsplan‑reservationer för högpresterande GPU‑typer måste ordnas innan det första klustret.

Distribution startar från en CloudFormation‑mall som skapar hanteringsmiljön, en delad S3‑bucket och stödjande IAM‑roller, där webbgränssnittet levereras från containern på port 3099 och nås via en AWS Systems Manager‑port‑forwarding‑session.