LLM en local pour votre entreprise : que peut-on faire avec 60 k€ ?

Déployer une IA ouverte, en local, sur vos infrastructures, c'est la promesse d'une vraie souveraineté et d'une vraie maitrise : vos données restent chez vous, vous maîtrisez l'infrastructure, vous êtes indépendant des providers. Pour un projet d'IA d'entreprise (agent intelligent, RAG, assistant interne, etc.), l'option est séduisante (et parfois indispensable).

Mais les réflexions habituelles du 'Make or Buy' ou du 'Cloud ou On-Premise' sont très différentes dans le cadre de l'IA au vu du coût massif des infrastructures adaptées. Cet article vous donne quelques repères pour décider en connaissance de cause.

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 consiste à donner 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'une projet d'IA d'entreprise ;
• IA agentique : une IA qui ne se contente pas de répondre directement mais qui enchaîne des étapes (utiliser un outil, faire une recherche, 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 mais plusieurs modèles à déployer

Premier élément important : un projet IA en entreprise, dès qu'il devient un peu avancé, ne repose pas sur un seul modèle, mais sur plusieurs modèles qui tournent en parallèle :

• LLM principal : génération de texte, raisonnement complexe, dialogue ;
• Modèles légers ou spécialisés : tâches rapides et simples (routage, extraction, nommage) ;
• Modèle d'embeddings : indispensable pour la recherche sémantique (RAG) ;
• Modèle de vision : si vous analysez des images ou des captures d'écran ;
• Modèle de génération d'images : si votre use case le demande.

Bref, selon toute vraisemblance, vous commencerez avec 1 ou 2 modèles, et au fur et à mesure vous vous retrouverez avec 5 ou 6 modèles.

Les utilisateurs sont exigeants

Ils sont devenus impatients : habitués à des services 'grand public' comme ChatGPT qui leur délivrent des réponses quasi immédiates. La latence perçue devient un critère d'acceptation. Il est difficile de donner un seuil de référence, mais au-dessous de 100 tokens générés/seconde, cela risque d'être perçu comme lent. Pour peu que l'IA soit agentique et appelle plusieurs outils, et "raisonne", c'est plutôt 500 tokens/seconde, voire plus, qu'il faut viser, pour une réponse rapide.

Seuils de référence :

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

Les utilisateurs sont aussi habitués à avoir beaucoup de services additionnels. Par exemple, joindre des documents aux messages (ex. des PDF) et avoir un traitement immédiat. Les services cloud de LLM excellent dans ce domaine (Gemini, ChatGPT, etc.). En local, on peut le proposer en convertissant le document en images et en utilisant un modèle de vision, mais cela sera beaucoup plus lent et souvent limité (en termes de nombre de pages du document par exemple).

Les questions clés à se poser avant de décider

1) Quels sont vos cas d'usage réels ?

• Tâches simples (extraction, reformulation, nommage) ou complexes (raisonnement, synthèse multi-documents, chaînes d'outils) ?
• Volume de requêtes attendu (pic, moyenne, croissance).
• Niveau de raisonnement requis : une réponse factuelle suffit-elle, ou faut-il enchaîner des étapes de raisonnement ?
• Besoin en multi-tâches et appels d'outils (agents) ? Cela tire fortement vers des modèles plus gros (pour l'orchestrateur) et une vitesse d'inférence plus élevée.

2) Quelle qualité de réponse est acceptable ?

Sur les requêtes complexes, l'écart entre un modèle moyen ou grand est net : profondeur de raisonnement, nuance, cohérence. Pour un assistant interne ou un agent métier, cette différence peut faire accepter ou rejeter la solution par les utilisateurs.

À l'inverse, pour des use cases très ciblés (RAG simple, tâches répétitives bien définies), un modèle plus petit peut suffire avec une infrastructure bien plus légère.

3) Quelle est votre vision long terme ?

• Obsolescence du matériel : les GPU achetés aujourd'hui seront-ils adaptés aux modèles de demain (taille, formats, frameworks) ?
• Évolution des besoins : votre projet va-t-il se complexifier (plus d'outils, plus de raisonnement, plus d'utilisateurs) ?
• Flexibilité vs engagement : le local vous "engage" sur 3–5 ans ; un provider vous permet d'évoluer sans changer de parc matériel.

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 : ex. générer un nom de conversation, extraire un champ, reformuler une phrase ;
• Retrieval simple : recherche documentaire basique, RAG avec peu de raisonnement ;
• Use cases très orientés RAG avec requêtes factuelles et peu de chaînage logique ;
• Tâches avec fine-tuning spécifique sur un domaine étroit.

Des modèles autour de 20 milliards de paramètres (ex. mistral-small ou gpt-oss-20b) peuvent suffire pour ceci, si vous tolérez quelques hallucinations et le fait que le modèle "ne raisonnera pas". L'avantage : une infrastructure très légère, rendant le scénario Make accessible.

En résumé : si votre use case est bien délimité, orienté retrieval et peu gourmand en raisonnement, un modèle de cette taille devrait suffire, et l'investissement reste raisonnable.

En pratique : c'est rare, et cela ne sera qu'un pilote avant un projet plus global.

Quand les modèles moyens ou gros sont indispensables

Dès que la complexité monte, un modèle autour de 100 milliards de paramètres devient le minimum. gpt-oss-120b d'OpenAI est fréquemment déployé, en raison de la notoriété de son éditeur, mais aussi d'un bon niveau de performance pour sa taille.

Les modèles de plus de 300 milliards de paramètres (Mistral Large, GLM, DeepSeek, etc.) sont recommandés quand les usages incluent par exemple :

• Des requêtes complexes avec raisonnement approfondi ;
• Agents multi-tâches avec appels d'outils et enchaînements ;
• Analyse multi-documents avec synthèse nuancée et prise de décision ;
• Tâches nécessitant une compréhension fine du contexte et des implicites.

La différence de qualité se voit dès que la requête demande du vrai raisonnement ou de la complexité.

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.

Parlons argent

Scénario "Make" : déployer gpt-oss-120b en local

Restons sur un exemple avec un modèle de taille "moyenne" (120 milliards de paramètres), qui sera donc limité à des scénarios simples.

Prenons un déploiement réaliste avec 2× NVIDIA H100 (ordre de grandeur : ~60 k€ d'investissement direct). D'après le benchmark Clarifai, la vitesse d'inférence est de :

• ~200 tokens/s pour 1 utilisateur ;
• ~40 tokens/s pour 100 utilisateurs simultanés.

Pour un usage multi-tâches et agents, l'objectif de 500 tokens/s est loin d'être atteint : l'expérience utilisateur en pâtira, surtout en charge. Par ailleurs, un modèle de cette taille reste insuffisant pour les usages avancés et le raisonnement complexe : pour ceux-ci, il faut viser des modèles plus gros, ce qui alourdit encore l'infrastructure en local.

Scénario "Buy" : utiliser un fournisseur d'inférence

D'après la documentation Cerebras, les débits annoncés sur le même modèle sont de l'ordre de ~3 000 tokens/s. Chez ATG, nous observons plutôt 1 000 à 2 000 tokens/s, ce qui reste 5 à 50 fois plus rapide que la config locale ci-dessus.

Avec 60 k€ d'investissement, vous pouvez donc déployer une première brique de votre projet d'IA. Pas très rapide, pas très puissant, mais qui couvre toutefois quelques use cases peu complexes.

Calcul de seuil de rentabilité

Pour trancher entre Make et Buy, il faut :

1. Estimer le volume de tokens à traiter par an (pas évident);
2. Comparer le coût amorti du matériel (achat + électricité + maintenance + obsolescence) au coût API sur la même période ;
3. Intégrer l'obsolescence : le matériel perd de la valeur et peut devenir sous-dimensionné pour les prochains modèles ; les services API évoluent sans que vous ayez à renouveler le parc.

En fonction de votre volume et de la durée de vie attendue du projet, le Buy peut être plus économique, mais en pratique c'est rare.

Conclusion

Le local peut avoir du sens pour des cas d'usage bien délimités et peu exigeants en performance (RAG simple, tâches légères, souveraineté stricte) ou à l'atteinte d'un volume très conséquent. Pour un projet d'entreprise ambitieux (agents, RAG complexe, multi-tâches), le Buy gagne généralement en simplicité, en vitesse et en évolutivité.

Le local est avant tout un choix de conviction, tout à fait légitime, qu'il vaut mieux mettre en oeuvre une fois une certaine maturité atteinte quant à ses projets d'IA.

Notre recommandation chez Ask This Guy : commencez par un provider pour gagner en maturité, validez vos cas d'usage et vos volumes, puis évaluez le local uniquement si le volume et des exigences spécifiques (souveraineté, coût long terme) le justifient.

---

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.