Nvidia Open-Sources Run:ai and Retires Its Proprietary GPU Fractioning

Nvidia has published the full Run:ai platform as open source, in the DSX AI Factory GitHub organisation and on NGC as a Community Product with a Helm chart. The licence stops being the gate: no paid Run:ai subscription and no NVIDIA support entitlement are required to run the community build. The announcement is on Nvidia's technical blog.

What the community build does not include is enterprise support. A team that runs shared GPU clusters and needs a vendor to escalate to still buys Run:ai through the commercial offerings: standalone, Mission Control, or AI Enterprise. The code moved. The phone number did not.

The scheduler stops being a purchase

KAI Scheduler handles GPU-aware scheduling on Kubernetes. It decides which pod lands on which GPU, and that decision is the difference between a cluster running at 60 percent utilisation and one running at 90. It is Apache 2.0 licensed and contributed to the CNCF as a Sandbox project. A component that used to arrive inside a paid suite can now be installed on its own, with the source in front of you.

A scheduler sits underneath everything else on the cluster, so its mistakes are visible everywhere: a job that waits behind a smaller one, a node that idles while another is oversubscribed, a queue that starves a team for an afternoon. That is the part of the stack where a licence fee is hardest to justify and hardest to remove. It is also the part where reading the source helps, because the placement decision you disagree with is made in code you can now open rather than in a black box you can only open a ticket about.

GPU fractioning is the part that breaks

The GPU Fractioning Operator is the one component where open sourcing takes something away. Nvidia's post states that the proprietary implementation "has been retired in favor of the native capability available in CUDA 13.4". If your nodes are pinned below that release because of a driver, a framework build or a validation cycle that takes months, the open-source fractioning path is not a drop-in replacement for what you run today. Moving the node stack to CUDA 13.4 is now part of the migration rather than an optional extra.

Check the CUDA version on every node before you plan that work. A cluster where half the nodes qualify and half do not is the expensive version of this upgrade, and it is the usual state of a cluster that has grown one rack at a time.

Four components, adoptable one at a time

The release is modular, which matters if you only wanted one piece of it. KAI Scheduler covers GPU-aware scheduling. The GPU Fractioning Operator exposes CUDA-native GPU fractions. KAI Resource Management handles projects, departments, quotas and node pools. Workload Map defines a workload-management contract and ships as a Go library that works offline.

Workload Map being offline matters more than it sounds. Clusters that run in a regulated environment, or on hardware with no route out, can adopt the library without carving an exception in a network policy. The four pieces are also separable in the reverse direction: if the only thing you want is GPU-aware placement, you can take the scheduler and leave the operator, the quota layer and the workload contract on the shelf. That was not a realistic option when the parts shipped as one product with one price.

Sandbox is early, and nobody is on call for you

KAI Scheduler's move into the CNCF as a Sandbox project is the earliest of the foundation's maturity stages, which is a statement about governance and adoption rather than a promise of support. For a team that has been buying GPU orchestration as a product, the shift is worth stating plainly: the community build gives you the code and the chart, and it does not give you a person to escalate to when a job will not schedule at 2am. If your cluster is small and your team is comfortable in Kubernetes, that trade is reasonable. If it is not, the commercial offering is still the honest answer, and it costs what it costs.

Support is what is left to sell

Eight DSX ecosystem partners are integrating the platform: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud and vCluster. That list is where supported distributions will come from, and for a buyer it is more useful than the licence change on its own. Nvidia acquired Run:ai for a reported $700 million in late 2024, and the shape of this release keeps the scheduler layer commoditised while support, Mission Control and AI Enterprise stay behind the paywall.

What to do if you already run Run:ai

The first question is not technical. It is whether the renewal is buying software or a support relationship, because the answer decides whether this announcement costs you money or saves it. Once that is settled, the technical work is a sequence rather than a project.

• Work out whether the renewal buys software or a support contract. If it buys software, the published Helm chart is the cheaper path and you carry the patching yourself.
• Confirm CUDA 13.4 on every node before you touch fractioning.
• Diff the published chart against your current values file instead of reinstalling from scratch.
• If you keep the commercial subscription, ask what the open-source release does to the price at renewal. That conversation is easier to start now than it was last month.

Faster weight loading is next to it

Two related Nvidia projects sit alongside the release. Model Streamer speeds up weight loading and is available in vLLM and SGLang through a load-format flag:

vllm serve MODEL --load-format runai_streamer

Grove, a multi-component inference orchestration layer, ships as part of NVIDIA Dynamo. Nvidia's benchmark of Azure Blob Storage with Model Streamer reports 3x to 6x faster loading across eight H100 VMs, and a steady 80Gbps where the baseline sat near 40Gbps. Those are the vendor's own figures from the vendor's own test, which makes them a reason to measure on your storage rather than a number to put in a budget.

Both projects are worth knowing about even if you never install Run:ai, because they solve a problem every inference deployment has: the time between a node starting and a model answering requests. That time is charged to somebody, whether it is a cold-start allowance in a serverless product or a stretched autoscaling window during a traffic spike.