FinOps pour l'IA : instrumenter le coût par token avant que la facture GPU ne dérape

Pendant dix ans, le FinOps a appris à découper une facture cloud en instances, en volumes de stockage et en gigaoctets sortants. Ces objets avaient une propriété précieuse : ils étaient stables, dimensionnables à l’avance et attribuables à une équipe. L’IA générative casse ces trois hypothèses en même temps. Un token n’est pas une instance, une requête d’inférence n’est pas un appel S3, et un cluster GPU réservé coûte le même prix qu’il tourne à 12 % ou à 85 % d’occupation.

Le constat chiffré : une bascule plus rapide que l’outillage

Les données du State of FinOps 2026 décrivent une adoption brutale : 98 % des répondants déclarent gérer désormais une dépense liée à l’IA, contre 63 % en 2025 et 31 % en 2024. Chez les organisations les plus avancées sur le sujet, le GPU représente environ 18 % de la dépense cloud, contre 4 % en 2023. L’IA est la catégorie de coût qui croît le plus vite, et « AI Cost Management » est la compétence la plus recherchée par les équipes FinOps.

Deux nuances comptent plus que les pourcentages eux-mêmes.

D’abord, cette dépense s’ajoute au cloud existant, elle ne le remplace pas. Aucun budget de machines virtuelles n’a été coupé pour financer les GPU : les workloads d’inférence viennent en surcouche d’un patrimoine applicatif inchangé. Les arbitrages se font donc à budget global croissant, ce qui masque temporairement l’inefficacité.

Ensuite, la vague est arrivée avant l’outillage, la gouvernance et les compétences. C’est pourquoi la visibilité sur les coûts IA est citée comme le premier défi, devant l’allocation par unité métier et la mesure du ROI. Ce n’est pas un problème d’optimisation : c’est un problème de mesure.

Pourquoi votre outillage FinOps actuel ne suffit pas

Le cœur du problème est structurel. Trois modèles de tarification coexistent, avec des granularités incompatibles :

• Le token (API managées), facturé différemment en entrée et en sortie, avec des variantes selon le cache de prompt, le raisonnement étendu ou les appels d’outils ;
• La GPU-heure (instances accélérées, endpoints managés), facturée à la réservation, indépendamment du travail réellement effectué ;
• La requête d’inférence (services serverless de type endpoint), parfois pondérée par la durée de calcul.

Aucun de ces trois modèles ne se projette proprement sur les schémas de facturation FOCUS ou les exports de coûts natifs. Un appel LLM apparaît comme une ligne agrégée par jour et par service, sans dimension applicative. Résultat : votre showback s’arrête au niveau du compte cloud, pas de l’équipe.

S’ajoutent deux facteurs aggravants :

1. Les ressources partagées. Un même endpoint sert le chatbot support, l’assistant interne et trois notebooks de data science. La clé d’API est commune, la facture aussi.
2. Les pilotes exploratoires. Une part significative de la dépense IA correspond à des expérimentations sans propriétaire clair, sans budget dédié et sans date de fin. Elles ne « ratent » jamais officiellement : elles continuent de tourner.

Construire la visibilité : du tag au coût par requête utile

La première étape est ingrate mais non contournable : rendre chaque euro attribuable.

Attribuer les workloads GPU

Sur Kubernetes, cela suppose une convention de labels appliquée par politique d’admission, pas par bonne volonté. Un déploiement d’inférence non labellisé doit être rejeté.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rag-answering-service
  labels:
    finops.company.io/product: support-assistant
    finops.company.io/cost-center: "CC-4412"
    finops.company.io/env: prod
    finops.company.io/workload-type: inference   # vs training | batch | experiment
spec:
  template:
    spec:
      containers:
        - name: vllm
          resources:
            limits:
              nvidia.com/gpu: "1"

Ces labels alimentent ensuite un moteur d’allocation (OpenCost, Kubecost ou un pipeline maison) capable de ventiler le coût des nœuds GPU au prorata des pods.

Mesurer l’occupation réelle, pas la capacité réservée

C’est la métrique qui révèle le gisement d’économies le plus important. L’exporter DCGM expose l’occupation des SM et la mémoire utilisée ; le rapprochement avec la capacité réservée donne le taux de gaspillage.

# Occupation moyenne des GPU par produit, sur 7 jours
avg by (product) (
  avg_over_time(
    DCGM_FI_DEV_GPU_UTIL{}[7d]
  )
  * on(pod) group_left(product)
    kube_pod_labels{label_finops_company_io_product!=""}
)

# GPU-heures réservées mais inutilisées (< 5 % d'occupation)
sum by (product) (
  count_over_time(DCGM_FI_DEV_GPU_UTIL < 5 [7d])
) / 60

Instrumenter le coût par token et par requête utile

Pour les API managées, l’unité de mesure doit être portée par l’application elle-même. Un middleware d’une trentaine de lignes suffit à transformer chaque appel en événement de coût attribuable.

from dataclasses import dataclass
from opentelemetry import metrics

meter = metrics.get_meter("llm.cost")
cost_counter = meter.create_counter("llm.cost.usd")
token_counter = meter.create_counter("llm.tokens")

@dataclass(frozen=True)
class Pricing:
    input_per_mtok: float   # USD / million de tokens d'entrée
    output_per_mtok: float  # USD / million de tokens de sortie

PRICING: dict[str, Pricing] = {
    # À alimenter depuis la grille tarifaire du fournisseur, versionnée.
    # "vendor/model": Pricing(input_per_mtok=..., output_per_mtok=...),
}

def record_usage(model: str, usage, *, product: str, feature: str,
                 tenant: str, outcome: str) -> float:
    p = PRICING[model]
    cost = (usage.input_tokens / 1e6) * p.input_per_mtok \
         + (usage.output_tokens / 1e6) * p.output_per_mtok

    attrs = {"model": model, "product": product, "feature": feature,
             "tenant": tenant, "outcome": outcome}
    cost_counter.add(cost, attrs)
    token_counter.add(usage.input_tokens, {**attrs, "kind": "input"})
    token_counter.add(usage.output_tokens, {**attrs, "kind": "output"})
    return cost

L’attribut outcome est le plus important et le plus souvent oublié. Il distingue une réponse acceptée par l’utilisateur d’un retry, d’un timeout ou d’une réponse rejetée par un garde-fou. Sans lui, vous mesurez un coût par token ; avec lui, vous mesurez un coût par requête utile, seule métrique qui permet ensuite de discuter ROI avec le métier. Une baisse du coût par token accompagnée d’une hausse du taux de retry est une régression, pas un gain.

Les leviers d’optimisation, par rapport effort/gain

Certaines analyses avancent 30 à 40 % d’économies pour les organisations dotées d’une pratique FinOps spécifique à l’IA. Le chiffre dépend évidemment du point de départ, mais l’ordre des leviers, lui, est assez stable.

1. Le taux d’occupation des GPU. C’est presque toujours le premier gisement. Les déploiements statiques dimensionnés sur le pic, laissés en 24/7 pour des usages ouvrables, ou un GPU entier pour un modèle d’embedding de 300 Mo. Les remèdes sont peu coûteux en ingénierie : scale-to-zero sur les environnements hors production, consolidation de plusieurs petits modèles sur un même GPU via MIG ou time-slicing, planification des jobs d’entraînement sur des instances spot.

2. Le batching et la mise en cache. Le continuous batching des serveurs d’inférence modernes (vLLM, TGI, TensorRT-LLM) augmente fortement le débit à matériel constant. Côté API, la mise en cache de prompt sur les préfixes système longs et un cache sémantique en amont sur les requêtes récurrentes réduisent directement le volume facturé. Attention toutefois : un cache mal invalidé transfère un problème de coût vers un problème de qualité.

3. Le routage de modèles et la quantification. Tous les appels ne méritent pas le modèle le plus capable. Un routeur qui envoie les classifications et les reformulations vers un petit modèle, en réservant le grand modèle aux cas complexes, produit des gains rapides — à condition d’être adossé à une suite d’évaluation. En auto-hébergement, la quantification (INT8, FP8, AWQ/GPTQ) réduit l’empreinte mémoire et augmente le débit ; elle exige de mesurer la dégradation qualité sur vos propres jeux d’évaluation, pas sur des benchmarks publics.

4. Les engagements de capacité. Instances réservées, savings plans ou capacity blocks n’ont de sens qu’une fois la charge stabilisée et le dimensionnement assaini. Réserver de la capacité sur un workload sous-utilisé revient à contractualiser son propre gaspillage sur un ou trois ans.

API managée ou auto-hébergement : poser le calcul, pas l’idéologie

L’auto-hébergement paraît toujours moins cher au tableur, parce que le tableur oublie l’ingénierie. Le coût réel d’un endpoint auto-hébergé inclut la disponibilité, l’astreinte, la mise à jour des serveurs d’inférence, l’évaluation à chaque changement de modèle et le sur-provisionnement nécessaire pour absorber les pics.

Le raisonnement doit donc porter sur un coût complet, comparé à un volume soutenu :

def monthly_self_hosted_cost(gpu_hourly: float, gpu_count: int,
                             utilization: float, fte_fraction: float,
                             fte_monthly_cost: float) -> float:
    """utilization : part du mois où la capacité est réellement nécessaire.
    On paie la capacité réservée, pas l'usage : le dénominateur, pas le numérateur."""
    infra = gpu_hourly * gpu_count * 730          # capacité réservée
    ops = fte_fraction * fte_monthly_cost         # ingénierie et astreinte
    return infra + ops

def monthly_api_cost(mtok_in: float, mtok_out: float,
                     price_in: float, price_out: float) -> float:
    return mtok_in * price_in + mtok_out * price_out

Deux enseignements de ce cadrage. D’une part, l’API reste souvent l’option la moins chère une fois le coût d’ingénierie intégré, en particulier pour des charges irrégulières : vous ne payez que l’usage, le fournisseur absorbe le sur-provisionnement. D’autre part, l’auto-hébergement devient défendable à partir d’un volume soutenu se comptant en millions de tokens par mois, sur un trafic régulier et prévisible — ou lorsque la souveraineté des données, la latence garantie ou un fine-tuning propriétaire pèsent davantage que l’euro par token. Un pic ponctuel ne justifie jamais un cluster permanent.

Shift-left : chiffrer une architecture avant de la déployer

C’est l’un des problèmes non résolus de la discipline. Personne ne sait aujourd’hui estimer proprement le coût d’une architecture RAG avant son déploiement, parce que le coût dépend de variables comportementales : longueur moyenne des prompts, nombre de documents injectés dans le contexte, taux de retry, profondeur des chaînes d’agents.

Une approximation utile reste possible dès la conception :

coût_mensuel ≈ requêtes/mois
             × (tokens_système + k_documents × tokens_par_document + tokens_utilisateur) × prix_entrée
             + requêtes/mois × tokens_sortie_moyens × prix_sortie
             × (1 + taux_de_retry)

Un simple tableur appliquant cette formule, exigé dans la revue d’architecture au même titre qu’un schéma de sécurité, suffit à écarter les conceptions structurellement intenables — typiquement les chaînes d’agents à plusieurs dizaines d’appels par interaction utilisateur. Il révèle aussi les variables sensibles : c’est presque toujours k_documents et la taille du prompt système qui dominent la facture, pas le modèle choisi.

Reste la question managériale. Une équipe qui divise par trois le coût par requête n’a livré aucune fonctionnalité ce trimestre-là. Si votre système d’évaluation ne valorise que la livraison, cet effort ne se produira pas. L’efficience doit apparaître dans les objectifs produit, avec une métrique explicite — coût par requête utile, ou coût par utilisateur actif mensuel — au même rang que la latence p95.

Une trame de gouvernance pragmatique

Quatre éléments suffisent à couvrir l’essentiel :

• Un budget et des alertes par produit, pas par compte cloud. Le seuil d’alerte utile est un seuil de dérive relative (par exemple +40 % sur sept jours glissants), pas un plafond mensuel absolu qui se déclenche le 28 du mois.
• Une revue mensuelle du coût par requête utile, par produit, avec la tendance du taux d’occupation GPU en regard. Trente minutes, avec les responsables produit, pas uniquement la finance.
• Des garde-fous techniques dans le code : quotas par tenant et par clé, limite dure sur la taille de contexte, plafond de tokens de sortie, budget d’appels par chaîne d’agent. Un garde-fou déclaré dans une politique interne mais absent du code n’existe pas.
• Une date d’expiration sur les pilotes. Tout endpoint exploratoire est créé avec un TTL et un propriétaire nommé ; sans renouvellement explicite, il est arrêté.

Le retard d’outillage se comblera : les plateformes FinOps intègrent progressivement les métriques de tokens et l’allocation GPU. Mais aucun outil n’inventera l’attribut product que votre code n’a pas émis, ni ne saura distinguer une réponse utile d’un retry si votre application ne l’a pas signalé. L’instrumentation est du ressort des équipes de développement, et elle doit être posée pendant que les volumes sont encore modestes — c’est-à-dire maintenant, tant que la facture reste un sujet d’ingénierie plutôt qu’un sujet de comité de direction.