OSMO de código abierto de NVIDIA: One YAML organiza entrenamiento de IA física, simulación y pruebas de robots

Los desarrolladores de robots no tienen ningún problema de computación. Tienen 3. Una política se entrena en clústeres GB200 o H100, se prueba en Isaac Sim en GPU RTX y luego se valida en un Jetson montado dentro de un robot real. Cada nivel tiene su propio clúster, su propio programador y sus propios scripts de pegamento. NVIDIA OSMO es la respuesta de NVIDIA a esa fragmentación: un orquestador de flujo de trabajo nativo de Kubernetes y de código abierto que permite a un equipo describir todo el proceso en un único archivo YAML y ejecutarlo en todos los niveles sin tocar el código de infraestructura.

¿Implementable? Sí. OSMO tiene licencia Apache-2.0, envía gráficos Helm y contenedores en NGC y tiene un inicio rápido local que ejecuta el plano de control total en una estación de trabajo con KIND.

El problema de las tres computadoras

NVIDIA enmarca la IA física como un problema de tres computadoras. La capacitación se realiza en GPU de centros de datos. La simulación, la física y la representación de sensores se realizan en hardware RTX de clase de estación de trabajo. La implementación y las pruebas de hardware-in-the-loop (HIL) se realizan en dispositivos periféricos como Jetson AGX Thor, generalmente en las instalaciones. Cada nivel generalmente tiene sus propias herramientas y las transferencias son donde se acumulan los scripts personalizados.

OSMO trata los 3 como servidores de un plano de control. Cada backend es un clúster de Kubernetes registrado a través de la CLI. Los flujos de trabajo nunca nombran un clúster. Nombran una plataforma (por ejemplo, gb200, rtx-pro-6000 o jetson-agx-thor) y OSMO dirige la tarea a un grupo que la ofrece.

Cómo se ve un flujo de trabajo

El ejemplo canónico del repositorio son 3 tareas encadenadas por datos: A

la simulación ejecuta un contenedor Isaac Sim en rtx-pro-6000 train-policy ejecuta un contenedor PyTorch en gb200 con 8 GPU, tomando el resultado de la tarea de simulación como entrada

Las dependencias provienen de las entradas, la persistencia de las salidas y la ubicación de la plataforma. La guía del usuario cubre grupos de tareas en serie y paralelos, plantillas de Jinja para flujos de trabajo parametrizados, políticas de reintento y prioridades ALTAS/NORMALES/BAJAS con preferencia y préstamo de GPU en todos los grupos.

Capacidades clave

Portabilidad: el mismo YAML se ejecuta en una computadora portátil (Docker/KIND) o en clústeres EKS, AKS, GKE, locales o aislados. La versión 6.3.0 agregó un implementación-k8s.sh de múltiples proveedores que aprovisiona OSMO en Azure AKS, AWS EKS, microk8s o cualquier clúster existente, con cableado de almacenamiento para MinIO, Azure Blob, AWS S3 o trae tu propio S3. Desarrollo interactivo: los desarrolladores pueden iniciar sesiones de VS Code, Jupyter o SSH en un nodo de GPU remoto, ejecutar tareas en ejecución, servicios de reenvío de puertos y archivos rsync en ambas direcciones. La versión 6.3.0 agregó la descarga de rsync del flujo de trabajo de Osmo con una barra de progreso en vivo. Programación: OSMO utiliza el Programador NVIDIA KAI de forma predeterminada. La versión 6.2.8 agregó la ubicación de NVLink con reconocimiento de topología para tareas de múltiples GPU. La versión 6.3.0 creó exec_timeout y queue_timeout por grupo, por lo que un grupo de simulación estancado ya no mata a los grupos de entrenamiento hermanos. Datos: el proyecto describe conjuntos de datos direccionables por contenido con deduplicación que, según afirma, puede reducir el almacenamiento entre 10 y 100 veces. Tenga en cuenta que la CLI independiente del conjunto de datos de osmo y la API /datasets quedaron obsoletas en 6.3.0 y están programadas para su eliminación en 6.4, con salidas de conjuntos de datos administrados por flujo de trabajo como reemplazo. Seguridad e identidad: desde 6.2.8, OSMO incluye un complemento de autorización RBAC, integración de proxy OAuth2 con inicio de sesión con código de dispositivo y mapeo de usuarios del proveedor de identidad. La versión 6.3.0 agregó la terminación TLS en la puerta de enlace de Envoy y la identidad de la carga de trabajo en la nube (Azure Workload Identity, AWS IRSA/Pod Identity), por lo que los servicios ya no montan claves de almacenamiento como secretos de Kubernetes. La versión 6.3.1 reforzó la función de usuario de osmo predeterminada al grupo predeterminado. Integración de agentes: el repositorio incluye AGENTS.md, un directorio de habilidades y una guía de implementación de MCP. En GTC 2026, NVIDIA dijo que OSMO se integra con Claude Code, OpenAI Codex y Cursor para que los agentes de codificación puedan enviar, monitorear y depurar canalizaciones.

Explicación interactiva: vea el flujo de trabajo de OSMO Route One en 3 niveles de computación

Presione Ejecutar flujo de trabajo para ver cómo OSMO programa el ejemplo README tarea por tarea. Haga clic en cualquier nivel o número de paso para inspeccionar lo que sucede allí.