Self-Hosting d'un LLM vs. API : Quand Est-Ce Vraiment Rentable ?

Le self-hosting d'un LLM devient pertinent dans deux situations : soit votre volume est suffisamment élevé pour que le coût GPU par token soit inférieur au coût API par token, soit vous avez une exigence de résidence des données que les appels API ne peuvent pas satisfaire, quel qu'en soit le prix. En dehors de ces deux cas, appeler l'API d'OpenAI, d'Anthropic ou de Google est moins cher, plus rapide à déployer et plus simple à maintenir que de faire tourner votre propre stack d'inférence.

Cette question revient souvent de la part de fondateurs dans la santé et le govtech, précisément parce que « les données peuvent-elles quitter notre réseau ? » n'est souvent pas une question de coût, mais une question légale. Le cadre ci-dessous sépare donc la décision en deux axes — coût et conformité — car les fondateurs n'ont généralement besoin que d'une des deux réponses, pas des deux.

Le calcul économique, développé

Un NVIDIA A100 80 Go coûte environ $2 à $3 de l'heure à la demande chez des fournisseurs comme Lambda ou CoreWeave. Faites tourner la machine 24h/24, 7j/7 pendant un mois, et vous atteignez $1 500 à $2 200, que vous traitiez une requête ou un million. C'est le problème central du self-hosting : vous payez pour de la capacité, pas pour de l'usage.

Comparez cela à la tarification API, où vous payez au token et rien du tout en période d'inactivité. Pour une charge de travail de, disons, 5 millions de tokens par jour sur un modèle de gamme intermédiaire, les coûts API se situent généralement bien en dessous de $1 500/mois, sans aucune charge opérationnelle. Le point de bascule où un GPU dédié commence à devenir rentable se situe généralement au-delà de 20 à 50 millions de tokens/jour de trafic soutenu et prévisible — et même dans ce cas, il vous faut quelqu'un pour maintenir la stack de serving (vLLM, TGI ou équivalent), gérer les pannes GPU, les mises à jour de pilotes et le scaling.

Nous avons traversé une version de ce calcul nous-mêmes. Notre outil de cold outreach scrape le site de chaque prospect via une instance Firecrawl en self-hosting et un modèle local pour extraire des informations et rédiger un email en un seul appel. À notre volume, exécuter cette étape localement était moins cher et nous donnait plus de contrôle sur les limites de débit que de router chaque scrape via une API hébergée. Mais nous n'hébergeons pas nous-mêmes la rédaction commerciale proprement dite — elle passe toujours par un modèle hébergé, car le volume ne justifie pas une capacité GPU dédiée et le niveau de qualité requis est plus élevé. Combiner les deux approches — self-hosting pour les tâches déterministes peu coûteuses, API pour la génération à fort enjeu — est généralement la bonne configuration pour les produits en phase initiale. C'est le même raisonnement que nous développons dans l'optimisation des coûts LLM : faites correspondre le niveau du modèle et le mode d'hébergement à la tâche, et non l'inverse.

D'où viennent les coûts « cachés » du self-hosting

• Infrastructure de serving. vLLM et Text Generation Inference gèrent le batching et la gestion du KV-cache, mais quelqu'un doit les opérer, les patcher et gérer les crashs OOM en charge.
• Mises à jour des modèles. Les modèles open-weight progressent vite. S'engager dans le self-hosting signifie que vous prenez en charge le cycle de fine-tuning et d'évaluation à chaque fois qu'un meilleur modèle de base est publié, au lieu qu'un fournisseur l'intègre en coulisses derrière une API.
• Redondance. Un seul nœud GPU est un point de défaillance unique. Une vraie disponibilité nécessite au minimum deux nœuds, ce qui double à peu près le coût de base mentionné plus haut.

L'argument de conformité, qui est une question entièrement différente

Si votre contrainte est la résidence des données, les PHI, ou un contrat client interdisant l'envoi de données à un tiers, le calcul économique ci-dessus est en grande partie hors sujet. Vous ne comparez pas des dollars — vous évaluez si vous pouvez légalement faire la chose ou non. C'est la situation dans laquelle se trouvent beaucoup de nos clients dans la santé et le secteur parapublic, et c'est le même terrain que nous couvrons dans l'architecture prête pour le contentieux dans l'IA de santé.

Quelques points sur lesquels il vaut la peine d'être précis :

• Le self-hosting règle le problème « les données quittent notre réseau », mais il ne vous rend pas conforme HIPAA en lui-même. Vous avez toujours besoin du chiffrement au repos et en transit, de journaux d'accès et d'une politique de rétention documentée autour du modèle et de ses logs.
• Les fournisseurs d'API managés proposent des endpoints éligibles HIPAA couverts par un BAA (OpenAI et Anthropic proposent tous deux ces options pour les clients enterprise), donc « nous avons besoin de la conformité HIPAA » ne signifie pas automatiquement « nous devons héberger nous-mêmes ». Vérifiez cette option avant de supposer que vous avez besoin de vos propres GPU.
• Les contrats gouvernementaux et de défense sont une autre histoire. Beaucoup exigent que le modèle et les données résident dans un environnement accrédité (FedRAMP, IL4/IL5, ou totalement air-gappé), où une API publique est d'emblée exclue, indépendamment de tout BAA. C'est là que le self-hosting cesse d'être optionnel.

La qualité des modèles open-weight, en toute franchise

Pour les tâches ciblées — classification, extraction, tri structuré, routage d'intention — un modèle open-weight fine-tuné ou bien prompté sur vos données peut rivaliser avec un modèle fermé de dernière génération, tout en vous laissant un contrôle total sur la latence et la confidentialité. La famille Llama de Meta et les modèles Qwen d'Alibaba sont tous deux des points de départ raisonnables pour des déploiements en self-hosting.

Pour le raisonnement ouvert, les documents longs, ou tout cas où le mode d'échec est « une réponse subtilement fausse exprimée avec assurance », les modèles API de dernière génération conservent un avantage. Ne régressez pas en qualité en choisissant le self-hosting pour économiser de l'argent sur une tâche où le jugement du modèle est le cœur du produit.

Un chemin de décision pratique

1. Estimez votre volume réel en tokens, pas en requêtes. Multipliez le nombre moyen de tokens par requête par le nombre de requêtes journalières. Si vous êtes en dessous d'environ 10 à 20 millions de tokens/jour, commencez avec une API.
2. Vérifiez si un endpoint éligible HIPAA/BAA d'un grand fournisseur satisfait votre exigence de conformité. Si oui, vous n'avez probablement pas besoin du self-hosting.
3. Si ni le coût ni la conformité ne vous y obligent, n'optez pas pour le self-hosting. La charge opérationnelle est une distraction par rapport à la construction du produit durant les 12 à 18 premiers mois de vie d'une entreprise.
4. Si vous choisissez le self-hosting, provisionnez pour la redondance et une astreinte permanente, pas seulement pour la ligne GPU.

C'est le même raisonnement qui s'applique au choix entre des fournisseurs managés et BYOK dans BYOK vs. clés LLM managées pour le pricing SaaS : l'option qui paraît la moins chère sur le papier est rarement la moins chère une fois que vous comptez la charge opérationnelle qu'elle impose à votre équipe.

Si vous cherchez à déterminer où se situe réellement votre produit sur cette ligne, parlons-en.