LLM et RAG on premise en entreprise : ce que 60 k€ permettent vraiment

Un LLM on premise est un modèle de langage qui tourne sur du matériel que l'entreprise possède ou contrôle, dans son propre réseau, sans API tierce sur le chemin des données. Concrètement, il s'agit de télécharger un modèle open weight, de le servir sur vos GPU et d'y brancher vos applications.

La promesse, c'est la maîtrise : vos données restent chez vous, et vous ne dépendez plus d'un fournisseur. Pour un projet d'IA d'entreprise (agents, RAG, assistants internes), l'option est séduisante, parfois indispensable.

Mais l'infrastructure IA coûte cher, et les réflexions habituelles du « Make or Buy » fonctionnent ici autrement. Cet article donne les chiffres d'octobre 2026 pour décider en connaissance de cause : ce que coûte le matériel, quels modèles y tiennent, le coût annuel complet et surtout le seuil de rentabilité face au même modèle servi en API. Pour le panorama complet des options, de l'achat de GPU au fournisseur clé en main, voir notre guide sur l'inférence IA en entreprise.

RAG on premise : ce que l'on confond souvent

Beaucoup d'équipes formulent le besoin sous l'angle RAG on premise (ou RAG on-prem) : un assistant qui répond depuis vos documents, hébergé chez vous. Un RAG on premise ne signifie pas forcément « tout reconstruire et héberger soi-même le LLM ». Trois couches se séparent :

1. Les données et le retrieval : documents, droits d'accès, index, citations. C'est le cœur métier du RAG.
2. La plateforme : connecteurs, ingestion, évaluation, monitoring. C'est ce qui coûte le plus à industrialiser.
3. L'inférence LLM : le modèle qui génère la réponse (cloud souverain, fournisseur européen, ou GPU on-prem).

Beaucoup de projets « on-prem » échouent parce qu'ils attaquent d'abord le point 3 (acheter des H100) alors que le vrai délai et le vrai TCO sont sur les points 1 et 2. Une solution RAG entreprise clé en main peut déjà tourner en hébergement européen, avec option on-premise selon vos contraintes, sans que vous ayez à dimensionner seuls la stack GPU.

Quelques définitions pour lire la suite sereinement

• LLM (Large Language Model) : le « cerveau » du système. C'est ce que vous allez déployer sur votre serveur.
• Nombre de paramètres : une mesure de la « taille » du modèle. Plus ce chiffre est élevé, plus le modèle est capable de raisonnements fins (et plus il demande de puissance de calcul et de mémoire).
• Inférence : le moment où le modèle répond à votre requête. On ne parle pas ici de l'entraînement (qui a déjà eu lieu), mais du simple fait de lui poser une question et d'obtenir une réponse.
• Token : une petite unité de texte (un mot ou un bout de mot). Quand on dit « 100 tokens par seconde », cela signifie que le modèle produit environ 100 de ces unités chaque seconde : plus ce nombre est élevé, plus la réponse arrive vite.
• RAG (Retrieval-Augmented Generation) : une technique qui donne au modèle l'accès à vos documents (PDF, wiki internes, etc.) pour qu'il réponde en s'appuyant sur vos données plutôt que sur sa seule mémoire. Souvent l'élément déclencheur d'un projet d'IA d'entreprise.
• IA agentique : une IA qui ne se contente pas de répondre une fois ; elle enchaîne des étapes (utiliser un outil, chercher, raisonner, réessayer) pour accomplir une tâche complexe, comme un assistant qui prend des initiatives.

IA agentique : enchaînement d'étapes et appels d'outils

Pas un modèle, mais toute une pile à faire tourner

Un projet IA d'entreprise, dès qu'il devient un peu avancé, ne repose pas sur un modèle mais sur plusieurs modèles qui tournent en parallèle : un LLM principal, des modèles légers pour les tâches simples (routage, extraction, nommage), un modèle d'embeddings pour la recherche sémantique, un modèle de vision si vous analysez des images ou des PDF scannés. Vous commencerez probablement avec 1 ou 2 modèles, et finirez avec 5 ou 6.

Autour de ces modèles, un RAG on premise qui fonctionne « comme un service cloud » compte au moins sept briques à exploiter :

À quoi s'ajoute le contrôle d'accès par document : chaque extrait porte les droits de son document source (SharePoint, GED), et la recherche filtre dessus avant que quoi que ce soit n'atteigne le LLM. C'est ce qui sépare la démo Ollama du service en production, et c'est ce que l'on sous-estime le plus souvent.

Côté moteur, l'écart entre un outil de poste de travail et un serveur n'a rien de marginal : dans un benchmark Red Hat, vLLM monte à 793 tokens/s contre 41 pour Ollama en charge, sur le même GPU et le même modèle.

Quels modèles open weight faire tourner on premise en 2026 ?

Le modèle fixe le matériel. Voici les principaux modèles open weight qu'une entreprise peut déployer en octobre 2026, avec la taille de leurs poids sur Hugging Face :

Deux points à garder en tête :

• Claude, GPT-5 et les derniers modèles Gemini ne se téléchargent pas. On ne peut les utiliser que dans le cloud de leur éditeur ou d'un hyperscaler. Les modèles open weight d'OpenAI (gpt-oss), eux, s'installent librement.
• Les modèles ouverts qui rivalisent avec les meilleurs modèles fermés (300 milliards à plus de mille milliards de paramètres) demandent au minimum un serveur 8 GPU. Le palier « 60 k€ » donne accès à la classe gpt-oss-120b, pas au-delà.

Quand les « petits » modèles suffisent

Quand les petits modèles suffisent

Plusieurs cas d'usage se contentent de modèles légers : tâches simples et précises (nommer une conversation, extraire un champ, reformuler une phrase), retrieval simple, RAG avec des requêtes factuelles et peu de chaînage logique, tâches avec fine-tuning sur un domaine étroit.

Des modèles de 20 à 30 milliards de paramètres (gpt-oss-20b, Mistral Small 3.2, Gemma 4) peuvent suffire, si vous tolérez quelques hallucinations et le fait que le modèle « raisonnera » peu. L'avantage : une infrastructure légère, qui rend le scénario Make accessible.

En pratique : ce scénario est rare, et ne sert le plus souvent que de pilote avant un projet plus global.

Quand les modèles moyens ou gros sont indispensables

Dès que la complexité monte, un modèle d'environ 100 milliards de paramètres devient le minimum. gpt-oss-120b est fréquemment déployé, pour la notoriété de son éditeur comme pour son bon niveau de performance à cette taille. Les modèles plus gros (Mistral Large 3, DeepSeek, GLM, etc.) sont recommandés pour les requêtes complexes avec raisonnement approfondi, les agents multi-étapes avec appels d'outils, l'analyse multi-documents et les tâches qui exigent une compréhension fine du contexte.

En résumé : dès que vous visez des agents évolués, du RAG avancé ou du raisonnement métier exigeant, les gros modèles deviennent difficiles à remplacer sans dégrader fortement l'expérience.

Quelle mémoire GPU faut-il ?

Selon NVIDIA, la règle tient en une ligne : mémoire = poids du modèle + KV cache + une marge. Les poids dépendent du nombre de paramètres et de leur format (2 octets en BF16, 1 en FP8, environ 0,5 en 4 bits). Le KV cache est la mémoire de travail du modèle pour chaque conversation : il grossit avec la longueur du contexte et le nombre d'utilisateurs simultanés.

Exemple chiffré avec gpt-oss-120b (calcul à partir de sa configuration publiée), pour 32 utilisateurs en même temps, chacun avec 32 000 tokens de contexte (un RAG courant) :

OpenAI a raison de dire que le modèle « tient dans un seul GPU de 80 Go ». Mais sur un H100 de 80 Go, il reste environ 10 Go pour le KV cache, soit à peu près 7 longues conversations à la fois. Pour une trentaine d'utilisateurs en RAG, il faut deux H100, ou un GPU de 141 Go (H200) ou plus.

Les utilisateurs sont exigeants : vitesse par utilisateur contre débit total

Les utilisateurs sont devenus impatients, habitués à des services grand public comme ChatGPT qui répondent quasi instantanément. La vitesse décide souvent de l'adoption ou du rejet de l'outil. En dessous de 100 tokens générés par seconde, cela risque d'être perçu comme lent. Si l'IA est agentique, appelle plusieurs outils et « raisonne », c'est plutôt 500 tokens/seconde ou plus qu'il faut viser.

Seuils de référence :

• ~500 tokens/s : projets multi-étapes, appels d'outils, raisonnement, agents complexes.
• ~100 tokens/s : tâches simples sans réflexion (chat basique, complétion).

Un serveur on premise a deux limites qu'on ne peut pas maximiser en même temps : la vitesse ressentie par chaque utilisateur, et le volume total qu'il produit. Les benchmarks publiés le montrent :

• Sur 2× RTX PRO 6000, d'après les mesures de Millstone AI, gpt-oss-120b passe de 230 tokens/s pour un utilisateur seul avec un contexte court à 14,5 tokens/s par utilisateur avec 6 utilisateurs et des contextes longs. L'attente avant le premier mot passe de 50 ms à 18 secondes à 128 000 tokens de contexte.
• Sur 2× H100 réglés pour le débit maximal, d'après les tests de performance de GPUStack, le même modèle atteint 16 042 tokens/s au total (entrée et sortie, dont 7 649 en sortie), mais chaque utilisateur reçoit alors environ 12 tokens/s, après 4,6 secondes d'attente.

Les « 16 000 tokens/s » des plaquettes commerciales, ce sont des utilisateurs servis à 12 tokens/s. Les « 200 tokens/s », c'est un utilisateur seul.

Pour comparaison, Cerebras annonce environ 3 000 tokens/s sur le même modèle. Chez ATG, nous observons 1 000 à 2 000 tokens/s : 4 à 13 fois plus rapide que le serveur on premise avec un seul utilisateur, et bien davantage en charge.

Les utilisateurs sont aussi habitués à beaucoup de services additionnels, comme joindre un PDF à un message et le voir traité immédiatement. Les services cloud excellent dans ce domaine. En local, on peut le proposer en convertissant le document en images pour un modèle de vision, mais ce sera plus lent et souvent limité (en nombre de pages, par exemple).

Prix du matériel en 2026 : le H100 a disparu, la mémoire flambe

L'ordre de grandeur « 2× H100 ≈ 60 k€ » tient toujours pour les cartes seules, mais le paysage a changé :

• Le H100 n'est plus vendu neuf. D'après le revendeur nelpx, la dernière livraison distributeur de la H100 NVL date du 15 juin 2026 ; d'autres revendeurs, comme Prostor, l'affichent encore autour de 28 446 € HT la carte. Sa remplaçante naturelle, la H200 NVL (141 Go), coûte le même prix : à partir de 26 500 € HT, avec 50 % de mémoire en plus.
• La carte « abordable » a doublé de prix. Selon Tom's Hardware, la RTX PRO 6000 de NVIDIA (96 Go) est passée de 8 565 $ en mars 2025 à 16 000 $ en août 2026, sous l'effet de la pénurie de mémoire : selon TrendForce, la DRAM serveur a pris 13 à 18 % en un seul trimestre au T3 2026.
• Un serveur complet coûte plus que ses cartes. Châssis, processeurs, RAM, stockage et réseau : comptez 70 000 à 90 000 € HT pour un serveur 2 GPU (notre estimation). Pour repère, un serveur 3× RTX PRO 6000 est affiché à 89 562 € HT chez LDLC Pro, un Lenovo 2× RTX PRO 6000 à 68 011 $ selon Lenovo Press.
• L'obsolescence se mesure. Selon le banc d'essai InferenceX de SemiAnalysis, à vitesse par utilisateur égale, un B200 produit 5 fois plus de tokens qu'un H100 sur gpt-oss-120b. Les GPU achetés aujourd'hui auront deux générations de retard avant d'être amortis.

La location est l'autre point de repère. Un H100 coûte 2,80 € de l'heure chez OVHcloud et 2,87 € chez Scaleway, contre 6,88 $ chez AWS et 12,29 $ chez Azure, selon le comparateur Vantage. Deux H100 loués en continu chez OVHcloud reviennent à environ 49 000 € par an : un serveur 2 GPU coûte l'équivalent d'un an et demi de location continue, avant énergie, hébergement, maintenance et personnel.

Coût total de possession : le prix d'achat n'est qu'une ligne

Notre estimation pour un serveur 2 GPU acheté 80 000 € HT, dimensionné pour gpt-oss-120b. Hypothèses : 1,8 kW de consommation, efficacité du data center (PUE) de 1,42 en moyenne en France selon l'Arcep, électricité à 0,20 € le kWh (PME françaises, 2026), colocation de 100 à 150 € par kW et par mois, maintenance de 10 à 12 % par an, ingénieur LLMOps à 120 000 € par an chargé (environ 85 000 € brut). La licence NVIDIA AI Enterprise (4 500 $ par GPU et par an) est incluse pendant cinq ans avec les cartes H100 NVL et H200 NVL.

L'électricité n'est pas le sujet : 4 à 14 % du total. Le personnel et l'amortissement font 77 à 83 % du coût dans les scénarios médian et haut. Et ce tableau n'inclut ni le reste de la pile RAG, ni une seconde machine pour la redondance, ni les coûts de projet (intégration, sécurité, tests).

Seuil de rentabilité : on premise contre le même modèle en API

La comparaison honnête se fait avec le même modèle servi en API, pas avec un modèle fermé plus capable. gpt-oss-120b coûte 0,15 € par million de tokens en entrée et 0,60 € en sortie chez Scaleway, fournisseur français. Pour un RAG (environ 8 tokens d'entrée pour 1 de sortie), cela fait 0,20 € par million de tokens en moyenne.

Côté capacité, à 100 tokens/s par utilisateur, un H100 produit au mieux 5 863 tokens/s sur ce modèle selon InferenceX (mesuré sur des nœuds très optimisés, hypothèse favorable à l'on premise). Un serveur 2 GPU délivre donc au maximum 370 milliards de tokens par an en continu, et 93 milliards en heures ouvrées.

Comment le lire :

1. À modèle égal, le serveur ne bat l'API que s'il tourne jour et nuit, à plus de 44 % de sa capacité sans compter le personnel, 88 % avec un quart de temps d'ingénieur. Saturé de 8 h à 18 h et vide la nuit, il produit l'équivalent de 18 600 € d'API par an : moins que son seul amortissement.
2. En utilisateurs, le seuil médian représente environ 11 000 utilisateurs intensifs d'un assistant RAG (20 requêtes par jour). Le serveur, saturé en heures ouvrées, en sert au mieux environ 3 250.
3. Le seuil ne devient atteignable qu'avec des traitements de masse en tâche de fond (classer ou extraire des documents, indexer, agents en batch) qui remplissent les nuits et les week-ends.
4. Pourquoi d'autres analyses trouvent « 9 à 18 mois » : elles comparent à une API fermée. Face à un modèle de classe GPT-5, environ dix fois plus cher, le seuil médian tombe à 34 milliards de tokens par an. Mais on compare alors deux modèles de qualité différente. Les études publiées comptent soit l'électricité seule, soit la location de GPU à la demande chez un hyperscaler américain.

Et le seuil bouge dans le mauvais sens pour l'on premise : le prix de l'inférence à performance égale baisse d'environ 10 fois par an, alors que le matériel acheté reste à son coût de 2026.

En résumé : sur le seul coût, à modèle égal, le Buy l'emporte dans presque tous les usages interactifs. L'on premise devient rentable avec d'énormes volumes traités en continu, ou quand une autre contrainte que le coût l'impose.

Cinq options entre « tout on premise » et « API publique »

Le choix n'est pas binaire. De la plus contrôlée à la plus déléguée :

L'option 3 est la comparaison la plus honnête avec l'achat : même logiciel, même modèle, même isolation, mais sans investissement ni obsolescence. Deux H100 dédiés chez Scaleway coûtent environ 58 500 € par an en continu, ou environ 14 700 € si vous ne les utilisez qu'en heures ouvrées.

Souveraineté : ce que l'on premise règle, et ce qu'il ne règle pas

L'on premise garantit que vous seul accédez aux données en clair. Mais la souveraineté n'exige pas l'on premise : un modèle open weight servi par un fournisseur européen contrôlé depuis l'EEE offre la même protection juridique, sans investissement matériel. Notre règle est stricte : un fournisseur dont la maison-mère est hors de l'EEE échoue au critère de souveraineté, même avec une filiale européenne et des data centers en Europe, parce que le CLOUD Act s'applique quel que soit le lieu de stockage.

À l'inverse, un modèle open weight hébergé chez soi ne « téléphone » pas à son éditeur : la nationalité de celui-ci (OpenAI pour gpt-oss, Alibaba pour Qwen, DeepSeek) n'expose pas vos données. Elle pèse sur la continuité (pas de mise à jour garantie) et sur les biais du modèle.

L'on premise reste justifié pour les systèmes déconnectés d'internet (défense, secret industriel), les contraintes contractuelles d'un client, ou une politique qui interdit toute sous-traitance. C'est l'illusion à laquelle renvoie le titre de cet article : croire que seul l'on premise est souverain.

Checklist de décision

L'on premise mérite d'être étudié si vous cochez la plupart de ces cases :

• une obligation de fonctionner déconnecté d'internet, ou un contrat qui interdit tout hébergeur tiers ;
• un volume qui remplit la machine jour et nuit, grâce à des traitements de masse, pas seulement du chat en heures ouvrées ;
• une équipe capable d'exploiter des GPU, un moteur d'inférence et une pile RAG, avec au moins deux personnes pour la continuité ;
• des cas d'usage qu'un modèle de la classe 120 milliards de paramètres traite bien, ou un budget pour un serveur 8 GPU ;
• un budget de 70 à 90 k€ à l'achat, plus 30 à 70 k€ par an pour l'exploitation ;
• des cas d'usage et des volumes déjà validés chez un fournisseur.

Si vous en cochez moins de trois, commencez par un fournisseur européen.

Questions fréquentes sur les LLM on premise

Qu'est-ce qu'un LLM on premise ?

C'est un modèle de langage qui tourne sur du matériel que l'entreprise possède ou contrôle, dans son propre réseau, sans API tierce sur le chemin des données. En pratique, il s'agit d'un modèle open weight (gpt-oss, Mistral, Gemma, Qwen, DeepSeek) servi par un moteur d'inférence comme vLLM sur les GPU de l'entreprise, dans son data center ou en colocation.

Combien coûte un LLM on premise ?

Pour un modèle comme gpt-oss-120b, comptez environ 60 000 € pour deux GPU et 70 000 à 90 000 € HT pour le serveur complet. L'exploitation coûte de 32 000 à 104 000 € par an selon le temps de personnel qui y est consacré, l'amortissement et le personnel pesant bien plus que l'électricité.

À partir de quel volume un LLM on premise est-il moins cher qu'une API ?

À modèle égal, un serveur 2 GPU pour gpt-oss-120b bat le prix API d'un fournisseur européen au-delà de 160 à 520 milliards de tokens par an, ce qui suppose de tourner à 44 à 88 % de sa capacité jour et nuit. Un usage interactif en heures ouvrées n'y arrive jamais ; des traitements de masse en tâche de fond, si.

Quelle mémoire GPU faut-il pour un LLM ?

Additionnez les poids du modèle (paramètres × octets par paramètre), le KV cache (qui grossit avec la longueur du contexte et le nombre d'utilisateurs simultanés) et une marge de sécurité. gpt-oss-120b pèse 65 Go, mais servir 32 utilisateurs avec 32 000 tokens de contexte chacun demande environ 104 Go, soit deux GPU de 80 Go.

Faut-il utiliser vLLM ou Ollama en production ?

Ollama est conçu pour un poste de travail : il traite une requête à la fois par défaut. Pour un service partagé par plusieurs utilisateurs, il faut un moteur comme vLLM ou SGLang, qui regroupe les requêtes et délivre un débit bien supérieur sur le même GPU.

Que faut-il pour un RAG on premise ?

En plus du LLM : un modèle d'embeddings, un reranker, un outil de parsing et d'OCR pour les documents, une base vectorielle, une passerelle avec authentification et quotas, de l'observabilité, et un contrôle d'accès par document pour que chaque utilisateur ne retrouve que ce qu'il a le droit de lire. Cela fait au moins sept briques à exploiter.

Faut-il de l'on premise pour être conforme au RGPD ou souverain ?

Non. Un fournisseur contrôlé depuis l'Espace économique européen, qui sert des modèles open weight en Europe, offre la même protection juridique sans achat de matériel. L'on premise reste utile quand les systèmes doivent être déconnectés d'internet ou qu'un contrat interdit tout hébergeur tiers.

Peut-on installer Claude, GPT-5 ou Gemini on premise ?

Pas Claude ni GPT-5 : leurs poids ne sont pas téléchargeables, et ils ne sont disponibles que dans le cloud de leur éditeur ou d'un hyperscaler. Gemini existe sur Google Distributed Cloud, y compris en mode déconnecté, mais l'éditeur reste américain. Les modèles open weight d'OpenAI, gpt-oss-20b et gpt-oss-120b, s'installent librement.

Un LLM local vaut-il ChatGPT ?

Pas à budget matériel égal. Les modèles ouverts de la classe 120 milliards de paramètres, qui tournent sur un serveur 2 GPU, restent en retrait des meilleurs modèles fermés sur le raisonnement complexe. Les modèles ouverts qui s'en rapprochent (300 milliards à plus de mille milliards de paramètres) demandent au minimum un serveur 8 GPU.

---

Conclusion

L'on premise a du sens pour des cas d'usage bien délimités avec des contraintes strictes (systèmes déconnectés, obligations contractuelles) ou avec de très gros volumes traités en continu. Pour un projet d'entreprise ambitieux (agents, RAG complexe, raisonnement), le Buy l'emporte généralement en vitesse, en simplicité et, à modèle égal, en coût.

L'on premise est souvent un choix de conviction, tout à fait légitime. Mais il est plus simple à mettre en œuvre une fois que l'on sait ce dont son projet a vraiment besoin.

Notre recommandation chez Ask This Guy : commencez par un fournisseur européen pour gagner en maturité et valider vos cas d'usage et vos volumes, puis évaluez l'on premise uniquement si le volume et des exigences spécifiques le justifient. Si votre priorité est un RAG on premise opérationnel sans reconstruire toute la stack, regardez d'abord notre solution RAG entreprise (hébergement européen, option on-prem).

Et si votre motivation première est la souveraineté plutôt que le coût, commencez par lire ce que ce mot recouvre exactement : IA souveraine, définition et critères. Héberger le modèle chez vous n'est qu'une des trois couches en jeu, et rarement la plus urgente.

Pour monter en compétence sur l'IA

Arbitrer entre local et fournisseur d'inférence, dimensionner ses GPU, maîtriser le coût d'un modèle en production : ces arbitrages s'apprennent. Pour les professionnels qui veulent se former au MLOps et au LLMOps, Jedha propose un parcours de 150 heures dédié à l'industrialisation de l'IA : infrastructure distribuée (GPU, Kubernetes), gouvernance des données, conformité RGPD et AI Act, et maîtrise des coûts. C'est à ce jour la seule formation en France à couvrir les deux à la fois. Elle s'adresse à des profils ayant déjà deux ans d'expérience en data ou en IA.

---

Vous voulez déployer un assistant IA performant sans gérer l'infrastructure ? Réservez une démo de 20 minutes, on vous montre comment.