NVIDIA Open Sourced Run:ai. The Hard Part Is Deciding What That Means

# NVIDIA open sourced Run:ai. The hard part is deciding what that means

On 13 October 2026, NVIDIA announced that the full Run:ai platform, the GPU orchestration layer it acquired and has been selling commercially, is now open source under the Apache License 2.0. The release lands as the foundation of the NVIDIA DSX AI Factory Platform, and it is a genuinely important move: the scheduler that decides which team gets which GPU, and how much of it, is now code you can read.

It is also not what most of the coverage implies, and the gap between the announcement and the operational reality is where your next two quarters of planning actually live.

Three things are true at once, and you need all three to make a good decision. The code is open. The governance is not. And the parts that are genuinely community-governed are not the parts that carry the vendor lock-in.

What actually shipped

The whole platform lives in one monorepo, dsx-ai-factory/run-ai, under Apache 2.0. It was created on 25 August 2026 and, when checked on 27 October, had 663 stars, 97 forks and 149 open issues, with documentation at docs.nvidia.com/run-ai. The latest tagged release was 3.0.21, published on 26 October, inside a 3.0 patch line that also contains 3.0.20 and 3.0.17. Only one release branch is supported: SUPPORT.md lists release-3.0 as Supported.

The repository is more than a scheduler. It contains the control plane services, the in-cluster operator and controllers, shared libraries and clients, the installer, the CLI, an MCP server and the local development environment.

Alongside the full platform, NVIDIA published four components that can be adopted on their own: KAI Scheduler, the GPU Fractioning Operator, KAI Resource Management and Workload Map. That last part is where the practical value sits, so it deserves precision, because the four are not equally ready.

The platform CRDs are vendor-specific, not upstream Kubernetes APIs: projects.run.ai, nodepools.run.ai, departments.scheduling.run.ai, clusters, datavolumes, accessrules, workloadrunners, runaiconfigs and remoteconfigs. If you install the full platform, your manifests will carry run.ai and scheduling.run.ai API groups, and moving away later means rewriting them.

KAI Scheduler, by contrast, is a separate community repository, kai-scheduler/KAI-Scheduler, also Apache 2.0, created on 26 February 2025 and showing 1,614 stars, 314 forks and 265 open issues. NVIDIA states that all scheduler development happens in that community repository, so every improvement flows through the same codebase. And it is the only part of this story with a foundation behind it: the CNCF Sandbox application, cncf/sandbox issue 372, was opened on 8 May 2025 and closed on 8 February 2026 with the sandbox milestone recorded as 16 December 2025.

That application was not a formality. The Volcano project team raised code-provenance and license-hygiene concerns on 10 June 2025, and the CNCF Technical Oversight Committee reviewed the project on 23 September 2025. Sandbox is the lowest tier of CNCF incubation, and it is still a tier above where the rest of Run:ai sits.

The governance line nobody puts in the press release

GOVERNANCE.md is explicit: roadmap and release scheduling are set by NVIDIA. Decision-making uses lazy consensus with a five-working-day objection window, and unresolved decisions escalate to the NVIDIA engineering leadership responsible for the project.

The project's own words are the fairest summary: "This is an NVIDIA open-source project. The source is public and contributions are welcome under the terms in Contributing, including the Developer Certificate of Origin sign-off requirement. Roadmap and release scheduling [are set by NVIDIA]."

That is a well-run single-vendor open source project. It is not a foundation-governed one, and the difference matters the day you want a feature that NVIDIA does not want.

Security reporting goes to the NVIDIA PSIRT rather than public GitHub issues, with a commitment to acknowledge within three business days, provide an initial assessment within ten, and update status at least every fourteen days. There is no paid bug bounty for the repository, although externally reported issues are publicly acknowledged under the coordinated disclosure policy when the reporter agrees.

And the licence story is not a single word. The monorepo is Apache 2.0, some vendored subdirectories ship under MIT, and the skills directory is Apache 2.0 and CC-BY-4.0. Downloading the Community Product from NGC still requires accepting the NVIDIA Software License Agreement and product-specific terms. The commercial Run:ai line continues separately, sold through a standalone product, NVIDIA Mission Control, NVIDIA AI Enterprise and selected cloud marketplaces.

The part that will decide whether you can run this

Fractional GPUs are the feature everybody wants, and they come with a prerequisite chain that press summaries leave out.

The GPU Fractioning Operator requires Kubernetes 1.28 or newer, containerd 2.0 or newer with NRI enabled, or CRI-O with NRI, the NVIDIA GPU Operator at v26.7.0 or newer with container toolkit v1.20.1 and device plugin v0.20.1 or newer, and an NVIDIA driver r615 or newer with CUDA 13.4 on the GPU nodes. The operator has four parts: a controller reconciling a GpuFractioningConfig custom resource, mpsd for MPS control and memory accounting, fractiond, an NRI plugin that injects the memory request and limit before the container process starts, and metricsd as a sidecar exporter.

The enforcement model is the good part. The README states it plainly: "The NVIDIA driver enforces NVIDIA_GPU_MEMORY_LIMIT as a hard cap, so a container cannot allocate beyond its share and impact its neighbors on the same GPU. A container that exceeds its limit is terminated (out-of-memory)."

And NVIDIA has retired its earlier proprietary fractioning implementation in favour of that native CUDA 13.4 capability, which is the right direction: the limit is enforced by the driver rather than by a daemon that can be bypassed.

Two caveats travel with it. The support matrix pins the GPU Operator at 25.10 through 26.7.1, and GPU fractions specifically require 26.7.1 together with an r615 driver, which 26.7.1 does not install by default. So the last mile of that upgrade is on you. And fractional GPU support is passthrough only: vGPU is not supported in v3.0, and DGX Spark, Jetson and workstations are excluded from support entirely.

The rest of the matrix is thorough. Run:ai v3.0 supports upstream Kubernetes 1.35 to 1.37 and Red Hat OpenShift 4.20 to 4.22, on containerd or CRI-O, for both x86 and ARM, with EKS, GKE, AKS, OKE and RKE2 listed. Third-party service versions validated for v3.0 include Keycloak 26.6, PostgreSQL 16, Traefik 3.7, NATS 2.11.8, Thanos 0.38.0, Valkey 9.0.4, oauth2-proxy 7.15.4 and git-sync 4.7.0.

One component is not actually released yet

KAI Resource Management is the piece that adds the organisational layer: projects and departments, a resource hierarchy with fair-share and quota semantics, and node pools for targeting heterogeneous hardware. It is also the piece you cannot install from a chart today.

Its README says it plainly: "There is not yet a published release, so cluster administrators must currently package the chart from source and supply compatible controller images."

That matters for anyone whose internal fight is about GPU cost attribution, because that is exactly what this component is for, and it is exactly the component that is not ready. Plan for that, not against it.

Workload Map, formerly Karta, is a Go library plus a CRD that describes arbitrary Kubernetes workload types, including PyTorchJob, RayCluster, JobSet and company-specific CRDs. It works offline on unstructured objects and deliberately does not schedule, queue, autoscale or propagate across clusters. Its CRD ships as run.ai/kartas.

What running it actually looks like

The local development path is heavier than the usual laptop demo. The guide describes about 50 Go services and a five-node Kind cluster, one control plane plus four workers, named runai-local and pinned to Kubernetes v1.37.0 with kind v0.33.0. GPUs are simulated with a fake GPU operator configured for eight Tesla-A10s. Prerequisites are macOS or Linux on amd64 or arm64, Windows is rejected, at least four CPUs, 16 GB of RAM and 100 GB of free disk on Linux, or at least 12 GB of RAM for the macOS Podman VM. One full build leaves about 44 GB of caches behind, roughly 11 GB of Docker build cache and 33 GB of Go module and build caches. The environment serves the platform at https://runai.local behind a self-signed CA and server certificate with a wildcard SAN, and adds the host entry for you.

That last number, 44 GB, is the one to put in your capacity planning. The local environment is a legitimate way to evaluate the platform, and it is not a laptop demo.

The install path itself is ordinary Helm, which is a point in favour. Add the NVIDIA open-source repository and refresh the indexes:

helm repo add runai https://helm.ngc.nvidia.com/nvidia/runai-oss --force-update helm repo update

The control plane chart declares kubeVersion >=1.29.0-0 and pulls in runai-common-chart, Bitnami PostgreSQL, codecentric keycloakx, Bitnami Thanos, Bitnami NATS, Unleash Edge and the NVIDIA runai-telemetry chart, so you are installing a full stateful stack rather than a scheduler. The cluster component registers with the control plane, and the scheduler engine installs as an OCI chart into its own namespace:

helm upgrade -i kai-scheduler oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler -n kai-scheduler --create-namespace --version <VERSION>

KAI Scheduler assigns work through the pod label kai.scheduler/queue and the schedulerName kai-scheduler, and a fresh install creates the default queues default-parent-queue and default-queue. Its GPU sharing modes are NonMemoryEnforced, HamiCore, NvFractions and Disabled, where NvFractions uses gpu-fractioning with the CUDA memory-limit enforcement described above. It ships its own CRDs, scheduling.run.ai for podgroups, queues and bindrequests, and kai.scheduler for configs, schedulingshards and topologies.

Fractioning needs a patch to the NVIDIA cluster policy so the container toolkit will hand the management device to the gpu-fractioning namespace, and the driver has to be installed explicitly at r615 because the operator does not do it for you:

kubectl patch clusterpolicies.nvidia.com/cluster-policy --type=json -p='[{"op":"add","path":"/spec/toolkit/env/-","value":{"name":"NRI_MANAGEMENT_CDI_DEVICE_NAMESPACES","value":"gpu-fractioning"}}]' helm install gpu-operator nvidia/gpu-operator --version v26.7.1 --namespace gpu-operator --create-namespace --set driver.version=615.<patch>

Then verify, rather than assume:

kubectl -n gpu-fractioning get pods kubectl get gpufractioningconfig default -o yaml kubectl get nodes -L nvidia.com/gpu.deploy.client,nvidia.com/gpu-driver-upgrade-state

And if you want any workload CRD described without writing a scheduler plugin, apply the Workload Map CRD:

kubectl apply -f https://raw.githubusercontent.com/dsx-ai-factory/workload-map/main/charts/karta/crds/run.ai_kartas.yaml

The ecosystem, honestly

Eight DSX partners announced integrations on 13 October: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud and vCluster. Crusoe validated the deployment and representative workloads including cluster registration, distributed multi-node PyTorch training, fractional GPU sharing and inference serving. Mirantis integrates Run:ai into k0rdent AI as a single catalog entry. Nebius, a launch partner, offers the open-source platform in its AI Cloud Applications running on managed Kubernetes.

Read the support matrix before you plan around any of that. The partner-compatible distribution table still lists Run:ai versions 2.22 through 2.25, with Crusoe CMK on Kubernetes 1.33, Mirantis k0rdent on 2.22 and 2.23, OpenNebula OneKS on 2.25 with Kubernetes 1.34, Rafay on 2.23 and 2.24, and Spectro Cloud on 2.24 with Kubernetes 1.34. The 3.0 line is not in that table yet. The ecosystem announcements are forward-looking, not a 3.0 certification, and the distinction matters if you are planning a purchase cycle this quarter.

One more number to treat carefully. The 3x to 6x speed-up that circulates in coverage belongs to Model Streamer, a Python SDK that streams SafeTensors files into GPU memory, integrated upstream in vLLM and SGLang and enabled with the --load-format runai_streamer flag. Microsoft measured it on Azure. It is a model-loading win, not a scheduling or quota-management win, and NVIDIA published no platform-level benchmark for the open-source release. If you have been quoted the 6x figure as a Run:ai result, that is a category error worth catching before it reaches a slide.

The decision this actually forces

Here is the version of the news that is useful to a platform leader.

The scheduler is the part worth adopting, and it is the part that is genuinely open. KAI Scheduler is Apache 2.0, community-developed, CNCF Sandbox reviewed, with its own CRDs and a clean Helm and OCI install path. Adopting it on its own gives you gang scheduling, quota and fair-share semantics and GPU sharing without taking a single vendor API group. That is a low-lock-in bet with an upstream track record.

The platform is the part worth evaluating, and it is the part that carries the lock-in. Installing the Run:ai control plane means vendor CRDs, a stateful stack of PostgreSQL, Keycloak, Thanos and NATS, and a governance model where NVIDIA sets the roadmap. That may well be the right call for an organisation that is standardising on DSX, and it is a different decision from the one you make about the scheduler.

And the middle of the platform, the quota and project hierarchy your finance team will ask about, does not have a published release yet.

The practical sequence is to run the local environment if you have the disk, adopt the scheduler as a standalone if your GPU contention is real, and treat the platform as a vendor decision rather than an open-source one. Do not plan on fractional GPUs until the r615 driver and the NRI-capable runtime are in place, because that chain is the one that will cost you the month. And do not budget on partner-certified stacks until the support matrix catches up with 3.0.

Open-sourcing the code is the easy half of this move. Deciding who decides, and how much of your platform you want to bind to, is the half that shows up in your next architecture review.