À partir de quel volume de tokens l'auto-hébergement revient-il moins cher qu'une API ?

Cela dépend du taux d'utilisation, il n'y a donc pas de chiffre unique. En gros, l'auto-hébergement peut l'emporter sur les API premium dès quelques millions de tokens par mois sur une GPU bien exploitée, mais l'emporter sur les API économiques nécessite des dizaines à des centaines de millions par mois. Un seuil indicatif courant est de quelques millions de tokens par jour, de façon soutenue ; en dessous, une API l'emporte généralement.

Combien coûte une H100 par mois ?

Une H100 à la demande coûte environ 1,50–3,00 $/heure sur les clouds GPU spécialisés (plus chez les hyperscalers), soit une instance dédiée 24h/24 aux alentours de 1 000–5 000 $ par mois selon le niveau du fournisseur. Ce coût fixe est ce que le volume de tokens doit couvrir pour que l'auto-hébergement soit rentable.

Pourquoi le taux d'utilisation de la GPU fait-il ou défait-il la rentabilité de l'auto-hébergement ?

Parce que la GPU coûte le même prix qu'elle soit occupée ou au repos. Bien exploitée, le coût par million de tokens peut descendre sous un dollar ; à faible charge (disons 10 %), le coût réel par token est multiplié par environ dix, rendant souvent l'auto-hébergement plus cher qu'une API premium. Une GPU au repos est du pur gaspillage : le taux d'utilisation est la variable la plus déterminante.

L'auto-hébergement revient-il moins cher qu'une API économique, comme un petit modèle hébergé ?

En général, seulement à très fort volume. Les API économiques sont tarifées de façon agressive, si bien que les surpasser par l'auto-hébergement nécessite typiquement des dizaines à des centaines de millions de tokens par mois à bon taux d'utilisation. Face aux API premium, le croisement survient bien plus tôt. Comparez avec l'API précise que vous utiliseriez sinon, pas avec un tarif générique.

Dans quelle mesure la quantification réduit-elle le coût de l'auto-hébergement ?

Substantiellement. FP8 double à peu près le débit avec une perte de qualité minimale, et INT4 peut le tripler à peu près tout en réduisant le modèle pour qu'il tienne sur une GPU plus petite et moins chère. Sur un grand modèle, cela peut réduire de moitié ou plus le coût par million de tokens : la quantification est l'un des leviers de coût les plus déterminants pour l'auto-hébergement.

Quels coûts cachés accompagnent l'auto-hébergement d'un LLM ?

L'exploitation. Au-delà de la facture GPU, vous payez l'ingénierie MLOps (un salaire à six chiffres), les cycles de mise à jour de modèle (des semaines de travail chacun) ainsi que le serveur d'inférence, la gestion des drivers, l'autoscaling et la supervision. Ces postes ajoutent couramment plusieurs fois le coût brut du matériel et c'est précisément ce que la plupart des calculs naïfs de seuil de rentabilité omettent.

Puis-je combiner auto-hébergement et API pour optimiser les coûts ?

Oui : l'approche hybride est généralement la plus judicieuse. Faites tourner les volumes élevés et réguliers sur une inférence locale ou propriétaire, les charges de volume moyen et prévisibles sur un endpoint dédié, et le trafic irrégulier ou à faible volume (ainsi que tout ce qui exige une qualité frontier) sur une API facturée au token. Router selon l'économie capture les économies de l'auto-hébergement sans payer de GPU au repos sur des charges en rafale.

← Resources

By Jordan Malik — Staff Engineer, Inference · 2026-06-02 · GUIDE

Quand héberger soi-même ses LLM revient moins cher qu'une API

Héberger soi-même un LLM revient moins cher qu'une API uniquement au-delà d'un volume de tokens qui dépend entièrement du taux d'utilisation de la GPU : il n'existe pas de seuil de rentabilité unique. Ce guide détaille les vrais calculs, pourquoi le batching et la quantification sont décisifs, le coût d'exploitation caché et pourquoi l'approche hybride est généralement la bonne réponse.

Il n'existe pas de seuil de rentabilité unique

La réponse honnête à « quand l'auto-hébergement revient-il moins cher ? » est une fourchette conditionnée par le taux d'utilisation, pas un chiffre. C'est pourquoi les estimations publiées divergent d'ordres de grandeur : elles partent de prix de GPU, de taux d'utilisation et d'API de référence différents.

La règle utile : l'auto-hébergement a tendance à l'emporter sur les API premium dès un volume soutenu relativement modeste (quelques millions de tokens par mois sur une GPU bien exploitée), mais l'emporter sur les API économiques en demande bien davantage (des dizaines à des centaines de millions par mois). Un ordre de grandeur courant se situe autour de quelques millions de tokens par jour, de façon soutenue. En dessous, une API l'emporte presque toujours.

Les calculs côté GPU

Auto-héberger, c'est louer ou posséder une GPU, et ce coût fixe est ce que votre volume de tokens doit « remplir ». Une H100 à la demande coûte environ 1,50–3,00 $/heure sur les clouds spécialisés (davantage chez les hyperscalers), soit une H100 dédiée 24h/24, 7j/7 de l'ordre de 1 000–5 000 $ par mois selon le niveau du fournisseur.

Cette mensualité est fixe, que vous l'utilisiez ou non : c'est pourquoi le coût par million de tokens n'est faible qu'à fort taux d'utilisation. Bien exploité, un modèle de taille moyenne peut descendre bien en dessous d'un dollar par million de tokens ; à 10 % de charge, le coût réel par token est multiplié par environ dix, de quoi rendre l'auto-hébergement plus cher qu'une API premium. Une GPU au repos est le moyen le plus rapide de perdre l'argument économique.

Le batching et la quantification sont décisifs

Deux leviers déplacent le seuil de rentabilité plus que tout le reste. Le batching continu (grâce aux serveurs d'inférence modernes) est le moteur économique : traiter de nombreuses requêtes simultanément sur la même GPU peut réduire drastiquement le coût par token ; passer d'une requête à la fois à de grands lots peut améliorer le débit d'ordres de grandeur. Un trafic irrégulier à faible concurrence ne remplit pas les lots et offre des performances plusieurs fois inférieures au pic, ce qui explique pourquoi les charges de travail en rafale s'auto-hébergent mal.

[La quantification](/articles/llm-quantization-explained-gguf) est l'autre levier : FP8 double à peu près le débit avec une perte de qualité minimale, et INT4 peut le tripler à peu près tout en réduisant le modèle pour qu'il tienne sur une GPU plus petite et moins chère. Ensemble, batching et quantification peuvent faire varier le coût par token d'un facteur de plusieurs unités.

Le coût caché : l'exploitation

La facture GPU n'est pas toute la facture. L'exploitation ajoute couramment plusieurs fois le coût brut du matériel : un ingénieur MLOps représente un salaire à six chiffres, et chaque cycle de mise à jour de modèle — requantification, tests, redéploiement — représente des semaines de travail. Les modèles open-weight « gratuits » peuvent dissimuler des centaines de milliers de dollars par an en ingénierie, une fois pris en compte le serveur d'inférence, la gestion des drivers et de CUDA, l'autoscaling et la supervision.

C'est le poste qui fait s'effondrer les calculs naïfs de l'auto-hébergement. Le coût par token sur fiche technique suppose que la GPU se gère toute seule ; en réalité, quelqu'un doit la maintenir en fonctionnement, et cette personne n'est pas gratuite.

Quand l'API l'emporte nettement (et les facteurs hors coût)

Une API est le bon choix pour des volumes faibles ou irréguliers, un trafic imprévisible, des équipes sans MLOps en interne et tout besoin de modèles de qualité frontier que l'on ne peut pas faire tourner soi-même. Selon une estimation, une API est le meilleur choix pour la grande majorité des cas d'usage, et les prix des API continuent de baisser, ce qui repousse le seuil de rentabilité de l'auto-hébergement toujours plus haut au fil du temps.

Deux facteurs échappent entièrement aux calculs de coût : la latence et la confidentialité. L'auto-hébergement s'impose pour la résidence des données, les charges de travail réglementées et une latence prévisible en région, indépendamment de l'économie des tokens ; voir notre [guide sur l'on-premise](/articles/on-premise-ai-for-enterprise). Ces facteurs peuvent justifier l'auto-hébergement même quand les calculs de coût seuls ne le justifient pas.

Router selon l'économie avec osFoundry

La réponse pragmatique est hybride : router selon des critères économiques, pas idéologiques. Les volumes élevés et réguliers reviennent à l'inférence locale ou propriétaire, où remplir les lots d'une GPU fait baisser le coût par token. Les charges de volume moyen et prévisibles conviennent à un endpoint GPU dédié : un débit qui exploite bien la GPU, sans posséder de matériel ni supporter le multiplicateur d'exploitation complet. Le trafic irrégulier, faible ou imprévisible, ainsi que tout ce qui exige une qualité frontier, reste sur des API BYOK facturées au token.

osFoundry gère automatiquement les leviers qui font réellement bouger le seuil de rentabilité — quantification, batching et routage par niveau — et permet à la même charge de travail de s'exécuter en local, sur un endpoint dédié ou via une API BYOK. Vous captez ainsi les économies là où l'auto-hébergement gagne, sans gérer vous-même CUDA, l'autoscaling ou les calculs de cycle d'utilisation. (Notre [analyse des coûts BYOK](/articles/byok-vs-managed-ai-cost-breakdown) couvre le versant API de l'équation.)

Frequently asked questions

À partir de quel volume de tokens l'auto-hébergement revient-il moins cher qu'une API ?: Cela dépend du taux d'utilisation, il n'y a donc pas de chiffre unique. En gros, l'auto-hébergement peut l'emporter sur les API premium dès quelques millions de tokens par mois sur une GPU bien exploitée, mais l'emporter sur les API économiques nécessite des dizaines à des centaines de millions par mois. Un seuil indicatif courant est de quelques millions de tokens par jour, de façon soutenue ; en dessous, une API l'emporte généralement.
Combien coûte une H100 par mois ?: Une H100 à la demande coûte environ 1,50–3,00 $/heure sur les clouds GPU spécialisés (plus chez les hyperscalers), soit une instance dédiée 24h/24 aux alentours de 1 000–5 000 $ par mois selon le niveau du fournisseur. Ce coût fixe est ce que le volume de tokens doit couvrir pour que l'auto-hébergement soit rentable.
Pourquoi le taux d'utilisation de la GPU fait-il ou défait-il la rentabilité de l'auto-hébergement ?: Parce que la GPU coûte le même prix qu'elle soit occupée ou au repos. Bien exploitée, le coût par million de tokens peut descendre sous un dollar ; à faible charge (disons 10 %), le coût réel par token est multiplié par environ dix, rendant souvent l'auto-hébergement plus cher qu'une API premium. Une GPU au repos est du pur gaspillage : le taux d'utilisation est la variable la plus déterminante.
L'auto-hébergement revient-il moins cher qu'une API économique, comme un petit modèle hébergé ?: En général, seulement à très fort volume. Les API économiques sont tarifées de façon agressive, si bien que les surpasser par l'auto-hébergement nécessite typiquement des dizaines à des centaines de millions de tokens par mois à bon taux d'utilisation. Face aux API premium, le croisement survient bien plus tôt. Comparez avec l'API précise que vous utiliseriez sinon, pas avec un tarif générique.
Dans quelle mesure la quantification réduit-elle le coût de l'auto-hébergement ?: Substantiellement. FP8 double à peu près le débit avec une perte de qualité minimale, et INT4 peut le tripler à peu près tout en réduisant le modèle pour qu'il tienne sur une GPU plus petite et moins chère. Sur un grand modèle, cela peut réduire de moitié ou plus le coût par million de tokens : la quantification est l'un des leviers de coût les plus déterminants pour l'auto-hébergement.
Quels coûts cachés accompagnent l'auto-hébergement d'un LLM ?: L'exploitation. Au-delà de la facture GPU, vous payez l'ingénierie MLOps (un salaire à six chiffres), les cycles de mise à jour de modèle (des semaines de travail chacun) ainsi que le serveur d'inférence, la gestion des drivers, l'autoscaling et la supervision. Ces postes ajoutent couramment plusieurs fois le coût brut du matériel et c'est précisément ce que la plupart des calculs naïfs de seuil de rentabilité omettent.
Puis-je combiner auto-hébergement et API pour optimiser les coûts ?: Oui : l'approche hybride est généralement la plus judicieuse. Faites tourner les volumes élevés et réguliers sur une inférence locale ou propriétaire, les charges de volume moyen et prévisibles sur un endpoint dédié, et le trafic irrégulier ou à faible volume (ainsi que tout ce qui exige une qualité frontier) sur une API facturée au token. Router selon l'économie capture les économies de l'auto-hébergement sans payer de GPU au repos sur des charges en rafale.