--- title: Billing sidebar_label: Billing --- import { Clock, CreditCard, HardDrive, TrendingDown, AlertTriangle } from 'react-feather'; # 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. }, { href: '#the-billing-lifecycle', label: 'Billing lifecycle', icon: }, { href: '#on-demand-savings-plans-and-committed', label: 'Plans', icon: }, { href: '#storage-is-billed-separately', label: 'Storage', icon: }, { href: '#keeping-the-bill-down', label: 'Keeping it down', icon: }, ]} /> --- ## 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 | :::danger An idle cluster costs exactly the same as a saturated one 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](/docs/tir/SlurmCluster/manage/actions#terminate-cluster) it — there is no pause. ::: :::tip This changes how you should size a cluster 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](/docs/tir/SlurmCluster/manage/monitoring#scheduler-metrics): a persistent pending backlog is the signal to [scale up](/docs/tir/SlurmCluster/manage/actions#scale-cluster); 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** | :::warning Failed clusters are free, but still clutter 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**](/docs/tir/SlurmCluster/manage/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 | :::danger The committed amount is charged upfront and is not refundable 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. ::: :::warning A committed cluster cannot be scaled **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. ::: :::warning The figure in the acknowledgement is per node 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](/docs/myaccount/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. :::tip Private Cluster is the right answer for a team that recreates clusters 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)](/docs/tir/pfs/) | Independently of the cluster | | [Shared File System (SFS)](/docs/tir/sfs/) | Independently | | [Datasets](/docs/tir/Datasets/) | Independently | | Weka | Independently | :::danger Storage keeps billing after the cluster is terminated 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: ```bash 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](/docs/tir/SlurmCluster/manage/monitoring#reading-the-charts) 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](/docs/tir/SlurmCluster/containers/image-cache) | | **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 | :::tip The clone-and-terminate pattern 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](/docs/tir/SlurmCluster/slurm-configuration/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](https://calculator.e2enetworks.com/) helps compare plans before you create anything. --- ## Related Resources - [Create a Slurm Cluster](/docs/tir/SlurmCluster/getting-started/create-cluster) - [Cluster actions](/docs/tir/SlurmCluster/manage/actions) - [Storage and volumes](/docs/tir/SlurmCluster/manage/storage) - [Monitoring](/docs/tir/SlurmCluster/manage/monitoring) - [Private Cluster](/docs/myaccount/private_cluster/)