← Toutes les pages modèles on-premise
Exécuter des petits et moyens LLM on-premise (4–80 Md)
● Mesuré + arithmétique — le segment où tout tient
Tous les usages n'exigent pas un cerveau de classe 200 Md. Assistants de code, tri, extraction, embeddings, chat client — le segment des modèles de trait va de 4 à 80 milliards de paramètres, et sur une unité à 128 Go de mémoire unifiée, il tient avec la place d'en exécuter plusieurs côte à côte.
Deux des entrées ci-dessous sont mesurées sur notre propre parc de production ; le reste relève de la même arithmétique que nous utilisons pour dimensionner les déploiements clients.
Capacité par classe de taille (une unité de 128 Go)
| Classe 7–9 Md (4 bits) | ~4–6 Go — des dizaines de gigaoctets de marge |
|---|---|
| Classe 24–35 Md (4 bits) | ~14–20 Go ; un planificateur de 35 Md à mélange d'experts occupe un créneau d'~20 Go dans la conception de notre propre parc |
| Classe 70–80 Md (4 bits) | Qwen3-Coder-Next (80 Md, ~3 Md actifs) — 45 Go mesurés sur notre parc, notre ouvrier de code en production |
| Mémoire de l'appareil | 128 Go unifiés (une unité) |
| Cohabitation typique | un modèle de code + un modèle de tri + des embeddings, ensemble sur UNE unité |
En 4 bits, les poids occupent environ un demi-gigaoctet par milliard de paramètres, plus le cache de contexte. Conséquence pratique : une seule unité est un serveur de bureau multi-modèles, pas un appareil mono-modèle.
Ce que ce segment sert bien
- Un assistant de code privé pour votre équipe d'ingénierie — votre code source ne quitte jamais vos murs.
- Des chaînes d'extraction, de classification et de synthèse documentaires.
- Le service d'embeddings et de recherche (RAG) à côté du modèle de génération.
- Chat interne et automatisation du service client, dans votre langue.
- Des modèles de tri et de routage toujours actifs, qui ne coûtent presque rien à garder résidents.
Ce que nous exploitons nous-mêmes
Qwen3-Coder-Next (80 milliards de paramètres, ~3 Md actifs, 45 Go quantifié — mesuré) est l'ouvrier de code de notre propre parc : il écrit et modifie du code pour nos produits chaque jour. Un modèle de classe 35 Md d'environ 20 Go occupe le créneau de planificateur compact dans l'un des modes d'exploitation de notre parc. Les deux chiffres viennent des registres de notre parc.
Limites honnêtes
- Le meilleur modèle exact par classe de taille change vite ; les classes de taille et leurs enveloppes mémoire, non. Nous arrêtons les modèles exacts pour votre cas dans l'évaluation, pas dans un texte marketing.
- Un petit modèle affiné bat souvent un grand modèle générique sur une tâche étroite — c'est précisément la raison d'être de notre LLM Factory, et nous vous dirons quand c'est votre cas.
Questions fréquentes
- Plusieurs modèles peuvent-ils partager une unité ?
- Oui — c'est ainsi que nous exploitons notre propre parc : un modèle de code d'~45 Go cohabite avec un planificateur d'~20 Go et des modèles utilitaires plus petits sur une seule unité de 128 Go, chacun avec sa réservation mémoire.
- Un petit modèle suffit-il à notre cas d'usage ?
- Souvent, oui — l'extraction, la classification, le routage et le chat ciblé exigent rarement un fleuron. Et quand votre charge a besoin d'un cerveau plus grand, la même unité fait tourner un modèle de classe 122 Md à la place. L'évaluation répond avec vos documents et vos volumes, pas avec un slogan.
- Ces modèles peuvent-ils être affinés sur nos données ?
- Oui — ce segment est le point idéal de l'affinage : l'entraînement reste abordable, et notre LLM Factory compare le modèle affiné aux meilleurs modèles du marché sur vos tâches avant tout engagement, puis le livre sur votre appareil.