Cosmos 3 Edge: la policy DROID per la robotica che gira sull'edge

C'è una famiglia di modelli che non è fatta per rispondere alle tue domande, ma per far muovere un braccio robotico: si chiama policy (politica di controllo), e la più interessante in questo momento è Cosmos3-Edge-Policy-DROID di NVIDIA. Il nome è lungo, ma il concetto è semplice: un modello da 4 miliardi di parametri che guarda dove si trova un oggetto, legge un'istruzione («metti la banana nella ciotola») e genera una sequenza di movimenti da spedire al robot.

La parte che ci riguarda da vicino — e che questo articolo prova a misurare — è un'altra: quanto hardware ti serve davvero per farlo girare sul tuo hardware, in tempo reale, senza mandare via nulla.

Cos'è, e perché «Edge»

Cosmos3 è la piattaforma di modelli mondo omnimodali di NVIDIA: modelli che generano video, immagini, audio e — qui il punto — comandi d'azione, a partire da testo, immagini, video o traiettorie di azione. L'architettura si chiama Mixture-of-Transformers (MoT): due torri Transformer dentro lo stesso modello, una autoregressiva per i token discreti (testo) e una a diffusione per le modalità continue (immagine, video, azione). È il motivo per cui un'unica rete può «parlare» e allo stesso tempo «agire».

Il checkpoint Cosmos3-Edge-Policy-DROID è la variante post-addestrata per la robotica del modello base Cosmos3-Edge. Addestrata sulla piattaforma robotica DROID, l'input è una combinazione di istruzioni linguistiche e osservazioni visive, e l'output è una traiettoria d'azione da 8 dimensioni (la «firma» di movimento di quel robot).

Perché «Edge»? Perché l'obiettivo dichiarato è il deployment su hardware compatti — Jetson, DGX Spark — dove il modello gira accanto al sensore, e la latenza conta più della pura capacità.

Quanto è grande, e cosa c'è dentro

I numeri che contano, tutti dalla model card ufficiale:

Caratteristica	Valore
Parametri addestrabili	4B
Architettura	Mixture-of-Transformers (MoT)
Precisione testata	BF16 (unica)
Dataset di addestramento	1,3 miliardi di punti dati, 393 dataset (2024–2026)
Spazio d'azione	8D (piattaforma DROID)
Licenza	OpenMDW 1.1 (uso commerciale e non commerciale)
Data di rilascio	2026-07-20

I 4B parametri a BF16 (2 byte per peso) significano circa 8 GB di pesi. È un modello che sta — in linea di principio — su una singola GPU consumer o su un Jetson con 16 GB di memoria. Il punto che però va detto chiaro: NVIDIA ha testato solo BF16. Le versioni quantizzate (FP4, FP8, FP16) non sono supportate ufficialmente. Questo cambia i conti per chi ha meno di 16 GB, e torniamo ci sotto.

Il modello è addestrato su un dataset mostruoso: 1,3 miliardi di punti dati aggregati da 393 dataset, tra cui 767 milioni di immagini, 348 milioni di clip video e dati d'azione. Per la parte robotica specifica, il checkpoint si appoggia al dataset DROID, un corpus di manipolazione «in the wild»: 76.000 traiettorie di dimostrazione, 350 ore di interazione, raccolte in 564 scene, 86 task e 52 edifici diversi. È un corpus che copre l'impazienza tipica dei dataset di robotica — oggetti, illuminazione, punti di vista — e per questo la policy generalizza oltre la scena in cui è stata provata.

Quanto hardware ti serve: la tabella

Qui c'è il cuore dell'articolo. La model card pubblica le latenze end-to-end (E2E) di un singolo chunk d'azione su una gamma di piattaforme, dalla workstation da 192 GB al Jetson a 16 GB. Il test di riferimento: un chunk d'azione da 16 step, un'immagine d'input, num_frames=17, fps=5.

Piattaforma	Memoria	E2E (vLLM)	E2E (PyTorch)
NVIDIA B200 SXM	192 GB	0,99 s	—
NVIDIA H100 SXM	80 GB	1,41 s	1,25 s
NVIDIA RTX PRO 6000 Blackwell	96 GB	1,87 s	1,65 s
NVIDIA DGX Spark	128 GB (unificata)	7,66 s	6,56 s
NVIDIA Jetson AGX Thor T5000	128 GB	— (vedi sotto)	—
NVIDIA Jetson T2000	16 GB	—	—

Le righe datacenter (B200, H100) sono lì a dare un riferimento: quando il modello deve girare «veloce» e non importa che sia sul tuo desktop. Ma le righe che contano per l'angolo locale/edge sono le ultime.

Tempo reale sul Jetson: il vero test

Per un robot, «in tempo reale» ha un significato preciso: devi produrre un chunk d'azione prima che scada la finestra di controllo. La model card misura un chunk da 32 step a un ritmo di controllo da 5 Hz, dove il budget è di 6,4 secondi per chunk. Il numero da guardare è l'RTF (Real-Time Factor): tempo disponibile diviso latenza misurata. Se è ≥ 1, il modello fa in tempo.

Jetson	Memoria	E2E (vLLM)	RTF a 5 Hz	Tempo reale?
AGX Thor T5000	128 GB	2,59 s	2,47	Sì
AGX Thor T4000	64 GB	3,24 s	1,98	Sì
Thor T3000	32 GB	4,05 s	1,58	Sì
Thor T2000	16 GB	7,63 s	0,84	No

Leggi la tabella così: il T5000 ha 2,47 volte di margine rispetto al budget — gira largo, con spazio per imprevisti. Il T2000 (16 GB) scende a 0,84, sotto la soglia: il modello c'è, i pesi ci stanno, ma il controllo a 5 Hz non lo fa in tempo. È il confine esatto tra «gira in locale» e «gira ma non in tempo reale».

Se non hai un Jetson, il riferimento più vicino a un setup desktop è il DGX Spark (128 GB di memoria unificata): 6,56 s con PyTorch, 7,66 s con vLLM. Non è «tempo reale» da robot (troppo lento per 5 Hz), ma è un punto di riferimento concreto per chi vuole far girare la policy su una workstation compatta senza GPU datacenter.

Come si fa a farlo girare

Il setup ufficiale è un server di policy che streamma le azioni a un client che guida il robot (fisico o simulato). Il flusso è: clone di cosmos-framework, immagine Docker, container con runtime NVIDIA, e dentro avvia il server di policy sul checkpoint:

git clone https://github.com/nvidia/cosmos-framework.git
cd cosmos-framework
# build dell'immagine Docker (INSTALL_APEX=0)
docker build --build-arg INSTALL_APEX=0 -t cosmos-framework:latest .

Poi, dentro il container, il server di policy:

python -m cosmos_framework.scripts.action_policy_server_robolab \
  --checkpoint_path nvidia/Cosmos3-Edge-Policy-DROID \
  --port 8000 \
  --format-prompt-as-json True

Per provarlo senza robot, NVIDIA punta a RoboLab, un benchmark di simulazione per policy «task-generalist»: il client carica un task (ad esempio BananaInBowlTask) e mostra la simulazione in tempo reale. È il modo più onesto per vedere la policy al lavoro senza spendere in hardware: un --num-envs 10 --headless fa girare dieci ambienti in parallelo.

Due cose da sapere prima di iniziare. Prima, il runtime è PyTorch e il supporto GPU dichiarato è Ampere, Blackwell e Hopper — niente Apple Silicon, niente AMD nella lista ufficiale. Seconda, serve un token Hugging Face per scaricare il checkpoint, e il modello è sotto licenza OpenMDW 1.1, che consente sia l'uso commerciale che quello non commerciale: non è un peso «open weight» in senso stretto, ma è liberamente scaricabile e riutilizzabile.

E i limiti?

Onesti, perché la model card stessa li dice chiaramente, e perché un articolo che li nasconde non ti serve:

• Niente fisica vera. Il modello non ha un simulatore fisico interno: geometria 3D, permanenza degli oggetti, dinamiche di contatto e leggi della fisica sono solo approssimate. Può apparire che un oggetto sparisca o si deformi, che una collisione sia innaturale. Per il controllo robotico reale serve validazione esterna, vincoli aggiuntivi e guardrail di sistema.
• Solo BF16. Se il tuo target è una GPU con 8 GB, il peso quantizzato che ti farebbe stare in 8 GB non è supportato ufficialmente. Il confine reale per il desktop è più vicino ai 16 GB che a 8.
• Solo piattaforma DROID. Lo spazio d'azione da 8 dimensioni è specifico di quel robot. Il modello non è un «cervello robotico universale» che funziona con qualsiasi effettore — è una policy per DROID, e per un altro robot serve un altro checkpoint o un addestramento.
• Latenza che scende bruscamente col ridimensionamento. Dai 128 GB (RTF 2,47) ai 16 GB (RTF 0,84) non c'è una pendenza lineare: c'è un punto in cui smetti di fare in tempo. Se il tuo controllo richiede più di 5 Hz, il T2000 non è il tuo target.
• Out-of-distribution. La qualità degrada in ambienti raramente visti in addestramento e nei casi limite a elevata criticità di sicurezza.

La sintesi: è un modello che gira in locale quando «locale» significa Jetson da 64–128 GB o workstation con memoria unificata, e non quando significa «la GPU consumer da 8 GB sul mio PC». Per quello, serve la quantizzazione che al momento manca.

Cosa c'entra con l'IA locale

Il punto non è «ho un robot a casa». Il punto è il pattern: un modello grande abbastanza da essere utile, ma abbastanza compatto da girare sull'hardware che hai accanto al sensore, senza che i dati vadano in cloud. Cosmos3-Edge-Policy-DROID è il caso d'uso più estremo di quel pattern — perché la robotica non tollera latenza né perdita di connettività — ma è lo stesso pattern di un RAG che gira su un Mac, di un TTS su un laptop, di un embedding su una GPU consumer.

Il confine «quanto hardware basta» si sposta di modello in modello, e la tabella sopra è esattamente quello che ti serve per spostarlo anche per te: guarda il RTF sul tuo hardware, confrontalo col tuo budget di controllo, e decidi. Se vuoi capire come si leggono questi numeri per i modelli che già girano in locale, il confronto tra i motori di inference (Ollama vs llama.cpp) e il ruolo di vLLM sono i punti di partenza giusti; e se la memoria ti manca, la quantizzazione è il primo strumento che ti fa stare in meno GB.

Fonti

• Model card ufficiale di NVIDIA — Cosmos3-Edge-Policy-DROID — architettura, dataset, licenza e tutte le latenze E2E/RTF riportate nelle tabelle.
• DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — 76.000 traiettorie, 350 ore, 564 scene, 86 task, 52 edifici.
• Dataset DROID — sito ufficiale — numeri di raccolta e copertura del corpus.
• NVIDIA Cosmos Framework — setup del server di policy e del client RoboLab.

In sintesi

Cosmos3-Edge-Policy-DROID è una policy robotica da 4B parametri, Mixture-of-Transformers, addestrata su 1,3 miliardi di punti dati e sul dataset DROID (76.000 traiettorie, 350 ore), che gira in BF16 su circa 8 GB di pesi. Su Jetson AGX Thor T5000/T4000/T3000 fa in tempo reale a 5 Hz (RTF 1,58–2,47); sul T2000 da 16 GB no (RTF 0,84). Sul DGX Spark con memoria unificata, 6,56 s di latenza con PyTorch. È il riferimento più concreto che oggi esista per il confine tra «IA locale» e «IA locale in tempo reale» — con il limite onesto che la quantizzazione non è ancora supportata, e che il modello è legato alla piattaforma DROID.

Articolo generato con IA