Il y a un sujet qui revient de plus en plus souvent dans les missions FinOps : la facture d’inférence IA. Azure OpenAI, Amazon Bedrock, ou des déploiements self-hosted sur des H100 — peu importe le canal, le constat est le même. Les montants grimpent vite, et personne dans l’organisation n’a vraiment de prise dessus.
Le réflexe naturel, côté finance, c’est de demander à négocier les tarifs avec le fournisseur. Le réflexe côté tech, c’est souvent de répondre « c’est le prix du marché, on ne peut rien y faire ». Les deux ont tort.
Entre les deux, il existe une zone qui appartient au FinOps. Une zone qui ne demande pas de devenir ingénieur machine learning, mais qui demande de comprendre que certains leviers techniques existent — et qu’ils ont un impact financier majeur.
Le scénario typique
Un client tourne sur du Llama 70B ou un équivalent, servi via une API managée, pour traiter ses workloads d’inférence en production. Facture mensuelle : 15 000 €. Tout fonctionne. L’équipe métier est contente du service. L’équipe tech est contente parce que ça marche sans qu’elle ait à gérer d’infra. La finance regarde la ligne grossir doucement chaque mois sans vraiment savoir quoi en faire.
Personne n’a jamais posé la question : « Est-ce qu’on pourrait faire le même travail pour 7 000 € ? »
Pas parce que la réponse serait gênante. Mais parce que personne n’a les bons éléments pour la poser.
Trois leviers qui restent souvent en jachère
Le premier concerne le format des poids du modèle. C’est sans doute le plus technique des trois, mais c’est aussi celui dont l’impact financier est le plus direct. Un modèle de 70 milliards de paramètres en FP16 — le format par défaut — occupe environ 140 Go de mémoire GPU. Le même modèle quantizé en FP8 occupe la moitié. Concrètement, ça veut dire que le modèle tient sur un seul GPU H100 au lieu d’en demander deux. Et qui dit deux fois moins de GPUs, dit deux fois moins de coût d’infrastructure.
Selon le fournisseur, le prix horaire d’un H100 varie entre 1,50 et 7 $/heure — les hyperscalers comme AWS ou Azure étant au haut de la fourchette, les fournisseurs spécialisés comme RunPod ou Lambda au bas. Quel que soit le point de départ, passer de deux GPUs à un seul coupe la facture de moitié, avec une perte de qualité qui se mesure en dixièmes de point sur les benchmarks de référence. Autant dire dans le bruit de mesure pour la plupart des cas d’usage réels — chat, résumé, classification, génération de code standard. Ce n’est pas une optimisation expérimentale : le FP8 est supporté nativement par le matériel récent, et les outils de production comme vLLM ou TensorRT-LLM l’intègrent depuis plusieurs trimestres. Le sujet a quitté la sphère R&D.
Le deuxième levier est probablement le plus universel, et celui qui demande le moins de connaissances techniques pour être actionné : le choix du modèle pour chaque tâche. L’écart de prix entre un modèle frontière et un petit modèle de la même famille est rarement de 20 ou 30 %. Il est généralement de 10 à 20 fois. Et la vraie question n’est pas « lequel est le meilleur ? » — c’est « lequel est suffisant pour cette tâche précise ? ». Un agent qui doit classifier des emails entrants n’a pas besoin du même modèle qu’un agent qui doit générer un rapport d’analyse. Pourtant, dans beaucoup d’organisations, c’est exactement ce qui se passe : le modèle le plus puissant est utilisé partout, par défaut, parce que c’est plus simple à mettre en place et que « ça marche mieux ». Mieux pour quoi, à quel coût, par rapport à quel besoin réel ? Ces questions ne sont presque jamais posées.
Le troisième levier est plus structurant et plus délicat : API managée, ou self-hosted ? La réponse simple — « API managée, c’est plus simple » — masque un calcul qui dépend complètement de ce à quoi on se compare. Comparé aux API frontière des grands fournisseurs, le break-even arrive vite : à partir de quelques millions à quelques dizaines de millions de tokens par jour selon la configuration, un déploiement self-hosted bien dimensionné commence à coûter moins cher qu’un appel répété à un modèle premium souvent surdimensionné pour la tâche réelle. Comparé en revanche aux API d’hébergement de modèles open source (Together.ai, DeepInfra, Fireworks et équivalents), le calcul s’inverse complètement. Ces fournisseurs opèrent déjà des infrastructures optimisées à grande échelle avec des marges fines. Le break-even monte alors à plusieurs centaines de millions de tokens par jour, et il faut un workload très spécifique pour que le self-hosted reste compétitif.
Entre les deux, il y a tout un spectre où la bonne réponse dépend du modèle de comparaison, du pattern de trafic, de la régularité de la charge, et de la capacité de l’équipe à opérer une infra d’inférence en production. Et c’est là que se trouve le vrai problème : très peu d’organisations savent où elles se situent sur ce spectre. Quel volume de tokens par jour ? Quelle proportion de contexte répété ? Quelle saisonnalité du trafic ? Quel modèle open source équivalent au modèle propriétaire utilisé aujourd’hui ? Sans ces données, le choix entre managé et self-hosted relève davantage de la croyance que de l’analyse — et il se fait par défaut, presque toujours en faveur du managé, parce que c’est le chemin de moindre résistance.
Pourquoi ces leviers ne sont pas activés
Le problème de fond est organisationnel, pas technique.
Les équipes ML connaissent ces techniques, généralement. Mais leur priorité, c’est la qualité du modèle, le délai de livraison, la stabilité en production. L’optimisation des coûts arrive loin derrière, parce qu’elle n’est pas dans leurs objectifs.
Les équipes finance voient la facture, mais n’ont pas le vocabulaire pour formuler la question. « Pourquoi ça coûte autant ? » reste sans réponse exploitable.
Et entre les deux, il manque souvent quelqu’un qui sait à la fois lire une facture cloud et comprendre qu’une décision technique sur le format de quantization ou le choix du modèle a un impact direct sur cette facture. C’est exactement le rôle qu’occupe le FinOps quand il est bien positionné — pas un contrôleur externe qui réclame des économies, mais un partenaire qui pose les bonnes questions au bon moment et qui aide les équipes ML à arbitrer.
Avant d’optimiser, il faut mesurer
Avant de toucher à quoi que ce soit, il faut savoir ce qu’on optimise. Trois métriques de base devraient être en place avant n’importe quelle initiative d’optimisation des coûts d’inférence.
D’abord, le coût par tâche métier accomplie. Pas le coût mensuel global, ni le coût par million de tokens. Le coût d’un ticket traité, d’un document résumé, d’une réponse client générée. Sans cette métrique, aucune décision d’optimisation n’est défendable. Ensuite, la répartition par modèle — quel pourcentage du budget va sur le modèle frontière, quel pourcentage sur les modèles plus légers ? Si la réponse est 90/10 en faveur du frontière, il y a presque toujours un travail de routing à mener. Enfin, le ratio prompt/completion : si le prompt représente 80 % des tokens facturés, l’enjeu principal est dans la gestion du contexte (caching, compression, architecture de prompt), pas dans le choix du modèle.
Ces trois métriques ne demandent pas d’instrumentation lourde. Quelques jours de travail, et la visibilité change radicalement.
Une intuition sur la suite
Les coûts d’inférence vont probablement devenir, dans les prochaines années, ce que les coûts de stockage ont été dans les années 2010 : un poste qui paraît négligeable au départ, qui devient significatif sans qu’on s’en rende compte, et qui finit par dominer la facture cloud si personne ne s’en occupe.
La différence, c’est que cette fois-ci, les leviers d’optimisation existent dès le premier jour. Quantization, choix du modèle, routing, caching — tout est documenté, tout est outillé. Ce qui manque, ce n’est pas la technique. C’est l’organisation qui permet de poser les bonnes questions, au bon moment, à la bonne personne.
« Un agent IA bien conçu sait quand utiliser un gros modèle et quand un petit suffit. Une organisation FinOps mature sait poser cette question avant que la facture l’impose. »
Le sujet n’est pas de freiner l’adoption de l’IA — c’est de s’assurer que les décisions techniques qui structurent la facture soient prises en connaissance de cause, et pas par défaut.
C’est exactement le type de problématique accompagnée chez YopoConsulting — aider les équipes à reprendre la main sur leurs coûts d’IA en production, avec des métriques claires et une gouvernance FinOps qui parle le langage des équipes ML. Pour faire le point sur la maturité FinOps de votre organisation, un assessment gratuit est disponible — quelques minutes pour avoir une photo honnête de là où vous en êtes. Si le sujet vous parle, on peut en discuter.