Hébergement de modèle on premise : la taille du modèle compte moins que la qualité du pipeline
Un client m'a récemment sollicité pour héberger un LLM en interne, sur son propre datacenter, sans dépendance à une API externe. Le réflexe naturel est de commencer par la question du modèle et du GPU. Ça a été mon point de départ aussi. Ça n'aurait pas dû l'être.
Le besoin n'était pas exotique : isolation stricte des données par entité, aucune fuite vers un fournisseur cloud, un cas d'usage principalement documentaire — répondre à des questions à partir de documents internes, via RAG.
Le sizing GPU, un point de départ trompeur
Le dimensionnement GPU a occupé les premières semaines. Plusieurs scénarios comparés, d'une carte L40S unique à des configurations multi-H200, avant de converger vers un châssis prêt pour quatre GPU, peuplé au départ de deux cartes 96 Go, suffisant pour faire tourner un modèle mixture-of-experts d'environ 120 milliards de paramètres en qualité FP8.
En parallèle, le choix du modèle : un candidat MoE sous licence Apache 2.0 comme cible souveraine de phase 1, face à une famille de modèles denses, disponibles en plusieurs tailles, également Apache 2.0, et certifiés sur un référentiel de gouvernance IA reconnu. Deux logiques différentes : la puissance brute d'un côté, la conformité et la prévisibilité de l'autre.
Un modèle surdimensionné alimenté par un retrieval médiocre produit des réponses médiocres avec assurance.
Ce travail de sizing était nécessaire, mais il a masqué la vraie question pendant trop longtemps. Pour un cas d'usage RAG documentaire, la qualité de la réponse ne dépend pas d'abord de la taille du modèle. Elle dépend de ce qu'on lui donne à lire. À l'inverse, un modèle plus modeste, correctement alimenté, tient largement la route sur des questions documentaires bornées.
Ce qui fait vraiment la différence
La qualité des embeddings choisis pour la langue et le domaine du client. Un reranking qui filtre le bruit avant de présenter le contexte au modèle. Un chunking qui respecte la structure réelle du document plutôt que de découper à taille fixe. Et surtout l'isolation des données par entité dès la conception du pipeline, pas ajoutée après coup. Sur un projet multi-entités avec cloisonnement strict, cette dernière contrainte structure toute l'architecture de stockage et de requête, bien avant que la taille du modèle n'ait la moindre importance.
La leçon
Applicable à tout projet d'hébergement souverain : dimensionner le GPU et choisir le modèle sont des décisions réversibles — on peut changer de modèle plus tard sans tout casser. La qualité du pipeline de retrieval, elle, est structurante dès le départ. Investir le temps d'analyse là plutôt que sur un tableau comparatif de benchmarks de modèles change davantage le résultat final pour l'utilisateur.
Un projet d'IA souveraine en tête ?
RAG, hébergement on premise, cloisonnement des données — échangeons sur l'architecture.