Déployer un LLM en production : infrastructure, coûts et monitoring

Quand nous avons déployé notre premier LLM en production, la surprise n'est pas venue du modèle. Elle est venue de l'infrastructure. Le modèle fonctionnait très bien sur notre machine de développement. En production, avec 50 utilisateurs simultanés, la latence a explosé, la mémoire GPU a saturé, et le coût d'inférence s'est révélé 8 fois supérieur à notre estimation initiale.

Ce fossé entre la démo et la production est le piège classique du déploiement de LLM en entreprise. Les tutoriels montrent comment lancer un modèle en trois lignes de code. Ils ne disent pas comment le faire tourner de façon fiable, à un coût maîtrisé, pendant des mois, avec de vrais utilisateurs et des exigences de disponibilité.

Cet article est un retour d'expérience terrain sur la mise en production de LLM : l'infrastructure nécessaire, les coûts réels en 2026, les outils de serving, le monitoring post-déploiement et les contraintes de souveraineté RGPD. Pas de théorie abstraite, pas de tutoriel "Hello World" : ce que nous avons appris en déployant des modèles pour nos clients chez Tensoria.

Pourquoi déployer un LLM n'a rien à voir avec déployer une application classique

Si vous avez l'habitude de déployer des API web classiques, oubliez vos repères. Un LLM en production pose des contraintes radicalement différentes d'une application standard :

• GPU obligatoire : un modèle de 7 milliards de paramètres pèse entre 14 et 28 Go en mémoire selon la précision. Pas de CPU qui tienne pour des temps de réponse acceptables en interactif.
• Latence variable et élevée : une requête LLM prend entre 1 et 30 secondes selon la longueur de la réponse. C'est 100 à 1 000 fois plus lent qu'un endpoint REST classique.
• Consommation mémoire imprévisible : chaque requête consomme de la VRAM proportionnellement à la longueur du contexte. Deux utilisateurs avec des prompts longs peuvent saturer un GPU qui servait dix utilisateurs avec des prompts courts.
• Coût au token : vous ne payez pas un serveur à la requête mais au volume de texte généré. Un prompt mal optimisé peut multiplier votre facture par 5 sans que vous le remarquiez.
• Pas de scaling horizontal simple : ajouter un réplica signifie louer un GPU supplémentaire, pas un simple conteneur CPU à 20 euros par mois.

Chez un de nos clients, le passage de la démo au déploiement production a révélé que le coût d'inférence était 8x supérieur à l'estimation initiale. La raison : personne n'avait anticipé les pics de charge. Dix commerciaux qui lancent leurs requêtes en même temps à 9h du matin, ça sature un GPU A100 qui semblait surdimensionné sur le papier.

Les trois architectures de déploiement LLM

Avant de choisir un outil ou un provider, vous devez d'abord trancher entre trois architectures fondamentalement différentes. Le choix dépend de votre volume, de vos contraintes de confidentialité et de votre budget.

Architecture 1 : API propriétaire (OpenAI, Anthropic, Mistral)

Vous n'hébergez rien. Vous appelez l'API d'un fournisseur qui gère l'infrastructure pour vous. C'est le point d'entrée le plus simple et souvent le bon choix pour démarrer.

• Avantages : zéro gestion infrastructure, accès aux meilleurs modèles (GPT-4o, Claude Sonnet, Mistral Large), facturation à l'usage, mise à jour automatique des modèles.
• Limites : vos données transitent chez le fournisseur, coût élevé à fort volume, latence réseau ajoutée, dépendance à un tiers, pas de personnalisation du modèle.
• Cas d'usage idéal : prototypage rapide, volumes modérés (moins de 50 000 requêtes par mois), pas de contrainte RGPD stricte sur les données traitées.

Architecture 2 : modèle open source auto-hébergé

Vous déployez un modèle open source (Mistral, Llama, Qwen) sur votre propre infrastructure ou sur un GPU cloud. Vous contrôlez tout : le modèle, les données, la latence, les coûts.

• Avantages : maîtrise totale des données, coût fixe prévisible, possibilité de fine-tuning, pas de dépendance fournisseur, conformité RGPD native.
• Limites : compétences DevOps/MLOps nécessaires, investissement initial plus élevé, maintenance continue, performances parfois inférieures aux modèles propriétaires de dernière génération.
• Cas d'usage idéal : données sensibles, volumes élevés qui rentabilisent le GPU, besoin de fine-tuning, contrainte souveraineté.

Architecture 3 : approche hybride

C'est l'approche que nous recommandons le plus souvent chez Tensoria. Vous combinez un modèle open source hébergé pour les tâches à fort volume ou les données sensibles, et une API propriétaire pour les tâches complexes ou ponctuelles.

• Exemple concret : un assistant RAG interne qui utilise Mistral NeMo 12B en auto-hébergement pour les requêtes courantes (80 % du volume), et bascule sur Claude Sonnet via API pour les analyses complexes qui nécessitent un raisonnement avancé (20 % du volume).
• Résultat : coût divisé par 3 par rapport au tout-API, confidentialité préservée sur les données sensibles, et qualité maximale quand c'est nécessaire.

Stack technique : vLLM, TGI, Triton, Ollama

Une fois votre architecture choisie, il faut un outil pour servir le modèle, c'est-à-dire exposer le LLM en API avec des performances de production. Nous utilisons systématiquement vLLM pour le serving de modèles open source. La différence de throughput par rapport à une inférence HuggingFace classique est de l'ordre de 5x à 10x.

Voici un comparatif des quatre solutions les plus utilisées en 2026 :

vLLM : notre choix par défaut en production

vLLM est le moteur d'inférence que nous utilisons sur la majorité de nos déploiements. Son avantage décisif est le PagedAttention, un mécanisme qui gère la mémoire GPU comme un système d'exploitation gère la RAM : en pages dynamiques, sans fragmentation. Résultat : vous pouvez servir beaucoup plus de requêtes simultanées avec le même GPU.

En pratique, sur un modèle Mistral 7B quantifié en AWQ 4 bits, vLLM nous permet de servir 30 à 50 requêtes simultanées sur un seul A100 80 Go, contre 5 à 8 avec une inférence HuggingFace standard. Le déploiement se fait avec Docker et expose une API compatible OpenAI, ce qui permet de remplacer un appel API propriétaire par un appel au modèle auto-hébergé sans changer une ligne de code applicatif.

TGI : l'alternative HuggingFace

Text Generation Inference (TGI) de HuggingFace est la solution de serving la plus simple à déployer si vos modèles viennent du Hub HuggingFace. Son batching continu et la gestion du streaming sont natifs. En revanche, sur les benchmarks de throughput pur, vLLM conserve une avance de 20 à 40 % dans la plupart des configurations.

Ollama : pour le développement, pas pour la production

Ollama est fantastique pour le prototypage local. Une commande, le modèle tourne. Mais en production, l'absence de multi-GPU, les performances limitées en concurrence et le manque d'outils de monitoring en font un choix inadapté pour des charges réelles. Si vous cherchez un outil de développement, utilisez Ollama. Si vous déployez pour des utilisateurs, passez à vLLM ou TGI.

Choisir son infrastructure GPU

Le GPU est le poste de coût le plus important dans un déploiement LLM. Le choix du type de GPU, du provider et du mode de facturation conditionne directement votre budget mensuel.

Cloud public (AWS, GCP, Azure)

Les hyperscalers offrent une large gamme de GPU (A100, H100, L4, L40S) avec une disponibilité mondiale. Le problème : les prix sont élevés, la disponibilité GPU est souvent limitée (quotas), et vos données transitent sur des serveurs américains. Pour une PME française avec des données sensibles, c'est rarement le bon choix en premier recours.

Cloud souverain français (OVH, Scaleway)

C'est l'option que nous recommandons pour les clients avec des contraintes RGPD. Scaleway propose des instances GPU L4 et L40S hébergées en France, avec des tarifs compétitifs. OVHcloud offre des instances GPU AI en datacenter français avec une certification SecNumCloud en cours. Scaleway propose aussi des API Generative qui permettent d'appeler Mistral ou Llama via API sans gérer l'infrastructure, avec hébergement garanti en France.

On-premise : le serveur GPU au bureau

Pour les volumes très élevés ou les contraintes de confidentialité maximales, un serveur GPU dédié peut se justifier. Un serveur avec un GPU NVIDIA RTX 4090 (24 Go VRAM) coûte environ 3 000 à 5 000 euros et peut servir un modèle 7B quantifié pour un usage interne modéré. Pour des modèles plus gros ou des volumes importants, un serveur avec un ou deux A100 80 Go représente un investissement de 15 000 à 40 000 euros, amorti en 6 à 18 mois par rapport au cloud.

Les vrais coûts d'inférence LLM en 2026

Les chiffres qui circulent sont souvent obsolètes ou déconnectés des usages réels. Voici une table de coûts basée sur des déploiements que nous avons réalisés et des tarifs constatés en mars 2026.

Le point de bascule entre API et auto-hébergement se situe généralement autour de 5 000 à 10 000 requêtes par jour. En dessous, l'API est plus économique (pas de coût fixe GPU). Au-dessus, l'auto-hébergement devient rentable en quelques semaines, surtout si vous pouvez utiliser un modèle 7B quantifié qui couvre 80 % de vos besoins.

Quantization : réduire les coûts sans sacrifier la qualité

La quantization est la technique la plus directe pour réduire le coût d'un déploiement LLM. Le principe : au lieu de stocker chaque paramètre du modèle en 16 bits (FP16), on le compresse en 8 bits, 4 bits, voire moins. Résultat : le modèle occupe 2 à 4 fois moins de VRAM, tourne sur un GPU moins cher, et la perte de qualité est souvent imperceptible.

Les trois formats à connaître

• GPTQ : quantization post-entraînement en 4 bits, optimisée GPU. C'est le format historique, bien supporté par vLLM et TGI. Performances très proches du modèle original.
• AWQ (Activation-Aware Weight Quantization) : version améliorée de GPTQ qui préserve mieux les poids importants du modèle. En pratique, AWQ 4 bits est souvent indiscernable du modèle FP16 sur des tâches métier, et c'est notre format par défaut pour les déploiements vLLM.
• GGUF : format optimisé pour l'inférence CPU/GPU via llama.cpp et Ollama. Idéal pour le développement local ou les petits déploiements, mais moins performant que GPTQ/AWQ en throughput pur sur GPU.

Impact réel de la quantization

Sur un Mistral 7B, voici ce que nous observons en production :

• FP16 (pas de quantization) : 14 Go VRAM, ~40 tokens/s sur A100
• AWQ 4 bits : 4,5 Go VRAM, ~55 tokens/s sur A100 (le modèle est plus petit donc plus rapide)
• Perte de qualité mesurée : moins de 2 % sur les benchmarks généraux, imperceptible sur nos tâches métier (extraction, classification, rédaction structurée)

Autrement dit, la quantization AWQ 4 bits réduit la VRAM nécessaire de 70 %, augmente la vitesse d'inférence, et dégrade la qualité de moins de 2 %. C'est le meilleur rapport coût/qualité disponible en 2026 pour les modèles de 7 à 14 milliards de paramètres.

Pour les modèles plus gros (70B+), la quantization devient quasi indispensable. Un Llama 3 70B en FP16 nécessite 140 Go de VRAM (deux A100 80 Go). En AWQ 4 bits, il tient sur un seul A100 80 Go. La différence de coût GPU est de l'ordre de 50 %.

Monitoring et observabilité en production

C'est le sujet le plus négligé dans les déploiements LLM, et pourtant le plus critique pour la pérennité du système. Un LLM en production dérive silencieusement : la qualité des réponses peut se dégrader sans qu'aucune alerte ne se déclenche, parce qu'il n'y a pas de "crash" visible comme dans une application classique.

Les quatre piliers du monitoring LLM

1. Métriques d'infrastructure

• Utilisation GPU (%) et mémoire VRAM consommée
• Latence réseau et temps de file d'attente des requêtes
• Température GPU (un GPU qui throttle réduit vos performances de 30 %)
• Outils : Prometheus + Grafana, DCGM Exporter pour les métriques GPU NVIDIA

2. Métriques d'inférence

• Time to First Token (TTFT) : le temps avant que le premier token ne soit généré. Critique pour l'expérience utilisateur en streaming.
• Tokens par seconde (TPS) : le débit de génération. Un TPS qui chute signale une surcharge ou un problème mémoire.
• Latence P50, P95, P99 : la médiane ne suffit pas, surveillez les percentiles hauts pour détecter les requêtes qui traînent.
• Outils : métriques natives de vLLM exposées en Prometheus, custom middleware FastAPI.

3. Métriques de qualité

• Taux de réponses vides ou refusées
• Longueur moyenne des réponses (un effondrement signale souvent un problème)
• Score de pertinence via LLM-as-a-judge (un modèle évalue les réponses d'un autre)
• Feedback utilisateur (thumbs up/down) quand c'est possible
• Outils : LangSmith, Langfuse, custom logging

4. Métriques de coûts

• Coût par requête (tokens consommés x prix unitaire)
• Budget consommé vs budget alloué (alerte à 80 %)
• Coût par utilisateur ou par département
• Outils : dashboards custom, intégration billing provider

Scaling : gérer les pics de charge

Un LLM en production connaît des pics de charge prévisibles (début de journée, fin de mois) et imprévisibles (campagne marketing, incident client). L'auto-scaling GPU est un exercice très différent de l'auto-scaling CPU classique.

Le problème du cold start GPU

Démarrer un conteneur avec un modèle LLM prend 2 à 10 minutes : il faut charger le modèle en VRAM, ce qui représente plusieurs gigaoctets à transférer. C'est incompatible avec un auto-scaling réactif façon serverless. Deux stratégies pour contourner ce problème :

• Pré-provisionnement : garder une instance GPU de secours en veille, prête à absorber un pic. Coûte le prix du GPU en permanence, mais élimine le cold start.
• Scaling prédictif : analyser vos patterns de charge (9h-12h forte activité, 14h-17h pic modéré) et programmer le scaling en conséquence. Moins cher que le pré-provisionnement, mais nécessite quelques semaines de données.

Queue de requêtes et dégradation gracieuse

Quand le GPU sature, il ne faut pas rejeter les requêtes. Mettez en place une file d'attente (Redis, RabbitMQ) avec un timeout raisonnable (30 à 60 secondes) et un message clair à l'utilisateur ("Votre requête est en cours de traitement"). En cas de surcharge prolongée, basculez automatiquement les requêtes vers une API propriétaire (Mistral API, OpenAI) en fallback. Mieux vaut une réponse via API externe que pas de réponse du tout.

Cette architecture de fallback automatique est un pattern que nous déployons systématiquement. Le modèle auto-hébergé absorbe 95 % des requêtes en temps normal. Les 5 % de pics extrêmes sont reroutés vers l'API, ce qui évite de surdimensionner l'infrastructure pour des scénarios rares.

Souveraineté et RGPD : héberger son LLM en France

La question de la souveraineté n'est pas un luxe réglementaire : c'est une exigence concrète pour toute entreprise qui traite des données personnelles, des données clients sensibles ou des informations confidentielles via un LLM. Et le RGPD est clair : le transfert de données personnelles vers les États-Unis sans garanties adéquates pose un risque juridique réel depuis l'invalidation du Privacy Shield.

L'avantage du auto-hébergement souverain

Quand vous déployez un modèle open source (Mistral, Llama) sur un serveur hébergé en France, vos données ne quittent jamais le territoire français. Ni les prompts, ni les réponses, ni les données de contexte. C'est la garantie la plus forte que vous pouvez offrir à vos clients, à votre DPO et à la CNIL.

En pratique, voici les options que nous déployons pour nos clients :

• Scaleway GPU Instances (datacenter Paris) : instances L40S avec vLLM, idéal pour les modèles 7B à 14B.
• OVHcloud AI Training/Serving (datacenter Gravelines/Roubaix) : GPU A100 avec certification en cours SecNumCloud.
• On-premise : serveur GPU dans les locaux du client, pour les cas où même le cloud souverain n'est pas suffisant (données de santé, défense, recherche confidentielle).

Pour aller plus loin sur l'hébergement souverain et le RGPD, consultez notre article sur l'hébergement RGPD avec n8n qui détaille les mêmes enjeux appliqués aux workflows d'automatisation.

API Mistral : le compromis souverain

Si vous ne voulez pas gérer l'infrastructure vous-même mais avez besoin de souveraineté, les API Mistral hébergées en Europe sont un bon compromis. Mistral AI est une entreprise française, les données sont traitées dans des datacenters européens, et les modèles sont parmi les plus performants du marché. C'est souvent le chemin que nous recommandons aux PME qui n'ont pas d'équipe DevOps interne pour maintenir un déploiement auto-hébergé.

La stack de déploiement type : de zéro à la production

Voici l'architecture que nous déployons le plus souvent pour nos clients PME/ETI qui veulent un LLM en production :

1. Modèle : Mistral 7B ou NeMo 12B quantifié en AWQ 4 bits (couvre 80 % des cas d'usage métier).
2. Serving : vLLM dans un conteneur Docker, exposé en API compatible OpenAI.
3. Application : FastAPI en frontend API, avec gestion du contexte, du RAG et du streaming.
4. Infrastructure : instance GPU L40S ou A100 chez Scaleway ou OVH, avec Docker Compose.
5. Monitoring : Prometheus + Grafana pour l'infra, Langfuse pour la qualité, alerting Slack.
6. Fallback : bascule automatique vers API Mistral en cas de surcharge GPU.

Cette stack est opérationnelle en 2 à 4 semaines pour un cas d'usage bien défini. Elle coûte entre 800 et 2 500 euros par mois en infrastructure, hors coût de développement initial. Si vous partez d'un projet IA déjà cadré, consultez notre guide pour lancer un projet IA en entreprise pour les étapes en amont.

Retour d'expérience Tensoria : ce que la production nous a appris

Après plusieurs dizaines de déploiements LLM pour nos clients, voici les leçons les plus importantes que nous avons tirées du terrain :

Leçon 1 : le modèle le plus gros n'est presque jamais la bonne réponse

L'instinct naturel est de vouloir le modèle le plus puissant disponible. En pratique, un Mistral 7B quantifié en AWQ et bien prompté couvre 80 % des cas d'usage métier que nous rencontrons (extraction de données, classification, rédaction structurée, Q&A sur documents). Les modèles 70B+ se justifient pour du raisonnement complexe multi-étapes ou de la génération créative longue. Pour le reste, un modèle plus petit signifie un GPU moins cher, une latence plus faible, et un système plus facile à maintenir.

Leçon 2 : l'optimisation des prompts vaut plus que l'optimisation du modèle

Nous avons vu des clients qui voulaient passer d'un modèle 7B à un 70B pour améliorer la qualité des réponses. Dans la majorité des cas, une refonte des prompts (instructions plus précises, exemples few-shot, structuration de la sortie) a produit le même gain de qualité sans changer de modèle ni augmenter le coût d'infrastructure.

Leçon 3 : le monitoring n'est pas optionnel, c'est vital

Sur un déploiement pour un éditeur de logiciel médical, nous avons détecté via notre monitoring que le taux de réponses pertinentes avait chuté de 12 % en trois semaines, sans qu'aucun utilisateur ne remonte le problème. La cause : un changement dans le format des documents source qui perturbait le pipeline RAG. Sans monitoring, ce drift serait passé inaperçu pendant des mois.

Leçon 4 : prévoyez le coût humain, pas seulement le coût GPU

Un LLM en production nécessite une maintenance continue : mise à jour des modèles, ajustement des prompts, analyse des logs, réponse aux incidents. Comptez 1 à 2 jours par mois d'intervention technique pour un déploiement standard. C'est un coût qu'il faut budgéter dès le départ, pas découvrir après la mise en production.

Questions fréquentes sur le déploiement LLM en production

Pour aller plus loin

• Notre service d'expertise LLM et NLP : du cadrage au déploiement production, en passant par le fine-tuning et le monitoring.
• Si votre LLM doit accéder à vos données internes, consultez notre guide sur le RAG et les bonnes pratiques pour optimiser un système RAG.
• Pour savoir si un fine-tuning est pertinent pour votre cas d'usage, lisez Fine-tuning LLM en PME : quand ça vaut le coup.
• Pour un cadrage budgétaire global, consultez le guide budget IA pour PME.
• Sur l'hébergement souverain et le RGPD, notre article n8n et hébergement RGPD couvre les mêmes enjeux appliqués aux automatisations.
• Documentation officielle vLLM : la référence technique pour le serving haute performance.
• RAG vs fine-tuning : comment choisir : déterminer la bonne architecture avant de choisir votre infrastructure.
• Évaluer un LLM en entreprise : métriques, golden dataset et monitoring qualité.
• Embeddings et recherche sémantique : comprendre les fondations techniques du RAG.
• Prompt engineering avancé : optimiser les résultats avant de toucher à l'infrastructure.
• Fine-tuner Mistral sur vos données métier : adapter un modèle Mistral avant de le déployer en production.
• RAG souverain avec Mistral : déployer une architecture RAG complète, 100% hébergée en France.
• Mistral Forge pour les PME : fine-tuner et déployer sans gérer l'infrastructure GPU.

En résumé : déployer un LLM en production, c'est un projet d'infrastructure autant que d'IA

Le modèle n'est que la partie visible de l'iceberg. Ce qui fait la différence entre un prototype qui impressionne en démo et un système qui tourne de façon fiable en production, c'est tout ce qu'il y a autour : le choix du GPU, l'outil de serving, la quantization, le monitoring, le scaling et la gestion des coûts.

Les décisions clés à prendre avant de se lancer :

• API, auto-hébergement ou hybride ? En fonction de votre volume, de vos contraintes de confidentialité et de votre budget.
• Quel modèle et quelle quantization ? Le plus petit modèle qui couvre votre besoin, quantifié au maximum sans perte de qualité perceptible.
• Quel monitoring ? Infrastructure, inférence, qualité et coûts : les quatre piliers à couvrir dès le premier jour.
• Quelle stratégie de scaling ? Pré-provisionnement, scaling prédictif ou fallback API : choisissez en fonction de vos patterns de charge.

Si vous envisagez de mettre un LLM en production, commencez par un audit IA pour cadrer le besoin, dimensionner l'infrastructure et estimer le budget réel. Chez Tensoria, c'est la première étape de chaque projet de déploiement LLM que nous accompagnons.