Ways to Pay for LLM Capacity, Compared
Four models: per token, seat based subscription, provisioned throughput, and self-hosting. They differ mainly on who carries the cost of idle capacity, how predictable the bill is, and how much operational work you absorb. Demand shape decides which is right, not headline rates.
What actually separates them
Prices change constantly, so comparing on rates is a comparison with a short shelf life. The structural differences are stable and they are what should drive the decision.
Who carries idle capacity. Per token, the provider does: you pay only for work performed. With provisioned throughput or your own hardware, you do, whether traffic arrives or not. That single question explains most of the cost difference between the models at any given volume.
How predictable the bill is. Per token converts usage directly into spend, which is honest and unbudgetable. Subscriptions and provisioning convert it into a fixed number, which is budgetable and wrong whenever demand moves.
Where the operational work sits. Hosted options put reliability, scaling and upgrades on the provider. Self-hosting moves all of it to you, and that cost is staffing rather than infrastructure, which is the part most comparisons omit.
What happens under a spike. Per token absorbs it and bills you. Provisioned capacity queues or rejects. Self-hosted does whatever your capacity planning allows, which under a genuine spike is usually degrade.
Data handling. Where inference runs determines where content goes, and for some workloads that decision is made by policy rather than by cost.
Reading the table
Three notes make the comparison usable.
Per token is the correct default and not the cheapest at every volume. It requires no forecast and no commitment, which is exactly what an early or variable workload needs. Its weakness is that a runaway loop turns directly into spend, so per-task budgets matter more here than anywhere else.
Committed options need a load shape, not a total. Provisioned throughput and self-hosting reward steady, predictable, high utilisation. The same monthly token volume delivered in a daily two-hour burst is a poor fit for both, because you buy for the peak and pay through the trough.
Self-hosting is a staffing decision. The hardware arithmetic is the easy half. The recurring cost is people who can operate serving infrastructure, handle upgrades, and be responsible when it fails at an inconvenient hour. Teams that model only the hardware reliably conclude it is cheaper than it turns out to be.
A hybrid is common and sensible: a committed tier sized to baseline demand, with per-token capacity absorbing the peaks. That captures most of the discount without buying for the maximum.
Choosing on demand shape
Three questions settle it more reliably than any rate card.
Is demand steady or spiky? Steady favours commitment. Spiky favours per token, because you would otherwise buy for the peak and pay through the trough.
Is volume predictable a quarter ahead? If not, committing is a forecast you will get wrong in one direction or the other, and both directions cost money.
Do you have people to operate it? If self-hosting means an engineer stops doing product work, that is the real price, and it should appear in the comparison rather than beside it.
And the point that outranks all four options. Every model here charges for volume in some form, so reducing volume improves the economics of whichever one you pick. A system that sends only the context a task requires is cheaper per token, needs less provisioned capacity, and runs on smaller hardware. That is what stacked retrieval in RDK is for: most queries resolve before the model is involved, so the capacity question shrinks before you have to answer it.
Decide volume first. Then decide how to buy it.
| Model | You pay for | Bill predictability | Who carries idle capacity | Best fit |
|---|---|---|---|---|
| Per token | Work actually performed | Low, tracks usage exactly | The provider | Variable or early workloads |
| Seat subscription | Access per person | High, fixed per head | The provider | Human tools with even usage |
| Provisioned throughput | Reserved capacity | High, fixed commitment | You | Steady high volume |
| Self-hosted | Hardware plus operations | Fixed cost, variable effort | You | Steady volume with data or latency constraints |
Frequently asked questions
- Which LLM pricing model is cheapest?
- It depends on demand shape rather than on rates. Per token avoids paying for idle capacity but never produces a predictable bill. Provisioned and self-hosted options reward steady high utilisation and waste money on spiky demand, because you buy for the peak and pay through the trough.
- When does self-hosting make sense?
- When volume is steady and high, when data handling or latency constraints make hosted inference unsuitable, and when you already have people who can operate serving infrastructure. That last condition is the one most comparisons omit, and it is usually the largest recurring cost.
- Are seat subscriptions good value?
- They are predictable, which is their main virtue, and they stop fitting when usage varies widely between people. A team where a few heavy users drive most consumption is subsidising them through everyone else's seats, and the model gives you no visibility into that.
- Can you combine pricing models?
- Yes, and it is often the right answer. A committed tier sized to baseline demand with per-token capacity absorbing the peaks captures most of the discount without buying for the maximum, which is what makes committed pricing expensive for spiky workloads.