Where Model Files Come From: Repos, Community Quants, and Licenses
We · October 2026
This is the fifth article in the "AI Tech Explainers" series. The Four Layers of Local AI Tools explained how the software splits into layers, and Choosing a Desktop Client covered the top layer—but neither piece of software produces a model. This article is about where that file comes from. No product reviews, no rankings, no download or sign-up links, and nothing here is legal advice.
AI moves fast. The tools, capabilities and numbers in this article describe where things stand right now, and are for reference only.
Once the software is installed, the real first step is getting a file
The previous articles covered the tools: the engine at the bottom, the runtime handling scheduling and commands, the client giving you a window. They share one trait—none of them contains a model. A machine with the software freshly installed still cannot generate a single token.
To make it talk, you have to put a file into the directory it designates. That file usually starts at tens of gigabytes: the large pile of numbers left over from training—the weights—plus a few small files that tell the software how to read them. The hard part of running a large model locally begins at this step: where to get it, which build to take, and who handed that build to you.
Here is a fact most people miss: the model you hit "download" on in your client is usually not published by the model company itself.
How many hands a model passes through before it reaches you
Take an open model from the end of training to running on your computer. What sits in between is commonly three identities, and they often all exist under the same model name at once.
| Who publishes it | What is inside | Who it is for | Size |
|---|---|---|---|
| Official raw weights | The format at the end of training, usually safetensors, the highest precision | Developers who keep training, do research, or convert formats themselves | Largest—often several times a same-size quantized build |
| Official converted build | The official’s own conversion to a general inference format | People who want convenience and original lineage | Medium |
| Community quantized build | Third parties compress the raw weights and republish them | Local users are in practice the main consumers of this batch | Smallest, and the most versions |
The third kind is the point of this article. Within days of a model’s release, several individual maintainers convert it to GGUF—the format local engines speak most broadly—slice it into a set of files at different compression levels, and each upload them to their own repo. The string of suffixes hanging behind one model name in your client’s model list is, overwhelmingly, these community repos.
How lopsided is that ratio? The figures quoted repeatedly in the field as of October 2026: public repos hold conversions in GGUF form in the tens of thousands, of which the model officials published only a few dozen themselves—on the order of one percent. In other words, the build you can load directly is basically made by the community; the official supplies the raw material (a public statistic, not an exact live count).
That does not mean community builds are untrustworthy, and it does not mean they are better. It means two concrete things:
First, when the same model feels different in two pieces of software, it is usually a quantization difference, not a model difference. Two apps running the same model may behave differently because one loaded a Q4 and the other a Q8, or because one picked a maintainer’s more aggressive level. How compression ratio affects quality and which level fits your VRAM is worked out in Parameters, Quantization, VRAM; here we collect only one conclusion back: the sheer number of community quantized builds is the direct cause of that article’s "one model comes as several files of different sizes".
Second, the officials are not standing still. Some vendors now publish their own compression-optimized builds, so that the low-precision versions the community converts lose fewer capabilities; on Apple Silicon there are also builds that take a separate technical route. These are still versions, still sitting in rows two and three of the table above—only the maker changed.
What is actually inside a repo
Open any model repo and you are met with a pile of files. Three kinds are worth telling apart.
| File type | What it does | Do you need to pick? |
|---|---|---|
Weight files (.safetensors, or .gguf for GGUF) | The model itself—the tens-of-gigabytes thing | Yes—it is the only place you are really downloading something |
| Config and tokenizer files (the small tokenizer and config ones) | Tell the software how to turn characters into numbers and how to build the structure | Usually no—if one is missing, the software says it cannot load the file |
| The documentation page (model card / README) | Says what the model is, what it can do, how it was quantized and what the traps are | Worth reading, especially for a community quantized build |
One convenient thing about GGUF files: the name is the choice you are making. A community repo usually lists a dozen or more files, and the filenames state in plain text the parameter count, the compression level, and whether only some layers were kept. The judgement is not "which file is the authentic one" but "which one fits in my VRAM"—which is also why you can pick these correctly without any graphical interface.
Six clues for judging whether a repo is worth installing
We are not in favor of ranking model repos—their sheer number, uneven update frequency and personal nature make a ranking meaningless. But "is this repo safe to install" does have a concrete method.
Look at who published it. The namespace in front of the repo name is either the model company’s official account or an individual maintainer. The latter is completely normal, but you should know you are installing an individual-maintained build.
Look at whether it says where it was converted from. A decent community quantization states in its model card whose original model it used, by what method it compressed, which layers kept higher precision, and what was tested. A repo that says nothing and just dumps files—skip it.
Use download counts and likes, but only as clues. High numbers mean many users and that problems get noticed; they cannot prove quality, only that you are not the one person stepping on the rake.
Look at the file suffix. This one is pure security and deserves its own paragraph. Historically, one class of model save formats executes code carried inside the file when it is loaded—which means downloading a model file and running a program of unknown origin can be the same level of risk. The two mainstream formats today, safetensors and GGUF, both take the data-only route, and the malicious-model cases in public reporting mostly involve the older format. So you do not need to learn to audit a model; you need one glance at what the suffix is and whether anything else in there looks like a script.
Check the update history. A repo uploaded once on release day and left alone for half a year is a different thing from one where people keep reporting problems and re-publishing fixes. A community quantized build being re-uploaded after a bug is routine.
See whether anyone is discussing it. Much of a community repo’s value lives in its comments: a level that fails to run on a certain machine, a build that converted badly—all surface there. Skimming before you install costs far less than installing and then finding out.
If you have gone through all six and still feel unsure, do not install it. Local models have no "miss it and it is gone" problem—downloading a day later costs you nothing.
Licenses: why an ordinary user should still glance
An open model’s license decides whether you may modify it, whether you may use it commercially, and what conditions you must carry when you pass the model on to others. For ordinary personal use there is usually nothing to act on, but two things are worth knowing.
First, the word "open source" hides a wide spread of freedom. The permissive licenses common in the industry—Apache 2.0, MIT and that family—largely allow modification and commercial use under light conditions; some models instead use community licenses with extra terms, which can include usage restrictions or additional obligations past a certain scale. Both let you run the model locally, but they are not the same answer to "can I sell what I make with it".
Second, the license on the model and the license on the quantized build are not necessarily the same. What you download is usually a community conversion, and the original model’s license normally sits on top of it. Whatever limits the original carries, the conversion generally cannot escape them—a community maintainer cannot relax the upstream terms for you.
We assert nothing here about the grant of any specific model or any specific repo. Terms change, and the same vendor often uses different licenses for different models; the only reliable move is to read the LICENSE file in the repo you are downloading, plus the original model source it names. This article is about looking—not about what you will find.
One more easily overlooked point: model hosting is not one platform. China has its own model communities, and many open models are mirrored on both sides. The difference in download speed and availability is real, but the way you judge who published a file and under what terms is exactly the same—a mirror does not change the origin.
Three questions to size it up
The next time you are about to download a model, three questions are enough:
- Who converted this build? Official or an individual maintainer—and does the model card name the original model clearly?
- Which suffix in that pile of files should I download, and will it fit in my VRAM?
- Is what I plan to do with it (commercial use and redistribution in particular) allowed by this repo’s LICENSE?
If you cannot answer the first two, go back to the quantization article and the six clues above. If you cannot answer the third, read the file—do not guess.
What you accumulate is files, not software
The point this article wants to leave is not really about tools.
The cost of getting software wrong keeps falling—switch clients, reinstall, click download again. But once you have chosen the right build of a model, verified it runs on this machine, and learned what kind of work it suits, the file in your hands is an asset that outlives both the software and the version. That is why we keep saying that when you look at this layer of software you should not stare only at the interface: the interface is the easiest part to replace, and files, formats and licenses—the boring-looking things—are what actually travel with you.
For people who do not intend to manage files themselves, the market already shows attempts to package "pick the right build, match your hardware, download and it works" into one step—list the models your machine can hold, choose one, click ready. The direction is that getting a model should stop requiring you to understand formats, and it is worth watching, but it does not change who has to make the judgements above.