dstack vs Slurm Workload Manager

dstack is an open-source orchestration layer for AI workloads across GPU clouds, Kubernetes, virtual machines, and bare-metal clusters. YAML configurations define fleets, development environments, tasks, services, presets, and volumes, while dstack handles provisioning and job scheduling, including auto-scaling, port forwarding, and ingress. Supported accelerators include NVIDIA, AMD, TPU, and Tenstorrent. Documented backends include AWS, Azure, GCP, Kubernetes, GPU cloud providers, remote SSH hosts, and experimental Slurm. Tasks can use frameworks such as accelerate, torchrun, Ray, and Spark. Users manage resources through the CLI or HTTP API, and the server can run on a laptop or another environment that can access the clusters in use. Services can publish inference endpoints through gateways with HTTPS, custom domains, auto-scaling, and rate limits. The self-hosted open-source stack is free. Server data and project secrets are stored in plaintext by default unless administrators configure AES-256-GCM encryption. TPU support is limited to single-host instances with up to eight cores. GPU Marketplace usage is prepaid, with prices that vary by GPU and provider and appear in the console before provisioning.

Slurm Workload Manager is free, open-source software for allocating compute resources and scheduling work across Linux clusters. It starts and monitors jobs on allocated nodes and manages queues of pending work. Optional plugins add accounting, advanced reservations, gang and backfill scheduling, topology-aware resource selection, resource limits, and multifactor job prioritization. The system uses a central slurmctld manager and slurmd daemons on compute nodes; accounting and REST components are optional. GPU plugins support NVIDIA, AMD, Intel, AWS Trainium, and AWS Inferentia accelerators, along with NVIDIA MPS and GPU sharing. Accounting can use MySQL or MariaDB and can record data in a text file, directly in a database, or through slurmdbd for multiple clusters. Slurmrestd provides REST access, but the API is not designed for direct internet exposure and supports only unencrypted HTTP. Linux is thoroughly tested on arm64, ppc64, and x86_64; FreeBSD and NetBSD support is limited, and macOS is unsupported. Deployment is self-hosted.