LLM API vs Self-Hosting: Doing the Break-Even Math
As open-weight models became runnable in-house, a question appeared: is it better to keep using an API, or to grab a GPU and self-host? The answer comes from arithmetic, not taste. The conclusion up front: an API is right for most teams, and self-hosting is the choice when steady throughput keeps a GPU full or when privacy and regulatory requirements are explicit. Server sizing itself is covered in LLM Self-Hosting Server Sizing; this post is the “should we do it at all” calculation that comes before it. Prices are as of mid-2026.
Billing structure: per token vs per GPU-hour #
An API bills per token. It prices input and output tokens in units of a million, and costs nothing when idle. A mid-tier model (say, Llama 3.3 70B serverless) runs around $0.88 per million tokens each way; frontier commercial models (Claude Sonnet, GPT, Gemini Pro class) run $2〜3 input and $12〜15 output. Infrastructure, scaling, and upgrades are all baked into the price.
Self-hosting bills per GPU-hour. However many tokens you produce, you pay for the time you hold the GPU. One H100 runs $4〜8 an hour on hyperscaler on-demand, $2〜3.3 on specialist GPU clouds (Lambda, RunPod, and the like), and down to $1〜2 on spot. Idle time still costs money as long as the GPU is held.
So the comparison narrows to one axis: the fraction of time the GPU actually produces tokens — utilization.
Break-even: the tokens one GPU produces in a day #
Run the numbers. Put a 70B-class model on a single H100 with vLLM at 4-bit quantization (see the quantization comparison), batch concurrent requests, and you get throughput in the hundreds to a thousand tokens per second. Take a comfortable 500 tokens/second: that is 1.8M tokens per hour, and about 43M tokens over a full 24 hours.
- Self-hosting cost: an H100 at a specialist cloud’s on-demand $3/hour is $72 a day. Producing 43M tokens works out to about $1.7 per million tokens. At spot $1.5/hour it drops to about $0.8 per million.
- API rate: an open model of the same class runs around $0.88 per million tokens serverless.
The key emerges here. Only by keeping the GPU full 24 hours does self-hosting cost approach or slightly undercut the API. At half utilization the per-token cost doubles and the API clearly wins. A service that gets traffic only a few hours a day is buying an idle GPU by self-hosting. Conversely, a workload that saturates the GPU continuously with batch and bulk processing (mass document classification, embedding generation, offline summarization) crosses over into economies of scale.
The variables that move the crossover #
- Utilization: this is the whole calculation above. Full 24 hours favors it, intermittent works against it. The always-on GPU with no scale-to-zero is self-hosting’s intrinsic weakness.
- Batch processing: work that needs no real-time response can fill the GPU to 100% via batching. APIs offer batch discounts (about 50%) too, but self-hosting lowers per-token cost directly by driving utilization up.
- Quantization: dropping to 4-bit fits a bigger model on the same GPU or raises throughput, lowering per-token cost — at the price of some accuracy, so be careful with reasoning and code tasks (see the quantization comparison).
- Model class: replacing a frontier commercial model (output $15/million) is a different calculation from replacing a mid-tier open model. If you need frontier-class quality and open models cannot deliver it, self-hosting is not an alternative to begin with.
Hidden costs: the GPU rate is not the whole bill #
Self-hosting cost carries items beyond the GPU-hour rate. The MLOps people who deploy and update models, redundancy for availability (a second GPU), handling traffic spikes, and re-validation every time a new model drops all become standing work. An API absorbs all of it into the vendor. The gap between demo and production is covered in LLM App Operations #1; self-hosting stacks a layer of infrastructure operations on top of that.
APIs have hidden items too. Skip prompt caching (about 90% off repeated prompts) and the bill inflates; there are rate limits, vendor lock-in, and the risk of a model version changing without notice.
What decides it outside of price #
When break-even is ambiguous, the decision comes from requirements, not price.
- Data privacy and regulation: in medical, financial, or classified environments where data cannot leave for an external API, it is self-hosting (or a dedicated in-VPC deployment) regardless of cost.
- Latency: an on-prem GPU that is physically close eliminates the network round trip. Though a regional API endpoint narrows much of that gap.
- Customization: serving fine-tuned weights directly or applying special decoding is freer when self-hosted.
- Team capacity: without people to operate GPU serving, self-hosting is effectively more expensive even when the raw cost is a little lower.
The selection order #
- Filter on requirements first: a regulation against sending data outside means self-hosting, full stop; otherwise move to the math.
- Estimate utilization: steady or batch throughput that saturates a GPU 24 hours makes self-hosting a candidate; intermittent traffic means an API.
- Match the model class: first confirm an open model meets your quality bar. If frontier class is required, self-hosting is not an alternative.
- Compare on total cost: add redundancy, operations staff, and re-validation to the GPU-hour rate, and compare against the API’s post-caching rate.
- Consider hybrid: starting on an API and peeling off only batch bulk work to self-hosting is a common optimum.
Summary #
- APIs bill per token, self-hosting per GPU-hour. The comparison narrows to a single axis: GPU utilization.
- Only a fully utilized 24-hour H100 brings self-hosting cost (about $1.7 per million tokens, $0.8 on spot) into contention with an open-model API (around $0.88). At low utilization the API clearly wins.
- Batching and quantization raise utilization and throughput, moving the crossover toward self-hosting.
- Operations staff, redundancy, and re-validation beyond the GPU rate are self-hosting’s real cost. The API’s hidden items are un-applied caching and vendor lock-in.
- When break-even is close, privacy, regulation, latency, and team capacity decide. Default API plus self-hosting only batch work is a common optimum.