Ce que coûte un million de tokens, dans les deux sens.

La version courte

Presque toutes les comparaisons de ces deux options que vous lirez se résument à un seul chiffre — « l’auto-hébergement coûte dix fois moins cher », « l’API est moins chère jusqu’à ce que vous soyez énorme » — et c’est la même erreur dans les deux cas : citer un coût par token pour une machine qui n’est pas facturée au token. Un GPU loué a exactement un prix et il ne bouge pas : que vous génériez un milliard de tokens ce mois-ci ou aucun, la facture est identique. La question honnête n’est donc pas « combien coûte un token ici » mais « combien de tokens dois-je générer avant que le prix fixe ne batte le compteur ».

Ce chiffre est une division, et elle est effectuée ci-dessous à partir de nos propres prix et de notre propre modèle de débit — le même que celui qu’utilise le configurateur. Tout ce qui suit porte sur les deux facteurs qui déterminent si vous pouvez atteindre ce volume : le traitement par lots, et les heures pendant lesquelles vous laissez la machine inactive.

Le calcul

Quatre lignes. La troisième est celle qui mérite d’être écrite sur un tableau blanc ; la quatrième est celle que les gens sautent, et c’est ce qui transforme une estimation solide en une estimation fausse.

# 1. What the API charges. Linear in what you use, zero when you stop.
api_cost_per_month = output_tokens_per_month / 1e6 × api_price_per_million

# 2. What the machine charges. A constant. Tokens are free once you own the hours.
machine_cost_per_month = monthly_price

# 3. Set them equal. This is the break-even VOLUME, in output tokens per month.
break_even_tokens = monthly_price / api_price_per_million × 1e6

# 4. And the only question that matters: can the machine produce that many?
#    730 hours is the month we bill, so 2,628,000 seconds of it.
sustained_tokens_per_second = break_even_tokens / 2,628,000

La ligne 4 est un débit soutenu, pas un pic. Une machine qui atteint 600 tokens par seconde pendant une heure par jour et reste inactive les vingt-trois heures restantes a un débit soutenu de 25, et la facture ne fait aucune différence entre les deux.

Ce que coûte le flux unique

Commencez par le pire cas, car c’est le seul chiffre qui puisse être énoncé sans hypothèse : une requête à la fois, sans traitement par lots, la machine inactive le reste du temps. Chaque nœud ci-dessous fait tourner Llama 3.3 70B à 4-bit (AWQ, GPTQ), et le débit est notre propre estimation prudente — celle qui est bornée par la bande passante mémoire plutôt que mesurée un bon jour.

Lisez ce chiffre comme un plafond, jamais comme un devis. C’est ce que coûte un token si vous faites répondre la machine à une question à la fois et que vous la laissez inactive le reste du mois — la façon la moins efficace qui soit de posséder un GPU. Toute pile de service réelle fait mieux, et les deux prochaines sections expliquent de combien.

Le seuil de rentabilité, par palier

Prenez la ligne la moins chère ci-dessus — 2 × NVIDIA RTX 5090 à $692 par mois — et demandez-vous quel travail elle doit fournir pour battre chaque palier du marché des API.

La dernière colonne est tout l’article. Là où elle indique « déjà moins cher », un flux sans traitement par lots sur une machine $692 bat l’API : il n’y a rien à réfléchir. Là où elle affiche un multiple, la machine peut quand même gagner — mais seulement si vous la faites vraiment travailler, ce qui est l’objet de la section suivante.

Le traitement par lots est tout l’enjeu

Générer un token nécessite de lire une fois les poids actifs depuis la mémoire. Générer cent tokens pour cent requêtes différentes nécessite aussi de les lire une seule fois — les mêmes poids servent chaque requête du lot. C’est pourquoi une pile de service avec traitement par lots continu produit plusieurs fois plus de tokens par seconde qu’un flux unique sur un matériel identique, et pourquoi le rapport de la dernière colonne de ce tableau est atteignable.

Conséquence pratique : traitez le multiple du tableau de seuil de rentabilité comme un objectif de débit, pas un nombre d’utilisateurs. Un objectif de dix fois le flux unique ne signifie pas « dix utilisateurs » ; cela signifie que le serveur doit atteindre en moyenne dix fois son débit sans traitement par lots, ce qui exige généralement plutôt plus de dix requêtes simultanées et plutôt moins d’une centaine. Mesurez-le sur la machine avant de vous engager sur un chiffre — c’est un seul benchmark, et il tranche le débat.

Les heures inactives que vous payez quand même

Tout ce qui précède supposait que la charge était répartie uniformément sur le mois. Ce n’est jamais le cas. Une machine louée au mois est payée le dimanche à 4 h 00, et les tokens que vous n’avez pas générés à ce moment-là ne se reportent pas. Divisez la semaine que vous servez réellement par la semaine que vous payez réellement :

La troisième ligne, c’est là que vivent la plupart des outils internes, et elle multiplie discrètement votre seuil de rentabilité par plus de quatre. C’est la raison la plus fréquente pour laquelle une estimation d’auto-hébergement se révèle fausse — pas le prix du token, pas le matériel, mais l’hypothèse qu’une semaine de travail est une semaine entière.

Pourquoi votre prompt est presque gratuit

Une asymétrie joue fortement en faveur du fait de posséder la machine, et aucune comparaison de prix par token ne la montre. Une API vous facture les tokens d’entrée — généralement le quart au tiers du prix de sortie, par token. Sur votre propre GPU, les tokens d’entrée sont traités pendant la passe de prefill, qui traite l’intégralité du prompt en parallèle et qui est limitée par le calcul plutôt que par la bande passante mémoire. Le prefill tourne à un débit de tokens par seconde supérieur d’un ordre de grandeur à celui de la génération.

Ce que le calcul laisse de côté

Quatre choses qui n’apparaissent jamais dans un tableau de coût par token, et qui tranchent la question au moins aussi souvent que les chiffres.

De quel côté vous êtes

Dans l’ordre, et arrêtez-vous au premier qui vous correspond.

1. Vous avez besoin de la qualité d’un modèle propriétaire de pointe. Alors cet article ne s’applique pas : personne ne vous loue ces poids. Utilisez l’API, et reconsidérez la question quand un modèle ouvert comblera l’écart sur votre tâche spécifique.
2. Votre volume est faible, ou vous ne le connaissez pas encore. Utilisez l’API. C’est le moyen le moins cher de découvrir à quoi ressemble réellement votre trafic, et le compteur est un instrument de mesure parfaitement adapté.
3. Votre trafic est irrégulier et tolère une file d’attente. Utilisez l’API, ou répartissez : votre propre machine pour la charge de base constante, un point d’accès hébergé pour les pics. Rien n’oblige à trancher entièrement dans un sens.
4. Vous soutenez un volume réel, traité par lots, sur un modèle à poids ouverts. C’est le cas où le matériel l’emporte, et il l’emporte largement — le prix fixe cesse de bouger pendant que le compteur continue de tourner. Vérifiez votre propre chiffre dans le tableau ci-dessus avant d’y croire.
5. Les prompts sont sensibles, le modèle ne doit pas changer, ou la facture doit être connue à l’avance. Alors le calcul n’est qu’une formalité. Louez la machine qui héberge votre modèle, et payez-la sans dire à quiconque qui vous êtes.

Quelle que soit la ligne où vous vous êtes arrêté, le chiffre à vérifier est celui du tableau de seuil de rentabilité pour votre modèle et votre volume. Le configurateur indique, pour chaque nœud que nous louons, si votre modèle tient sur une seule carte, doit être réparti, et quelle est l’estimation de débit — ce qui représente toutes les données dont ce calcul a besoin. Si vous hésitez encore entre la location au mois et la facturation à l’heure, c’est un autre seuil de rentabilité, et il est également détaillé.