An open-weight model is a machine learning model whose trained parameters, the weights, are publicly released for download, so that anyone permitted by its license can run it locally, inspect it and adapt it. Among language models, the term distinguishes models that users can host on their own hardware from closed models that are reachable only through a provider’s interface.
Open weights are not the same as open source in the full sense. A release usually includes the weights, a model architecture definition and inference code, but often not the training data, the full training code or the data processing pipeline. The license may also restrict commercial use, field of use or very large deployments, so the label open-weights model describes access to parameters rather than complete openness.
What an open-weight release contains
An open-weight release consists of the numerical parameters plus the minimum needed to use them. For a large language model, this typically means weight files in a tensor format, a configuration describing layers and dimensions, the tokenizer, and a license. Many releases include both a base model trained only on next-token prediction and an instruction-tuned variant prepared for chat and task following.
The table below shows which components are usually included and which are commonly withheld.
| Component | Usually released | Why it matters |
|---|---|---|
| Model weights | Yes | Enable local inference and fine-tuning |
| Tokenizer and configuration | Yes | Required to load and run the model |
| Model card | Usually | Documents intended use and known limits |
| Training data | Rarely | Needed to audit content and reproduce training |
| Full training code and recipes | Sometimes | Needed to rebuild the model from scratch |
Weights are distributed at a given numerical precision, often 16-bit floating point. Community-made quantized versions at 8, 5 or 4 bits are widely produced from these files, which is only possible because the weights are open.
Degrees of openness
Openness in language models is a spectrum rather than a binary property. Discussions often separate three levels: models available only through an API, open-weight models, and fully open models that also publish data and training code. The license adds a second dimension, because the same weights may be free for research yet restricted for commercial products.
| Level | What users receive | What users can do |
|---|---|---|
| Closed, API only | Access to outputs through a service | Use the model under provider terms |
| Open weights, restrictive license | Weights with use or scale limits | Run and adapt within license limits |
| Open weights, permissive license | Weights under a broad license | Run, modify and redistribute widely |
| Fully open model | Weights, data, code and recipes | Audit and reproduce training |
Reading the license is therefore a mandatory step, not a formality. Common clauses include acceptable-use policies, attribution requirements, thresholds on monthly active users and limits on using outputs to train competing models.
Open-weight and closed models compared
The choice between an open-weight and a closed model is mainly a trade-off between control and convenience. Open weights give data residency, predictable versions and freedom to fine-tune; a closed service offers top-tier capability, managed scaling and no infrastructure work. The capability gap between the best closed models and the best open-weight models has varied over time and differs by task.
| Criterion | Open-weight model | API-only model |
|---|---|---|
| Data location | Stays on own infrastructure | Sent to the provider |
| Customization | Full fine-tuning, LoRA, distillation | Limited to offered options |
| Version stability | Fixed until the owner updates | Provider may change or retire versions |
| Operating effort | Hardware, serving and monitoring | Minimal, usage-based billing |
| Safety controls | Owner must add guardrails | Provider filters are built in |
Hybrid setups are common: a small language model with open weights handles routine or sensitive requests locally, while hard cases go to a larger hosted model.
Total cost also differs in structure. A hosted model is billed per token processed, which suits irregular or low volume. Self-hosting has a largely fixed hardware cost, so it becomes economical mainly at steady, high utilization or when regulation rules out external processing.
Running and adapting open-weight models
Running an open-weight model requires enough accelerator memory for the weights plus the context cache. A rough rule is about 2 bytes per parameter at 16-bit precision and about half a byte at 4-bit, before adding memory for the context window. A 7-billion-parameter model thus needs roughly 14 GB at 16-bit and around 4 to 5 GB when quantized to 4 bits.
| Model size | 16-bit weights | 4-bit weights |
|---|---|---|
| About 7 billion parameters | About 14 GB | About 4 to 5 GB |
| About 13 billion parameters | About 26 GB | About 7 to 8 GB |
| About 70 billion parameters | About 140 GB | About 35 to 40 GB |
Adaptation usually relies on parameter-efficient fine-tuning such as LoRA or QLoRA, which trains small adapter matrices instead of the full model. This allows specialization on a single high-memory accelerator and keeps the original weights unchanged.
Risks and common misunderstandings
Releasing weights is irreversible: once files are copied, the publisher cannot recall or patch them. Safety training can be weakened by fine-tuning, so responsibility for guardrails moves to whoever deploys the model. Deployers also inherit the model’s hallucination and bias behavior without the provider’s monitoring.
- Open weights do not mean open data: the training corpus usually remains unknown.
- Free download does not mean free use: license terms may forbid the intended application.
- Local does not mean secure: weight files and serving software must be obtained from trusted sources and kept patched.
- Benchmark scores may not transfer: evaluation on the target task is still required.
Explained without jargon
An open-weight model is like buying a finished engine for your own car. The alternative is riding in someone else’s taxi. The owner can run the engine, tune it and keep it in the garage. The factory and its blueprints, however, stay private.
This brings independence and privacy. It also brings duties. The owner must maintain the engine, supply the computer hardware that fuels it, and drive responsibly.
A typical use case
A law firm must keep client documents inside its own network and cannot send them to an external AI service. Its IT team deploys an open-weight language model of about 8 billion parameters, quantized to 4 bits, on two internal servers with consumer-grade accelerators.
The team fine-tunes the model with LoRA adapters on several thousand anonymized contract summaries and adds a retrieval layer over the firm’s own clause library. Lawyers use it to draft first-pass summaries and flag unusual clauses. Because the weights are fixed and stored locally, results stay reproducible between audits, and no client text leaves the building. The firm still routes complex research questions to human associates, since the model occasionally produces confident but incorrect citations.