GPU VPS ou API au token : où est le seuil ?

À quel niveau se situe réellement le seuil de rentabilité

Un GPU VPS devient plus avantageux qu’une facturation API au token lorsque le coût mensuel fixe, divisé par le nombre de tokens de sortie que vous générez réellement ce mois-là, passe sous le prix facturé par l’API pour ces mêmes tokens. Le loyer ne change pas. La facture API varie à chaque requête. La réponse est donc toujours un volume mensuel, jamais un simple oui ou non.

Prenons un GPU VPS de gamme intermédiaire à $0.50 de l’heure, soit $365 pour un mois de 730 heures. Face à l’API d’un modèle de pointe, le seuil de rentabilité est atteint à 24.3 millions de tokens de sortie par mois. Face à un petit modèle commercial, il est de 73 millions. Face à un modèle hosted open-weight de même taille, vous n’atteignez jamais le seuil de rentabilité, car une seule carte ne peut pas produire suffisamment de tokens en un mois pour atteindre le point de croisement.

Les études publiées sur le seuil de rentabilité ne répondent pas à cette question. Deux études publiées plus tôt en 2026 situent le point de croisement autour de 72 % d’utilisation soutenue sur un H200, et entre 22 % et 48 % de duty cycle sur un MI300X. Toutes deux comparent les coûts au produit serverless du même fournisseur, et toutes deux évaluent des accélérateurs dont le coût horaire dépasse le budget mensuel de la plupart des lecteurs de ce guide. Le calcul est identique. La suite le reprend pour une seule carte, un seul modèle open de 7B à 30B, et une facturation API metered classique.

Chaque nombre ci-dessous est une donnée d’entrée, pas un résultat. Remplacez-les tous par vos propres valeurs.

La formule, pour remplacer les valeurs par les vôtres

cost_per_million = (hourly_rate * 1000000) / (tokens_per_second * 3600 * duty_cycle)

breakeven_millions_per_month = (hourly_rate * hours_per_month) / api_price_per_million

capacity_millions_per_month = (tokens_per_second * 3600 * hours_per_month) / 1000000

required_duty_cycle = breakeven_millions_per_month / capacity_millions_per_month

Quatre valeurs sont nécessaires. Vous pouvez toutes les mesurer ou les rechercher.

• hourly_rate correspond au coût horaire du GPU VPS, y compris pendant les heures où il reste inactif. Si vous payez au mois, divisez le prix mensuel par 730.
• tokens_per_second correspond au débit de sortie global que votre serveur maintient avec votre niveau réel de concurrence. Il ne s’agit pas de la valeur pour un flux unique affichée dans le tableau du fournisseur.
• duty_cycle correspond à la fraction du mois pendant laquelle le GPU génère des tokens. Une machine louée tout le mois et utilisée deux heures par jour atteint 8.3 %.
• api_price_per_million correspond au tarif mesuré auquel vous comparez le serveur, pour les tokens de sortie.

Dans l’exemple, les tokens de sortie sont facturés des deux côtés, car ils représentent l’essentiel du coût pour les conversations et le travail avec des agents. Si vos prompts sont longs, ajoutez les tokens d’entrée des deux côtés. Du côté de l’API, ils apparaissent sur une ligne distincte de la facture. Sur votre propre machine, le prefill consomme du temps GPU ; il est donc déjà pris en compte dans la valeur tokens_per_second mesurée, qui est plus faible.

Comment mesurer les tokens par seconde avant de faire confiance aux calculs

Tout ce qui précède repose sur une seule valeur mesurée. Si vous vous trompez d’un facteur trois, le résultat sera faux d’un facteur trois. Mesurez cette valeur sur la carte que vous louez, avec le modèle et la quantification que vous utiliserez réellement.

Ollama fournit la valeur pour un flux unique avec une seule commande :

ollama run qwen3:8b --verbose "Write 400 words about disk latency."

--verbose affiche un bloc de mesures après la réponse. La ligne importante est eval rate, en tokens par seconde. Elle compte uniquement la génération. prompt eval rate correspond à la vitesse de prefill et est normalement bien plus élevée. Vos valeurs seront différentes de celles-ci :

eval count:       412 token(s)
eval duration:    9.612s
eval rate:        42.86 tokens/s

Le flux unique n’est pas la bonne valeur pour un modèle de coûts, car il mesure une requête à la fois sur une carte capable d’en traiter plusieurs simultanément. Pour obtenir la valeur agrégée, servez le modèle avec vLLM et consultez le débit que le serveur indique lui-même :

pip install vllm
vllm serve Qwen/Qwen3-8B --max-model-len 8192

Pendant que des requêtes sont en cours de traitement, le serveur consigne une ligne d’état à chaque intervalle de reporting. Les champs exacts changent selon les versions de vLLM. Consultez donc les vôtres plutôt que les miens :

Avg prompt throughput: 812.4 tokens/s, Avg generation throughput: 396.1 tokens/s, Running: 16 reqs, Waiting: 0 reqs, GPU KV cache usage: 21.7%

Avg generation throughput est la valeur utilisée par la formule. Elle augmente lorsque vous ajoutez des requêtes concurrentes, jusqu’à ce que le KV cache (cache clé-valeur, l’état d’attention conservé en VRAM par vLLM pour chaque requête) soit plein. Elle cesse alors d’augmenter. Si vous dépassez cette limite, les requêtes sont mises en file d’attente au lieu d’être traitées plus rapidement. Vous le verrez avec l’augmentation du compteur Waiting. vLLM fournit également un générateur de charge, vllm bench serve. Ses flags changent selon les versions. Exécutez donc vllm bench serve --help sur la version que vous avez installée au lieu de copier une commande trouvée dans un article de blog.

Surveillez la carte pendant le test :

nvidia-smi --query-gpu=utilization.gpu,memory.used,power.draw --format=csv -l 5

Si utilization.gpu reste proche de 100 % pendant la génération, vous êtes limité par le débit et la valeur mesurée correspond au plafond réel. S’il reste faible, un autre élément constitue la limite : trop peu de requêtes concurrentes, un client lent ou un modèle qui ne tient pas en VRAM et dont une partie est déportée vers la RAM système. Ollama et vLLM font ici des compromis très différents, et l’écart entre eux sur une même carte est suffisamment important pour déplacer votre seuil de rentabilité d’un facteur de plusieurs fois.

À quoi ressemble la facture sur un mois

L’exemple détaillé porte sur un VPS GPU de 24 GB à 0.50 dollar par heure, avec un modèle open de 8B servi par vLLM, mesuré à 400 tokens de sortie par seconde au total avec 16 requêtes concurrentes. La location reste fixe, que vous utilisiez ou non la carte. À ce débit, la capacité atteint 1,051 million de tokens de sortie par mois. C’est la production de la carte si elle ne s’arrête jamais.

[
  {
    "output_tokens_millions": 5,
    "gpu_vps_usd": 365,
    "open_api_usd": 1,
    "small_api_usd": 25,
    "frontier_api_usd": 75
  },
  {
    "output_tokens_millions": 10,
    "gpu_vps_usd": 365,
    "open_api_usd": 2,
    "small_api_usd": 50,
    "frontier_api_usd": 150
  },
  {
    "output_tokens_millions": 25,
    "gpu_vps_usd": 365,
    "open_api_usd": 5,
    "small_api_usd": 125,
    "frontier_api_usd": 375
  },
  {
    "output_tokens_millions": 50,
    "gpu_vps_usd": 365,
    "open_api_usd": 10,
    "small_api_usd": 250,
    "frontier_api_usd": 750
  },
  {
    "output_tokens_millions": 100,
    "gpu_vps_usd": 365,
    "open_api_usd": 20,
    "small_api_usd": 500,
    "frontier_api_usd": 1500
  },
  {
    "output_tokens_millions": 250,
    "gpu_vps_usd": 365,
    "open_api_usd": 50,
    "small_api_usd": 1250,
    "frontier_api_usd": 3750
  },
  {
    "output_tokens_millions": 500,
    "gpu_vps_usd": 365,
    "open_api_usd": 100,
    "small_api_usd": 2500,
    "frontier_api_usd": 7500
  },
  {
    "output_tokens_millions": 1000,
    "gpu_vps_usd": 365,
    "open_api_usd": 200,
    "small_api_usd": 5000,
    "frontier_api_usd": 15000
  }
]

Le coût du GPU reste constant à 365 dollars, car la location ne dépend pas de l’utilisation de la carte. Chaque ligne d’API est une droite qui passe par zéro. Chaque paire de lignes se croise une seule fois.

À 25 millions de tokens de sortie par mois, l’API frontier facture 375 dollars. Les deux options sont donc à moins de dix dollars l’une de l’autre. À 50 millions, le petit modèle commercial facture 250 dollars et reste l’option la moins chère. À 1000 millions de tokens de sortie, ce qui exige que la carte soit occupée pendant 95% du mois, l’API hébergeant le modèle open-weight facture 200 dollars, contre le même coût de location. La carte coûte presque deux fois plus cher exactement au volume où elle travaille le plus.

Ce dernier résultat surprend, mais il n’est pas dû au hasard. Un endpoint open-weight hébergé est une flotte de GPU utilisée à un taux élevé. Son prix reste donc proche du coût d’une carte saturée. Vous ne pouvez pas faire mieux qu’une flotte saturée en louant une seule carte et en l’utilisant à moins de sa pleine capacité. En revanche, vous pouvez faire mieux que les tarifs frontier, qui dépendent des capacités du modèle plutôt que du temps d’utilisation du matériel.

Coût par million de tokens de sortie selon le taux d’utilisation

Le volume et le taux d’utilisation décrivent le même fait sous deux angles. La location vous donne accès à des heures d’utilisation. Les heures d’inactivité ne produisent rien, mais coûtent toujours de l’argent.

[
  {
    "label": "100% duty",
    "self_host_usd_per_million": "0.35",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "50% duty",
    "self_host_usd_per_million": "0.69",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "25% duty",
    "self_host_usd_per_million": "1.39",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "10% duty",
    "self_host_usd_per_million": "3.47",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "5% duty",
    "self_host_usd_per_million": "6.94",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "2% duty",
    "self_host_usd_per_million": "17.36",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  }
]

Les trois colonnes d’API correspondent à des tarifs catalogue généralement publiés en août 2026 : 0.20 dollars par million de tokens de sortie pour un modèle open-weight 8B hébergé, 5.00 dollars pour un petit modèle commercial et 15.00 dollars pour un modèle frontier. Ces chiffres sont donnés à titre indicatif. Consultez la page tarifaire du jour avant de prendre une décision. Si votre comparaison porte sur une offre mensuelle fixe plutôt que sur des tokens facturés à l’usage, le calcul de l’abonnement fonctionne différemment et le point de croisement se déplace encore.

Faites fonctionner la carte à pleine charge : un million de tokens de sortie coûte 0.35 dollars, ce qui est réellement peu coûteux. Avec un taux d’utilisation de 10 %, le même million coûte 3.47 dollars. Avec un taux d’utilisation de 2 %, il coûte 17.36 dollars. Ce montant n’est pas comparable aux 0.20 dollars facturés par une API hébergeant un modèle open-weight pour une sortie identique.

En dessous d’environ 10 % de taux d’utilisation, louer un GPU est le choix le plus coûteux. Vous payez 3.47 dollars par million de tokens pour une sortie vendue 0.20 dollars. La différence vous achète la confidentialité et une facture stable. Ces avantages peuvent avoir une réelle valeur. Ils ne réduisent pas le prix : ne les présentez donc pas comme un gain financier.

Le volume d’équilibre pour chaque niveau d’API

[
  {
    "label": "Hosted open 8B API",
    "breakeven_tokens_millions": 1825,
    "required_duty_pct": 174
  },
  {
    "label": "Small commercial model",
    "breakeven_tokens_millions": 73,
    "required_duty_pct": 6.9
  },
  {
    "label": "Frontier model",
    "breakeven_tokens_millions": 24.3,
    "required_duty_pct": 2.3
  }
]

Par rapport au niveau frontier, il vous faut 24.3 millions de tokens de sortie par mois, soit seulement 2.3% de la capacité de la carte. La barre est donc basse. Une petite équipe qui exécute des coding agents pendant les heures de travail l’atteint sans difficulté.

Par rapport au niveau commercial small, il vous faut 73 millions de tokens par mois, soit un taux d’utilisation de 6.9%. Par rapport au niveau hosted open-weight, le taux d’utilisation requis est de 174%. Toute valeur supérieure à 100% est impossible par définition : la carte devrait fonctionner plus d’heures que le mois n’en compte. Une seule carte mid-range proposée à ce tarif horaire ne peut pas être compétitive dans cette comparaison. Les seuls moyens de modifier le résultat sont donc d’utiliser une carte moins chère, une carte plus rapide ou une raison qui ne soit pas liée au prix.

Ce que la formule ne montre pas

La formule chiffre les heures GPU et les tokens. Plusieurs coûts réels n’y figurent pas.

Démarrages à froid. Un modèle 8B en poids 16-bit occupe environ 16 GB, et son chargement depuis le disque local vers la VRAM prend plusieurs dizaines de secondes. Si vous arrêtez la machine entre deux utilisations pour réduire la facture, vous devez attendre ce délai à la première requête. Si vous la laissez fonctionner pour éviter cette attente, son taux d’utilisation s’effondre, ce qui augmente le coût par token. C’est précisément pour gérer ce compromis que l’inférence serverless existe.

Stockage et téléchargement. Les poids occupent beaucoup d’espace. Un modèle 8B en 16-bit fait environ 16 GB, un modèle 30B quantifié en 4-bit environ 18 GB, et un modèle 30B en 16-bit ne tient pas du tout sur une carte de 24 GB. La limite devient rapidement évidente pour les modèles haut de gamme : exécuter un modèle open à un billion de paramètres comme Kimi K3 signifie que les poids seuls dépassent la capacité de toute carte unique que vous pouvez louer à l’heure. Vous payez ce disque chaque mois et vous payez aussi le temps nécessaire à chaque reconstruction. Exécutez du -sh ~/.cache/huggingface/hub après une semaine d’expérimentations. Il grossit plus vite que prévu, car chaque quantification testée une seule fois y est toujours présente.

Votre temps. Les versions des drivers et de CUDA, les erreurs out-of-memory avec une longueur de contexte qui fonctionnait encore hier, ou une mise à jour du modèle qui modifie le chat template : rien de tout cela n’apparaît dans un coût par token, mais tout cela se traduit par des soirées consacrées à l’administration. Si vous n’avez jamais dimensionné ce type de machine, ce que fournit réellement un GPU VPS mérite d’être lu avant de vous engager pour un mois de location.

L’écart de qualité. C’est le coût caché le plus important et le plus difficile à chiffrer. Un modèle open 8B n’est pas un modèle de pointe. S’il nécessite trois tentatives là où le modèle de pointe n’en nécessite qu’une, son prix réel par réponse utile est trois fois supérieur à la valeur indiquée dans le tableau, et il peut malgré tout échouer sur la tâche. Comparez les résultats sur vos propres prompts avant de comparer les prix. Pour les workloads d’agents, la réponse habituelle consiste à router les requêtes selon leur difficulté et à réserver les tokens locaux peu coûteux au traitement en volume. C’est l’essentiel de ce que recouvre la maîtrise des dépenses des agents sur un VPS.

La facturation que vous avez oubliée. Une instance GPU facturée à l’heure que vous avez arrêtée continue souvent à facturer son stockage attaché et son adresse IP réservée. Consultez la facture, pas la page des tarifs.

Quand l’auto-hébergement s’impose pour une autre raison que le prix

Quatre cas où le calcul n’est pas le facteur déterminant.

• Des données qui ne peuvent pas sortir de votre contrôle. Si une règle de conformité interdit d’envoyer le texte à un tiers, le prix par token n’est pas la question posée.
• Un volume élevé et régulier selon un planning défini. Une tâche de classification par lots qui s’exécute six heures chaque nuit a par construction un taux d’utilisation de 25 %, sans jamais vous réserver de mauvaise surprise sur la facture.
• Les limites de débit. Votre propre carte graphique n’a qu’une seule file d’attente, qui vous appartient.
• Un modèle qu’aucune API ne propose. Si vous avez besoin d’un fine-tune spécifique, il n’y a rien à comparer.

Si vous voulez d’abord tester la version économique, exécuter un petit modèle sur un VPS avec Ollama prend un après-midi, et dimensionner un modèle open source en fonction de la carte graphique que vous loueriez vous indique le GPU dont vous avez réellement besoin. Faites les mesures à cette étape avant de vous engager pour un mois de location de GPU.

FAQ

À partir de quel volume mensuel de tokens un GPU VPS devient-il moins cher qu’une API ?

Divisez le coût mensuel du GPU par le prix de l’API par million de tokens de sortie. Une carte louée 365 $ par mois, comparée à une API frontier à 15.00 dollars par million, atteint son seuil de rentabilité à 24.3 millions de tokens de sortie par mois. Avec un petit modèle commercial à 5.00 dollars, le seuil est de 73 millions. Avec un modèle open-weight hébergé à 0.20 dollars, une carte de milieu de gamme ne peut pas générer assez de tokens en un mois pour atteindre le seuil de rentabilité.

Pourquoi une API open-weight hébergée coûte-t-elle moins cher que mon propre GPU ?

Parce que son prix est proche du coût d’un GPU utilisé à pleine charge, contrairement à votre carte. Un fournisseur qui traite des milliers de requêtes simultanées maintient son parc proche de la saturation. Il peut donc vendre les tokens à un prix proche de leur coût marginal de production. Votre carte reste inactive la majeure partie de la journée, mais vous payez ces heures d’inactivité. Avec un duty cycle de 10 %, votre coût est de 3.47 dollars par million de tokens de sortie, contre 0.20 dollars pour ce fournisseur.

Dois-je compter les tokens d’entrée et les tokens de sortie ?

Comptez-les si vos prompts sont longs. La comparaison présentée ici utilise uniquement les tokens de sortie, qui constituent le poste principal pour le chat et les agents. Ajouter les tokens d’entrée modifie les deux côtés. Pour l’API, ils apparaissent sur une ligne distincte et moins chère de la facture. Sur votre propre carte, le prefill consomme du temps GPU. Son coût est donc déjà inclus dans le débit global de tokens par seconde que vous avez mesuré. Effectuez les mesures avec vos longueurs de prompts réelles pour conserver une comparaison cohérente.

Comment mesurer le nombre de tokens par seconde requis par la formule ?

Servez le modèle dans les conditions prévues, puis relevez le débit global de génération avec une concurrence réelle. Avec Ollama, ollama run <model> --verbose affiche un eval rate en tokens par seconde. Cette valeur correspond toutefois à un flux unique et sous-estime le débit d’un serveur traitant des requêtes par lots. Avec vLLM, le serveur en cours d’exécution journalise Avg generation throughput lorsque des requêtes sont en cours de traitement. C’est cette valeur qu’il faut utiliser. Surveillez nvidia-smi en même temps. Si l’utilisation du GPU n’est pas proche de 100 % pendant la génération, vous n’avez pas encore atteint le débit maximal.

Un GPU VPS vaut-il la peine d’être loué avec une utilisation inférieure à 10 % ?

Pas pour réduire le coût. Avec un duty cycle de 10 %, vous payez 3.47 dollars par million de tokens de sortie. Avec 2 %, vous payez 17.36 dollars. Ces deux coûts sont supérieurs à ceux de toutes les API facturées à l’usage de cette comparaison, à l’exception du niveau frontier. Louez un GPU VPS sous ce seuil uniquement si vous payez pour la confidentialité ou pour utiliser un modèle qu’aucune API ne propose.