How do we do chargeback or showback for GPU usage across teams?

Chargeback and showback for GPU usage across teams both start with granular usage metering that tracks GPU-hours, or ideally tokens processed, per team or project, typically using Kubernetes namespaces, Slurm accounting, or NVIDIA's MIG and monitoring tools to attribute usage accurately on shared clusters. Showback simply reports usage and cost back to each team without actually billing them, which builds cost awareness and often changes behavior on its own, while chargeback goes further and formally allocates cost to each team's budget, requiring more rigorous metering accuracy and an agreed internal pricing model since teams scrutinize a bill far more closely than a report. A workable internal price per GPU-hour or per token should be based on the organization's actual fully loaded infrastructure cost, including hardware amortization and electricity, rather than an arbitrary number, and should be revisited periodically as infrastructure costs change. Shared clusters using NVIDIA MIG to partition a single GPU into isolated instances make chargeback more precise for smaller or bursty workloads that do not need a full GPU. Starting with showback before moving to full chargeback is a common and lower-friction path for organizations new to GPU cost allocation. Nanobase AI sets up GPU usage metering and chargeback or showback systems as part of shared cluster deployments for enterprise clients.

Showback and chargeback are mechanically different, not just semantically

The two terms get used interchangeably, but they require different levels of metering rigor and create different organizational dynamics. Showback reports usage and cost back to a team without moving money, which tolerates modest metering imprecision since no budget is actually debited; chargeback formally allocates cost to a team's budget, which demands accurate, defensible metering because teams scrutinize a bill far more closely than a report and will contest an inaccurate one. Treating chargeback-level stakes with showback-level metering accuracy is where these programs lose credibility.

Setting a defensible internal rate

An internal GPU-hour rate should be built from the organization's actual fully loaded cost, not an arbitrary or market-referenced number. Fully loaded cost per GPU-hour = (amortized hardware cost + electricity + colocation or facility cost + a reasonable share of operations staff time) ÷ total available GPU-hours in the period, measured against actual available capacity rather than theoretical 24/7 uptime, since planned maintenance and downtime reduce real available hours.

A worked rate calculation

Using illustrative figures to show the mechanism (as of 2026, verify current hardware and electricity costs for the actual calculation):

1. Amortized hardware cost for one GPU over its depreciation period: illustrative $1,200/month.
2. Electricity at typical H100-class draw run continuously: illustrative $150/month.
3. Allocated share of facility and operations staff time: illustrative $200/month.
4. Total fully loaded monthly cost: $1,550. Available GPU-hours in a month, accounting for maintenance downtime: roughly 700 hours.
5. Internal rate: $1,550 ÷ 700 ≈ $2.21 per GPU-hour, the number teams get billed or shown against, not a cloud list price copied from a vendor's website.

Using a vendor's public cloud rate instead of this internally calculated figure is a common shortcut that produces a number disconnected from what the infrastructure actually costs the organization, undermining trust in the program once someone compares the two.

A maturity roadmap

1. Instrument metering first, using Kubernetes namespaces, Slurm accounting, or NVIDIA MIG and monitoring tools to attribute GPU-hours or tokens processed per team on shared clusters.
2. Launch showback with the fully loaded rate calculated above, reporting cost back to teams without moving budget, and use this period to validate the metering is accurate.
3. Address disputes and metering gaps surfaced during showback before introducing real budget impact, since unresolved accuracy issues become far more contentious once money moves.
4. Transition to chargeback for teams and workloads where metering has proven reliable, potentially phasing it in workload by workload rather than organization-wide on day one.
5. Revisit the internal rate at least annually, since hardware amortization schedules and electricity costs both change over time.

Frequently asked questions

Should chargeback use GPU-hours or tokens processed as the billing unit?

GPU-hours are simpler to meter and more transparent to teams, while tokens processed more accurately reflects actual workload intensity on a shared cluster; many organizations start with GPU-hours for simplicity and move to token-based billing once workloads are heterogeneous enough that GPU-hours alone misrepresent actual usage.

Does MIG partitioning make chargeback easier?

Yes, MIG's hard isolation between instances on a single GPU gives each team a guaranteed slice of memory and compute, which produces cleaner, more defensible metering for smaller or bursty workloads than trying to time-slice a shared, unpartitioned GPU across teams.

What happens when a team disputes their chargeback bill?

A credible program needs a defined dispute process referencing the underlying metering data, which is another reason accurate metering during the showback phase matters, since resolving disputes without trustworthy underlying data undermines the whole chargeback program's credibility with every team going forward.

How Nanobase AI helps

Nanobase AI sets up GPU usage metering and chargeback or showback systems as part of shared cluster deployments, calculating a defensible internal rate from a client's actual fully loaded infrastructure cost rather than a borrowed cloud list price. This work pairs with broader Kubernetes GPU Operator and Slurm cluster management.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.