Open-Weight Models in Production: Licence, Host, Control

Open-weight means the parameters are published. It does not mean open-source. Many widely used models carry bespoke licences that restrict use by company size, by use case, or by what you may do with the outputs — so the licence is the first question, not the last.

Read the licence before the benchmark

Open-source has a settled meaning: freedom to use, modify and redistribute for any purpose, including purposes the author dislikes. A published weights file under a custom licence is something else, whatever the announcement called it.

Conditions that appear in practice include thresholds above which separate terms apply, prohibitions on specific use categories, requirements to name the base model, and restrictions on using outputs to train a competing model. None of these make a model unusable. All of them decide whether the evaluation you are about to run was worth the time.

Licence review belongs at the start of a model selection, alongside cost. Doing it after the architecture depends on a particular model is how a project discovers a constraint it cannot design around.

What self-hosting actually buys

Reason	Is it real?
Data cannot leave a boundary	Yes — where no hosted provider offers a deployment inside it.
The version must not change under us	Yes. Pinned weights behave the same next quarter as this one.
Cost becomes capacity, not per-token	Yes at sustained high utilisation. Rarely below it.
It will be cheaper	Usually not. See below.
We want control	Too vague to plan against. Name which of the first three you mean.

The cost comparison that gets skipped

Hardware versus per-token pricing is the easy half. The half that decides it:

GPU capacity bills whether it is busy or idle. Utilisation is the whole argument.
Batching, queueing and capacity planning are engineering you now own.
Upgrades, monitoring and on-call are permanent, not one-off.
A hosted provider's next model is an API change. Yours is a project.

None of this argues against self-hosting. It argues against choosing it on a spreadsheet that only compares the hardware.

Residency, checked properly

Data residency is the strongest genuine driver, and the one most often satisfied without self-hosting. Before building, establish whether a regional deployment or an in-tenant offering from a hosted provider meets the requirement as written.

Frequently it does, and the residency constraint turns out to have been a proxy for a procurement question and not a technical one.

The failure mode nobody plans for

Self-hosting removes the risk that a provider changes the model underneath you. It introduces the risk that nobody changes it at all — and two years later the deployment is running weights that are several generations behind, because upgrading is a project and no one owns it.

Give the model an owner and a review date, the same as any other pinned dependency. A quiet risk is still a risk; it just fails later and with less warning.

Frequently Asked Questions

Is an open-weight model the same as open-source?

No, and the difference is contractual, not pedantic. Open-source has an accepted definition covering freedom to use, modify and redistribute for any purpose. Many widely used "open" models publish weights under bespoke licences that restrict use by scale, by use case, or by what you may do with outputs. Read the licence before the benchmark: it decides whether the evaluation was worth running.

What does self-hosting a model actually buy you?

Three things, and only three reliably: data never leaves your boundary, the model version cannot change under you, and cost becomes fixed capacity instead of per-token. If none of those is a live constraint, self-hosting is usually a way of paying more for a worse model in engineering time you could have spent elsewhere.

Is self-hosting cheaper than a hosted API?

At low and moderate volume, almost never. GPU capacity is billed whether or not it is busy, and the engineering to run it — capacity planning, batching, upgrades, monitoring, on-call — is a permanent cost that does not appear in the hardware comparison. It becomes cheaper at sustained high utilisation, which is a narrower band than most projections assume.

When is data residency a real reason to self-host?

When the data cannot lawfully or contractually leave a boundary, and no hosted provider offers a deployment inside it. That is a genuine constraint and self-hosting answers it directly. It is worth checking first whether a regional or in-tenant deployment from a hosted provider satisfies the requirement, because it often does at a fraction of the effort.

How do you stop an open-weight deployment going stale?

Treat the model as a pinned, reviewable dependency with an owner and a review date. Self-hosting removes the risk of a provider changing the model underneath you and replaces it with the risk that nobody changes it for two years. Both are real; the second is quieter and therefore more common.