Local LLM vs API: when self-hosting is actually cheaper
In the r/startups thread on runaway AI bills, one commenter described the setup a lot of cost-conscious builders are drifting toward, and gave it a good name:
The idea is simple and sound: run a small model you host yourself for the boring, repeatable 80% of the work (the tasks that never needed a frontier model in the first place), and keep the expensive frontier API — GPT-4-class, Claude Opus — for the hard 20% that genuinely needs it. Someone else in the thread put a number on the upside: moving a classification job to a small local model, “costs dropped ~90%.”
That number is real. But I’ve watched people read “90% cheaper” and hear “free,” and that’s how the turbo model turns into a worse deal than the bill they were fleeing. There is no free lunch. The cost doesn’t disappear — it changes shape:
- From a per-token meter you can watch → to fixed hardware, power, and your own time.
- From pay-per-use (idle costs nothing) → to pay-whether-you-use-it-or-not.
Here’s how to tell, before you buy anything, which side of the line you’re on.
What “the bulk” actually is
The turbo model only works because most production AI traffic isn’t hard. It’s the same list from the frontier-tasks post: extracting fields, classifying tickets, normalizing records, converting text to a fixed format. Narrow, repeatable jobs a small model does about as well as a giant one. That’s what you move in-house. You are not trying to replace the frontier model at what it’s good at — you’re relieving it of the work it was overqualified for.
Concretely, “small model” here means the open Qwen family (or Llama, Mistral) in the 3-billion to 32-billion-parameter range — big enough to be genuinely useful on narrow tasks, small enough to run on one consumer graphics card.
What the hardware costs
A graphics card (GPU) is the engine. The number that matters is its memory — it decides how big a model fits. Rough 2026 picture:
| The box | Rough price | Model size it runs well | Speed (one request at a time) |
|---|---|---|---|
| One used RTX 3090 (24GB) | ~$700–900 | 7B–14B comfortably; 32B compressed | a 7B model: ~50–90 words/sec |
| One RTX 4090 (24GB) | ~$1,600–2,000 | same, faster | a 7B model: ~80–130 words/sec |
| Two 3090s (48GB) | ~$1,600 used | up to a 72B model, compressed | ~10–20 words/sec |
| Rent it by the hour (cloud) | ~$0.35–0.70/hr | same as a 4090 | pay only while it’s on |
The trick that makes self-hosting economical is batching — serving software (vLLM, SGLang) runs many requests through the card at once, so while one request reads slowly, the card is actually pushing thousands of words per second in aggregate. That’s why one card can feed a busy app.
Now the honest all-in monthly cost of owning one 4090 box:
- Hardware, spread over ~3 years: ~$50/month.
- Electricity: ~450 watts under load, running all day, at typical rates → ~$50/month (far less if it isn’t on 24/7).
- Your time: the line nobody puts in the spreadsheet, and usually the biggest one. More on that below.
So call it ~$100–150/month in hard cost, plus your labor — and that one box can serve tens of millions of small-model words a day. That density is the whole case for self-hosting.
The break-even, in plain numbers
Take a support-triage classifier, ~500 words per call, and compare three ways to run it:
At 5 million calls a month (a real, busy product):
- Frontier API: ~$10,000–25,000/month. (This is the bill people are fleeing.)
- A cheap hosted small model (someone else runs it, per-use): ~$750/month.
- Your own 4090 box: ~$150/month + your time.
- → Self-hosting wins, even against the cheap hosted option.
At 100,000 calls a month (early traction):
- Cheap hosted small model: ~$15/month.
- Your own box: still ~$150/month + your time.
- → The API wins, by a mile. Don’t buy a GPU to save $15.
That’s the shape of it. Self-hosting only beats a cheap hosted small model once you’re spending somewhere north of ~$200–400/month on steady, high-volume, batchable traffic. Below that, the per-use API is both cheaper and less work. And note what self-hosting never does: it never competes with the frontier model on frontier-quality work. That’s what the Claude fallback in the “turbo model” is for.
You're not deleting the cost — you're trading a bill you rent for an asset you run.
The three hidden charges
These are the “no free lunch” line items, and any one of them can erase the savings.
-
The fallback rate. The turbo model keeps calling Claude “if there’s a bug” or when the local model is too slow or too weak. Every one of those calls costs API money while your GPU is also running. If your local model punts 5% of calls, fine. If it punts 30% because the tasks are harder than you thought, you’re now paying for both — and the 90% saving becomes 40%. Measure the punt rate before you commit to hardware.
-
Utilization. A hosted API costs exactly $0 when no one is using it. An owned GPU costs the same whether it’s flat out or idle. Self-hosting only pays if you keep the card busy — roughly two-thirds of the time or more. Spiky, business-hours-only, or seasonal traffic wastes most of what you bought. (Overnight batch jobs, which don’t care about speed, are the ideal load — cheapest and easiest to keep full.)
-
Maintenance — the 2am charge. This is the one that decides it for most small teams. Graphics drivers, the serving software, the models themselves all need updating; something breaks; and when it does, someone has to be the person who gets up at 2am to fix it. A few hours a month of a founder-engineer’s time is worth more than the GPU. The Reddit user who named the turbo model was refreshingly honest about who he is: “not a founder, 0 business experience, just a nerd.” He runs it because he enjoys running it. That’s a real, unpriced input — and if it’s not true of you or someone on your team, the maintenance tax will quietly exceed the token savings.
When the turbo model pays — and when it doesn’t
Reach for it when:
- You have high, steady, batchable volume of narrow tasks (overnight ETL is the sweet spot).
- A 7B–32B model is genuinely good enough for that work (test it — measure the fallback rate).
- You have, or genuinely enjoy having, the ops capacity to keep a box healthy.
- You can keep the card busy most of the time.
Stick with the API when:
- Traffic is spiky or low-volume — you’ll pay for an idle GPU.
- The task needs frontier-quality judgment — there’s no small-model substitute.
- Nobody wants the 2am pager — the maintenance cost will outrun the savings.
The deeper point
The turbo model isn’t wrong — it’s a genuinely good lever, and one commenter reckons “there’s a ton of money to be made setting up small open models (qwen family) to replace portions of a frontier.” Another was blunter: “if you don’t have a way to work with smaller open models, you don’t have a business.” I agree with both. Just go in clear-eyed: you’re not deleting the cost, you’re trading a bill you rent for an asset you run. That trade is a bargain at high, steady volume with the skills to keep it alive — and a bad deal, dressed up as a saving, everywhere else.
The same rule holds as it does for leaving the cloud generally: owning your infrastructure beats renting it once you’re big and steady enough to keep it busy — and not a moment before.
If you’re staring at an AI bill and wondering whether the turbo model would actually save you money or just move the pain to a GPU under your desk, that’s exactly the sizing I do. It’s just me for now, so I read and reply to every message myself, usually within a day. Send me your setup and your volumes and I’ll run the break-even honestly — including the fallback rate and the 2am cost most spreadsheets leave out — free, within a business day.