Skip to content
Aitsam Ahad

AI Systems

Self-hosting your LLM probably costs more

Self-hosting an open model is supposed to be the cheap option. Run the numbers and it usually isn't - and the reason is one variable almost nobody measures.

slower with one user — slower with one user than with many

The open-weights argument is usually made on price: the model is free, so running it yourself must be cheaper than paying per token. The weights are free. The GPU is not, and the GPU is what you are actually buying.

Once you write the cost per million tokens as a single expression, the whole argument reduces to one number — and it is not a number about models at all.

cost per million tokens
Serving one user on your own H100, against paying an API.

The expression everything reduces to

python
cost_per_million = (dollars_per_hour)
                 / (tokens_per_second * 3600)
                 * 1_000_000
Code
Three inputs, and only one of them is under your control at runtime.

dollars_per_hour is what the hardware costs whether or not you use it. tokens_per_second is what you actually get out of it. Every argument about self-hosting economics is an argument about one of those two terms, and most of them quietly assume the best case for both.

Why the throughput number is usually wrong

This is the term people get wrong by two orders of magnitude, because the number quoted in benchmarks and the number you get in production are measuring different things.

H100, seventy billion parameters
The same card, the same model, two different questions.
tokens/second
batched, many concurrent requests ~3,066
one user, one stream ~24

Both are real numbers for an H100 running a 70-billion-parameter model. The difference is batching. Generating tokens for one stream leaves the card overwhelmingly idle — it is waiting on memory bandwidth, not compute — so serving many requests at once is nearly free compared to serving one.

Which means the benchmark figure is achievable only if you have enough simultaneous traffic to fill the batch. If you do not, you are paying for a card running at a fraction of a percent of its capacity, and your cost per token is the idle cost divided by the handful of tokens you actually produced.

The number that decides it

So the question is not "is the model good enough". It is:

sustained utilisation needed to break even
Sustained utilisation required before self-hosting wins.
you would have paid utilisation needed to break even
the cheapest mainstream API ~34%
a mid-tier API ~4%
a frontier API ~1.6%

Read that carefully, because it is the opposite of what the framing usually implies. Against the cheapest API you need to keep a card meaningfully busy about a third of the time, every hour, indefinitely. Against expensive frontier pricing the bar is low — under two percent — which is why the self-hosting argument is strongest precisely where people make it least.

"Sustained" is doing real work in that sentence. It is not your peak hour. It is the average over the whole billing period, including nights, weekends, and every week nobody used the feature.

The costs that do not appear in the comparison

monthly cost of self-hosting
The hardware is the cheaper half.
monthly
H100, running 24/7 ~$1,901
25% of one engineer ~$4,000

The engineer is the larger number, and it is the one that never appears in the blog post comparing token prices. Somebody has to own model updates, driver and CUDA versions, inference server upgrades, capacity planning, and being paged when it stops.

Add it in and the all-in comparison at 100% utilisation — the most generous possible assumption — looks like this:

all-in cost per million tokens, 100% utilisation
At perfect utilisation, self-hosting is still marginally more expensive than the cheapest API.
$ per million tokens
self-hosted, all-in ~0.743
cheapest API ~0.700

At a hundred percent utilisation, which nobody achieves, it is still slightly more expensive than simply buying the tokens.

Translated into a realistic monthly volume:

monthly
self-hosted, all-in ~$5,901
cheapest API ~$105

Where the argument actually holds

None of this says self-hosting is wrong. It says the reason people give for it is usually wrong.

Self-hosting wins on data residency, on latency floors you control, on not being deprecated by a vendor, and on sustained high-volume workloads that genuinely keep the batch full. Those are good reasons and they survive scrutiny.

"It is cheaper" is not one of them, unless you can name your sustained utilisation figure — and if you can, you already know which side of the line you are on.

H100 hourly rate
Spot pricing improves the arithmetic. It does not change its shape.

Spot instances at around $2.10/hour against on-demand at around $2.64 shift the break-even point but do not move it to a different kind of place. You are still buying hours and selling tokens, and the ratio between them is still set by how full you can keep the card.

What to look at next

Before comparing any two options, compute your own utilisation: total tokens generated last month, divided by what one card could have produced running flat out for those hours. Most teams have never calculated it, and the number is usually far lower than the intuition.

Next: local inference does not remove the re-read multiplier either — we worked through where the bill actually comes from in episode three.

  • LLM Inference
  • GPU Cost
  • Self Hosting

Written by

Aitsam Ahad

Senior Full-Stack Engineer with 6+ years architecting scalable web applications in Node.js, TypeScript, Express and NestJS on the backend and React/Next.js on the front. Currently Principal Software Engineer at TEO International, Islamabad.

Explore my experience