FinOps IA: maîtriser les coûts GPU multi-cloud

Le FinOps IA rend les coûts GPU visibles et transforme l’inférence en discipline de pilotage.

Les points clés en bref

• L’inférence n’est pas le cousin du training : Les sessions de training sont des charges de travail par lots planifiables, l’inférence est une charge dans le temps. Celui qui budgétise les deux avec la même logique de capacité réservée paie soit pour l’inactivité, soit pour les surcoûts à la demande. La séparation des deux types de coûts doit figurer dans chaque tableau FinOps dès le premier jour.
• Le multi-cloud est un levier de prix, pas une fin en soi : Entre l’heure de GPU d’un hyperscaler et l’heure de Neocloud, il y a un facteur de 2 à 3. Celui qui sépare les charges de travail selon la tolérance à la latence, la résidence des données et la classe de conformité peut retirer les charges sensibles aux prix de l’hyperscaler de manière ciblée.
• L’économie unitaire l’emporte sur la planification de la capacité : Le coût par 1 000 tokens, par requête ou par utilisateur actif est la seule unité de contrôle qui porte au conseil d’administration. Sans cette métrique, toute discussion sur les GPU reste une dispute sur la location de serveurs.

RelatedLa facture d’inférence que personne n’a budgétisée  /  38 % de coûts cloud en moins dans l’ingénierie mécanique

Où le budget est réellement dépensé

Trois postes remplissent chaque facture GPU que j’ai vue ces derniers mois. Premièrement : le temps d’inactivité sur le matériel réservé. Celui qui a réservé une instance H100 pour 730 heures par mois et ne l’utilise que 220 heures paie 510 heures d’inactivité. Deuxièmement : les pics de charge à la demande, car la capacité réservée ne fait pas l’échelle. Troisièmement : les coûts de sortie entre les régions, lorsque les poids du modèle sont déplacés d’une région à l’autre.

Aucun de ces trois postes n’est visible dans le modèle. Ils apparaissent dans l’architecture. Celui qui met à l’échelle l’inférence comme un service web, c’est-à-dire en montant et descendant des pods via Kubernetes, obtient les deux premiers postes. Celui qui utilise le multi-région pour la latence, sans maintenir les poids du modèle au niveau régional, obtient le troisième en plus.

La leçon difficile : l’inférence a une courbe de charge qui ne peut pas être dérivée de la session de training. Elle dépend du comportement de l’utilisateur, de l’heure de la journée, des vagues de marketing. La planification de la capacité sans données de courbe de charge est un jeu de hasard avec un tarif horaire à trois chiffres.

Trois tableaux de prix indispensables pour chaque tableau FinOps

Pour contrôler l’inférence multi-cloud, trois tableaux de prix sont nécessaires en parallèle. Situation au T2 2026, tous les prix sont indicatifs, la situation de négociation par compte doit être impérativement vérifiée.

La différence nominale de facteur 3 entre l’On-Demand des hyperscalers et le Neocloud n’est pas le point final. Les hyperscalers regroupent le réseau, le stockage et la pile d’identité, ce qui réduit la différence effective. Les Neoclouds exigent que l’identité, la surveillance et la connexion VPC soient construites par soi-même. En tenant compte de cela, la différence réelle se situe entre un facteur de 1,8 et 2,4.

Tri des charges de travail comme levier FinOps

Toutes les charges d’inférence ne doivent pas être sur la même pile. Un tri en quatre classes suffit en pratique pour adresser 30 à 50 pour cent des coûts.

Le tri est efficace dès qu’il est contraignant. Si vous le communiquez comme une recommandation, vous obtiendrez la même répartition qu’auparavant après trois mois, car les équipes prendront le chemin de la moindre résistance. Les règles de tri doivent être intégrées dans le flux de travail de déploiement, pas dans un document Confluence.

De la capacité réservée au sliding reserve

La capacité réservée classique n’est pas la bonne réponse pour l’inférence GPU. Les engagements de trois ans pour les H100 sont rarement amortis, car la génération GPU est obsolète en 18 mois. Meilleure architecture : une sliding reserve de 30 à 50 pour cent de capacité réservée comme base, 20 à 30 pour cent de plans de réduction pour la flexibilité, le reste sur demande ou spot.

Ce qui manque souvent dans le plan de maturité : un point explicite sur les délais de livraison. La capacité H100 reste en déficit dans certaines régions jusqu’en 2026. Celui qui ne met pas de marge de manœuvre dans le plan pour la latence de provisionnement déplace le problème à l’échelle des opérations.

L’économie de l’unité comme devise de contrôle

La discussion FinOps la plus honnête au conseil ne se passe pas sur les heures GPU, mais sur le coût par unité de sortie. Trois indicateurs se sont avérés efficaces en pratique : coût par 1 000 jetons de sortie, coût par requête utilisateur terminée, coût par utilisateur actif et par mois. Le choix dépend du produit.

Exemple d’un setup client : une application RAG avec environ 80 000 requêtes par jour coûtait environ 0,034 euros par requête, dont 0,022 euros pour l’inférence, 0,008 euros pour le vecteur de recherche, 0,004 euros pour le journalisation et l’observabilité. C’est l’exploitation qui a révélé que le journalisation représentait 18 pour cent du coût par trimestre. La réduction était là, pas dans le modèle.

Qui ne rapporte pas l’économie de l’unité chaque mois perd la maîtrise après deux trimestres. Ensuite, le mandat de réduction des coûts viendra du bureau du CFO, et le choix sera dur : réduire le modèle, changer de fournisseur, supprimer des fonctionnalités.

Architectural decisions with the greatest leverage

Trois leviers architecturaux ont un impact surage. Premièrement : routage de modèle au niveau de l’équipe de requêtes. Toutes les requêtes nécessitent pas le meilleur modèle. Un classifieur au début, qui routage les requêtes simples vers un modèle plus petit ou vers l’inférence open source, réduit la mélange de coût de 20 à 35 pour cent.

Deuxièmement : mise en cache au niveau des embeddings et des réponses. Dans les cas d’utilisation proches des FAQ, les requêtes répétées sont souvent dans l’intervalle de 10 à 20 pour cent. Un cache sémantique avec TTL contrôlé économise le round trip complet du modèle pour chaque hit.

Troisièmement : agrégation de lot au niveau de l’API. Celui qui transmet des requêtes d’inférence individuellement paie le tarif premium par jeton. Celui qui agrège des micro-batches de 50ms sur la couche de service double ou triple le débit GPU par heure sans aucun ajustement du modèle.

Ces trois leviers ne sont pas spectaculaires. Ils sont des routines d’ingénierie. C’est ce qui les rend planifiables et répétables.

Qu’il y a dans le modèle de maturité FinOps

Trois indicateurs montrent si un équipe maîtrise les coûts d’inférence. Premièrement : la responsabilité FinOps est au sein de l’ingénierie, pas dans le contrôle financier. Celui qui vit les revues de coûts comme des audits externes n’a pas de contrôle. Celui qui les traite comme des normes de révision d’architecture en a.

Deuxièmement : les coûts des jetons par fonctionnalité sont visibles dans le backlog produit. Les product managers qui ne savent pas ce que crée une nouvelle fonctionnalité d’IA en termes de coûts variables planifient à la lanterne.

Troisièmement : il existe un chemin codifié pour changer de modèle. Celui qui reste 18 mois sur un fournisseur et n’a pas de chemin de re-déploiement documenté paie le surcoût de lock-in sans le voir.

Foire aux questions

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré dans l’image