MJWarp: 2.048 robots paralelos en GPU con NVIDIA Warp

Por qué la simulación física pasó de ser una herramienta a ser el cuello de botella

Para entrenar un robot con reinforcement learning necesitas millones de pasos de interacción. En CPU, conseguir esa cantidad cuesta semanas de cómputo y limita a los equipos pequeños a escenas trivialmente simples. Cuando NVIDIA publicó su framework de simulación médica abierta el 22 de julio de 2026, mostró el techo alcanzable: ejecutar 8.192 entornos de entrenamiento de robots quirúrgicos en GPU comprimió el entrenamiento de políticas de más de cinco horas a menos de dos minutos, según reportó Tech Times. Eso es aproximadamente 150 veces más rápido.

La pregunta para un founder ya no es si entrenar en GPU, sino cómo migrar sin reescribir todo el stack. La segunda entrega de la serie State of Simulation for Physical AI de NVIDIA en Hugging Face responde exactamente a eso: cómo mover un brazo SO-101 desde MuJoCo CPU hacia MJWarp ejecutando 2.048 entornos paralelos sobre la misma tarjeta gráfica.

NVIDIA Warp: el lenguaje Python que se compila a CUDA

NVIDIA Warp es un framework Python para escribir kernels de alto rendimiento acelerado por GPU. El desarrollador escribe kernels tipados estáticamente en Python y el framework los compila a ejecución CPU o CUDA, con interop hacia PyTorch y JAX. La primera vez que se lanza un kernel se compila y se cachea; las siguientes reutilizan el binario nativo.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Tres capacidades centrales lo separan de escribir CUDA a mano:

Rendimiento nativo CUDA con compilación JIT, fusión de kernels y soporte para CUDA Graphs.
Autoría en Python puro con primitivas incluidas para vectores, matrices, cuaterniones, BVH, hash grids y matrices sparse.
Kernels diferenciables e interop tipo DLPack, lo que permite meter la simulación dentro del loop de entrenamiento de un modelo.

Sobre esa base opera un detalle crítico: a partir de Warp 1.15 se introdujo ejecución determinista opcional, donde los atomics de GPU se vuelven reproducibles a cambio de algo de rendimiento. Esto importa para validación y tests de regresión, aunque la determinidad cubre los kernels de Warp, no garantiza la del rollout completo de MJWarp.

MJWarp: el mismo MuJoCo, ahora batched sobre GPU

MJWarp es la implementación del pipeline físico de MuJoCo sobre NVIDIA Warp. No es un simulador nuevo: si tu modelo MJCF ya corre en MuJoCo CPU, en principio corre en MJWarp. La diferencia no está en hacer un paso más rápido, sino en avanzar cientos o miles de escenas independientes con una sola llamada a mjw.step, lo que entrega el trabajo paralelo que la GPU necesita para mejorar el throughput agregado.

Ese matiz cambia la métrica relevante para un founder:

Latencia: tiempo de pared para un paso de simulación.
Throughput agregado: total de world-steps completados por segundo medido en wall-clock.

Si tu objetivo es RL o muestreo a gran escala, el throughput pesa más que la latencia de un solo entorno. La transición de API es corta:

MuJoCo CPU	MJWarp sobre GPU
`mujoco.MjModel`	`mjw.put_model(mjm)` crea el modelo en device
`mujoco.MjData`	`mjw.put_data(mjm, mjd, ...)` preserva y batcha el estado inicial
`mujoco.mj_step(mjm, mjd)`	`mjw.step(m, d)` avanza todos los worlds en `d`
Arrays host como `mjd.ctrl`	Arrays batched en device como `d.ctrl` con shape `(nworld, nu)`

A partir de ahí el truco es ajustar cuatro parámetros de capacidad — nworld, nconmax, naconmax, njmax — y capturar el paso en un CUDA Graph para reejecutarlo con el menor overhead posible de dispatch.

Las cuatro puertas críticas del flujo de migración

El walkthrough de NVIDIA en Hugging Face estructura la migración en cuatro gates que conviene respetar en este orden:

Validar un world en CPU. Antes de tocar GPU, confirma que el archivo MJCF representa la tarea. El ejemplo usa un SO-101 apilando dos cubos de 44 mm: el éxito requiere error horizontal xy_err ≤ 0.015 m y separación vertical 0.035 m ≤ dz ≤ 0.055 m entre centros.
Mover a MJWarp con nworld = 1. Subir el modelo, alocar el estado batched, sembrarlo desde el estado inicial del host y comparar los mismos dos números. Esto detecta modelos con features no soportadas antes de escalar.
Subir el batch al tamaño objetivo. En el ejemplo, nworld = 2.048, replicando el estado inicial con np.tile y capturando mjw.step en un CUDA Graph.
Quitar las copias por paso. El loop de validación lleva el estado a host cada substep vía .numpy(). Es un camino de validación, no de benchmark. La versión de producción elimina esas copias para que el data path quede residente en GPU.

Dos detalles prácticos del guide que vale la pena subrayar: los buffers de MJWarp se asignan antes del primer paso, y un desbordamiento de nconmax o njmax invalida el rollout aunque la ejecución continúe con warning. La herramienta mjwarp-testspeed --measure_alloc reporta los contactos y constraints realmente consumidos y aborta si detecta overflow.

¿Qué significa esto para tu startup?

El artículo es un tutorial técnico, pero la lectura estratégica es otra. NVIDIA está construyendo el equivalente físico de lo que CUDA fue para el deep learning: una pila coherente donde el mismo fabricante controla kernels (Warp), física (MJWarp/Newton), entrenamiento (Isaac Lab) e inferencia (Jetson Thor). El Newton Physics Engine GA en abril de 2026, codearrollado con Google DeepMind y Disney Research y administrado por la Linux Foundation según reportó Yahoo Finance/SiliconANGLE, formaliza esa capa intermedia.

Para founders en robotics o IA física la consecuencia práctica es directa:

No entrenes en CPU aunque el equipo sea pequeño. La compresión de costo por entrenamiento de NVIDIA en el caso quirúrgico (de horas a minutos) replica el mismo salto que supusieron las GPUs para el deep learning en 2014. Esperar significa perder la categoría.
Diseña tus assets para que sean portables entre simuladores. MJCF compatible con MuJoCo es hoy el formato más portable. Tu modelo sobrevive al salto CPU → MJWarp → Newton sin reescritura, mientras que atarse a un stack propietario cierra puertas.
Apunta a throughput agregado, no a latencia por entorno. Si vas a hacer RL, el cuello de botella es cuántos world-steps por segundo puedes ejecutar, no cuánto tarda uno solo. Mide y reporta ambos números siempre.
Planifica el desbordamiento de contacts desde el día uno. Los parámetros nconmax, naconmax, njmax no son detalles de implementación: son tu techo de complejidad geométrica. Subirlos cuesta memoria GPU; no dimensionarlos invalida benchmarks y experimentos.

Skild AI, citada por IoT Tech News, ejecuta el modelo S1 sobre infraestructura NVIDIA con un run rate de US$100M diez meses después del lanzamiento comercial y sobre 60 alianzas de despliegue. La misma pila — Isaac Lab entrenando con Newton physics — sirve para research académica y para un producto de fábrica con ingresos de nueve cifras. Esa es la vara con la que tu arquitectura tiene que medirse hoy.