Kueue vs Volcano vs KAI Scheduler: Kubernetes GPU Scheduling Compared (2026)

Kueue vs Volcano vs NVIDIA’s KAI Scheduler is the 2026 decision for Kubernetes GPU scheduling - and the short answer is that they occupy three different layers: Kueue queues and admits jobs against quotas while kube-scheduler places pods, Volcano replaces the scheduling path entirely with a batch-native engine, and KAI Scheduler runs as an opt-in secondary scheduler built GPU-first. Which one fits depends on how invasive you can afford to be and how much GPU-specific capability you need.

This guide compares the three on architecture, gang scheduling, quota and fairness, GPU sharing, and AI/ML workload fit, then gives a verdict by cluster profile.

The short answer

Pick Kueue if:

• You want job queueing and multi-team quota with zero changes to pod placement
• You run on managed Kubernetes (EKS, AKS, GKE) where replacing the scheduler is unattractive
• Your workloads are Jobs, JobSets, Kubeflow training jobs, or Ray - all supported natively
• You value staying inside the Kubernetes project: Kueue is a SIG Scheduling subproject, at v0.19 as of September 2026

Pick Volcano if:

• You need gang scheduling enforced at placement time for distributed training
• You want GPU sharing - vGPU, dynamic MIG, HAMi integration - from the scheduler itself
• You need DRF fairness, task topology, and network topology aware scheduling for communication-heavy jobs
• You are comfortable operating a CNCF incubating replacement scheduler (v1.15, May 2026)

Pick KAI Scheduler if:

• Your cluster is GPU-first and utilization is the metric that matters
• You want fractional GPUs, hierarchical queues with borrowing and reclaim, and NVLink-aware placement without buying the commercial Run:ai platform
• You accept a younger project: open-sourced April 2025, CNCF Sandbox since December 2025, smaller community than the other two

Deciding factors at a glance

Architecture: admission layer vs scheduling engine

The core of the Kueue vs Volcano comparison is where each tool sits.

Kueue deliberately avoids duplicating mature Kubernetes components. It intercepts workload creation, suspends the job, and holds it in a queue until its ClusterQueue has quota; then it admits the job and steps aside. Kube-scheduler places the pods and the cluster autoscaler provisions nodes exactly as before. That non-invasive shape is why Kueue has become the default answer on managed clusters.

Volcano is a real scheduler with a plugins-and-actions framework. Pods that set schedulerName: volcano get batch-native placement logic: gang constraints, fairness, bin-packing, topology. You gain control over placement itself and take on responsibility for a scheduling engine in the critical path.

KAI Scheduler splits the difference operationally: it runs alongside kube-scheduler as a secondary scheduler, handling only pods that opt in via schedulerName: kai-scheduler. Unlike Kueue it does real placement; unlike Volcano it never touches workloads that did not ask for it. It ships from the same codebase that powers NVIDIA’s commercial Run:ai platform, with weekly-cadence releases (v0.17 as of September 2026).

Gang scheduling

Distributed training dies without all-or-nothing placement - 63 of 64 workers running is 100% of the cost for 0% of the progress.

• Kueue guarantees gangs at the admission layer: a JobSet or RayJob stays suspended until quota for the whole workload exists. Strong for preventing partial starts; it cannot react at placement time if capacity fragments after admission.
• Volcano enforces gangs in the scheduler, and v1.15 added gang-granularity preemption - when preemption is needed, it evaluates at job level and evicts surplus replicas rather than randomly shooting pods out of a training job.
• KAI Scheduler gang-schedules through PodGroups with atomic placement, inherited from years of Run:ai production use.

For serious multi-node training, placement-time gang enforcement (Volcano, KAI) is the stronger guarantee; Kueue’s admission-level model is often enough for single-node jobs and moderate-scale training.

Quota, fairness, and multi-tenancy

• Kueue: ClusterQueues own quota pools, LocalQueues expose them per namespace, cohorts let queues borrow unused quota from each other, and fair sharing plus preemption policies keep tenants honest. MultiKueue dispatches jobs across clusters - unique among the three and a big deal for organizations with GPU capacity spread over regions.
• Volcano: queue capacity management with DRF (Dominant Resource Fairness), unified multi-tenant quota limits, and v1.15 scheduling gates for queue admission control.
• KAI Scheduler: hierarchical queues (department, then team) with fair-share borrowing and reclaim, plus time-based fair-share recalculation that continuously rebalances as demand shifts - the most refined tenant model of the three for GPU clusters, reflecting its Run:ai lineage.

GPU sharing and DRA

This is where kubernetes gpu scheduling gets concrete. Whole-GPU allocation wastes most of an H100 on small inference services.

• Volcano supports software vGPU sharing and dynamic MIG partitioning, integrates with HAMi for hard-isolated fractions with queue-level vGPU limits, and added exclusive-GPU support and vGPU preemption in v1.15. Its capacity plugin now counts DRA ResourceClaims against queue quota.
• KAI Scheduler ships fractional GPU sharing natively, has adopted HAMi-core for isolation, supports bin-packing versus spread placement policies to consolidate or protect workloads, and is NVLink-domain aware for multi-GPU placement. DRA-based sharing via ResourceClaims is supported.
• Kueue does not share GPUs - it counts them. Its DRA support (alpha, ResourceClaimTemplate-only) maps device classes into quota so ClusterQueues can govern GPU consumption, but the sharing mechanism must come from the driver or another scheduler.

Context for all three: Dynamic Resource Allocation went GA in Kubernetes 1.34, NVIDIA donated its GPU DRA driver to the community at KubeCon EU 2026, and successive releases through 1.37 have been graduating DRA extensions. Every scheduler in this comparison is mid-migration from device plugins to DRA - treat DRA paths as supported but still hardening.

AI/ML workload fit

• Training-heavy clusters need gang scheduling, topology awareness, and preemption that respects job boundaries: Volcano or KAI. Volcano’s network topology aware scheduling reduces cross-switch traffic for large distributed jobs; KAI’s NVLink awareness targets the intra-node fabric.
• Inference-heavy clusters need fractional GPUs and bin-packing to stack services densely: KAI or Volcano with HAMi. Pair the scheduler with the right serving engine - our vLLM vs TGI vs Triton benchmark covers that layer.
• Mixed research platforms with many teams sharing capacity need quota governance first: Kueue, possibly with Volcano underneath. The documented split - Kueue decides when to admit, Volcano decides where to place - is the strongest pattern for large multi-team platforms. The equivalent Kueue-plus-KAI combination is still an open integration issue rather than a shipped pattern, so validate it yourself before committing.

Sovereign AI in the UAE and GCC

GPU scheduling is quietly a sovereignty topic. UAE and Saudi enterprises building sovereign AI infrastructure - national LLMs, government inference platforms, regulated in-country training - buy scarce, expensive accelerator capacity and cannot burst to a US region when a queue backs up. That makes scheduler-level utilization the difference between one H100 cluster and two: hierarchical quotas keep ministries and business units inside their allocations, fractional GPUs stop 80-gigabyte cards idling under 7B-parameter inference services, and gang scheduling protects the long training runs that justify the hardware in the first place. All three schedulers here are Apache 2.0 open source with no phone-home dependency, which matters for air-gapped and classified deployments. Our AI/ML Infrastructure practice designs exactly this layer for GCC clusters - scheduler selection included.

Verdict by cluster profile

• Managed cloud cluster, mixed batch + services, multiple teams: Kueue. Non-invasive, upstream, MultiKueue for multi-cluster later.
• Dedicated training cluster, large distributed jobs: Volcano. Mature gang scheduling, topology awareness, and the deepest batch feature set.
• GPU-dense cluster chasing utilization, inference + training mix: KAI Scheduler. Fractional GPUs, hierarchical fair share, and bin-packing - accepting Sandbox-stage maturity.
• Large multi-team AI platform: Kueue + Volcano, with Kueue governing admission and Volcano placing pods.

FAQ

Kueue vs Volcano: which should I use? Kueue for quota and queueing without replacing the scheduler - best on managed clusters. Volcano for placement-time gang scheduling, DRF fairness, and GPU sharing - best on dedicated batch clusters. Large platforms run both: Kueue admits, Volcano places.

What is NVIDIA KAI Scheduler? Run:ai’s scheduling engine, open-sourced April 2025 and CNCF Sandbox since December 2025. A secondary scheduler with gang scheduling, hierarchical fair-share queues, fractional GPUs, and NVLink-aware placement for opted-in pods.

Does Kueue replace kube-scheduler? No. Kueue only queues and admits workloads against quotas; kube-scheduler still places every pod. Volcano and KAI do their own placement for pods that select them.

Which scheduler supports gang scheduling? All three: Kueue at admission (all-or-nothing quota), Volcano and KAI at placement (PodGroups, atomic scheduling). Placement-time enforcement is stronger for large distributed training.

How do the three handle GPU sharing? Volcano: vGPU, MIG, HAMi, v1.15 vGPU preemption. KAI: native fractional GPUs with HAMi-core isolation. Kueue: quota accounting only - sharing comes from the driver or another scheduler.

Can I run Kueue and Volcano or KAI together? Kueue + Volcano is documented and proven. Kueue + KAI is architecturally sensible but still an open integration as of late 2026.

How NomadX Kubernetes Delivers

NomadX Kubernetes runs GPU scheduling and AI platform work as fixed-scope sprints:

• 5-day GPU Scheduling Assessment - measures real GPU utilization, maps workload profiles, and recommends Kueue, Volcano, KAI, or a combination per cluster
• 3-4 week Scheduler Implementation Sprint - deploys and tunes the chosen scheduler, configures queues, quotas, gang policies, and GPU sharing, and validates behavior under contention with safe rollback
• AI Platform Buildout - the full AI/ML infrastructure engagement: scheduling, serving, MLOps, and sovereignty controls for GCC enterprises

Book a free 30-minute discovery call to scope your Kubernetes GPU scheduling engagement with a NomadX Kubernetes engineer.