Coût des LLM auto-hébergés par million de tokens : un modèle reproductible des coûts GPU

Coût des LLM auto-hébergés par million de tokens : un modèle reproductible des coûts GPU

La méthode fiable pour calculer le coût des LLM auto-hébergés par million de tokens consiste à diviser le coût total de serving par les tokens que votre charge de travail accepte réellement — et non par le débit de pointe annoncé d'un GPU.

Cette distinction est importante. Un GPU peut afficher de bons résultats dans les benchmarks, tout en étant coûteux en production lorsqu'il reste inactif pendant du temps payé, traite des prompts inhabituellement longs, réessaie des requêtes ayant échoué ou génère une sortie que votre produit rejette. Ce guide fournit un modèle reproductible pour le coût des LLM auto-hébergés par million de tokens, une feuille de calcul, un exemple détaillé et une méthode équitable pour comparer un endpoint autogéré à une API managée.

Mis à jour le 16 octobre 2026. Tous les montants en dollars et les débits ci-dessous sont des valeurs illustratives, et non des tarifs de fournisseurs ni des revendications de performance.

La formule du coût des LLM auto-hébergés par million de tokens

Pour une vue en tokens de sortie, utilisez :

coût par 1 M de tokens de sortie acceptés =
  coût horaire total de serving
  / (tokens de sortie/seconde pendant la fenêtre active × 3,600 × utilisation du temps payé × taux de réussite × taux d’acceptation)
  × 1,000,000

Où :

Le dénominateur est l'élément clé. Le coût des LLM auto-hébergés par million de tokens doit être un coût par unité utile, et non un coût par benchmark GPU.

La règle de non-double comptage

Utilisez l'une de ces deux méthodes de mesure :

1. Mesurez le débit pendant la fenêtre active, puis multipliez-le par l'utilisation du temps payé.
2. Mesurez les tokens acceptés sur l'ensemble de l'intervalle payé, puis définissez l'utilisation sur 1, car le temps d'inactivité est déjà inclus dans l'observation.

Ne faites pas les deux. Appliquer un facteur d'utilisation à un débit en temps réel qui inclut déjà le temps d'inactivité fait paraître le coût d'inférence LLM par token plus élevé qu'il ne l'est. Omettre l'utilisation d'un benchmark en fenêtre active le fait paraître meilleur qu'il ne l'est.

Une feuille de calcul copiable du coût GPU par million de tokens

Ajoutez une ligne à votre feuille de calcul pour chaque modèle, topologie matérielle, région et forme de charge de travail. Ne mélangez pas un benchmark de chat court avec une charge de travail de production à contexte long.

La feuille de calcul rend le calcul du coût des LLM auto-hébergés par million de tokens vérifiable : un autre opérateur doit pouvoir remplacer les entrées, relancer la fenêtre de mesure et reproduire le résultat.

Il s'agit d'un calcul illustratif, et non d'une grille tarifaire pour un GPU donné. Remplacer les cinq entrées par des valeurs mesurées produit votre propre coût GPU par million de tokens.

Exemple détaillé : pourquoi l'utilisation change la réponse

Maintenez constants le coût horaire total hypothétique de l'endpoint, de $4.07, et ses 900 tokens de sortie/seconde pendant la fenêtre active. De faibles changements dans les entrées modifient fortement le coût unitaire.

La leçon n’est pas d’acheter un accélérateur en particulier. La leçon est que la tarification des LLM auto-hébergés est un modèle fondé sur les opérations et le débit. Un coût horaire de nœud plus élevé peut produire un coût inférieur par sortie acceptée s’il dispose de suffisamment de mémoire, de marge pour le batching et de demande pour maintenir davantage de travail utile. Un tarif horaire plus bas peut devenir moins avantageux lorsque la capacité inactive et les nouvelles tentatives entrent dans le dénominateur.

Séparez le préremplissage du décodage avant l’évaluation comparative

Le serving de LLM n’est pas une charge de travail homogène. L’inférence comporte une phase de traitement du contexte (préremplissage) et une phase de génération (décodage) ; le guide TensorRT-LLM de NVIDIA les traite explicitement comme des phases distinctes et souligne l’importance d’un réglage propre à la charge de travail. Consultez le guide de réglage des performances de TensorRT-LLM avant de considérer un chiffre phare de tokens par seconde comme représentatif.

• Les prompts longs, le contexte de récupération et les pièces jointes volumineuses sollicitent le préremplissage et le cache KV.
• Les réponses longues, la génération de code et le raisonnement des agents sollicitent la capacité de décodage et le temps par token de sortie.
• Une forte concurrence fait du comportement de l’ordonnanceur, du batching, de la résidence en cache et de la marge mémoire des éléments du modèle de prix.

Enregistrez séparément les distributions des prompts et des sorties. Pour un assistant fortement axé sur la récupération avec 20,000 tokens d’entrée et 300 tokens de sortie, une analyse économique limitée aux sorties peut manquer le véritable goulot d’étranglement. Pour un flux de travail de codage avec 2,000 tokens d’entrée et 4,000 tokens de sortie, le décodage peut dominer.

Pour une comparaison rigoureuse du coût des LLM auto-hébergés par million de tokens, conservez au moins ces trois vues :

Mesurez le dénominateur à partir de la télémétrie de production

Ne déduisez pas le débit accepté à partir d’une spécification matérielle. La pile de serving doit exporter les données nécessaires pour rendre le calcul reproductible.

Par exemple, vLLM documente des métriques Prometheus pour les tokens de prompt, les tokens générés, les complétions de requêtes, les rejets à l’admission, le temps en file d’attente, le temps de préremplissage, le temps de décodage, l’utilisation du cache KV, le délai avant le premier token et la latence par token de sortie. Elles suffisent pour constituer un relevé de mesures plutôt que de deviner à partir d’un benchmark. La référence des métriques de vLLM répertorie les noms et significations actuels des métriques.

Capturez cet enregistrement pour chaque exécution :

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

La télémétrie matérielle est utile, mais elle constitue un outil de diagnostic — pas un dénominateur de coût unitaire. La documentation de profilage DCGM de NVIDIA indique que l’activité est une moyenne sur un intervalle et doit être corrélée au débit d’une charge de travail représentative. Utilisez les métriques de profilage DCGM pour déterminer si le calcul, la bande passante mémoire ou le comportement de l’interconnexion contraint l’exécution ; ne remplacez pas l’utilisation du temps payé par un unique pourcentage d’utilisation du GPU.

Construisez le numérateur entièrement chargé

Le prix de location des GPU est une donnée d’entrée, pas la réponse. Pour calculer équitablement le coût de serving des LLM, incluez les coûts de capacité et d’exploitation requis pour la même fenêtre de mesure.

Pour un pilote, indiquez deux chiffres :

Coût GPU uniquement par 1 M de tokens
Coût complet par 1 M de tokens acceptés

L'écart n'est pas une erreur ; il correspond au coût d'exploitation du service auto-hébergé. Il rend la décision de tarification des LLM auto-hébergés vérifiable.

Inclure les nouvelles tentatives et les sorties rejetées

Les tokens générés ne sont pas automatiquement des tokens utiles. Une requête peut consommer de la capacité de préremplissage et de décodage partiel avant d'expirer, de produire du JSON non valide, d'échouer lors d'un appel d'outil, d'enfreindre une règle de politique ou de ne pas atteindre un seuil de qualité.

Utilisez un ajustement d'acceptation que votre équipe produit peut reproduire :

tokens de sortie acceptés =
  tokens de sortie générés
  × taux de réussite d'exécution
  × taux d'acceptation produit

Si l'acceptation est mesurée au niveau de la requête, consignez la règle exacte : version de l'évaluateur, ensemble d'échantillonnage, validateur de schéma, protocole de revue humaine ou événement de réussite de tâche. Modifier la règle sans la versionner rend toute tendance de coût dénuée de sens.

C'est aussi pourquoi un coût d'inférence LLM brut par token peut être trompeur. Une configuration qui gagne 30 % de débit mais diminue le taux de réussite des tâches acceptées peut coûter davantage au niveau du produit.

Comparer l'auto-hébergement à une API gérée avec la même unité

L'auto-hébergement achète de la capacité. Une API gérée achète de l'usage. Ils ne deviennent comparables que lorsque le numérateur et le dénominateur correspondent.

Utilisez cette vérification du débit de seuil de rentabilité lorsque la référence API est exprimée dans la même unité :

tokens de sortie requis par seconde pendant la fenêtre active =
  coût horaire complet du service × 1 000 000
  / (coût de l'API gérée par 1 M de tokens de sortie acceptés × 3 600 × utilisation × taux de réussite × taux d'acceptation)

Avant de décider, alignez ces paramètres sur les deux approches :

• Même modèle ou modèle explicitement évalué comme équivalent en qualité.
• Même distribution des longueurs de prompts et de sorties.
• Même SLO de latence et même profil de concurrence.
• Mêmes règles de nouvelle tentative, de repli et d'acceptation.
• Même traitement des accès au cache, des échecs d'outils et du travail annulé.

Si le contrôle direct des GPU, des poids personnalisés, un placement strict ou une pile de kernels spécialisée sont des exigences, l'auto-hébergement peut rester la bonne réponse même au-dessus de la référence gérée. Si le trafic est faible ou irrégulier, si les modèles changent fréquemment ou si l'équipe ne souhaite pas exploiter une infrastructure d'inférence, une API tarifée à l'usage peut absorber le risque d'utilisation.

Pour une comparaison d'achat plus large, consultez le guide GPU cloud vs. model API de Flatkey et le guide des prix de location de GPU. Lorsque le contrôle direct des GPU n'est pas requis, une solution gérée constitue une référence utile : Flatkey fournit une API unifiée de modèles et d'outils avec un solde unique, afin que les équipes puissent comparer une approche gérée à leur calcul auto-hébergé sans maintenir des clés de fournisseurs distinctes. Créez une référence d'API Flatkey avec le même jeu de tests et la même règle d'acceptation.

Un test d'approvisionnement en sept étapes

Utilisez ce cadre de coût des LLM auto-hébergés par million de tokens comme un document d'approvisionnement, et non comme une simple référence d'ingénierie. Il doit montrer précisément quelles hypothèses de charge de travail, de capacité et de qualité ont modifié le résultat.

1. Définissez l'unité : token d'entrée, token de sortie, token combiné, réponse acceptée ou tâche acceptée.
2. Mesurez le débit pendant la fenêtre active avec un trafic représentatif de la production, et non avec un seul prompt synthétique.
3. Mesurez l'utilisation pendant le temps payé sur chaque réplique payante et nœud de réserve chaude.
4. Ajoutez tous les coûts d'exploitation au numérateur horaire.
5. Versionnez les règles de réussite et d'acceptation, puis calculez la sortie acceptée.
6. Exécutez la même charge de travail via une référence d'API gérée.
7. Examinez conjointement le coût, la latence p95, la fiabilité, la qualité et l'effort d'ingénierie avant de réserver de la capacité.

Erreurs courantes dans un modèle de coût des LLM auto-hébergés

Utiliser le débit maximal de benchmark. Le maximum est utile pour comparer une configuration contrôlée. Ce n'est pas le débit attendu de votre mix de production.

Confondre l'utilisation des GPU avec l'utilisation de capacité. Un GPU très sollicité peut tout de même être rattaché à un endpoint surdimensionné pour la demande payante. Utilisez l'utilisation pendant le temps payé pour l'économie unitaire et la télémétrie matérielle pour en diagnostiquer la cause.

Appliquer l'utilisation deux fois. Choisissez le débit pendant la fenêtre active plus l'utilisation, ou le débit en temps réel qui inclut déjà le temps d'inactivité.

Ignorer les tokens de prompt. Un contexte long augmente la pression sur le préremplissage et le cache KV, même lorsque le produit facture principalement la sortie.

Considérer que chaque token généré est accepté. Les nouvelles tentatives, les arguments d’outils invalides, les échecs de schéma et les rejets pour cause de qualité représentent du travail facturé.

Comparer uniquement une facture GPU au prix catalogue d’une API. L’ingénierie, le support, le stockage, le réseau, l’observabilité et la capacité maintenue à chaud doivent figurer dans le même calcul.

Pour une décision complète (à partir de quand l’auto-hébergement est rentable, le dimensionnement de la mémoire GPU, les outils et une configuration serveur étape par étape), consultez notre guide des LLM auto-hébergés.

Questions fréquentes

Comment calculer le coût d’un LLM auto-hébergé par million de tokens ?

Divisez le coût horaire complet du service par le nombre de tokens acceptés par heure facturée, puis multipliez par 1 000 000. Utilisez un débit mesuré représentatif de la production, le taux d’utilisation du temps facturé, le taux de réussite et le taux d’acceptation — et non le pic théorique du GPU.

Le coût GPU par million de tokens est-il identique au coût d’inférence d’un LLM par token ?

Le coût GPU par million de tokens peut être une mesure d’infrastructure limitée au GPU. Le coût d’inférence d’un LLM par token doit inclure le numérateur opérationnel pertinent et un dénominateur clairement défini. Pour une décision produit, le coût par réponse ou tâche acceptée est souvent une mesure complémentaire plus sûre.

Dois-je utiliser les tokens de sortie ou le total des tokens ?

Utilisez les deux lorsque les coûts des prompts et des sorties présentent des goulots d’étranglement différents. Les tokens de sortie sont faciles à comparer pour les charges de travail génératives ; les tokens totaux ou pondérés représentent mieux les charges de travail de récupération à contexte long. Conservez une unité identique lorsque vous comparez l’auto-hébergement à une API.

Quand l’auto-hébergement permet-il d’économiser de l’argent ?

Il est plus susceptible de permettre des économies lorsque la demande est stable, que la capacité reste bien utilisée, que le modèle et le déploiement sont stables, et que le contrôle direct apporte de la valeur. Il est moins susceptible de permettre des économies lorsque le trafic est irrégulier, que le choix du modèle change souvent ou que les frais opérationnels dépassent les économies de capacité.

Conclusion

Le chiffre défendable du coût d’un LLM auto-hébergé par million de tokens correspond à la capacité facturée entièrement chargée divisée par le débit accepté. Mesurez séparément le préremplissage et le décodage, comptabilisez une seule fois le temps d’inactivité, versionnez votre règle d’acceptation et comparez une référence gérée dans la même unité. Vous transformerez ainsi un devis GPU en modèle de coûts prêt à étayer une décision.

Références techniques

• Référence des métriques vLLM
• Guide d’optimisation des performances NVIDIA TensorRT-LLM
• Documentation de profilage NVIDIA DCGM