Operator capability and cost per usable token in GPU serving
Two clouds rent the same B200 by the hour. One delivers roughly 300 output tokens per second per user under load; the other manages about 200 on the identical chip against the same latency targets. The chip is the same. The operator is not. That gap — and what it does to the real cost of every usable token — is what this chapter explores, drawing on Oliver Kennon's SemiAnalysis argument that hardware sets potential while operating capability sets delivered output.
A GPU falls to the level of the operator
The starting point is a corrective to hardware-first thinking: a GPU does not ship with a guaranteed performance level. Hardware sets the ceiling of what is possible, but the operator — the team running the serving stack — determines how much of that potential is actually delivered. On identical silicon, identical contracts, and identical latency targets, one operation extracts substantially more than the other. The chip falls to the level of the operator.
Same chip, about 50% more output
Put numbers on the gap. One operator sustains roughly 300 output tokens per second per user under load; another manages about 200 on the very same B200 against the same latency targets. That is roughly 50% more output from the same rented hardware. Nothing about the accelerator changed between the two cases — the difference is entirely in operating capability: how the serving configuration is tuned and run.
Usable is the operative word
Raw token counts flatter the wrong thing. What matters is the usable token: output that arrives at the promised latency targets, under real load, for the actual user. An operator who hits 300 tokens per second only by missing latency targets has not produced more usable output. This is why the comparison above holds latency constant — the 50% advantage is delivered within the same quality constraints, not in spite of them.
Cost position is relative, and scarcity hides it
Cost per usable token is therefore a relative measure. An operator paying the same hourly rate for the same GPU is not in the same cost position if one turns that hour into 300 usable tokens per user and the other into 200. And when compute is scarce, this difference hides: demand absorbs whatever output the weaker operator produces, so the penalty for poor operation never surfaces in the invoice — only in what could have been delivered.
Grading operators, hedging compute
The practical takeaway is to grade operators on delivered output per chip, not on the chip they rent. Where compute is the scarce input, hedging means steering spend toward operators whose serving configurations convert the same GPU into more usable tokens. By the end of this chapter you should be able to explain how operator choice changes cost per usable token, and identify serving configurations that yield more output from the same GPU.