Metatron-v1: NVIDIA:s tysta humanoidpolicy är inte en språkmodell

Sent den 27 oktober 2026 dök ett repository som heter nvidia/Metatron-v1 upp på Hugging Face. Det fanns inget pressmeddelande, inget inlägg på NVIDIAs egen blogg – en sökning på bloggen efter namnet ger fortfarande "Inga resultat hittades" – ingen artikel och ingen produktsida. Det som dök upp var två ONNX-filer på ungefär 403 MB vardera, en licens, en NOTICE-fil och ett modellkort som beskriver en inlärd gång- och återhämtningscontroller för en Unitree G1-humanoid. Metatron-v1 är en robotikpolicy, inte en språkmodell, och nästan allt som är värt att veta om den måste läsas ut ur det kortet, eftersom det inte finns något annat att läsa.

Repots egna räknare vittnar om hur tyst detta landade. Sex commits mellan 21:43 och 22:32 UTC, tre gillningar och ingen meningsfull nedladdningssiffra alls – sidan anger att nedladdningar inte spåras för den här modellen, medan API:et rapporterar noll. Det är ingen lansering. Det är en exportdump med dokumentation bifogad, publicerad under NVIDIAs öppna modelllicens och lämnad åt någon att hitta.

Namnet är det första som vilseleder

Metatron skiljer sig bara en bokstav från Nemotron, NVIDIAs faktiska öppna språkmodellsfamilj, och likheten gör redan skada: samma Hugging Face-organisation publicerar båda, taggarna i det här repot anger robotics / reinforcement-learning / humanoid, och pipeline-taggen är reinforcement-learning snarare än text-generation. Inget av det hindrar namnet från att placeras bredvid chattmodeller.

Det spelar roll eftersom jämförelsen inte bara är ofördelaktig – den är meningslös. En läsare som ställer Metatron-v1 mot Gemma 4 12B eller Qwen 3.8 håller en controller som mappar ledhistorik och målposeringar till motoriska mål bredvid modeller som mappar text till text. Det finns ingen gemensam indata, ingen gemensam utdata och inget benchmark som skulle kunna placera dem på samma axel. Den ärliga versionen av den sidan skulle vara en enda mening, vilket är anledningen till att vi inte har skrivit någon.

Vad policyn konsumerar och vad den producerar

Kortet är ovanligt specifikt om tensorer, vilket är det mest användbara med det. Demofilen för en enskild robot tar totalt 39 indata:

• Aktuellt G1-tillstånd plus åtta historiska tillståndsprover – policyn ser ungefär en tiondels sekund av nyligen inträffad rörelse, inte en enda ögonblicksbild.

• Parade ihop inkommande råa åtgärder med en historik över råa åtgärder på nio poster, så att nätverket kan avgöra vad det redan försökte göra.

• Maskerade framtida mål för pose, stil och hastighet, plus scenboxkontext — målen är delvis specificerade och delvis tomma, vilket är den MaskedMimic-liknande inpainting-idé som kortet anspelar på.

Den returnerar PD-mål för leder som action, förstärkningarna som stiffness och damping, och raw_action för historikåterkoppling. Dessa tre utdata är vad en robot behöver vid styrfrekvens; det finns ingen text någonstans i gränssnittet.

Två påståenden i kortet är värda att skilja från resten. Det första är att gång, sceninteraktion och återhämtning nu delar en och samma policy — kortet beskriver den aktuella exporten som epoch-6410 "SAMP-capable unified student" utan någon separat återhämtningsadapter. SAMP skrivs inte ut, men i litteraturen om scenmedveten rörelse står det för Stochastic Scene-Aware Motion Prediction, och scen-box-indata passar den tolkningen; behandla utvidgningen som vår slutledning, inte NVIDIAs formulering. Det andra är att återhämtningsmål förblir aktiva runtime-indata snarare än inbakade mål, vilket är skillnaden mellan en policy som kan riktas om mitt under ett fall och en fast animation.

Två exporter, två körtidsmiljöer, en uppsättning vikter

Båda filerna innehåller samma inlärda policy i olika graflayouter, och kortet betonar starkt att de inte är utbytbara. Demofilen kör en robot och inkluderar observationsbearbetning och aktionskonvertering inuti grafen. Racer-filen är ett batchat nätverk för sex robotar som förväntar sig observationer beräknade utanför grafen, och dess batchstorlek kan inte ändras utan att bygga om och validera om det.

De enda siffrorna i hela repositoriet är en paritetskontroll: den sexrobotiga banan jämfördes mot demoexporten för en enskild robot på 60 distinkta och historikperturberade testtillstånd, med ett maximalt absolut aktionsfel på 5.55e-6. NVIDIA varierade också återhämtningshöjd, återhämtningstidpunkt, aktionshistorik och scenindata och bekräftade att utdata förändrades som svar. Båda dessa är exporttekniska kontroller – de bevisar att de två graferna beräknar samma funktion och att ingångarna är korrekt kopplade. De säger ingenting alls om huruvida roboten håller sig upprätt, och kortet säger det rakt ut: "Detta är numeriska exportkontroller, inte benchmarks för uppgiftsframgång eller verkliga robotar."

Vad NVIDIA inte har sagt

Frånvarolistan är längre än närvarolistan, och det är den del som en läsare bör väga tyngst.

• Inget tillkännagivande, blogginlägg, paper eller produktsida som vi kunde hitta, och ingen NVIDIA-bloggbevakning under namnet överhuvudtaget.

• Ingen träningsbeskrivning utöver två fraser – MaskedMimic-liknande transformer-student, deterministisk prior och dekoder – och ingen uppgift om data, beräkningsresurser eller träningsmål.

• Ingen framgångsgrad för uppgifter, ingen återhämtningsgrad vid fall, inget sim-till-real-resultat, ingen video som vi självständigt kan verifiera.

• Ingen träningscheckpoint och inget dataset. Kortet säger klart och tydligt att repot inte är ett komplett paket för att återskapa träning, vilket innebär att det inte finns något här att finjustera.

Säkerhetsspråket är lika direkt: modellen är inte ett kollisionsundvikningssystem eller en säkerhetsstyrenhet, hårdvaruanvändning kräver oberoende validering, vridmomentgränser, övervakad testning och en nödstopp, och spelsidans hjälpmedel – startboosts, lågtyngdzoner, respawns – är applikationsmekanik snarare än förmågor hos den inlärda policyn. Ett kort som särskilt framhåller att en respawn inte är en förmåga berättar något om hur mycket av demon som är policyn och hur mycket som är spelet.

Licensen anger vad du inte får ta.

Filerna släpps under NVIDIA Open Model License, med attribuering i NOTICE.txt och ett separat tillstånd som specifikt omfattar de två ONNX-exporterna. Allt runt omkring dem är undantaget. Repositoriet ger inga rättigheter till motionsdataset, referensklipp för återställning, robotmeshar, spelresurser eller tredjepartsprogramvara för körtid, och NOTICE-filen tillägger en skarp rad om "fristående vidaredistribution av motionsklipp som endast är avsedda för demo" – tillstånd att visa ett klipp i en demo följer inte med klippet.

I praktiken: du får redistribuera policyfilen enligt licensvillkoren, och du kan inte bygga om demon från det här repositoriet, eftersom mesharna, klippen, körtidskoden och applikationskonfigurationen distribueras någon annanstans och under egna villkor. Kortet anger också att leverans via offentlig webbläsare kräver anonym åtkomst till filerna, vilket är en vink om den leveransmodell som exporten byggdes för.

Vem kan faktiskt göra något med det här idag

Inte många personer, och kortet är ärligt om varför. Webbläsarintegrationerna kör MuJoCo kompilerat till WebAssembly för fysik och ONNX Runtime Web för inferens; WebGPU rekommenderas, och CPU/WASM-reservlösningen ”garanterar inte realtidsdrift av sex robotar”. Integration kräver motsvarande runtime-manifest och identisk ordning för leder och kroppar, kvaternionkonvention, historikordning, normalisering, målmasker, styrfrekvens och åtgärdsmappning. Får man en av dessa fel kommer policyn att köra glatt och producera nonsens.

Driftsättning utanför webbläsaren nämns – andra simulatorer, riktig G1-hårdvara – men utan någon medföljande anvisning, och kortet avstår uttryckligen från att intyga att just dessa filer har validerats på hårdvara. För ett forskningsteam med en G1 och en MuJoCo-scen är det tillräckligt för att komma igång. För alla andra är det en referensartefakt.

Var en router passar in, och var den inte gör det

Du kan inte anropa Metatron-v1 via ett API, och inget här ändrar på det: det NVIDIA publicerade är ett par filer som du laddar bredvid en simulator, inte en hostad endpoint. Det vi routar är den andra halvan av en robotikstack — språkarbetet som omger en styrenhet. Uppgiftsplaner som skrivs innan policyn tar över, telemetri- och felloggar som sammanfattas efter en körning, rörelsebeskrivningar som görs om till strukturerade mål. OrcaRouter sätter över 200 modeller bakom en enda nyckel till leverantörens listpris utan påslag, och växlar automatiskt över när en leverantörs endpoint går ner, vilket är skillnaden mellan en utvärderingsharness som blir klar över natten och en som tyst tappar hälften av sina körningar.

Det är hela kopplingen. Om din fråga är vilken controller som ska läsas in i MuJoCo, är den här artikeln fel plats att besvara den på, och inget routningsbeslut kommer att hjälpa.

Vad skulle förändra den här historien?

Fyra saker, i grov ordning efter hur mycket de skulle spela roll. Ett riktigt tillkännagivande med siffror för uppgiftsframgång på hårdvara skulle förvandla ett kort till ett påstående. En träningscheckpoint eller en datamängd skulle göra policyn anpassningsbar snarare än fast. En oberoende reproduktion i en offentlig simulator skulle låta någon annan än NVIDIA säga om den enhetliga designen för scen och återhämtning fungerar. Och applikationspaketen som släpps offentligt – webbläsardemon och Racer med sex robotar – skulle låta oss andra se hur policyn faktiskt ser ut i rörelse, vilket är det enda som ett modellkort inte kan visa.

Fram till dess är det intressanta inte policyn. Det är publiceringsmönstret: NVIDIA lade en humanoid kontroller på den öppna hubben med en licens och en noggrann sektion om begränsningar, berättade det inte för någon och lät kortet bära den vikt som ett lanseringsinlägg brukade bära. Sex commits, tre gillningar och en nedladdningsräknare som aldrig kom igång. Det är så en release ser ut när ett företag har bestämt att artefakten är tillkännagivandet.