AMD put Spur forward publicly on August 7, an Apache 2.0 job scheduler written in Rust that answers to sbatch, squeue and scancel exactly like Slurm does. The pitch is that GPU clusters have outgrown a scheduler designed when CPUs were the interesting resource, and that the way to fix it is not to ask anyone to rewrite their batch scripts. There is a second thing worth noticing about the timing. NVIDIA acquired SchedMD, the company behind Slurm, in December 2025. Eight months later AMD has an alternative that reads the same job files. We looked at what Spur actually does differently, and at how much of the compatibility promise is finished.
The short answer
Spur is a GPU first job scheduler AMD wrote in Rust and released under Apache 2.0. It replicates cluster state with embedded Raft consensus rather than an external database, injects accelerators through the Container Device Interface rather than vendor plugins, carries WireGuard mesh networking for multi site clusters, and submits Kubernetes work into the same GPU pool as batch jobs. Crucially it accepts existing Slurm commands and batch directives, so adopting it does not start with rewriting job scripts. Compatibility is explicitly still growing.
Every cluster admin who has migrated a scheduler knows where the pain actually lives, and it is not in the scheduler. It is in the four hundred batch scripts that assume #SBATCH --gres=gpu:4 means something, the monitoring that parses squeue output, and the one researcher whose pipeline has been running since 2019 and who will not be rewriting anything. AMD appears to have understood this, because Spur's headline feature is not a scheduling algorithm. It is that your existing scripts still work.
What Spur is, and what it is made of
Spur is a job scheduler written in Rust, developed by AMD as part of its open ecosystem work and published under Apache 2.0 at github.com/ROCm/spur. Anush Elangovan, AMD's corporate vice president for AI software, put it forward publicly on August 7, with the ROCm engineering write up having gone up earlier in the summer.
The daemons will look familiar to anyone who has run Slurm, deliberately so. spurctld is the controller, holding cluster state and making scheduling decisions over gRPC on port 6817. spurd runs on each compute node, discovering resources and executing jobs, on port 6818. spurrestd exposes the REST API. spur-cli is a multi call binary, which is the neat part: invoked as sbatch it behaves as sbatch, the same trick busybox uses, which is why dropping it into a PATH ahead of the real Slurm tools is enough to redirect submissions.
The argument for building it at all is that Slurm comes from a world where the scheduler's job was to allocate CPU cores and memory, and GPUs were bolted on afterwards as a generic resource. That is a fair description of history. The alternative most sites reach for is Kubernetes, and there the complaint is different: you assemble a working batch system out of device plugins, a scheduler like Volcano and a queue manager like Kueue, and the result is several projects deep before a training job runs. Spur's claim is that GPU awareness belongs in the scheduler's core rather than in an adapter.
What that means concretely is topology awareness. When a training run wants sixty four MI300X accelerators wired together over XGMI, the placement across eight nodes is not interchangeable, because the interconnect between two GPUs on the same node is nothing like the link between two racks. A scheduler that treats accelerators as a countable resource will happily hand you a topologically terrible allocation that satisfies the request and runs at a fraction of the speed.
The parts that are genuinely different
Three choices here are worth the attention of anyone who operates clusters rather than reads about them.
The state handling is the one we would care about first. Spur embeds Raft consensus inside the controller, so scheduling state replicates between controller replicas with automatic leader election and no external database. Compare that with what a redundant Slurm control plane needs: a backup controller, a state directory both controllers can reach on shared storage, and slurmdbd in front of MySQL for accounting. Removing the shared filesystem dependency from a scheduler's failure path is not a small thing, because in practice that filesystem is the component that takes the whole cluster down. AMD quotes sub-second failover. Raft brings its own constraint, which is that losing quorum stops scheduling entirely, so a two node control plane is not redundancy.
Device handling goes through the Container Device Interface, the vendor neutral specification for describing accelerators to container runtimes, rather than per vendor plugins. The practical upshot is that Spur is not structurally an AMD only scheduler even though AMD wrote it, which matters for anyone running mixed silicon.
The Kubernetes integration is the most ambitious and the least proven. A spur-k8s-operator watches SpurJob custom resources and submits them to the controller, so Kubernetes workloads and batch jobs draw from one GPU pool. Sites that today carve their accelerators in half, inference on one side and training on the other, are the target. That static split is pure waste and everyone running it knows so, but unifying the two schedulers is genuinely difficult, and this is the newest code in the project.
For multi site clusters, integrated WireGuard mesh networking builds one overlay for job communication across on premises and cloud capacity. Beyond the core, AMD also describes Spur-Cloud, layering session management, PostgreSQL backed billing and multi tenancy through local auth, GitHub OAuth or Okta OIDC, which is a GPU as a service product rather than a scheduler feature.
What we would actually do with this
Try it, on a test partition, with your own job scripts. The installation is a shell one liner plus two daemons, which means an afternoon rather than a project:
curl -fsSL https://raw.githubusercontent.com/ROCm/spur/main/install.sh | bashThen point spurctld at a state directory, start spurd against it, and submit something real. The useful test is not whether sbatch hello.sh works, because it will. It is whether the twenty scripts you care about most survive contact, and where exactly they stop. That failure list is the only migration estimate worth having, and it costs a day to produce.
What we would not do is plan a production migration on this. AMD's own documentation says compatibility is under active development with parity still growing, and the roadmap still lists GPU partitioning and SR-IOV, advanced preemption and multi cluster federation as future work. Accounting is where we would expect the sharpest edges, since sacct reporting and fairshare policy are where a mature Slurm site keeps years of accumulated rules that no compatibility shim can infer.
The strategic reading is harder to dismiss than the technical one. Slurm schedules work on more than half of the top ten and top one hundred TOP500 systems, and since December 2025 it has been maintained by NVIDIA. NVIDIA has said it will keep Slurm open source and vendor neutral, and nothing suggests it has not. But a credible second implementation that accepts the same job files changes the shape of that dependency for everyone, including sites that never install it. That is worth more than the feature list.
Sources and further reading
- AMD ROCm Spur: providing AI-native, Rust-based job scheduling, Phoronix, August 7, 2026
- Spur: modern GPU job scheduling for HPC and AI workloads, AMD ROCm Blogs
- ROCm/spur, the Apache 2.0 source repository on GitHub
- NVIDIA acquires Slurm developer SchedMD, Evertiq, December 17, 2025
- NVIDIA moves deeper into AI infrastructure with SchedMD acquisition, Network World
- Container Device Interface specification
Frequently asked questions
Can I actually replace Slurm with Spur today?
Not in production, and AMD does not claim otherwise. The ROCm documentation describes Slurm compatibility as actively under development with broader parity still expanding, which is an honest way of saying the common commands work and the long tail does not yet. The commands covered are sbatch, srun, squeue, scancel, sinfo, sacct and scontrol, plus recognition of #SBATCH directives inside batch scripts, a REST API shaped like Slurm's, and a C FFI shim called libspur_compat.so for tools that link against the scheduler rather than shelling out to it. That covers the shape of most job submission. What it does not tell you is how your particular site behaves, because real Slurm deployments accumulate a decade of accounting rules, QOS policies, prolog and epilog scripts and reservation logic, and none of that is in the compatibility list. Treat it as something to stand up on a test partition and drive with your actual job files, not as a migration you schedule.
What does Raft consensus change compared to how Slurm does high availability?
It removes a piece of infrastructure. Classic Slurm high availability means a backup controller plus a shared state directory that both controllers can reach, usually on shared storage, and an accounting database sitting in MySQL or MariaDB alongside it. That is three things to install, secure and back up before the scheduler is redundant. Spur embeds Raft directly inside the controller daemon, so the cluster state is replicated between controller replicas by the scheduler itself, with automatic leader election and no external database required. AMD describes failover as sub-second. The practical difference is what happens on a bad night: instead of asking whether the shared filesystem is up and whether the database replicated, you are asking whether a quorum of controllers is reachable. Fewer moving parts is a real operational win, though it is worth saying that Raft has its own failure mode, which is losing quorum, and a three node control plane that loses two nodes stops scheduling.
Why does a job scheduler need WireGuard?
Because the clusters AMD is aiming at are not always in one room. Spur ships integrated WireGuard mesh networking to build a single overlay network for job communication across sites, which is aimed squarely at the case where some capacity is on premises and some is rented in a cloud. Traditionally that gets solved outside the scheduler, with a VPN or a dedicated interconnect that the platform team maintains separately, and the scheduler simply assumes nodes can reach each other. Folding it in means one fewer system to keep in sync with the node list. Whether you want that is a genuine architectural question rather than an obvious yes. If you already run a mature overlay network, a scheduler with opinions about your tunnels is another thing to reconcile. If you are assembling GPU capacity from more than one place and do not have that layer yet, having it arrive with the scheduler is convenient.
How does the Kubernetes side fit in, given Kubernetes already schedules things?
The two are meant to share the same GPUs rather than compete for them. Spur ships an operator, spur-k8s-operator, that watches a SpurJob custom resource and hands it to the Spur controller, so a batch job submitted through Kubernetes lands in the same GPU pool as one submitted with sbatch. That addresses a specific and very common annoyance: a site that runs inference services on Kubernetes and training jobs on Slurm ends up statically partitioning its accelerators between the two, because neither scheduler can see the other's allocations. Device handling goes through the Container Device Interface rather than vendor specific plugins, which is why AMD can say it works for its own GPUs and other vendors' accelerators without hardcoding either. The honest caveat is that unified scheduling is the hardest thing on this list to get right, and it is the part with the least public production history.
Is this AMD reacting to NVIDIA owning Slurm?
AMD has not framed it that way, and the technical arguments in the ROCm write up stand on their own. The sequence is still hard to ignore. NVIDIA completed its acquisition of SchedMD in December 2025, taking ownership of the project that schedules work on more than half of the top ten and top one hundred systems in the TOP500. NVIDIA committed publicly to keeping Slurm open source and vendor neutral, and there is no evidence so far that it has done otherwise. But there is a difference between a promise being kept and a competitor being comfortable, and the strategic value of a Slurm compatible scheduler under a licence AMD controls does not depend on NVIDIA behaving badly. The useful way to read Spur is as an option existing, which is worth something regardless of whether anyone ends up needing it.