AWS ha reso disponibile HyperPod InstantStart, un control plane open source progettato per riunire l’orchestrazione di Amazon EKS e le funzionalità gestite di Amazon SageMaker HyperPod in un unico ambiente operativo. Il sistema è pensato per gestire infrastrutture dedicate al training e all’inferenza dei modelli AI attraverso due modalità che utilizzano lo stesso backend: un’interfaccia web e un agente AI capace di pianificare ed eseguire operazioni articolate tramite strumenti basati sul Model Context Protocol, MCP. InstantStart viene eseguito all’interno dell’account AWS come singolo container di gestione esterno al percorso dati: comunica con le API dei servizi AWS e con le API Kubernetes, ma non si interpone nei job di training né nelle richieste di inferenza. Le risorse generate rimangono normali risorse AWS o Kubernetes e possono quindi essere ispezionate direttamente tramite AWS CLI e kubectl.
L’interfaccia web, le API REST e gli strumenti MCP utilizzati dall’agente accedono allo stesso control plane. Gli strumenti dell’agente non richiamano direttamente AWS CLI o SDK per costruire autonomamente le operazioni, ma utilizzano le API REST del backend di InstantStart. Questo permette di applicare alle richieste provenienti dall’agente le stesse verifiche, regole di configurazione e procedure di riconciliazione utilizzate dall’interfaccia grafica. La configurazione dell’agente prevista dal progetto è hypd-inst-agent, utilizzabile tramite Kiro CLI. Le procedure operative dell’agente sono inoltre definite attraverso skill conservate come playbook Markdown versionati nel repository, che specificano l’ordine delle operazioni e le condizioni da controllare durante l’esecuzione.
La creazione di un cluster viene suddivisa in fasi distinte. InstantStart procede inizialmente alla creazione del control plane EKS, quindi seleziona il cluster attivo, riconcilia le dipendenze necessarie, crea il cluster HyperPod e configura lo storage. La sola creazione del control plane EKS richiede indicativamente tra 8 e 12 minuti. Ogni fase successiva mantiene uno stato proprio e può essere ripetuta autonomamente in caso di errore, evitando di dover ricominciare l’intera procedura. L’agente continua inoltre a interrogare lo stato delle operazioni asincrone fino al raggiungimento di uno stato conclusivo, invece di limitarsi a inviare la richiesta. Prima di creare nuove risorse controlla quelle già presenti e interroga le configurazioni disponibili, per esempio le Availability Zone e i tipi di istanza utilizzabili. All’utente vengono lasciate soprattutto le decisioni relative a parametri come zona di disponibilità, tipo di istanza e modalità di capacità, mentre subnet, routing, security group e ordine delle dipendenze vengono gestiti dal control plane.
InstantStart crea i cluster HyperPod con automatic node recovery abilitato. HyperPod può quindi riavviare o sostituire nodi che presentano problemi rilevati dal proprio sistema di monitoraggio, attraverso controlli sanitari di base e, se configurati, deep health check che sottopongono a verifica anche GPU e connettività Elastic Fabric Adapter prima che i nodi vengano messi a disposizione dei workload. Quando viene aggiunto un instance group, InstantStart gestisce in una singola operazione parametri come tipo di capacità, configurazione delle interfacce di rete e subnet. La capacità può essere On-Demand, Spot per workload compatibili con le interruzioni oppure riservata tramite SageMaker Training Plan. Alcuni parametri, tra cui il tipo di capacità e determinate configurazioni EFA, vengono stabiliti al momento della creazione del gruppo e non possono essere modificati successivamente. Le subnet destinate ai grandi gruppi di acceleratori vengono predisposte con dimensionamento /20 e possono essere dedicate a uno specifico gruppo quando è necessario evitare l’esaurimento degli indirizzi IP.
Per la gestione dinamica delle risorse è disponibile il node autoscaling basato su Karpenter gestito da HyperPod. In questo caso AWS gestisce direttamente il controller Karpenter, mentre i nodi vengono avviati partendo dagli instance group HyperPod, che possono essere scalati da zero in funzione dei workload. I nodi continuano così a beneficiare del monitoraggio e del recupero automatico propri di HyperPod. L’autoscaling utilizza normali oggetti Karpenter NodePool associati a HyperpodNodeClass e può ridurre nuovamente verso zero i gruppi rimasti inattivi. Questa funzionalità riguarda però gli instance group HyperPod e non costituisce un sistema generale di autoscaling per qualsiasi capacità Amazon EC2 presente nell’account.
Le funzionalità avanzate di HyperPod vengono esposte attraverso un unico livello di configurazione che comprende training operator, inference operator, managed tiered checkpointing e autoscaling gestito. Ogni modifica viene tradotta in un’operazione del backend che tiene conto delle relative dipendenze. L’abilitazione del managed tiered checkpointing, per esempio, richiede la costruzione dell’intera catena di identità necessaria per consentire ai workload Kubernetes di accedere alle risorse AWS: service account Kubernetes, ruolo e policy IAM, relazione di trust OpenID Connect e relativa annotazione di collegamento. Quando la funzionalità viene disattivata, InstantStart rimuove la stessa catena. Il sistema adotta inoltre un meccanismo di explicit diff: l’interfaccia comunica al backend soltanto i campi effettivamente modificati dall’utente, mentre il backend confronta la richiesta con lo stato reale del cluster e non applica modifiche quando i due stati coincidono. Questo evita che un aggiornamento relativo a una funzione possa modificare involontariamente dipendenze o impostazioni appartenenti ad altre funzioni.
Per il training sono disponibili due percorsi. Il primo utilizza Amazon SageMaker HyperPod Training Operator, installato come add-on di EKS, che introduce recupero dei processi in caso di errore, rilevamento dei job bloccati attraverso il monitoraggio dei log e individuazione degli outlier nei workload distribuiti. I job vengono rappresentati come risorse HyperPodPyTorchJob e includono esplicitamente le politiche di recupero. Il secondo percorso utilizza KubeRay ed è destinato soprattutto ai workload nativamente basati su Ray, come diversi flussi di reinforcement learning. Entrambe le modalità operano sugli stessi nodi HyperPod e possono utilizzare gli stessi sistemi di storage e monitoraggio. Sopra questi due meccanismi InstantStart fornisce inoltre recipe per script PyTorch, LLaMA-Factory, MS-Swift e VERL per reinforcement learning.
Le recipe adottano un modello comune per i dati. Lo stesso bucket Amazon S3 può essere montato nell’ambiente di sviluppo e nei pod di training, permettendo di aggiornare script o configurazioni senza dover ricostruire ogni volta l’immagine del container. I log dei job vengono inviati all’interfaccia web tramite WebSocket e le recipe possono registrare metriche, compreso il throughput di training, su Managed MLflow in Amazon SageMaker AI. InstantStart gestisce anche il percorso IAM necessario ai pod per scrivere le informazioni delle esecuzioni, mentre l’interfaccia può mostrare lo storico degli esperimenti e supportare la condivisione tra account regolata tramite permessi IAM granulari.
Anche per l’inferenza vengono mantenuti due modelli operativi. Nel percorso gestito, HyperPod Inference Operator controlla il ciclo di vita dell’endpoint partendo da una configurazione dichiarativa che comprende posizione del modello su Amazon S3, immagine del worker, porta di invocazione, risorse GPU e numero di repliche. Sono disponibili managed tiered KV caching e strategie di intelligent routing. La cache può utilizzare un livello L1 nella memoria CPU e un secondo livello appoggiato a Redis o al managed tiered storage di SageMaker, mentre il routing può utilizzare strategie prefix-aware, KV-aware, basate sulla sessione oppure round-robin.
Il percorso self-managed consente invece di distribuire un container scelto dall’utente, compresi vLLM, SGLang o immagini personalizzate, come normale deployment Kubernetes. Il servizio può essere esposto tramite load balancer esterno, servizio interno al cluster oppure tramite un model pool costituito da worker GPU già avviati. In quest’ultimo caso i worker possono essere assegnati a servizi diversi modificando un’etichetta Kubernetes, evitando di distruggere i pod e ricaricare ogni volta i pesi del modello. Con distribuzioni SGLang multi-replica è possibile utilizzare anche SGLang Router con routing sensibile alla cache e autoscaling basato su Kubernetes Event-driven Autoscaling, KEDA.
Il server MCP mette a disposizione 38 strumenti che coprono il ciclo di vita dei cluster, gli instance group, le funzionalità gestite, lo storage, il download dei modelli, il deployment per inferenza, i job e le operazioni sui nodi. Ogni strumento che modifica lo stato indica anche quale strumento deve essere utilizzato per verificarne il completamento. Lo stato dell’operazione viene registrato prima dell’avvio del polling, in modo che un eventuale nuovo tentativo dell’agente non ripeta accidentalmente una modifica già effettuata. Le skill definiscono invece le sequenze complete: la creazione del cluster, per esempio, stabilisce come controllare lo stato esistente e come riprendere una procedura interrotta, mentre altre skill impongono controlli sulla disponibilità delle GPU o sulla compatibilità tra Training Plan e Availability Zone.
Sono previste anche regole specifiche per la diagnostica. Le skill destinate all’analisi dei problemi NCCL, dello stato dei nodi e degli errori di creazione dei cluster eseguono autonomamente soltanto operazioni di lettura. Quando sarebbe necessario intervenire sullo stato dell’infrastruttura, il comando viene presentato come proposta e richiede approvazione. La sequenza di escalation prevista è prima l’analisi del problema, poi l’eventuale riavvio e infine la sostituzione del nodo. I limiti effettivi dei privilegi rimangono comunque determinati da IAM, autorizzazioni Kubernetes, configurazioni di rete e validazioni del backend: l’agente dispone di una modalità aggiuntiva per utilizzare il control plane, ma non riceve automaticamente privilegi ulteriori.
Lo storage utilizza Amazon S3 per modelli e altri asset prevalentemente in lettura tramite Mountpoint for Amazon S3 CSI Driver, mentre Amazon FSx for Lustre può essere impiegato quando training data e checkpoint richiedono un’elevata velocità di lettura e scrittura. Il download dei modelli da Hugging Face viene eseguito attraverso job Kubernetes CPU-only, evitando di tenere occupate GPU durante il trasferimento dei file. I dati vengono prima preparati sullo storage NVMe dell’istanza e successivamente copiati sul mount dell’object storage. Per l’osservabilità, la piattaforma mostra salute dei nodi, GPU disponibili, pod, servizi, deployment, InferenceEndpointConfig e HyperPodPyTorchJob, mentre HyperPod può inviare metriche ad Amazon Managed Service for Prometheus e renderle disponibili attraverso Amazon Managed Grafana. Le risorse rimangono comunque sempre verificabili anche all’esterno di InstantStart attraverso AWS CLI e kubectl.
L’installazione parte da un template AWS CloudFormation che crea l’ambiente di gestione, un bucket S3 condiviso e i ruoli IAM necessari. Il container espone l’interfaccia web sulla porta 3099, raggiungibile tramite una sessione di port forwarding di AWS Systems Manager. Per l’utilizzo dell’agente è necessario Kiro CLI autenticato, mentre MCP server e skill sono già inclusi nello stesso container e non richiedono un toolchain locale aggiuntivo. Prima del provisioning devono essere verificati anche i limiti di capacità: per i tipi di istanza previsti può essere necessario aumentare le quote SageMaker HyperPod relative al Cluster Usage e, per gli acceleratori di fascia alta, predisporre in anticipo un Flexible Training Plan. Va inoltre considerato che l’elastic training non è attualmente compatibile con Spot Instances, managed tiered checkpointing e checkpointless training, quindi le combinazioni di funzionalità devono essere verificate prima della configurazione del cluster.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)