AWS:n tarkemmat tiedot avoimen lähdekoodin HyperPod InstantStart -ohjauskerroksesta agenttitoiminnoille

Amazon Web Services on kuvannut HyperPod InstantStartin, avoimen lähdekoodin ohjauskerroksen, joka yhdistää Amazon EKS -orchestroinnin Amazon SageMaker HyperPodin hallittuihin ominaisuuksiin, AWS Machine Learning Blog -julkaisussa julkaistu 4. syyskuuta 2026. Projekti yhdistää verkkokäyttöliittymän AI‑agenttiin, joka suunnittelee ja toteuttaa monivaiheisia klusteritoimintoja Model Context Protocol -työkalujen avulla.

InstantStart toimii yhtenä erillisenä hallintakonttainerina käyttäjän AWS-tilissä, kutsuen AWS‑palvelujen API‑rajapintoja ja Kubernetes‑API:a ilman, että se sijoittuu koulutustehtävien tai inferenssipyynnöiden dataväylään. Kaikki sen luomat resurssit ovat standardeja AWS- tai Kubernetes-objekteja, jotka ovat tarkasteltavissa AWS Command Line Interface -työkalulla ja kubectl-komennolla. Verkkokäyttöliittymä, REST‑API ja agentin käyttämät MCP‑työkalut ovat saman konttainerin kolme eri kasvoa, joten molemmat käyttöliittymät kulkevat yhden taustajärjestelmän kautta ja käyvät läpi samat validoinnit.

Yksi taustajärjestelmä kahden käyttöliittymän takana

Julkaisun keskeinen suunnitteluperuste on, että MCP‑työkalut käärittävät ohjauskerroksen omat REST‑API:t sen sijaan, että ne käyttäisivät AWS‑CLI:tä tai SDK:ta, jolloin kerran lisätty validointi suojaa sekä selainta että agenta. Verkkokäyttöliittymässä klusterin luominen, jossa riippuvuudet on asennettu, automaattinen solmujen palautus on käytössä ja tallennustila on liitetty, näkyy lomakkeena ja edistymispaneelina; terminaalissa se on yksi luonnollisen kielen lause agenttikonfiguraatiolle nimeltä hypd-inst-agent, joka on rakennettu Kiro CLI:lle. Agentti sitten jäsentää työn: EKS‑ohjauskerroksen luominen, aktiivisen klusterin valinta, riippuvuuksien sovittaminen, HyperPod‑klusterin luominen ja tallennustilan asennus. AWS:n mukaan EKS‑ohjauskerroksen luominen kestää noin 8–12 minuuttia, ja jokainen myöhempi vaihe tallentaa oman tilansa ja on itsenäisesti uudelleenkäynnistettävissä.

Projektin agenttitaidoissa on koodattu kolme työnkulun sääntöä, jotka julkaisu kuvaa markdown‑pelioppaita versionoituna repositoriossa. Agentti tarkkailee jokaisen pitkään kestävän toiminnon päättymistä tilaan sen sijaan, että se raportoisi lähetetystä pyynnöstä. Se esittää vain päätöksentekokysymyksiä, kuten saatavuusalue, instanssityyppi ja kapasiteettityyppi, ja käsittelee aliverkon CIDR-osoitteet, reititaulut ja turvallisuusryhmät ohjauskerroksen tehtävinä. Lisäksi se tarkastelee ennen luomista, listaa olemassa olevat klusterit ja kysyy kelvollisia alueita ja instanssityyppejä ennen vaihtoehtojen tarjoamista.

Hallitut ominaisuudet sovitettuna tilana

InstantStart luo HyperPod‑klustereita, joissa automaattinen solmujen palautus on käytössä, jolloin HyperPod voi käynnistää uudelleen tai korvata vialliset solmut sen terveydentilan valvontaa tekevästä agentista, perusterveystarkastuksista ja valinnaisista syvällisistä terveystarkastuksista, jotka rasittavat GPU:ita ja Elastic Fabric Adapter -yhteyksiä ennen kuin solmut hyväksyvät työn. Kun käyttäjä lisää instanssiryhmän, kapasiteettityyppi, verkkoliittymän tila ja aliverkon sijoitus ratkaistaan yhtenä luontitoimenpiteenä; kapasiteettityyppi ja pelkästään EFA‑liittymätila ovat kiinteitä ryhmän elinkaaren ajan. Ohjauskerros reitittää jokaisen kapasiteettipolun yhden funktion kautta, joka varaa laskentaaliverkot kooltaan /20 suurille kiihdyttimijoukoille.

HyperPodin hallitsema Karpenter-pohjainen solmujen automaattinen skaalaus päättää, kuinka suuri osa kapasiteetista on käytössä kussakin hetkessä, kun AWS hallinnoi itse Karpenter‑kontrolleria ja solmut käynnistyvät HyperPod‑instanssiryhmistä, jotka on skaalattu nollasta ylöspäin. Julkaisu mainitsee yhden raja‑aspektin: hallittu Karpenter hallinnoi HyperPod‑instanssiryhmiä, ei yleiskäyttöistä Amazon EC2 -kapasiteettia.

Advanced Features -paneeli paljastaa HyperPodin hallitut ominaisuudet, kuten koulutusoperaattorin, inferenssioperaattorin, hallitun tasotetun tarkistuspisteen ja hallitun automaattisen skaalaamisen, joista jokainen kytkin on liitetty riippuvuuksista tietoiselle taustatoiminnolle. Tasotetun tarkistuspisteen käyttöönotto luo identiteettiketjun, joka kattaa Kubernetes‑palvelutilin, IAM‑roolin ja -politiikan, OpenID Connect -luottamussuhteen sekä sidontamerkinnän, ja sen poistaminen poistaa saman ketjun. Julkaisu kuvaa myös eksplisiittistä diff‑sopimusta, joka otettiin käyttöön varhaisen virheen jälkeen: käyttöliittymä lähettää vain ne kentät, joita käyttäjä on todella muuttanut, ja taustajärjestelmä lukee todellisen klusteritilan ja ei tee mitään, jos pyydetty ja todellinen tila jo vastaavat.

Koulutus- ja inferenssipolut

Koulutusta varten InstantStart tarjoaa kaksi lähetystapaa. HyperPod‑koulutusoperaattori, joka on asennettu EKS‑lisäosana, lisää prosessitasoisen vikojen palautuksen, jumiutuneiden tehtävien havaitsemisen lokimallien seurannan kautta sekä poikkeavien havaintojen tunnistuksen, ja työ lähetetään HyperPodPyTorchJob-resursseina, joilla on näkyvä palautusbudjetti. Toinen tapa on standardi KubeRay, joka on suunnattu Ray‑natiivisiin työkuormiin, kuten vahvistusoppimiseen. Molempien yläpuolella on reseptikerros tavallisille PyTorch‑skripteille, LLaMA‑Factorylle, MS‑Swiftille ja VERL‑vahvistusoppimiselle, jotka kaikki jakavat yhden datasopimuksen, jossa sama Amazon S3 -ämpäri on liitetty kehitysympäristöön ja podien sisälle. Työn lokit virtaavat selaimeen WebSocketin kautta, ja reseptit voivat raportoida mittareita, kuten koulutuksen läpimenoaikaa, hallitulle MLflow:lle Amazon SageMaker AI:ssa.

Inferenssillä on vastaavasti kaksi polkua. Hallittu polku siirtää elinkaaren HyperPod‑inferenssioperaattorille, jossa on hallittu tasotettu KV‑välimuisti ja älykkäät reititysstrategiat, jotka on määritelty päätepisteen yhteydessä. Itsehallittu polku ottaa käyttöön käyttäjän valitseman palvelukontin, kuten vLLM:n tai SGLangin, standardina Kubernetes‑asennuksena, jossa palvelumuodot sisältävät ulkoisen kuormantasaajan, klusterin sisäisen palvelun sekä mallipoolin lämpimistä GPU‑työntekijöistä, jotka voidaan uudelleenkohdistaa muuttamalla etikettiä. Monireplika SGLang‑palvelulle ohjauskerros voi ottaa käyttöön SGLang‑reitittimen, jossa on välimuistitietoinen reititys, ja ohjata automaattista skaalausta Kubernetes Event-driven Autoscaling -toiminnon avulla.

Agenttien työkalut ja rajat

MCP‑palvelin julkaisee 38 työkalua, jotka kattavat klusterin elinkaaren, instanssiryhmät, hallitut ominaisuudet, tallennuksen, mallin latauksen, inferenssin käyttöönoton, tehtävät ja solmutoiminnot, julkaisutiedon mukaan. Jokainen muokkaava työkalu nimeää tilatyökalun, joka määrittää suorituksen, ja toiminnot tallentavat vaiheensa ennen tarkkailun aloitusta, jotta agentin uudelleenyritys ei voi toistaa muokkausta. Projektin GitHub-repo kuvaa alustaa koulutus‑ ja inferenssi‑integrointijärjestelmänä, joka on rakennettu SageMaker HyperPodiin ja standardiin EKS‑orchestrointiin, ja sen README kertoo, että MCP‑työkalut käärittävät projektin taustapohjaiset API:t parhaan käytännön noudattamiseksi, kun taas agenttitaidot orkestroivat kokonaisvaltaiset työnkulut ilman paikallista asetusta agentin ulkopuolella.

Julkaisu määrittelee selkeät operatiiviset rajat. Paketoidut diagnostiikkataidot NCCL:lle, solmujen terveydelle ja klusterin luomisen epäonnistumisille tutkivat vain luku -tilassa, esittävät tilaa muuttavia komentoja ehdotuksina ja eskaloivat järjestyksessä tutki, käynnistä uudelleen, sitten korvaa. IAM, Kubernetes‑valtuutus, verkon hallinta ja taustavalidointi pysyvät todellisina turvallisuusrajoina; agentti laajentaa pääsyn ohjauskerrokseen ilman, että sen oikeuksia laajennetaan. AWS myös neuvoo, että elastinen koulutus sulkee tällä hetkellä pois Spot‑instanssit, hallitun tasotetun tarkistuspisteen ja tarkistuspisteettömän koulutuksen, ja että SageMaker HyperPod -klusterin käyttökiintiöt sekä koulutussuunnitelman varaukset huippuluokan GPU‑tyypeille on järjestettävä ennen ensimmäistä klusteria.

Käyttöönotto alkaa CloudFormation‑mallista, joka luo hallintaympäristön, jaetun S3‑ämpärin sekä tukevat IAM‑roolit, ja verkkokäyttöliittymä tarjoillaan kontista portissa 3099 sekä saavutetaan AWS Systems Manager -porttiohjauksen istunnon kautta.