NVIDIA has released the complete Run:ai platform as open-source software, turning a product it acquired in late 2024 into a public Kubernetes stack for scheduling, sharing and governing expensive GPU clusters.
The October 13 release is broader than the KAI Scheduler code NVIDIA opened earlier. It includes Run:ai’s control plane, in-cluster operators and controllers, installer, command-line client, web interface, API, observability services and an MCP server for AI assistants. The main repository is licensed under Apache 2.0, with separate notices for bundled third-party components.
Teams can now inspect and modify the software, deploy the full platform on Kubernetes or OpenShift, or pull out individual components. NVIDIA is also distributing an integrated Helm-based community package through NGC. That package does not require a paid Run:ai subscription, but it does not include NVIDIA enterprise support.
What NVIDIA actually released
Run:ai sits above Kubernetes rather than replacing it. Kubernetes still starts containers and manages nodes; Run:ai adds scheduling and policy logic designed for AI development, training and inference across a shared GPU estate.
The platform has two major halves. A centralized control plane handles identities, role-based access, quotas, workload policies, metrics and the desired state of connected clusters. Components inside each cluster translate those instructions into Kubernetes resources, place workloads and report live status back to the control plane. NVIDIA’s architecture documentation says the connection from a cluster back to the control plane is outbound-only, so the cluster does not need to be publicly reachable.
Four components can also be adopted separately:
- KAI Scheduler handles fair-share allocation, priorities, preemption, gang scheduling and topology-aware placement. Gang scheduling keeps a distributed job from starting unless the cluster can place all of its required pods.
- GPU Fractioning Operator lets multiple Kubernetes workloads use portions of the same GPU with driver-enforced memory limits. It is aimed at jobs such as notebooks and smaller inference services that do not need an entire accelerator.
- KAI Resource Management adds projects, departments, node pools, queues and workload-placement policies to the scheduler.
- Workload Map provides a common representation for Kubernetes workload types such as PyTorchJob, RayCluster and JobSet, reducing the need for separate orchestration logic for every custom resource.
KAI Scheduler is already a Cloud Native Computing Foundation sandbox project. NVIDIA says scheduler development occurs in that community repository, so platform users and standalone KAI adopters work from the same upstream engine.
Why GPU sharing needs more than a queue
A single cluster may serve interactive notebooks, short evaluation jobs, multi-node training runs and production inference. Their requirements rarely line up neatly. A notebook can reserve a whole GPU while using only a fraction of its memory, while a distributed training job may need several specific GPUs available at the same time and close enough in the cluster topology to communicate efficiently.
Run:ai addresses the first problem by dividing supported GPUs into memory-bounded fractions. It addresses the second with placement simulation, gang scheduling, topology awareness and bin-packing. Fair-share and quota rules can reserve capacity for a department while allowing another team to borrow idle resources until the owner needs them.
That combination matters more than a simple first-in, first-out job queue. Poor placement can strand free memory across several GPUs, start only part of a distributed job or leave high-bandwidth links underused. The scheduler’s job is to consider the shape of each request as well as the number of available devices.
Cloud provider Lambda, which plans to add Run:ai to its managed Kubernetes service, offered a concrete description of the problem: debugging may need only part of a GPU, evaluations may launch many independent jobs and distributed training may need numerous tightly connected accelerators. Its planned integration will pair Run:ai scheduling with Lambda’s node monitoring, isolation and remediation. The integration was announced as future work, not an already available managed option.
Open source does not erase the operational work
The code release removes a licensing barrier, but it does not make multi-tenant GPU infrastructure simple. A self-managed deployment still needs Kubernetes or OpenShift, compatible GPU and network operators, storage, identity integration, monitoring and an upgrade process. Air-gapped installations are supported, although they add their own image-mirroring and lifecycle requirements.
The platform’s governance layer also deserves careful review before production use. Run:ai can enforce access rules and workload policies, but operators still have to design sensible project boundaries, quotas and administrator roles. GPU fractioning improves density; it should not be mistaken for a universal security boundary between mutually hostile tenants. Teams should test isolation against their own threat model and supported driver configuration.
NVIDIA’s community route and commercial route now serve different buyers. The Apache-licensed repository is the clearest option for teams that want to audit, customize or embed the platform. The NGC Community Product provides packaged installation without a paid entitlement, but NVIDIA explicitly excludes enterprise support. Supported versions remain available through standalone commercial offerings, NVIDIA Mission Control, NVIDIA AI Enterprise and selected cloud marketplaces.
Who should evaluate Run:ai now
The strongest candidates are organizations with several teams competing for the same Kubernetes GPU fleet, especially when those teams mix small interactive work with large training or inference jobs. Quotas, borrowing, fractional allocation and multi-cluster visibility address real coordination costs in that environment.
A single team running predictable jobs on dedicated GPUs may not need the extra control plane. NVIDIA’s own repository notes that native Kubernetes scheduling can be sufficient in that simpler case. Existing users of Kueue, Volcano, Kubeflow, Ray, Argo Workflows or Slurm should map overlaps before changing platforms: Run:ai complements several Kubernetes workload systems, but Slurm can remain an alternative for bare-metal HPC scheduling.
The release also creates a more practical evaluation path. Platform teams can examine the code and security model, run the local Kind-based development environment, test individual components, and compare scheduling behavior before committing a production cluster. The open repository currently exposes its issues and release history, but NVIDIA does not publish a long-range roadmap there.
That makes October’s release a starting point rather than proof of lower infrastructure costs. The useful test is measurable: whether Run:ai can reduce queued work and idle accelerator capacity in a representative cluster without adding more operational burden than it removes.
