Cosmos 3 Edge : la policy DROID pour la robotique qui tourne sur l'edge

Il y a une famille de modèles qui n'est pas faite pour répondre à vos questions, mais pour faire bouger un bras robotique : on l'appelle une policy (politique de contrôle), et la plus intéressante en ce moment est Cosmos3-Edge-Policy-DROID de NVIDIA. Le nom est long, mais le concept est simple : un modèle de 4 milliards de paramètres qui regarde où se trouve un objet, lit une instruction (« mets la banane dans le bol ») et génère une séquence de mouvements à envoyer au robot.

La partie qui nous concerne — et que cet article essaie de mesurer — est une autre : combien de matériel faut-il vraiment pour le faire tourner sur votre propre matériel, en temps réel, sans rien envoyer à l'extérieur.

Ce que c'est, et pourquoi « Edge »

Cosmos3 est la plateforme de modèles mondiaux omni-modaux de NVIDIA : des modèles qui génèrent vidéo, images, audio et — c'est le point ici — commandes d'action, à partir de texte, d'images, de vidéo ou de trajectoires d'action. L'architecture s'appelle Mixture-of-Transformers (MoT) : deux tours de Transformer dans le même modèle, une autorégressive pour les tokens discrets (texte) et une à diffusion pour les modalités continues (image, vidéo, action). C'est la raison pour laquelle un seul réseau peut « parler » et, en même temps, « agir ».

Le checkpoint Cosmos3-Edge-Policy-DROID est la variante post-entraînée pour la robotique du modèle de base Cosmos3-Edge. Entraînée sur la plateforme robotique DROID, l'entrée est une combinaison d'instructions linguistiques et d'observations visuelles, et la sortie est une trajectoire d'action de 8 dimensions (la « signature » de mouvement de ce robot).

Pourquoi « Edge » ? Parce que l'objectif affiché est le déploiement sur des matériels compacts — Jetson, DGX Spark — où le modèle tourne à côté du capteur, et où la latence compte plus que la capacité pure.

Sa taille, et ce qu'il contient

Les chiffres qui comptent, tous issus de la model card officielle :

Caractéristique	Valeur
Paramètres entraîlables	4B
Architecture	Mixture-of-Transformers (MoT)
Précision testée	BF16 (unique)
Jeu de données d'entraînement	1,3 milliard de points de données, 393 datasets (2024–2026)
Espace d'action	8D (plateforme DROID)
Licence	OpenMDW 1.1 (usage commercial et non commercial)
Date de publication	2026-07-20

Les 4B paramètres en BF16 (2 octets par poids) représentent environ 8 Go de poids. C'est un modèle qui tient — en principe — sur une seule GPU grand public ou sur un Jetson avec 16 Go de mémoire. Le point qu'il faut dire clairement : NVIDIA n'a testé que le BF16. Les versions quantifiées (FP4, FP8, FP16) ne sont pas officiellement supportées. Cela change les calculs pour ceux qui ont moins de 16 Go, et on y revient plus bas.

Le modèle est entraîné sur un corpus énorme : 1,3 milliard de points de données agrégés depuis 393 datasets, dont 767 millions d'images, 348 millions de clips vidéo et des données d'action. Pour la partie robotique, le checkpoint s'appuie sur le dataset DROID, un corpus de manipulation « en conditions réelles » : 76 000 trajectoires de démonstration, 350 heures d'interaction, collectées dans 564 scènes, 86 tâches et 52 bâtiments différents. C'est un corpus qui couvre la variété typique des datasets robotiques — objets, éclairage, points de vue — et pour cette raison la policy généralise au-delà de la scène où elle a été testée.

Combien de matériel faut-il : le tableau

Voici le cœur de l'article. La model card publie les latences de bout en bout (E2E) d'un seul chunk d'action sur une gamme de plateformes, de la workstation à 192 Go au Jetson à 16 Go. Le test de référence : un chunk d'action de 16 pas, une image en entrée, num_frames=17, fps=5.

Plateforme	Mémoire	E2E (vLLM)	E2E (PyTorch)
NVIDIA B200 SXM	192 Go	0,99 s	—
NVIDIA H100 SXM	80 Go	1,41 s	1,25 s
NVIDIA RTX PRO 6000 Blackwell	96 Go	1,87 s	1,65 s
NVIDIA DGX Spark	128 Go (unifiée)	7,66 s	6,56 s
NVIDIA Jetson AGX Thor T5000	128 Go	— (voir ci-dessous)	—
NVIDIA Jetson T2000	16 Go	—	—

Les lignes datacenter (B200, H100) sont là pour donner un repère : quand le modèle doit tourner « vite » et que ce n'est pas grave qu'il soit sur votre bureau. Mais les lignes qui comptent pour l'angle local/edge sont les dernières.

Temps réel sur Jetson : le vrai test

Pour un robot, « en temps réel » a une signification précise : il faut produire un chunk d'action avant que la fenêtre de contrôle n'expire. La model card mesure un chunk de 32 pas à un rythme de contrôle de 5 Hz, où le budget est de 6,4 secondes par chunk. Le chiffre à regarder est le RTF (Real-Time Factor) : temps disponible divisé par la latence mesurée. S'il est ≥ 1, le modèle fait en temps.

Jetson	Mémoire	E2E (vLLM)	RTF à 5 Hz	Temps réel ?
AGX Thor T5000	128 Go	2,59 s	2,47	Oui
AGX Thor T4000	64 Go	3,24 s	1,98	Oui
Thor T3000	32 Go	4,05 s	1,58	Oui
Thor T2000	16 Go	7,63 s	0,84	Non

Lisez le tableau ainsi : le T5000 a 2,47 fois de marge par rapport au budget — il tourne largement, avec de la place pour les imprévus. Le T2000 (16 Go) descend à 0,84, sous le seuil : le modèle est là, les poids tiennent, mais le contrôle à 5 Hz n'y parvient pas. C'est la frontière exacte entre « tourne en local » et « tourne mais pas en temps réel ».

Si vous n'avez pas de Jetson, le repère le plus proche d'un setup de bureau est le DGX Spark (128 Go de mémoire unifiée) : 6,56 s avec PyTorch, 7,66 s avec vLLM. Ce n'est pas « temps réel » pour un robot (trop lent pour 5 Hz), mais c'est un point de repère concret pour qui veut faire tourner la policy sur une workstation compacte sans GPU datacenter.

Comment le faire tourner

Le setup officiel est un serveur de policy qui transmet les actions à un client qui guide le robot (physique ou simulé). Le flux est : clone de cosmos-framework, image Docker, conteneur avec runtime NVIDIA, et à l'intérieur on lance le serveur de policy sur le checkpoint :

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

Puis, dans le conteneur, le serveur de policy :

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

Pour l'essayer sans robot, NVIDIA pointe vers RoboLab, un benchmark de simulation pour les policy « task-generalist » : le client charge une tâche (par exemple BananaInBowlTask) et affiche la simulation en temps réel. C'est le moyen le plus honnête de voir la policy à l'œuvre sans investir dans du matériel : un --num-envs 10 --headless lance dix environnements en parallèle.

Deux choses à savoir avant de commencer. D'abord, le runtime est PyTorch et le support GPU déclaré est Ampere, Blackwell et Hopper — pas d'Apple Silicon, pas d'AMD dans la liste officielle. Ensuite, il faut un token Hugging Face pour télécharger le checkpoint, et le modèle est sous licence OpenMDW 1.1, qui autorise l'usage commercial comme non commercial : ce n'est pas un poids « open weight » au sens strict, mais il est librement téléchargeable et réutilisable.

Et les limites ?

Honnêtes, parce que la model card elle-même les dit clairement, et parce qu'un article qui les masque ne vous sert à rien :

• Pas de physique réelle. Le modèle n'a pas de simulateur physique interne : géométrie 3D, permanence des objets, dynamique de contact et lois de la physique ne sont qu'approximées. Il peut sembler qu'un objet disparaisse ou se déforme, qu'une collision soit irréaliste. Pour le contrôle robotique réel, il faut une validation externe, des contraintes supplémentaires et des garde-fous système.
• BF16 uniquement. Si votre cible est une GPU avec 8 Go, la version quantifiée qui vous ferait tenir dans 8 Go n'est pas officiellement supportée. La frontière réelle pour le bureau est plus proche de 16 Go que de 8.
• Uniquement la plateforme DROID. L'espace d'action de 8 dimensions est spécifique à ce robot. Le modèle n'est pas un « cerveau robotique universel » qui fonctionne avec n'importe quel effecteur — c'est une policy pour DROID, et un autre robot appelle un autre checkpoint ou un entraînement.
• Latence qui s'effondre en réduisant la taille. Des 128 Go (RTF 2,47) aux 16 Go (RTF 0,84), la pente n'est pas linéaire : il y a un point où on cesse de faire en temps. Si votre contrôle exige plus de 5 Hz, le T2000 n'est pas votre cible.
• Hors distribution. La qualité se dégrade dans les environnements rarement vus en entraînement et dans les cas limites critiques.

La synthèse : c'est un modèle qui tourne en local quand « local » signifie Jetson de 64–128 Go ou workstation avec mémoire unifiée, et pas quand cela signifie « la GPU grand public de 8 Go sur mon PC ». Pour ça, il faut la quantisation qui, pour l'instant, manque.

Ce que ça a à voir avec l'IA locale

Le point n'est pas « j'ai un robot à la maison ». Le point est le schéma : un modèle assez grand pour être utile, mais assez compact pour tourner sur le matériel à côté du capteur, sans que les données partent dans le cloud. Cosmos3-Edge-Policy-DROID est le cas d'usage le plus extrême de ce schéma — parce que la robotique ne tolère ni la latence ni la perte de connexion — mais c'est le même schéma qu'un RAG qui tourne sur un Mac, d'un TTS sur un laptop, d'un embedding sur une GPU grand public.

La frontière « combien de matériel suffit » se déplace d'un modèle à l'autre, et le tableau ci-dessus est exactement ce qu'il vous faut pour la déplacer aussi pour vous : regardez le RTF sur votre matériel, comparez-le à votre budget de contrôle, et décidez. Si vous voulez comprendre comment lire ces chiffres pour les modèles qui tournent déjà en local, la comparaison des moteurs d'inférence (Ollama vs llama.cpp) et le rôle de vLLM sont les bons points de départ ; et si la mémoire vous manque, la quantisation est le premier outil qui vous fait tenir dans moins de Go.

Sources

• Model card officielle de NVIDIA — Cosmos3-Edge-Policy-DROID — architecture, dataset, licence et toutes les latences E2E/RTF citées dans les tableaux.
• DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — 76 000 trajectoires, 350 heures, 564 scènes, 86 tâches, 52 bâtiments.
• Dataset DROID — site officiel — chiffres de collecte et couverture du corpus.
• NVIDIA Cosmos Framework — setup du serveur de policy et du client RoboLab.

En résumé

Cosmos3-Edge-Policy-DROID est une policy robotique de 4B paramètres, Mixture-of-Transformers, entraînée sur 1,3 milliard de points de données et sur le dataset DROID (76 000 trajectoires, 350 heures), qui tourne en BF16 sur environ 8 Go de poids. Sur Jetson AGX Thor T5000/T4000/T3000, il fait en temps réel à 5 Hz (RTF 1,58–2,47) ; sur le T2000 de 16 Go, non (RTF 0,84). Sur un DGX Spark avec mémoire unifiée, 6,56 s de latence avec PyTorch. C'est le repère le plus concret qui existe aujourd'hui pour la frontière entre « IA locale » et « IA locale en temps réel » — avec la limite honnête que la quantisation n'est pas encore supportée, et que le modèle est lié à la plateforme DROID.

Article généré par IA