NVIDIA has released the full code for its platform that allocates GPUs to AI workloads across teams. Teams building shared infrastructure can review and modify code from scheduling to organizational resource allocation. They can also add only the features they need to existing environments.

1. Open source expands from the scheduler to the full platform

NVIDIA announced the open-source release of the full Run:ai platform on 2026-10-13. Beyond the previously released scheduling engine, it provides additional platform code and four independently adoptable components. The release is part of the NVIDIA DSX AI Factory Platform.

The unified repository includes the central management layer, cluster services, installation tools, and a development environment. Its code uses Apache 2.0, but third-party code and assets in some subdirectories have separate licenses.

2. Separating scheduling, partitioning, organization, and workload definitions

KAI Scheduler decides which GPU runs a workload. For workloads requiring multiple execution units together, it first checks placement feasibility in memory so that all units are scheduled or none are. It allocates resources fairly across teams, considers device interconnections, and can run alongside existing schedulers.

GPU Fractioning Operator manages node components so multiple workloads can share one GPU. The previous proprietary implementation has been replaced by native fractioning in CUDA 13.4. The driver enforces per-workload GPU memory limits, terminating the container with an out-of-memory error if it exceeds its limit.

KAI Resource Management determines who can use how much across departments and projects. It allocates, guarantees, and shares GPU capacity along organizational hierarchies and groups heterogeneous hardware to assign suitable resources to workloads.

Workload Map is a convention for describing the varying structures, roles, and states of workload types in a common way. It is like a shared workload specification, rather than a separate interpreter for each tool. It is a Go library requiring no additional cluster installation. It does not schedule workloads or manage queues and autoscaling itself.

3. Unified installation and local evaluation

The full platform can be adopted directly or through ecosystem partner products. NVIDIA NGC also offers a community product with Helm charts for unified installation. Unlike the source code's open-source license, downloading this product requires accepting the NVIDIA Software License Agreement and AI product-specific terms.

The following example from the unified repository is for local evaluation. It builds services from source and deploys them to a local Kubernetes cluster. Prerequisite tools, such as a container runtime, and resources must be prepared in advance; only some cluster tools are installed automatically.

./local-dev.sh                                  # full build + cluster + deploy
./local-dev.sh --skip-build --skip-cluster      # re-deploy only
./local-dev.sh --teardown                       # tear the environment down

4. GPU fractioning starts with checking the software combination

The fractioning operator documentation recommends NVIDIA GPU Operator v26.7.1. It includes the required container tools and device plugin by default, but GPU node drivers must be explicitly set to r615 or later. Check the repository for other prerequisites, including the container runtime environment.

If the GPU configuration tool runs in its own node integration plugin mode and the fractioning operator is installed in another namespace, an administrator must expand the tool's namespace allowlist. Here, a namespace is a unit that separates workspaces within a cluster.

Disabling version validation does not create compatibility. Unsupported GPU software combinations may still appear ready, and failures to enforce memory limits may go unreported.

5. Benefits of choice and costs of operation

Choosing between the full platform and individual features benefits teams that want to keep their existing environments. Self-hosting, however, brings the burden of managing software combinations and node components. The community product requires no paid subscription or support entitlement but does not include enterprise support. Those needing support must separately review the terms of commercial offerings.

The repository explains that basic Kubernetes scheduling may suffice for a single team that only runs workloads on dedicated GPUs. Whether multiple teams need resource sharing and quota controls determines the scope of adoption.

The value of this release lies in choosing the features needed to operate shared GPUs, while adoption should match each organization's resource control needs and its capacity to operate the system itself.