Billing
A Slurm Cluster is billed for the nodes it holds, not for the work it does. That single fact drives every cost decision on this page.
What You Pay For
| Billed | Not billed |
|---|---|
| Each worker node, per hour, at the plan rate | Individual Slurm jobs — of any kind, any number |
| Attached storage volumes, separately | Job arrays, container jobs, multi-node jobs |
| Reserved IPs, per your account's IP pricing | Restarting workers, the login service or the cluster |
| Cloning a cluster's configuration | |
| Adding or removing partitions, SSH keys or security groups | |
Editing slurm.conf or prolog scripts |
There is no per-job charge and no idle discount. A cluster with an empty queue for a week bills the full rate for that week. The only way to stop compute charges is to terminate it — there is no pause.
Because jobs are free and nodes are not, the cost-optimal setup is the smallest node pool your queue can keep busy, not the largest one you can afford. Watch Job Count — running vs pending in Monitoring: a persistent pending backlog is the signal to scale up; a permanently empty queue is the signal to scale down.
The Billing Lifecycle
| Event | Effect on billing |
|---|---|
| The cluster is created | Charges start — the create form warns "Charges apply from the moment the cluster is created." |
| It sits Creating | Billed |
| It is Running, idle or busy | Billed at the same rate |
| Jobs run, fail, or fill the queue | No change |
| You scale up | The rate rises with the new node count. The Scale dialog shows New hourly cost and Change from current before you confirm |
| You scale down | The rate falls |
| You restart anything | No change |
| The cluster is Failed | Not billed for compute |
| You terminate it | Compute billing stops |
| You delete it | Already stopped |
| Storage stays attached after termination | Storage keeps billing |
A Failed cluster is not billed for compute, so there is no rush — but clone it into a working cluster and delete the failed record so nobody mistakes it for capacity they can use.
On-Demand, Savings Plans and Committed
On-Demand
The default: "Flexible pay-as-you-go hourly pricing." Billed per hour, terminate whenever, scale freely.
Savings plans
At create time, the Pricing section may offer discounted terms:
| Plan | Discount |
|---|---|
| 1 Month Savings Plan | Save 10% |
| 3 Month Savings Plan | Save 14% |
| 6 Month Savings Plan | Save 20% |
Convert to Committed
An existing hourly cluster can be converted with Actions → Convert to Committed. You choose a committed plan and a Renewal Policy:
| Policy | At the end of the term |
|---|---|
| Auto Renewal | The same committed plan renews |
| Convert to Hourly Plan | Hourly billing resumes at the listed rate |
| Auto Delete | The cluster is deleted |
The acknowledgement in the dialog is precise: the full cost for the whole commitment period is deducted immediately, you cannot terminate before the term ends, and terminating early refunds nothing for the remaining days.
Scale Cluster is hidden once the plan is committed, in both directions. Size the cluster on On-Demand first, confirm the queue is consistently busy, and only then commit — otherwise you have locked in the wrong shape for the whole term.
The credits quoted in the acknowledgement text are the per-node price for the commitment period. The amount actually debited is that figure multiplied by your node count. On a multi-node cluster the charge is correspondingly larger than the number in the dialog — work it out before you confirm.
Conversion causes no restart and no downtime. Nothing on the cluster changes; only the billing does.
Private Cluster
A Private Cluster reserves physical nodes for your account. Slurm clusters built on it draw from that reserved pool, so you are not paying an hourly Slurm-cluster rate on top of the reservation — the plan reads "Billed as part of your private cluster plan" rather than an hourly rate.
If you create and tear down clusters regularly, an on-demand cluster fails whenever inventory is short. A private cluster guarantees the capacity is there and provisions faster.
Which to choose
| Situation | Choose |
|---|---|
| Evaluating, or a one-off experiment | On-Demand |
| A known project with a fixed end date | A savings plan matching the duration |
| Steady training demand for months | Convert to Committed once the size is settled |
| Frequent create/destroy cycles, or capacity guarantees | Private Cluster |
Storage Is Billed Separately
| Volume | Billed |
|---|---|
| Parallel File System (PFS) | Independently of the cluster |
| Shared File System (SFS) | Independently |
| Datasets | Independently |
| Weka | Independently |
Terminating a cluster unmounts your volumes; it does not delete them. That is deliberate — your data survives — but the charges continue indefinitely until you delete the volumes yourself, under Storage in the sidebar.
This is the most common source of unexpected charges on a Slurm Cluster. Add "review volumes" to your teardown routine.
Container squash files and checkpoints are the usual reason a volume grows faster than expected:
du -sh /pfs/*
du -sh /pfs/images/* /pfs/checkpoints/*
Keeping the Bill Down
| Practice | Why it matters |
|---|---|
| Terminate clusters you are not using | The single biggest lever. There is no pause |
| Size to the queue, not to ambition | Jobs are free; nodes are not. Idle nodes are pure waste |
| Check GPU utilisation on new job scripts | A job at 15% utilisation for three days costs the same as one at 95%. Monitoring shows it in seconds |
| Scale down after a burst | Node counts are adjustable on live hourly clusters |
| Cache container images | Not a billing item, but 16 array tasks each pulling a 15 GB image wastes hours of paid GPU time. Cache them |
| Use partition time limits | A Max time on your partitions stops a hung job holding GPUs indefinitely |
| Delete old checkpoints and squash files | Storage bills forever |
| Clone rather than keep clusters idle | A cluster's configuration survives termination via Clone Cluster. Terminate, clone later, pay nothing in between |
| Attach a utilisation alert | Catches the expensive silent failure — a cluster nobody is using |
For work that comes in bursts, do not keep a cluster idle between them. Terminate it — the record stays at status Terminated and can still be cloned — then clone it into a fresh cluster when the next burst arrives. You keep the exact configuration and pay nothing in between. Re-add partitions after each clone, since those do not carry over.
Where to See Your Spend
Billing and Usage in the TIR sidebar shows usage and invoices across the project, including clusters and storage separately. The E2E pricing calculator helps compare plans before you create anything.