Cosmos3-H-Embodied-Nano: análisis de capacidades, límites y coste para robótica quirúrgica

Qué hace el modelo exacto

Cosmos3-H-Embodied-Nano es un checkpoint de investigación publicado por NVIDIA el 20 de octubre de 2026. Se trata de una variante especializada de Cosmos3-Nano (16B parámetros) que ha sido post-entrenada durante 50.000 iteraciones en el conjunto de datos Open-H-Embodiment, enfocado en robótica quirúrgica.

A diferencia de los modelos de generación de vídeo genéricos, este modelo está diseñado para acoplar vídeo, acciones robóticas y texto en una única secuencia multimodal. No es un dispositivo médico autorizado, sino una herramienta para la generación de modelos de mundo quirúrgicos, la evaluación en bucle cerrado de políticas robóticas y la generación de datos sintéticos antes de la implementación en sistemas físicos.

La combinación de vídeo, acciones robóticas y texto permite representar tanto lo que el sistema observa como las acciones asociadas a esa observación dentro de una secuencia común. Esa estructura sirve para estudiar relaciones entre estado visual, instrucciones y movimiento, pero no convierte las predicciones en mediciones directas del estado físico ni en órdenes validadas para un robot real.

La distinción entre checkpoint de investigación y producto terminado importa para interpretar su papel: el modelo puede apoyar experimentos de modelado, evaluación y generación de datos, pero su publicación no equivale a autorización para uso médico. La generación de datos sintéticos tampoco demuestra por sí sola que esos datos reproduzcan todas las condiciones de una intervención o que basten para validar un sistema físico.

El carácter especializado del ajuste sitúa el modelo en el contexto de la robótica quirúrgica y del conjunto Open-H-Embodiment. Esa especialización describe el objetivo del entrenamiento; no establece automáticamente que el comportamiento aprendido se transfiera sin cambios a instrumentos, configuraciones o secuencias que no estén representados en las pruebas descritas.

Arquitectura y modos de funcionamiento

El modelo utiliza una arquitectura Mixture-of-Transformers (MoT) que combina una torre de razonamiento (basada en Qwen3-VL-8B) y una torre de generación (experto de difusión). Durante el post-entrenamiento, la torre de razonamiento se mantiene congelada, mientras que se actualizan aproximadamente 7.000 millones de parámetros en la torre generativa, el incrustador de tiempo y las proyecciones de entrada/salida de acciones.

El modelo opera en tres modos que son, en realidad, diferentes máscaras de tokens limpios y ruidosos sobre la misma secuencia compartida: dinámica directa (vídeo a partir de acciones), dinámica inversa (acciones a partir de vídeo) y política (acciones y vídeo a partir de imagen, texto e historial). Estos modos se entrenan conjuntamente con una proporción de 0,4 / 0,2 / 0,4 respectivamente.

La arquitectura MoT organiza el procesamiento en una torre de razonamiento y otra de generación, con funciones distintas dentro del modelo. La primera aporta el componente de razonamiento visual y lingüístico basado en Qwen3-VL-8B, mientras que el experto de difusión produce la generación. Mantener congelada la torre de razonamiento durante el post-entrenamiento significa que esa parte no se actualiza en esa etapa; no implica que el modelo completo permanezca sin cambios.

La actualización de aproximadamente 7.000 millones de parámetros se reparte entre la torre generativa, el incrustador temporal y las proyecciones que conectan las acciones con la representación compartida. Por ello, el número de parámetros ajustados durante el post-entrenamiento no debe confundirse con el tamaño total del checkpoint: la variante descrita conserva 16B parámetros en conjunto.

Los tres modos se distinguen por qué partes de la secuencia se presentan como condicionamiento y cuáles se generan. En dinámica directa, las acciones condicionan la producción de vídeo; en dinámica inversa, el vídeo observado sirve para inferir acciones; y en política, imagen, texto e historial condicionan la predicción conjunta de acciones y vídeo. Las máscaras de tokens permiten compartir la representación y el entrenamiento, pero cada modo plantea una tarea distinta y sus resultados no son intercambiables.

La proporción de entrenamiento 0,4 / 0,2 / 0,4 asigna pesos relativos a dinámica directa, dinámica inversa y política, respectivamente. Esa distribución describe cómo se combinan las tareas durante el entrenamiento conjunto; no significa que el modelo dedique esas mismas fracciones de tiempo a cada modo durante una inferencia individual ni que los tres modos tengan igual rendimiento.

Benchmarks y metodología publicada

NVIDIA evalúa el modelo en 640 clips de 2,4 segundos (25 fotogramas y 24 pasos de acción a 10 Hz) extraídos de la división de validación reservada (5% de los datos) de diez familias de datos públicas. Las métricas principales son el PSNR (Peak Signal-to-Noise Ratio) para la calidad del vídeo y el MSE (Mean Squared Error) en el espacio de acciones normalizadas.

En el modo de dinámica directa, el modelo alcanza un PSNR medio de 26,1 dB. En dinámica inversa, el MSE de acciones es de 0,009, lo que representa una mejora de 8,6 veces sobre la línea base de predicción de la media. En el modo de política, el MSE medio es de 0,052 y el mejor de cuatro muestras es de 0,033. Es importante destacar que estas métricas no miden la seguridad clínica ni garantizan el seguimiento preciso de los instrumentos quirúrgicos.

La evaluación se basa en clips breves de una división de validación reservada, no en una demostración de desempeño clínico. Cada clip contiene 25 fotogramas y 24 pasos de acción a 10 Hz, por lo que los resultados describen tareas acotadas en el tiempo. La selección de 640 clips procedentes de diez familias de datos permite resumir el comportamiento en ese conjunto, pero no establece por sí sola cómo responderá el modelo ante datos distintos de los evaluados.

El PSNR compara la similitud de los valores de píxel entre el vídeo generado y el de referencia. Un valor medio de 26,1 dB resume esa comparación en dinámica directa, pero no separa necesariamente el movimiento de los instrumentos de las zonas estáticas de la imagen. Por eso, la cifra no debe interpretarse como una medida directa de seguimiento quirúrgico, precisión anatómica o calidad clínica.

El MSE de acciones calcula el error cuadrático medio en el espacio de acciones normalizadas. En dinámica inversa, el valor de 0,009 y la mejora indicada frente a la predicción de la media expresan una comparación con esa línea base dentro del protocolo descrito. En política, el promedio de 0,052 y el mejor resultado entre cuatro muestras de 0,033 corresponden a resúmenes distintos: el segundo selecciona el menor error de varias generaciones y no equivale al rendimiento medio de una única predicción.

Las columnas de dVRK y CMR Versius permiten observar que los resultados varían entre los subconjuntos asociados a esos sistemas. Por ejemplo, la dinámica directa presenta valores de PSNR distintos para ambos, y los errores de acción de política también difieren. Estas diferencias aconsejan leer el promedio general junto con los resultados por sistema; ninguno de ellos demuestra por sí solo un comportamiento uniforme en todas las tareas o configuraciones.

Precio y requisitos de despliegue

Cosmos3-H-Embodied-Nano se distribuye como un checkpoint público bajo la NVIDIA Open Model License Agreement. No existe una tarifa API oficial publicada por NVIDIA para este modelo específico; los costes se asocian a la infraestructura de GPU necesaria para su despliegue propio.

El modelo requiere hardware NVIDIA (Ampere, Hopper o Blackwell) y se ha validado únicamente en precisión BF16. Para la inferencia, se recomienda una GPU con suficiente memoria para manejar la secuencia multimodal de 16B parámetros. El servidor HTTP incluido en el repositorio permite desplegar el modelo localmente, pero no constituye una API comercial gestionada.

La licencia que acompaña al checkpoint regula su uso, mientras que la ausencia de una tarifa API publicada para este modelo concreto significa que no hay un precio oficial por llamada que pueda usarse como referencia. El despliegue propio traslada el cálculo a la infraestructura administrada por quien ejecuta el modelo; por tanto, el acceso a los pesos y el coste de generar inferencias son cuestiones distintas.

La compatibilidad declarada con Ampere, Hopper y Blackwell delimita las arquitecturas de hardware NVIDIA indicadas para el modelo. La validación únicamente en BF16 describe la precisión probada, no asegura que otros formatos sean equivalentes ni que una configuración compatible produzca idéntico rendimiento en toda infraestructura. La memoria disponible debe cubrir tanto los parámetros como las necesidades de la secuencia multimodal y de la ejecución, de modo que el tamaño del modelo es solo una parte de los requisitos prácticos.

El servidor HTTP incluido permite exponer localmente la inferencia mediante una interfaz de servicio, pero no incorpora por ese hecho las características de una API comercial gestionada. La administración del entorno, la disponibilidad y los recursos de cómputo siguen dependiendo del despliegue propio. Del mismo modo, que el repositorio ofrezca una vía local no elimina el trabajo de instalación y configuración del runtime.

El coste total de propiedad incluye más que la adquisición o disponibilidad del checkpoint: la GPU, la electricidad y el mantenimiento forman parte del coste de operar el sistema. Los ejemplos de GPU citados en el texto ilustran posibles referencias de infraestructura, no un presupuesto universal ni una recomendación de compra. El gasto efectivo depende de la configuración elegida y del uso que se haga de ella.

Limitaciones, seguridad y alternativas

El modelo está entrenado en clips de 2,4 segundos. En secuencias más largas (superiores a 6 segundos), la calidad del vídeo se degrada, con un aumento de la difuminación y la deriva de estado. La métrica de PSNR está dominada por el tejido estático y no mide directamente la precisión del seguimiento de los instrumentos.

NVIDIA advierte explícitamente que el modelo no es un simulador de física y que las salidas no son decisiones certificadas de seguridad. Para aplicaciones críticas, se requiere una validación independiente y un análisis de seguridad a nivel de sistema. Como alternativa, el modelo Cosmos3-H-Dreams es una versión destilada de este checkpoint, optimizada para inferencia en tiempo real (30 FPS en RTX PRO 6000) y específica para el sistema CMR Versius.

La degradación en secuencias superiores a seis segundos limita la interpretación de las predicciones temporales: el aumento de difuminación y deriva de estado indica que la calidad visual puede deteriorarse al prolongar el horizonte más allá de los clips cortos de entrenamiento descritos. No permite concluir que todos los resultados largos fallen del mismo modo, pero sí desaconseja tratar la calidad observada en clips breves como una garantía para secuencias extendidas.

La advertencia de que el modelo no es un simulador de física separa la generación visual de una representación física validada. Un vídeo plausible no prueba que las interacciones, fuerzas o trayectorias reproduzcan con exactitud las condiciones reales. Por esa razón, las salidas tampoco constituyen decisiones certificadas de seguridad, y las aplicaciones críticas requieren validación independiente y análisis de seguridad del sistema completo.

En el ejemplo de evaluación de políticas, la comparación con datos reales de validación sirve para examinar las predicciones del modelo en una tarea delimitada. El resultado de 24 pasos permite contrastar acciones y vídeo previstos con la secuencia observada, pero esa comparación no demuestra por sí sola que una estrategia de sutura sea segura, eficaz o adecuada para su ejecución física. El ejemplo ilustra una evaluación de investigación, no una recomendación clínica.

Cosmos3-H-Dreams se presenta como una variante destilada orientada a la inferencia en tiempo real y al sistema CMR Versius. La cifra de 30 FPS se refiere a la configuración indicada con RTX PRO 6000; no debe extenderse automáticamente a otras GPU, secuencias o condiciones de despliegue. Su especialización y su objetivo de latencia también hacen que la comparación con el checkpoint base dependa de la tarea y la métrica considerada.

Criterios prácticos de elección

La elección entre usar Cosmos3-H-Embodied-Nano directamente o usar su variante destilada Cosmos3-H-Dreams depende de la necesidad de latencia. Si se requiere interactividad en tiempo real (teleoperación o evaluación en vivo), Cosmos3-H-Dreams es la opción adecuada debido a su arquitectura causal de 4 pasos. Si se requiere la máxima calidad de generación y se dispone de tiempo de cómputo para inferencia offline, el modelo base H-Embodied-Nano ofrece mejores métricas de fidelidad.

Para equipos que trabajan con robots dVRK, el modelo ofrece un rendimiento superior al de su predecesor (Cosmos-H-Surgical-Simulator) en métricas de píxel (PSNR y SSIM). Sin embargo, para el sistema CMR Versius en secuencias largas, el predecesor muestra una degradación más lenta en métricas de distribución (FVD).

La latencia y la fidelidad son criterios distintos para elegir entre el modelo base y la variante destilada. La arquitectura causal de cuatro pasos de Cosmos3-H-Dreams está asociada a su orientación hacia la interactividad, mientras que el modelo base se describe como preferible cuando se dispone de más tiempo para inferencia offline y se prioriza la calidad de generación. Esta comparación no establece una opción universalmente superior: la decisión depende del ritmo requerido y del tipo de resultado que se evalúe.

Las métricas de píxel y las métricas de distribución responden a preguntas diferentes. PSNR y SSIM comparan propiedades de las imágenes, mientras que FVD evalúa similitud entre distribuciones de vídeo; una ventaja en una familia de métricas no implica ventaja en todas las demás. Así, el mejor resultado del modelo base frente al predecesor en dVRK no contradice que el predecesor se degrade más lentamente en secuencias largas de CMR Versius según FVD: son sistemas y criterios de evaluación distintos.

El proceso de despliegue descrito corresponde a un entorno de investigación y separa la preparación de los pesos, la instalación del runtime y la ejecución de inferencia. La conversión a DCP se plantea cuando se utiliza inferencia distribuida, no como requisito universal para cualquier uso local. Tras iniciar el servidor o invocar la API de Python, contrastar las salidas con datos propios permite comprobar el comportamiento en el conjunto de trabajo previsto, aunque esa comprobación no sustituye la validación independiente ni el análisis de seguridad necesarios para aplicaciones críticas.

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.