What the customer buys

Only the middle of the data flow is billed. What goes in and what comes back belong to the customer; the GPU-hours of work between them are the billable line.

The data flow, and the one billable segment

Segment	What it is	Whose it is
Input	A prompt, a query, a document, raw data	The customer’s own
Process · compute	GPU-hours of work done	The only thing billed
Output	A token, an answer, an image, a prediction	The customer’s own

The operator’s side of the same flow, on the main paper’s Vehicle A basis:

What the operator puts in, spends, and bills · AUD, central case

Operator line	Value	Source
Inputs · power, space, capital	45 m per MW	Model, Assumptions: capex per MW
Process · operating cost	22% of revenue	Model, Assumptions: opex ratio
The bill · anchor rent	5.31 m per MW per yr	Model, Assumptions: 4.5 baseline × 1.18 premium

Market context for what the customer pays downstream, from v3 Ch.7: USD 2–4 per million output tokens at frontier; USD 1.50–3 per H100 GPU-hour at retail. Context only, not underwriting inputs.

A single customer’s compute demand runs in bursts: morning ramp, midday peak, evening peak, overnight floor. A fleet sized to that customer’s own peak sits idle most of the time. Pool several customers with different busy periods and the peaks land on one another’s troughs.

Average utilisation, one fleet basis against the other

Fleet basis	Average utilisation	Consequence
One customer, fleet sized to its own peak	~30%	The other ~70 per cent of capacity is paid for and idle
Many customers, pooled	~70%	One customer’s peak is another’s trough

Source: v3 Ch.7 illustration. These are customer-side figures. The main paper’s Vehicle B underwrites stabilised utilisation of 78 per cent of sellable capacity, retiring below about 70 and failing below about 60 at central pricing (§3). The two sets answer different questions and are not to be netted against each other.

The gap between those two numbers is the product. The pooling is the operator’s craft, and it is the structural reason a floor can be kept usefully full and the reason the service margin in Vehicle B exists at all.

Main paper · The margin Vehicle B captures: §2 · The utilisation assumption it rests on: §3

Whether a customer should own compute or rent it turns on one number: sustained utilisation of the fleet. Below the crossover the chip is idle too often to amortise, and the all-in cost of build per useful GPU-hour exceeds the rental rate. Above it, build undercuts rent; that takes a constant workload or a strategic mandate. Almost every customer lives below the line.

Cost per useful GPU-hour, build against rent at ~USD 3

Sustained utilisation	Build, per useful GPU-hour	Reading
30%	~USD 7	Rent wins; most customers sit here or below on their own
50%	~USD 4	Rent wins
~67%	~USD 3	Crossover: the chip is amortised
80%	~USD 2.50	Build wins; constant load or strategic mandate
95%	~USD 2	Build wins

Source: v3 Ch.7. The ~67 per cent is the customer’s build-or-rent threshold, not the facility’s utilisation assumption; it explains why customers rent, while §3’s 78 per cent is what the operator must sustain once they do.

What the boutique tier monetises is the distance between a customer’s ~30 per cent on its own and the pooled ~70 per cent: the same chip, paid for and idle alone, profitable when pooled.

Your peak is everyone else’s trough. That arbitrage is what a datacentre operator sells. The chips age in three years; the pooled demand had better not. Whether it does is the question the main paper prices in §3 and tests at the gates in §4.

Main paper · The load-bearing assumption: §3