Getting Started
A Slurm Cluster is a dedicated pool of GPU nodes with a Slurm scheduler in front of it. You submit jobs to a queue, Slurm allocates nodes and GPUs, and your work runs — optionally inside any container image you choose.
| Step | Page |
|---|---|
| 1. Understand the pieces | How a Slurm Cluster works |
| 2. Create one | Create a Slurm Cluster |
| 3. Run something | Submit your first job |
Is a Slurm Cluster the Right Fit?
| Use a Slurm Cluster when | Consider something else when |
|---|---|
| You train across multiple GPUs or multiple nodes | A single GPU for a notebook — use a Node or TIR Notebook |
| A team shares GPU capacity and needs a queue | One person, one job at a time |
| You want predictable cost for a fixed pool of nodes | You want to pay only while a job runs |
| Your jobs must run in specific container images | Your workload is a served model — use Inference |
| You need per-job scheduling, priorities and fair sharing | You just need a long-running process |
A Slurm Cluster is billed for the nodes it holds, per hour, whether they are busy or idle. Jobs are never billed separately. An idle cluster costs exactly as much as a saturated one, so size it to what your team will actually keep busy — see Billing.
What You Need Before You Start
| Requirement | Why | Where |
|---|---|---|
| An SSH key in TIR | It is required at create time and is how you log in | Create one from the create form's Click here link, or under Personal Access Tokens / SSH keys |
| A Parallel File System volume | Required at create time, and it is where your data, checkpoints and container images live | Parallel File System |
| Enough credit | Billing starts the moment the cluster is created | Billing and Usage in the sidebar |
| A security group allowing SSH | Without inbound TCP 22 you cannot reach the login node | The default SSH security group works |
GPU inventory is finite, and creating an 8-node H100 cluster can fail simply because the nodes are not free. A Private Cluster reserves a pool of nodes for your account, so cluster creation always succeeds and is faster. It is the right choice if you expect to create and recreate clusters regularly.
The Shape of the Work
Once the cluster is Running, the routine is the same every day:
ssh root@<cluster-ip> # land on the login node
sinfo # what nodes and partitions exist
sbatch train.sh # submit
squeue # watch the queue
Everything else in this section is detail on top of that loop: which container to run, which partition to submit to, what to do when a job will not start, and how to keep the cluster healthy.