NVIDIA Open-Sources Run:ai GPU Orchestration Platform

Introduction

On October 13, 2026, NVIDIA's technical blog (by Ekin Karabulut and Sam Heywood) announced that the full NVIDIA Run:ai platform is now open source as part of the NVIDIA DSX AI Factory Platform. The source lives in the Run:ai repository inside the NVIDIA DSX AI Factory GitHub organization. The repository is licensed under Apache 2.0 and is written mostly in Go, with TypeScript and Vue. It is a monorepo holding the control plane and cluster services, the installer, a CLI, an MCP server, documentation and a local development environment.

NVIDIA describes the release as an open foundation for AI workload and GPU orchestration on Kubernetes, which partners and customers can adopt whole, build on, or take apart component by component.

Four modular components

The post names four components that can be adopted independently and that, together with additional platform code, form the integrated platform.

KAI Scheduler is released under Apache 2.0 and was contributed to the CNCF as a Sandbox project. NVIDIA says it covers gang scheduling with prescheduling in-memory simulation, fair-share (including time-based) and quota allocation, topology awareness and bin-packing, GPU sharing through MIG, MPS, time sharing, HaMi and CUDA 13.4 MPS fractioning, and Dynamic Resource Allocation support. It can be deployed in an existing cluster without the full platform.

GPU Fractioning Operator brings CUDA 13.4-native fractioning to Kubernetes. According to NVIDIA, the proprietary implementation has been retired in favor of the native capability. The CUDA driver enforces a hard memory limit per workload, the operator is scheduler-agnostic, and a metrics exporter gives per-pod visibility into fractions in use. It integrates with KAI Scheduler but stays compatible with other schedulers.

KAI Resource Management adds the organizational layer: projects and departments, hierarchical allocation with fair-share and quota semantics, and node pools for heterogeneous hardware. NVIDIA's example is guaranteeing 50% of a cluster to research while preventing any single team from monopolizing the rest.

Workload Map is the contract Run:ai uses to treat workload types such as PyTorchJob, RayCluster, JobSet, KServe InferenceService and Dynamo graph deployments consistently. It ships as a Go library that works offline on unstructured objects, so nothing needs to be added to a cluster. NVIDIA says it is deliberately narrow and does not schedule, queue, autoscale or propagate across clusters.

How to get it

Teams can use the source directly, or install the integrated stack from NVIDIA NGC as a Community Product with a Helm chart. NGC download requires accepting the NVIDIA Software License Agreement and product-specific terms. No paid Run:ai subscription is required, but NVIDIA enterprise support is not included. Commercial offerings continue as a standalone product, through NVIDIA Mission Control and NVIDIA AI Enterprise, and on select cloud marketplaces, with terms varying by offering.

Eight DSX ecosystem partners are integrating it: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud and vCluster.

Usability

The README describes two installed pieces: a control plane that handles workload submission, organizational resources and monitoring across one or more clusters, and per-cluster services that extend Kubernetes scheduling with GPU-aware capabilities. Users work through a web UI, CLI or REST API, and the repository also includes an MCP server that exposes Run:ai operations as tools for AI assistants.

For evaluation, a local-dev.sh script builds the control plane and cluster services from source and deploys them to a self-contained Kind cluster; Go, Node and Java are not needed on the host because builds run inside containers. Production installs can use the runai-installer CLI, which runs preflight checks, or the Helm charts directly for teams managing deployments through tools such as Argo CD. Kubernetes and OpenShift are supported, in connected or air-gapped environments.

The README is also direct about fit. Run:ai sits on top of Kubernetes rather than replacing it, and is aimed at GPU sharing, quota enforcement and multi-tenant governance across teams. If a single team runs jobs on dedicated GPUs, it says native Kubernetes scheduling may be sufficient.

Related projects, briefly

The post also points to two complementary projects. Model Streamer, which loads weights concurrently into GPU memory, is integrated upstream in vLLM and SGLang through --load-format runai_streamer; the figures in the post, such as a 3x-6x faster load on eight H100 VMs in an Azure-published benchmark, and storage-vendor timings from WEKA, VAST Data and DDN, are vendor-reported. Grove, part of NVIDIA Dynamo, provides hierarchical gang scheduling for multicomponent inference.

Outlook

Opening the full platform, rather than only the scheduler, changes who can build on it. The eight launch partners span managed Kubernetes, AI cloud and multi-tenancy vendors, and NVIDIA positions the release as a way for DSX ecosystem partners to ship their own GPU orchestration offerings faster. Because KAI Scheduler development already happens in a CNCF Sandbox repository, contributors outside NVIDIA have a path to influence the core engine. How actively that community forms, and how releases are cut and supported over time, will matter more than the launch announcement.

Assessment

For platform teams running shared GPU clusters, the modular design is the practical draw: KAI Scheduler or Workload Map can be adopted without taking the whole stack. The caveats are that the NGC route carries license terms and no enterprise support, and that the post states throughput and utilization benefits without presenting measurements. Teams should evaluate the components against their own clusters.

Editor's Verdict

NVIDIA Open-Sources Run:ai GPU Orchestration Platform earns a solid recommendation within the open source space.

The strongest case for paying attention is that the modular components can be adopted independently of the full platform. Reinforcing that, Apache 2.0 source code and a CNCF Sandbox scheduler give teams inspectable, community-governed code. The broader signal worth registering is straightforward: four independently adoptable modules let teams fill one gap, such as quota management, without replacing their whole scheduling stack. On the other side of the ledger, enterprise support is not included with the NGC Community Product, so production users must rely on the community or a commercial offering. Layered on top of that, the native fractioning path depends on CUDA 13.4, which limits it to environments that can run that version.

For platform teams and AI cloud operators running shared Kubernetes GPU clusters across multiple teams, this is a serious evaluation candidate, not just a curiosity to bookmark. For a single team running jobs on dedicated GPUs, native Kubernetes scheduling may be sufficient, as the project's own README notes.