Open-Weights Model

The Technical Definition

An open-weights model is a model whose trained parameters — the weights — are published and downloadable, typically under a license that permits use, modification, and in many cases commercial deployment. Llama (Meta), Mistral, DeepSeek, and Qwen (Alibaba) are the most-deployed examples in enterprise. Open-weights is not the same as open source. Open source, in the strict sense, requires the training data, the training code, the data-preparation pipeline, and the architecture to all be published under a license that permits redistribution. Most “open” models in the market today release the weights and the inference code, and keep the training data and training process proprietary.

What This Actually Means for Your Business

The practical question is not “is this open.” The practical question is “what can my team actually do with this model that they cannot do with a closed API.”

What you can do. Run the model on your own infrastructure — on-premise, in your own cloud account, in an air-gapped environment for regulated workloads. Send no data to a third-party vendor. Fine-tune the model on your proprietary data and keep the resulting weights. Inspect the model’s behavior at the level of its parameters, not just its outputs. Deploy without per-token pricing — once the hardware is paid for, the marginal cost of inference is electricity. Avoid the deprecation risk of a closed vendor retiring the model out from under you, because you have the weights and they cannot take them back.

What you cannot do. Inspect the training data — for almost every “open” model on the market, the training data is not published, which means you cannot audit what the model learned or whether it ingested copyrighted material that creates IP exposure. Modify the architecture freely without retraining from scratch — the weights are tied to the architecture they were trained on. Assume the license is permissive — Llama’s license, for example, has a commercial-use threshold that triggers special terms for very large companies, and several “open” licenses prohibit specific use cases. Get vendor support — when something breaks at 2 AM, there is no support line. Your team owns the outcome.

The infrastructure cost is the part that gets underestimated. Running a 70-billion-parameter open-weights model in production at low latency requires GPUs, and the GPUs are not cheap. The total cost of self-hosting only beats the closed-API cost above a usage threshold, and that threshold is higher than most operators initially model. Below the threshold, you pay more to host it yourself than to call a closed API. Above it, the math flips.

Reality Check

What the vendor says: “Our open-source AI gives you full control and freedom.”

What that means in practice: The weights are downloadable. The training data is not. The license has commercial restrictions you should read. Self-hosting requires real infrastructure and real ops headcount. “Full control” is accurate. “Free” is not.

What Operators Actually Do

Operators who deploy open-weights well start by being honest about why they are doing it. There are three legitimate reasons: regulatory or data-sensitivity requirements that prohibit sending data to a third-party API, scale that makes self-hosting cheaper per token than a closed model, or a fine-tuning need where keeping the resulting weights matters more than capability ceiling. If none of those three apply, closed-source is usually the better default.

When they do go open-weights, they pick the model on the actual task, not on the leaderboard. They run the candidate models against a representative eval set on their own hardware. They measure latency, throughput, and cost per useful output. They read the license — actually read it, with legal — for any usage restrictions, attribution requirements, or large-company carve-outs. They confirm the model’s training-data disclosure, because IP indemnification on an open-weights model is on the operator, not the publisher.

The other discipline: they treat the open-weights deployment as a product, not a project. It needs versioning, eval regression, monitoring, and a named owner. The same operational rigor applies whether the weights came from Meta or from OpenAI’s API. The model is not the product. The system around the model is the product.

The Questions to Ask

1. Why open-weights instead of a closed API for this use case? If the answer is “because open-source is better,” push back. Specific reason — data sensitivity, scale economics, or fine-tuning ownership. If none, the closed API is probably the cleaner build.

2. What does the license actually permit, and at what scale does it change? Llama, Qwen, and several others have commercial-use thresholds or restricted use cases. Read the license with legal before the model goes anywhere near production.

3. What is the all-in cost per useful output, including hardware, ops, and eval, compared to a closed API at our volume? Open-weights only wins economically above a usage threshold. Calculate the threshold. If you are below it, the closed API is cheaper and faster to deploy.