Problem
dstack gives AI teams a single, dev-friendly interface for running containerized GPU workloads across cloud providers and Kubernetes. But a large share of the world's on-prem GPU capacity isn't on the cloud or Kubernetes: it sits behind Slurm, the de facto standard scheduler for HPC and on-prem GPU clusters in universities, national labs, and a growing number of enterprises.
Teams with access to Slurm-managed GPUs — institutional clusters, HPC allocations, shared on-prem fleets — can't use dstack on that hardware today.
A Slurm backend extends dstack's core promise — one simple, portable interface across compute environments — to the on-prem HPC world, meeting a substantial set of AI teams where their GPUs already are.
Solution
A slurm backend that connects to a cluster's login node over SSH and submits dstack runs as Slurm jobs, launching each run's container via Pyxis/enroot. A single backend can manage multiple clusters — each surfaced as a dstack region — with Slurm partitions mapped to availability zones. From the user's side, dev environments, tasks, services, and multi-node fleets work on Slurm just as they do on cloud and Kubernetes backends, with no batch scripts to write.
Workaround
No response
Would you like to help us implement this feature by sending a PR?
Yes
Problem
dstackgives AI teams a single, dev-friendly interface for running containerized GPU workloads across cloud providers and Kubernetes. But a large share of the world's on-prem GPU capacity isn't on the cloud or Kubernetes: it sits behind Slurm, the de facto standard scheduler for HPC and on-prem GPU clusters in universities, national labs, and a growing number of enterprises.Teams with access to Slurm-managed GPUs — institutional clusters, HPC allocations, shared on-prem fleets — can't use
dstackon that hardware today.A Slurm backend extends
dstack's core promise — one simple, portable interface across compute environments — to the on-prem HPC world, meeting a substantial set of AI teams where their GPUs already are.Solution
A
slurmbackend that connects to a cluster's login node over SSH and submitsdstackruns as Slurm jobs, launching each run's container via Pyxis/enroot. A single backend can manage multiple clusters — each surfaced as adstackregion — with Slurm partitions mapped to availability zones. From the user's side, dev environments, tasks, services, and multi-node fleets work on Slurm just as they do on cloud and Kubernetes backends, with no batch scripts to write.Workaround
No response
Would you like to help us implement this feature by sending a PR?
Yes