The 10 Best GPU Orchestration Tools for Kubernetes in 2027
By Kory White · Updated Oct 2026 · 6 min read
Direct answer
NVIDIA Run:ai is the best GPU orchestration tool for Kubernetes: NVIDIA describes it as the open source AI workload and GPU orchestration platform, with fractional GPU sharing and fairness policies. KAI Scheduler, its scheduler core, is #2, and Kueue is #3. All ten are free open source; Run:ai standalone support pricing is not published.
Free open source under Apache License 2.0; commercially supported versions come through NVIDIA DSX OS, NVIDIA Mission Control, NVIDIA AI Enterprise or standalone software, and standalone pricing is not published (Contact NVIDIA)
Platform teams that want one governed GPU pool shared by many teams, with a commercial support path
HPC and research teams that want Slurm job semantics on a Kubernetes GPU cluster
Pick by what you want
Best overall
NVIDIA Run:ai
Best standalone scheduler
KAI Scheduler
Best upstream job queue
Kueue
Best batch scheduler
Volcano
Best for NVIDIA GPU setup
NVIDIA GPU Operator
Best for Ray
KubeRay
Best fractional GPU sharing
HAMi
Best across clusters and clouds
SkyPilot
Best in core Kubernetes
Dynamic Resource Allocation
Best for Slurm users
Slinky Slurm Operator
The ranking
1
NVIDIA Run:ai
Answrs VerdictThe full GPU orchestration platform, now open source and owned by NVIDIA.
Price: Free open source under Apache License 2.0; commercially supported versions come through NVIDIA DSX OS, NVIDIA Mission Control, NVIDIA AI Enterprise or standalone software, and standalone pricing is not published (Contact NVIDIA)What it is: Described as the open source AI workload and GPU orchestration platform for Kubernetes, covering training, fine-tuning and inferenceFeatures: Dynamic GPU allocation, policy-driven governance with quotas, priorities and fairness, fractional GPU sharing and GPU memory swapOwnership: NVIDIA announced a definitive agreement to acquire Run:ai on April 24, 2024, and the Run:ai GitHub organization now says Run:ai is part of NVIDIAOpen source: The repository ships a control plane, a per-cluster component and an installer, its scheduler ships the KAI Scheduler, and it shows 599 stars
NVIDIA Run:ai is described as the open source AI workload and GPU orchestration platform for Kubernetes, for training, fine-tuning and inference. It offers dynamic GPU allocation, policy-driven governance with quotas, priorities and fairness, and fractional GPU sharing with GPU memory swap. The code is Apache License 2.0 and includes a control plane, a per-cluster component and an installer. NVIDIA announced a definitive agreement to acquire Run:ai on April 24, 2024, and the Run:ai GitHub organization now says it is part of NVIDIA. Commercially supported versions come through NVIDIA DSX OS, NVIDIA Mission Control, NVIDIA AI Enterprise or standalone, and standalone pricing is not published.
Go ifPlatform teams that want one governed GPU pool shared by many teams, with a commercial support path
Skip ifYou want a single small component rather than a full platform
Why #1 over #2: It is a full platform with governance and a control plane, where KAI Scheduler is the scheduler core alone.
2
KAI Scheduler
Answrs VerdictThe scheduler core on its own, with GPU sharing and fair-share queues.
Price: Free open source under the Apache-2.0 licenseScheduling: Gang scheduling, packing and spreading, and topology-aware scheduling for GPU-heavy AI and ML workloadsQueues: Hierarchical queues with quotas and fair-share policies, including Dominant Resource FairnessGPU sharing: Multiple workloads can share GPUs, and elastic workloads can scale within set minimum and maximum boundsStatus: Described as a Cloud Native Computing Foundation sandbox project, built on kube-batch; the repository shows 1,598 stars
KAI Scheduler is a Kubernetes-native scheduler for GPU-heavy AI and ML workloads, built on kube-batch and described as a Cloud Native Computing Foundation sandbox project. It does gang scheduling, packing and spreading, topology-aware scheduling, hierarchical queues with fair-share including Dominant Resource Fairness, and GPU sharing. It is free under Apache-2.0 and shows 1,598 stars.
Go ifTeams that want Run:ai-style scheduling and fair-share queues as a standalone scheduler
Skip ifYou need a UI and policy console out of the box
Why #2 over #3: It adds GPU sharing and topology-aware placement, where Kueue only manages admission and quotas.
3
Kueue
Answrs VerdictThe upstream-native job queue and quota manager.
Price: Free open source under Apache-2.0What it does: A Kubernetes-native system that manages quotas and how jobs consume them, deciding when a job waits, is admitted or is preemptedFair sharing: Quotas and policies for fair sharing among tenants, resource flavor fungibility and preemption policies between tenantsIntegrations: Batch Jobs, JobSet, plain Pods, Deployments, StatefulSets and LeaderWorkerSet, with RayCluster, RayJob and RayService listed as StableScope: Does not replace kube-scheduler, which keeps pod-to-node placement; the repository shows 3,100 stars
Kueue is a Kubernetes-native system that manages quotas and how jobs consume them, deciding when a job waits, is admitted or is preempted. It supports fair sharing among tenants and resource flavor fungibility, and integrates with Batch Jobs, JobSet, Pods, Deployments, StatefulSets and LeaderWorkerSet, with RayCluster, RayJob and RayService listed as Stable. It leaves pod placement to kube-scheduler. It is Apache-2.0 and shows 3,100 stars.
Go ifTeams that want queueing and quotas layered on the default Kubernetes scheduler
Skip ifYou need gang placement and GPU sharing inside a replacement scheduler
Why #3 over #4: It keeps the default Kubernetes scheduler, where Volcano replaces it.
4
Volcano
Answrs VerdictThe most mature batch scheduler, with GPU virtualization built in.
Price: Free open source under Apache-2.0Scheduling: Gang scheduling, binpack, DRF, NUMA-aware and task-topology policies, plus multi-level queues with borrowing, reclaiming and preemptionGPU: GPU virtualization through dynamic NVIDIA MIG, vCUDA and multi-container GPU sharingFrameworks: Schedules Spark, TensorFlow, PyTorch, Flink, Argo and RayStatus: A Cloud Native Computing Foundation incubating project; the repository shows 6,030 stars
Volcano is a Cloud Native Computing Foundation incubating batch scheduler for Spark, TensorFlow, PyTorch, Flink, Argo and Ray. It offers gang scheduling, binpack, DRF, NUMA-aware and task-topology policies, multi-level queues with borrowing, reclaiming and preemption, and GPU virtualization through dynamic NVIDIA MIG, vCUDA and multi-container GPU sharing. It is Apache-2.0 and shows 6,030 stars.
Go ifBatch, HPC and distributed training teams that want a full replacement batch scheduler
Skip ifYou want to keep the default scheduler and only add quotas
Why #4 over #5: It bundles GPU virtualization with batch scheduling, where the GPU Operator does neither.
5
NVIDIA GPU Operator
Answrs VerdictThe required foundation for NVIDIA GPUs, not a scheduler.
Price: The operator source code and Helm chart are Apache 2.0; the page does not state a price, and most images fall under NVIDIA product-specific termsWhat it automates: GPU drivers, the Kubernetes device plugin, the NVIDIA Container Toolkit, GPU Feature Discovery node labeling and DCGM-based monitoringAlso lists: MIG Manager, vGPU Device Manager and KubeVirt GPU Device Plugin among its componentsScope: Provisions and manages GPUs on nodes; it is not a job queue or schedulerOpen source: The repository shows 2,933 stars under Apache-2.0
NVIDIA GPU Operator automates the NVIDIA software needed to provision GPUs in Kubernetes: drivers, the device plugin, the Container Toolkit, GPU Feature Discovery node labeling and DCGM-based monitoring. The operator source code and Helm chart are Apache 2.0, while most component images fall under NVIDIA product-specific terms, and the page states no price. It provisions GPUs and is not a job scheduler. The repository shows 2,933 stars.
Go ifAnyone running NVIDIA GPUs on Kubernetes, as the layer underneath every scheduler here
Skip ifYou are looking for job queueing or fair-share scheduling
Why #5 over #6: It is the layer every NVIDIA cluster needs, where KubeRay serves only Ray users.
6
KubeRay
Answrs VerdictThe standard way to run Ray on Kubernetes.
Price: Free open source under Apache-2.0Custom resources: RayCluster, RayJob and RayService manage clusters, jobs and serving applicationsAutoscaling: Optional autoscaling lets the operator size Ray clusters as the workload needsHardware: Supports heterogeneous compute nodes, including GPUs, and multiple Ray versions in one Kubernetes clusterOpen source: The repository shows 2,739 stars
KubeRay adds RayCluster, RayJob and RayService custom resources for running Ray on Kubernetes, with optional autoscaling, support for heterogeneous nodes including GPUs, and multiple Ray versions in one cluster. It is Apache-2.0 and the repository shows 2,739 stars.
Go ifTeams running Ray for training, batch inference or serving on Kubernetes
Skip ifYou do not use Ray
Why #6 over #7: It runs Ray natively, where HAMi shares GPUs but does not run any framework.
7
HAMi
Answrs VerdictThe best fractional GPU sharing here, across many vendors.
Price: Free open source under Apache License 2.0GPU sharing: Workloads can request a fraction of an accelerator by memory, cores or device count, for example one GPU with about 3 GB of GPU memoryScheduling: Binpack, spread, topology-aware, mutex and NUMA-based policiesVendors: NVIDIA GPUs with MIG, AMD GPUs, Huawei Ascend, Cambricon, Hygon and others, with feature support varying by vendorStatus: A CNCF Incubating project, formerly k8s-vGPU-scheduler; the repository shows 4,912 stars
HAMi, a CNCF Incubating project formerly called k8s-vGPU-scheduler, lets workloads request a fraction of an accelerator by memory, cores or device count, for example one GPU with about 3 GB of GPU memory. It supports binpack, spread, topology-aware, mutex and NUMA-based policies across NVIDIA with MIG, AMD, Huawei Ascend and other vendors, with support varying by vendor. It is Apache License 2.0 and shows 4,912 stars.
Go ifTeams that need to split a GPU between small inference jobs, including mixed vendors
Skip ifYour jobs each need whole GPUs
Why #7 over #8: It shares GPUs across many vendors, where SkyPilot decides where jobs run.
8
SkyPilot
Answrs VerdictThe user-facing launcher that spans Kubernetes and clouds.
Price: Free open source under Apache-2.0Kubernetes: Runs tasks on an existing cluster (EKS, GKE, on-prem, Kubeadm, Rancher, K3s) and does not provision new clusters or nodesGPU: The sky gpus list command with --infra k8s shows real-time GPU availability per nodeMulti-cluster: Multi-node jobs run one pod per node, with failover to another cluster or cloud if scheduling failsReach: The README lists 25 supported targets, including Kubernetes, Slurm, AWS, GCP and Azure; the repository shows 10,726 stars
SkyPilot runs tasks on an existing Kubernetes cluster (EKS, GKE, on-prem, Kubeadm, Rancher, K3s) without provisioning new clusters or nodes. It shows real-time GPU availability per node, runs multi-node jobs as one pod per node, and fails over to another cluster or cloud if scheduling fails. The README lists 25 supported targets. It is Apache-2.0 and shows 10,726 stars.
Go ifResearchers who want one launch command across Kubernetes clusters and clouds
Skip ifYou need cluster-side fair-share quotas for many tenants
Why #8 over #9: It reaches across clusters and clouds, where Dynamic Resource Allocation lives inside one cluster.
9
Dynamic Resource Allocation
Answrs VerdictThe core Kubernetes API for devices, with no queueing on top.
Price: Built into Kubernetes, with no separate priceStatus: Stable since Kubernetes v1.35, first available in v1.30How it works: Device drivers and admins define device classes, workloads claim them, and Kubernetes allocates matching devices and places PodsSharing: Multiple containers or Pods can share one device through a resource claim, with CEL filtering on device attributesLimit: The Kubernetes scheduler does not support preemption for DRA resources
Dynamic Resource Allocation lets device drivers and admins define device classes that workloads claim, after which Kubernetes allocates matching devices and places Pods. It has been stable since Kubernetes v1.35, first available in v1.30, supports sharing one device across containers or Pods, and filters devices with CEL. The Kubernetes scheduler does not support preemption for DRA resources. It is built into Kubernetes with no separate price.
Go ifClusters that want vendor-neutral, per-workload GPU requests in core Kubernetes
Skip ifYou need queues, fair-share or preemption
Why #9 over #10: It is part of core Kubernetes, where Slinky adds a second scheduler, Slurm.
10
Slinky Slurm Operator
Answrs VerdictSlurm users get Kubernetes without leaving Slurm.
Price: Free open source under Apache-2.0What it does: A Kubernetes operator that deploys and manages parts of Slurm clusters on KubernetesOwnership: NVIDIA describes Slinky as an open source project developed by SchedMD, now part of NVIDIA, and says Slurm and Slinky support, training and consultation services are available from NVIDIA with no price givenResources: NodeSets for worker nodes with replica or one-pod-per-node scaling, and LoginSets for login nodesScaling: Scale to zero is supported for NodeSets and LoginSets, and Slurm components can run partly outside KubernetesMaturity: The repository shows 377 stars, and community issues are handled on a best effort basis
Slinky Slurm Operator, developed by SchedMD (now part of NVIDIA), deploys and manages parts of Slurm clusters on Kubernetes. NodeSets scale by replica or one pod per node, LoginSets provide login nodes, scale to zero is supported, and components can run partly outside Kubernetes. It is Apache-2.0, shows 377 stars, and community issues are handled on a best effort basis. NVIDIA says Slurm and Slinky support, training and consultation services are available from NVIDIA, with no price given.
Go ifHPC and research teams that want Slurm job semantics on a Kubernetes GPU cluster
Skip ifYour team does not already use Slurm
How we ranked these
We ranked tools that orchestrate GPU workloads on Kubernetes first (platforms and schedulers), then the node setup layer, the framework operators and the launchers, using each project’s own site, documentation and repository. Prices are shown only where published; all ten are free open source. NVIDIA Run:ai’s ownership is taken from NVIDIA’s April 24, 2024 announcement and the Run:ai GitHub organization. The chart counts GitHub stars as displayed on each repository, and DRA is not charted because it ships inside Kubernetes. Facts are taken from each maker's own published information; check the official site before you buy.
Questions people ask
What is the best GPU orchestration tool for Kubernetes?
NVIDIA Run:ai is our top pick: it is described as the open source AI workload and GPU orchestration platform for Kubernetes, with fractional GPU sharing, quotas and fairness policies. KAI Scheduler, its scheduler core, is #2.
Is Run:ai still a separate company?
NVIDIA announced a definitive agreement to acquire Run:ai on April 24, 2024, and the Run:ai GitHub organization now says Run:ai is part of NVIDIA. NVIDIA describes the platform as fully open source.
What are good Run:ai alternatives?
Kueue, Volcano and HAMi are free Apache-licensed alternatives for queueing, batch scheduling and GPU sharing. KAI Scheduler is the scheduler that ships inside Run:ai.
Do I need the NVIDIA GPU Operator if I use a scheduler?
Yes for NVIDIA GPUs. The GPU Operator automates the drivers, device plugin, container toolkit, node labeling and monitoring; it does not queue or schedule jobs, so it sits under the schedulers on this list.
GitHub stars on each project’s repository at a glance
Slinky Slurm Operator377 stars
NVIDIA Run:ai599 stars
KAI Scheduler1,598 stars
KubeRay2,739 stars
NVIDIA GPU Operator2,933 stars
Kueue3,100 stars
HAMi4,912 stars
Volcano6,030 stars
SkyPilot10,726 stars
GitHub stars on each project’s repository, as published by each maker. Picks without a published figure are left off.