Por Canuto  

NVIDIA liberó OSMO, un orquestador de flujos de trabajo de código abierto que permite coordinar entrenamiento, simulación y pruebas de robots mediante un solo archivo YAML en clústeres Kubernetes heterogéneos.
***

  • OSMO conecta centros de datos con GPUs GB200 o H100, estaciones RTX y dispositivos Jetson para pruebas de hardware en el circuito.
  • La plataforma usa Kubernetes y el NVIDIA KAI Scheduler, con soporte para NVLink, prioridades, reintentos, RBAC y almacenamiento en la nube.
  • La versión 6.3.0 obsoletó la CLI independiente de conjuntos de datos, mientras que la 6.3.1 restringió el rol predeterminado osmo-user.

NVIDIA presentó OSMO como una respuesta a la fragmentación que enfrentan los equipos dedicados a la robótica y la inteligencia artificial física. El proyecto es un orquestador de flujos de trabajo de código abierto, basado en Kubernetes, que permite describir en un único archivo YAML las etapas de entrenamiento, simulación y validación de un robot, sin exigir que los desarrolladores reescriban la infraestructura cada vez que cambia el entorno de cómputo.

La propuesta parte de una dificultad concreta: una política robótica puede entrenarse en un clúster con GPUs GB200 o H100, probarse después en Isaac Sim sobre hardware RTX y finalmente validarse en un dispositivo Jetson instalado dentro de un robot real. MarkTechPost reportó que OSMO busca convertir esos tres niveles en backends de un mismo plano de control, con una ruta común para mover datos, políticas y resultados entre centros de datos, estaciones de trabajo y sistemas de borde.

Un plano de control para tres entornos

NVIDIA describe la IA física como un problema de tres computadoras, aunque cada una representa en realidad una clase distinta de infraestructura. El entrenamiento necesita GPUs de centro de datos y grandes volúmenes de datos, la simulación combina física y renderizado de sensores en equipos RTX, y las pruebas de hardware en el circuito, conocidas como HIL, se ejecutan normalmente en dispositivos instalados en las propias instalaciones.

En los modelos tradicionales, cada entorno suele tener su propio clúster, planificador y conjunto de scripts de integración. Las transiciones entre entrenamiento, simulación y robot físico concentran buena parte del trabajo manual, porque los equipos deben mantener herramientas diferentes y resolver de forma particular la transferencia de archivos, las dependencias y los permisos.

OSMO trata esos entornos como clústeres de Kubernetes registrados mediante su interfaz de línea de comandos. Los flujos no necesitan nombrar directamente un clúster específico, sino una plataforma, como gb200, rtx-pro-6000 o jetson-agx-thor; el sistema encuentra entonces un grupo que ofrece esa capacidad y enruta la tarea correspondiente.

Ese diseño separa la descripción del experimento de la infraestructura que lo ejecuta. En principio, el mismo flujo puede trasladarse desde una estación de trabajo local hacia un despliegue en la nube, en las instalaciones o en un entorno aislado, aunque su funcionamiento seguirá dependiendo de que existan los recursos, contenedores, permisos y almacenamiento necesarios.

El flujo que conecta simulación y entrenamiento

El ejemplo central del repositorio organiza tres tareas encadenadas por datos. La primera ejecuta un contenedor de Isaac Sim en una plataforma rtx-pro-6000, la segunda lanza un contenedor de PyTorch en una plataforma gb200 con ocho GPUs y recibe como entrada la salida generada por la simulación.

La tercera etapa ejecuta una aplicación ROS en jetson-agx-thor, consume la política entrenada y escribe los resultados en un conjunto de datos con nombre. Las dependencias se expresan mediante los campos de entrada, las salidas persistentes y la plataforma seleccionada, de modo que el archivo YAML funciona como una declaración del proceso completo.

La documentación también contempla grupos de tareas en serie y en paralelo, plantillas Jinja para parametrizar flujos, políticas de reintento y prioridades HIGH, NORMAL y LOW. Estas prioridades permiten apropiación y préstamo de GPUs entre grupos, una característica destinada a administrar recursos compartidos cuando simulaciones, entrenamientos y evaluaciones compiten por el mismo clúster.

La portabilidad se extiende desde Docker y KIND en un computador local hasta clústeres EKS, AKS, GKE, despliegues en las instalaciones y redes sin conexión externa. Según la información publicada, la versión 6.3.0 incorporó un script deploy-k8s.sh para aprovisionar OSMO en Azure AKS, AWS EKS, microk8s o un clúster existente, con opciones de almacenamiento para MinIO, Azure Blob, AWS S3 y servicios compatibles con S3.

Planificación, desarrollo y almacenamiento

OSMO utiliza de forma predeterminada NVIDIA KAI Scheduler para asignar trabajos y administrar los recursos disponibles. La versión 6.2.8 agregó colocación consciente de la topología NVLink para tareas que usan varias GPUs, una función relevante porque la distancia entre aceleradores y el ancho de banda entre ellos pueden afectar el rendimiento de los entrenamientos distribuidos.

La versión 6.3.0 también hizo que exec_timeout y queue_timeout se aplicaran por grupo. Con ese cambio, un grupo de simulación detenido no debería terminar automáticamente con los grupos de entrenamiento hermanos, lo que permite aislar fallas o demoras dentro de un flujo que contiene varias etapas independientes.

Para el trabajo interactivo, los desarrolladores pueden iniciar sesiones de VS Code, Jupyter o SSH en un nodo remoto con GPU, ejecutar comandos dentro de tareas activas y publicar servicios mediante port-forward. La plataforma también permite sincronizar archivos en ambas direcciones mediante rsync, y la versión 6.3.0 añadió una descarga con barra de progreso en vivo a través de osmo workflow rsync download.

El proyecto describe conjuntos de datos direccionables por contenido y con deduplicación, una combinación que, según sus propias afirmaciones, podría reducir el almacenamiento entre 10 y 100 veces. Sin embargo, existe un cambio importante para quienes ya utilizan la plataforma: la CLI independiente osmo dataset y la API /datasets quedaron obsoletas en la versión 6.3.0 y están previstas para eliminarse en la 6.4, mientras las salidas de conjuntos de datos pasan a gestionarse mediante flujos de trabajo.

Seguridad, agentes y estado del proyecto

En materia de identidad, OSMO incorporó desde la versión 6.2.8 un sidecar de autorización RBAC, integración con un proxy OAuth2 mediante inicio de sesión por código de dispositivo y mapeo de usuarios procedentes de proveedores de identidad. La versión 6.3.0 sumó terminación TLS en la puerta de enlace Envoy e identidad de carga de trabajo para la nube, con Azure Workload Identity, AWS IRSA y Pod Identity.

Estas integraciones buscan evitar que los servicios monten directamente claves de almacenamiento como secretos de Kubernetes. En la versión 6.3.1, el rol predeterminado osmo-user quedó restringido al grupo predeterminado, un ajuste que apunta a limitar el alcance de los permisos iniciales en instalaciones con varios equipos o usuarios.

El repositorio incluye un archivo AGENTS.md, un directorio de habilidades y una guía para despliegues MCP. NVIDIA afirmó durante GTC 2026 que OSMO se integra con Claude Code, OpenAI Codex y Cursor, permitiendo que agentes de programación envíen, supervisen y depuren pipelines de entrenamiento, simulación y evaluación.

La plataforma se distribuye bajo la licencia Apache-2.0, incluye gráficos de Helm y contenedores en NGC, y ofrece una guía de inicio rápido local que ejecuta el plano de control completo con KIND. La versión más reciente señalada en la información disponible es la 6.3.1, publicada en junio de 2026, y el proyecto menciona pruebas o integraciones con GR00T, Isaac Lab, Isaac Sim, Isaac ROS, Azure y Nebius.

El atractivo de OSMO está en reducir la cantidad de infraestructura específica que acompaña cada experimento robótico, pero su adopción no elimina la complejidad física de los sistemas que coordina. Los equipos todavía deben garantizar que sus contenedores, modelos, datos, aceleradores y dispositivos de borde sean compatibles, especialmente cuando el flujo abandona el laboratorio y llega a un robot real.

La decisión de centralizar el proceso en YAML puede facilitar la repetición de experimentos y hacer más visible la relación entre simulación, entrenamiento y pruebas HIL. Al mismo tiempo, la obsolescencia de la interfaz independiente de conjuntos de datos obliga a planificar migraciones antes de la versión 6.4, un detalle que puede pesar tanto como las nuevas funciones de automatización.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados