Skip to main content
AMD Spur Scheduler Kubernetes Operator for HPC and AI jobs, optimizing high-performance computing workloads.

Editorial illustration for AMD's Spur Scheduler Adds Kubernetes Operator for HPC and AI Jobs

AMD Open-Sources Spur GPU Scheduler for HPC

AMD's Spur Scheduler Adds Kubernetes Operator for HPC and AI Jobs

4 min read

AMD open-sourced a new GPU job scheduler called Spur on Apache 2.0, built as part of its Open Ecosystem initiative and written in Rust. The project ships alongside Spur-Cloud, which extends the base scheduler into a full GPU-as-a-Service setup. AMD's pitch is straightforward: Slurm was built for CPU-era HPC clusters and bolted on GPU support later, while Kubernetes offers strong orchestration but needs a pile of extra operators and queueing layers before it handles batch GPU jobs the way Slurm shops expect. Spur tries to close that gap directly, with a Slurm-compatible CLI and APIs, topology-aware scheduling for interconnects like XGMI, built-in high availability through Raft consensus, native Kubernetes integration, and vendor-agnostic device handling via the Container Device Interface.

The stakes are concrete. A large language model training run might need 64 MI300X GPUs spread across 8 nodes with exact locality requirements. A vision pipeline might want to split one 8-GPU node across 8 separate jobs.

Inference workloads need fast placement and teardown on hardware that isn't uniform. That's the terrain AMD says Spur was built to handle.

Traditional HPC schedulers were built in an era when CPUs dominated, and GPU support was retrofitted as an afterthought. Meanwhile, Kubernetes emerged from the cloud-native world with powerful orchestration primitives—but batch GPU scheduling and Slurm-style job workflows remain friction points unless you assemble a full ecosystem of operators, custom schedulers, and queueing layers on top of the default control plane.

Why this matters

The spur-k8s-operator is AMD's bet that GPU scheduling shouldn't force teams to choose between Slurm's batch-job muscle memory and Kubernetes' orchestration tooling. Letting a SpurJob custom resource carry an actual #SBATCH script down to spurctld is a pragmatic hack: researchers keep writing jobs the way they always have, while platform teams get the operator patterns and cluster APIs they've already built around Kubernetes. For teams running MI300x fleets, that's one less migration headache.

We'd flag the obvious question AMD hasn't answered yet: how this behaves at scale, under real multi-tenant contention, versus mature Slurm deployments with years of scheduling policy tuning baked in. A CRD that shells out to a legacy scheduler is a clean abstraction on paper, but the failure modes (queue starvation, priority inversion, operator crashes mid-submission) are where these things get tested. Worth watching whether AMD publishes benchmarks against SchedMD's own Kubernetes integrations, and whether this stays a convenience wrapper or gets treated as production infrastructure for serious HPC-AI hybrid clusters.

Common Questions Answered

What is AMD's Spur scheduler and how does it differ from Slurm for GPU workloads?

AMD's Spur is an open-source GPU job scheduler written in Rust that was designed from the ground up for GPU-era computing, whereas Slurm was originally built for CPU-dominated HPC clusters and had GPU support retrofitted later. Spur addresses the limitations of Slurm's GPU handling by providing native GPU scheduling capabilities without requiring extensive additional configuration or workarounds.

How does the Spur-k8s-operator bridge Kubernetes and traditional HPC job workflows?

The Spur-k8s-operator allows researchers to submit jobs using traditional #SBATCH scripts through a SpurJob custom resource, enabling them to maintain their existing HPC workflow patterns while leveraging Kubernetes' orchestration capabilities. This pragmatic approach eliminates the friction of choosing between Slurm's batch-job familiarity and Kubernetes' modern cloud-native tooling.

What is Spur-Cloud and what does it provide beyond the base Spur scheduler?

Spur-Cloud extends the base Spur scheduler into a full GPU-as-a-Service setup, providing a complete solution for managing GPU resources in cloud environments. It complements the core scheduler with additional capabilities needed for production GPU service delivery.

Why is AMD's open-sourcing of Spur significant for GPU scheduling in Kubernetes environments?

AMD's Spur addresses a major pain point where Kubernetes, despite its powerful orchestration primitives, requires assembling multiple operators, custom schedulers, and queueing layers to handle batch GPU jobs effectively. By providing a purpose-built GPU scheduler with Kubernetes integration, Spur eliminates the need for teams to cobble together complex ecosystems of tools to achieve Slurm-like GPU job scheduling capabilities.

What license is AMD's Spur scheduler released under?

AMD open-sourced Spur under the Apache 2.0 license as part of its Open Ecosystem initiative, making it freely available for both commercial and non-commercial use. This licensing choice promotes adoption and community contribution to the project.

LIVE20:14Monday.com cuts hundreds of jobs amid AI platform redesign