A Guide to GPU Chargeback
A Practical Guide to GPU Chargeback
The moment multiple teams start sharing a GPU cluster, one question always comes from finance: “This multi-million-dollar asset, who’s using how much of it?”
If you can’t answer, two things happen. Heavy users ask for more, and light users reserve capacity “just in case.” Everyone hoards their allocation, idle GPUs pile up, and yet the dashboard still shows high utilization. Cost disappears into shared overhead, and no one owns efficiency.
The operating discipline that solves this is GPU chargeback.
Showback vs. chargeback
First, the terms. Both connect usage to cost, but they differ in force.
Showback | Chargeback | |
|---|---|---|
Definition | Merely shows each team the cost they incurred | Actually bills and deducts from each team’s budget |
Enforcement | None (awareness only) | Yes (budget accountability) |
Difficulty | Low | High (must integrate with budgeting) |
Effect | Recognizes overuse, prompts voluntary savings | Suppresses real demand, clarifies ownership |
Recommended order | Adopt first, as step one | Transition to it after showback stabilizes |
The practical advice: don’t start with chargeback. Simply making it transparent, via showback, how much each team actually spends is often enough to change behavior. Once the numbers are visible, holding onto idle GPUs becomes uncomfortable.
GPU cost allocation in 4 steps
Step 1 — Collect usage data. Allocation starts with who used how much, and when. You need GPU-hours aggregated by account, project, and workload. This is where many teams stall, because scraping nvidia-smi logs by hand makes per-team aggregation effectively impossible.
Step 2 — Define the cost model. Assign a rate to each GPU-hour. The rate should include depreciation (hardware cost ÷ useful life), power, data-center operations, and staffing. It’s more accurate to set different rates per GPU type (an H100 vs. an older card).
Step 3 — Generate allocation reports. Multiply collected usage by the cost model to produce account- and project-level reports. These must come out in a format finance can use (such as Excel) to connect to the real budget process.
Step 4 — Tie it to quotas. Allocation alone doesn’t stop overuse. Set per-team quotas, compare them against the real usage the reports reveal, and run a loop that adjusts allocations. Reclaim unused capacity and redistribute it.
Where it breaks in practice
Most organizations stall at step 1. On Kubernetes, many teams’ workloads run intermixed, and attributing which Pod belongs to which team, or how to attribute each slice when a GPU is partitioned, is not technically trivial. It ends in “roughly this much” estimates, and estimate-based chargeback only breeds pushback.
Accurate allocation is possible only when usage is already tracked at the platform level, per account and project.
AIPub’s FinOps Suite
TEN’s AIPub addresses this with its FinOps Suite. AIPub aggregates GPU usage monthly and can export Excel reports by account and project, so the platform handles step 3 directly. With quota management and idle-resource reclaim (Workspace Reclaim), it also closes the operating loop in step 4.
Combined with GPU partitioning (100 blocks at 1% granularity, or MIG), even in environments where one card is shared across teams, each slice’s usage is tracked at the platform level, enabling allocation based on measurement rather than estimates.
The goal of chargeback isn’t to pressure teams. It’s to let the organization see who owns and efficiently uses a multi-million-dollar asset. That visibility is the savings.
→ Explore AIPub’s FinOps Suite: https://ten1010.io/en