NVIDIA Opens 4 Run:ai Tools to DSX Platform [2026]

NVIDIA said on October 13, 2026 that it is making the full NVIDIA Run:ai platform available as open source software, a move that hands the company’s Kubernetes native GPU orchestration layer to any developer, startup, or research lab willing to deploy and run it themselves. The release folds Run:ai into the NVIDIA DSX AI Factory Platform, the company’s broader push to turn data centers into standardized, software defined factories for producing AI output at scale.

“NVIDIA is making the full NVIDIA Run:ai platform available as open source software, giving customers, developers, and ecosystem partners access to production-grade AI workload and GPU orchestration capabilities,” the company said in its announcement of the release. The statement frames the move less as charity and more as an infrastructure bet: get the scheduling layer for GPU clusters into as many hands as possible, then sell the support, operating system, and management tools that sit on top of it.

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech once in the Google app and our stories appear in your news suggestions.

Add Now

What NVIDIA Run:ai does and why the release matters

NVIDIA Run:ai is a Kubernetes native platform built to manage AI workload and GPU orchestration across shared infrastructure. In plain terms, it is the software that decides which job gets which GPU, how much of that GPU it gets, and when a lower priority job gets paused so a higher priority one can run. That matters because GPUs are the most expensive line item in almost every AI budget today, and a cluster that sits half idle because of poor scheduling is money spent and not used.

Before this release, Run:ai existed primarily as a commercial product that NVIDIA inherited through a 2024 acquisition of the Israeli orchestration startup of the same name. The deal brought a team with deep Kubernetes scheduling expertise into NVIDIA’s enterprise software stack, and the company has spent the time since folding that technology into its data center software roadmap. Open sourcing the platform is the clearest signal yet that NVIDIA sees orchestration software as a lever for selling more hardware and more support contracts, not as a standalone product line to protect behind a paywall.

Companies that have spent the past two years wrestling with GPU costs and utilization rates have already been experimenting with their own scheduling layers, comparing tools the way teams size up ECS against EKS for container workloads. Run:ai’s open source release gives that same crowd a GPU aware option that did not exist in a fully open form before now.

Inside the NVIDIA DSX AI Factory Platform

The open source Run:ai release is positioned as part of the NVIDIA DSX AI Factory Platform, the umbrella NVIDIA uses to describe its stack for building and operating AI focused data centers. The idea behind an “AI factory” is that a data center built for AI workloads should behave less like a collection of servers and more like a production line, with standardized hardware, standardized software, and predictable throughput measured in tokens or training steps rather than generic compute hours.

Run:ai now sits as the orchestration layer inside that factory model. NVIDIA’s supported commercial offerings, including NVIDIA DSX OS, NVIDIA Mission Control, and NVIDIA AI Enterprise, continue to require licensing or entitlement terms, but the orchestration engine underneath them is now free to deploy and self-operate. That distinction, open core plus paid support and management, mirrors a pattern that has become standard across infrastructure software, from Kubernetes itself to projects like Kubeflow.

For data center operators already tracking standards work from chipmakers and hyperscalers, including the recent grid timing standard pushed by Nvidia, AMD, Google, and Meta, the DSX framing reinforces a broader theme in 2026: the companies that control the silicon want to control more of the software stack that sits directly on top of it, while leaving room for partners to build differentiated products around the open pieces.

The four components NVIDIA is open sourcing

NVIDIA’s release breaks Run:ai into four distinct components rather than a single monolithic package. That modularity is deliberate: a team can adopt one piece, like the scheduler, without taking the entire stack, or they can run all four together as the full platform distributed through NVIDIA NGC as a Community Product with an accompanying Helm chart.

KAI Scheduler

The KAI Scheduler is the GPU aware Kubernetes scheduling engine at the center of the release. It is the component responsible for deciding which workload gets access to which GPU resources, based on queues, quotas, and priority rules set by the cluster operator. For organizations running mixed workloads, from short inference jobs to multi-day training runs, a scheduler that understands GPU topology rather than treating GPUs like generic compute slots is the difference between a cluster that hums along near capacity and one where expensive accelerators sit idle waiting for the wrong job to finish.

GPU Fractioning Operator

The GPU Fractioning Operator handles CUDA native GPU sharing, letting multiple workloads split a single physical GPU rather than requiring each job to claim an entire accelerator for itself. That matters enormously for inference workloads and smaller fine-tuning jobs that do not need a full GPU’s memory or compute budget. Splitting GPUs safely, without one workload stepping on another’s memory space, has historically required either custom tooling or accepting the waste of dedicating whole GPUs to jobs that barely use them.

KAI Resource Management and Workload Map

KAI Resource Management governs organizational quotas and hierarchy, the layer that lets an IT team say “the research division gets this many GPU hours per week, split across these teams in this priority order.” Workload Map, the fourth component, functions as a workload management contract, giving operators and higher level tools a consistent way to describe what a given AI job needs and how it should be tracked through its lifecycle. Together, the four pieces cover scheduling, sharing, governance, and description, the four jobs any serious GPU orchestration platform has to solve.

Component	Core function	Who it serves
KAI Scheduler	GPU aware Kubernetes scheduling, queues, quotas, priority	Platform and infrastructure teams
GPU Fractioning Operator	CUDA native GPU sharing across multiple workloads	ML engineers running inference and fine-tuning
KAI Resource Management	Organizational quota and hierarchy management	IT administrators and finance teams
Workload Map	Workload management contract for describing AI jobs	Tooling and orchestration integrators

Where to find the code and how licensing works

The complete source code for the release sits in the NVIDIA Run:ai repository within the NVIDIA DSX AI Factory GitHub organization. NVIDIA has also published the integrated platform on NVIDIA NGC as a Community Product, which includes a Helm chart for installing the full stack on an existing Kubernetes cluster. For teams already comfortable managing Helm based deployments, a typical installation pattern looks similar to pulling any other NGC hosted chart into a cluster:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install runai nvidia/runai --namespace runai-system --create-namespace

On licensing, NVIDIA has been explicit: no license is required to deploy and self-operate the open source software. The licensing and entitlement terms apply to NVIDIA’s supported commercial offerings, specifically NVIDIA DSX OS, NVIDIA Mission Control, and NVIDIA AI Enterprise, along with related standalone software products. In other words, a team can run the scheduler, the fractioning operator, resource management, and workload map entirely on their own, on their own hardware, without paying NVIDIA anything. What they give up is NVIDIA’s support contract, its managed operating system layer, and its enterprise tooling, which remain the paid tier sitting above the now free orchestration core.

Teams that already track Kubernetes cost reporting through tools compared in our Kubecost and OpenCost cost monitoring walkthrough will find a natural next step in attaching GPU level cost visibility to whatever the KAI Scheduler and GPU Fractioning Operator allocate, since neither of NVIDIA’s released components ships with its own cost reporting layer.

From acquisition to open source: Run:ai’s path to this release

Run:ai began as an independent Israeli startup building GPU orchestration software for enterprise AI teams, before NVIDIA agreed to acquire the company in a deal announced in 2024. That acquisition gave NVIDIA a mature Kubernetes scheduling codebase and a team that had already spent years solving the exact problem NVIDIA’s own customers were running into: too many GPUs, not enough visibility into who was using them and how efficiently.

In the time since, NVIDIA folded Run:ai into its broader enterprise software push, pairing it with the DSX branding that now covers the company’s full vision for AI focused data centers. NVIDIA Run:ai 3.0 is the version identified as the release in which the complete platform became available as open source, suggesting the two prior major versions were developed and refined under NVIDIA’s ownership as closed, commercial software before the company decided the scheduling layer itself was worth giving away.

That arc, acquire a promising orchestration company, integrate it, then open source the core engine roughly two years later, is a notable change in posture for a company that has historically guarded its software stack, from CUDA to its networking protocols, far more tightly than its hardware roadmap.

How Run:ai compares to other GPU orchestration options

NVIDIA Run:ai does not enter an empty field. Teams running large GPU clusters already choose between several established approaches to scheduling and orchestration, each with a different history and a different sweet spot.

SLURM remains the default choice in traditional high performance computing environments and national research labs, with decades of maturity in batch scheduling, queues, and reservations, though it is not Kubernetes native and was not designed around containerized AI workloads. Kubeflow takes a different angle, focusing on machine learning pipelines, notebooks, and training operators rather than acting as a GPU scheduler in its own right, which makes it complementary to a scheduler like KAI rather than a direct substitute. Volcano offers a more direct comparison, since it is a Kubernetes native batch and gang scheduler built with distributed AI and big data workloads in mind. Cloud providers round out the field with their own managed options, including GPU sharing features inside Google Kubernetes Engine and AWS’s own GPU orchestration services layered across its container and batch products.

Run:ai’s pitch against all of them is the combination it offers in one open package: AI aware Kubernetes scheduling, hierarchical quotas and fair share governance, fractional GPU enforcement down to the container level, and direct integration with NVIDIA’s own DSX stack. For teams comparing cloud GPU pricing and availability, including the gap our AWS vs Azure vs GCP GPU pricing comparison found between major clouds, a vendor neutral, self-hosted scheduler that works the same way whether the GPUs sit in a public cloud or an on-premises rack adds a genuine portability argument that fully managed cloud-native schedulers cannot match.

Platform	Primary strength	Kubernetes native	Relationship to Run:ai
NVIDIA Run:ai	AI aware scheduling, quotas, GPU fractioning, DSX integration	Yes	The subject of this release
SLURM	Mature HPC batch scheduling and reservations	No	Alternative for traditional supercomputing clusters
Kubeflow	ML pipelines, notebooks, training operators	Yes	Complementary rather than a direct scheduler replacement
Volcano	Kubernetes batch and gang scheduling	Yes	Closest direct open source scheduling alternative
Google Kubernetes Engine GPU sharing	Managed GPU sharing inside GKE	Yes	Cloud managed alternative for GKE users
AWS GPU orchestration	Managed cluster and batch GPU services	Partial	Cloud specific alternative on AWS infrastructure

Why NVIDIA is giving away its orchestration layer

The strategic logic behind the release is not hard to follow once you look at where NVIDIA actually makes its money. NVIDIA sells GPUs, networking, and increasingly entire rack scale systems. Software that makes those GPUs easier to deploy, share, and keep busy increases the value of every chip NVIDIA sells, regardless of whether NVIDIA charges separately for the scheduler itself. An open, widely adopted orchestration layer also makes it easier for NVIDIA’s hardware to win in environments where a customer’s internal platform team, not NVIDIA, chooses the software stack, since that team is far more likely to standardize on something they can inspect, modify, and run without a new procurement cycle.

There is also an ecosystem argument. As NVIDIA put it in its own description of the release, the move “expands the NVIDIA DSX AI Factory Platform by establishing NVIDIA Run:ai as an open foundation that enables the broader ecosystem to bring differentiated solutions to market faster in response to evolving customer needs.” Read plainly, that means NVIDIA wants partners, from cloud providers to systems integrators, building products on top of Run:ai rather than building their own competing schedulers from scratch. Every partner that adopts KAI Scheduler instead of rolling a custom one becomes another channel reinforcing NVIDIA’s software stack as the default for GPU infrastructure.

That framing fits a pattern NVIDIA chief executive Jensen Huang has described in public remarks about the company’s broader data center strategy, describing the shift toward facilities “that specialize in producing intelligence tokens, essentially AI factories.” Treating the orchestration software as open infrastructure, rather than a locked commercial product, is consistent with building out that factory model as widely and as fast as possible.

Market impact for cloud providers and enterprise AI teams

For enterprise infrastructure teams, the immediate impact is practical rather than dramatic. Teams that were already running Run:ai under a commercial license gain the option to self-host the same components without a license fee, while teams that had ruled out Run:ai because of cost now have a reason to evaluate it alongside Volcano and custom Kubernetes scheduling setups. Platform teams that manage multi-cloud Kubernetes deployments, the same audience that follows our Terraform and Kubernetes multi-cloud walkthrough, get a GPU aware scheduler that can, in principle, sit consistently across on-premises clusters and public cloud Kubernetes services alike.

Cloud providers face a more complicated calculation. NVIDIA’s partners, including GPU cloud specialists that have already begun preparing integrations around the open release, benefit from a common orchestration layer they can offer customers without building it themselves. Hyperscalers with their own competing GPU scheduling features inside their managed Kubernetes offerings face a new open alternative that customers can run identically whether they stay on that provider or move workloads elsewhere, which weakens one of the lock-in arguments cloud providers have historically used to keep GPU workloads inside their own managed services.

The broader AI chip market context matters here too. With NVIDIA’s position in some regions facing new competitive pressure, as seen in the shifting shares detailed in our coverage of Nvidia’s falling China AI chip share against Huawei, strengthening the software layer that sits on top of NVIDIA GPUs is one lever the company controls more directly than chip supply or export policy. A better, freely available orchestration stack gives customers one more reason to standardize on NVIDIA hardware even as alternatives gain ground in specific markets.

Historical context: open sourcing the infrastructure layer

NVIDIA’s move follows a well-worn playbook in infrastructure software. Kubernetes itself began as an internal Google project before Google open sourced it in 2014, a decision that helped Kubernetes become the default container orchestration standard rather than one of several competing proprietary systems. Docker’s own container runtime went through a similar arc, as did large parts of the Hadoop and Spark ecosystems a decade earlier. In each case, the company that opened its core infrastructure software did not give up its commercial position, it expanded the addressable market for the paid products built around that open core.

Applied to NVIDIA’s situation, the comparison is direct: NVIDIA is not in the business of selling Kubernetes schedulers, it is in the business of selling GPUs and the systems built around them. Giving away the orchestration software removes a reason for customers to look elsewhere for scheduling, while NVIDIA’s commercial offerings, DSX OS, Mission Control, and AI Enterprise, capture the revenue from operators who want a supported, managed version of the same stack rather than one they maintain themselves.

What enterprise infrastructure teams should do next

Teams running mixed GPU workloads on Kubernetes now have a reasonably clear set of next steps. First, evaluate whether the KAI Scheduler’s queue, quota, and priority model maps cleanly onto how the organization already allocates GPU budgets across teams, since migrating scheduling logic is rarely a drop-in replacement. Second, test the GPU Fractioning Operator against real inference workloads before committing production traffic to shared GPUs, since memory isolation guarantees matter more once multiple tenants depend on the same physical accelerator. Third, decide early whether the team wants to self-operate the open source stack or pay for one of NVIDIA’s supported offerings, since that decision affects staffing and on-call expectations far more than it affects day one functionality.

Teams already comparing managed container options, the way our ECS versus EKS cost breakdown lays out the tradeoff between a fully managed service and a self-operated cluster, will recognize the same fork in the road here: Run:ai’s open source components are free to run, but running them well at scale still requires the kind of dedicated platform engineering time that NVIDIA’s paid support tier exists to replace.

Predictions: where GPU orchestration goes from here

Expect at least one major cloud provider or GPU cloud specialist to announce a managed Run:ai offering within the next two to three quarters, packaging the open source components as a hosted service rather than building a competing scheduler from scratch.
Volcano and Kubeflow maintainers will likely face pressure to clarify how their projects interoperate with Run:ai’s components, since customers will want to know whether they can mix and match rather than choosing one stack exclusively.
NVIDIA’s commercial DSX OS, Mission Control, and AI Enterprise tiers will increasingly be marketed around support, compliance, and multi-cluster management features rather than core scheduling functionality, now that the scheduling engine itself is free.
Enterprises running smaller GPU fleets will adopt the GPU Fractioning Operator faster than large hyperscale operators, since the cost savings from sharing GPUs matter proportionally more to teams without the scale to keep every GPU fully booked already.
Competing chipmakers and their software partners will come under more pressure to offer an equivalent open orchestration layer, since a free, GPU aware Kubernetes scheduler tied to NVIDIA hardware raises the bar for what customers expect from any GPU vendor’s software stack.

Frequently asked questions

Is NVIDIA Run:ai completely free now?

The core platform, including the KAI Scheduler, GPU Fractioning Operator, KAI Resource Management, and Workload Map, is free to deploy and self-operate with no license required. NVIDIA’s supported commercial offerings, NVIDIA DSX OS, NVIDIA Mission Control, and NVIDIA AI Enterprise, still carry licensing or entitlement terms.

Where can developers get the NVIDIA Run:ai source code?

The source code is published in the NVIDIA Run:ai repository within the NVIDIA DSX AI Factory GitHub organization. The full integrated platform is also distributed through NVIDIA NGC as a Community Product, including a Helm chart for installation.

What is the NVIDIA DSX AI Factory Platform?

DSX is NVIDIA’s umbrella platform for building and operating data centers dedicated to AI workloads, combining open components like the newly released Run:ai orchestration layer with supported commercial software such as DSX OS and Mission Control.

How is the GPU Fractioning Operator different from the KAI Scheduler?

The KAI Scheduler decides which GPU fraction a workload should receive based on queues, quotas, and priority. The GPU Fractioning Operator then enforces that allocation at runtime, ensuring the memory boundary between workloads sharing the same physical GPU is actually respected.

Does open sourcing Run:ai affect existing paying customers?

NVIDIA has not indicated that existing commercial customers lose any functionality. The change gives customers the option to self-operate the open components, while NVIDIA’s supported offerings continue to carry their existing licensing and entitlement terms for teams that prefer a managed experience.

How does Run:ai compare to SLURM for AI workloads?

SLURM remains the standard in traditional high performance computing environments with decades of batch scheduling maturity, but it was not built as Kubernetes native software. Run:ai targets teams already standardized on Kubernetes who need GPU aware scheduling, fractional GPU sharing, and hierarchical quota management inside that same container ecosystem.

Can Run:ai’s components be used independently of each other?

Yes. NVIDIA has described the GPU Fractioning Operator as scheduler agnostic, meaning teams can combine individual components, such as using only the KAI Scheduler or only the fractioning operator, alongside their existing Kubernetes platform rather than adopting the entire Run:ai stack at once.

When exactly did NVIDIA make this announcement?

NVIDIA’s announcement is dated October 13, 2026, and the company says the open source release, tied to NVIDIA Run:ai 3.0, is available immediately.

NVIDIA Run:ai Goes Open Source With 4 GPU Tools [2026]