Metatron-v1 : la politique humanoïde discrète de NVIDIA n’est pas un modèle de langage

Tard dans la journée du 27 octobre 2026, un dépôt appelé nvidia/Metatron-v1 est apparu sur Hugging Face. Il n’y a eu ni communiqué de presse, ni article sur le blog de NVIDIA — une recherche de ce nom sur ce blog renvoie toujours « No Results Found » — ni article scientifique, ni page produit. Ce qui est apparu, en revanche, c’est deux fichiers ONNX d’environ 403 Mo chacun, une licence, un fichier NOTICE et une fiche modèle décrivant un contrôleur appris de marche et de rétablissement pour un humanoïde Unitree G1. Metatron-v1 est une politique robotique, et non un modèle de langage, et presque tout ce qui vaut la peine d’être su à son sujet doit être lu dans cette fiche, car il n’existe rien d’autre à lire.

Les compteurs propres au dépôt disent à quel point cela s’est fait discrètement. Six commits entre 21:43 et 22:32 UTC, trois likes, et aucun chiffre de téléchargements vraiment significatif — la page indique que les téléchargements ne sont pas suivis pour ce modèle, tandis que l’API en rapporte zéro. Ce n’est pas un lancement. C’est un export brut avec sa documentation jointe, publié sous la licence de modèle ouverte de NVIDIA et laissé là pour que quelqu’un le trouve.

Le nom est la première chose qui induit en erreur.

Metatron n’est qu’à une lettre de Nemotron, la véritable famille ouverte de modèles de langage de NVIDIA, et la ressemblance fait déjà des dégâts : la même organisation Hugging Face publie les deux, les étiquettes de ce dépôt indiquent robotics / reinforcement-learning / humanoid, et l’étiquette de pipeline est reinforcement-learning plutôt que text-generation. Rien de tout cela n’empêche le nom d’être classé à côté des modèles de chat.

Cela compte parce que la comparaison n’est pas simplement défavorable — elle n’a aucun sens. Un lecteur qui place Metatron-v1 face à Gemma 4 12B ou Qwen 3.8 met côte à côte un contrôleur qui associe l’historique articulaire et les poses cibles à des cibles motrices, et des modèles qui associent du texte à du texte. Il n’y a ni entrée commune, ni sortie commune, ni benchmark susceptible de les placer sur un même axe. La version honnête de cette page tiendrait en une seule phrase, et c’est pourquoi nous n’en avons pas écrit.

Ce que la politique consomme et ce qu'elle produit

La fiche est inhabituellement précise au sujet des tenseurs, ce qui est son aspect le plus utile. Le fichier de démonstration mono-robot prend 39 entrées au total :

• État actuel de G1, plus huit échantillons d’état historiques — la politique voit environ un dixième de seconde de mouvement récent, pas un instantané.

• Des actions brutes entrantes appariées et un historique de neuf entrées d’actions brutes, afin que le réseau puisse déterminer ce qu’il essayait déjà de faire.

• Objectifs masqués de pose, de style et de vitesse futurs, ainsi qu’un contexte de boîte de scène — les objectifs sont en partie spécifiés et en partie laissés vides, ce qui correspond à l’idée d’inpainting de style MaskedMimic à laquelle la carte fait allusion.

Il renvoie les consignes PD articulaires sous forme de action, les gains sous forme de stiffness et damping, et raw_action pour le retour d’historique. Ces trois sorties sont ce dont un robot a besoin à la fréquence de contrôle ; il n’y a aucun texte dans l’interface.

Deux affirmations de la fiche méritent d’être distinguées du reste. La première est que la marche, l’interaction avec la scène et la récupération partagent désormais une seule politique — la fiche décrit l’export actuel comme l’« étudiant unifié compatible SAMP » de l’epoch-6410, sans adaptateur de récupération distinct. SAMP n’est pas explicité, mais dans la littérature sur le mouvement conscient de la scène, il signifie Stochastic Scene-Aware Motion Prediction, et les entrées de type scene-box cadrent avec cette lecture ; considérez cette expansion comme notre déduction, et non comme la formulation de NVIDIA. La seconde est que les cibles de récupération restent des entrées d’exécution dynamiques plutôt que des objectifs figés, ce qui fait la différence entre une politique que l’on peut réorienter en pleine chute et une animation fixe.

Deux exports, deux runtimes, un seul ensemble de poids

Les deux fichiers portent la même politique apprise dans des agencements de graphe différents, et la fiche insiste sur le fait qu’ils ne sont pas interchangeables. Le fichier de démonstration fait fonctionner un seul robot et inclut le traitement des observations et la conversion des actions à l’intérieur du graphe. Le fichier Racer est un réseau par lots pour six robots qui attend des observations calculées en dehors du graphe, et sa taille de lot ne peut pas être modifiée sans le reconstruire et le revalider.

Les seuls chiffres présents dans l’ensemble du dépôt sont un contrôle de parité : le chemin à six robots a été comparé à l’export de démonstration à un seul robot sur 60 états de test distincts et perturbés par l’historique, avec une erreur absolue maximale d’action de 5,55e-6. NVIDIA a également fait varier la hauteur de récupération, le moment de la récupération, l’historique des actions et les entrées de scène, et a confirmé que les sorties variaient en conséquence. Ces deux éléments sont des contrôles d’ingénierie d’export — ils prouvent que les deux graphes calculent la même fonction et que les entrées sont correctement câblées. Ils ne disent absolument rien sur le fait que le robot reste debout, et la fiche le dit explicitement : « Il s’agit de contrôles numériques d’export, et non de benchmarks de réussite de tâche ou sur robot réel. »

Ce que NVIDIA n'a pas dit

La liste des absences est plus longue que celle des présences, et c’est la partie que le lecteur doit peser le plus lourdement.

• Aucune annonce, aucun article de blog, aucune publication ni page produit que nous ayons pu trouver, et pas la moindre mention sur le blog de NVIDIA sous ce nom.

• Aucune description de l'entraînement au-delà de deux phrases — un modèle étudiant de type transformer à la MaskedMimic, un prior déterministe et un décodeur — et aucune indication sur les données, les ressources de calcul ou l'objectif d'entraînement.

• Aucun taux de réussite des tâches, aucun taux de récupération après chute, aucun résultat de transfert simulation→réalité, aucune vidéo que nous puissions vérifier indépendamment.

• Aucun checkpoint d'entraînement et aucun jeu de données. La fiche indique clairement que le dépôt n'est pas un package complet de reproduction d'entraînement, ce qui signifie qu'il n'y a rien ici à fine-tuner.

Le langage de sécurité est tout aussi direct : le modèle n'est pas un système d'évitement de collisions ni un contrôleur de sécurité ; l'utilisation du matériel exige une validation indépendante, des limites de couple, des tests supervisés et un arrêt d'urgence ; et les assistances côté jeu — boosts de lancement, zones à faible gravité, réapparitions — sont des mécaniques d'application plutôt que des capacités de la politique apprise. Une fiche qui prend soin de préciser qu'une réapparition n'est pas une capacité vous dit quelque chose sur la part de la démo qui revient à la politique et sur celle qui revient au jeu.

La licence vous indique ce que vous ne pouvez pas prendre.

Les fichiers sont publiés sous la licence NVIDIA Open Model License, avec attribution dans NOTICE.txt et une autorisation distincte couvrant spécifiquement les deux exportations ONNX. Tout ce qui les entoure est explicitement exclu. Le dépôt n’accorde aucun droit sur les jeux de données de mouvement, les clips de référence de récupération, les maillages de robots, les ressources de jeu ou les logiciels d’exécution tiers, et le fichier NOTICE ajoute une phrase appuyée à propos de « la redistribution autonome de clips de mouvement réservés aux démonstrations » — l’autorisation de montrer un clip dans une démonstration ne suit pas le clip.

Concrètement : vous pouvez redistribuer le fichier de politique selon les termes de la licence, et vous ne pouvez pas reconstruire la démo à partir de ce dépôt, car les maillages, les clips, le code d’exécution et la configuration de l’application sont distribués ailleurs et sous leurs propres conditions. La fiche indique également que la diffusion publique dans un navigateur exige un accès anonyme aux fichiers, ce qui donne un indice sur le modèle de diffusion pour lequel l’export a été conçu.

Qui peut réellement faire quelque chose avec ça aujourd’hui ?

Peu de personnes, et la fiche est honnête sur les raisons. Les intégrations au navigateur exécutent MuJoCo compilé en WebAssembly pour la physique et ONNX Runtime Web pour l’inférence ; WebGPU est recommandé, et le repli CPU/WASM « ne garantit pas le fonctionnement en temps réel de six robots ». L’intégration exige le manifeste d’exécution correspondant et des ordres identiques des articulations et des corps, une même convention de quaternions, un même ordre de l’historique, une même normalisation, les mêmes masques de cible, la même fréquence de commande et le même mappage des actions. Si l’un de ces éléments est erroné, la politique s’exécutera allègrement et produira des absurdités.

Le déploiement au-delà du navigateur est évoqué — autres simulateurs, matériel G1 réel — mais sans recette jointe, et la fiche refuse explicitement de certifier que ces fichiers exacts ont été validés sur matériel. Pour une équipe de recherche disposant d’un G1 et d’une scène MuJoCo, cela suffit pour démarrer. Pour tous les autres, c’est un artefact de référence.

Là où un routeur a sa place, et où il ne l'a pas

Vous ne pouvez pas appeler Metatron-v1 via une API, et rien ici ne change cela : ce que NVIDIA a publié, ce sont deux fichiers à charger à côté d’un simulateur, pas un point de terminaison hébergé. Ce que nous routons, c’est l’autre moitié d’une pile robotique — le travail linguistique qui entoure un contrôleur. Des plans de tâches rédigés avant que la politique ne prenne le relais, des journaux de télémétrie et de défaillance résumés après une exécution, des légendes de mouvement transformées en objectifs structurés. OrcaRouter met plus de 200 modèles derrière une seule clé au prix catalogue du fournisseur, sans marge, et bascule automatiquement lorsque le point de terminaison d’un fournisseur tombe en panne, ce qui fait la différence entre un harnais d’évaluation qui se termine pendant la nuit et un autre qui perd discrètement la moitié de ses exécutions.

C’est là toute la connexion. Si votre question est de savoir quel contrôleur charger dans MuJoCo, cet article n’est pas le bon endroit pour y répondre, et aucune décision de routage n’y changera rien.

Qu’est-ce qui changerait cette histoire ?

Quatre éléments, classés à peu près par ordre d’importance. Une véritable annonce assortie de chiffres de réussite des tâches sur matériel transformerait une fiche en affirmation. Un point de contrôle d’entraînement ou un jeu de données rendrait la politique adaptable plutôt que figée. Une reproduction indépendante dans un simulateur public permettrait à quelqu’un d’autre que NVIDIA de dire si la conception unifiée scène-et-récupération fonctionne. Et les lots d’applications diffusés publiquement — la démo navigateur et le Racer à six robots — nous permettraient, à nous autres, de voir à quoi ressemble réellement la politique en mouvement, ce qu’une fiche de modèle ne peut pas montrer.

D’ici là, le fait intéressant n’est pas la politique. C’est le mode de publication : NVIDIA a mis un contrôleur humanoïde sur l’open hub avec une licence et une section prudente sur les limitations, sans prévenir personne, et a laissé la fiche porter le poids qu’un billet de lancement portait autrefois. Six commits, trois mentions J’aime et un compteur de téléchargements qui n’a jamais démarré. Voilà à quoi ressemble une sortie quand une entreprise a décidé que l’artefact est l’annonce.