Self-Hosting Llama 4 vs Paying DeepSeek: The Break-Even Math Nobody Runs

A rented RunPod H100 costs about $3.29 per hour on demand, with spot rates occasionally dipping toward $1.19 (Spheron, 2026). That number anchors almost every self-hosting cost argument, and it is where most of them go wrong. The hourly GPU rate is not the cost you should be comparing against an API bill. The cost that matters is dollars per million tokens at the utilization you will actually sustain, and that figure is usually several times higher than the headline implies.

The teams that get burned are not the ones who chose wrong. They are the ones who never ran the formula. They compared "$3 an hour for a GPU I own" against "$0.28 per million tokens I rent" as if those units were comparable, signed the GPU contract, and discovered six months later that their effective cost was triple the API they walked away from. The math that prevents this is one line long. It is just rarely written down.

The only formula that matters

Self-hosting an open-weight model is renting (or owning) a GPU billed by time, then producing tokens with it. An API is billed by tokens directly. To compare them you have to convert the time-billed resource into a token-billed cost, and that conversion depends entirely on throughput. Everything else in this post is a consequence of that one conversion.

The core conversion, written out

The conversion takes a dollars-per-hour rate, turns it into dollars per second, then divides by how many tokens the card emits each second. Scale the result to a million tokens and you have a number that lines up unit-for-unit with an API price sheet. There are only two inputs, and both are measurable rather than assumed.

effective_cost_per_million_tokens =
    (gpu_dollars_per_hour / 3600) / sustained_tokens_per_second × 1,000,000

The worked single-H100 example

Plug in a single H100 at Spheron's $2.50 on-demand rate, serving a 70B-class model under vLLM or SGLang in FP8 at batch size 64, which Cerebrium measured at about 460 tokens per second (Cerebrium throughput benchmark). The arithmetic falls out cleanly, and the result is the floor every comparison in this post is measured against.

# single H100, 70B model, vLLM/SGLang FP8, batched
# gpu_dollars_per_hour        = 2.50   (Spheron on-demand H100)
# sustained_tokens_per_second = 460    (batch size 64, FP8)
#
# (2.50 / 3600) / 460 × 1,000,000
#   = 0.0006944 / 460 × 1,000,000
#   = $1.51 per million tokens   (at 100% GPU utilization)

Run the same arithmetic at the top of the H100 on-demand range, $3.29 per hour, and the cost rises to roughly $1.99 per million tokens (rates from Spheron). So a single rented H100 serving a 70B-class model lands somewhere around $1.50 to $2.00 per million tokens when the GPU never goes idle. That last clause is doing enormous work, and the next section is entirely about it.

The real cost has three inputs and you control none of them by wishful thinking. The GPU rate is set by your provider. The throughput is set by your model, your serving stack, and your batch size. And the third input, the one hidden inside "at 100% utilization," is set by your actual traffic pattern. Skip the third input and the whole estimate is fiction.

The utilization trap that ruins the estimate

The $1.51 figure assumes the GPU is producing 460 tokens every second of every hour you pay for it. A rented GPU bills 24 hours a day whether it is saturated or sitting at an idle prompt. If your real workload keeps that card busy 10% of the time, you still pay the full hourly rate, and your effective cost per token multiplies by ten. That turns $1.51 per million into roughly $15 per million at 10% utilization, with the same hourly cost simply divided across a tenth of the tokens.

effective_cost = headline_cost_per_million / utilization_rate

# 10% utilization:  $1.51 / 0.10 = $15.10 per million tokens
# 30% utilization:  $1.51 / 0.30 = $5.03 per million tokens
# 70% utilization:  $1.51 / 0.70 = $2.16 per million tokens

The reason production utilization sits so far below 100% is structural, not a sign of a badly run team. Real inference traffic is bursty: it follows diurnal cycles where daytime concurrency can be ten times the overnight floor, it spikes around launches and campaigns, and it arrives in uneven request bunches rather than a steady stream. A continuously rented GPU has to be sized for the peak you cannot drop, so it spends most of its hours under-filled. Continuous batching helps only when there are enough simultaneous requests to fill a batch, and outside peak windows there usually are not.

This is why the published per-token costs for self-hosting are so optimistic. The Spheron benchmark that puts a 70B model at about $2.30 per million on an 8x H100 cluster ($23.20 per hour, roughly 2,800 tokens per second) is real, but it holds only at batch size 256 with the cluster fully saturated (Spheron cost-per-token benchmark). An 8x A100 cluster lands near $2.60 per million under the same all-out assumption. Both numbers describe a GPU running flat out, which is the one condition most production traffic never meets.

Autoscaling and scale-to-zero blunt the trap but do not remove it on rented hardware. Spinning a cold GPU node up takes time to provision, pull the weights, and warm the KV cache, so you either keep a warm floor of capacity running (and paying) or you accept cold-start latency on the first request after a quiet stretch. Serverless GPU billing, where you pay only for active seconds, is the cleanest escape from the duty-cycle problem, and I come back to it under model footprint below. For a 24/7 rented card, the realistic question is not whether you hit 100% but whether you can hold the duty cycle high enough for long enough.

The crossover behavior matters because the curve is steep at the left edge. Moving from 10% to 30% utilization saves you more per token than any model optimization you are likely to ship that quarter. Before you tune anything else, you tune the duty cycle of the card.

The cheap-API baseline self-hosting has to beat

Here is the comparison the scenario-table posts skip. They benchmark self-hosting against frontier closed models, where it looks favorable, and quietly avoid the budget APIs that buyers actually consider first. DeepSeek V4 Flash is priced at $0.14 per million input tokens and $0.28 per million output tokens, with cache-hit input at $0.0028 per million, a 98% discount (CloudZero). A typical mixed input/output workload blends to roughly $0.21 per million. That is one seventh of the self-host floor before utilization even enters the picture.

Against that price, self-hosting does not break even on cost. Not at 100% utilization, not with the cheapest spot GPU, not with the best serving stack. The gap is too large to close with efficiency, because even the spot-GPU floor of about $0.72 per million is more than three times DeepSeek's blended rate.

Option	Price per million (blended)	Notes
DeepSeek V4 Flash	~$0.21 ($0.14 in / $0.28 out)	Cache-hit input $0.0028/M
Fireworks Llama 4 Scout	~$0.40 ($0.20 in / $0.60 out)	Hosted open-weight
Fireworks Llama 4 Maverick	~$0.60 ($0.30 in / $0.90 out)	Hosted open-weight
Groq Llama 70B	~$0.69 ($0.59 in / $0.79 out)	Cheapest hosted 70B found
Fireworks Llama 3.3 70B	$0.90 ($0.90 in / $0.90 out)	128K context
Together Llama 3.3 70B	$1.04 ($1.04 in / $1.04 out)	Hosted open-weight
DeepSeek V4 Pro	~$2.61 ($1.74 in / $3.48 out)	75% promo cuts to ~$0.65 blended
Self-host 70B, single H100, 100% util	$1.51 - $1.99	Formula floor; rises with idle time

Sources for the table: DeepSeek from CloudZero; Fireworks and Groq from the TokenMix Fireworks review; Together AI from its published pricing; self-host floor derived above. The honest reading is blunt. Fireworks AI serves Llama 4 Scout cheaper than you can self-host a 70B at full saturation, and it carries no MLOps burden, no idle billing, and no on-call rotation.

Where the break-even actually clears

Self-hosting can win, but only against premium-tier APIs and only at volume, with the GPU kept busy. Two different thresholds get conflated here, and keeping them apart is the whole game. One threshold is the marginal break-even: the per-token cost at full saturation, which can already beat a premium API. The other is the payback threshold: the monthly volume that recovers the fixed GPU commitment you pay whether or not the card is full.

Independent break-even analyses put the self-host-versus-frontier crossover at roughly $20,000 per month in API spend, or about 500 million tokens per month for a 20-month payback, scaling to 1 billion tokens per month for a 7-month payback when replacing a frontier model with Llama 4 (TokenMix break-even analysis). Against DeepSeek-tier pricing the same analysis pushes the threshold out toward 50 billion tokens per month, which is another way of saying it effectively never clears. Those volume figures assume hardware that can actually absorb the tokens, which is why they belong to dense clusters or owned capex, not a single rented card.

A concrete monthly scenario makes the scale tangible. Suppose you are spending $20,000 a month on a frontier API and considering an 8x H100 cluster, which rents at $23.20 per hour, or about $16,700 per month if you keep it running continuously (Spheron benchmark). At 2,800 tokens per second fully saturated, that cluster can emit roughly 7.3 billion tokens per month, which is the ceiling, not the expectation. If your real traffic only fills it to 30%, you produce about 2.2 billion tokens for the same $16,700, an effective cost near $7.60 per million that no longer looks like a saving against a frontier model and is a catastrophe against DeepSeek. The cluster only justifies itself if your demand can keep it most of the way full, month after month.

The break-even, written as utilization

# Single full-price H100 at $2.50/hr vs Together Llama 70B ($1.04/M):
# self_host_floor = (2.50/3600)/460 × 1e6 = $1.51/M  >  $1.04/M
# -> the per-token floor is already ABOVE Together at 100% util.
#    A full-price H100 never beats Together at any utilization.

# Single SPOT H100 at $1.19/hr vs Together Llama 70B ($1.04/M):
# self_host_floor = (1.19/3600)/460 × 1e6 = $0.72/M  <  $1.04/M
# -> the per-token floor is BELOW Together, so a busy card wins.
#
# The break-even is a UTILIZATION, not a token volume.
# A 24/7 spot H100 always pays its fixed monthly cost:
#   fixed_monthly = 1.19 × 24 × 30 = $857
# A single H100 at 460 tok/s maxes at ~1.19B tokens/month.
# Solve for the utilization u where API cost of produced tokens = fixed cost:
#   857 = 1.04/M × (1.19e9 × u)
#   u  = 857 / (1.04 × 1190) ≈ 0.69
#
# -> Above ~69% sustained utilization the spot H100 beats Together.
#    Below ~69%, the API wins. At full saturation the spot card
#    produces ~1.19B tokens that would cost ~$1,240 on Together,
#    versus $857 rented: about $380/month saved.

That is the trap in sharp relief, and it cuts both ways. The spot card can win, but only on the spot rate and only when you hold utilization above roughly 69% on a model that is barely cheaper than the hosted version. Drop to the full on-demand rate, or let the card idle below that line, and the hosted API is cheaper on every axis you are measuring and several you are not. Token-volume paybacks in the billions only make sense once capacity stops being the binding constraint, which means a denser cluster or owned hardware, not one rented H100 whose monthly output ceiling sits below the volume you would need to clear.

Model footprint changes the fixed cost

The GPU dollars in the formula are not a single H100 for every model. The footprint is set by parameter count and quantization, and a bigger footprint raises the fixed cost before throughput ever enters. Llama 4 Scout, a 109B mixture-of-experts model, fits on one H100 80GB at 4-bit (around 55GB VRAM), but a production deployment at 64K to 128K context needs 2x H100 or a single H200, and full FP16 needs 4x H100 at roughly 218GB (Spheron deployment guide).

Llama 4 Maverick is heavier still. The 400B MoE model with 17B active parameters needs a minimum of 4x H100 80GB at INT4 (around 200GB VRAM), and a production 8x H100 or H200 setup achieves about 126 tokens per second at 100K-plus context (Spheron). Plug 126 tokens per second and an 8x cluster cost into the formula and the per-token cost is far above the single-H100 70B floor. Larger models do not just cost more to run, they run slower per dollar at long context, which moves the denominator the wrong way.

• Scout, single H100 at 4-bit: cheapest footprint, but short context only.
• Scout, 2x H100 for real context: fixed cost doubles, throughput does not.
• Maverick, 4x to 8x H100 minimum: high fixed cost, ~126 tok/s at long context.

If you are testing the waters before committing to rented GPUs, run the model locally first with Ollama to confirm the quantized weights produce acceptable quality, then estimate throughput on the target card before signing anything. A serverless option such as Modal sits between full self-host and a hosted API. It bills only for active GPU seconds, which sidesteps the utilization trap for bursty workloads at the cost of a higher per-second rate, and for traffic that idles most of the day that trade is often worth making.

The cost the formula politely ignores

Every figure above counts only GPU rental. It counts zero engineering hours, and those hours are not a rounding error. A self-hosted inference stack is a system you operate, and each line item below is real, recurring time that never appears in dollars per million tokens.

Stack configuration and quantization validation come first: choosing between vLLM and SGLang, tuning batch size and KV-cache settings, and confirming that the 4-bit or FP8 weights you are running have not quietly degraded output quality on your own evals. Budget a few engineer-days to stand this up and recurring hours every time you change models or context length. Skipping the quality check is how teams ship a cheaper, dumber model without noticing.

Then comes the operational surface that runs forever: autoscaling policy, GPU health monitoring, throughput and latency dashboards, model version rollouts, and an on-call rotation for the night a node falls over at 3am. Even at a conservative loaded engineering cost, a single on-call rotation plus a few hours a week of maintenance can add the equivalent of thousands of dollars a month, comparable to the GPU bill itself for a small deployment. A hosted API absorbs all of this into its per-token price.

The naive comparison treats a rented GPU's cost as fixed while quoting per-token costs that silently assume 100% saturation. The single most important variable, utilization rate, gets buried.

There is also a licensing cost that is not measured in dollars at all. The Llama 4 Community License is not OSI-approved, not Apache, not MIT (Meta). It permits commercial use only below 700 million monthly active users, above which you must request a separate license from Meta at its sole discretion. For most buyers that ceiling is irrelevant, but it is a clause your legal team should read before standing on it.

More restrictive for some buyers is the geography. The license excludes the EU, with rights not granted to individuals domiciled in or companies headquartered in the European Union, save a narrow carve-out for end users of products incorporating the multimodal models (IO+). If your company is headquartered in the EU, self-hosting Llama 4 multimodal is not a cost decision. It is off the table.

When self-hosting is still the right call

Cost is the wrong axis to justify self-hosting against budget APIs, and a hard one to justify against premium APIs below billions of tokens a month. The right reasons are categorical, not financial. Data residency requirements that forbid sending tokens to a third party. Ownership of fine-tuned weights you cannot expose to an API vendor. Compliance regimes where the inference boundary has to sit inside your own network.

Those reasons stand on their own, and they are worth paying a premium for. What does not stand up is the spreadsheet that compares $3.29 per hour to $0.28 per million and concludes you are saving money. You are not, unless you are sustainably saturating that card with billions of tokens against a premium-tier API. The honest framing is that self-hosting buys control, and control sometimes costs more than the API you replaced.

Before you commit, run the full calculation with your own three inputs: your provider's GPU rate, your model's measured tokens per second on that card, and your honest utilization rate (not your hoped-for one). If the result lands above DeepSeek's roughly $0.21 per million, and it almost always will, then write down the non-cost reason you are doing this anyway. If you cannot name one, rent the API.