Cosmos 3 de NVIDIA : modèles ouverts de simulation IA
Découvrez les quatre modèles Cosmos 3 de NVIDIA, leurs usages en robotique et conduite autonome, leurs contraintes techniques et les étapes pour les adapter.
Cosmos 3 de NVIDIA : quatre modèles pour simuler des mondes interactifs
Les modèles d'IA qui génèrent des images ou des vidéos à partir d'une consigne sont devenus familiers. Mais quand on veut entraîner un robot ou tester une politique de conduite, il ne suffit pas d'obtenir une vidéo « plausible » : il faut aussi que les observations évoluent de façon crédible avec les actions, les capteurs et l'état de l'environnement.
C'est précisément ce que vise la famille Cosmos 3 de NVIDIA. L'entreprise met à disposition quatre modèles ouverts, orientés vers la génération de scènes de conduite et de robotique. L'objectif : produire des vues caméra et LiDAR synchronisées, transformer des commandes de simulateur en images, ou encore prédire les conséquences visuelles des mouvements d'un robot.
Ces modèles ne remplacent pas un simulateur physique, et ils ne suffisent pas à eux seuls à garantir un entraînement fiable. Là où ils sont utiles, c'est pour relier des actions à des observations, avec des contrôles adaptés à des scénarios précis. Voici comment les quatre variantes fonctionnent, ce que ça change pour les équipes produit et recherche, et les précautions à prendre avant de les intégrer.
Ce que Cosmos 3 apporte à la simulation interactive
Cosmos 3 regroupe quatre variantes post-entraînées de Cosmos 3 Nano. Chaque modèle dispose de 16 milliards de paramètres, mais la différence ne vient pas seulement de la taille : elle vient surtout de la place de chaque modèle dans la chaîne de simulation.
Ces modèles appartiennent à la catégorie des modèles du monde. Ils apprennent à produire des observations visuelles en tenant compte du contexte, de l'historique et des contrôles. On n'est pas seulement sur « une scène générée à partir d'un texte » : il s'agit de faire évoluer la scène après une action (changement de direction, mouvement de caméra, manipulation d'un bras robotique, etc.).
Quatre modèles, quatre fonctions distinctes
- Cosmos3-Nano-Transfer-Auto génère des données de conduite hors ligne, avec plusieurs vues caméra et, selon la configuration, des données LiDAR synchronisées.
- Cosmos3-Nano-Sim-Auto produit des séquences successives de vues caméra et de LiDAR à partir de contrôles de conduite mis à jour.
- Cosmos3-Nano-Sim-Transfer transforme des contrôles spatiaux d'un simulateur et une consigne textuelle en images RGB.
- Cosmos3-Nano-Sim-Bimanual prédit les observations suivantes à partir des actions d'un robot à deux bras, ou de mouvements de caméra.
Cette séparation sert à répondre à des besoins différents. Transfer-Auto est utile pour enrichir des jeux de données. Sim-Auto vise une génération en continu pour des essais interactifs. Sim-Transfer garde la physique dans le simulateur, et Sim-Bimanual s'occupe surtout des actions de manipulation et des changements de point de vue.
Pourquoi la génération doit rester reliée aux actions
Dans une simulation classique, le moteur calcule les états physiques, puis un système de rendu produit l'image. Une autre approche consiste à générer directement une observation visuelle à partir d'une action et de l'historique récent.
Le gain potentiel, c'est de varier plus facilement les scènes et les apparences, sans devoir modéliser à la main chaque détail visuel. Mais l'inconvénient est simple : une image réaliste ne garantit pas une observation fidèle au monde. Si une voiture change de voie alors que la géométrie ou les capteurs ne suivent pas, la sortie peut devenir trompeuse pour l'évaluation d'une politique de conduite. Et si un robot « a l'air » de saisir un objet alors que la position des pinces est incohérente, on n'obtient pas un bon signal d'entraînement.
Cosmos 3 essaie d'éviter ce décalage en s'appuyant sur des contrôles structurés, des données synchronisées et un historique temporel. Cela reste une approche à valider : il faut mesurer les erreurs et comparer les sorties aux états de référence.
Ce que signifie « ouvert » dans ce contexte
NVIDIA présente ces modèles comme des modèles à poids ouverts. Les quatre checkpoints sont publiés sous la licence OpenMDW 1.1, qui autorise des usages commerciaux et non commerciaux, sous réserve de respecter les termes.
Autrement dit : avant de les intégrer en production, il faut vraiment regarder la licence. « Ouvert » ne veut pas dire « sans restrictions ».
Les recettes de post-entraînement sont aussi importantes : elles donnent un point de départ pour adapter un modèle à vos données, comparer des approches et, éventuellement, poursuivre l'entraînement. Elles ne remplacent pas pour autant des données de qualité, des tests de robustesse et des validations adaptées à votre usage opérationnel.
Quels cas d'usage couvrent les quatre modèles
Cosmos 3 vise surtout deux domaines où les systèmes doivent réagir à des observations successives : la conduite autonome et la robotique. Dans les deux cas, le défi est de produire des scénarios variés sans perdre le lien exploitable entre action, état du monde et signaux capteurs.
Conduite autonome : varier les scènes et les capteurs
Transfer-Auto génère des séquences de conduite hors ligne sur un maximum de onze vues caméra, y compris des vues fisheye. Il peut aussi produire conjointement des images RGB et des observations LiDAR. Les contrôles de type World Scenario Map (WSM) décrivent la structure de la scène et les déplacements du trafic. Des consignes textuelles peuvent guider certains aspects visuels (éclairage, météo, moment de la journée).
Concrètement, ça aide à couvrir des variations difficiles à obtenir uniquement avec des trajets enregistrés : conditions météo, luminosité, configuration de la circulation, état des feux. On peut aussi utiliser des images initiales comme point d'ancrage visuel. Pour la génération LiDAR, les contrôles de carte HD doivent correspondre aux contrôles caméra.
Le bon point : construire des données synthétiques cohérentes entre plusieurs capteurs. Le point à surveiller : cette cohérence elle-même. Avant d'utiliser les données pour entraîner ou comparer une politique de conduite, il faut vérifier les désalignements temporels, les artefacts et la manière dont les situations rares sont représentées. Une séquence générée n'est pas, à elle seule, une preuve que le système gérera correctement la situation réelle correspondante.
Sim-Auto reprend cette logique avec une approche causale et optimisée pour le flux. Il génère de petits segments vidéo et LiDAR à partir de l'historique et de contrôles de conduite mis à jour. Pour une interaction en boucle fermée, il faut en plus un environnement d'exécution de simulation et un moteur WSM capable de modifier ces contrôles selon les actions du véhicule.
Robotique : prédire des observations après une action
Sim-Bimanual cible les manipulations avec deux bras, notamment pour les configurations YAM et AgiBot. Le modèle reçoit une image et une séquence de commandes, puis prédit les observations suivantes. Les commandes peuvent venir d'une politique ou d'une personne via des joysticks. Une même séquence peut mélanger une manipulation et un changement de point de vue.
L'interface d'action est un point critique de l'intégration. Dans l'exemple décrit dans les éléments publiés, on utilise 59 valeurs de contrôle, complétées à 64 pendant l'entraînement. Le document précise les repères de coordonnées, les rotations, le calibrage des pinces, les masques de validité et les domaines des commandes. Si vos conventions ne sont pas les mêmes, le modèle peut interpréter une valeur comme un mouvement différent de celui attendu.
La synchronisation compte aussi. Pour une séquence de T transitions, il faut T+1 observations. Les données brutes d'entraînement doivent être transformées dans la représentation d'action attendue ; pour l'inférence, les actions fournies sont déjà normalisées. Ce sont des détails d'implémentation, mais c'est précisément ce genre de détail qui fait la différence entre « ça marche sur un exemple » et « ça marche dans votre pipeline ».
Sim-Transfer : garder la physique dans le simulateur
Sim-Transfer répartit clairement les responsabilités : le simulateur calcule les mouvements, les contacts et l'état physique. Ensuite, le modèle convertit certains contrôles spatiaux en observations RGB que la politique peut utiliser.
Les contrôles peuvent inclure la profondeur relative à la caméra, la segmentation des objets, les régions, les contours, ou encore une représentation floutée de l'apparence. Le texte peut préciser le rendu visuel, tandis que la physique et l'état de référence restent gérés par le simulateur.
Cette architecture intéresse surtout une équipe qui dispose déjà d'un moteur physique et veut augmenter la variété des observations visuelles. L'intérêt, c'est d'éviter de demander au générateur d'inventer à la fois la dynamique et l'apparence. En échange, la qualité finale dépend de la compatibilité entre contrôles, domaine d'entraînement et environnement cible. Si le modèle a été post-entraîné sur des données trop éloignées du robot ou du décor visé, les sorties peuvent rester « jolies » tout en étant peu utiles pour la politique.
Conclusion : choisir selon le besoin de simulation
Cosmos 3 propose une boîte à outils pour relier actions et observations dans des scénarios de conduite et de robotique. Les quatre modèles ne font pas tous la même chose : enrichissement de données, génération en flux, rendu piloté par un simulateur et prédiction d'actions robotiques.
La bonne démarche, c'est de partir de votre système existant, de vos capteurs et de la tâche à évaluer. Testez ensuite sur des épisodes tenus à l'écart de l'entraînement et mesurez l'effet sur la politique, pas seulement la qualité visuelle des séquences. C'est à ce prix-là que des modèles du monde « ouverts » deviennent un outil d'ingénierie, plutôt qu'une démonstration impressionnante.
Comment intégrer et adapter Cosmos 3 à un projet
Le bon checkpoint dépend d'abord de votre besoin, pas de l'effet « nouveauté ». Une équipe qui veut produire un corpus de conduite hors ligne n'a pas les mêmes contraintes qu'une équipe qui teste en temps réel, ni qu'un laboratoire entraînant une manipulation bimanuale.
Choisir le modèle à partir du résultat attendu
Pour éviter de confondre génération de données et simulation interactive, voici une règle simple :
Cette règle ne remplace pas un test sur vos données : elle réduit surtout le risque de partir d'un modèle dont le mode de génération ou l'interface ne colle pas à votre système.
Comprendre le fonctionnement en flux
Pour la génération interactive, Cosmos 3 utilise une architecture Mixture-of-Transformers. Elle relie un réseau pour le texte et un réseau pour la génération visuelle via des mécanismes d'attention. Le modèle prédit un segment court à partir de la consigne, des contrôles disponibles et de l'historique généré.
Les vidéos sont représentées sous forme de latents compressés. Après l'image initiale, chaque pas temporel latent correspond à quatre images RGB. Transfer prédit un pas par segment ; dans la configuration optimisée décrite pour Sim-Bimanual, deux pas sont prédits. Des segments plus courts permettent de prendre en compte plus souvent les nouveaux contrôles, mais augmentent le rythme de génération.
L'attention causale donne accès à l'historique et aux contrôles disponibles, sans laisser le modèle « regarder » les observations futures qu'il doit prédire. Un cache de clés et de valeurs aide à limiter le recalcul pour les étapes suivantes. En pratique, la logique est la suivante : contrôles et historique, génération d'un segment, décodage des images, puis mise à jour de l'historique.
Adapter le modèle sans confondre exécution et qualité
Les recettes d'entraînement publiées décrivent quatre étapes : adaptation bidirectionnelle sur des séquences complètes, apprentissage avec prédiction de segments à partir de l'historique, distillation en quelques étapes de débruitage, puis entraînement sur l'historique généré par le modèle lui-même.
Cette dernière étape vise un problème concret : une petite erreur sur une image peut devenir le contexte des prédictions suivantes, puis s'amplifier au fil du temps. En exposant le modèle à son propre historique, l'entraînement cherche à mieux préparer les séquences aux écarts qui apparaîtront en conditions réelles. Cela ne supprime pas les dérives : il faut toujours les mesurer sur des épisodes qui n'ont pas servi à l'entraînement.
Avant un entraînement long, vérifiez l'environnement, validez un échantillon de données et testez la reprise à partir d'un checkpoint. Si vous devez reprendre l'entraînement, conservez les checkpoints complets : les poids exportés pour l'inférence ne contiennent pas l'état de l'optimiseur ni les éléments nécessaires à une reprise totale.
Pour Sim-Bimanual, l'environnement publié s'appuie sur Linux, un GPU NVIDIA, Docker et NVIDIA Container Toolkit. La configuration vLLM-Omni décrite a été testée sur un seul GB200, mais ce n'est pas une exigence minimale de mémoire. Vous devrez donc valider les besoins matériels sur votre configuration avant d'estimer les coûts.
Évaluer la valeur métier et les risques
Pour une entreprise, la valeur potentielle se mesure à deux choses : élargir les scénarios testés et réduire certains coûts de collecte. Le tout doit être comparé aux coûts d'adaptation, de calcul, de validation et de maintenance des données synthétiques.
En Europe, l'usage de données réelles implique aussi de vérifier les droits d'utilisation, la présence éventuelle de données personnelles et les obligations applicables, notamment au regard du RGPD.
Un protocole d'évaluation utile devrait au minimum regarder :
Le test décisif ne consiste pas à vérifier que le modèle « fait une belle vidéo ». La question est plutôt de savoir si ça améliore une tâche clairement définie, sans cacher des angles morts importants. Pour une flotte, un labo ou un industriel de la robotique, cette nuance conditionne le retour sur investissement et le niveau de risque acceptable.