OpenCost 1.121.0 mesure enfin le coût réel de chaque token d’inférence sur Kubernetes
Le 5 août 2026, OpenCost s’associe à llm-d pour publier le premier suivi du coût d’inférence par token sur Kubernetes. La distinction entre coût d’allocation et coût d’usage met fin au calcul trompeur qui justifiait à tort l’auto-hébergement des LLM.
5 août 2026. OpenCost, le projet CNCF en incubation, publie sa version 1.121.0 avec une première mondiale : le suivi du coût d’inférence par token sur Kubernetes, via une intégration avec llm-d, le projet CNCF de serving LLM distribué. L’annonce, cosignée par Sima Nadler (IBM Research) et Alex Meijer (mainteneur OpenCost), répond à une question que les équipes plateforme se posent depuis deux ans sans pouvoir y répondre : combien coûte réellement un token produit par votre propre cluster ?
La facture GPU grimpe, les modèles servent des milliards de tokens, et pourtant le lien entre les deux reste invisible. Trois décisions se prennent aujourd’hui à l’aveugle :
- Auto-héberger ou consommer une API SaaS ? Vous devinez.
- Quel modèle est réellement rentable à votre niveau de trafic ? Les données n’existent pas.
- Quelle équipe consomme le budget IA ? Personne ne le sait.
Le résultat est une grosse facture mensuelle sans explication, pendant que la direction pose des questions de ROI auxquelles vous ne pouvez pas répondre avec des chiffres.
Pourquoi maintenant
La question n’est pas académique. La facture GPU grimpe pendant que les modèles servent des milliards de tokens, et les équipes plateforme n’ont toujours aucun moyen de relier les deux chiffres. Le FinOps, qui a structuré la facture cloud généraliste, ne couvrait pas l’inférence IA : un pod GPU facturé, oui ; un token, non. En juillet 2026, la FinOps Foundation a étendu son framework aux licences, au SaaS et au data center — l’inférence est la prochaine frontière, et elle manquait cruellement d’instrumentation.
Jusqu’ici, les équipes compensaient par des estimations au doigt mouillé : un prix moyen par modèle, un ratio approximatif de tokens par heure. Ces approximations suffisaient tant que l’IA restait un prototype. Elles ne suffisent plus dès que la production et le chargeback arrivent — c’est exactement le moment où OpenCost entre en scène.
Coût ≠ prix
Première clarification, posée d’emblée par le billet : le coût n’est pas le prix. Un fournisseur SaaS peut facturer sous son coût pour acheter des parts de marché, ou bien au-dessus pour un modèle premium. Quand vous comparez l’auto-hébergement au SaaS, le coût du SaaS pour votre entreprise est le prix affiché — pas son coût interne. La distinction paraît académique ; elle est pourtant au cœur de l’erreur de calcul la plus répandue.
Deux coûts, deux questions
L’intuition centrale de l’intégration : il existe deux questions différentes, qui exigent deux métriques différentes.
- Le coût par allocation englobe tout ce qui sert à rendre le modèle disponible : la mémoire GPU réservée aux poids, le calcul consommé pendant l’inférence active, et une part des infrastructures communes (gateway, stockage du cache KV). Il se réconcilie avec votre facture d’infrastructure et répond à la question « combien ce modèle nous coûte-t-il ? ».
- Le coût par usage n’inclut que le calcul consommé pendant l’inférence active, en créditant les économies des hits du cache KV. Il répond à « combien a coûté le travail réel de ce modèle ? ».
L’écart entre les deux représente le coût de garder le modèle chaud. Un modèle à faible trafic peut passer 95 % de son temps dans cet état « chaud mais inactif » : ses poids occupent la VRAM quoi qu’il arrive, brûlant du budget sans produire le moindre token utile.
La relation entre les deux métriques exprime directement l’utilisation GPU, sans métrique séparée :
# Utilisation = coût d'usage / coût d'allocation
llm_cost_per_million_tokens{cost_basis="usage"}
/
llm_cost_per_million_tokens{cost_basis="allocation"}
# Exemple : 1,00 $ (usage) / 4,00 $ (allocation) = 25 % d'utilisationLe piège du build-vs-buy
L’erreur classique de modélisation consiste à justifier l’auto-hébergement avec le coût d’usage. Si votre coût d’usage est de 1,00 $ par million de tokens et que l’API SaaS facture 2,00 $, l’auto-hébergement paraît deux fois moins cher. Sauf que le coût d’usage ne capture que le calcul actif : il exclut la réservation GPU, l’idle et l’infrastructure. À 25 % d’utilisation, le vrai coût d’auto-hébergement est 4,00 $ par million de tokens, pas 1,00 $.
La comparaison correcte est donc coût d’allocation vs prix de l’API :
Modèle auto-hébergé à 25 % d'utilisation :
coût d'usage par million de tokens : 1,00 $ (calcul seul — trompeur)
coût d'allocation par million de tokens : 4,00 $ (coût réel — utilisez celui-ci)
prix API externe par million de tokens : 2,00 $
Conclusion : l'API externe est moins chère à l'utilisation actuelle.
L'auto-hébergement devient compétitif au-dessus de ~50 % d'utilisation.Ce cadre fournit aussi la cible d’optimisation : augmenter l’utilisation par un routage plus intelligent, le partage de modèles ou la consolidation du trafic fait baisser le coût d’allocation par token — et peut rendre l’auto-hébergement rentable.
Ce que l’intégration mesure réellement
L’intégration s’appuie sur des métriques déjà présentes dans un déploiement llm-d : le débit de tokens de vLLM (vllm:prompt_tokens_total, vllm:generation_tokens_total), les coûts GPU du moteur d’allocation OpenCost, et des métriques de temps de traitement. Les utilisateurs vLLM qui n’utilisent pas llm-d en bénéficient aussi, puisque les métriques de base proviennent de vLLM.
Deux métriques sont publiées vers Prometheus et exposées via l’API REST d’OpenCost :
| Métrique | Ce qu’elle mesure |
|---|---|
llm_total_hourly_cost | Coût horaire par modèle |
llm_cost_per_million_tokens | Coût par million de tokens, avec labels séparant entrée et sortie |
Les coûts des tokens d’entrée et de sortie (y compris les tokens de raisonnement) sont rapportés séparément, car ils sollicitent des phases différentes : l’entrée déclenche la prefill, la sortie pilote le decode. Dans les déploiements disaggregated — prefill et decode sur du matériel distinct — cette séparation est indispensable à une attribution juste. Les métriques intègrent aussi l’effet des hits du cache KV sur le coût de traitement des tokens d’entrée.
Au-delà du GPU : le coût complet d’un modèle
Un modèle servi par llm-d ne tourne pas en isolation. Le coût complet inclut le scheduler d’inférence (EPP), le proxy de gateway, le stockage du cache KV — jusqu’à 18 To en déploiement tiered — et l’autoscaler de variantes de workload. OpenCost répartit ces coûts partagés via son mécanisme SharedLabels, ce qui maintient les deux projets découplés : llm-d étiquette ses composants au déploiement, OpenCost attribue les coûts sans connaître l’architecture interne de llm-d.
Lire la matrice de coûts
Les quatre combinaisons coût d’allocation / coût d’usage racontent chacune une histoire distincte :
| Allocation | Usage par million | Diagnostic |
|---|---|---|
| Élevé | Faible | Cher à garder disponible, efficace en inférence : le problème est l’utilisation. |
| Élevé | Élevé | Cher à héberger et à exécuter : ce modèle est-il le bon choix ? |
| Faible | Faible | Déploiement probablement bien dimensionné. |
| Faible | Élevé | Peu cher à héberger, mais l’inférence coûte : évaluez taille, quantization et matériel. |
Une équipe finance peut interroger les coûts par namespace et par label d’équipe pour générer des rapports de showback. Une équipe FinOps identifie les modèles sous-utilisés et chiffre l’économie d’un right-sizing ou d’une désaffectation. Et un routeur intelligent — que llm-d développe — pourra intégrer le coût par token dans ses décisions de routage, aux côtés de la latence et du débit.
La fonctionnalité a été validée sur un cluster de 109 GPU et 30 modèles déployés.
Mise en œuvre en pratique
Activer la fonctionnalité ne demande pas de réécrire votre stack :
- Sous llm-d, la mise à jour vers OpenCost 1.121.0 suffit : les métriques remontent vers Prometheus, et l’API REST expose
llm_total_hourly_costetllm_cost_per_million_tokens. - Sous vLLM sans llm-d, vous récupérez les mêmes métriques de base, car le calcul repose sur
vllm:prompt_tokens_totaletvllm:generation_tokens_total. - Un guide de déploiement OpenCost + llm-d a été publié avec la release.
Premier réflexe une fois les métriques en place : afficher la matrice allocation / usage de vos modèles et repérer les lignes « allocation élevée, usage faible ». Ce sont vos GPU chauds et inactifs — les plus faciles à rentabiliser par la consolidation du trafic ou le partage de modèles. OpenCost reste entièrement open source : l’essayer coûte un helm install, pas un cycle d’achat.
Verdict
Si vous servez des LLM sur Kubernetes, vous ne pouvez pas décider du build-vs-buy sans le coût d’allocation par million de tokens — et jusqu’à présent, aucune métrique ne vous le donnait. OpenCost 1.121.0 comble ce trou.
La règle de décision est désormais chiffrable : comparez le coût d’allocation au prix de l’API, jamais le coût d’usage. En dessous de ~50 % d’utilisation GPU, l’API externe gagne presque toujours ; au-dessus, l’auto-hébergement devient compétitif. Avant d’acheter plus de GPU, déployez OpenCost et regardez votre matrice de coûts : l’économie est souvent dans la consolidation du trafic, pas dans le matériel.