NVIDIA Open-Sources OSMO: One YAML Orchestrates Physical AI Training, Simulation, and Robot Testing

Nvidia has released OSMO, an open-source tool that lets developers run physical AI workflows across three different computing environments using a single configuration file. The project targets the fragmentation where teams maintain separate schedulers and scripts for data centre GPUs, workstation simulations, and edge robots. OSMO is licensed under Apache-2.0 and ships with Helm charts on the NGC catalog. A local quickstart guide allows the full control plane to run on a workstation using KIND.

The Three Computer Problem

Nvidia describes robotics as a three computer problem. Training occurs on data centre GPUs. Simulation, physics, and sensor rendering happen on workstation-class RTX hardware. Deployment and hardware-in-the-loop testing happen on edge devices like Jetson AGX Thor. Each tier usually requires its own tooling, and the handoffs between them accumulate custom scripts.

OSMO treats all three as backends for one control plane. Developers register each backend as a Kubernetes cluster via the command line. Workflows do not name a specific cluster. They name a platform, such as gb200, rtx-pro-6000, or jetson-agx-thor, and OSMO routes the task to a pool that offers it.

What a Workflow Looks Like

The repository’s canonical example chains three tasks by data.

• simulation runs an Isaac Sim container on rtx-pro-6000
• train-policy runs a PyTorch container on gb200 with 8 GPUs, taking the simulation task’s output as input
• evaluate-thor runs a ROS app on jetson-agx-thor, consuming the trained policy and writing results to a named dataset

Dependencies come from inputs, persistence from outputs, and placement from platform. The user guide covers serial and parallel task groups, Jinja templating for parameterised workflows, retry policies, and HIGH/NORMAL/LOW priorities with preemption and GPU borrowing across pools.

Key Capabilities

• Portability: The same YAML runs on a laptop with Docker and KIND, or on EKS, AKS, GKE, on-premise, or air-gapped clusters. Release 6.3.0 added a multi-provider deploy-k8s.sh that provisions OSMO on Azure AKS, AWS EKS, microk8s, or any existing cluster. Storage wiring supports MinIO, Azure Blob, AWS S3, or bring-your-own S3.
• Interactive development: Developers can launch VS Code, Jupyter, or SSH sessions on a remote GPU node. They can exec into running tasks, port-forward services, and rsync files in both directions. Version 6.3.0 added osmo workflow rsync download with a live progress bar.
• Scheduling: OSMO uses the Nvidia KAI Scheduler by default. Release 6.2.8 added NVLink topology-aware placement for multi-GPU tasks. Release 6.3.0 made exec_timeout and queue_timeout per group, so a stalled simulation group no longer kills sibling training groups.
• Data: The project describes content-addressable datasets with deduplication. Nvidia claims this can cut storage by 10 to 100x. Note that the standalone osmo dataset CLI and /datasets API were deprecated in 6.3.0 and are slated for removal in 6.4, with workflow-managed dataset outputs as the replacement.
• Security and identity: Since 6.2.8 OSMO ships an RBAC authorisation sidecar, OAuth2 proxy integration with device-code login, and identity-provider user mapping. Release 6.3.0 added TLS termination at the Envoy gateway and cloud workload identity. This allows services to avoid mounting storage keys as Kubernetes Secrets. Release 6.3.1 tightened the default osmo-user role to the default pool.
• Agent integration: The repository ships an AGENTS.md, a skills directory, and an MCP deployment guide. At GTC 2026 Nvidia said OSMO integrates with Claude Code, OpenAI Codex, and Cursor so coding agents can submit, monitor, and debug pipelines.

Interactive Explainer

Press Run workflow to see how OSMO schedules the README example task by task. Click any tier or step number to inspect what happens there.

What it means

Robotics teams previously had to maintain separate pipelines for training, simulating, and testing on hardware. OSMO removes the need to write glue code to move data between these environments. A developer defines the logic once and the system handles the routing. This reduces the engineering overhead required to move a model from a data centre cluster to a real robot.