At the end of September, InfoQ wrote up an open-source approach from Adobe engineers that lets teams see their own Prometheus metrics in a shared Kubernetes cluster without seeing anyone else's. The design is sensible and worth reading. But one detail in the write-up is the bit leaders should take away. In one of their GPU clusters, a single GPU sat at zero utilisation for 11 days in a row while still allocated to a workload and still drawing power.
Nobody did anything wrong there. The GPU was reserved, so the scheduler treated it as taken. It just was not doing any work. Multiply that across a fleet and you have the question that causes most of the arguments in shared clusters: who pays for capacity that is booked but idle?
Why this is getting harder
The FinOps Foundation's State of FinOps 2026 survey, covering 1,192 respondents and more than 83 billion dollars of yearly cloud spend, found that 98 percent of respondents now manage AI spend. Two years earlier the figure was 31 percent. FinOps for AI is now the top priority people say they are working towards, and allocation ranks near the top of what they want to get right across almost every kind of spend.
At the same time, the people closest to the problem are saying the old methods are straining. In an interview published on 28 September, CloudBolt's chief operating officer Yasmin Rajabi made the point that splitting a cluster bill evenly across teams or namespaces gives you a rough picture, but charging teams real money needs much finer detail. AI makes this worse. One user request might call several agents running different models for different lengths of time, all on expensive shared GPUs.
So the stakes are higher and the measurements are messier. That is the exact combination that turns a finance exercise into an internal fight.
The rules matter more than the tool
Most allocation disputes are not about the data. They are about rules nobody agreed in advance. A team sees a number it did not expect, discovers the method behind it was decided by someone else, and from then on argues about the method rather than the spend.
The open OpenCost specification is a useful neutral reference here, because it writes down the choices you have to make anyway. It treats a workload's cost as the greater of what it requested and what it actually used. If you reserve a GPU, you pay for it, busy or not. It defines idle cost as the gap between what the cluster costs and what has been allocated or used. And it lists three ways to share common costs: split evenly, split in proportion to use, or split by some other agreed measure.
None of these is the right answer. Each is defensible. The point is to pick one, write it down, and get the heads of the teams paying to sign it before the first bill lands.
A worked example
The numbers below are illustrative, not from any real company.
Say you run a shared cluster with 16 GPUs, and each one costs you 2.50 dollars an hour. Over a 730-hour month that is 1,825 dollars per GPU and 29,200 dollars for the cluster.
Three teams reserve GPUs. The search team holds 6, the recommendations team holds 4 and a research team holds 2. That is 12 GPUs, or 21,900 dollars. The other 4 GPUs, worth 7,300 dollars, are free capacity that nobody reserved.
Now the real decision. If you spread idle cost in proportion to reservations, search pays 14,600 dollars, recommendations about 9,733 and research about 4,867. If instead the platform team carries idle capacity as a central cost, the teams pay 10,950, 7,300 and 3,650, and 7,300 dollars sits on the platform budget as a visible number someone has to justify.
Both add up to 29,200. Neither is wrong. But the second one puts the idle capacity in front of the person who can actually shrink the cluster, which is usually the more useful outcome. If the 4 spare GPUs are there as deliberate headroom for launches, say so in the rules and charge it to whoever asked for the headroom.
Then turn it into a unit cost. If search serves 40 million requests a month, 14,600 dollars works out at about 37 cents per thousand requests. That figure is what a product owner can reason about. A GPU-hour rarely is.
The honest caveat
This works best where GPUs are reserved in whole units and teams map neatly to namespaces. Real clusters are often messier. Shared inference endpoints serve several products at once, GPUs get sliced between workloads, and a single request may touch three models owned by two teams. In those cases you need application-level signals, such as requests or tokens per model, to split the cost, and those signals are only as good as your tagging.
Kubernetes is also moving under your feet. Version 1.37 took another part of Dynamic Resource Allocation, the newer way of requesting devices such as GPUs, to general availability. As device sharing gets finer, your allocation rules will need revisiting.
And watch out for precision theatre. It is tempting to chase allocation down to the last cent, but if your method moves a team's bill by 3 percent and the team spends a week disputing it, you have lost money on the exercise. Accuracy is worth paying for when it changes a decision. Past that point it mostly changes the mood.
What to do this quarter
Start with showback, not chargeback. Show every team its share for two or three months before any money moves between budgets. People argue less about a number they have had time to question in private. The Adobe work is a useful pattern here too, because letting teams see their own usage directly builds trust in the figures.
Write the allocation rules on one page. Cover how reserved but unused GPUs are charged, who carries idle cluster capacity, how shared system costs are split, and how disputes get settled. Get it signed off by the people whose budgets it touches.
Make idle capacity someone's number. Whether it lands with the platform team or is spread across tenants, report it as its own line every month. A GPU idle for 11 days should be visible to someone within a day or two, not discovered in a write-up.
Pick one unit cost per major AI product, per thousand requests or per model call, and track it monthly. Trends in that figure will tell you more than any line-by-line reconciliation.
Agree a tolerance. Decide in advance that differences under a few percent are not worth re-running the numbers for, and hold to it.
