Nous avons construit un tableau de bord pour maîtriser les coûts des LLM — et cela a changé notre pratique

Il y a un moment dans chaque cours de yoga où un élève cesse d’essayer de forcer une posture et se contente de remarquer ce que fait le corps. La hanche est raide. Le souffle est court. L’épaule compense. Ce moment de conscience — sans jugement, précis — est l’endroit où le changement commence. Pas dans l’effort. Dans l’observation.

Nous avons construit l’AI Model Pricing Dashboard exactement pour la même raison. Non pas parce que nous voulions dépenser davantage pour les grands modèles de langage, mais parce que nous ne pouvions pas dire — honnêtement, précisément — combien nous dépensions déjà. Personne dans l’équipe ne le savait. Les factures arrivaient, et personne ne pouvait répondre à la question simple : quels modèles utilisons-nous réellement, et à quel coût par fournisseur ?

Le désordre sous le capot

Si vous avez exécuté des charges de travail IA chez plusieurs fournisseurs, vous connaissez la douleur. OpenRouter facture au token avec un taux. OpenAI sépare les tokens d’entrée et de sortie à des prix différents. Anthropic a sa propre structure. Kilo AI Gateway superpose des formules d’abonnement avec une logique de dépassement. Chaque fournisseur compte les tokens différemment. Chaque fournisseur modifie sa grille tarifaire sans note de version.

C’est un peu comme essayer de pratiquer le yoga en lisant cinq livres différents dans cinq langues différentes, dont aucun ne s’accorde sur la signification de « Chien tête en bas ». On peut s’en sortir tant bien que mal. Mais on va compenser. Et la compensation a un coût — payé en argent du côté de l’infrastructure, payé en alignement sur le tapis.

Ce que fait le tableau de bord

L’AI Model Pricing Dashboard est un outil open source — BSD 3-Clause, compatible MIT — construit avec un backend FastAPI et un frontend Next.js. Il agrège les tarifs de plus de 10 fournisseurs de LLM, normalise tout en dollars par million de tokens, et vous donne un tableau unique, filtrable et triable qui rend la comparaison sans effort.

Mais la vraie valeur n’est pas le tableau. La vraie valeur, c’est ce que le tableau révèle :

• Calcul des tokens d’entrée par rapport aux tokens de sortie. La plupart des équipes pensent en termes de « coût par appel ». Mais l’usage moderne des LLM est dominé par les tokens de sortie — les réponses du modèle. Un modèle qui facture 2 $ par million de tokens d’entrée mais 15 $ par million de tokens de sortie a un profil de coût complètement différent d’un modèle qui facture respectivement 5 $ et 6 $. Le tableau de bord rend cela visible instantanément.

• Contexte de la fenêtre de contexte. Un modèle avec une fenêtre de contexte de 128K peut sembler plus coûteux au token qu’un modèle avec une fenêtre de 4K. Mais si vous enchaînez actuellement plusieurs appels à un modèle moins cher pour gérer de longs prompts, le modèle plus coûteux avec la grande fenêtre de contexte est en réalité moins cher — et produit de meilleurs résultats.

• Suivi des tendances. Les prix changent. Le tableau de bord conserve l’historique des prix sur 30 jours. Cela signifie que vous voyez les mouvements de prix des fournisseurs avant qu’ils n’apparaissent sur votre prochaine facture.

• Projection du plan Kilo. Si vous utilisez Kilo AI Gateway, le tableau de bord compare l’utilisation réelle à chaque palier et vous indique quel plan minimise votre coût total, dépassements inclus.

L’architecture en dessous

Le système fonctionne sur Postgres et Redis, avec des manifestes Kubernetes pour le déploiement en production. Le backend FastAPI gère l’agrégation des tarifs avec un cache Redis de 900 secondes — assez rapide pour un usage en temps réel du tableau de bord, assez léger pour les API des fournisseurs. Des CronJobs actualisent les tarifs toutes les 15 minutes et envoient des rapports quotidiens par e-mail à 9 AM UTC.

Pour le développement local, toute la pile démarre avec docker-compose.yml — Postgres, Redis, l’API et le frontend Next.js — en moins de deux minutes.

Nous avons choisi Kubernetes non pas parce que le tableau de bord a besoin d’une échelle massive, mais parce que le modèle de déploiement devrait être banal. Traefik pour l’ingress, cert-manager pour TLS, autoscaling horizontal des pods pour les réplicas de l’API et du web. Banal, c’est fiable. Fiable, c’est ce qu’on veut quand cet outil éclaire des décisions budgétaires.

Où le yoga rencontre le tableau de bord

Voici la partie qu’aucun article sur l’architecture ne vous dira : l’optimisation des coûts et le yoga partagent la même première étape.

En yoga, nous disons la conscience précède le changement. Vous ne pouvez pas corriger une hanche mal alignée si vous ne savez pas qu’elle est mal alignée. Vous ne pouvez pas assouplir une mâchoire crispée en permanence si vous n’avez jamais remarqué qu’elle était tendue. Le fait de remarquer est la pratique. Le fait de remarquer est l’endroit où commence l’agency.

Le tableau de bord existe parce que nous avons remarqué. Pour la première fois, nous avions une image précise et honnête de ce que coûtaient réellement nos charges de travail IA — pas une estimation, pas une vague impression que « ça semble cher », mais un chiffre. Et une fois que vous avez un chiffre, vous pouvez prendre une décision. Changeons-nous de fournisseur pour cette charge de travail ? Utilisons-nous un modèle moins cher pour les tâches non critiques ? Devons-nous mettre en cache de manière plus agressive ? Choisissons-nous le modèle avec la fenêtre de contexte plus large et supprimons-nous l’enchaînement des appels ?

Aucune de ces décisions n’était visible auparavant. Non pas parce que les données n’existaient pas, mais parce qu’elles étaient dispersées sur cinq tableaux de bord de fournisseurs, trois pages de facturation et une feuille de calcul que personne ne mettait à jour.

Nous avons construit le scraper. Nous avons construit le normaliseur. Nous avons construit le tableau de bord. Et la première semaine où nous l’avons utilisé, nous avons trouvé une inefficience de 40 $/mois qui durait depuis quatre mois. Cela fait 160 $ que nous avons dépensés parce que nous ne regardions pas. Le tableau de bord a coûté moins qu’une soirée à mettre en place.

Ce que nous apprenons des données

Depuis le déploiement du tableau de bord, trois choses ont changé dans notre façon de travailler :

Ajustement à la taille de la tâche. Nous attribuons désormais des modèles spécifiques à des tâches spécifiques sur la base du coût réel par tâche, et non d’une préférence de marque. Les tâches répétitives et peu complexes vont vers des modèles moins chers et plus rapides. Les tâches de raisonnement complexes vont là où la qualité justifie le prix. Ce n’est pas une idée nouvelle — c’est le même principe que choisir une pratique restaurative plutôt qu’un flow dynamique en fonction de ce dont votre corps a réellement besoin ce jour-là.

Le caching comme pranayama. En yoga, le pranayama (contrôle du souffle) est la pratique qui consiste à faire compter chaque respiration — moins de volume, plus d’intention, un meilleur échange d’oxygène. Mettre en cache les réponses des LLM, c’est le même concept. Si le même prompt produit la même sortie, vous l’enregistrez. Vous ne payez pas deux fois pour le même calcul. Le cache Redis du tableau de bord avec un TTL de 900 secondes a réduit nos dépenses en tokens répétés d’environ 30 %. Respirer moins, obtenir plus.

Conscience des tendances. Suivre les tendances tarifaires sur 30 jours signifie que nous voyons les baisses de prix des fournisseurs avant de voir des articles à leur sujet. Lorsqu’un fournisseur baisse son tarif de 20 %, nous le savons dans l’heure. Lorsqu’un fournisseur augmente ses tarifs, nous pouvons réévaluer avant le prochain cycle de facturation. Conscience. Agency. Décision.

Open source, parce que thésauriser des outils est une mauvaise pratique de yoga

Le projet est sous licence BSD 3-Clause sur GitHub : github.com/andreab67/ai-models-pricing. Les manifestes Kubernetes sont inclus. La documentation de l’API se trouve dans FUNCTIONAL.md. Le SBOM — chaque dépendance, sa licence, ses notes de sécurité — se trouve dans SBOM.md.

Nous avons ouvert le code source parce que le problème n’est pas le nôtre seul. Toute équipe qui exécute des charges de travail IA multi-fournisseurs a ce problème. Et thésauriser des outils utiles, pour utiliser une analogie de yoga, revient à refuser d’enseigner à un élève une posture qui pourrait l’aider. La pratique n’est pas diminuée par le partage. Elle s’en trouve approfondie.

Un geste pour cette semaine

Si votre équipe exécute des charges de travail LLM et que vous ne pouvez pas répondre immédiatement à « combien dépensons-nous par fournisseur et par tâche » — vous compensez. Pas mal. Juste de façon coûteuse.

Mettez le tableau de bord en place localement. Cela prend deux minutes avec Docker. Lancez-le. Regardez les chiffres. Laissez les chiffres vous dire quelque chose que vous n’aviez pas remarqué.

Puis décidez.

C’est la même pratique que nous faisons sur le tapis : arriver, remarquer, choisir. Les outils changent. Le principe, non.

L’AI Model Pricing Dashboard est open source sur github.com/andreab67/ai-models-pricing. L’instance de production s’exécute sur notre cluster Kubernetes. Si vous souhaitez de l’aide pour le déployer ou l’intégrer à votre propre pipeline d’alertes de coûts, contactez-nous.