Cosmos3-Nano-Sim-Bimanual: Technische Analyse, Grenzen und Deployment-Kriterien

Identität und Zweck des Modells

Cosmos3-Nano-Sim-Bimanual ist eine nachtrainierte und kausal destillierte Variante des Basismodells Cosmos3-Nano, entwickelt von NVIDIA. Seine spezifische Funktion besteht darin, die Entwicklung einer Umgebung in Reaktion auf die Aktionen eines bimanuellen Roboters und auf Kameratrassen zu simulieren. Im Gegensatz zu einem Steuerungsmodell, das Aktionen vorhersagt, generiert dieses Modell Video aus gegebenen Aktionen und fungiert als visueller Simulator für die Vorwärtsdynamik.

Das Modell wurde am 20. Oktober 2026 unter der Lizenz OpenMDW 1.1 veröffentlicht. Es ist so konzipiert, dass es die Bewertung robotischer Politiken, das Training von Reinforcement Learning und die Generierung synthetischer Demonstrationsdaten ohne Teleoperation ermöglicht, sofern die Steuerungs-Eingaben von einem anderen Modell oder einem menschlichen Operator bereitgestellt werden.

Die Richtung der Vorhersage ist für die Systemarchitektur entscheidend. Der Simulator erhält vorgegebene Aktionen und erzeugt dazu ein mögliches visuelles Geschehen. Ein Policy-Modell würde dagegen die Aktionen auswählen, die der Roboter ausführen soll. Wird der Simulator zur Bewertung einer Policy verwendet, bleibt diese Auswahl deshalb eine getrennte Komponente. Das erzeugte Video kann bei der Untersuchung der Folgen helfen, erteilt dem Roboter aber keinen eigenständig validierten Bewegungsauftrag. Gerade in einer geschlossenen Bewertungsschleife müssen die Rollen der Aktionswahl und der Beobachtung klar getrennt bleiben.

Architektur und technische Spezifikationen

Das Modell verfügt über 16 Milliarden Parameter und nutzt eine Transformer-Architektur mit Mixture-of-Transformers (MoT). Es arbeitet durch die Generierung von Video in kleinen Blöcken latenter Frames, die auf den zwischengespeicherten Historie und den eingehenden Steuereingaben basieren. Dies ermöglicht es, die Szenenkontinuität über Änderungen in der Kamerapose und dem Zustand der Roboterarme oder Greifer hinweg aufrechtzuerhalten.

Die unterstützten Eingaben umfassen ein Startbild (JPG, PNG, JPEG, WebP), Sequenzen von Roboteraktionen im JSON-Format, Kameratrassen und optionalen Text zur Beschreibung der Szene. Die Ausgabe ist ausschließlich Video im MP4-Format oder gestreamte Frames, mit einer Auflösung von 480p und einer Wiedergabefrequenz von 30 fps. Es ist entscheidend, zwischen der Wiedergabefrequenz (30 fps) und der Inferenzleistung (generierte Frames pro Sekunde) zu unterscheiden, die je nach Hardware variiert.

Die zwischengespeicherte Historie verbindet die Erzeugung aufeinanderfolgender Videoblöcke. Diese Konditionierung beschreibt, welche Informationen in die nächste Vorhersage eingehen; sie garantiert keine physikalisch korrekte Fortsetzung jeder Szene. Auch die Wiedergabefrequenz beschreibt etwas anderes als die Geschwindigkeit der Berechnung. Ein Video kann mit einer bestimmten Bildrate abgespielt werden, obwohl seine Erstellung auf einer gewählten Hardware länger dauert. Für einen interaktiven Versuch muss deshalb die tatsächlich erreichte Inferenzleistung zusammen mit der restlichen Verarbeitung betrachtet werden, statt die Wiedergabeangabe als Zusicherung von Echtzeitbetrieb zu lesen.

Benchmarks und Bewertungsmethodik

NVIDIA veröffentlicht Ergebnisse in drei Hauptkategorien: Kameranavigation (PAI-Bench-G und Sana-WM) und robotische Manipulation (AgiBot-World und AgiBot-GEAR). Bei der Navigation wird das Modell durch die Umeyama-Ausrichtung bewertet, um geschätzte Trassen mit den Eingabetrassen zu vergleichen, wobei absolute (ATE) und relative (RTE/RRE) Translationsfehler gemessen werden. Bei der Manipulation werden Metriken für die Video-Treue (PSNR, SSIM, LPIPS) und die wahrgenommene Drift verwendet.

Der Anbieter hat diese Ergebnisse veröffentlicht; Inferama hat sie nicht unabhängig reproduziert. Navigations-Benchmarks belegen keine präzise physische Manipulation und umgekehrt. Eine Punktzahl für die Videoqualität sollte nicht mit einem Trassenfehler gemittelt werden, da beide unterschiedliche Leistungsdimensionen messen.

Die verschiedenen Benchmarks prüfen unterschiedliche Eigenschaften der erzeugten Sequenzen. Eine Bildähnlichkeitsmetrik vergleicht visuelle Eigenschaften mit einer Referenz; ein Trajektorienfehler betrifft die Übereinstimmung der betrachteten Bewegung. Diese Messgrößen dürfen weder zu einer beliebigen Gesamtnote vermischt noch als direkter Nachweis für sicheren Kontakt eines realen Roboters interpretiert werden. Die angegebenen Vergleiche beschreiben die getesteten Daten und Bedingungen. Für ein anderes Robotersystem oder eine andere Aufgabe ist gesondert zu prüfen, welche Aussage die jeweilige Metrik überhaupt unterstützt.

Auch innerhalb derselben Tabelle sind Richtung und Bedeutung der Werte zu beachten. Bei Qualitäts- und Ähnlichkeitsmaßen kann ein höherer Wert günstiger sein, während Fehler- und Driftmaße eine andere Richtung haben. Das hilft, die aufgeführten Ergebnisse korrekt zu lesen, macht sie aber nicht zu einer unabhängigen Reproduktion. Vor einer Verwendung im eigenen Versuch müssen Eingaben, Referenzen und Auswertung so gewählt werden, dass sie zur vorgesehenen Aufgabe passen. Eine gute visuelle Bewertung allein beantwortet die Frage nach genauer physischer Manipulation nicht.

Deployment-Anforderungen und Kosten

Das Modell ist für den Betrieb auf GPU-beschleunigten Systemen von NVIDIA optimiert, speziell auf den Mikroarchitekturen Blackwell und Hopper. Die offizielle Dokumentation empfiehlt Hardware für Rechenzentren oder High-Performance-Workstations, wie RTX PRO 6000, H100, H200 oder B200. Der unterstützte Inferenz-Engine ist vLLM-Omni, das es ermöglicht, das Modell über einen Docker-Container bereitzustellen.

Für diese spezifische Variante steht keine veröffentlichte kommerzielle API-Gebühr pro Token fest. Die Hauptkosten entstehen durch die eigene Infrastruktur: GPU, Speicher, Storage und Betrieb. Die Gewichte lassen sich herunterladen; die Inferenz ist dadurch jedoch nicht kostenlos. Energieverbrauch und Rechenzeit müssen eingeplant werden. Die Inferenzrate reicht von 10,7 fps auf H20 bis zu 54,1 fps auf GB200.

Die veröffentlichten Durchsatzangaben beziehen sich auf die jeweilige Testhardware und Ausgabekonfiguration. Sie zeigen deshalb keine einheitliche Geschwindigkeit des Modells für alle Installationen. Für die Kostenplanung zählt die Rechenzeit des eigenen Versuchs einschließlich der übrigen Verarbeitungsschritte. Der frei verfügbare Download der Gewichte beseitigt weder den Bedarf an kompatibler Hardware noch den Aufwand für Betrieb und Wartung. Ebenso ist der Zugang zu einem Modell über einen anderen Dienst eine eigene technische und vertragliche Frage, aus der sich keine offizielle API-Tarifangabe für diesen Checkpoint ableiten lässt.

Einschränkungen, Sicherheit und Auswahlkriterien

Das Modell ist kein Physiksimulator. Geometrie, Objektpermanenz, Kontakt und physikalische Gesetze werden nur approximiert. Es kann zeitliche Inkonsistenzen, instabile Bewegung und Ungenauigkeiten in physischen Interaktionen erzeugen. Daher sollte es nicht für sicherheitskritische Entscheidungen oder zur Zertifizierung der Sicherheit eines Roboters in der realen Welt ohne umfassende unabhängige Validierung verwendet werden.

Die Lizenz OpenMDW 1.1 erlaubt kommerzielle und nicht-kommerzielle Nutzung, aber die Nutzer sind für die Rechte an den Eingaben und die sichere Integration verantwortlich. Es wird empfohlen, das Modell zur Generierung synthetischer Daten oder zur Bewertung von Politiken in kontrollierten Umgebungen zu verwenden, wobei immer eine menschliche Aufsicht und unabhängige Sicherheitsgrenzen vom generierten Video aufrechterhalten werden. Die Fähigkeit, eine Bewegung im Video darzustellen, garantiert nicht, dass der physische Roboter sie ohne Kollisionen oder Schäden ausführen kann.

Die Grenze zwischen visueller Plausibilität und physischer Validierung bleibt auch bei überzeugenden Videos bestehen. Ein dargestellter Kontakt kann plausibel aussehen, ohne Kräfte, Kollisionen oder Sicherheitsabstände zuverlässig abzubilden. Daher benötigt ein Robotersystem unabhängige Sicherheitsgrenzen und physische Prüfungen, die nicht allein vom generierten Video abhängen. Das Modell kann für Forschungsversuche und synthetische Daten nützlich sein, ohne damit eine Zertifizierung oder eine sichere Übertragung jeder beobachteten Bewegung auf reale Hardware zu liefern.

Eine sinnvolle Bewertung beschreibt zuerst die Morphologie und die Aktionen, die im Versuch unterstützt werden sollen. Danach kann untersucht werden, ob die erzeugten Sequenzen über den benötigten Zeitraum brauchbar sind und welche Fehler auftreten. Der rechtliche Zugriff auf die Gewichte und die Rechte an den Eingaben gehören ebenfalls zur Integration, beantworten aber nicht die technische Sicherheitsfrage. Diese Trennung erlaubt eine begrenzte, überprüfbare Verwendung des Simulators, ohne seine Ausgabe als allgemeines Abbild der realen Robotik zu behandeln.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.