9 Min. Temps de lecture

Une heure de H100 coûte environ 12 dollars chez AWS, 11 chez Google et moins de 4 chez Lambda Labs. Si vous achetez de l’inférence chez un hyperscaler et que vous devez expliquer au prochain bilan trimestriel pourquoi votre facture GPU est 40 % supérieure au plan, vous avez rarement un problème de modèle. Vous avez un problème de budgétisation qui est apparu dans la conception de l’architecture.

Les points clés en bref

• L’inférence n’est pas un cousin de l’entraînement : Les sessions d’entraînement sont des workloads par lots prévisibles, l’inférence est une charge au fil du temps. Quiconque budgétise les deux avec la même logique de capacité réservée paie soit des frais d’inoccupation soit des frais à la demande. La séparation de ces deux types de coûts appartient à chaque tableau FinOps dès le premier jour.
• Le multi-cloud est un levier de prix, pas une fin en soi : Entre l’heure GPU d’un hyperscaler et l’heure Neocloud, il y a un facteur de 2 à 3. Quiconque sépare les workloads en fonction de la tolérance à la latence, de la résidence des données et de la classe de conformité peut tirer les charges sensibles aux prix hors du hyperscaler.
• L’économie unitaire bat la planification de la capacité : Les coûts par 1 000 tokens, par demande ou par utilisateur actif sont la seule unité de contrôle qui compte au conseil d’administration. Sans cette métrique, chaque discussion sur les GPU est une dispute sur les loyers de serveurs.

LiéLa facture d’inférence que personne n’a budgétisée  /  38 % de coûts cloud en moins dans la construction mécanique

Où le budget est réellement brûlé

Trois postes remplissent chaque facture GPU que j’ai vue ces derniers mois. Premièrement : le temps d’inoccupation sur du matériel réservé. Si vous avez réservé une instance H100 pour 730 heures par mois et que vous ne l’avez utilisée que 220 heures, vous payez 510 heures d’inoccupation. Deuxièmement : les pics de demande à la demande, parce que la capacité réservée ne peut pas être mise à l’échelle. Troisièmement : les coûts d’égout entre régions, lorsque les poids de modèle sont déplacés.

Aucun de ces trois postes n’est visible dans le modèle. Ils apparaissent dans l’architecture. Si vous mettez à l’échelle l’inférence comme un service Web, c’est-à-dire que vous montez et descendez des pods via Kubernetes, vous obtenez les deux premiers postes. Si vous utilisez plusieurs régions pour la latence sans stocker les poids de modèle régionalement, vous obtenez le troisième en plus.

L’apprentissage difficile : l’inférence a une courbe de charge qui ne peut pas être déduite de la session d’entraînement. 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 taux horaire à trois chiffres.

Trois tableaux de prix dont chaque tableau FinOps a besoin

Pour contrôler l’inférence multi-cloud, vous avez besoin de trois tableaux de prix en parallèle. Situation à Q2 2026, tous les prix sont donnés à titre indicatif, la situation de négociation par compte doit être vérifiée impérativement.

La plage nominale de facteur 3 entre l’On-Demand hyperscaler 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 soi-même. Qui calcule cela, atterrit à une différence réelle entre le facteur 1,8 et le facteur 2,4.

Tri des charges de travail comme levier FinOps

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

Le tri est efficace dès qu’il est contraignant. Qui le communique comme une recommandation obtient après trois mois la même répartition qu’auparavant, parce que les équipes prennent le chemin de la moindre résistance. Les règles de tri appartiennent dans le workflow de déploiement, pas dans un document Confluence.

De la réserve de bloc à la réserve glissante

La capacité de réserve classique est la mauvaise réponse pour l’inférence GPU. Les engagements de trois ans pour les H100 sont rarement amortis, car la génération de GPU est dépassée en 18 mois. Meilleure architecture : une réserve glissante de 30 à 50 % de réserve comme socle, 20 à 30 % de plans d’épargne pour la flexibilité, le reste à la demande ou en spot.

Ce qui manque souvent dans le plan de maturité : un point explicite sur les délais de livraison. La capacité H100 est encore rare en 2026 dans certaines régions. Qui ne prévoit pas de tampon pour la latence de provisionnement déplace le problème au niveau des opérations.

L’économie unitaire comme devise de contrôle

La discussion FinOps la plus honnête au conseil d’administration ne concerne pas les heures de GPU, mais les coûts par unité de sortie. Trois métriques se sont avérées efficaces dans la pratique : coûts par 1 000 jetons de sortie, coûts par demande utilisateur finalisée, coûts par utilisateur actif et par mois. Laquelle est pertinente dépend du produit.

Un exemple tiré d’une configuration client : une application RAG avec environ 80 000 demandes par jour était à environ 0,034 EUR par demande, dont 0,022 EUR d’inférence, 0,008 EUR de récupération de vecteur, 0,004 EUR de journalisation et d’observabilité. Ce n’est que la ventilation qui a montré que la journalisation représentait une part qui avait augmenté de 18 % par trimestre. La réduction était là, pas dans le modèle.

Qui ne rapporte pas les économies unitaires chaque mois perd le contrôle après deux trimestres. Ensuite, l’ordre de réduction des coûts vient du bureau du directeur financier, et le choix est difficile : réduire le modèle, changer de fournisseur, supprimer des fonctionnalités.

Décisions d’architecture avec le plus grand effet de levier

Trois leviers architecturaux ont un effet supérieur à la moyenne. Premièrement : routage de modèle au niveau de la demande. Toutes les demandes n’ont pas besoin du modèle haut de gamme. Un classificateur à l’avant qui route les demandes simples vers un modèle plus petit ou vers une inférence open source réduit la calcul mixte de 20 à 35 %.

Deuxièmement : mise en cache au niveau de l’incrustation et de la réponse. Dans les cas d’utilisation proches de la FAQ, les demandes répétées se situent souvent dans la plage à deux chiffres. Un cache sémantique avec une TTL contrôlée économise par hit le cycle complet du modèle.

Troisièmement : agrégation par lots au niveau de l’API. Qui envoie des demandes d’inférence individuellement paie le tarif premium par jeton. Qui agrège des micro-lots avec une fenêtre de 50 ms sur la couche de service augmente le débit GPU par heure d’un facteur 2 à 3 sans intervention sur le modèle.

Ces trois leviers ne sont pas spectaculaires. Ils font partie de la routine d’ingénierie. Cela les rend prévisibles et reproductibles.

Ce qui contribue au modèle de maturité FinOps

Trois indicateurs montrent si une équipe maîtrise les coûts d’inférence. Premièrement : la responsabilité FinOps relève de l’ingénierie et non du contrôle. Celui qui vit les examens de coûts comme un audit externe n’a pas de contrôle. Celui qui les pratique comme une norme de revue d’architecture en a un.

Deuxièmement : les coûts de jetons par fonctionnalité sont visibles dans le backlog produit. Les responsables produits qui ne savent pas quelles sont les coûts variables générés par une nouvelle fonctionnalité d’IA planifient à l’aveugle.

Troisièmement : il existe un chemin éprouvé pour changer de modèle. Celui qui reste 18 mois chez un fournisseur sans avoir de chemin de redéploiement documenté paie le supplément de verrouillage sans le voir.

Foire aux questions

La multi-inférence en cloud vaut-elle la peine avec un budget mensuel inférieur à 50 000 euros ?

Rarement. La complexité supplémentaire liée à la fédération d’identités, à la surveillance et au routage VPC ne se justifie que si les économies réalisées dépassent les coûts d’ingénierie par trimestre. Avec un budget mensuel d’environ 50 000 euros, une solution single-hyperscaler avec un mix réservé propre est la démarche la plus pragmatique.

Comment établir un modèle de coût unitaire réaliste ?

Avec trois composantes : les coûts d’inférence par jeton à partir des factures des fournisseurs, les coûts d’infrastructure par demande à partir des données de traçage, les coûts de journalisation et d’observabilité à partir des étiquettes d’allocation de coûts. Si les étiquettes ne sont pas appliquées de manière cohérente, la correspondance est perdue et il faut estimer avec Excel.

Quelle est l’erreur la plus courante lors de la transition vers les néo-clouds ?

Sous-estimer la pile d’identité et de réseau. Les hyperscalers proposent IAM, VPC Peering et Service Mesh comme blocs intégrés. Les néo-clouds exigent que ces blocs soient construits soi-même ou comblés avec des outils inter-cloud. Si cet effort n’est pas planifié, les économies réalisées sont annulées dans les trois premiers mois.

Combien de temps faut-il pour amortir les capacités de GPU réservées en 2026 ?

En cas de taux d’utilisation stable supérieur à 70 %, généralement dans les 8 à 12 mois. En dessous de 50 % d’utilisation, les GPU réservés ne sont plus rentables par rapport à Spot ou On-Demand, car la génération de GPU est renouvelée tous les 18 mois.

Les coûts de GPU peuvent-ils être activés dans le bilan ?

Dans le modèle de location des hyperscalers, ce ne sont généralement pas des coûts activables, ce sont des coûts d’exploitation courants. Avec des GPU propriétaires en co-location ou sur site, une activation est possible, avec les règles d’amortissement correspondantes. D’un point de vue fiscal et comptable, cela devrait être coordonné avec le département financier, car cela implique également des obligations de reporting.

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