NVIDIA Run:ai Is Now Open Source: What Platform Teams Get

NVIDIA just published the whole Run:ai platform as source code. On October 13, 2026 it announced that NVIDIA Run:ai is open source, released as part of its DSX AI Factory platform. If you schedule GPUs on Kubernetes, you can now read, test and patch the layers that decide which job gets which GPU, without a paid subscription for the Community Product.

What the NVIDIA Run:ai open source release includes

The platform is split into four modules, each in its own repo, so you can adopt one without the rest.

• KAI Scheduler: the Kubernetes-native scheduler behind Run:ai. It does gang scheduling (all pods of a job start together or none do), fair-share and quota allocation, topology awareness, bin-packing and GPU sharing. It is Apache 2.0 and a CNCF Sandbox project. The scheduler itself has been open since April 2025.
• GPU Fractioning Operator: splits one GPU between pods using the native fractioning in CUDA 13.4, replacing Run:ai's retired proprietary implementation. It includes a per-pod metrics exporter and works with schedulers other than KAI.
• KAI Resource Management: projects and departments, guarantees and sharing with quota semantics, and node pools for mixed hardware.
• Workload Map: a Go library that describes workloads for scheduling, gang semantics, discovery and lifecycle. It works offline on unstructured objects, so it adds nothing to your cluster. It does not schedule, queue or autoscale.

The full platform is also on NVIDIA NGC as a "Community Product" with a Helm chart for the integrated stack. The source lives in the dsx-ai-factory GitHub organization.

Licensing and support: what the announcement leaves open

• No single license for the full platform. The post says the source is "governed by its applicable open source licenses." Only KAI Scheduler is named as Apache 2.0. Read each repo's license file before you fork or embed anything.
• NGC has its own terms. Downloading from NGC requires accepting the NVIDIA Software License Agreement and product-specific terms.
• No support included. The Community Product needs no paid Run:ai subscription or NVIDIA support entitlement, and it does not come with enterprise support. Commercial Run:ai is still sold separately.
• No Kubernetes version list. Neither the post nor the KAI Scheduler README states a minimum version, so test against yours.
• Isolation is unclear. KAI offers install-time GPU sharing modes (NonMemoryEnforced, HamiCore, NvFractions, Disabled). Read the GPU sharing docs before you promise a tenant that their GPU memory is protected.

Why GPU scheduling in open source matters

GPU clusters leak money in two ways: cards reserved by a team that isn't using them, and a distributed training job holding half its GPUs while it waits for the rest. Queues with quotas and over-quota sharing attack the first. Gang scheduling attacks the second.

The catch: you now own upgrades and debugging for a scheduler. That is a real cost, so start small.

Try KAI Scheduler on a test cluster on Monday

KAI Scheduler can run alongside your existing scheduler, so a staging cluster is enough. You need Helm, and the NVIDIA GPU Operator for GPU workloads.

Install KAI Scheduler with Helm

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

Pick <VERSION> from the project's releases page. A fresh install creates default-parent-queue and default-queue.

Create a queue and a dedicated namespace

Never submit workloads from the kai-scheduler namespace. Make your own, then add a queue under the default parent.

kubectl create namespace kai-demo

apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: team-a
spec:
  parentQueue: default-parent-queue
  resources:
    cpu:
      quota: 0
      limit: -1
      overQuotaWeight: 1
    memory:
      quota: 0
      limit: -1
      overQuotaWeight: 1
    gpu:
      quota: 1
      limit: 2
      overQuotaWeight: 1

The cpu and memory blocks are the defaults from the repo's default-queues.yaml. Only the GPU numbers are mine, so check the queue docs for units.

Submit a pod through the scheduler

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
  namespace: kai-demo
  labels:
    kai.scheduler/queue: team-a
spec:
  schedulerName: kai-scheduler
  containers:
    - name: gpu-check
      image: ubuntu
      command: ["bash", "-c"]
      args: ["nvidia-smi; trap 'exit 0' TERM; sleep infinity & wait"]
      resources:
        limits:
          nvidia.com/gpu: "1"

This follows the repo's quickstart gpu-pod.yaml. The queue label and schedulerName are what route the pod to KAI. Apply it, then run kubectl logs gpu-pod -n kai-demo to see nvidia-smi output.

Then try the other modules

• Deploy the GPU Fractioning Operator on its own and watch its per-pod metrics.
• Read the Workload Map repo (dsx-ai-factory/karta), since it needs no cluster changes.
• If you serve models with vLLM or SGLang, try the related Model Streamer with --load-format runai_streamer. NVIDIA reports 3x to 6x faster weight loading on eight H100 Azure VMs, which is their benchmark, not yours.

Keep the full NGC Helm chart off production until you have read its terms.

An open scheduler you can test on your own hardware beats a slide deck, and that is the fastest way to find out whether your GPU bill has a scheduling problem.