Model Weights, Checkpoints and What “Open” Really Means
6 min read · updated August 3, 2026
“The weights are open” is doing a lot of work in a short sentence. It says something precise about a directory of files and something much less precise about what you are allowed to do with them, and the two get conflated constantly.
What is in a checkpoint
A released model is a directory, and it is worth knowing what each part is because the parts have different licences, different risks and different consequences if you get them wrong.
| File | Description |
|---|---|
| weight shards | The tensors — every learned number, split across files so each fits comfortably in memory. This is the model in the sense people mean. |
| config.json | Architecture: layer count, hidden width, head counts, vocabulary size, activation, position scheme. The shapes that make the parameter arithmetic work out. |
| tokenizer files | The vocabulary and merge rules. Wrong tokenizer, right weights, and the output is fluent noise. |
| tokenizer_config.json | Often carries the chat template, which is what tells you the checkpoint expects to be spoken to in turns. |
| generation_config.json | Default sampling parameters and stop tokens. The defaults a runtime uses if you set nothing. |
The weights are only meaningful in combination with the rest. A tensor file without its config is a large blob of numbers with no arrangement, and without the tokenizer there is no way to turn text into indices that mean anything to it.
The size of the directory is arithmetic, not a mystery: parameters times bytes per parameter. A 7B model at bf16 is about 13.5 GB, usually split into shards of a few gigabytes each so that a download can resume and a load can stream. The same model quantized to four bits is roughly 4 GB — the same parameters, a quarter of the bytes, and measurably different behaviour. The parameter count in the model card does not change with quantization, which is exactly why it is not sufficient to tell you what you are about to run.
Formats, and one real security risk
The distinction that matters is not compression, it is what happens when the file is loaded.
- safetensors. A header of tensor names, shapes and offsets, then raw bytes. Loading is a parse and a memory map. It cannot execute anything, which is the entire reason it exists.
- PyTorch
.bin/.pt. Python pickle files. Unpickling is by design capable of constructing arbitrary objects and therefore of executing arbitrary code, so loading an untrusted pickle is running an untrusted program. This is a documented property of the format, not a speculative vulnerability, and it is why the ecosystem migrated. If you are downloading community checkpoints, prefer safetensors and treat a pickle-only release as code you are choosing to run. - GGUF. A single-file format used by llama.cpp and things built on it, carrying weights, metadata and tokenizer together, usually quantized. Convenient for local inference; see model file formats and choosing a quantization for what the trade costs.
What is not released
Even for the most permissively licensed models, four things are almost always absent: the training data, the data-processing and filtering code, the training code and configuration, and the intermediate checkpoints. A few projects publish some of these; most publish none.
The consequence is exact. With weights you can run, inspect, quantize, fine-tune and distil. You cannot reproduce, cannot audit what the model was trained on, and cannot rebuild it with one dataset removed. That is a real limit on what “open” buys, and it is why the terminology fight is not pedantry.
It is also why the Open Source Initiative’s Open Source AI Definition, published in 2024, asks for more than a licence on the weights: it requires enough information about the training data for a skilled person to build a substantially equivalent system. Whether that bar is the right one is genuinely contested — several widely-used releases fail it while being far more open than the alternative — but the definition at least names the thing the weights alone cannot give you.
A practical corollary for anyone doing due diligence: questions about copyright, personal data or licence contamination in the training corpus cannot be answered from a checkpoint. You are relying on the publisher’s statements, and the indemnity clause — or its absence — is the part of the licence that tells you who carries that risk.
Licence families
A per-model licence table would be wrong within a release cycle, and any specific claim here would be unverifiable by the time you read it. The families are stable, so here are the families and the clause each turns on. Read the actual licence text shipped with the checkpoint — terms differ between versions of the same family.
| Family | Description |
|---|---|
| OSI-approved permissive | Apache-2.0, MIT. No field-of-use restriction, no user threshold. This is the only family that is open source in the sense the term is defined. |
| Community / bespoke | Free for most uses, with an acceptable-use policy, sometimes an attribution or naming requirement, and sometimes a monthly-active-user threshold in the hundreds of millions above which a separate licence must be requested. Fails the open-source definition because of the restrictions, not because of the price. |
| Non-commercial / research | CC-BY-NC and equivalents. Fine for evaluation and papers; not shippable in a product, including internally in a commercial company. |
| Gated access | The licence may be permissive while distribution sits behind an acceptance click or an approved-account list. Affects redistribution and CI more than it affects use. |
| Output and derivative terms | A separate axis found inside several of the above: whether you may use the outputs to train another model, and what a derivative must be named. This is the clause most often missed. |
The vocabulary that survives all this is: open weights for a downloadable checkpoint under any terms, open source only where the licence grants use, study, modification and redistribution for any purpose without field-of-use limits. The distinction and its consequences are the subject of open weights versus open source.
What to check before you ship
- Field-of-use restrictions, and whether your use is in the acceptable-use policy.
- Any scale threshold, and how it is measured — users, revenue, or something else.
- Whether outputs may be used to train other models.
- Naming and attribution obligations on derivatives.
- Redistribution: may you host it, ship it inside an appliance, or put it in a container image?
- Whether the licence covers the weights only or also the tokenizer and the code.
- Which checkpoint variant you actually pulled — base, instruct or chat — since they occasionally carry different terms as well as different behaviour.
One operational habit is worth more than the rest of the list combined: pin the revision. A model repository is mutable — weights can be replaced, a tokenizer corrected, a configuration adjusted, a licence amended — and a build that fetches “latest” can change underneath you with no code change and no version bump. Pin the commit hash, record it next to the eval results it produced, and treat a revision change as what it is: a new model, requiring the same verification as any other.