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

Robot teams usually end up with three separate worlds. Training runs on big GPU clusters like GB200 or H100. Simulation happens on RTX machines in Isaac Sim. Then the whole thing gets pushed into a real robot, often through a Jetson at the edge. That handoff is where the glue scripts breed.

OSMO is NVIDIA’s attempt to make that mess behave. It’s an open-source, Kubernetes-native workflow orchestrator under Apache-2.0, with Helm charts and containers on NGC, plus a local quickstart that runs the control plane on a workstation with KIND. The pitch is simple: describe the whole physical AI pipeline in one YAML file, then let OSMO route each step to the right compute pool.

The workflow model is built around platforms, not fixed clusters. A task can ask for gb200, rtx-pro-6000, or jetson-agx-thor, and OSMO sends it to whatever registered backend offers that platform. NVIDIA’s canonical example chains three steps together: simulate in Isaac Sim on rtx-pro-6000, train a PyTorch policy on gb200 with 8 GPUs, then run evaluate-thor on jetson-agx-thor and write results to a named dataset.

OSMO is trying to cover the rest of the workflow headache too. The user guide includes serial and parallel task groups, Jinja templating, retry policies, and HIGH/NORMAL/LOW priorities with preemption and GPU borrowing across pools. Version 6.3.0 added a multi-provider deploy-k8s.sh for AKS, EKS, microk8s, or an existing cluster, with storage wiring for MinIO, Azure Blob, AWS S3, or bring-your-own S3.

There’s also a lot for operators, not just experimenters. OSMO uses the NVIDIA KAI Scheduler by default, added NVLink topology-aware placement in 6.2.8, and made exec_timeout and queue_timeout per group in 6.3.0 so one stalled simulation group won’t sink a sibling training group. Security got the usual enterprise treatment too: RBAC, OAuth2 proxy integration, device-code login, TLS termination at Envoy, and cloud workload identity support so services do not need to mount storage keys as Kubernetes Secrets.