The terms “closed model”, “open weight” and “open source” come up constantly in discussions about generative AI. Unfortunately, they are regularly confused with one another. For an architect who has to weigh customisation, sovereignty, cost control and vendor dependency against each other, these distinctions have direct operational consequences.
This article clarifies two things:
- what is an AI model actually made of?
- what do the three levels of openness of an AI model mean: closed, open weight or open source?
What is an AI model made of?
A generative AI model is an assembly of several distinct components. Each one can be released publicly or withheld, independently of the others. The overall level of openness of the model depends on which of them are made public.
The architecture
The architecture is the structure of the model’s neural network. It is defined by a handful of structural parameters:
- The number of layers: this is the depth of the network. The more layers a model has, the more complex the relationships it can capture, at the cost of higher compute and memory requirements. As an order of magnitude, Llama 7B (an open weight model with 7 billion parameters released by Meta, representative of the range of “small open models” intended for self-hosting) has 32 layers. The largest closed models have several hundred.
- The attention type: the mechanism that allows the model, when processing a word, to look at every other word in the context and weigh their relative importance. Several variants of attention exist, each with its own trade-offs between speed, memory and context length.
- The vocabulary size: the number of distinct tokens the model can handle. A token is the elementary unit of text (a whole word, a fragment of a word, or a single character depending on the case). A typical vocabulary contains between 32,000 and 128,000 tokens.
- The activation scheme: the mathematical operation applied to the output of each neuron. Without it, the network would reduce to a plain matrix multiplication and could not learn complex relationships.
The architecture is usually described in a research paper published alongside the model. Even for closed models, part of the architecture is often public, because it serves the vendor’s scientific communication.
→ What an open architecture means for the user. An open architecture is a prerequisite for understanding precisely how the model works and for considering deep modifications (adding or removing layers, changing the attention type). Actually running the model, and porting it to a new hardware platform, additionally requires the weights and the inference code (the program that loads the weights into memory and performs the model’s computations to produce a response; this is distinct from the training code, which is what produces those weights in the first place).
The weights (parameters)
The weights are the numerical values learned during training. They represent what the model retained from the data it was trained on.
These values are distributed as one or more binary files, in standard formats, downloadable from platforms such as Hugging Face. A model with 7 billion parameters amounts to a file of several gigabytes.
What does loading a model mean?
“Loading a model” means placing those values into a machine’s memory so that the model can be executed. Two types of memory are used:
- System RAM: the ordinary working memory of a server, used when execution happens on the processor (CPU). Slow, but it requires no specialised hardware.
- The VRAM of a GPU: the dedicated working memory of a graphics card. This is the standard configuration for inference (running the model to produce a response from a prompt), because a GPU is far faster than a CPU at the massively parallel matrix computations a language model relies on.
In practice, loading a model means reading the weights file from disk, allocating it in memory (VRAM in the majority of deployments), and connecting those values to a software implementation of the architecture.
Two broad families of tooling coexist:
- a reference library such as PyTorch or Transformers (Hugging Face): easy to use, well suited to prototyping and research, but not always optimised for production performance;
- a specialised inference engine, optimised for real service. The two open source references are vLLM (aimed at production at scale on NVIDIA datacenter GPUs) and llama.cpp (aimed at local, portable execution on CPUs or on consumer and mobile GPUs).
→ What open weights mean for the user. Without the weights, you cannot run the model yourself; you can only call an API. With the weights, the architecture and an inference engine, you can run it on your own infrastructure, customise it, and free yourself from an API vendor.
The training corpus
Training a language model happens in two successive phases:
- Pre-training: the model learns to predict the next word from enormous volumes of raw text (web content, books, code, scientific papers). At this stage it is not yet learning to answer questions or follow instructions, only to produce coherent text.
- Post-training: this adjusts the model’s behaviour so that it knows how to respond and follow instructions (covered further down).
The corpus discussed here is the pre-training one. Its size is counted in trillions of tokens (as a reminder, a token represents roughly 0.75 of a word on average in English). Its composition largely determines what the model knows, what it does not know, and the biases it reproduces.
→ What an open corpus means for the user. Without the corpus, it is impossible to redo the training from scratch to obtain an equivalent model. It is also impossible to audit biases rigorously, or to verify whether copyrighted content is present. Publishing the corpus is the most demanding criterion of openness.
The training code and procedures
The training code covers the scripts, the frameworks, the hyperparameters and the validation procedures. Hyperparameters are the configuration settings of the training run that are not learned but chosen in advance.
They have a major impact on the final result. It is the combination of “architecture + corpus + code and hyperparameters” which, run for weeks or months across thousands of GPUs, produces the weights.
→ What open training code means for the user. Without this code, you may hold the weights but you cannot reproduce the training, even with the corpus. You then depend on the initial vendor’s opaque technical choices.
Post-training data and procedures
After pre-training, a model goes through post-training phases that adjust its behaviour. The main ones are:
- Instruction tuning: supervised training on pairs of (instruction, ideal response) that teaches the model to answer instructions rather than simply continue a piece of text.
- Alignment: procedures that steer the model’s behaviour towards responses judged preferable by human evaluators.
- Filtering of harmful outputs: adjustments that reduce the production of dangerous or illegal content, or content contrary to the vendor’s policy.
These phases draw on annotated datasets, often produced by humans, and on procedures specific to each vendor.
→ What open post-training data means for the user. Post-training data determines the tone, the style, the refusals and the conversational behaviour of the model. Without access to this data, it is difficult to reproduce or to deeply modify that behaviour.
Documentation and licence
Documentation covers everything that allows a third party to understand, use and reproduce the model.
Two artefacts have become standards:
- The model card: a descriptive sheet documenting the model’s capabilities, its limits, its known biases, and the use cases that are recommended or advised against. The format was proposed by Google in 2019 and has established itself as a de facto standard on platforms such as Hugging Face.
- The corpus datasheet: the equivalent for the training data. It documents provenance, collection method, the processing applied, identified biases, and legal sensitivities.
The licence specifies the rights of use, modification and redistribution. A restrictive licence (non-commercial use only, a user threshold, a ban on competing uses) can make a model unusable in an enterprise context, even when the weights are public. The licence is not a legal footnote: it is an architectural constraint.
In summary
A model is the combination of the following components:
- an architecture,
- weights,
- a corpus,
- training code,
- post-training data,
- and a licence.
The three levels of openness presented below correspond to three combinations of what is made public.
The three levels of openness of an AI model
Closed model
None of the components is published. Access happens exclusively through an API, under pricing and contractual terms set by the vendor.
Examples: GPT (OpenAI), Claude (Anthropic), Gemini (Google DeepMind), Mistral Large (Mistral AI).
✓ What it gives you
- Operational simplicity (no infrastructure to manage).
- Access to what are generally the highest-performing models on the market.
- Automatic updates.
✗ What it limits
- No possibility of deep customisation.
- Total dependency on the vendor (pricing, availability, terms of use, versions, and so on).
- No guarantee about the model’s behaviour if it changes silently.
- No reversibility other than a full migration to another vendor.
Open weight model
The model’s weights are published and downloadable, under a licence that permits their use. The architecture is generally documented. The corpus, the complete training code and the post-training data, however, are not published.
Examples: Llama (Meta, under the Llama Community License), Mistral 7B and Mixtral (Apache 2.0), Qwen (Alibaba, Apache 2.0 for most of the range), DeepSeek, Gemma (Google), Phi (Microsoft).
An important point that is often overlooked. Open weight licences are not all equivalent. The Llama Community License, for instance, imposes restrictions on competing uses and requires a commercial agreement beyond 700 million monthly active users. Apache 2.0 (Mistral, Qwen) carries no such restrictions. That difference has direct consequences for what a company can do in production.
✓ What it gives you
- Execution on your own infrastructure: full control of inference cost (the GPU resources consumed by each request to the model), of latency, and of the residency of the user data passing through the model.
- Customisation through fine-tuning: a technique that continues training the model on a smaller, more targeted dataset in order to adapt it to a domain, a style or a specific task (the original corpus is not required for this).
- Longevity: an open weight model you have downloaded remains available locally, even if the vendor disappears or changes its terms.
✗ What it limits
- No reproducibility: rebuilding the model from scratch is impossible without access to the corpus and the training code.
- The biases and the contents of the corpus cannot be audited.
- Indirect legal risk: if the training corpus contained copyrighted material used without authorisation, the user of the model inherits a regurgitation risk (the model may reproduce passages close to the original in its outputs).
Open source model in the strict sense (OSAID)
The Open Source Initiative (OSI), which has maintained the canonical definition of open source software since 1998, published a formal definition for AI in October 2024: the Open Source AI Definition (OSAID) v1.0. This definition was developed over two years with more than 25 partner organisations (Mozilla, the Linux Foundation, the Apache Foundation, Microsoft, Google, Meta, Intel and Samsung, among others).
For an AI system to qualify as open source under the OSAID, it must permit four fundamental freedoms:
- Use the system for any purpose without asking permission;
- Study how it works;
- Modify it;
- Share it with or without modifications.
These freedoms require the publication of three sets of components, all under a licence approved by the OSI:
- Data Information: information about the training data detailed enough that a skilled person could rebuild a substantially equivalent system. This wording is a compromise: it does not force publication of the complete corpus (sometimes impossible for legal or data protection reasons), but it does require, at minimum, documentation of the pipeline used to build the corpus: data provenance, the selection criteria applied, the cleaning methods, and the processing carried out before training.
- Code: all of the source code used to train and run the system.
- Parameters: the weights and other parameters of the model.
Examples of models that meet this definition: OLMo (Allen AI), Pythia (EleutherAI), BLOOM (BigScience), Baguettotron and the Pleias-RAG family (Pleias, France), which are built on the Common Corpus dataset.
✓ What it gives you
- Full reproducibility of the model.
- The ability to audit biases from the corpus or from its description.
- The ability to intervene on any component (architecture, corpus, training code).
- Stronger legal safety when the corpus itself is under a permissive licence: if the training data comes exclusively from the public domain, from Creative Commons licences, or from content explicitly cleared for training, the end user does not inherit the legal risk attached to copyrighted material sitting inside the opaque corpora of open weight models.
✗ What it limits
- Fewer strictly open source models are available today than closed or open weight ones.
- Performance: the highest-performing models on the market (known as frontier models, meaning the models that define the state of the art at a given moment, typically the latest GPT, Claude or Gemini) are not open source, because laboratories that publish everything generally have fewer resources to compete on generalist benchmarks.
A word on the confusion in terminology
The open weight category is frequently labelled “open source” in a way that is not accurate, particularly in vendor marketing and in the press. Under the OSAID definition, that usage is incorrect: you cannot speak of open source without publication of the corpus (or at minimum its Data Information) and without the training code. Keeping the distinction between these two levels in mind avoids a great deal of misunderstanding in architectural decisions.
Three risks for the user of an opaque model
The distinction between open weight and strict open source is not merely a theoretical nuance. Using a model trained on a corpus that cannot be audited exposes you to three concrete risks:
- Indirect legal risk: if the model regurgitates copyrighted content into an output that is used commercially.
- Undetected bias: bias whose source cannot be traced.
- Reputational risk: if the model’s vendor becomes involved in a highly publicised legal case.
Implications for enterprise architecture: distinguishing the three layers of sovereignty
Three levels of control coexist, and they apply to different objects:
- The data: the user and business information that passes through the model at inference time. The question being asked: who sees my prompts and my data, and where are they stored?
- The model: the weights that produce the responses. The question being asked: can I run this model on my own infrastructure, without depending on a vendor?
- The corpus: the data the model learned from. The question being asked: what was this model trained on, and can I audit it?
The levers available to answer these questions accumulate naturally rather than mapping one to one onto the layers:
- A managed cloud service (Azure OpenAI, AWS Bedrock) with contractual clauses, European residency and encryption addresses the data layer only.
- Self-hosting an open weight model addresses the data and the model simultaneously: requests no longer leave your infrastructure, and you are no longer tied to an API.
- A strictly open source model (in the OSAID sense), whether self-hosted or trained in house, addresses all three layers at once.
The architectural decision consists in identifying which of these layers the use case genuinely requires:
- A GDPR compliance requirement covering personal data may only require the data layer; a European managed cloud offering is then sufficient.
- A requirement for scientific audit, a heavily regulated context, or a guarantee against regurgitation of copyrighted content requires the corpus layer; only a strictly open source model answers that.
Bibliography and sources
Definition of open source AI
- Open Source Initiative, The Open Source AI Definition v1.0, October 2024. https://opensource.org/ai/open-source-ai-definition
- Open Source Initiative, OSAID FAQ. https://opensource.org/ai/faq
- InfoWorld, “OSI unveils Open Source AI Definition 1.0”, 28 October 2024. https://www.infoworld.com/article/3593266/osi-unveils-open-source-ai-definition-1-0.html
Technical references
- Mitchell et al., Model Cards for Model Reporting, Google, 2019. https://arxiv.org/abs/1810.03993
Organisations and models mentioned
- Pleias (France), AI laboratory and start-up. https://pleias.fr/
- A la french podcast, episode “IA : Pourquoi la taille ne compte plus ?” (in French), with Anastasia Stasenko (CEO of Pleias), 17 February 2026. https://www.youtube.com/watch?v=wirmd5kCWok
- Hugging Face, Baguettotron model page. https://huggingface.co/PleIAs/Baguettotron
- Allen Institute for AI, the OLMo family. https://allenai.org/olmo
- EleutherAI, the Pythia family. https://github.com/EleutherAI/pythia
- BigScience / Hugging Face, the BLOOM model. https://huggingface.co/bigscience/bloom

