Last week I had lunch with the CTO of a SaaS company. He opened his laptop and laid two quotes side by side. On one side, a monthly API invoice. On the other, a build-out estimate for a self-hosted GPU server. "We crossed 8 million won. Every month. The approval memo came back with a note: if we keep going for another six months, wouldn''t it be cheaper to just buy the servers?"
This question is a natural next step from the discussion in the previous installment on PoC budgets. Once the PoC ends and a service actually starts absorbing traffic, this exact picture inevitably shows up on the next approval memo. Do we build our own LLM, or do we keep going with APIs?
Start with the fact that the pricing structures are different
The first place people get confused when comparing these two options on the approval memo is that they are fundamentally different kinds of spend. APIs are variable cost. If requests double this month, so does your invoice. Self-hosting is closer to fixed cost. Whether the server handles 100 requests or 1 million, the hourly cost stays roughly the same as long as the GPU is powered on.
That is why the phrase "break-even" makes sense here. At low usage, APIs are overwhelmingly cheaper. Above some threshold, volume becomes large enough to absorb the fixed cost, and self-hosting starts winning. The problem is that the threshold sits much higher than most people imagine.
The price landscape as of 2026
Let''s put concrete numbers on the table. As of August 2026, the per-million-token prices for the major APIs look roughly like this:
- OpenAI GPT-5.5 (frontier): $5 input / $30 output
- Anthropic Claude Sonnet 4.6: $3 / $15
- Claude Haiku 4.5: $1 / $5
- OpenAI GPT-5.4 Nano (ultra-low): $0.2 / — (for ultra-light tasks)
What about self-hosting? If you serve an open-weight model in the Llama 3.1 70B class with vLLM on an 8x H100 server (roughly $19.2/hour) at a throughput of 2,800 tokens per second, the theoretical cost drops to around $1.9 per million tokens. That number gets cited repeatedly in 2026 benchmarks from vendors like Cloudzy and GIGAGPU.
Look at $1.9 alone and self-hosting looks extremely attractive — more than ten times cheaper than GPT-5.5''s average input/output cost. But that number comes with a big asterisk: "only when the GPU is running fully loaded."
Where the break-even point actually sits
The ranges that keep showing up in 2026 analyses are these. To replace a frontier API (GPT-5, Claude Opus class) with a self-hosted open-weight 70B model, break-even sits somewhere around 160 to 250 million tokens per month. Against low-cost APIs (Haiku, GPT Nano), the floor is 50 to 100 million tokens per month, and in practice you need considerably more traffic than that before self-hosting actually pulls ahead.
100 million tokens is hard to picture. If an average chatbot exchange runs about 3,000 tokens, that is roughly 33,000 conversations. To hit 30,000 in a month you need 1,000 per day, every day — most internal tools and early-stage services never come close. When the company behind that 8-million-won invoice actually pulled their usage data, they were running about 40 million tokens per month. Half of the break-even point.
The line items that never make it onto the approval memo
To be honest, the math above only covers pure infrastructure cost. Once you commit to self-hosting, there are line items that rarely appear on the approval memo but always show up in the ledger.
The engineer''s salary for operating the model serving stack. The person who wakes up at 3 a.m. when the GPU dies. The fine-tuning experiments to lift an open-weight model up toward frontier quality. The in-house build of the safety filtering that a vendor API used to handle for you. Security audits to prepare for the possibility of a data leak. Several vendor reports point out that these hidden costs inflate TCO by 30 to 50 percent.
This matters. If you layer these personnel and operating costs onto the "100 million tokens per month" number from the break-even math, the real economic break-even shifts roughly two times higher. In other words, you need something like 200 to 300 million tokens per month before self-hosting is actually cheaper. The number of Korean companies operating at that volume is, frankly, not that large.
Three cases where self-hosting still makes sense
So is the conclusion that self-hosting is premature? Not necessarily. There are three scenarios where self-hosting is the right call on an axis entirely separate from break-even.
First, when data must not leave the building. Medical records, undisclosed financial data, design documents for unreleased products. For some organizations, simply sending this data to a commercial API is a compliance violation. Here, the concept of break-even does not apply — APIs were never on the menu to begin with.
Second, services that are extremely latency-sensitive. Real-time interactions that need to return an answer within 100 ms per exchange cannot tolerate the network round trip of a frontier API. In this case, self-serving is a performance requirement, not a cost decision.
Third, a long-term strategy of avoiding vendor lock-in. If a company is confident this service will still be alive in three years and wants to secure API pricing leverage from today, it will willingly absorb two years of losses upfront.
The most commonly chosen answer: hybrid
Watching real approval decisions play out, the companies that most often get sign-off pick neither pure API nor pure self-hosting, but something in the middle. Tasks that are predictable, high-volume, and low-complexity (document classification, summarization, structured data extraction) get routed to a self-hosted open-weight model, while complex reasoning or sudden traffic spikes are routed to APIs. Vendor case reports repeatedly cite this combination cutting total cost by 30 to 50 percent.
That said, remember that hybrid is a much more complex architecture than it looks. Building the routing logic between the two systems, the caching layer, and automatic fallback on failure takes at least three to four months of engineering. When "we''re going hybrid" appears on the approval memo, the owner has to include this upfront engineering cost in the numbers.
A decision frame that gets approvals through
When a decision feels ambiguous, here is a simple frame that operators can use in practice.
If your current monthly API invoice is under 5 million won, self-hosting is premature. There is far more room to optimize on the API side. Prompt caching, routing to cheaper models, and the batch API alone will easily shave 30 to 40 percent. Once the invoice crosses 15 million won, it is time to start looking at hybrid — from that point on, it is worth running a self-hosting pilot in parallel. When the invoice consistently exceeds 50 million won, the break-even for self-hosting starts to feel within reach.
Layer data sensitivity and latency requirements on top of that to reach the final decision. The CTO from the opening story ran the numbers on the spot and decided to first spend three months optimizing with prompt caching and model routing, then reassess. In quite a few companies, the need for self-hosting actually disappears at this first stage.
Coming up next
This installment only covered break-even based on upfront cost and usage. But the ongoing costs I briefly mentioned earlier — operations staff, retraining, monitoring — are their own topic for the next installment. They are the line items you don''t see in month one but that inevitably become the problem on the approval memo one year in. The next installment will pick up with "The costs you can''t see — operations, maintenance, retraining."
5years+ has supported mid-sized Korean and Japanese companies with exactly this kind of break-even analysis and hybrid architecture design. If a self-hosting quote is currently sitting on your approval memo, before you rush the decision we recommend starting with an hour-long consultation to walk through the numbers together. In practice, delaying the approval memo often saves far more than pushing it through.