AWS Dettaglia il Piano di Controllo Open-Source HyperPod InstantStart per le Operazioni degli Agenti

Amazon Web Services ha illustrato HyperPod InstantStart, un piano di controllo open-source che combina l’orchestrazione di Amazon EKS con le funzionalità gestite di Amazon SageMaker HyperPod, in un post del blog AWS Machine Learning pubblicato il 4 settembre 2026. Il progetto accoppia un’interfaccia web con un agente IA che pianifica ed esegue operazioni di cluster a più fasi tramite gli strumenti Model Context Protocol.

InstantStart funziona come un unico contenitore di gestione out-of-band all’interno dell’account AWS di un utente, chiamando le API dei servizi AWS e l’API di Kubernetes senza trovarsi nel percorso dati dei job di addestramento o delle richieste di inferenza. Ogni risorsa creata è un oggetto standard di AWS o Kubernetes, ispezionabile tramite l’AWS Command Line Interface e kubectl. L’interfaccia web, l’API REST e gli strumenti MCP usati dall’agente sono tre facce dello stesso contenitore, quindi entrambe le interfacce accedono a un unico backend e superano le stesse convalide.

Un Backend Dietro Due Interfacce

L’argomento di design centrale del post è che gli strumenti MCP avvolgono le API REST del piano di controllo anziché la AWS CLI o SDK, così una convalida aggiunta una sola volta protegge sia il browser sia l’agente. Nell’interfaccia web, creare un cluster con dipendenze installate, recupero automatico dei nodi attivato e storage montato è un modulo e un pannello di avanzamento; in un terminale, è una singola frase in linguaggio naturale per una configurazione dell’agente chiamata hypd-inst-agent, costruita per Kiro CLI. L’agente poi sequenzia il lavoro: creazione del control‑plane EKS, selezione del cluster attivo, riconciliazione delle dipendenze, creazione del cluster HyperPod e configurazione dello storage. AWS afferma che la creazione del control‑plane EKS richiede circa 8‑12 minuti, e ciascuna fase successiva registra il proprio stato ed è ripetibile in modo indipendente.

Tre regole di flusso di lavoro sono codificate nelle competenze dell’agente del progetto, descritte nel post come playbook markdown versionati nel repository. L’agente monitora ogni operazione a lunga durata fino a uno stato terminale anziché segnalare una richiesta inviata. Pone solo domande di livello decisionale, come Zona di disponibilità, tipo di istanza e tipo di capacità, trattando CIDR di subnet, tabelle di routing e gruppi di sicurezza come lavoro del control‑plane. Inoltre, ispeziona prima di creare, elencando i cluster esistenti e interrogando zone e tipi di istanza validi prima di offrire scelte.

Funzionalità Gestite come Stato Riconciliato

InstantStart crea cluster HyperPod con il recupero automatico dei nodi abilitato, così HyperPod può riavviare o sostituire nodi difettosi basandosi sul suo agente di monitoraggio della salute, controlli di salute di base e controlli di salute approfonditi opzionali che stressano GPU e connettività Elastic Fabric Adapter prima che i nodi accettino lavoro. Quando un utente aggiunge un gruppo di istanze, tipo di capacità, modalità dell’interfaccia di rete e posizionamento della subnet vengono definiti come un’unica operazione di creazione; tipo di capacità e modalità interfaccia solo EFA rimangono fissi per tutta la durata del gruppo. Il control‑plane indirizza ogni percorso di capacità attraverso una singola funzione che provvede subnet di calcolo dimensionate a /20 per grandi flotte di acceleratori.

L’autoscaling dei nodi basato su Karpenter gestito da HyperPod decide quanta capacità viene eseguita in ogni momento, con AWS che gestisce il controller Karpenter stesso e i nodi che si avviano da gruppi di istanze HyperPod scalati da zero. Il post segnala un limite di ambito: Karpenter gestito amministra i gruppi di istanze HyperPod, non la capacità generica di Amazon EC2.

Il pannello Funzionalità Avanzate espone le capacità gestite di HyperPod, inclusi l’operatore di addestramento, l’operatore di inferenza, il checkpointing a livelli gestito e l’autoscaling gestito, con ogni interruttore collegato a un’operazione backend consapevole delle dipendenze. L’attivazione del checkpointing a livelli provvede a una catena di identità che comprende un account di servizio Kubernetes, un ruolo e una policy IAM, una relazione di fiducia OpenID Connect e l’annotazione di binding; la sua disattivazione rimuove la stessa catena. Il post descrive inoltre un contratto explicit‑diff adottato dopo un bug iniziale: l’interfaccia invia solo i campi effettivamente modificati dall’utente, e il backend legge lo stato reale del cluster e non esegue operazioni quando lo stato richiesto e quello reale coincidono.

Percorsi di Addestramento e Inferenza

Per l’addestramento, InstantStart offre due percorsi di invio. L’operatore di addestramento HyperPod, installato come add‑on EKS, aggiunge recupero di errori a livello di processo, rilevamento di job bloccati tramite monitoraggio di pattern di log e rilevamento di outlier, con il lavoro inviato come risorse HyperPodPyTorchJob dotate di un budget di recupero visibile. Il secondo percorso è il KubeRay standard, destinato a carichi di lavoro nativi Ray come il reinforcement learning. Sopra entrambi si trova uno strato di ricette per script PyTorch semplici, LLaMA‑Factory, MS‑Swift e VERL reinforcement learning, tutti condividono lo stesso contratto dati in cui lo stesso bucket Amazon S3 è montato sia nell’ambiente di sviluppo sia all’interno dei pod. I log dei job vengono trasmessi al browser via WebSocket, e le ricette possono segnalare metriche come il throughput di addestramento a MLflow gestito su Amazon SageMaker AI.

Anche l’inferenza dispone di due percorsi. Il percorso gestito affida il ciclo di vita all’operatore di inferenza HyperPod, con caching KV a livelli gestito e strategie di routing intelligenti dichiarate accanto all’endpoint. Il percorso auto‑gestito distribuisce un contenitore di servizio a scelta dell’utente, come vLLM o SGLang, come un deployment Kubernetes standard, con forme di servizio che includono un bilanciatore di carico esterno, un servizio interno al cluster e un pool di modelli costituito da worker GPU riscaldati, riassegnabili modificando un’etichetta. Per il servizio SGLang a più repliche, il control‑plane può distribuire il router SGLang con routing consapevole della cache e guidare l’autoscaling tramite Kubernetes Event‑driven Autoscaling.

Strumenti dell’Agente e Confini

Il server MCP pubblica 38 strumenti che coprono il ciclo di vita del cluster, i gruppi di istanze, le funzionalità gestite, lo storage, il download del modello, il deployment dell’inferenza, i job e le operazioni sui nodi, secondo il post. Ogni strumento di mutazione indica lo strumento di stato che determina il completamento, e le operazioni conservano la loro fase prima dell’avvio del polling così un nuovo tentativo dell’agente non può ripetere una mutazione. Il repository GitHub del progetto descrive la piattaforma come un sistema integrato di addestramento e inferenza costruito su SageMaker HyperPod e sull’orchestrazione standard di EKS, e il suo README afferma che gli strumenti MCP avvolgono le API backend del progetto per garantire la conformità alle migliori pratiche, mentre le competenze dell’agente orchestrano flussi di lavoro end‑to‑end senza alcuna configurazione locale oltre all’agente.

Il post delinea confini operativi espliciti. Le competenze diagnostiche integrate per NCCL, salute dei nodi e fallimenti nella creazione del cluster indagano in modalità sola lettura, presentano comandi che modificano lo stato come suggerimenti e scalano nell’ordine indaga, riavvia, poi sostituisci. IAM, autorizzazione Kubernetes, controlli di rete e convalida backend rimangono i veri confini di sicurezza; l’agente amplia l’accesso al control‑plane senza ampliare i suoi privilegi. AWS consiglia inoltre che l’addestramento elastico attualmente esclude le Spot Instances, il checkpointing a livelli gestito e l’addestramento senza checkpoint, e che i limiti di utilizzo dei cluster SageMaker HyperPod e le prenotazioni di piani di addestramento per tipi di GPU di fascia alta devono essere organizzati prima del primo cluster.

Il deployment parte da un modello CloudFormation che crea l’ambiente di gestione, un bucket S3 condiviso e ruoli IAM di supporto, con l’interfaccia web servita dal contenitore sulla porta 3099 e raggiungibile tramite una sessione di port‑forwarding di AWS Systems Manager.