Le calcul d'inférence que personne n'a budgété

16 mai 2026

5 Min. Temps de lecture

Le rapport State of FinOps 2026 est disponible. Un chiffre en particulier concerne toutes les équipes qui exploitent des modèles de manière productive : 73 % des organisations interrogées déclarent que leurs coûts liés à l’IA ont dépassé leur planification budgétaire initiale. Les responsables des charges de travail d’inférence doivent revoir leur calcul avant que cela ne dicte leur prochaine planification trimestrielle.

Les points clés en bref

Le rapport fournit les chiffres : Selon le State of FinOps 2026, la proportion d’équipes FinOps qui gèrent activement les dépenses liées à l’IA est passée de 31 à 98 % en deux ans. La gestion des coûts liés à l’IA est la nouvelle compétence la plus recherchée dans l’industrie.
L’inférence est le bloc de coûts : La FinOps Foundation situe 80 à 90 % des dépenses liées à l’IA dans l’inférence, et non dans la formation. Pourtant, l’utilisation des GPU en fonctionnement est souvent comprise entre 15 et 30 %.
Quatre étapes pour réorganiser le calcul : Mesurer les coûts par jeton, rendre l’utilisation visible, adapter le modèle à la tâche, ouvrir le mélange de fournisseurs. Dans cet ordre.

Lié :Les dépenses liées à l’IA poussent les équipes FinOps dans de nouvelles pièges budgétaires / L’IA consomme de l’électricité, le cloud reçoit la facture

Ce que le rapport FinOps 2026 montre en noir et blanc

Le rapport annuel State of FinOps de la FinOps Foundation est basé sur près de 1 200 praticiens qui sont responsables ensemble de plus de 83 milliards de dollars de dépenses cloud annuelles. L’édition 2026 fait de l’IA la catégorie de coûts à la croissance la plus rapide. Pour les entreprises liées à l’IA, la proportion de charges de travail liées à l’IA dans le budget cloud est de 18 %, contre 4 % en 2023.

Il est intéressant de noter le saut dans la zone de responsabilité. Il y a deux ans, un peu moins d’un tiers des équipes FinOps géraient les dépenses liées à l’IA, maintenant c’est presque tout le monde. Ce n’est pas une mode, c’est une réaction à des factures que personne n’avait prévues. Qui met un modèle derrière un point final construit une unité de coûts qui grandit avec chaque demande et est souvent considérée comme secondaire dans l’examen de l’architecture.

Le véritable problème ne se trouve pas dans la croissance, mais dans le gaspillage. Les analyses sectorielles de l’économie de l’inférence montrent un tableau cohérent en 2026 : une partie importante du budget GPU paie du matériel qui ne fait rien de productif.

35 à 60 %

du budget cloud GPU d’une équipe d’IA moyenne est considéré comme évitable – causé par l’inactivité, des modèles mal dimensionnés et des réservations non utilisées.

Source : Analyses sectorielles de l’économie de l’inférence, 2026

Trois endroits où l’argent des GPU s’évapore

Avant d’optimiser, il vaut la peine de jeter un regard honnête sur l’endroit où l’argent va réellement. Dans la plupart des configurations d’inférence productives, ce sont les mêmes trois fuites.

Premièrement : l’inactivité. Une GPU en fonctionnement d’inférence fonctionne rarement à la limite de charge. 15 à 30 % de charge sont une valeur courante, mais la pleine heure est facturée de toute façon. Tout ce qui est inférieur à 50 % est essentiellement de l’argent récupérable. Cela s’applique particulièrement aux points de terminaison avec un trafic irrégulier, qui sont disponibles la nuit comme à l’heure de pointe de midi. Qui sous-estime l’aspect énergétique de cette disponibilité permanente le retrouve dans la facture d’énergie du cloud.

Deuxièmement : trop de précision. De nombreux déploiements utilisent des modèles en FP16, alors que la tâche ne l’exige pas. La quantification FP8 sur un H100 réduit les coûts par million de jetons de manière significative, selon les benchmarks matériels, et avec une qualité vérifiée proprement, c’est le choix préférable pour la plupart des charges de travail de production. La pleine précision est une décision, pas un défaut.

Troisièmement : le supplément du fournisseur de cloud. La même carte H100 coûte plusieurs fois plus cher chez les grands fournisseurs que chez les fournisseurs de cloud spécialisés en IA. Cela ne signifie pas que tout doit être déplacé. Cela signifie qu’un point de terminaison d’inférence fonctionnant de manière régulière est simplement trop cher lorsqu’il est stationné sur un prix à la demande d’un fournisseur de cloud.

Le chemin en quatre étapes vers des coûts d’inférence prévisibles

L’ordre n’est pas un simple effet de style. Qui commence par l’étape trois optimise un modèle dont les coûts ne peuvent pas être chiffrés. Ce chemin fonctionne pour une configuration existante avec une poignée de points de terminaison de production.

Chemin FinOps pour les charges de travail d’inférence

Étape 1

Mesurer les coûts par jeton. Par modèle et point de terminaison, une journée, puis diviser les dépenses par les jetons traités. Sans cette mesure, toute optimisation supplémentaire est basée sur le feeling. Un prévision de coûts dans une requête de tirage rend les modifications coûteuses visibles avant qu’elles ne soient mises en ligne.

Étape 2

Rendre l’utilisation visible. Un tableau de bord d’utilisation de la GPU par point de terminaison montre l’inactivité. Le batching dynamique et la mise en cache augmentent l’utilisation de environ 30 à 70 % et réduisent les coûts d’inférence en conséquence.

Étape 3

Adapter le modèle à la tâche. Quantisation FP8 avec des benchmarks de qualité, un modèle plus petit pour des tâches de routage ou de classification simples, décodage spéculatif là où la latence compte. Toutes les requêtes n’ont pas besoin du fleuron.

Étape 4

Ouvrir le mélange de fournisseurs. Charge de base sur des prix réservés ou engagés, pics via Autoscaling, charges de travail stables et intensives en inférence sur des clouds spécialisés en IA à examiner. Les mouvements de prix comme la réduction de 8 % des coûts de calcul chez Google Cloud au premier trimestre 2026 font partie de la comparaison régulière.

Je me suis plus d’une fois investi une après-midi dans la sélection de modèles, pour finalement constater que le véritable levier était un Autoscaling non configuré. Comme souvent, l’argent important se trouve à l’endroit le moins apparent.

Ce qui contribue à l’épargne et ce qui se retourne contre elle

L’optimisation des coûts peut également se retourner contre vous. Ces modèles ont fait leurs preuves dans la pratique – et ceux-ci récupèrent l’argent économisé sous forme de coûts consécutifs.

Ce qui contribue

Coûts par token comme indicateur visible de l’équipe, et non comme rapport trimestriel
Quantisation toujours avec un benchmark de qualité par rapport au modèle d’origine
Autoscaling qui réagit à la charge réelle et non à une estimation
Capacité réservée pour la charge de base calculable, à la demande uniquement pour les pics

Ce qui se retourne contre

Spot-only pur sans fallback si la capacité disparaît au milieu du trafic
Quantisation sans vérification qui réduit silencieusement la qualité de la réponse
Réduction de la taille du modèle qui produit des tickets de support au lieu d’heures de GPU
Déplacement multi-cloud sans prendre en compte les frais d’égout

La partie la plus coûteuse d’une inférence n’est pas l’heure de GPU. C’est l’heure de GPU pendant laquelle rien n’est calculé.

Le rapport 2026 ne fera plus de FinOps pour l’IA une option facultative. Lorsque presque chaque équipe FinOps gère désormais les dépenses en IA, la question lors du prochain examen d’architecture ne portera pas sur le fonctionnement d’un modèle. Elle portera sur le coût d’une réponse. Qui a ce chiffre à disposition discutera sur un pied d’égalité.

Foire aux questions

Pourquoi l’inférence est-elle plus chère que l’entraînement ?

L’entraînement est une dépense unique et délimitée. L’inférence est continue et évolue avec l’utilisation. La FinOps Foundation situe donc 80 à 90 % des dépenses en IA dans l’inférence. Chaque utilisateur supplémentaire et chaque invite plus longue augmentent la facture en cours.

Quel est le premier indicateur le plus important ?

Coûts par token, séparés par modèle et point de terminaison. Il relie la facture cloud à l’utilité métier et permet d’évaluer toute optimisation supplémentaire. Sans ce chiffre, on optimise dans le noir.

La quantisation réduit-elle toujours la qualité de la réponse ?

Pas nécessairement. FP8 fournit des résultats pratiquement équivalents pour de nombreuses charges de travail de productivité à des coûts nettement inférieurs. La décision est un benchmark de qualité par rapport au modèle d’origine avant de lancer la variante quantisée.

Les clouds AI spécialisés en valent-ils la peine par rapport aux hyperscalers ?

Pour des charges de travail stables et à forte inférence, souvent oui, car les prix des heures de GPU y sont nettement inférieurs. Il faut prendre en compte les frais d’égout, les coûts de stockage et les durées minimales d’exécution. Pour des charges très variables ou une intégration étroite dans une pile hyperscaler, le fournisseur établi reste souvent pertinent.

Comment empêcher les instances Spot de perturber l’exploitation ?

Spot convient aux tâches interrompables comme l’inférence par lots, pas pour les points de terminaison critiques à latence sans sauvegarde. Un fallback sur une capacité à la demande et une limitation de la proportion Spot dans la charge globale maintiennent l’exploitation stable si la capacité disparaît.