GPU chargeback and metering
Bill the hardware, not the workload
The unit of sale for a GPU cloud is hardware-time. A tenant holds eight H100s and 40TB of storage from Tuesday to Friday, and you invoice for that, whether they ran Kubernetes, Slurm, raw Linux, or left the nodes idle. Saturn Cloud snapshots allocation state from your BMaaS provider and turns it into invoices.
What this page is about
Allocation-based billing for GPU cloud operators
Saturn Cloud meters and bills at the resource-allocation layer. The BMaaS provider (k0rdent or equivalent) knows which physical resources belong to which tenant at any moment. Saturn Cloud captures that state on a regular cadence, retains it as billing history, and joins it against the tenant catalog and price book.
Snapshot the BMaaS allocation ledger
Saturn Cloud queries the BMaaS provider on a fixed cadence and records which tenant holds which nodes and which storage volumes. The historical state is the audit trail behind every invoice.
Bare metal, clusters, and standalone, the same way
It does not matter whether a node is part of a Kubernetes cluster, attached to a Slurm partition, or provisioned as standalone bare metal. If the BMaaS provider says the tenant holds it, the tenant is billed for it.
Storage, networking, and other resources
The same allocation model applies to storage volumes, reserved IPs, and any other resource the BMaaS provider tracks. One billing pipeline, one invoice per tenant, all resource types.
Exportable invoices and usage records
CSV and API exports of allocation-hours per tenant, per resource type, per time window. Feeds your billing system, your data warehouse, or your accounting team. No proprietary format.
How it works
From BMaaS state to invoice
Snapshots, not log scraping
Saturn Cloud asks the BMaaS provider "what is the current allocation state" on a fixed cadence and stores the answer. The billing pipeline reads from those snapshots, not from Kubernetes events or DCGM metrics.
Kubernetes is not in the billing path
Tenants pay for the hardware they hold regardless of whether they run a Kubernetes cluster on it. Workload-level metering inside a cluster does not change the invoice. The customer signed up for the nodes.
Bare metal and Slurm work without K8s involved
A tenant who runs Slurm on bare metal, or no scheduler at all, is billed the same way as a tenant who runs Kubernetes. The allocation ledger is the source of truth, and it has no opinion about what runs on the nodes.
Utilization data is a separate product surface
DCGM and Prometheus tell tenants whether the GPUs they bought are doing useful work. That is showback, and it belongs inside the tenant's view of the platform. It is not what the invoice is based on.
Two different problems, not two options for the same one
Cluster-internal attribution vs. operator-level invoicing
If you run a single large Kubernetes cluster shared across teams in your company, you need to attribute workloads inside it so you can split the bill. Tools built around DCGM, Prometheus, and Kubernetes events handle that. If you sell resources to external tenants, none of that applies. The invoice is for the hardware the tenant held, not for what they ran on it.
| Aspect | Cluster-internal attribution (kubecost, Run:ai showback, others) | Saturn Cloud operator-level invoicing |
|---|---|---|
| Who buys it | Enterprise platform teams sharing one cluster across business units | GPU cloud operators selling resources to external tenants |
| Unit of billing | Workload-hours inside a cluster | Hardware-hours allocated to a tenant |
| Data source | Kubernetes events, DCGM, Prometheus | BMaaS allocation state, snapshotted over time |
| What about an idle cluster? | Costs less, because nothing scheduled | Billed the same. Tenant paid for the nodes. |
| Bare metal outside a cluster | Not covered | Billed identically to cluster-attached nodes |
| Slurm without Kubernetes | Not covered | Billed identically to cluster-attached nodes |
The allocation ledger on your stack
What Saturn Cloud snapshots, by partner
"BMaaS allocation ledger" is the abstract name for the data we bill against. On each partner stack it is a different concrete object, exposed by the project or vendor that owns the bare metal layer. The shape changes; the model does not.
| Stack | What "tenant X holds resource Y" looks like |
|---|---|
| Mirantis k0rdent (CAPI + Metal3 + Ironic) | Metal3 BareMetalHost CRDs with a consumerRef pointing at a tenant cluster's Metal3Machine (or unassigned). Storage and other resources follow similar CRDs in the same management cluster. |
| SUSE Rancher with OpenNebula | OpenNebula host-to-VDC mapping. Hosts and storage are placed in Virtual Data Centers (VDCs) owned by tenants. Saturn Cloud reads VDC membership over the OpenNebula API. |
| Spectro Cloud Palette | Palette host inventory. Each registered server has an assigned cluster (or is in the unallocated pool), exposed via the Palette API. Same ledger whether Palette is provisioning via Canvos/Kairos or via a CAPI provider. |
Chargeback vs showback
One platform, two billing surfaces
Chargeback is what the operator does to the tenant: real invoices for the hardware the tenant held. The allocation ledger is the source. Showback is what the tenant's admins do inside their own organization: who used what, sourced from workload-level signals (DCGM utilization, workspace lifecycle, Slurm accounting). Showback runs inside the tenant's view of Saturn Cloud and does not appear on the invoice. Their teams use it to chase their own waste.