Inférence auto-hébergée ou hébergée : vLLM, TGI et calcul du seuil de rentabilité

L’argument est séduisant. Les modèles open source sont compétitifs. Les GPU sont disponibles. Les serveurs d’inférence comme vLLM, TGI et SGLang sont matures. Pourquoi payer cinq à dix fois plus cher auprès d’OpenAI ou d’Anthropic alors que vous pourriez héberger vous-même un modèle équivalent ?

La réalité est plus complexe. L’auto-hébergement est réellement avantageux à certaines échelles. Dans d’autres cas, son coût opérationnel dépasse largement les économies d’inférence. Le seuil de rentabilité varie selon la charge de travail, la taille du modèle, les exigences de latence et les compétences de l’équipe.

Cet article examine en détail les calculs, les contraintes opérationnelles et les critères qui distinguent les équipes qui devraient auto-héberger leurs modèles de celles qui ne le devraient pas. Nous partons du principe que vous envisagez sérieusement cette option et souhaitez disposer de chiffres réalistes.

Lorsque l’auto-hébergement est pertinent

Certaines caractéristiques favorisent l’auto-hébergement :

Échelle. Volume d’inférence élevé. Plus précisément, des dépenses mensuelles d’inférence par API supérieures à 5 000-10 000 € justifient généralement d’envisager l’auto-hébergement.

Charge de travail prévisible. Utilisation régulière et prévisible. L’auto-hébergement exige une planification de la capacité ; les charges très irrégulières entraînent soit un gaspillage de capacité en période creuse, soit des défaillances en cas de saturation.

Exigences de confidentialité ou de conformité. Données qui ne peuvent pas être envoyées à des fournisseurs cloud (secteurs réglementés, certains marchés publics, données strictement internes).

Modèles personnalisés. Modèles affinés, architectures personnalisées ou variantes spécialisées que les fournisseurs gérés ne proposent pas.

Contrôle de la latence. Pour certaines applications, une latence de premier token inférieure à 100 ms exige de faire fonctionner les modèles sur une infrastructure contrôlée.

Coût par appel inférieur au seuil de rentabilité. Lorsque vos calculs montrent que l’auto-hébergement est réellement plus avantageux.

Lorsque la plupart de ces conditions sont réunies, l’auto-hébergement mérite d’être sérieusement envisagé.

Lorsque l’auto-hébergement n’est pas pertinent

L’autre côté. Les caractéristiques qui favorisent les API gérées :

Échelle faible ou variable. Dépenses d’inférence inférieures à 5 000 €/mois. Les économies ne justifient pas le coût opérationnel.

Charges de travail irrégulières. Utilisation qui varie d’un facteur dix entre les pics et les périodes calmes. L’auto-hébergement gaspille de la capacité pendant les périodes creuses.

Besoin de capacités de pointe. GPT-5.5, Claude Opus 4.8 et les derniers niveaux de raisonnement sont des modèles fermés, disponibles uniquement par API. Si votre charge de travail exige réellement ce niveau de qualité, vous devrez utiliser des API.

Petite équipe. L’inférence auto-hébergée exige des compétences opérationnelles. Sans ressources dédiées, les incidents sont inévitables.

Itérations rapides. Vous devez tester de nombreux modèles, configurations ou fournisseurs. Les API facilitent ces essais ; avec l’auto-hébergement, chaque changement devient un déploiement.

Utilisateurs répartis dans plusieurs régions. L’auto-hébergement exige d’exploiter une infrastructure dans chaque région. Les fournisseurs d’API gérées s’en chargent.

Dans ces cas, les API gérées sont la bonne réponse même à un coût significatif.

Le calcul des coûts, avec prudence

Calculons les coûts réels d’un cas représentatif. Hypothèses :

• Charge de travail : 100 millions de tokens/mois d’entrée, 30 millions de tokens/mois de sortie.
• Objectif de qualité : comparable à Claude Sonnet 5 ou au niveau GPT-5.x actuel.
• Modèle open source disponible : Llama 3.3 70B (sa qualité est proche de celle des modèles fermés phares pour de nombreuses tâches ; notez qu’il n’existe pas de « Llama 4 70B » — Llama 4 est proposé sous la forme des modèles MoE Scout et Maverick).

Option A : API d’un modèle fermé.

• API d’un modèle fermé phare (tarif public de Claude Sonnet 5, vérifié le 2026-07-07) : 3 $/million de tokens d’entrée × 100 millions = 300 $. 15 $/million de tokens de sortie × 30 millions = 450 $. Total : environ 750 $/mois.

Ce niveau de dépense ne justifie pas l’auto-hébergement.

Multiplions la charge de travail par dix :

• 1 milliard de tokens d’entrée, 300 millions de tokens de sortie.
• API fermée : 7 500 $/mois.

L’auto-hébergement devient alors intéressant.

Option B : API d’un modèle open source chez un fournisseur géré.

• Llama 3.3 70B sur Together AI : 0,88 $/million de tokens d’entrée comme de sortie (tarif public vérifié le 2026-07-07).
• 1 milliard de tokens d’entrée × 0,88 $/million = 880 $. 300 millions de tokens de sortie × 0,88 $/million = 264 $. Total : environ 1 144 $/mois.

Économie d’environ 85 % par rapport aux modèles fermés. Significative.

Option C : auto-hébergement sur des GPU loués.

• Un modèle 70B quantifié en INT8 ou FP8 tient sur un seul H100 de 80 Go ; prévoyez environ deux H100 pour des poids FP16 ou pour disposer d’une marge de débit par lots — le dimensionnement ci-dessous en suppose deux pour le débit.
• H100 loués : 2 à 3 $/heure chacun.
• 2 H100 × 2,50 $/heure × 730 heures/mois = 3 650 $/mois pour le calcul seul.
• À cela s’ajoutent le stockage, le réseau et le temps d’exploitation.

Pour cette charge de travail, le modèle open source proposé par un fournisseur géré coûte moins cher que l’auto-hébergement. Ce dernier ne devient avantageux que si vous avez également besoin de contrôle (confidentialité ou modèle personnalisé) ou si votre débit est beaucoup plus élevé.

Option D : auto-hébergement sur des GPU achetés ou réservés à long terme.

• 2 H100 achetés ou réservés à long terme : coût effectif de 1 à 2 $/heure chacun.
• 2 H100 × 1,50 $/heure × 730 heures = 2 190 $/mois.
• Une utilisation plus élevée peut répartir le coût : si ces GPU gèrent plusieurs charges de travail, le coût par charge de travail est plus bas.

Maintenant, nous sommes compétitifs avec les fournisseurs open source gérés. Mais le surcoût opérationnel est réel.

Idée clé : à cette échelle de charge de travail (environ 1,3 milliard de tokens/mois), les économies de l’auto-hébergement par rapport aux fournisseurs gérés de modèles open source sont marginales. Les économies par rapport aux modèles fermés sont spectaculaires, mais l’offre open source gérée permet déjà d’en capter l’essentiel.

Avec une charge dix fois supérieure (environ 13 milliards de tokens/mois), l’auto-hébergement commence à devenir clairement avantageux. Avec une charge dix fois inférieure, l’hébergement géré est la bonne réponse.

Le coût opérationnel

Au coût brut de l’inférence s’ajoute celui de l’exploitation de l’infrastructure auto-hébergée.

Mise en place initiale :

• Choix du bon serveur d’inférence (vLLM, TGI, SGLang).
• Configuration pour votre modèle et votre matériel.
• Mise en place de l’infrastructure GPU (cloud ou propriétaire).
• Réseau, sécurité, observabilité.
• Quantification et optimisation.

Ordre de grandeur : une à quatre semaines d’ingénierie pour le premier déploiement.

Opérations continues :

• Surveillance (latence, débit, erreurs, utilisation GPU).
• Planification de la capacité.
• Mises à jour (nouvelles versions de modèles, mises à jour du serveur d’inférence, correctifs de sécurité).
• Gestion des incidents (pannes GPU, erreurs OOM, bugs logiciels).
• Mise à l’échelle (ajout de GPU lorsque la charge augmente).

Ordre de grandeur : de 0,25 à 1 ETP d’ingénierie en continu, selon l’échelle.

Coûts cachés :

• Volatilité des prix des GPU.
• Coûts de sortie cloud si hybride.
• Expertise spécialisée (CUDA, quantification, optimisation).
• Coûts de remplacement et de panne du matériel détenu.

Avec un coût complet de 100 000 à 200 000 € par ingénieur et par an, même une mobilisation à temps partiel représente une dépense importante. Une économie de 5 000 €/mois sur l’inférence disparaît face à 15 000 €/mois de coûts d’ingénierie.

C’est à ce niveau que les équipes sous-estiment le coût de l’auto-hébergement. Les seuls coûts d’inférence paraissent très favorables ; le coût total de possession est nettement plus élevé.

Les serveurs d’inférence

Si vous choisissez l’auto-hébergement, les principales options sont les suivantes :

vLLM. Open source, il est probablement le serveur le plus populaire pour exposer des LLM open source. Il propose PagedAttention, le traitement continu par lots et la prise en charge de nombreux modèles. C’est le choix par défaut.

TGI (Text Generation Inference). Serveur de Hugging Face. Mature, compatible avec de nombreux modèles et performant. Le rythme d’ajout de fonctionnalités a récemment été moins soutenu que celui de vLLM.

SGLang. Plus récent, très haute performance. Fort pour la génération structurée. Développement actif.

LMDeploy. Développé par l’équipe InternLM. Solide prise en charge de la quantification et bonnes performances.

llama.cpp / Ollama. Pour les modèles plus petits et les débits plus faibles. Adaptés aux CPU et suffisamment robustes pour certains usages en production.

Hugging Face TGI Inference Endpoints. Auto-hébergement géré. Les instances sont facturées à l’heure et exploitées par Hugging Face. Il s’agit d’un compromis entre l’auto-hébergement intégral et un service entièrement géré.

Modal, RunPod, Replicate. Inférence à la demande sous forme de service. Moins d’engagement que l’auto-hébergement intégral, mais un coût supérieur à une infrastructure exploitée en interne.

Pour la plupart des équipes : vLLM ou SGLang pour l’auto-hébergement en production. Les deux sont matures, rapides, bien documentés.

Choix du matériel

La question du GPU :

NVIDIA H100. Référence actuelle pour l’inférence. Environ 2 à 3 $/heure à la location. Il offre 80 Go de VRAM et une inférence rapide. Les modèles 70B fonctionnent bien sur un seul H100 avec quantification ou sur deux sans quantification.

NVIDIA H200. Successeur de H100, plus de VRAM (141 Go). Pour les modèles très grands.

NVIDIA L40S. Plus accessible, environ 1 à 2 $/heure. Adapté aux modèles de taille intermédiaire (jusqu’à environ 30B avec quantification).

NVIDIA A100. Génération précédente, encore largement disponible. Environ 1 à 2 $/heure. Il reste très utilisé dans de nombreux déploiements en production.

AMD MI300X. Compétitif avec le H100 pour certaines charges de travail et de plus en plus disponible. Son écosystème logiciel reste moins mature que celui de NVIDIA.

Apple M-series. Pour les très petits modèles (moins de 8B), un Mac Studio ou un Mac Pro doté de mémoire unifiée peut convenir. Il s’agit d’un cas d’usage de niche.

Pour la plupart des auto-hébergements en production en 2026 : H100 ou H200 si vous avez besoin de modèles grands ; L40S ou A100 pour les modèles modérés.

Sources de location : AWS, GCP, Azure (principales), Lambda Labs, Runpod, Together, Vast.ai (spécialisées). Les prix varient. Les instances spot/préemptibles peuvent économiser 50-70 % si vous tolérez les interruptions.

Quantification

La plupart des déploiements en production auto-hébergés utilisent des modèles quantifiés. Les compromis :

FP16 (16 bits). Précision par défaut. Qualité maximale, mais consommation de mémoire la plus élevée.

INT8 / FP8 (8 bits). Mémoire divisée par deux, avec une légère perte de qualité. Choix courant en production.

INT4 (4 bits). Mémoire divisée par quatre, avec une perte de qualité plus perceptible, mais parfois acceptable. Choix plus agressif.

AWQ, GPTQ, GGUF. Différents formats de quantification avec différents compromis.

Pour un modèle 70B :

• FP16 : 140 Go de VRAM.
• INT8 : 70 Go de VRAM.
• INT4 : 35 Go de VRAM.

Le H100 dispose de 80 Go de VRAM. Un modèle INT8 y tient confortablement ; le FP16 nécessite deux GPU.

Impact sur la qualité :

• INT8 : généralement <1 % de dégradation sur les benchmarks.
• INT4 : 1-5 % de dégradation, varie selon la tâche.

Testez sur votre charge de travail avant de déployer. Certaines tâches (surtout structurées/code) sont plus sensibles à la quantification que d’autres.

Débit et planification de la capacité

Une question essentielle pour la planification : de combien de tokens par seconde avez-vous besoin ?

Débit pour une requête unique.

• Modèle 70B sur H100, INT8 : environ 50 à 80 tokens/seconde pour un utilisateur.

Débit avec traitement par lots.

• Plusieurs requêtes simultanées : 1 000 à 3 000 tokens/seconde au total (vLLM avec un regroupement efficace).

Considérations de latence.

• Latence du premier token : 100-500 ms habituellement.
• Latence par token : 10-30 ms.

Pour la planification de la capacité :

• Estimez le pic de demandes simultanées.
• Estimez la longueur moyenne de la demande.
• Calculez le débit total de tokens/seconde nécessaire.
• Ajoutez 50 % de marge.

Une équipe qui traite 1 million de tokens/heure avec un pic de 50 utilisateurs simultanés a généralement besoin de deux à quatre H100 correctement exploités.

Fiabilité et plan d’urgence

L’auto-hébergement signifie que vous êtes propriétaire de la fiabilité.

Contrôles d’état. Surveillez en continu l’état du service et redémarrez les instances défaillantes.

Dégradation progressive. Lorsque la capacité est saturée, privilégiez les réponses lentes plutôt que les échecs.

Repli vers des API. De nombreuses équipes traitent le trafic principal sur leur propre infrastructure et basculent vers des API gérées en cas de surcharge. Cette approche combine les avantages des deux options, au prix d’une réelle complexité.

Matériel de secours. Les GPU peuvent tomber en panne. Maintenez une capacité de remplacement prête à prendre le relais.

Multi-région. Pour les utilisateurs mondiaux, répliquez. Ou utilisez les API gérées pour les régions éloignées.

Stratégie de mise à jour. Nouvelles versions de modèles, mises à jour du serveur. Déploiements bleu-vert pour éviter les temps d’arrêt.

Chacun de ces éléments est un travail d’ingénierie que les API gérées absorbent pour vous.

Exemple concret : une décision d’auto-hébergement d’une équipe

Prenons un exemple réel : une équipe SaaS proposant des fonctionnalités d’IA dépense 18 000 €/mois en inférence sur des API gérées.

Les calculs :

• 80 % de l’inférence concerne la classification et l’extraction (ces tâches pourraient être exécutées par un modèle open source plus petit).
• 20 % est de génération complexe (nécessite des modèles fermés de pointe).

Plan :

• Auto-héberger Llama 3.3 70B pour 80 % de la charge de travail.
• Conserver les API Claude/GPT pour les 20 %.
• 3 H100 réservés sur Lambda Labs : environ 4 500 €/mois.
• Mise en place : quatre semaines d’ingénierie, soit un coût ponctuel de 25 000 €.
• Exploitation continue : 0,25 ETP d’ingénierie, soit environ 30 000 €/an.

Résultat après 6 mois :

• Le coût d’inférence est passé de 18 000 €/mois à 6 000 €/mois (4 500 € d’auto-hébergement et 1 500 € d’API fermées pour les tâches difficiles).
• Économie brute par rapport à l’ancienne solution : 12 000 €/mois, soit 144 000 €/an.
• Investissement d’ingénierie à déduire : 25 000 € ponctuels et 30 000 €/an, soit environ 55 000 € la première année, puis 30 000 €/an.
• Bénéfice financier net : environ 89 000 € la première année, puis 114 000 €/an.

Complexités cachées :

• Une panne lorsqu’un déploiement avait un bug de configuration. Dégradation partielle de 2 heures.
• Plusieurs semaines de réglage continu pour obtenir un débit optimal.
• L’ingénieur faisant l’auto-hébergement souhaitait faire d’autres choses.

Résultat : bénéfice financier positif mais opérationnellement plus lourd que prévu. L’équipe continue l’auto-hébergement ; si le volume diminuait de 50 %, ils reviendraient aux API gérées.

Voilà à quoi ressemble une décision d’auto-hébergement réellement réussie. Il ne s’agit pas de magie, mais d’un travail d’ingénierie dont le retour sur investissement est mesurable.

Exemple concret : une décision de “retour aux API” d’une équipe

Une autre équipe, point de départ similaire.

Configuration initiale : Llama 3 70B auto-hébergé sur des GPU loués. Coût d’inférence : 3 000 €/mois de location, plus environ 20 000 €/an d’ingénierie récurrente.

Le changement :

• Le prix des modèles open source sur fournisseur géré a baissé de 50 % sur 18 mois.
• Leur équipe a grandi mais n’a pas embauché de MLOps dédié.
• La configuration d’auto-hébergement nécessitait un travail majeur pour suivre les nouveaux modèles.

La décision :

• Arrêter l’auto-hébergement.
• Passer à l’hébergement de modèles open source sur Together AI.
• Coût : 2 500 €/mois pour une offre open source gérée. L’économie est modeste, mais la complexité diminue.
• Libérer l’ingénieur.

Résultat :

• Économies financières modestes.
• Temps d’ingénieur libéré pour le travail produit.
• Moins de stress opérationnel.

Résultat : c’était la bonne décision pour cette équipe. L’auto-hébergement est avantageux pour certaines équipes, mais pas pour toutes.

Lorsqu’il faut reconsidérer la décision

La décision n’est pas permanente. Reconsidérez périodiquement :

Évolution du volume. Une forte hausse rend l’auto-hébergement plus attractif ; une forte baisse le rend moins intéressant.

Évolution des prix. Les API fermées peuvent devenir moins ou plus chères, les offres open source gérées peuvent baisser leurs tarifs et le matériel peut devenir plus abordable.

Amélioration des modèles. De nouveaux modèles open source peuvent atteindre la qualité des modèles fermés, tandis que de nouveaux modèles fermés peuvent reprendre de l’avance.

Capacité opérationnelle. Les compétences de l’équipe en ML et en exploitation ont augmenté ou diminué.

Changements de confidentialité / conformité. Nouvelles exigences imposant l’auto-hébergement.

Une réévaluation trimestrielle est raisonnable : inutile de remettre constamment la décision en question, mais elle ne doit pas non plus être considérée comme définitive.

Erreurs courantes

Voici les erreurs que nous observons fréquemment dans les décisions d’auto-hébergement :

Erreur 1 : calculer les économies sans tenir compte du coût opérationnel. « L’auto-hébergement économise 10 000 €/mois » — mais ce calcul ignore 15 000 €/mois d’ingénierie. Le retour sur investissement est négatif.

Erreur 2 : Auto-hébergement trop tôt. Dépenser des efforts d’ingénierie sur l’auto-hébergement alors que la charge de travail est petite. Optimisation prématurée.

Erreur 3 : chercher une qualité de pointe en auto-hébergeant de petits modèles open source. « Nous pouvons économiser de l’argent en utilisant un modèle plus petit » — mais la qualité baisse, les utilisateurs se plaignent et l’équipe revient aux API.

Erreur 4 : Aucun plan de secours. L’infrastructure auto-hébergée tombe en panne ; pas de dégradation progressive. Pannes lorsque les clients API n’auraient pas eu de pannes.

Erreur 5 : sous-investir dans l’optimisation. Faire fonctionner un modèle 70B sur un seul GPU à 5 tokens/seconde, alors qu’une configuration correcte en fournit 50, revient à gaspiller l’essentiel du potentiel.

Erreur 6 : Ignorer la dérive de qualité. Le modèle auto-hébergé s’est dégradé par rapport au modèle fermé actuel. Les clients le remarquent ; l’équipe ne le fait pas.

Erreur 7 : ne pas réévaluer la décision. Une décision pertinente il y a deux ans peut ne plus l’être aujourd’hui.

Erreur 8 : utiliser des instances spot ou préemptibles sans mécanisme de continuité. Vous économisez 60 % sur le calcul, mais subissez des interruptions toutes les quelques heures lorsque les instances sont récupérées par le fournisseur.

Liste de vérification pour la décision

Pour prendre la décision de manière délibérée :

• Les dépenses d’inférence par API atteignent-elles au moins 5 000 à 10 000 €/mois ?
• La charge de travail est-elle stable et prévisible ?
• L’équipe dispose-t-elle de compétences en MLOps et en inférence, ou peut-elle les recruter ?
• Existe-t-il un modèle open source offrant une qualité suffisante ?
• Les exigences de latence sont-elles compatibles avec l’auto-hébergement ?
• Avez-vous effectué un calcul détaillé qui inclut les coûts opérationnels ?
• Disposez-vous d’un plan de repli ?
• Les exigences de conformité ou de confidentialité n’imposent-elles pas déjà l’une des deux options ?
• Réévaluerez-vous la décision chaque trimestre ?

Si vous répondez oui à la plupart de ces questions, l’auto-hébergement mérite d’être sérieusement envisagé.

Modèles hybrides

Ce n’est pas tout ou rien. Beaucoup d’équipes opèrent en hybride :

Auto-hébergement pour le volume principal ; API pour les cas difficiles. Classification et génération simple sur l’infrastructure interne ; raisonnement complexe via des API fermées.

Auto-hébergement pour la charge de base ; API pour les pics. L’infrastructure interne traite la charge de base et les API absorbent les pics.

Auto-hébergement pour les données sensibles ; API pour les requêtes générales. Les données sensibles restent sur l’infrastructure interne et les requêtes générales passent par les API.

Auto-hébergement pour les modèles affinés ; API pour les modèles de base. Les modèles personnalisés sont exécutés en interne et les modèles standard sont consommés par API.

L’hybride ajoute de la complexité mais capture souvent le meilleur des deux mondes. Pour les équipes à grande échelle, l’hybride est souvent la bonne réponse.

Le message clé

L’inférence de LLM auto-hébergée est véritablement viable en 2026. Les modèles open source sont compétitifs, les serveurs d’inférence sont matures et le matériel est disponible.

Mais le coût opérationnel est réel et facile à sous-estimer. Le seuil de rentabilité par rapport aux API gérées se situe autour de 5 000 à 10 000 €/mois de dépenses d’inférence ; en dessous, l’investissement en ingénierie ne se justifie généralement pas.

Les équipes qui réussissent l’auto-hébergement :

• Ont effectué des calculs réalistes, coûts opérationnels compris.
• Ont ou peuvent construire des compétences MLOps.
• Opèrent à une échelle suffisante pour justifier l’investissement.
• Ont des charges de travail stables.
• Ne dépendent pas exclusivement de capacités disponibles dans les modèles de pointe fermés.
• Planifient la fiabilité, la surveillance et les mises à jour.

Les équipes qui devraient rester sur les API :

• Faible volume.
• Charges de travail très irrégulières.
• Besoin d’itérations rapides.
• Petites équipes sans capacité ops.
• Besoin de capacités de pointe fermées.

La bonne réponse dépend de votre situation. Faites les calculs avec soin. Évaluez honnêtement votre capacité opérationnelle. Privilégiez les API, sauf si l’auto-hébergement est clairement plus avantageux.

Lorsque l’auto-hébergement est avantageux, il peut l’être très nettement, sur les plans économique comme architectural. Dans le cas contraire, il constitue un moyen coûteux de découvrir que les API gérées étaient depuis le début la solution la plus adaptée.