Auto-héberger un LLM ou appeler une API : le calcul

L'équation, en une ligne

Toute comparaison entre louer un GPU et appeler une API se ramène à une seule division :

Volume d'équilibre (tokens par mois) = (prix horaire de la machine × 730) ÷ (prix au token que vous paieriez autrement)

730, c'est le nombre d'heures d'un mois moyen. Tout le reste de cet article est soit l'un des deux côtés de cette division, soit un coût que la division escamote. Si le résultat surprend, ce n'est pas parce que l'arithmétique est difficile : c'est parce que les deux côtés se facturent dans des unités incompatibles. Un serveur facture du temps. Une API facture de la consommation. Vous ne gagnez du côté facturé au temps que si vous remplissez ce temps.

Le côté prix est public et exact

Commençons par le matériel. Une instance de cloud public bâtie autour d'un seul NVIDIA H100 se situe autour de 2,80 € de l'heure en prix de liste chez un fournisseur européen — nous avons revérifié cet ordre de grandeur en août 2026, et il vaut la peine de le revérifier vous-même : les tarifs GPU bougent et varient selon la région, l'engagement, et selon que le stockage et la sortie réseau sont inclus ou non. À prendre comme un point de départ, pas comme un devis.

Faites-la tourner en continu et vous obtenez ≈ 2 044 € par mois (2,80 € × 730). Ce montant ne bouge pas quand votre trafic bouge. Il est identique une semaine de lancement et un mois d'août calme.

L'autre côté maintenant. Prenons Llama 3.3 70B, un modèle que nous servons sur infrastructure souveraine UE : 1,26 € par million de tokens, en entrée comme en sortie — le prix complet qui vous serait effectivement facturé, pas un coût d'infrastructure. Tous les prix de notre catalogue de modèles sont publiés de la même façon, par million de tokens en entrée et en sortie.

Divisons : 2 044 € ÷ 1,26 € ≈ 1 622 millions de tokens. Soit environ 1,6 milliard de tokens par mois avant qu'un H100 loué ne devienne gagnant sur le seul critère du prix. S'il vous faut deux cartes — et pour un modèle 70B, c'est probablement le cas, voir la section suivante — le seuil double, à environ 3,2 milliards de tokens par mois.

Scénario	Coût machine / mois	Équilibre face à 1,26 €/M tokens
1 × H100, en continu	≈ 2 044 €	≈ 1,6 milliard de tokens
2 × H100, en continu	≈ 4 088 €	≈ 3,2 milliards de tokens
2 × H100 + une seconde machine pour la redondance	≈ 8 176 €	≈ 6,5 milliards de tokens

Pour donner l'échelle : une recharge prépayée de 20 € achète environ 16 millions de tokens sur ce même modèle 70B, ou près de 357 millions sur le modèle le moins cher du catalogue. La plupart des équipes découvrent que leur volume mensuel réel est deux à trois ordres de grandeur sous le seuil.

Pourquoi « un H100 » est rarement la bonne unité

Les estimations de coin de table se trompent presque toujours au même endroit : elles chiffrent une carte, puis le déploiement se fait sur deux. La contrainte, c'est la mémoire, et elle mord avant le débit.

Un modèle de 70 milliards de paramètres en FP16 réclame environ 140 Go rien que pour les poids — deux octets par paramètre. Un H100 dispose de 80 Go de HBM. Quantifiez en FP8 et les poids tombent à environ 70 Go : techniquement ça rentre sur une carte, et il ne reste presque rien pour le cache KV — cette mémoire par requête qui croît avec la longueur de contexte et la taille de lot, et qui est précisément ce dont vous avez besoin pour servir plusieurs utilisateurs à la fois. En pratique, un modèle 70B servi avec un contexte utilisable et du batching demande deux cartes.

Avant toute comparaison, dimensionnez donc la machine par la mémoire d'abord, par le débit ensuite. Puis chiffrez cette machine-là. C'est la même arithmétique qui fait qu'un modèle de 158 milliards de paramètres réclame environ 160 Go en FP8 et atterrit sur deux H200 ou quatre H100, tandis qu'un modèle de 2 800 milliards de paramètres ne relève plus du tout d'une conversation à un seul nœud.

Le côté débit, c'est à vous de le mesurer

Convertissez le seuil de tokens par mois en tokens par seconde et l'image devient nette. Un mois de 730 heures compte 2 628 000 secondes, donc :

• 1,6 milliard de tokens par mois ≈ 617 tokens par seconde, en continu, jour et nuit
• 3,2 milliards de tokens par mois ≈ 1 234 tokens par seconde, en continu, jour et nuit

Nous n'allons délibérément pas vous donner un chiffre de tokens par seconde pour votre modèle sur votre matériel. Cela dépend de la quantification, de la taille de lot, de la longueur de contexte, du mélange entre prompt et complétion, et de la pile de service — et un chiffre recopié du billet de blog de quelqu'un d'autre n'est pas un chiffre sur lequel bâtir un budget. Mesurez le vôtre, sous votre propre charge.

Ce que l'arithmétique vous dit en revanche, quelle que soit votre mesure, c'est que le seuil de rentabilité se situe tout près du point de saturation de la machine. Cela change complètement la question posée. Il ne s'agit pas de savoir « si un GPU revient moins cher au token qu'une API » — à saturation, en général oui. Il s'agit de savoir « si je peux occuper ce GPU chaque heure que je paie ». Pour la plupart des équipes, la réponse honnête est non, et c'est cette réponse-là qui décide du coût.

C'est le taux d'utilisation qui tranche

Voici l'asymétrie en une comparaison. Faites tourner un outil interne utilisé aux heures de bureau — huit heures par jour, cinq jours par semaine — et vous avez acheté 730 heures pour en utiliser 176. Soit 24 % d'utilisation, ce qui signifie que votre coût réel par token délivré vaut environ quatre fois celui que vous aviez calculé à saturation. Le côté API de l'équation, lui, ne bouge pas d'un centime : vous avez consommé ce que vous avez consommé.

Les pics aggravent les choses au lieu de les arranger. Un serveur doit être dimensionné pour votre heure la plus chargée, et vous payez ce dimensionnement pendant toutes les heures creuses. Une API élastique au token inverse la logique : le pic coûte plus cher précisément quand il a lieu, et rien quand il n'a pas lieu.

Ce que le tarif horaire ne comprend pas

Les 2,80 € vous achètent une machine, pas un service. Avant de les comparer à un prix qui inclut un engagement de service, ajoutez :

• Le stockage et la sortie réseau, généralement facturés à part — et des poids de modèle, ça pèse des dizaines à des centaines de gigaoctets à déplacer.
• La redondance. Une machine, c'est un point de défaillance unique. Deux machines, c'est deux fois la facture pour les mêmes tokens.
• Le temps d'ingénierie. Déploiement, pile de service, mises à jour de pilotes et de CUDA, supervision, et quelqu'un de joignable quand ça s'arrête à 3 h du matin. C'est le coût qui n'apparaît jamais dans la comparaison, et c'est fréquemment le plus élevé.
• La diversité de modèles. Une machine sert le modèle qu'elle a chargé. Si votre produit route entre un petit modèle pour la classification, un modèle de code pour les diffs et un gros pour le raisonnement, cela fait plusieurs déploiements — ou des rechargements permanents, qui détruisent le taux d'utilisation sur lequel vous comptiez. Un catalogue d'API vous les donne tous derrière un seul endpoint et une seule clé.
• Le rythme des versions. Les poids ouverts bougent vite. Chaque montée de version est un redéploiement et une nouvelle campagne de validation, sur une infrastructure qui est la vôtre.

Quand l'auto-hébergement gagne vraiment

Rien de ce qui précède ne dit « jamais ». Cela dit : pour des raisons précises, à des volumes précis. L'auto-hébergement est le bon choix quand

• vous avez un volume soutenu et saturant sur un seul modèle — le cas où la division penche nettement de votre côté ;
• vous faites tourner des poids personnalisés ou affinés que personne ne sert ;
• le modèle dont vous avez besoin n'est présent dans aucun catalogue géré — de plus en plus fréquent pour les poids de pointe tout juste sortis ;
• vous avez une exigence qu'aucun fournisseur ne satisfait, qu'il s'agisse d'une contrainte juridictionnelle dure ou d'un objectif de latence et de localisation.

Ce que nous faisons nous-mêmes, et pourquoi

Nous faisons tourner cette même arithmétique, et elle ne penche pas toujours du côté qu'on attendrait d'une passerelle.

Pour les modèles matures, nous ne possédons pas de matériel : ils tournent sur des clouds gérés souverains — des fournisseurs sans contrôle capitalistique non-UE, ce qui est précisément ce qui les rend utilisables pour du travail régulé. Pour les modèles de pointe tout juste sortis qu'aucun catalogue géré souverain ne sert encore, nous louons bel et bien nos propres serveurs UE dédiés, parce qu'il n'existe aucune alternative qui préserve la garantie de juridiction. Et avant d'engager une machine qui facture 24 h/24, il nous arrive de servir un modèle via un endpoint américain au token, comme filtre de validation de la demande — étiqueté « accès rapide », jamais souverain, parce que la société qui l'exploite est américaine et donc atteignable au titre du CLOUD Act quelle que soit la région où elle opère. Cette distinction est juridique, pas géographique.

L'important, c'est que nous achetons la machine quand le volume le justifie, pas parce que l'auto-hébergement serait vertueux. C'est exactement le test que nous vous mettons entre les mains ici.

Comment trancher en quinze minutes

1. Sortez votre volume réel de tokens du mois dernier, entrée et sortie séparément. Pas votre prévision — vos logs.
2. Multipliez par le prix publié du modèle que vous utiliseriez. C'est votre facture d'API, exactement.
3. Dimensionnez la machine dont vous auriez réellement besoin — mémoire d'abord, débit ensuite — et multipliez son tarif horaire par 730.
4. Si la facture d'API est inférieure à la machine, arrêtez-vous là. Vous avez votre réponse, en quatre étapes.
5. Si elle est supérieure, divisez le seuil par 2 628 000 pour obtenir le débit soutenu en tokens par seconde qu'il faudrait tenir, puis demandez-vous honnêtement si votre profil de trafic le tient un dimanche à 3 h du matin.
6. Ajoutez les coûts cachés du côté machine — redondance, temps d'ingénierie, diversité de modèles — avant de conclure.

Si vous atterrissez du côté de l'API, l'étape suivante est modeste : notre comparatif modèle par modèle détaille à quoi chacun est bon, le catalogue liste chaque prix et chaque juridiction d'hébergement, et la référence API montre les deux lignes qu'il faut réellement changer. Sans abonnement — un solde prépayé dès 20 €, qui s'arrête à zéro.

FAQ