Billing Policy¶

Starting from the 20th call period, a new billing policy will take place.

Billing Core Hours¶

All resource usage is converted into a single core hour unit. A core hour represents the equivalent of one CPU core used for one hour. Every resource — CPU cores, memory, and GPUs — is translated into this common unit so that allocations can be compared and charged fairly regardless of the resource type requested.

Partition Billing Weights¶

Partition	CPU	Memory	GPU
`compute`	1.0 per core	0.25 per GB	—
`taskp`	1.0 per core	0.125 per GB	—
`fat`	1.0 per core	0.125 per GB	—
`gpu`	1.0 per core	0.25 per GB	32 per A100
`mig`	1.0 per core	0.25 per GB	4 per 1g.10gb · 8 per 2g.20gb · 16 per 3g.40gb

The fat and taskp partitions have a lower memory weight because each node provides double the memory (992 GB vs 496 GB) for the same number of cores.

Usage Calculation¶

The cost of a job is given by:

core hours = JobWalltime × TRESBillingJobWeight

where TRESBillingJobWeight uses the MAX rule across all resource dimensions:

TRESBillingJobWeight = MAX(
    AllocatedCPUs  × CPU weight,
    AllocatedMem   × Memory weight,
    AllocatedGPUs  × GPU weight
)

You are charged for whichever resource dominates your request:

CPU-bound: if you request many cores but little memory, the CPU contribution drives the cost.
Memory-bound: if you reserve a large amount of memory relative to your cores, the memory contribution takes over — even if you use only 1 CPU, you are billed as if you occupied the fraction of the node that your memory represents.
GPU-bound: a GPU carries a fixed billing weight regardless of how many CPUs or how much memory you pair with it. Each GPU node has 4 A100 GPUs and 128 CPU cores. One A100 represents exactly one quarter of the node, and one quarter of 128 cores is 32 — this is why the billing weight for 1 A100 is 32. Requesting 1 A100 therefore costs 32 core hours per hour, the same as occupying 32 CPU cores. If you request 1 A100 with only 1 CPU core, you still get charged for 32 core hours. MIG instances weights follow the same logic: a 1g.10gb instance is 1/8 of an A100, so its weight is 32 ÷ 8 = 4; a 2g.20gb is 1/4 of an A100, weight 8; and a 3g.40gb is 1/2 of an A100, weight 16.

Good Examples¶

All examples below assume a job walltime of 1 hour.

Balanced job on the fat partition¶

A user requests 10 CPUs and the proportional share of memory (10 cores × 8 GB/core = 80 GB) on the fat partition.

#!/bin/bash
#SBATCH --partition=fat
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=16
#SBATCH --mem=128G
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(16 × 1.0, 128 × 0.125, 0)
                     = MAX(16, 16, 0)
                     = 16

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 16 = 16 ch

Balanced — neither CPU nor memory dominates; you get charged for exactly what you use.

A “fair quarter” of a GPU node¶

A user requests the proportional share of a quarter GPU node: 32 CPUs, 128 GB memory, 1 A100.

#!/bin/bash
#SBATCH --partition=gpu
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=32
#SBATCH --mem=124G
#SBATCH --gres=gpu:a100:1
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(32 × 1.0, 124 × 0.25, 1 × 32.0)
                     = MAX(32, 31, 32)
                     = 32

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 32 = 32 ch

A three-way tie. The weights are calibrated so that taking exactly one quarter of every dimension of a GPU node costs the same as taking one A100 alone.

A small MIG instance¶

A user requests 4 CPUs, 16 GB memory, and one 1g.10gb MIG instance on the mig partition.

#!/bin/bash
#SBATCH --partition=mig
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G
#SBATCH --gres=gpu:1g.10gb:1
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(4 × 1.0, 16 × 0.25, 1 × 4.0)
                     = MAX(4, 4, 4)
                     = 4

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 4 = 4 ch

A three-way tie — CPU, memory and MIG instance are all balanced. A 1g.10gb MIG instance costs 4 core hours per hour versus 32 for a full A100. If your job genuinely fits within the 1g.10gb compute and memory capacity, this translates to real savings. Keep in mind that a larger instance delivers proportionally more GPU compute — if your job is compute-bound, it will finish faster on a bigger instance and the total core hours may be comparable. Choose the smallest instance that satisfies both your memory and compute requirements.

Whole-node fat job¶

A user takes a full fat node: 128 CPUs and all 992 GB of memory.

#!/bin/bash
#SBATCH --partition=fat
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=128
#SBATCH --mem=992G
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(128 × 1.0, 992 × 0.125, 0)
                     = MAX(128, 124, 0)
                     = 128

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 128 = 128 ch

Whole-node billing — you get charged for the full node.

Common Mistakes¶

Memory hoarding on the fat partition

A user requests only 1 CPU but reserves all the memory of a fat node (992 GB).

#!/bin/bash
#SBATCH --partition=fat
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=992G
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(1 × 1.0, 992 × 0.125, 0)
                     = MAX(1, 124, 0)
                     = 124

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 124 = 124 ch

Although only 1 CPU was requested, the job blocks all the memory of the node, preventing other jobs from running on it. The billing reflects this: the user get charged for the whole node. Request only the memory your job actually needs.

Requesting a GPU with too few CPU cores

A user requests 1 CPU, 1 GB of memory, and one full A100 GPU on the gpu partition.

#!/bin/bash
#SBATCH --partition=gpu
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=1G
#SBATCH --gres=gpu:a100:1
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(1 × 1.0, 1 × 0.25, 1 × 32.0)
                     = MAX(1, 0.25, 32)
                     = 32

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 32 = 32 ch

The GPU dominates. You get charged for 32 core hours even if you only used 1 CPU core.

Requesting a large MIG instance when a smaller one is sufficient

A user requests a 3g.40gb instance (weight 16) for a job that fits in a 1g.10gb instance (weight 4).

#!/bin/bash
#SBATCH --partition=mig
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=8G
#SBATCH --gres=gpu:3g.40gb:1
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(1 × 1.0, 8 × 0.25, 1 × 16.0)
                     = MAX(1, 2, 16)
                     = 16

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 16 = 16 ch

The same job on a 1g.10gb instance:

#!/bin/bash
#SBATCH --partition=mig
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=8G
#SBATCH --gres=gpu:1g.10gb:1
#SBATCH --time=01:00:00

TRESBillingJobWeight = MAX(1 × 1.0, 8 × 0.25, 1 × 4.0)
                     = MAX(1, 2, 4)
                     = 4

core hours = walltime (1h) × TRESBillingJobWeight = 1 × 4 = 4 ch

Choosing a larger instance than needed costs more per hour without extra benefit — but only when your job fits in the smaller instance. A larger instance delivers more GPU compute, so if your job is compute-bound it will finish faster and the total core hours may be similar. The waste occurs when you pick a large instance for a job that does not use the extra compute capacity. Always match the instance size to both your memory and compute requirements.

Viewing your usage¶

To see the billing you have accumulated:

mybudget