# NVIDIA OSMO: Orchestrating Physical AI Workflows Across Training, Simulation, and Edge Infrastructure
## The Fragmentation Problem in Robot Development
Building physical AI systems demands compute resources spread across dramatically different hardware tiers. A typical robot development pipeline involves training neural network policies on massive data-center GPU clusters, running high-fidelity simulations and physics rendering on workstation-class hardware, and finally validating those policies on edge devices physically attached to a robot. Each of these stages traditionally requires its own infrastructure stack, its own job scheduler, and its own set of custom scripting to move data between them. The result is a fragmented development experience where engineering teams spend significant time managing plumbing rather than building models.
NVIDIA frames this challenge as the “three computer problem.” Training workloads run on data-center accelerators like the GB200 or H100. Simulation and sensor rendering workloads run on RTX-class workstation GPUs such as the RTX PRO 6000. Deployment and hardware-in-the-loop testing happens on edge compute platforms like the Jetson AGX Thor, often running on local on-premises infrastructure. The handoff points between these tiers are where complexity compounds, as developers must write custom glue scripts to pass simulation outputs into training pipelines, and then feed trained policies into edge-side evaluation frameworks.
## What Is NVIDIA OSMO?
OSMO is an open-source workflow orchestration platform designed to unify these three compute tiers under a single control plane. Built to be Kubernetes-native, it allows development teams to describe their entire physical AI pipeline in a single declarative YAML file and execute it across every infrastructure tier without needing to write infrastructure-specific code. The project is released under the Apache 2.0 license and ships Helm charts and container images through NVIDIA’s NGC registry, making it immediately accessible for teams already working within the NVIDIA ecosystem.
At its core, OSMO treats every compute tier as a backend managed by the same orchestration layer. Rather than requiring users to specify which cluster to run a job on, workflows declare a target platform — such as `gb200`, `rtx-pro-6000`, or `jetson-agx-thor` — and the orchestrator automatically routes tasks to an available pool that offers that platform. This abstraction means the same pipeline definition can run on a developer’s laptop, a cloud-based Kubernetes cluster, or a localized on-premises setup with minimal or no modification.
## How a Workflow Is Structured
A typical OSMO workflow chains multiple tasks together based on data dependencies. Consider a common physical AI pipeline with three stages. The first task launches an Isaac Sim container on an RTX PRO 6000 platform to generate simulated sensor data and physics interactions. The second task takes that simulation output and trains a reinforcement learning policy using a PyTorch container on a GB200 cluster with eight GPUs. The third task deploys the trained policy to a ROS application running on a Jetson AGX Thor device, where it undergoes hardware-in-the-loop validation and writes benchmark results to a persistent dataset.
Dependencies between tasks are declared through `inputs` and `outputs` fields. A task with no declared inputs can begin immediately, while downstream tasks automatically wait for their upstream dependencies to complete. Placement is determined by the `platform` field, ensuring each container lands on infrastructure that matches its resource requirements. The platform supports both serial and parallel task groups, parameterized workflows through Jinja templating, configurable retry policies, and a priority system with preemption capabilities and GPU sharing across resource pools.
## Key Capabilities of the Platform
### Portability Across Environments
The same workflow definition can execute on a single workstation running Docker with KIND (Kubernetes in Docker), or scale to enterprise-grade clusters on Amazon EKS, Azure AKS, Google GKE, or bare-metal deployments. Version 6.3.0 introduced a multi-provider deployment script that provisions the full control plane on Azure AKS, AWS EKS, microk8s, or any pre-existing Kubernetes cluster, with flexible storage wiring for MinIO, Azure Blob Storage, AWS S3, or user-provided S3-compatible object stores. This means teams can develop locally and promote the identical pipeline to production cloud or on-premises infrastructure.
### Interactive Development Experience
Developers working with OSMO can launch interactive sessions directly on remote GPU nodes. The platform supports VS Code, Jupyter notebooks, and SSH sessions on running compute nodes. Users can execute commands inside active tasks, forward ports for debugging web interfaces, and synchronize files bidirectionally between local workstations and remote clusters. A recent enhancement added a download command with a live progress bar, making it straightforward to retrieve artifacts from completed or running tasks.
### Advanced Scheduling and Resource Management
OSMO leverages the NVIDIA KAI Scheduler as its default scheduling engine. A recent update introduced NVLink topology-aware placement, which ensures multi-GPU tasks are scheduled on nodes with optimal interconnect configurations for maximum bandwidth. The platform now also supports per-task-group timeout policies, meaning a simulation group that stalls or hangs will not inadvertently terminate sibling training groups sharing the same execution window. This isolation prevents cascading failures across pipeline stages.
### Data Management and Deduplication
The platform describes content-addressable datasets with built-in deduplication capabilities. According to internal benchmarks, this approach can reduce storage consumption by a factor of 10 to 100 times compared to traditional file-based data management. It is worth noting that the standalone dataset command-line interface and its associated API endpoints have been deprecated as of version 6.3.0 and are scheduled for removal in version 6.4. The recommended path forward is to manage dataset outputs directly through workflow definitions, which provides tighter integration between pipeline execution and data persistence.
### Security and Identity Management
Starting with version 6.2.8, OSMO includes an RBAC authorization sidecar, OAuth2 proxy integration with device-code-based authentication, and identity provider user mapping. Version 6.3.0 added TLS termination at the Envoy ingress gateway and cloud workload identity support, including Azure Workload Identity and AWS IAM Roles for Service Accounts. This eliminates the need to mount cloud storage credentials as Kubernetes Secrets, significantly reducing the attack surface. A subsequent patch tightened the default user role to restrict access to the default resource pool unless explicitly granted broader permissions.
### Coding Agent Integration
The repository ships with an AGENTS.md file, a skills directory, and a dedicated deployment guide for Model Context Protocol (MCP) integration. At a recent industry event, NVIDIA demonstrated OSMO’s compatibility with Claude Code, OpenAI Codex, and Cursor, enabling coding agents to submit workflows, monitor execution status, and debug pipeline failures through natural-language interactions. This integration positions OSMO as a platform that can be driven programmatically by AI-assisted development tools.
## Deployment Options
OSMO is designed to scale from a single developer’s machine to enterprise infrastructure. For local development, a single Helm chart deploys the complete control plane on a workstation using KIND, providing a friction-free way to prototype workflows before moving to production environments. In cloud settings, the deploy script provisions OSMO on major Kubernetes services with minimal configuration. For edge and air-gapped scenarios, on-premises clusters register as backends in the control plane, and Jetson devices execute hardware-in-the-loop tasks directly on the factory floor or laboratory.
## Real-World Validation
The platform has been tested extensively against NVIDIA’s flagship robotics frameworks including GR00T, Isaac Lab, Isaac Sim, and Isaac ROS. It also integrates with Azure cloud services and Nebius, NVIDIA’s cloud platform for AI infrastructure. These integrations confirm that OSMO is designed not as a theoretical prototype but as a practical tool for production robotics workflows.
## Frequently Asked Questions
**What hardware platforms does OSMO support?**
OSMO supports NVIDIA’s full spectrum of AI hardware, including data-center GPUs like the GB200 and H100 for training, workstation GPUs like the RTX PRO 6000 and L40 for simulation, and edge devices like the Jetson AGX Thor for deployment and hardware-in-the-loop testing. Any Kubernetes-compatible infrastructure can serve as a backend, provided the appropriate node labels and resource pools are configured.
**Is OSMO free to use?**
Yes. OSMO is released under the Apache 2.0 open-source license, meaning it can be used, modified, and distributed without licensing fees. Helm charts and container images are available on NVIDIA’s NGC registry at no cost, though users are responsible for their own cloud or hardware infrastructure expenses.
**Can OSMO run outside of NVIDIA’s ecosystem?**
While OSMO is built around NVIDIA hardware and software stacks, its Kubernetes-native architecture means it can technically run on any Kubernetes cluster. However, its full feature set — including KAI Scheduler integration, NVLink-aware placement, and the NVIDIA container ecosystem — is optimized for NVIDIA infrastructure.
**What happened to the standalone dataset CLI?**
The `osmo dataset` command-line tool and its associated API endpoints were deprecated in version 6.3.0 and will be removed in version 6.4. Users are encouraged to migrate to workflow-managed dataset outputs, where datasets are defined and produced directly within YAML workflow definitions.
**Does OSMO support CI/CD integration?**
Yes. Because workflows are declared as YAML files, they can be version-controlled in Git repositories and triggered through standard CI/CD pipelines. The platform’s CLI and API expose all necessary operations for automated execution, monitoring, and result retrieval.
**What security features are built in?**
OSMO includes role-based access control, OAuth2 authentication with device-code login, TLS termination at the gateway layer, cloud workload identity federation, and identity-provider user mapping. The default user role has been tightened to limit access to the default pool unless explicitly expanded.
## Conclusion
NVIDIA OSMO addresses one of the most persistent friction points in physical AI development: the gap between training, simulation, and deployment infrastructure. By abstracting away cluster-specific details and letting teams define their entire pipeline in a single YAML file, it dramatically reduces the custom scripting and infrastructure management that typically consume engineering hours. Its open-source licensing, local development support, and cloud-to-edge portability make it a practical choice for teams building robotics and embodied AI systems at any scale. As the platform continues to evolve with tighter agent integration and improved scheduling intelligence, it is positioned to become a foundational layer in the physical AI tooling ecosystem.
Thank you for reading
