Cosmos3-Nano-Sim-Bimanual : analyse technique, limites et critères de déploiement

Identité et objectif du modèle

Cosmos3-Nano-Sim-Bimanual est une variante post-entraînée et distillée de manière causale du modèle de base Cosmos3-Nano, développée par NVIDIA. Sa fonction spécifique consiste à simuler l’évolution d’un environnement en réponse aux actions d’un robot bimanuel et aux trajectoires de la caméra. Contrairement à un modèle de politique de contrôle qui prédit des actions, ce modèle génère une vidéo à partir d’actions fournies : il sert ainsi de simulateur visuel de dynamique directe.

Le modèle a été publié le 20 octobre 2026 sous licence OpenMDW 1.1. Il est conçu pour évaluer des politiques robotiques, entraîner des systèmes d’apprentissage par renforcement et générer des données synthétiques de démonstration sans téléopération, à condition que les entrées de contrôle soient fournies par un autre modèle ou par un opérateur humain.

La distinction entre simulation visuelle et contrôle détermine le rôle de chaque composant du système. Cosmos3-Nano-Sim-Bimanual reçoit une séquence d’actions déjà définie et produit une représentation visuelle de l’évolution attendue ; le choix de ces actions relève d’un contrôleur, d’une politique robotique ou d’un autre mécanisme externe. Le modèle peut donc montrer comment une séquence se projette dans une scène, mais il ne remplace pas le processus qui choisit le mouvement à exécuter et ne fixe pas lui-même les objectifs du robot.

Le caractère causal de cette variante décrit l’organisation temporelle de la génération : les nouveaux blocs sont conditionnés par l’historique disponible et par les entrées reçues. La distillation et le post-entraînement distinguent cette variante du modèle de base, sans modifier sa fonction de générateur vidéo conditionné. Sa sortie doit être comprise comme une simulation visuelle de dynamique directe, non comme une mesure directe de l’état physique ni comme une garantie que le mouvement représenté sera reproduit par un robot réel.

L’utilité prévue dépend des actions de contrôle fournies par l’utilisateur. Une personne ou un système externe peut préparer ces entrées afin d’évaluer des politiques, d’explorer des séquences ou de produire des démonstrations synthétiques sans téléopérer chaque mouvement pendant la génération. Cela ne signifie pas que le modèle élabore les démonstrations de façon autonome : la séquence d’actions, la scène initiale et l’objectif de l’essai restent des éléments à définir dans l’intégration.

Architecture et spécifications techniques

Le modèle compte 16 milliards de paramètres et repose sur une architecture Transformer de type Mixture-of-Transformers (MoT). Il génère la vidéo par petits blocs de trames latentes, conditionnés par l’historique mis en cache et les nouvelles entrées de contrôle. Cette méthode vise à préserver la continuité de la scène lorsque changent la pose de la caméra, la position des bras ou l’état des pinces du robot.

Les entrées prises en charge comprennent une image initiale (JPG, PNG, JPEG ou WebP), des séquences d’actions du robot au format JSON, des trajectoires de caméra et, en option, un texte décrivant la scène. La sortie est uniquement une vidéo, au format MP4 ou sous forme de trames en flux, en 480p et à une fréquence de lecture de 30 images par seconde. Il faut distinguer cette fréquence de lecture de la vitesse d’inférence, c’est-à-dire du nombre de trames effectivement générées par seconde, qui varie selon le matériel.

La génération par blocs latents organise la production vidéo en segments successifs, plutôt que de traiter toute la séquence comme une seule image. L’historique mis en cache fournit du contexte entre les blocs, tandis que les entrées de contrôle conditionnent le contenu généré. Cette structure vise à préserver la continuité visuelle lorsque la caméra ou la configuration des bras et des pinces change ; elle n’exclut pas les sauts, la dérive ou les incohérences temporelles, qui restent à examiner dans la sortie.

L’image initiale fournit le point de départ visuel, tandis que les actions JSON et les trajectoires de caméra décrivent les changements à représenter au fil du temps. Le texte facultatif peut caractériser la scène, mais ne remplace pas ces entrées de contrôle. Il faut donc préparer chaque modalité avec soin et maintenir la cohérence de leurs références : une vidéo plausible ne prouve pas, à elle seule, que les actions ont été interprétées selon la sémantique physique attendue.

La résolution de 480p et les 30 images par seconde décrivent la sortie en lecture, et non le rythme auquel le système calcule chaque image. Le débit d’inférence indique combien d’images le système peut générer par seconde dans une configuration matérielle donnée. Comparer ces chiffres comme s’ils décrivaient la même vitesse conduirait à une interprétation erronée : une vidéo peut être lue à 30 images par seconde même si sa génération a pris plus ou moins de temps que sa durée finale.

Les spécifications du checkpoint résument la taille du modèle, son architecture et le format de sortie, mais ne décrivent pas à elles seules la qualité de chaque séquence ni la compatibilité avec toute configuration robotique. La capacité bimanuale et la référence à AgiBot délimitent le champ indiqué pour ce modèle. Le tableau ne transforme pas non plus la résolution, la fréquence de lecture ou le nombre de paramètres en mesures directes de précision, de stabilité ou de fidélité physique.

Benchmarks et méthode d’évaluation

NVIDIA publie des résultats dans trois grands domaines : la navigation de caméra (PAI-Bench-G et Sana-WM) et la manipulation robotique (AgiBot-World et AgiBot-GEAR). Pour la navigation, le modèle est évalué en alignant, selon la méthode d’Umeyama, les trajectoires estimées sur les trajectoires fournies. Les mesures comprennent l’erreur absolue de translation (ATE) et les erreurs relatives de translation et de rotation (RTE et RRE). Pour la manipulation, l’évaluation utilise des mesures de fidélité vidéo — PSNR, SSIM et LPIPS — ainsi qu’une mesure de dérive perceptuelle.

Ces résultats sont ceux publiés par le fournisseur et n’ont pas été reproduits de manière indépendante. Les benchmarks de navigation ne démontrent pas une capacité de manipulation physique précise, pas plus que les résultats de manipulation ne valident la navigation. Il ne faut pas non plus calculer une moyenne entre une mesure de qualité vidéo et une mesure d’erreur de trajectoire : elles évaluent des dimensions différentes.

Les catégories de navigation de caméra et de manipulation répondent à des questions différentes. En navigation, l’alignement d’Umeyama permet de comparer une trajectoire estimée à la trajectoire d’entrée après leur alignement ; l’ATE résume l’erreur absolue de translation, tandis que RTE et RRE décrivent les erreurs relatives le long de la trajectoire. Ces mesures caractérisent le suivi géométrique évalué : elles n’établissent ni la façon dont le robot interagit avec les objets ni la sécurité physique d’une manœuvre.

En manipulation, PSNR, SSIM et LPIPS comparent différents aspects de la ressemblance entre la vidéo générée et la référence, tandis que la dérive perceptuelle décrit un autre aspect de l’évolution visuelle. Chaque métrique n’offre qu’un point de vue partiel : les scores de qualité d’image ne démontrent pas que les contacts, la géométrie ou la permanence des objets sont correctement représentés. La comparaison entre modèles doit donc conserver les mesures séparées et tenir compte de la dimension évaluée par chaque colonne.

Le tableau d’AgiBot-World présente une comparaison publiée par NVIDIA avec DreamDojo 2B et DreamDojo 14B. Dans les colonnes affichées, Cosmos3-Nano-Sim-Bimanual obtient des valeurs supérieures pour la qualité vidéo, le PSNR et le SSIM, et inférieures pour le LPIPS et la dérive. Cette lecture décrit uniquement les résultats de cette comparaison et de ces métriques ; elle ne permet pas de conclure que le modèle est supérieur dans toutes les tâches, avec d’autres morphologies ou en matière de précision physique. Les résultats publiés n’ayant pas été reproduits de façon indépendante, ils doivent rester présentés comme tels, et non comme une validation universelle.

Déploiement et coûts

Le modèle est optimisé pour fonctionner sur des systèmes NVIDIA accélérés par GPU, basés sur les microarchitectures Blackwell et Hopper. La documentation recommande du matériel de centre de données ou des stations de travail hautes performances, notamment les RTX PRO 6000, H100, H200 et B200. Le moteur d’inférence pris en charge est vLLM-Omni, qui permet de servir le modèle dans un conteneur Docker.

Au moment de l’examen, aucun tarif commercial à l’API par jeton n’était publié pour cette variante précise. Le coût porte donc principalement sur l’infrastructure exploitée par l’utilisateur : GPU, mémoire, stockage et fonctionnement. Le téléchargement des poids ne rend pas l’inférence gratuite ; il faut aussi budgéter l’énergie consommée et le temps de calcul. Les débits d’inférence publiés varient fortement selon le matériel : de 10,7 images/s sur H20 à 54,1 images/s sur GB200.

Le choix du GPU influe à la fois sur la possibilité d’exécuter le modèle et sur le temps nécessaire pour générer une séquence. Les valeurs de débit du tableau correspondent à des essais en 480p avec un seul GPU et doivent être lues dans le cadre de cette configuration : elles ne garantissent pas les mêmes performances sur tout matériel, pour toute longueur de séquence ou toute charge de travail. Les différences entre H20, RTX PRO 6000, H100, H200 et GB200 montrent que le matériel compte, mais ne permettent pas, à elles seules, d’isoler tous les facteurs qui peuvent influer sur une exécution donnée.

vLLM-Omni et le conteneur Docker font partie de la méthode de déploiement décrite pour servir le modèle, tandis que la disponibilité des poids permet une installation locale. Aucun de ces éléments ne supprime les besoins opérationnels de l’inférence : il faut disposer de suffisamment de mémoire et de stockage, maintenir l’environnement d’exécution et prendre en compte l’énergie et le temps de calcul. Télécharger les poids peut éviter de dépendre nécessairement d’une tarification à l’usage, mais n’élimine pas les coûts d’infrastructure et ne garantit pas qu’une instance donnée soit disponible ou économique.

L’absence de tarif commercial par jeton publié pour cette variante ne confirme pas qu’aucun service géré n’existe et ne suffit pas à estimer le coût d’un déploiement propre sans connaître sa configuration. Le budget dépend du matériel choisi et de l’intensité d’utilisation. De même, le débit en images par seconde n’est ni un tarif ni un coût par séquence : pour le relier au coût d’exploitation, il faut aussi considérer la quantité de vidéo générée et le temps de calcul effectif.

Limites, sécurité et critères de choix

Ce modèle n’est pas un simulateur de physique. La géométrie, la permanence des objets, les contacts et les lois physiques ne sont qu’approximés. Il peut produire des incohérences temporelles, des mouvements instables et des interactions physiques imprécises. Il ne convient donc pas à la prise de décisions critiques pour la sécurité ni à la certification de la sécurité d’un robot réel sans validation indépendante approfondie.

La licence OpenMDW 1.1 autorise les usages commerciaux et non commerciaux, mais les utilisateurs restent responsables des droits associés aux entrées et de la sécurité de l’intégration. Le modèle peut servir à générer des données synthétiques ou à évaluer des politiques dans des environnements contrôlés, en maintenant une supervision humaine et des limites de sécurité indépendantes de la vidéo produite. Le fait qu’un mouvement paraisse plausible à l’écran ne garantit pas que le robot physique puisse l’exécuter sans collision ni dommage.

L’apparence cohérente d’une séquence ne prouve pas que le modèle reproduit les lois physiques. La représentation des objets, des contacts et des mouvements peut s’écarter du comportement réel, même lorsque les images semblent s’enchaîner sans rupture. Cette différence est essentielle pour interpréter une simulation visuelle : le modèle génère une prédiction vidéo conditionnée par les entrées, et non une certification de l’état physique futur ou une vérification déterministe des collisions.

L’examen d’une sortie peut chercher des signes de dérive perceptuelle, des changements inattendus dans la scène, des mouvements instables ou des interactions qui ne concordent pas avec la séquence d’actions. Ces vérifications aident à décrire des défauts visibles, mais ne remplacent pas les essais du système robotique complet. La sécurité exige une validation indépendante, car une séquence convaincante à l’écran peut omettre une collision ou représenter de façon inexacte le contact et la géométrie.

Le processus d’évaluation sépare la préparation des entrées, la génération et l’analyse. Définir la morphologie et faire correspondre les dimensions des actions au schéma JSON permet de préciser les valeurs envoyées ; préparer l’image initiale et les actions normalisées fixe les conditions de l’essai. Des métriques de référence peuvent ensuite permettre des comparaisons quantitatives lorsque des données de vérité terrain existent, même si PSNR et ATE ne mesurent pas la même chose et ne doivent pas être fusionnés en un score unique sans justification spécifique.

La responsabilité concernant les droits associés aux entrées et la sécurité de l’intégration incombe aux utilisateurs du modèle. La licence indiquée autorise les usages commerciaux et non commerciaux, mais cette autorisation ne rend pas automatiquement toute image, tout texte ou toute séquence d’actions libre de restrictions. La supervision humaine et les limites de sécurité externes doivent également fonctionner indépendamment de la vidéo générée : représenter un mouvement ne prouve pas qu’un robot puisse l’exécuter sans dommage ni collision.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.