← Journal
5 September 20264 min read

Self-hosting an open-weight model is not automatically cheaper

The open-weight models are genuinely good now. The savings argument for running them yourself is weaker than it looks, and it turns on one number most teams never measure.

The open-weight argument has largely been won on quality. DeepSeek V4, Qwen3, Kimi and GLM are close enough to the closed frontier for most production work that "can it do the job" is no longer the interesting question.

So the conversation has moved to cost, and this is where a lot of teams talk themselves into an expensive decision.

Two different prices

Here is the arithmetic that usually gets skipped.

Serving DeepSeek V4 on your own infrastructure works out at roughly $1.74 per million input tokens and $3.48 per million output, against on-demand H100 rental somewhere in the $2.50 to $4.00 an hour range.

DeepSeek's own hosted API lists DeepSeek V4 Flash at about $0.14 per million cache-miss input tokens and $0.28 per million output.

Both numbers are real. They are roughly an order of magnitude apart, and the cheaper one is the API you did not have to operate.

Cost per million tokens, self-hosted against the provider's own APISelf-hosting costs $1.74 per million input and $3.48 per million output. The hosted Flash API costs $0.14 and $0.28.Self-hosted · input$1.74Self-hosted · output$3.48Hosted API · input$0.14Hosted API · output$0.28COST PER MILLION TOKENS · DEEPSEEK V4
List prices at the time of writing, and a short shelf life. MindStudio; OptimNow, 2026

The "self-hosting saves you 3x" claim is generally made against frontier closed-model pricing, and against that comparison it holds. It does not hold against the open-weight models' own hosted endpoints, which are the actual alternative you are choosing between.

Why the inversion happens

Per-token pricing and per-hour pricing fail in opposite directions.

When you rent a GPU you pay for wall-clock time whether tokens are flowing or not. A provider serving thousands of tenants keeps their hardware saturated and amortises it across all of them. You are serving one tenant — yourself — and your traffic has nights, weekends and a launch-day spike you provisioned for and now pay for permanently.

The number that decides this is utilisation, and it is the number almost nobody measures before the decision. At 80% sustained utilisation the per-hour model wins comfortably. At 5% — which is what a lot of internal tooling and early product traffic actually looks like — you are paying for an idle H100 with the enthusiasm of someone who has confused a fixed cost for a saving.

Before choosing, take a week of your real request logs, work out tokens per hour across the whole week including the quiet hours, and divide. If you have not got production traffic yet, you do not have the input to this decision, and the honest answer is to start on the API and revisit.

The reasons that do actually hold

None of this is an argument against self-hosting. It is an argument against justifying it with a spreadsheet that does not survive contact with your traffic pattern. There are three reasons that stand on their own.

The data cannot leave. If you are handling medical records, government data, or anything under a contract that names where bytes may sit, this is not a cost decision and the cost comparison is irrelevant. Through the first half of 2026 open-weight models moved from early-adopter teams into procurement-bound enterprises in finance, healthcare and the public sector, and this is overwhelmingly why.

You need the model to stop changing. Hosted endpoints get deprecated, retuned and repriced. If you have spent months getting prompts and evaluation right against a specific set of weights, owning those weights is worth paying for. This is the reason I find most persuasive and the one that gets discussed least.

The licence matters commercially. Qwen3-235B under Apache 2.0 is a genuinely different proposition from something you may only use under a bespoke agreement — particularly if you ship software to clients who will ask what is inside it.

The cost that is never in the spreadsheet

Running a mixture-of-experts model with a trillion-plus total parameters is not a deployment, it is an operational commitment. Somebody owns batching and KV cache configuration, GPU memory pressure, model updates, and a pager at three in the morning when throughput collapses and nobody can say why.

For a small senior team, the real currency is attention, and inference infrastructure is an excellent way to spend a lot of it on something that is not your product. That does not mean don't — it means count it. If self-hosting saves $400 a month and costs a fifth of an engineer, you have made a bad trade with a good-looking spreadsheet.

A reasonable default

Start on the hosted API for the open-weight model you want, so you are not locked to a closed vendor's pricing and can move later. Instrument utilisation from day one. Move to your own hardware when the data rules require it, when you need the weights frozen, or when sustained utilisation makes the per-hour maths genuinely favourable — and not because a benchmark chart showed a 3x saving against a comparison you were not actually making.

All the figures here are list prices as of early September 2026. In this market that is a short shelf life, which is itself the argument for keeping the decision reversible.

AIinfrastructurecostopen weights

Building something like this?

We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.