NVIDIA is open-sourcing OSMO, a Kubernetes-native workflow orchestrator designed to run physical-AI work across data-centre GPUs, workstation hardware and robots. The useful idea is simple: describe the whole journey in one YAML workflow, then let OSMO route each task to the platform that can handle it.
NVIDIA Watch analysis
What happened
The system targets a familiar robotics headache. A policy may be trained on powerful data-centre GPUs, tested in simulation on workstation hardware, then validated on an edge computer mounted inside a robot. NVIDIA’s OSMO treats those environments as backends of one control plane rather than three separate projects stitched together with bespoke scripts.
The MarkTechPost report says workflows can name a platform such as GB200, RTX Pro 6000 or Jetson AGX Thor instead of hard-coding a particular cluster. Its example runs an Isaac Sim task, feeds the result into policy training, then sends the trained policy to a ROS-based evaluation task on Jetson hardware.
Key findings
- One YAML pipeline
A single workflow can connect simulation, training and hardware-in-the-loop evaluation across different compute tiers. - Platform-aware scheduling
Tasks target capabilities such as GB200, RTX Pro 6000 or Jetson AGX Thor, allowing OSMO to select a suitable registered cluster. - Portable deployment
The report says OSMO can run locally with Docker and KIND or across EKS, AKS, GKE, on-premises and air-gapped clusters. - Useful developer access
VS Code, Jupyter and SSH sessions can be launched on remote GPU nodes, with task access and file synchronisation for interactive work. - Operational guardrails
Reported features include retries, priorities, GPU borrowing, per-group timeouts, RBAC and OAuth2 proxy integration. - A migration wrinkle
The standalone dataset CLI and datasets API are deprecated in the 6.3 series and reported as due for removal in 6.4.
Why it matters
Physical AI has an awkward habit of making every stage speak a different infrastructure dialect. OSMO’s pitch is that teams should be able to move from simulated sensor data to a trained policy and then to a real robot without rebuilding the orchestration layer at every step.
That does not make the underlying hardware, scheduling or safety problems disappear. It does make the hand-offs explicit and reproducible, which is precisely where robotics projects often accumulate fragile glue code. For developers, the practical takeaway is that OSMO is worth examining if a project already spans NVIDIA training hardware, Isaac Sim and Jetson-based testing.
Our read
This is infrastructure news with unusually clear practical value. NVIDIA is trying to make physical-AI development look more like a portable pipeline and less like a relay race between incompatible clusters. The interesting test will be whether the YAML abstraction survives real-world workloads, especially when capacity, data movement and hardware quirks enter the room.
Treat the dataset deprecation as an early migration note, not a footnote. Anyone evaluating OSMO should start with the workflow-managed dataset path and verify the current release documentation before building around the older CLI.
What to watch
- Whether OSMO gains support beyond NVIDIA-heavy physical-AI stacks.
- How much overhead the multi-cluster control plane adds to real training and simulation runs.
- Evidence from independent users on portability, scheduling and hardware-in-the-loop reliability.
- The replacement path for the deprecated dataset CLI before the reported 6.4 removal.
Discussion spark: Does a single workflow layer genuinely make physical-AI development more portable, or does it mainly standardise an NVIDIA-shaped stack?
Sources and evidence
- NVIDIA Open-Sources OSMO: One YAML Orchestrates Physical AI Training, Simulation, and Robot Testing – MarkTechPost (14 September 2026, 08:04 UTC)
Independent WittyWires tracker for public updates about NVIDIA. Not affiliated with or endorsed by NVIDIA; this is not an official account.