The Pulse
AWS pubblica architetture di riferimento per l’uso in produzione di NVIDIA Cosmos 3
AWS ha pubblicato architetture di riferimento per eseguire NVIDIA Cosmos 3 nelle attività di selezione dei dati, fine-tuning, inferenza nel cloud e distribuzione sui dispositivi edge. I progetti combinano Amazon S3, SageMaker HyperPod, EKS,
AI.info Team · Scritto con l’IA ·
«Cosmos 3 offre tutte e tre le capacità con un unico modello e una sola chiamata di inferenza.»
Abhishek Srivastav, Ali Shahrokni e Brett Hamilton, AWS Physical AI Blog
Quattro fasi dai dati dei sensori al robot
Il 28 settembre AWS ha pubblicato architetture di riferimento per l’uso in produzione di NVIDIA Cosmos 3, illustrando come i team possano portare i dati del mondo fisico dall’archiviazione all’adattamento e alla distribuzione del modello. La pipeline proposta usa Amazon S3 per i flussi video, LiDAR e delle telecamere in ingresso; AWS Batch per eseguire Cosmos Curator e filtrare e valutare la qualità dei dati; e Amazon EKS con Milvus e Cosmos-embed NIM per cercare i filmati pertinenti.
Per adattare il modello, AWS indica SageMaker HyperPod, dove i team possono effettuare il fine-tuning di Cosmos 3 per i propri ambienti e per i compiti dei robot. L’articolo descrive l’adattamento degli output relativi alle azioni alla configurazione delle articolazioni, alla pinza e alle traiettorie dell’organo terminale di un robot, seguito dall’uso della capacità del modello di prevedere la dinamica futura per effettuare verifiche a ciclo chiuso prima della distribuzione su sistemi fisici.
L’architettura si estende ai dispositivi oltre che ai servizi cloud. Secondo AWS, la variante Cosmos 3 Edge da 4 miliardi di parametri può essere eseguita su hardware NVIDIA Jetson tramite AWS IoT Greengrass, con aggiornamenti del modello da remoto e dati dei sensori inviati a S3 per un successivo addestramento. Il progetto collega questi passaggi in un ciclo, anziché considerare l’inferenza il punto finale della pipeline.
Una famiglia di modelli, tre dimensioni
Cosmos 3 riunisce il ragionamento sulle scene, la generazione di mondi e la previsione delle azioni in un’unica architettura di modello. Secondo AWS, la precedente configurazione di Cosmos utilizzava modelli Predict, Transfer e Reason separati, ciascuno con una propria chiamata di inferenza e una propria infrastruttura di erogazione. Il design Mixture-of-Transformers di Cosmos 3 abbina invece un modulo di ragionamento a un generatore che produce video e output relativi alle azioni sulla base di quel ragionamento.
AWS elenca tre varianti: Super, da 64 miliardi di parametri, per simulazioni più fedeli e generazione offline; Nano, da 16 miliardi, per l’inferenza in produzione; ed Edge, da 4 miliardi, per l’uso sui dispositivi e i cicli di controllo a bassa latenza. L’articolo le presenta come opzioni operative diverse, non come checkpoint intercambiabili: le versioni più grandi sono destinate ai carichi di lavoro su scala cloud, mentre Edge è pensata per i robot che richiedono inferenza locale.
L’architettura promette di evitare che le informazioni spaziali e relative ai compiti vadano perse quando un sistema passa da un modello separato all’altro. Nella descrizione di AWS, un solo passaggio forward può produrre ragionamento, video, audio e traiettorie delle azioni, inclusi angoli delle articolazioni, comandi per la pinza e traiettorie a sei gradi di libertà.
Controllo con EKS o endpoint gestiti di SageMaker
AWS presenta due modalità per erogare il modello nel cloud. I team che hanno bisogno di controllare la pianificazione, il raggruppamento delle richieste e l’instradamento in Kubernetes possono distribuire su EKS i microservizi Cosmos NIM eseguiti su GPU; l’esempio usa Karpenter per predisporre nodi GPU e le metriche di CloudWatch e Prometheus per monitorare l’utilizzo, la lunghezza delle code e la latenza.
SageMaker JumpStart è l’alternativa gestita. Secondo AWS, ad agosto 2026 tutte e tre le varianti di Cosmos 3 erano disponibili in JumpStart, con endpoint in tempo reale per le richieste interattive ed endpoint asincroni per le attività di generazione di mondi più lunghe. I checkpoint prodotti tramite HyperPod possono anche essere registrati in SageMaker Model Registry ed erogati attraverso gli endpoint gestiti.
La differenza è operativa: EKS offre un maggiore controllo sull’infrastruttura di erogazione, mentre JumpStart riduce l’infrastruttura che i team devono gestire. Nessuna delle due modalità elimina la necessità di scegliere una capacità GPU adatta al modello e al carico di lavoro specifici.
Le indicazioni sulle GPU richiedono verifiche con benchmark
AWS raccomanda istanze g7e.2xlarge o p5.4xlarge per l’inferenza di Nano su una sola GPU, associandole rispettivamente a una RTX PRO 6000 96 GB o a una H100 80 GB. Per aumentare la capacità di elaborazione di Nano o per il post-addestramento, le indicazioni puntano a istanze p5.48xlarge con otto GPU H100; per il post-addestramento su più nodi, indicano p5en.48xlarge con otto GPU H200 ed EFAv3.
Per l’inferenza di Super, AWS elenca p5e.48xlarge o p5.48xlarge e consiglia di usare la configurazione di parallelismo raccomandata dal runtime, anziché presupporre una semplice configurazione di parallelismo tensoriale su otto GPU. L’articolo afferma inoltre che i checkpoint completi di Nano e Super sono stati testati in BF16, mentre i profili supportati di Cosmos 3 Generator NIM offrono opzioni FP8 separate.
AWS fornisce raccomandazioni sul dimensionamento, non uno studio comparativo delle prestazioni o dei prezzi. Le sue stesse indicazioni invitano a verificare la suddivisione e la replica rispetto al runtime scelto e a sottoporre le configurazioni a benchmark prima di formulare affermazioni sulle prestazioni. I team hanno quindi punti di partenza concreti per la distribuzione, ma devono comunque effettuare test specifici per il proprio carico di lavoro per determinare i costi e le prestazioni di un sistema in produzione.