Open weights — what they are and when they beat closed models

Open weights are the published parameters of a trained model. The file of numbers is downloaded, run on a company's own hardware and tuned to its own documents. No call to anyone else's API is needed.

That is how open-weights models work. A closed model is reachable only through the developer's API; an open one runs wherever it is installed.

Why this matters

• To understand when a model on a company's own server costs less than a subscription to someone else's API
• To know that an "open model" and a "transparent model" are different things, and which questions to put to a vendor
• To keep client documents inside the perimeter when the industry demands it

What are open weights in plain words

A finished recipe and a finished dish are different things. The dish can be eaten, reheated, seasoned to taste. The recipe explains what it is made of and what to substitute when an ingredient is missing.

Open weights are the dish. The developer publishes the trained parameters of the model: a file of numbers that can be downloaded and run. The model works, can be fine-tuned and can be built into existing systems. How it was made and which texts it learned from are not included.

Hence the difference from a closed model. A closed model lives on the vendor's server and is reached over the internet with a fee for every request. An open-weights model lives wherever it is installed: on a company's own server, in a private cloud, sometimes on a laptop.

How it works

1. The developer publishes a weights file. Inside are the parameters produced by training. A licence and inference code usually sit alongside it; a description of the training data more rarely.
2. The licence is checked. Apache 2.0 permits using, modifying and selling the result. Other licences restrict industries, company size, or require modifications to be disclosed.
3. Hardware is chosen. The size of the model sets the amount of video memory. Headroom is also needed for the length of the context window and for the number of concurrent requests.
4. Deployment happens inside the perimeter. From there it is an ordinary model running on a company's own hardware, with its own monitoring, updates and on-call staff.
5. Tuning to the task follows. First the company's own documents are connected through search — that is RAG. Fine-tuning comes as the next step, once search proves insufficient.

The order of the steps matters more than speed. The licence is read before any GPUs are bought: a model can fit technically and fail legally.

An example from practice

An insurance company processes roughly 8,000 enquiries a month with a model: claims, certificates, correspondence with clients. Some documents contain personal data, and the security team has forbidden sending them outside.

Two options were costed on the same monthly volume. Through a closed API the bill would come to around RUB 40,000 a month at mid-tier model rates — but with the ban on exporting personal data, that option fails outright. An in-house model on a rented GPU server would run RUB 90,000–150,000 a month including upkeep.

The bill is not the only thing to count. Every month adds work for the team: updates, on-call duty, incident handling. At a volume of 8,000 operations those hours weigh more than the difference in rates. The economics work out where volume reaches at least several hundred thousand operations a month, or where exporting data is expressly forbidden.

Open weights are debated at the regulatory level as well. The open letter "Open Weights and American AI Leadership", released on 24 July, had been signed by more than 230 companies and organisations by 30 July, among them Nvidia, Meta and Microsoft: they object to premature restrictions on publishing weights.

What business gets out of it

• Documents never leave the perimeter. For banks, healthcare and anyone handling personal data, this is often the only workable option. Processing requirements are covered in the FSTEC order.
• The bill stops tracking volume. Hardware costs the same at 10,000 operations as at 500,000. As load grows, the cost per operation falls, while an API's bill rises linearly. The crossover point can be found with the budget calculator.
• The version stays put. A closed model's vendor changes it whenever it sees fit, and every workflow tuned to it has to be retested. Downloaded weights do not change on their own.
• The model can be tuned to a company's own documents. Industry terminology, internal formats, the quirks of particular contracts — all of it is built in through fine-tuning rather than by hunting for the right prompt wording.

When it can be skipped

A small volume is served more cheaply by an API. A few thousand operations a month pay for neither a server nor the person who runs it: operating costs exceed the entire bill for calling someone else's model.

Open weights are also unnecessary where the data is not sensitive anyway: website copy, draft emails, processing public documents. Here speed of launch wins — a closed model is working an hour after sign-up.

One more case is the absence of an in-house operations team. A model on a server needs on-call staff, updates and incident handling. Without those people, the open-weights option turns into a project that will stall one day with nobody to restart it.

What is worth checking

First: the word "open" is sold more broadly than it should be. Sometimes only the weights are published, sometimes inference code is added, rarely any information about the training data. The Open Source AI 1.0 definition from the Open Source Initiative requires all three parts: the parameters, the full training and inference code, and a description of the data detailed enough for a specialist to build an equivalent system. The training data itself does not have to be disclosed. Access to weights means a model can be deployed, but not that anyone understands what it learned from.

Second: quality is tested on a company's own tasks, not read off comparison tables. The gap between open and closed models on general benchmarks is narrowing, but on a particular flow of documents it can look quite different. The measurement is made on a sample of several hundred real cases before any hardware is bought.

Third: contractors should be asked for a full cost of ownership for a year. Server, licences, updates, on-call duty, replacing the model a year out — all of it counted together. Comparing "the rate per million tokens against the price of a GPU" shows nothing: only annual totals at the same volume of operations are comparable.