AWS podrobnosti o open-source řídicím plánu HyperPod InstantStart pro operace agentů

Amazon Web Services podrobně představila HyperPod InstantStart, open-source řídicí rovinu, která kombinuje orchestraci Amazon EKS s řízenými funkcemi Amazon SageMaker HyperPod, v AWS Machine Learning Blog post zveřejněném 4. září 2026. Projekt spojuje webové rozhraní s AI agentem, který plánuje a provádí vícestupňové operace clusteru pomocí nástrojů Model Context Protocol.

InstantStart běží jako jediný out-of-band správcovský kontejner v rámci AWS účtu uživatele, volá API služeb AWS i Kubernetes API, aniž by se nacházel v datové cestě trénovacích úloh nebo požadavků na inferenci. Každý vytvořený zdroj je standardní objekt AWS nebo Kubernetes, který lze prohlížet pomocí AWS Command Line Interface a kubectl. Webové UI, REST API a MCP nástroje používané agentem jsou tři podoby stejného kontejneru, takže obě rozhraní vstupují přes jedno backendové rozhraní a podléhají stejným validacím.

Jedno backendové rozhraní za dvěma rozhraními

Hlavním argumentem návrhu v příspěvku je, že MCP nástroje obalují vlastní REST API řídicí roviny místo AWS CLI nebo SDK, takže jednou přidaná validace chrání jak prohlížeč, tak agenta. Ve webovém rozhraní je vytvoření clusteru s nainstalovanými závislostmi, zapnutou automatickou obnovou uzlů a připojeným úložištěm formulář a panel postupu; v terminálu jde o jedinou větu v přirozeném jazyce pro konfiguraci agenta nazvanou hypd-inst-agent, vytvořenou pro Kiro CLI. Agent pak řadí práci: vytvoření řídicí roviny EKS, výběr aktivního clusteru, sladění závislostí, vytvoření HyperPod clusteru a nastavení úložiště. AWS uvádí, že vytvoření řídicí roviny EKS trvá přibližně 8 až 12 minut a každá následující fáze zaznamenává svůj stav a je samostatně opakovatelná.

Tři pravidla pracovního postupu jsou zakódována v dovednostech agenta projektu, které jsou v příspěvku popsány jako markdownové playbooky verzované v repozitáři. Agent sleduje každou dlouho běžící operaci až do terminálního stavu místo hlášení odeslaného požadavku. Pokládá pouze rozhodovací otázky, jako je dostupnost zóny, typ instance a typ kapacity, zatímco subnetové CIDR, směrovací tabulky a bezpečnostní skupiny jsou považovány za práci řídicí roviny. A také kontroluje před vytvořením, vypisuje existující clustery a dotazuje se na platné zóny a typy instancí, než nabídne volby.

Řízené funkce jako sladěný stav

InstantStart vytváří HyperPod clustery s povolenou automatickou obnovou uzlů, přičemž HyperPod může restartovat nebo nahradit vadné uzly na základě svého monitorovacího agenta, základních kontrol zdraví a volitelných hlubokých kontrol, které zatěžují GPU a konektivitu Elastic Fabric Adapter před tím, než uzly přijmou práci. Když uživatel přidá skupinu instancí, typ kapacity, režim síťového rozhraní a umístění subnetu jsou vyřešeny jako jedna operace při vytváření; typ kapacity a režim rozhraní pouze pro EFA jsou pevně dané po celou dobu existence skupiny. Řídicí rovina směruje každou cestu kapacity přes jedinou funkci, která poskytuje výpočetní subnety o velikosti /20 pro velké flotily akcelerátorů.

HyperPod spravované automatické škálování uzlů založené na Karpenteru rozhoduje, kolik této kapacity běží v daném okamžiku, přičemž AWS provozuje samotný Karpenter kontroler a uzly jsou spouštěny ze skupin instancí HyperPod škálovaných od nuly. Příspěvek uvádí jedno omezení rozsahu: spravovaný Karpenter řídí skupiny instancí HyperPod, nikoli kapacitu obecného účelu Amazon EC2.

Panel Pokročilé funkce zobrazuje řízené schopnosti HyperPod, včetně operátoru pro trénování, operátoru pro inferenci, řízeného vrstveného kontrolního bodu a řízeného automatického škálování, přičemž každý přepínač je mapován na operaci backendu s ohledem na závislosti. Povolení vrstveného kontrolního bodu vytvoří řetězec identity zahrnující Kubernetes service account, IAM roli a politiku, vztah důvěry OpenID Connect a anotaci vazby, a jeho vypnutí řetězec odstraní. Příspěvek také popisuje smlouvu explicit-diff přijatou po rané chybě: rozhraní odesílá pouze pole, která uživatel skutečně změnil, a backend čte aktuální stav clusteru a neprovádí žádnou operaci, pokud požadovaný a aktuální stav již odpovídají.

Cesty pro trénování a inferenci

Pro trénování InstantStart nabízí dvě cesty podání. HyperPod tréninkový operátor, nainstalovaný jako EKS add-on, přidává zotavení na úrovni procesu, detekci zaseknutých úloh prostřednictvím monitorování vzorů v logu a detekci odlehlých hodnot, přičemž práce je podána jako zdroje HyperPodPyTorchJob s viditelným rozpočtem na zotavení. Druhá cesta je standardní KubeRay, zaměřená na pracovní zatížení nativní pro Ray, jako je posilování učení. Nad oběma leží vrstva receptů pro čisté PyTorch skripty, LLaMA-Factory, MS-Swift a VERL posilování učení, všechny sdílející jeden datový kontrakt, ve kterém je stejný Amazon S3 bucket připojen jak v vývojovém prostředí, tak uvnitř podů. Logy úloh jsou streamovány do prohlížeče přes WebSocket a recepty mohou hlásit metriky, jako je propustnost trénování, do řízeného MLflow na Amazon SageMaker AI.

Inferenci má také dvě cesty. Řízená cesta předává životní cyklus HyperPod inferenčnímu operátoru, s řízeným vrstveným KV cachováním a inteligentními strategií směrování deklarovanými vedle koncového bodu. Samo-řízená cesta nasazuje kontejner pro servírování dle volby uživatele, například vLLM nebo SGLang, jako standardní nasazení Kubernetes, s typy služeb zahrnující externí load balancer, interní službu clusteru a pool modelů s teplými GPU pracovníky, které lze přerozdělit změnou štítku. Pro více-replikační servírování SGLang může řídicí rovina nasadit SGLang router s cache‑aware směrováním a řídit automatické škálování pomocí Kubernetes Event-driven Autoscaling.

Nástroje agenta a hranice

MCP server zveřejňuje 38 nástrojů pokrývajících životní cyklus clusteru, skupiny instancí, řízené funkce, úložiště, stahování modelů, nasazení inferencí, úlohy a operace uzlů, podle příspěvku. Každý měnící nástroj pojmenovává stavový nástroj, který určuje dokončení, a operace uchovávají svou fázi před zahájením dotazování, takže opakování agenta nemůže znovu provést mutaci. project’s GitHub repository popisuje platformu jako systém integrovaný pro trénování a inferenci postavený na SageMaker HyperPod a standardní orchestraci EKS, a jeho README uvádí, že MCP nástroje obalují backendová API projektu pro soulad s osvědčenými postupy, zatímco dovednosti agenta orchestrují end‑to‑end pracovní postupy bez jakékoli lokální konfigurace kromě agenta.

Příspěvek vymezuje explicitní provozní hranice. Balíčkové diagnostické dovednosti pro NCCL, zdraví uzlů a selhání při vytváření clusteru provádějí jen read‑only vyšetřování, představují příkazy měnící stav jako návrhy a eskalují v pořadí: vyšetřit, restartovat, pak nahradit. IAM, autorizace Kubernetes, síťové kontroly a backendová validace zůstávají skutečnými bezpečnostními hranicemi; agent rozšiřuje přístup k řídicí rovině, aniž by rozšiřoval svá oprávnění. AWS také upozorňuje, že elastické trénování v současnosti vylučuje Spot Instances, řízené vrstvené kontrolní body a trénování bez kontrolních bodů, a že kvóty využití clusteru SageMaker HyperPod a rezervace tréninkových plánů pro špičkové typy GPU je potřeba zařídit před prvním clusterem.

Nasazení začíná z CloudFormation šablony, která vytváří správcovské prostředí, sdílený S3 bucket a podpůrné IAM role, přičemž webové rozhraní je poskytováno z kontejneru na portu 3099 a přístupné přes relaci port‑forwardingu AWS Systems Manager.