Auto-héberger un LLM open-weight vs une API : les vrais calculs de coût

Votre produit sort, il appelle une API LLM, et la facture grimpe un peu plus chaque mois. Alors vous faites ce que tout bâtisseur finit par faire : vous ouvrez un nouvel onglet et vous vous demandez si louer un GPU et faire tourner Llama vous-même serait moins cher.

La question du coût de l'auto-hébergement d'un LLM a une réponse, mais ce n'est pas le chiffre unique que les premiers résultats de recherche et les AI Overviews répètent sans cesse. Cela dépend de trois choses que ces articles aplatissent : contre quelle API vous vous comparez, à quel point votre GPU est occupé, et le coût opérationnel que personne ne met dans le tableur.

Voici la version courte avant les détails : pour la plupart des bâtisseurs solo, l'auto-hébergement ne gagne pas sur le coût à l'heure actuelle. Mais il y a une ligne précise où ça bascule, et vous pouvez la calculer sur votre propre facture en deux minutes environ. Ci-dessous, les calculs de 2026 (prix actuels, chiffres de VRAM par modèle, et une formule que vous pouvez appliquer).

La version courte

• Le seuil de rentabilité n'est pas un chiffre. C'est trois, selon l'API contre laquelle vous vous comparez. Face à une API de pointe (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro), l'auto-hébergement atteint le seuil de rentabilité le plus vite. Face à une API open-weight économique (DeepSeek, DeepInfra, Together à environ $0.14–$0.50 par million de tokens), il ne gagne presque jamais sur le seul coût.
• L'utilisation est le multiplicateur qui tue le cas solo. Un GPU loué coûte la même chose au repos qu'à pleine charge, donc un GPU tournant à 10% d'utilisation coûte à peu près 10× par token ce qu'il coûte à pleine charge. Les charges de travail solo en rafales se situent par défaut à faible utilisation.
• En dessous du seuil de rentabilité, le gain de coût consiste généralement à passer à une API open-weight économique, pas à l'auto-hébergement. L'auto-hébergement gagne sa vie quand un volume soutenu face à une tarification de pointe franchit la ligne à 60%+ d'utilisation, ou quand vous avez une raison non liée au coût (confidentialité, latence, contrôle du fine-tuning).
• Appliquez la formule à vos propres chiffres avant de louer quoi que ce soit. Tokens du seuil de rentabilité ≈ coût mensuel du VPS GPU ÷ votre prix API mixte par token.

Ce que ceci ne couvre pas

• Les clusters GPU multi-nœuds ou à l'échelle d'un datacenter. C'est une décision de coût solo, pas une flotte.
• L'économie du fine-tuning en profondeur (un calcul distinct avec ses propres compromis).
• Un tutoriel de configuration Ollama-vs-vLLM étape par étape. Le périmètre ici, c'est la question de l'argent, pas l'installation.
• Le matériel possédé comme votre vecteur principal. L'hypothèse tout au long est un GPU loué, puisque c'est la voie réaliste pour un bâtisseur qui n'a pas déjà un GPU posé sur un bureau.

Ce qui détermine le coût (et où les chiffres populaires se trompent)

Cherchez « self host LLM vs API cost » et vous tomberez sur un chiffre de rentabilité bien net : quelque chose comme 11 milliards de tokens par mois, ou environ $4,200 de dépense API mensuelle, cité par l'analyse de coût de braincuber et repris presque mot pour mot dans l'AI Overview en haut de la page. C'est un chiffre propre. Il est aussi presque inutile en lui-même, parce qu'il cache les deux variables qui décident de votre réponse.

La raison pour laquelle c'est glissant, c'est que les deux côtés de la comparaison ont des formes de coût différentes. Une facture d'API est un coût variable : vous payez par token, donc la facture monte et descend avec l'usage que vous en faites. Un GPU loué est un coût fixe : vous payez le même tarif mensuel que vous poussiez un milliard de tokens à travers ou que vous le laissiez au repos. Comparer un coût variable à un coût fixe avec un seul chiffre exige de prétendre que vous savez exactement combien de tokens vont circuler, et à l'échelle solo, en général vous ne le savez pas.

Cela laisse trois leviers qui déplacent le seuil de rentabilité :

• Contre quelle API vous vous comparez. Une API de pointe et une API open-weight économique sont séparées par environ deux ordres de grandeur de prix. Le seuil de rentabilité face à chacune est radicalement différent.
• Votre utilisation du GPU. Le coût fixe ne se rentabilise que si le GPU est occupé. Le temps au repos, c'est de l'argent dépensé pour rien.
• Le coût opérationnel caché. Vos heures, le renouvellement lié aux mises à jour de modèles, et les surprises de VRAM qui n'apparaissent qu'une fois en production.

Chiffrez chacun d'eux et le brouillard se dissipe. C'est le reste de cet article.

À retenir de la section : le seuil de rentabilité n'est pas un chiffre unique. C'est trois chiffres, un par palier d'API, et choisir le mauvais palier de comparaison, c'est là que la plupart des estimations de coût dérapent.

Le seuil de rentabilité à trois voies : API de pointe vs intermédiaire vs économique

Auto-héberger un LLM open-weight sur un VPS GPU bat une API de pointe (classe GPT-5, Claude Sonnet 5 / Opus 4.8, Gemini Pro) à environ quelques millions de tokens par jour, à condition de garder le GPU à une utilisation saine (disons 60% ou plus). Face à une API open-weight économique à environ $0.14–$0.50 par million de tokens, il gagne rarement sur le coût tout court. Cette différence, c'est toute l'histoire, et c'est pourquoi un seul chiffre de rentabilité ne peut pas être juste.

Voici la forme générale à travers les trois paliers. Traitez ces seuils comme des plages indicatives, pas des lignes fermes. Ils proviennent d'estimations communautaires et de la tarification de 2026, qui bougent vite tous les deux.

Prix issus des pages de tarification OpenAI, Anthropic, Google, DeepInfra, Together, et DeepSeek au July 2026. Chacun de ces chiffres a une durée de vie qui se compte en mois, alors vérifiez les pages actuelles avant de vous engager.

Maintenant le point à contre-courant, parce que c'est celui qui change les décisions. Il y a un argument bruyant et correct qui circule selon lequel les API économiques ont tué le seuil de rentabilité de l'auto-hébergement. Les API open-weight comme DeepInfra et Together servent maintenant les modèles Llama et Qwen à une fraction des prix de pointe, et les prix de pointe eux-mêmes ont fortement chuté depuis 2025. Face à ces tarifs économiques, le seuil de rentabilité par token se chiffre en milliards de tokens par mois. Un solopreneur ne pousse pas des milliards de tokens par mois. Donc si votre seul objectif est une facture plus basse, le premier mouvement n'est généralement pas « louer un GPU », c'est « passer à une API open-weight économique et garder zéro opérations ».

Le cas de coût de l'auto-hébergement survit à deux endroits : la comparaison face à une tarification de pointe coûteuse à un volume véritablement élevé et soutenu, et les raisons non liées au coût (confidentialité, latence, contrôle du fine-tuning) couvertes plus bas. Partout ailleurs, l'API économique gagne l'argument de l'argent.

La formule du seuil de rentabilité

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Exemple concret, à l'échelle d'un solopreneur : disons qu'un seul VPS GPU haut de gamme coûte environ $1,000/mois (plage du catalogue 2026 pour un palier mono-GPU de tête), et que vous êtes sur une API de pointe avec un tarif mixte d'environ $6 par million de tokens (à peu près $0.000006 par token). Cela fait ~$1,000 ÷ $0.000006 ≈ 167 millions de tokens/mois avant que le GPU ne se rentabilise sur le papier. Maintenant refaites le calcul face à une API open-weight économique à $0.40 par million ($0.0000004/token) : ~$1,000 ÷ $0.0000004 = 2,5 milliards de tokens/mois. Même GPU, même coût fixe, et le seuil de rentabilité se déplace de plus de 10× selon uniquement l'API que vous mettez au dénominateur. Et c'est avant l'utilisation, qui aggrave le chiffre.

À retenir de la section : l'API contre laquelle vous vous comparez peut déplacer votre seuil de rentabilité de 10× ou plus, donc « faire les calculs » veut dire les faire contre l'API précise que vous remplaceriez réellement.

Ce que l'utilisation fait au coût par token

Prenez ce seuil de rentabilité de pointe d'environ 167 millions de tokens et ajoutez la variable que la formule met tranquillement de côté : votre GPU est occupé tout le temps. Il ne l'est pas. Un GPU loué facture la même chose qu'il soit saturé ou au repos, donc votre coût effectif par token du VPS GPU LLM évolue à l'inverse de l'utilisation. Tournez à 10% de charge et chaque token que vous servez porte à peu près 10× le coût qu'il aurait à pleine charge, parce que vous payez pour les 90% de capacité que vous n'avez pas utilisés. Les estimations communautaires et les retours de praticiens placent le plancher pratique autour de 50–60% d'utilisation soutenue avant que les chiffres cessent d'être embarrassants (des chiffres indicatifs, pas des constantes de laboratoire).

Pour une charge de travail solo en rafales (un trafic qui grimpe en pic pendant la journée et retombe à plat la nuit), une utilisation soutenue de 60% est difficile à atteindre. C'est le piège. Voici ce que ça fait au coût par million de tokens à travers quelques points concrets, en utilisant les prix GPU du catalogue 2026 divisés par un débit mensuel approximatif à chaque niveau d'utilisation :

Le coût absolu par token en cents dépend de votre modèle, de la quantification, et du nombre de requêtes concurrentes que vous pouvez tasser sur la carte, alors traitez les colonnes comme montrant la forme de la pénalité plutôt qu'un devis. Le point, c'est le multiplicateur : passez de la pleine charge à un quart de charge et votre coût par token quadruple à peu près. C'est généralement ce qui tue le cas de l'auto-hébergement solo, pas le prix affiché du GPU.

Il y a une échappatoire structurelle, et c'est la raison pour laquelle louer peut battre posséder pour une demande en dents de scie : vous pouvez arrêter une instance louée quand elle est au repos. Possédez le matériel et il se déprécie et tire du courant que vous l'utilisiez ou non. Sur des locations à l'heure ou à la demande, vous pouvez arrêter ou démonter l'instance quand le travail est fini et éviter de payer pour les heures au repos. Sur des forfaits mensuels fixes, la facture reste fixe pour la période de facturation, donc l'utilisation demeure le principal problème de coût. Cela ne règle pas une charge de travail véritablement à faible utilisation toute la journée, mais pour une demande occupée en rafales et morte entre-temps, la capacité à couper le compteur est le seul levier qui fait pencher louer-vs-posséder vers la location.

À retenir de la section : l'utilisation, pas le prix mensuel du GPU, est généralement ce qui décide si l'auto-hébergement est rentable, et c'est la variable que les chiffres de rentabilité populaires laissent entièrement de côté.

Quel modèle tient sur quel GPU : la réalité de la VRAM

Le plan qui casse en premier, c'est « je vais simplement faire tourner un 70B sur un 4090 ». Vous ne pouvez pas. Un modèle 70B en quantification Q4_K_M a besoin d'environ 40–46 GB de VRAM, et un RTX 4090 de 24 GB ou un RTX 5090 de 32 GB n'a tout simplement pas la place. Forcez-le sur une carte de 24 GB et vous voilà réduit à la quantification Q2_K (autour de 21 GB) avec une perte de qualité visible, ou le modèle déborde sur la RAM système et la vitesse de génération s'effondre. La VRAM est le mur dur qui décide quels modèles sont même envisageables pour un GPU donné.

Voici ce qui tient où. Les chiffres de VRAM sont approximatifs : ils sont dérivés de l'arithmétique standard octets-par-paramètre (FP16 ≈ params × 2 avec ~15% de surcharge ; Q4_K_M ≈ params × ~0.55 avec surcharge), alors traitez-les comme un guide de dimensionnement, pas des garanties.

Les chiffres de VRAM sont recoupés avec les pages officielles de spécifications GPU de NVIDIA pour chaque carte. L'A100 offre à un 70B quantifié une marge plus confortable ; le RTX 6000 Ada peut convenir pour des configurations Q4 plus serrées, tandis que les cartes grand public de 24 GB et 32 GB n'ont pas assez de VRAM pour un déploiement 70B Q4 normal. Si vous voulez le détail complet de la façon dont les formats GGUF, GPTQ, AWQ et EXL2 consomment la mémoire, c'est un terrier qui mérite sa propre lecture : GGUF, GPTQ, AWQ, EXL2 : comment les formats de quantification LLM utilisent vraiment la mémoire.

Le point idéal de la communauté pour une seule carte de 24 GB, c'est un modèle de 24B à 32B (Mistral Small 3.1 ou Qwen 3 32B en Q4). C'est la taille qui donne à un bâtisseur solo un modèle utile sur le palier GPU le moins cher sans se battre avec la VRAM tout du long. Si vous pesez quelle carte louer en premier lieu, notre benchmark H100 vs RTX 4090 pour les charges de travail IA compare les paliers sur le débit.

Astuce de pro : prévoyez un budget pour le KV cache, pas seulement pour les poids. La surprise de premier déploiement la plus courante : vous dimensionnez le GPU pour les poids du modèle, vous le chargez, et ça tient. Puis les requêtes arrivent, le KV cache grandit avec la longueur du contexte et la concurrence, et vous manquez de VRAM en servant vos tout premiers utilisateurs. Quand la VRAM déborde et que le modèle se répand sur le CPU, la vitesse de génération chute de 10–100×. Laissez de la marge au-dessus des chiffres de poids du tableau pour le cache, surtout si vous servez de longs contextes ou plusieurs utilisateurs à la fois.

Les coûts cachés qui effacent les économies naïves

Le tableur qui dit que l'auto-hébergement est moins cher n'a presque toujours qu'une ligne : le prix mensuel du GPU. La facture que vous payez a plus de lignes. Il y a votre temps (chaque heure passée à patcher, à redémarrer un serveur d'inférence bloqué ou à traquer un crash de mémoire insuffisante est une heure que vous n'avez pas passée sur le produit). Il y a le renouvellement lié aux mises à jour de modèles : le modèle open-weight que vous avez déployé se fait supplanter, et re-benchmarker et redéployer est un travail récurrent, pas une configuration ponctuelle. Il y a la surprise de VRAM et de KV cache de la section précédente. Et il y a le gaspillage au repos, les heures où le GPU facture sans que rien ne tourne.

Les praticiens qui ont compté tout ça placent le coût réel à environ 1,3–2× le prix brut du GPU une fois le temps d'opérations intégré, et certains vont plus haut, jusqu'à 3–5×, sur des configurations plus désordonnées. Ce sont des multiplicateurs indicatifs issus de retours communautaires, pas des chiffres audités, mais c'est la direction qui compte. Comme le dit une formule largement citée, un GPU au repos n'est pas un actif, c'est un passif facturé à l'heure. Pour un bâtisseur solo, la bonne façon de chiffrer cela n'est pas une ligne de salaire MLOps, ce sont vos propres heures, qui sont la chose la plus rare que vous ayez. Si l'auto-hébergement vous fait économiser $200 par mois sur le papier mais vous coûte six heures d'opérations que vous passeriez autrement à livrer, ce n'est pas manifestement un gain.

Quand l'auto-hébergement gagne malgré tout : confidentialité, latence et fine-tuning

Le coût n'est pas la seule raison de faire tourner votre propre modèle, et pour certains bâtisseurs ce n'est même pas la principale. En dessous du seuil de rentabilité de coût, là où l'argent dit « restez sur l'API », il y a trois raisons de s'auto-héberger quand même. La souveraineté des données : garder les prompts et les données de vos utilisateurs hors du pipeline d'un fournisseur d'IA externe, ce qui compte pour certains produits quoi que disent les chiffres. Une latence prévisible : pas de file d'attente en multi-locataires, pas de limites de débit que vous n'avez pas fixées, pas de ralentissements surprises pendant le pic de trafic de quelqu'un d'autre. Et le contrôle total : la liberté de fine-tuner, quantifier, changer de modèle et figer les versions sans attendre un fournisseur.

Il y a une réserve sur le point de la confidentialité, et la sauter serait malhonnête. Un VPS GPU loué tourne quand même sur le matériel de quelqu'un d'autre dans le datacenter de quelqu'un d'autre. C'est une souveraineté significative vis-à-vis du pipeline d'entraînement et de journalisation du fournisseur d'IA (vos prompts ne transitent pas par les systèmes d'un fournisseur de modèle), mais ce n'est pas la même chose qu'un équipement sur site que vous contrôlez physiquement. Si votre exigence est une véritable isolation on-premises, un VPS loué ne vous y amène pas. Si votre exigence est « garder nos données hors des mains d'un fournisseur de modèle tiers », il le fait. Sachez lequel des deux vous avez besoin.

Pour des charges de travail qui tournent dans des environnements réseau restrictifs, un modèle auto-hébergé sur une infrastructure que vous contrôlez peut aussi contourner les dépendances à des endpoints externes qui pourraient être injoignables, une capacité qui compte indépendamment de l'endroit où vous déployez.

Alors devriez-vous vous auto-héberger ? Une réponse directe selon la situation

Tout ce qui précède se ramène à une décision courte. Vous avez une facture, une idée approximative de votre volume mensuel de tokens, et maintenant les trois paliers de rentabilité, la pénalité d'utilisation et le multiplicateur de coûts cachés. Faites correspondre votre situation à l'une de celles-ci :

• Vous êtes en dessous du seuil de rentabilité de pointe et le coût est votre seule préoccupation. Restez sur une API, et chiffrez sérieusement une API open-weight économique (DeepSeek, DeepInfra, Together) avant toute autre chose. C'est généralement le gain de coût, pas l'auto-hébergement. Changer d'API est un changement de config ; l'auto-hébergement est un second emploi.
• Vous avez un volume élevé et soutenu face à une tarification de pointe et pouvez garder un GPU à 60%+ d'utilisation. C'est là que l'auto-hébergement paie. Appliquez la formule à votre tarif de pointe, confirmez que vous franchissez le seuil avec une utilisation soutenue (pas de pointe), et un VPS GPU loué commence à gagner.
• Vous avez un moteur non lié au coût : confidentialité, latence ou contrôle du fine-tuning. Auto-hébergez en dessous du seuil de rentabilité délibérément, en sachant que vous payez pour le contrôle. Ne vous racontez simplement pas que c'est moins cher si ça ne l'est pas.
• Vous êtes entre les deux. Regardez le schéma hybride sur lequel la plupart des praticiens atterrissent en 2026 : un petit modèle auto-hébergé pour les tâches simples à fort volume, plus une API de pointe pour le raisonnement difficile dont votre modèle local s'approche à 85–90% (benchmarks communautaires, pas vérifiés en laboratoire, et la dernière ligne droite est souvent là où vous avez le plus besoin de la qualité).

Sur la question du « comment j'obtiens le GPU », la réponse pour un bâtisseur solo est presque toujours louer, pas acheter. Posséder du matériel de qualité datacenter est un pari en capex qui n'a de sens qu'à une échelle que vous n'avez pas encore. L'inférence serverless peut réduire le gaspillage au repos en descendant à zéro et en ne facturant que le calcul actif, mais elle troque souvent cela contre un tarif par heure-GPU plus élevé et une latence de démarrage à froid. Un VPS GPU loué se situe au milieu : pas de capex, une facture mensuelle prévisible, un accès root, et la capacité d'arrêter l'instance quand elle est au repos.

Si vous avez appliqué la formule, franchi le seuil de rentabilité, et voulez un serveur d'inférence dédié, privé, avec accès root sans acheter de carte, c'est exactement à cela que sert une machine GPU louée. Les plans VPS GPU de Cloudzy couvrent la gamme d'un modèle 8B sur une seule carte jusqu'à un 70B quantifié, et l' application Ollama en un clic dans le marketplace se déploie en une minute environ avec une API REST compatible avec les clients OpenAI, si bien que le passage d'une API payante à votre propre serveur peut être quasiment un remplacement direct dans votre code, sans coût par token après le forfait mensuel fixe. Consultez la page pour la tarification actuelle ; les tarifs GPU bougent.

La seule action qui vaille la peine avant de louer quoi que ce soit : appliquez la formule du seuil de rentabilité à votre propre facture. Cela prend deux minutes et ça vous dira dans laquelle des quatre situations ci-dessus vous êtes.

Foire aux questions

Est-il moins cher d'auto-héberger un LLM ou d'utiliser une API ?

Cela dépend de quelle API. Auto-héberger un modèle open-weight sur un VPS GPU peut battre une API de pointe (classe GPT-5, Claude Sonnet 5 / Opus 4.8) à un volume élevé et soutenu avec une bonne utilisation du GPU. Il bat rarement une API open-weight économique (DeepSeek, DeepInfra, Together à environ $0.14–$0.50 par million de tokens au July 2026) sur le seul coût : ce seuil de rentabilité se chiffre en milliards de tokens par mois, ce que la plupart des bâtisseurs solo n'atteignent jamais.

De quel GPU ai-je besoin pour faire tourner un modèle 70B ?

Un modèle 70B en quantification Q4_K_M a besoin d'environ 40–46 GB de VRAM rien que pour les poids quantifiés. Un A100 de 80 GB est l'option mono-GPU la plus sûre parce qu'elle laisse de la place pour le KV cache, la surcharge d'exécution et les prompts plus longs. Un RTX 6000 Ada de 48 GB peut convenir pour des configurations Q4 plus serrées, mais la longueur du contexte et la concurrence doivent être gérées avec soin.

Comment l'utilisation du GPU affecte-t-elle le coût par token ?

Un GPU loué coûte la même chose qu'il soit au repos ou pleinement chargé, donc votre coût effectif par token évolue à l'inverse de l'utilisation. À 10% de charge, chaque token que vous servez coûte à peu près 10× ce qu'il coûterait à pleine charge, parce que vous payez pour la capacité inutilisée. Le plancher pratique pour que l'auto-hébergement ait du sens est autour de 50–60% d'utilisation soutenue.

Combien de tokens par mois avant que l'auto-hébergement en vaille la peine ?

Face à une API de pointe, environ 160–256 millions de tokens par mois à une utilisation saine est le seuil indicatif (au July 2026). Face à une API open-weight économique, c'est des milliards par mois, concrètement inatteignable en solo. Le chiffre exact dépend de votre coût de GPU et de votre tarif API mixte, alors appliquez la formule : tokens du seuil de rentabilité ≈ coût mensuel du VPS GPU ÷ votre prix API par token, puis décotez-le pour l'utilisation soutenue.

Puis-je faire tourner un LLM open-weight sur un VPS ?

Oui, sur un VPS GPU dimensionné à la VRAM du modèle. Un outil comme Ollama fait tourner des modèles open-weight (Llama, Qwen, Mistral et d'autres) avec un déploiement en un clic et une API REST compatible OpenAI, si bien que votre code existant appelant une API peut pointer vers votre propre serveur avec un minimum de changements. Faites correspondre le palier GPU à votre modèle : un 8B tient confortablement sur une carte de 24 GB, un 70B quantifié a besoin de 48–80 GB.