Self-host ou API : lequel est le moins cher ?
Louer un GPU paraît bon marché face à une facture au token - jusqu’à ce qu’on compte les heures d’inactivité. L’arithmétique qui tranche.
Louer un H100 à l’heure paraît bon marché face à une facture d’API au token - jusqu’à ce qu’on compte les heures où le GPU ne fait rien. Voici l’arithmétique qui tranche.
Une API ne facture que les tokens réellement envoyés et reçus. Un modèle auto-hébergé facture chaque seconde où la machine est allumée, qu’elle serve une requête ou qu’elle attende. La vraie question, c’est le taux d’utilisation : quelle fraction du temps le GPU travaille vraiment.
Le seuil de rentabilité, en une ligne
Prends le prix horaire du GPU, divise-le par les tokens/heure qu’il produit à ta taille de batch, et compare au prix au token de l’API.
self-host $/tok = (GPU $/h) ÷ (tokens/h × utilisation)
moins cher en self-host quand self-host $/tok < API $/tok
Avec des chiffres réels. Un H100 à 2,50 $/h servant un modèle 70B à 2,0M tokens de sortie par heure, tournant à 40 % d’utilisation :
| Coût GPU par heure | 2,50 $ |
| Tokens utiles par heure (40 %) | 800 000 |
| Self-host, par 1M tokens | 3,13 $ |
| Un 70B hébergé rapide, par 1M sortie | 0,79 $ |
À 40 % d’utilisation, l’API gagne largement. Le self-host ne passe devant qu’en gardant le GPU occupé la plupart du temps - environ 70 %+ pour ce modèle et ce prix - ou quand la résidence des données, la latence ou des poids fine-tunés rendent l’API impossible.
Le temps GPU inutilisé, c’est toute l’histoire du coût. Le reste est une erreur d’arrondi.
Deux coûts que la formule oublie, tous deux en faveur de l’API : le temps d’ingénierie pour faire tourner l’inférence de façon fiable, et la capacité payée mais jamais utilisée pendant les creux de trafic. Les GPU réservés baissent le tarif horaire mais relèvent la barre d’utilisation.
Fais tes propres calculs dans le calculateur self-host vs API →Les chiffres sont indicatifs. Vérifie les prix en vigueur sur le site du fournisseur avant de décider.