NVIDIA Open-Sources Run:ai Under Apache 2.0

NVIDIA has released the full Run:ai platform as open source under the Apache 2.0 license, putting production GPU scheduling, quotas and workload management in developers' hands without a paid subscription. The code, published on GitHub, makes Run:ai part of the NVIDIA DSX AI Factory platform. Platform teams can now inspect, fork and self-host the entire stack.

The release matters because GPU orchestration has become a cost bottleneck for AI infrastructure teams. Clusters running training and inference workloads sit idle without schedulers that share accelerators across teams, and NVIDIA just removed the price tag from one of the main commercial options.

What Ships in the Release?

The repository is a monorepo containing the control plane, cluster services, installer, CLI and an MCP server for AI assistants. Local development builds about 50 Go services. The platform runs on Kubernetes or OpenShift clusters with NVIDIA GPUs, and local development runs on macOS or Linux with 8 simulated Tesla-A10 GPUs — no GPU hardware required.

NVIDIA published no platform-level benchmark for the release. The strongest performance figure attached to the ecosystem comes from the related Model Streamer project, which loaded models 3x to 6x faster on 8 NVIDIA H100 VMs on Azure.

The free community edition excludes NVIDIA enterprise support. Local builds need 16 GB RAM and 100 GB disk on Linux.

What Are the Four Modular Components?

NVIDIA split the release into four components that teams can adopt independently:

• KAI Scheduler — the Kubernetes-native scheduling engine, Apache 2.0 licensed and a CNCF Sandbox project. It covers gang scheduling, time-based fair-share, topology awareness, bin-packing and DRA support.
• GPU Fractioning Operator — brings CUDA 13.4-native GPU fractions to Kubernetes. The CUDA driver enforces a hard memory limit per workload. NVIDIA retired its older proprietary fractioning in favor of this approach. The operator is scheduler-agnostic and exports per-pod metrics.
• KAI Resource Management — adds projects, departments, quotas and node pools. NVIDIA's example guarantees 50% of a cluster to a research team.
• Workload Map — a Go library that describes workload types such as PyTorchJob, RayCluster and KServe services. It works offline and does not schedule, queue or autoscale.

The four-way split lets a team adopt the KAI Scheduler alone without the control plane, or take the full platform. Each component carries its own repository under the DSX AI Factory organization.

How Do Developers Run It Locally?

The local development guide stands on one script, local-dev.sh. It builds about 50 Go services from source inside containers, then creates a 5-node Kind cluster pinned to Kubernetes v1.32.5. A fake GPU operator simulates 8 Tesla-A10 GPUs.

The hardware requirements are modest for an AI infrastructure project:

• Supported hosts: macOS or Linux, on amd64 or arm64. Windows is not supported.
• Linux hosts need 4 CPUs, 16 GB RAM and 100 GB free disk.
• macOS Podman VMs need at least 12 GB RAM.
• One full build leaves about 44 GB of caches.

The --gpu-operator flag switches to real NVIDIA GPUs. That mode requires Linux, Docker and the NVIDIA Container Toolkit. AMD and Intel accelerators are not supported — the platform is NVIDIA-only by design.

How Can Teams Deploy It in Production?

Dev teams can deploy from source or from the NGC Community Product Helm chart. That edition needs no paid subscription but excludes NVIDIA enterprise support.

Teams can also adopt the platform through 8 DSX ecosystem partners: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud and vCluster. Each announced an integration around the open-source release. Supported commercial editions continue through NVIDIA AI Enterprise, NVIDIA Mission Control and select cloud marketplaces.

The partner list signals the market stakes. Cloud and platform vendors now compete to package the same open-source scheduler with their own operational layers, the same dynamic that played out around Kubernetes itself after Google donated it to the CNCF.

What Related Projects Ship Alongside?

Two adjacent projects round out the stack. Model Streamer streams model weights directly into GPU memory; vLLM and SGLang enable it with --load-format runai_streamer.

Microsoft's published benchmark used 8 NVIDIA H100 VMs. It showed 3x to 6x faster loading than the default loader, with throughput holding at 80 Gbps versus about 40 Gbps on the default path. The gain targets LLM cold starts, a direct cost in inference deployments.

Grove, the second adjacent project, orchestrates multicomponent inference workloads. It starts components such as prefill and decode as all-or-nothing units.

How Does Run:ai Compare With Other Kubernetes Schedulers?

The open-source field already includes Volcano, Kueue and Apache YuniKorn, all Apache 2.0. The comparison turns on scope, not licensing:

Feature	Run:ai (open source)	Volcano	Kueue	YuniKorn
Governance	NVIDIA DSX org (KAI Scheduler: CNCF Sandbox)	CNCF Incubating	kubernetes-sigs (wg-batch)	Apache Software Foundation
Scope	Full platform: control plane, UI, CLI, REST API, MCP server	Batch scheduling system	Job queueing controller	Scheduler, alternative to default
Replaces kube-scheduler	No, extends it via KAI Scheduler	Not disclosed	No	Yes, as an alternative
Gang scheduling	Yes	Yes	Timeout-based all-or-nothing	Yes
Quota hierarchy	Projects, departments, node pools	Multi-level queues	Cohorts, fair sharing	Hierarchical queues
GPU sharing	CUDA 13.4-native fractions with hard memory limits	vGPU, dynamic MIG	DRA-based GPU quota; fractioning not in overview	Not disclosed
Multi-cluster	Yes, via control plane	Yes	Yes, MultiKueue	Not disclosed
Web UI	Yes	Separate dashboard project	Not disclosed	Not disclosed

The key difference is scope. Volcano, Kueue and YuniKorn focus on scheduling or queueing. Run:ai ships a full management platform on top of its scheduler.

That breadth cuts both ways. A team wanting a queueing controller can adopt Kueue inside kubernetes-sigs governance and avoid vendor alignment. A team wanting quotas, a web UI, an MCP server and GPU fractioning in one package now gets all of it free — with the caveat that the project lives in a vendor organization rather than a neutral foundation.

What Happens Next?

The release compresses the paid tier of GPU orchestration to support and services. Rivals such as Run:ai's former commercial competitors now face a free, full-platform alternative backed by the dominant GPU vendor, and the eight launch partners indicate the packaging race has already started.