"Artificial intelligence" now covers a dozen technical families that share neither the same strengths, nor the same costs, nor the same uses. Confusing them leads to expensive decisions: paying for a graphics card on a task that never needed one, or expecting from a generalist model what a classifier of a few megabytes would do better, for free.
This overview covers the families that handle text, then those that handle images, sound and video. When we have a number measured on our public benchmark, it is here; when we don't, we say so rather than borrowing someone else's.
This is the architecture behind everything you know as an LLM. Its strength is real and deserves to be stated before its limits: on our tool-calling benchmark, a 7-billion-parameter transformer, without any training on our part, scores 69 out of 82. That is better than our 2.9-billion RNN after training.
Its attention mechanism compares every word with all the others. That is what makes it good, and it is also what makes it expensive: the cost per generated word grows with the length of the conversation, because it keeps a cache of everything that came before. A long session costs more at the end than at the beginning, and that memory lives on the graphics card.
Bottom line: excellent everywhere, and increasingly costly as the conversation goes on.
A variant that has become standard for large models. The model holds many parameters but only activates a fraction of them for each word. The cloud model that serves as the reference on our benchmark advertises 30 billion parameters for about 3 billion actually active.
The economics benefit the provider, not the user: the whole model still has to be loaded into memory. This is not a family that makes local deployment more accessible.
An RNN reads text as it goes and maintains an internal state of fixed size that summarises everything it has read. There is no growing cache: the memory a session occupies does not depend on its length, and the cost per word stays constant from the first exchange to the last.
For a long time RNNs were clearly worse. That is no longer true. On our benchmark, a 2.9-billion-parameter RWKV first matched a 30-billion cloud model after $0.53 of training, then overtook it: the same recipe applied to the next generation of the same model scores 63 out of 82, against 58 for the cloud model. And the 7.2-billion version does better still in its production configuration.
The family is moving fast, and not only thanks to us. The generation released in August 2026 is the first where size measurably pays: raw, without any training on our part, it scores 29, 36, 43 then 52 out of 82 from the smallest to the largest of its four sizes, up to 13.3 billion parameters. Previous generations plateaued around 28-29 whatever the size. And the detail of the largest one says more than the total: 18 out of 23 on hard selection, untrained, the level our trained models reach.
But the same raw model scores 0 out of 17 on abstention, like every raw checkpoint of every size across four generations: not a single point in that category, ever. Size and pretraining buy selection skill; they do not buy the judgement of knowing when to do nothing. That is exactly what our few euros of training install, and the counter-test is clean: trained with our recipe, that same 13.3-billion model gains 18 points, 17 of which come from abstention alone. It is the behaviour that matters most in a business setting.
We also publish what does not flatter us: applied as-is to a transformer of comparable size, our recipe costs it 18 points. The family is not magic; it is the combination of architecture, method and size that produces the result.
Bottom line: quality now comparable at equal size, a structural property the transformer does not have, and a public generation that is improving fast.
An embedder produces no text. It turns a document into a list of numbers that captures its meaning, which makes it possible to find the relevant passages in a document base. It is the building block behind any search by meaning.
It is the most underestimated family, and the most profitable. On our benchmark, giving a large model a shortlist of 40 relevant tools instead of the full catalogue gains it thirteen cases out of 82. Improving the retrieval upstream often pays more than changing the model downstream, at a fraction of the cost. We fine-tuned ours for zero euros.
Bottom line: if your project is about querying your documents, this is where quality is decided, not in the choice of the model that writes.
A classifier puts an input into a category. Is this a factual question, a request for action, a greeting? It generates nothing, it routes. Some recent architectures, known as continuous-time models, are particularly compact.
Its value is in avoiding a call to a large model when none is needed. In a well-designed architecture, a classifier sends each request to the cheapest module that can handle it. Invisible to the user, decisive for the bill.
The families above deal with language. Three other domains have their own architectures, and they obey very different economics.
This is the architecture behind image generation. The principle is the inverse of a language model's: instead of writing word after word, the model starts from random noise and denoises it step by step until the image matches the request.
Two practical consequences. Producing one image takes dozens of successive passes, so a graphics card is effectively mandatory for interactive use. And the cost depends on resolution and step count, not on the length of a conversation: it is a rendering economy, not a dialogue economy.
Video generation belongs to the same family with one extra constraint, consistency between successive frames, and a cost that changes by an order of magnitude.
Bottom line: for a company this is almost always an occasional, creative use, not a process building block. It is not what enterprise AI is about, and we do not work on it.
Turning speech into text is probably the clearest case for local deployment today. Transcription models are compact, fast, and run all the way down to a browser without sending anything anywhere. That is what we do in our own assistant: dictation runs on the user's machine, with several quality tiers depending on the available hardware.
For a profession that handles confidential information, dictation is often the first building block to bring back in-house: it is the cheapest to host and one of the most sensitive, since people speak without a filter.
The reverse path, speech synthesis, is also mature locally, with a trade-off between voice naturalness and resources.
Detecting sound events, classifying them, separating sources: this is a family of its own, often built on small convolutional models. It is low-profile and very effective: typically models of a few megabytes, runnable on a modest processor.
It should not be confused with music generation, which follows a logic close to diffusion, costs included.
Recognising what is in an image, reading a scanned document, detecting an object: these are analysis tasks, not creation, and they rest on other, much lighter architectures. Automated document reading is in fact often the practical entry point of AI into a company, well before any conversational assistant.
Bottom line: do not confuse generating an image with understanding one. The second is far cheaper and far more useful day to day.
Some recent models accept several input types at once, text and images in particular. It is convenient, and it is also the domain where the gap between large remote models and what can be self-hosted remains the widest.
RAG is not a model, it is an architecture: you retrieve relevant excerpts, you hand them to the model, it answers based on them. The word names an assembly, not a technology.
Fine-tuning is not a family either, it is an operation. You start from an existing model and adjust it. It comes in very different degrees, from tuning a few million parameters to resuming full training, with costs ranging from under one euro to considerable sums.
An agent is a system that uses tools, not a type of model. Any family above can serve as its brain, and that is precisely what our benchmark measures.
What must the system produce? If it has to find and quote, the embedder and the retrieval matter more than the model. If it has to write and reason, the reverse.
Are the data allowed to leave? If not, the space narrows to models that run on your premises, and the constraint becomes available memory, not theoretical quality.
Will the conversation be long, and for how many users? That is where the constant memory of an RNN stops being a technical detail and becomes a cost factor, and it is the question that shapes our own architecture choice.
The guide to sovereign AI for SMEs covers the second question; for the first, our method and its measurements show what upstream retrieval changes in the result.
On a targeted, well-trained task, yes, and it is measured: parity, then an edge, over a model ten times its size on our benchmark. Across all generalist uses, no, and nobody serious claims otherwise.
Measure your own instead, and be wary of your own benchmark. We had concluded that a recent generation was worse than the previous one on our task: it was our prompt template penalising it. Re-evaluated in the format it had been trained on, it gains 9 points while the older one loses 3. A benchmark always measures the model and the way you ask it.
The one that runs on your premises, and the choice then comes down to available memory and the nature of the task rather than generalist leaderboards. That is what our services are about.
