API LLMs are cheaper at low or variable volume because you pay only per token with no idle cost; self-hosting on your own GPUs is cheaper at high, steady volume that keeps those GPUs busy. The decision is a break-even: find the token volume at which the per-token cost of running your own GPUs drops below the API rate. Self-hosting carries hidden costs, GPU idle time, engineering effort, and peak headroom, that often erase the apparent saving at moderate volume. A hybrid, self-hosted base load plus API burst, is frequently the lowest-cost answer. Calculate it from your real measured traffic, not a spec sheet.
Last updated: June 2026
Choosing between a self-hosted LLM and a model API is a cost break-even problem. An API charges per token with no fixed cost, so it scales perfectly with usage and is cheapest when usage is low or uneven. Self-hosting means renting GPUs by the hour and paying for them whether busy or idle, so it is cheapest only when high, steady volume keeps utilization near full. The right choice is whichever is cheaper at your actual token volume and traffic shape, and the only way to know is to compute both honestly, including the overheads self-hosting hides.
This article is part of our AI, GPU and ML cluster. For the full picture start with the complete guide to AI and GPU cost optimization, the pillar this piece links up to. If you decide on an API, the next step is how to cut LLM API costs with caching and prompt compression, and if you use Amazon Bedrock, see Amazon Bedrock pricing explained.
What is the real difference in cost structure?
The difference is fixed cost versus variable cost. An API LLM is pure variable cost: a per-token rate, billed only on use, that drops to zero when idle. A self-hosted LLM is mostly fixed cost: GPU instances billed by the hour regardless of traffic, plus the engineering and operations to run them. This is why the answer flips with volume. Variable cost wins when volume is low, because you pay nothing for idle capacity. Fixed cost wins when volume is high and steady, because the fixed hourly cost spreads across enough tokens to undercut the per-token rate. Utilization is the hinge, the same idle-capacity issue covered in what is GPU utilization and why idle accelerators cost so much.
| Decision criterion | API LLM | Self-hosted LLM |
|---|---|---|
| Cost structure | Variable, per token | Fixed, per GPU-hour |
| Pay when idle? | No | Yes |
| Best at | Low or variable volume | High, steady volume |
| Engineering effort | Minimal | Significant, ongoing |
| Control and privacy | Provider-managed | Full control |
| Scales to zero | Yes | No |
Verdict: default to an API until sustained volume is high enough to keep self-hosted GPUs busy, then move the steady base load in-house and keep an API for the spikes.
Step 1: How do I measure my real token volume?
Pull input and output token volume per day and per hour over a representative period, and note how peaky it is. Peakiness matters as much as the total, because a workload that doubles every afternoon needs GPU headroom that sits idle the rest of the day. Capture the distribution, not just the average, so the self-hosted estimate accounts for the capacity you must provision for peaks. This measured volume is the input to every step that follows and the reason instinct-based decisions usually overspend.
Step 2: How do I cost the API option?
Multiply your token volume by the per-token rate of the model you would use, separating input and output tokens since output usually costs more. This gives a clean monthly API cost that scales linearly with usage and requires no capacity planning. Use current published rates and verify them against the provider's pricing page, since model prices change. The API number is the benchmark the self-hosted option has to beat once its full overhead is counted.
Not sure whether your LLM workload should be self-hosted or on an API?
Our cost audit measures your token volume, costs both options fully including idle GPU and operational overhead, and finds the break-even and the hybrid split that minimizes your LLM bill. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Step 3: How do I cost the self-hosted option fully?
Size the GPUs your peak throughput needs, then add every overhead, not just the compute rate. Start with the hourly cost of enough GPU instances to serve your peak at target latency, billed around the clock since you cannot scale them to zero instantly. Then add the costs spec-sheet math ignores: idle time between peaks, engineering and on-call effort to run the serving stack, model and dependency maintenance, and headroom for growth. These overheads are where self-hosting estimates go wrong, and they routinely turn an apparent per-token saving into a real loss at moderate volume. Right-sizing the GPU fleet is its own discipline, covered in how to right-size GPU instances for model serving.
Step 4: How do I find the break-even volume?
Compare the two fully-loaded costs at your current volume and at your expected growth to locate the crossover. Below the break-even, the API is cheaper because the self-hosted GPUs sit underused; above it, self-hosting wins because the fixed cost spreads across enough tokens. Plot both as a function of volume and mark where the lines cross. If your current and near-term volume sit clearly below the crossover, stay on the API; if clearly above and steady, self-host. If you are near the line, the hybrid usually wins.
Step 5: How do I decide and keep the decision current?
Choose the cheaper option for your volume, then revisit as traffic, prices, and utilization move. The break-even is not permanent: API rates fall, your volume grows, and utilization shifts, so a decision that was right last quarter can be wrong this one. Where you are near the crossover, run a hybrid, serve the steady base load on self-hosted GPUs sized to that floor and burst to an API for spikes, so you never pay for idle capacity. Re-check the math on a cadence as part of your AI cost scope, which we cover in how to build an AI cost FinOps scope for 2026.
The AI and GPU Cost Control Guide includes our self-hosted versus API break-even calculator with the full overhead checklist. It is the downloadable companion to this article.
Frequently asked questions
Is it cheaper to self-host an LLM or use an API?
It depends on volume and utilization. API LLMs are cheaper at low or variable volume because you pay only per token with no idle cost. Self-hosting becomes cheaper at high, steady volume that keeps your GPUs busy, since the fixed hourly cost of the instances is then spread across enough tokens to beat the per-token API rate. The crossover is the break-even you must calculate for your own traffic.
What hidden costs does self-hosting add?
Self-hosting adds GPU idle time when traffic dips, engineering and on-call effort to run the serving stack, model and dependency maintenance, and the cost of capacity headroom for peaks. These overheads often erase the apparent per-token saving at moderate volume, which is why the API option wins more often than spec-sheet math suggests.
At what volume does self-hosting pay off?
Self-hosting pays off once sustained token volume is high enough that your GPUs stay highly utilized and the per-token cost of running them falls below the API rate. There is no universal number; it depends on the model size, the GPU you would use, your utilization, and the specific API rate, which is why you compute the break-even from your own measured traffic.
Can I use both API and self-hosted models?
Yes, and a hybrid is often the cheapest shape. Serve your steady base load on self-hosted GPUs sized to that floor, and burst to an API for spikes and rare large requests so you never pay for idle capacity. Routing simpler requests to smaller or cheaper models within either path lowers cost further.
The short version
Choose between self-hosted and API LLMs on a break-even: APIs win at low or variable volume, self-hosting wins at high, steady volume that keeps your GPUs busy, and a hybrid wins near the crossover. Cost both options fully, including the idle and operational overhead self-hosting hides, then decide from your real traffic and revisit it as conditions change. When you want that break-even calculated and the lowest-cost split put into production, that is exactly what our FinOps implementation service delivers.
Written by Fredrik Filipsson and reviewed by Morten Andersen, applying the See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.