gensai.ai
Generative artificial intelligence is settling into companies: internal chatbots, answer engines connected to business data, document analysis, agents automating processes. Behind each of these uses sits the same component: the language model.
But not all models are equal, and above all, they are not obtained the same way.
Should you choose a proprietary model, an open source model or an open-weight model? And what do these terms really mean? The answer determines the confidentiality of your data, your costs and your technological autonomy.
In reality, the point is not to have "the best model on the market". The point is to choose the right level of openness for your sovereignty, budget and compliance constraints.
Open-weight, open source, proprietary: three levels of openness
A proprietary model is used only through its publisher's API: GPT-5 (OpenAI), Claude (Anthropic) or Gemini (Google). You never access the model itself: your requests travel to the provider's servers, and usage is billed.
An open-weight model publishes its weights, that is, the billions of parameters learned during training. Anyone can download and run them at home; we come back to this in detail just below. The training data and full code, however, often remain closed, and the licence may impose conditions: Meta's Llama, for instance, is distributed under a community licence that is not a free licence in the strict sense.
A genuinely open source model goes further. Since October 2024, the Open Source Initiative has published an official definition of open source AI: weights, code and detailed information about the training data must be accessible under an open licence. Few large models comply fully. In practice, models such as Mistral Small or Mixtral (Apache 2.0 licence), DeepSeek-R1 (MIT licence) or Microsoft's Phi family come closest: their licence allows unrestricted commercial use.
For a company, the nuance is less legal than strategic: open-weight is generally enough to guarantee what matters most, running the model at home.
An open-weight model, concretely, what is it?
A simple image: the taxi and the engine.
Using a proprietary model is taking a taxi. You never drive: you state your destination, the driver handles it, and the meter runs. The meter is the tokens: every question and every answer is billed. Simple, maintenance-free, but you choose neither the vehicle nor the route, and the driver always knows where you are going.
An open-weight model is a manufacturer delivering the complete engine, ready to install. On the other hand, it keeps its blueprints and its factory: the training data and code are not provided. That is the whole nuance with complete open source, which would deliver the blueprints too.
What do the files contain, and what happens at runtime?
The weights are immense tables of numbers: the billions of settings the model learned during training. All its knowledge sits there, engraved in those values, the way an engine's settings are fixed in metal. They download for free from platforms such as Hugging Face, as a handful of standardised files: count roughly 14 GB for a 7-billion-parameter model, 140 GB for a 70-billion one.
At runtime, free software such as Ollama or vLLM loads these files into memory, on a server or even a workstation. Each question is split into tokens, flows through the neural network guided by the weights, and comes out as an answer. Essential point: the weights are read, never modified. Your conversations leave no trace in them; the engine does not wear out and learns nothing behind your back.
What can you do with the weights once you own them?
This is where open-weight earns its keep. Once the engine is in your garage, you can:
- choose the engine size: most families come in several sizes (3, 7, 70 billion parameters), from city-car engine to truck engine, depending on the power and hardware you have;
- lighten it: quantization compresses the weights by reducing the precision of the numbers, like swapping steel for aluminium; the model loses a touch of finesse but fits in 4 to 8 GB and runs on standard hardware;
- tune it to your taste: fine-tuning adjusts the weights on your data; its light variant, LoRA, simply bolts small removable adapter parts onto the engine, without ever touching the original block, which can then be reused for other purposes;
- freeze it for good: keep exactly the same version for years, something no API guarantees, a decisive asset for auditability and compliance;
- embed it: in an On Premise server, a museum kiosk, an industrial box, with no Internet connection.
In practice, this changes three things for a company: confidentiality (your documents never leave your infrastructure), cost (no more token meter, a fixed server and energy cost) and durability (the model will still run in ten years, even if its publisher disappears or changes its prices).
The delivered engine is already run in: it leaves the factory with all its knowledge, acquired during training. What remains is adapting it to your road, and that is precisely the point of fine-tuning, RAG and memory, covered further down.
Who offers models you can run On Premise?
The range of self-hostable models has broadened considerably. You can now deploy on your own servers:
- Mistral AI (France): Mistral Small and Mixtral under Apache 2.0, plus commercial models deployable on site under licence;
- Meta: the Llama family, the reference for open-weight deployments;
- Google: the Gemma models, open versions derived from Gemini;
- OpenAI: gpt-oss-20b and gpt-oss-120b, published in August 2025 under Apache 2.0;
- DeepSeek and Qwen: strong models under MIT or Apache licences;
- Microsoft: the Phi family of SLMs, under MIT licence.
On the hardware side, the orders of magnitude have become reasonable thanks to quantization: a compressed 7-billion-parameter model fits in 5 to 8 GB of memory and runs on a recent workstation; a 70-billion one calls for 40 to 80 GB and a dedicated GPU server. This is what allowed Gensai to run the "Monsters of the Oceans" voice installation fully locally, on a simple Mac Mini, with no Internet connection.
Self-hosting also changes the economics. Proprietary APIs bill per token: every question and answer has a cost, which grows with usage. With a model hosted on your infrastructure, tokens do not disappear technically, but their billing does: the cost becomes fixed (server, energy), whatever the request volume. For intensive usage, the switch pays for itself quickly.
How is an LLM or an SLM made?
An LLM (Large Language Model) is born of a three-step process. First, collecting and cleaning massive data, several trillion tokens of text. Then pre-training: for weeks or months, on thousands of GPUs, the model learns a single thing, predicting the next word. From this simple task, repeated at a dizzying scale, its abilities emerge. Finally post-training: humans refine the model's behaviour through instruction and reinforcement (RLHF), to make it useful, polite and safe.
An SLM (Small Language Model) follows the same path in a more compact form, often through distillation: a large model teaches a small one, which retains the essentials for a far lower running cost. We detail this in our article on pre-trained LLMs.
Why does a model not learn on the fly?
A deployed model is frozen: it learns nothing from your conversations. That is a design choice, not a technical limit.
History proved it. In March 2016, Microsoft launched Tay, a chatbot designed to keep learning from conversations on Twitter. In less than 24 hours, coordinated users made it produce hateful statements, and Microsoft withdrew it with an apology. A model that learns on the fly can be manipulated by anyone.
Frozen pre-training is therefore a protection: the model's behaviour is validated once, then stable, auditable and compliant.
Fine-tuning, RAG, memory, the Internet: how do you complement a frozen model?
If the model does not learn continuously, how do you adapt it to your company? Four complementary paths exist.
Fine-tuning partially retrains a model on your data to change its behaviour: a sector's vocabulary, a brand's tone, a precise output format. Light techniques such as LoRA make it affordable, but it remains the heaviest option, reserved for cases where the model's very style must change.
Memory is built on the application side: conversation history and user preferences are fed back into the context window at each exchange. The model retains nothing; the application does.
RAG (Retrieval-Augmented Generation) remains the royal road for knowledge: before answering, the system retrieves the relevant passages from your documents and grounds its answer in them. It is the architecture we describe in our article on RAG in business, and the one that eliminates most hallucinations.
Finally, you may or may not give the model access to the Internet, through a web search tool. It is in no way mandatory: the model already holds an immense body of knowledge acquired during training. Early ChatGPT users remember: in late 2022, the assistant warned that its knowledge stopped at September 2021, its cutoff date, because it was not connected to the Internet. Yet it could already discuss millennia of history, science and culture. Web access only serves to cover recent news; for a business chatbot, one often prefers to do without it and control the sources through RAG.
What this changes for an SME: no need to train your own model. A well-chosen open-weight model, a RAG over your documents and an application-side memory cover the vast majority of needs, for a fraction of the cost of proprietary development.
The right level of openness rather than the best model
Proprietary for simplicity, open-weight for sovereignty, open source for full auditability: each level of openness answers a need. Before comparing raw power, ask two very concrete questions: where is your data allowed to go, and how much are you willing to pay per request?
When it comes to artificial intelligence in business, technical sophistication never replaces strategic clarity.