When is self-hosting an LLM cheaper than a hosted API?

Only above a break-even volume equal to your monthly GPU cost divided by your hosted cost per task, and only if that volume is below what the hardware can physically serve. A $2/hour instance costs $1,460 a month, so break-even is 21,630 tasks against a model at $0.06750 per task, but 286,275 tasks against one at $0.00510.

Can self-hosting be cheaper at any volume?

No. If break-even sits above the GPU's throughput ceiling, the crossover is unreachable. In our worked example the instance serves 788,400 tasks a month at full utilisation, but break-even against DeepSeek-V4-Flash is 1,390,476 tasks and against Mistral Small 2,703,704, so self-hosting can never win against either on that hardware.

Does a bigger GPU always help?

Not necessarily. A bigger GPU raises both the throughput ceiling and the fixed monthly cost, which raises break-even too. It helps only when you were capacity-limited rather than cost-limited. Check which constraint you actually hit before upgrading.

How much does utilisation matter?

It scales the ceiling directly. Dropping from perfect utilisation to a realistic 40% takes our example instance from 788,400 to 315,360 tasks a month, which turns comfortable cases into marginal ones. Utilisation can be raised by queueing and batching, but that is engineering effort, which is itself a cost.

What does the break-even calculation leave out?

Staffing to operate the instance, redundancy (a second instance doubles fixed cost and therefore break-even), and the fact that self-hosting means open-weight models. If your workload needs a frontier proprietary model, self-hosting is not a cheaper path to the same result.

Self-hosting vs hosted LLMs: when a GPU actually beats the API

A worked, computed break-even: at what monthly task volume does renting a dedicated GPU become cheaper than paying per token? With the exact numbers.

The self-hosting question is usually argued with adjectives. It is a arithmetic question with a specific answer, and the answer depends on exactly two things: how much you pay for the GPU per month, and how much one task costs on the API you would otherwise use.

A rented GPU is a fixed cost. You pay for all 730 hours in a month whether requests arrive or not. A hosted API is a variable cost that scales with usage and is zero when idle. Fixed beats variable above some volume, and the break-even is simply the monthly GPU cost divided by the hosted cost per task.

What that formula hides, and what this guide makes explicit, is a second constraint that decides the question more often than the first: a GPU has a throughput ceiling. If the break-even volume sits above the volume the box can physically serve, self-hosting never wins at any volume.

The honest answer is it depends on volume, and you can compute the exact crossover. A hosted API charges per token, so its monthly cost scales linearly with usage. A dedicated GPU is a fixed monthly cost no matter how busy it is. So self-hosting only wins once you run enough work to amortize the box.

Here's a worked example: a task that sends ~1,500 input and ~500 output tokens across 3 model calls, using a frontier model at $3/$15 per million tokens, versus a $2/hr GPU sustaining 1,800 tokens/sec. The break-even is about 40,556 tasks/month:

Tasks / month	Hosted /mo	Self-hosted /mo	Cheaper
50,000	$1800	$1460	Self-hosted
150,000	$5400	$1460	Self-hosted
300,000	$10800	$1460	Self-hosted
600,000	$21600	$1460	Self-hosted

Your token profile and GPU price will differ - plug your own numbers into the $/task calculator to get your exact break-even and whether your GPU can even sustain the volume.

Running the numbers on a rented GPU? Compare on-demand GPU pricing:

Compare GPU cloud pricing →

The break-even formula, stated plainly

Monthly GPU cost divided by hosted cost per task gives the break-even task volume. Above it, self-hosting is cheaper per task. Below it, the API is.

Take a $2/hour instance running continuously: $2 x 730 hours is $1,460 per month, fixed. Against a model costing $0.06750 per task, break-even is 21,630 tasks per month. Against a model costing $0.00510 per task, break-even is 286,275 tasks. Against one costing $0.00054, break-even is 2,703,704 tasks.

The pattern is the important part: the cheaper the API model, the more work you must do before owning hardware pays off. Self-hosting is not a way to save money in general. It is a way to save money specifically against expensive models at high volume.

The ceiling that decides it: throughput

A GPU can only produce so many tokens per second. That sets a hard maximum on tasks per month, entirely separately from cost. If your break-even volume exceeds that maximum, the crossover point is unreachable and self-hosting is never cheaper, no matter how much traffic you have.

Continue the example: 1,800 tokens per second sustained, on a task consuming 6,000 tokens end to end. That is 1,800 x 3,600 x 730 tokens a month, divided by 6,000 tokens a task, giving 788,400 tasks per month at perfect utilisation.

Now compare that ceiling to the break-even figures. Against GPT-5.5, break-even is 21,630 tasks, comfortably under the ceiling, so self-hosting is viable. Against Gemini 2.5 Flash, break-even is 286,275, still under. But against DeepSeek-V4-Flash, break-even is 1,390,476 tasks and against Mistral Small it is 2,703,704, both far above the 788,400 the box can serve. For those two models this GPU can never be cheaper. You would saturate the hardware long before you saturated the savings.

This is the check most self-hosting discussions skip, and it disqualifies the plan outright against cheap models.

Perfect utilisation does not exist

The 788,400 figure assumes the GPU is busy every second of every hour. Real traffic is not shaped like that. It has business hours, weekday peaks, and idle nights.

At 40% utilisation, a realistic figure for a workload with a daily peak and no queueing, the same instance serves 315,360 tasks per month rather than 788,400. That reshapes the answer: Gemini 2.5 Flash, whose break-even was a comfortable 286,275, is now only barely worth self-hosting, with almost no margin for error.

You can raise utilisation by queueing non-urgent work, batching aggressively, or serving several applications from one instance. Each of those adds latency or operational complexity. That is the real trade: utilisation is bought with engineering effort, and the effort is a cost the spreadsheet usually omits.

The costs that never make the comparison

The arithmetic above compares a GPU bill to an API bill. A real migration carries costs on the self-hosted side that no formula captures.

Someone has to run it. Model weights need updating, drivers break, instances fail and need replacing, and a queue that backs up at 3am pages a human. A hosted API has that staffing built into the price. Redundancy is the same story: one instance is a single point of failure, and a second for failover doubles the fixed cost, which doubles the break-even volume.

There is also a ceiling on capability. Self-hosting means open-weight models. If your workload genuinely needs a frontier proprietary model, self-hosting is not a cheaper route to the same output, it is a different and usually weaker output. Compare like with like, or you are pricing two different products.

Set against that, self-hosting buys things the API cannot sell you: data never leaves your environment, latency is yours to tune, you can serve a fine-tuned model, and your unit economics stop moving when a provider changes its price list.

A decision procedure that takes ten minutes

Measure your real task profile first: tokens in, tokens out, calls per task. Guessing here invalidates everything downstream.

Compute your hosted cost per task at your current model's rates, then divide your prospective monthly GPU cost by it. That is your break-even volume.

Compute the capacity ceiling: sustained tokens per second times 3,600 times 730, divided by tokens per task, then multiplied by the utilisation you can honestly expect. If your break-even exceeds that number, stop. Self-hosting cannot pay off for this workload, and no amount of growth fixes it.

If break-even is comfortably below both the ceiling and your actual volume, self-hosting is worth costing properly, with staffing and redundancy included. If you are within a factor of two of break-even, stay on the API: the margin will not survive contact with real utilisation.

The short version

Break-even task volume is monthly GPU cost divided by hosted cost per task. A $2/hour instance is $1,460 a month fixed.
The cheaper your API model, the harder self-hosting is to justify: break-even is 21,630 tasks/month against GPT-5.5 but 2,703,704 against Mistral Small.
Throughput sets a hard ceiling. At 1,800 tokens/second and 6,000 tokens per task, one instance serves 788,400 tasks/month at perfect utilisation.
Against the two cheapest models tracked, break-even exceeds that ceiling, so self-hosting can never be cheaper at any volume on this hardware.
At a realistic 40% utilisation the ceiling drops to 315,360 tasks/month, which eliminates most of the marginal cases.
Staffing, redundancy and the open-weight capability ceiling are real costs that the break-even formula does not include.

FAQ

When is self-hosting an LLM cheaper than a hosted API?: Only above a break-even volume equal to your monthly GPU cost divided by your hosted cost per task, and only if that volume is below what the hardware can physically serve. A $2/hour instance costs $1,460 a month, so break-even is 21,630 tasks against a model at $0.06750 per task, but 286,275 tasks against one at $0.00510.
Can self-hosting be cheaper at any volume?: No. If break-even sits above the GPU's throughput ceiling, the crossover is unreachable. In our worked example the instance serves 788,400 tasks a month at full utilisation, but break-even against DeepSeek-V4-Flash is 1,390,476 tasks and against Mistral Small 2,703,704, so self-hosting can never win against either on that hardware.
Does a bigger GPU always help?: Not necessarily. A bigger GPU raises both the throughput ceiling and the fixed monthly cost, which raises break-even too. It helps only when you were capacity-limited rather than cost-limited. Check which constraint you actually hit before upgrading.
How much does utilisation matter?: It scales the ceiling directly. Dropping from perfect utilisation to a realistic 40% takes our example instance from 788,400 to 315,360 tasks a month, which turns comfortable cases into marginal ones. Utilisation can be raised by queueing and batching, but that is engineering effort, which is itself a cost.
What does the break-even calculation leave out?: Staffing to operate the instance, redundancy (a second instance doubles fixed cost and therefore break-even), and the fact that self-hosting means open-weight models. If your workload needs a frontier proprietary model, self-hosting is not a cheaper path to the same result.