Cosmos3-Nano-Sim-Bimanual: análisis técnico, límites y criterios de despliegue

Identidad y propósito del modelo

Cosmos3-Nano-Sim-Bimanual es una variante post-entrenada y destilada causalmente del modelo base Cosmos3-Nano, desarrollada por NVIDIA. Su función específica es simular la evolución de un entorno en respuesta a las acciones de un robot bimanual y a trayectorias de cámara. A diferencia de un modelo de política de control que predice acciones, este modelo genera vídeo a partir de acciones dadas, actuando como un simulador visual de dinámica hacia adelante.

El modelo fue publicado el 20 de octubre de 2026 bajo la licencia OpenMDW 1.1. Está diseñado para permitir la evaluación de políticas robóticas, el entrenamiento de aprendizaje por refuerzo y la generación de datos sintéticos de demostración sin necesidad de teleoperación, siempre que las entradas de control sean proporcionadas por otro modelo o un operador humano.

La distinción entre simulación visual y control determina qué componente debe aportar cada parte del sistema. Cosmos3-Nano-Sim-Bimanual recibe una secuencia de acciones ya definida y produce una representación visual de la evolución esperada; la elección de esas acciones corresponde a un controlador, una política robótica u otro mecanismo externo. Por ello, el modelo puede servir para observar cómo se proyecta una secuencia sobre una escena, pero no sustituye el proceso que decide qué movimiento ejecutar ni establece por sí mismo objetivos para el robot.

El carácter causal de la variante describe la organización de la generación en el tiempo: los bloques nuevos se condicionan en el historial disponible y en las entradas que llegan. La destilación y el post-entrenamiento distinguen esta variante del modelo base, pero no cambian su función descrita como generador condicionado de vídeo. La salida debe interpretarse como una simulación visual de dinámica hacia adelante, no como una medición directa del estado físico ni como una garantía de que el movimiento mostrado se reproduzca en un robot real.

La utilidad prevista depende de que el usuario proporcione las acciones de control. Una persona o un sistema externo puede preparar esas entradas para evaluar políticas, explorar secuencias o producir demostraciones sintéticas sin teleoperar cada movimiento durante la generación. Esa posibilidad no significa que el modelo formule las demostraciones de manera autónoma: la secuencia de acciones, la escena inicial y el objetivo del ensayo siguen siendo elementos que la integración debe definir.

Arquitectura y especificaciones técnicas

El modelo cuenta con 16.000 millones de parámetros y utiliza una arquitectura Transformer con Mixture-of-Transformers (MoT). Opera mediante la generación de vídeo en pequeños bloques de fotogramas latentes, condicionados en el historial en caché y en las entradas de control entrantes. Esto permite mantener la continuidad de la escena a través de cambios en la postura de la cámara y el estado de los brazos o pinzas del robot.

Las entradas soportadas incluyen una imagen inicial (JPG, PNG, JPEG, WebP), secuencias de acciones del robot en formato JSON, trayectorias de cámara y texto opcional para describir la escena. La salida es exclusivamente vídeo en formato MP4 o fotogramas en streaming, con una resolución de 480p y una tasa de fotogramas de reproducción de 30 fps. Es crucial distinguir entre la tasa de reproducción (30 fps) y el rendimiento de inferencia (fotogramas generados por segundo), que varía según el hardware.

La generación por bloques latentes organiza la producción de vídeo en segmentos sucesivos, en vez de tratar la secuencia completa como una única imagen. El historial en caché aporta contexto entre bloques y las entradas de control condicionan el contenido que se genera. Esa estructura busca conservar la continuidad visual cuando cambian la cámara o la configuración de los brazos y pinzas; no elimina la posibilidad de saltos, deriva o incoherencias temporales, que siguen siendo aspectos que conviene examinar en la salida.

La imagen inicial proporciona el punto de partida visual, mientras que las acciones JSON y las trayectorias de cámara describen cambios que deben representarse a lo largo del tiempo. El texto opcional puede caracterizar la escena, pero no sustituye esas entradas de control. En consecuencia, preparar correctamente cada modalidad y mantener coherentes sus referencias es parte del uso del modelo: un vídeo plausible no demuestra por sí solo que las acciones se hayan interpretado con la semántica física esperada.

La resolución de 480p y los 30 fotogramas por segundo corresponden a características de la salida reproducida, no al ritmo al que el sistema calcula cada fotograma. El throughput de inferencia expresa cuántos fotogramas puede generar por segundo bajo una configuración de hardware determinada. Comparar ambas cifras como si describieran la misma velocidad llevaría a una lectura equivocada: un vídeo puede reproducirse a 30 fps aunque la generación haya tardado más o menos tiempo que su duración final.

Las especificaciones del checkpoint resumen el tamaño del modelo, su arquitectura y el formato de salida, pero no describen por sí solas la calidad de cada secuencia ni la compatibilidad con cualquier configuración robótica. La capacidad bimanual y la referencia a AgiBot delimitan el alcance indicado para este modelo. La tabla tampoco convierte la resolución, la tasa de reproducción o el número de parámetros en medidas directas de precisión, estabilidad o fidelidad física.

Benchmarks y metodología de evaluación

NVIDIA publica resultados en tres categorías principales: navegación de cámara (PAI-Bench-G y Sana-WM) y manipulación robótica (AgiBot-World y AgiBot-GEAR). En la navegación, el modelo se evalúa mediante la alineación de Umeyama para comparar trayectorias estimadas con las de entrada, midiendo errores de traslación absoluta (ATE) y relativa (RTE/RRE). En la manipulación, se utilizan métricas de fidelidad de vídeo (PSNR, SSIM, LPIPS) y deriva perceptual.

Los resultados se comunican, pero no se han reproducido de forma independiente. Los benchmarks de navegación no acreditan la capacidad de manipulación física precisa, y viceversa. No se debe promediar una puntuación de calidad de vídeo con una de error de trayectoria, ya que miden dimensiones distintas del rendimiento.

Las categorías de navegación de cámara y manipulación responden a preguntas distintas. En navegación, la alineación de Umeyama permite comparar una trayectoria estimada con la trayectoria de entrada después de alinearlas; ATE resume el error de traslación absoluto y RTE/RRE describen errores relativos entre partes de la trayectoria. Estas medidas caracterizan el seguimiento geométrico evaluado y no establecen cómo interactúa el robot con objetos ni si una maniobra es físicamente segura.

En manipulación, PSNR, SSIM y LPIPS comparan aspectos de la semejanza entre vídeo generado y referencia, mientras que la deriva perceptual refleja otro aspecto de la evolución visual. Cada métrica ofrece una perspectiva parcial: las puntuaciones de calidad de imagen no demuestran que el contacto, la geometría o la permanencia de los objetos sean correctos. Por eso, la comparación entre modelos debe conservar las métricas separadas y atender a qué dimensión evalúa cada columna.

La tabla de AgiBot-World presenta una comparación publicada por NVIDIA con DreamDojo 2B y DreamDojo 14B. En las columnas mostradas, Cosmos3-Nano-Sim-Bimanual tiene valores superiores en calidad de vídeo, PSNR y SSIM, y valores inferiores en LPIPS y deriva. Esa lectura describe únicamente los resultados de esa comparación y esas métricas; no permite concluir que el modelo supere a los otros en toda tarea, en otras morfologías o en precisión física. Los resultados comunicados tampoco cuentan con reproducción independiente indicada aquí, de modo que deben conservarse como resultados publicados, no como una validación universal.

Requisitos de despliegue y coste

El modelo está optimizado para ejecutarse en sistemas acelerados por GPU de NVIDIA, específicamente en microarquitecturas Blackwell y Hopper. La documentación oficial recomienda hardware de centro de datos o estaciones de trabajo de alto rendimiento, como RTX PRO 6000, H100, H200 o B200. El motor de inferencia soportado es vLLM-Omni, que permite servir el modelo mediante un contenedor Docker.

No existe una tarifa API comercial publicada por tokens para esta variante específica en el momento de la revisión. El coste principal es la infraestructura propia: GPU, memoria, almacenamiento y operación. Los pesos son descargables, pero esto no implica que la inferencia sea gratuita; se debe presupuestar el consumo energético y el tiempo de cómputo. La tasa de inferencia varía drásticamente: desde 10,7 fps en H20 hasta 54,1 fps en GB200.

La elección de una GPU condiciona tanto la posibilidad de ejecutar el modelo como el tiempo requerido para generar una secuencia. Los valores de throughput de la tabla corresponden a pruebas a 480p con una GPU y deben leerse dentro de esa configuración: no son una promesa de rendimiento para cualquier equipo, longitud de secuencia o carga de trabajo. Las diferencias entre los resultados de H20, RTX PRO 6000, H100, H200 y GB200 muestran que el hardware importa, pero no aíslan por sí solas todos los factores que pueden influir en una ejecución concreta.

vLLM-Omni y el contenedor Docker forman parte de la vía de despliegue descrita para servir el modelo, mientras que la disponibilidad de los pesos permite una instalación propia. Ninguno de esos elementos suprime las necesidades operativas de la inferencia: hay que disponer de memoria y almacenamiento suficientes, mantener el entorno de ejecución y considerar energía y tiempo de cómputo. Descargar los pesos evita depender necesariamente de una tarifa por uso, pero no elimina los costes de infraestructura ni garantiza que una instancia concreta esté disponible o resulte económica.

La ausencia de una tarifa comercial por tokens publicada para esta variante no equivale a confirmar que no exista un servicio gestionado, ni permite estimar el coste de una implementación propia sin conocer su configuración. El presupuesto depende del hardware elegido y de cuánto se utilice. Del mismo modo, el throughput medido en fotogramas por segundo no es una tarifa ni un coste por secuencia: para relacionarlo con la operación hay que considerar cuánto vídeo se genera y el tiempo efectivo de cómputo.

Limitaciones, seguridad y criterios de elección

El modelo no es un simulador de física. La geometría, la permanencia de objetos, el contacto y las leyes físicas son solo aproximadas. Puede generar inconsistencias temporales, movimiento inestable e imprecisiones en interacciones físicas. Por lo tanto, no debe utilizarse para tomar decisiones de seguridad crítica ni para certificar la seguridad de un robot en el mundo real sin validación independiente exhaustiva.

La licencia OpenMDW 1.1 permite el uso comercial y no comercial, pero los usuarios son responsables de los derechos de las entradas y de la integración segura. Se recomienda utilizar el modelo para generar datos sintéticos o evaluar políticas en entornos controlados, manteniendo siempre una supervisión humana y límites de seguridad independientes del vídeo generado. La capacidad de representar un movimiento en vídeo no garantiza que el robot físico pueda ejecutarlo sin colisiones o daños.

La apariencia coherente de una secuencia no constituye una prueba de que el modelo reproduzca las leyes físicas. La representación de objetos, contactos y movimientos puede desviarse del comportamiento real, incluso cuando los fotogramas parecen continuos. Esta diferencia es especialmente importante al interpretar una simulación visual: el modelo genera una predicción en vídeo condicionada por las entradas, no una certificación del estado físico futuro ni una verificación determinista de colisiones.

La revisión de una salida puede buscar señales de deriva perceptual, cambios inesperados en la escena, movimiento inestable o interacciones que no concuerdan con la secuencia de acciones. Estas comprobaciones ayudan a describir defectos visibles, pero no sustituyen pruebas del sistema robótico completo. La evaluación de seguridad requiere validación independiente, porque una secuencia visualmente convincente puede omitir una colisión o representar de forma inexacta el contacto y la geometría.

El flujo de evaluación separa la preparación de entradas, la generación y el análisis. Definir la morfología y mapear las dimensiones de acción al esquema JSON permite precisar qué valores se envían; preparar la imagen inicial y las acciones normalizadas establece las condiciones del ensayo. Después, las métricas de referencia pueden aportar comparaciones cuantitativas cuando existen datos de verdad terrestre, aunque PSNR y ATE no midan lo mismo y no deban fusionarse en una puntuación única sin una justificación específica.

La responsabilidad por los derechos de las entradas y por una integración segura permanece en quienes utilizan el modelo. La licencia indicada permite usos comerciales y no comerciales, pero esa autorización no convierte cualquier imagen, texto o secuencia de acciones en una entrada libre de restricciones. Asimismo, la supervisión humana y los límites de seguridad externos deben operar independientemente del vídeo generado; la representación de un movimiento no demuestra que un robot pueda ejecutarlo sin daños ni colisiones.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.