NVIDIA opens Run ai source for shared GPU management
NVIDIA announced the open source release of its full Run ai platform on October 13, giving infrastructure teams access to software for sharing and managing GPU capacity across AI workloads. The release sits within the company’s DSX AI Factory platform.
The announcement identifies four components that teams can adopt separately. KAI Scheduler handles placement, GPU Fractioning Operator handles sharing, KAI Resource Management organises capacity and Workload Map provides a common way to describe different workloads.
What the public code actually contains
The public platform repository includes control plane services, cluster controllers, an installer, clients and an MCP server. Its architecture puts central management above services running in each connected Kubernetes cluster. Users can work through a web interface, command line or API.
That makes the release relevant to organisations whose teams compete for the same pool of accelerators. The repository describes quotas across departments and projects, workload priorities, GPU sharing and visibility across clusters. It also says native Kubernetes scheduling may be sufficient for a single team using dedicated GPUs.
The main code is under Apache License 2.0, with separate notices for bundled third party material. The repository explicitly excludes NVIDIA and Run ai brand assets from that software licence. Opening the source therefore does not grant unrestricted rights to its logos or artwork.
Sharing a GPU requires more than a scheduler
The GPU Fractioning Operator repository separates two jobs. The scheduler decides which fraction of a GPU a workload receives. Components on the node enforce its memory boundary and report usage. The operator applies limits before a container starts and relies on NVIDIA’s driver to enforce them.
Its current requirements include Kubernetes 1.28 or later, a container runtime with NRI support and the r615 NVIDIA driver branch or newer. The documentation also specifies minimum container toolkit and device plugin versions. Those dependencies make this an infrastructure integration task rather than an option every existing cluster can immediately enable.
The documented hard cap is a memory limit. A workload that exceeds its allocation can be terminated for running out of memory. That is a useful boundary to understand before treating fractional allocation as interchangeable with an entire dedicated GPU.
Individual components have different readiness levels
KAI Resource Management adds projects, departments, node pools and placement rules around the scheduler. At the time of review, its standalone repository said there was no published release yet. Administrators adopting that component directly must package its Helm chart from source and provide compatible controller images.
Workload Map, whose documentation also calls it Karta, addresses a different maintenance problem. Kubernetes tools such as Ray and distributed training frameworks describe their jobs in different structures. A mapping tells a controller where to find pod definitions, replica counts and status without writing a separate integration for every type.
Its supplied definitions cover workloads including RayCluster, PyTorchJob, KServe and NVIDIA Dynamo. The repository labels the project as active development before version 1.0 and warns that its API may change between minor versions. Teams building against it should account for that stated compatibility risk.
Check the distribution path and support terms
NVIDIA says an NGC Community Product requires no paid Run ai subscription and includes no enterprise support. It distinguishes source code licences from the additional NVIDIA terms covering the packaged download.
There is a distribution detail still to verify. The NGC listing linked by the announcement, retrieved for this report, displayed premium subscription wording and a September 23 update date. We confirmed the public repositories, but did not complete a Community Product download or test an installation.
For platform teams, the immediate opportunity is to inspect and evaluate the implementation against their own cluster requirements. Public code, packaged availability, compatibility and operational support are separate checks. None of the sources establishes a guaranteed utilisation gain for a particular deployment.
