NVIDIA Open-Sources Run:ai and Moves GPU Scheduling Into a Shared Repository

TL;DR

• NVIDIA Run:ai is a platform that schedules AI workloads across GPUs inside Kubernetes clusters, so one pool of accelerators can serve training, inference and interactive jobs without a separate cluster for each team; NVIDIA released the complete platform as open source on 13 October 2026.
• Run:ai 3.0 ships as four components that can be adopted one at a time: KAI Scheduler for GPU-aware Kubernetes scheduling, GPU Fractioning Operator for CUDA-native GPU sharing, KAI Resource Management for organisational quota and hierarchy, and Workload Map for a consistent workload-management contract.
• KAI Scheduler is published under Apache 2.0 and contributed to the CNCF as a Sandbox project, and NVIDIA states that all scheduler development happens in the community repository, so the upstream engine behind the commercial platform is the community codebase.
• Eight DSX ecosystem partners are integrating the open platform, among them Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud and vCluster.
• Two adoption routes are documented: the community product on NGC, where NVIDIA says no paid subscription or support entitlement is required, and a supported commercial path through Run:ai standalone, NVIDIA AI Enterprise, Mission Control, cloud marketplaces or partners.
• The licence answer changes the buying question: no licence is required to self-operate the software, support is paid for on the commercial paths, and an organisation that self-operates the stack owns upgrades, tuning and capacity planning; fractioning through MIG, MPS and CUDA MPS stays bound to NVIDIA runtimes.
• NVIDIA's product page carries utilisation claims of 10x GPU availability and 20x workloads running with no baseline published alongside them.

What NVIDIA released on 13 October 2026

NVIDIA published the full Run:ai platform as open source software on 13 October 2026, describing the release as an expansion of its DSX AI Factory Platform and as an open foundation for AI workload and GPU orchestration (NVIDIA developer blog, 13 October 2026).

The platform arrived before this release. Run:ai has spent several years helping organisations run AI workloads on Kubernetes across the lifecycle, from data processing and training to inference, and the same announcement says every DSX ecosystem partner and AI cloud can now use it to raise workload throughput and GPU utilisation on shared infrastructure. What changed on 13 October is where the code lives and how it is obtained: the complete source is published in the Run:ai repository inside NVIDIA's DSX AI Factory GitHub organisation, and the product FAQ states that the release in which the whole platform is open source is Run:ai 3.0.

Two routes are published side by side. The community product is available from NVIDIA's NGC catalogue with a Helm chart for installing the integrated stack; NVIDIA's note says no paid Run:ai subscription or support entitlement is required for it and that enterprise support is not included. The supported route runs through Run:ai standalone, NVIDIA AI Enterprise, NVIDIA Mission Control, participating cloud marketplaces and partners.

The four components and the job each one does

KAI Scheduler is the Kubernetes-native scheduler that powers the platform. It was released under the Apache 2.0 licence and contributed to the CNCF as a Sandbox project, and NVIDIA states that KAI remains the upstream engine behind Run:ai, with all scheduler development happening in the community repository. The repository readme lists batch scheduling for pod groups, bin packing and spread scheduling, workload priority, background pods that are evicted on demand, Dynamic Resource Allocation support for NVIDIA ComputeResources on GB200 and GB300, topology-aware scheduling with hierarchical podgroups, workload signatures for large multi-pod submissions, and scheduler explainability through Kubernetes events.

GPU Fractioning Operator handles the sharing side: multiple workloads on a single GPU or across several, with hard memory isolation, fractions requested on demand and configuration that does not require a per-node setup in advance. KAI Resource Management adds organisational quota and hierarchy, with projects, departments and node pools, which is the part that lets several teams share one cluster within set limits. Workload Map supplies a single workload-management contract across the components.

Two further projects are named as complementary: Model Streamer reads model weights concurrently and streams them into GPU memory, is integrated upstream in vLLM and SGLang behind the runai_streamer load format, and NVIDIA reports a DDN result that puts the saving at up to 10% of daily GPU runtime compared with using local storage; Grove provides a Kubernetes API for multi-component inference workloads, with topology-aware autoscaling and hierarchical gang scheduling so that prefill and decode start as all-or-nothing units, and it manages ComputeDomain resources automatically on GB200 NVL72.

Why the scheduling layer decides how many GPUs a team needs

Shared accelerator capacity is the resource an AI platform manages, and the scheduler is the component that decides how much of it reaches a job. A cluster with eight GPUs split across two nodes can deliver very different throughput depending on whether the scheduler places a distributed training job as a single gang across both nodes, keeps a small inference service inside one GPU fraction, or leaves a maintenance pod holding a full card.

A concrete case, marked as a hypothetical: an SME running four accelerators, training overnight and serving inference during business hours. Without fractioning, the inference service holds a full GPU all day while using a fraction of its memory; without quota, one team's training job can occupy the whole pool. The mechanisms NVIDIA published address exactly those two losses, which is why the release matters more to the operator than the licence line does.

What the ecosystem partners are building against

Eight partners are named as integrating the open platform: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud and vCluster. The list splits into GPU cloud operators on one side and Kubernetes platform vendors on the other, and both groups are building on a codebase that is developed in the open.

A published roster of this kind tells a buyer where support will exist. It also creates a shared foundation: a vendor that wants to differentiate its scheduling now contributes to the same repository that its competitor builds on, and improvements land in one shared codebase.

The licence question a buyer asks first

NVIDIA's FAQ answers the first question directly: no licence is required to deploy and self-operate the open source software, and licensing or entitlement terms apply when a commercial offering is chosen. Asked whether a supported version is a different feature edition, the same FAQ answers that supported options exist as a commercial support and procurement path for the same platform, and that it carries no separate proprietary feature tier.

That answer converts the commercial conversation. On the community route the cost of the software disappears and the cost of operating it appears in the same line: the source code is governed by its applicable open source licences, downloading the community product from NGC requires acceptance of NVIDIA's software licence agreement and product-specific terms, and support arrives only on the paid paths.

What self-operating the stack now involves

Self-operation is a real workload: cluster upgrades, Kubernetes version and feature gates, the fractioning configuration path, queue fairness between teams, and the capacity plan that decides when another accelerator is cheaper than another scheduling rule. The operator inherits all of it, and gains the ability to inspect and adapt the code that makes placement decisions.

The dependency to name is the runtime. Fractioning rests on MIG, MPS and CUDA 13.4 MPS fractioning, which are NVIDIA GPU features, so the open control plane still depends on NVIDIA's stack for the data path in those modes. Netics works this class of decision — where a workload runs, who operates it and what the exit looks like — through sovereign infrastructure and cloud exit. The rack-level buying question that sat next to it in October is the one we read in Microsoft's Maia 300 rack numbers, and the two decisions arrive in the same capacity review: what silicon to buy, and how it gets shared.

A utilisation claim with no baseline

NVIDIA's product page carries three figures for the platform: 10x GPU availability, 20x workloads running and 5x GPU utilisation, with zero manual intervention, and the announcement does not attach a baseline, a workload shape or a measurement window to any of them. Those are vendor claims, and a buyer should treat them as such.

The mechanism can be checked directly. Fractioning granularity, queue fairness, whether quota is enforced per team or per project, support for Dynamic Resource Allocation, and whether the scheduler explains a refusal through Kubernetes events are all published in the repository, and each one is testable on the hardware already owned. The open-source release is what makes that test possible before a purchase order.

Sources

Source: NVIDIA Run:ai Is Now Open Source as Part of NVIDIA DSX AI Factory Platform — developer.nvidia.com blog, 13 October 2026, retrieved 2026-10-16 (the full Run:ai platform released as open source software expanding the NVIDIA DSX AI Factory Platform; the four modular components KAI Scheduler, GPU Fractioning Operator, KAI Resource Management and Workload Map and their individual functions; the eight providers named as DSX ecosystem partners; KAI Scheduler under Apache 2.0 contributed to the CNCF as a Sandbox project with development in the community repository; GPU sharing across MIG, MPS, time sharing, HaMi and CUDA 13.4 MPS fractioning with Dynamic Resource Allocation support; Model Streamer integrated upstream in vLLM and SGLang behind the runai_streamer load format and credited with saving up to 10% of daily GPU runtime against local storage; Grove as a Kubernetes API for multi-component inference workloads with topology-aware autoscaling and hierarchical gang scheduling on GB200 NVL72; the NGC community product and the note that no paid subscription or support entitlement is required for it).

Source: NVIDIA Run:ai product page and get-started FAQ — nvidia.com, retrieved 2026-10-16 (Run:ai 3.0 as the release in which the complete platform is open source for AI workload and GPU orchestration on Kubernetes; no licence required to deploy and self-operate the software, with licensing or entitlement terms applying to supported commercial offerings; supported options described as a commercial support and procurement path rather than a separate proprietary feature tier; eligible support paths from Run:ai standalone to NVIDIA AI Enterprise, Mission Control, cloud marketplaces and partners; the vendor figures of 10x GPU availability, 20x workloads running, 5x GPU utilization and zero manual intervention; the licence terms attached to the NGC community product).

Source: KAI Scheduler repository readme — github.com/kai-scheduler/KAI-scheduler, retrieved 2026-10-16 (KAI Scheduler as the Kubernetes-native scheduler behind the Run:ai platform, built on kube-batch; batch scheduling, bin packing and spread scheduling, workload priority, background pods, Dynamic Resource Allocation for NVIDIA ComputeResources on GB200 and GB300, topology-aware scheduling with hierarchical podgroups, workload signatures, scheduler explainability through Kubernetes events, GPU sharing across single or multiple GPUs, and compatibility with cloud auto-scalers such as Karpenter as well as static on-premise deployments).

Source: NVIDIA's developer-blog announcement, product pages and the KAI Scheduler repository, 13 October 2026 — the component names, licence, partner list, availability paths and vendor figures relied on above, retrieved 2026-10-16. Images are captures of NVIDIA's own pages, plus two Netics editorial diagrams.