Si votre trafic OpenAI passe par LiteLLM, Portkey, Kong AI Gateway ou une passerelle interne, votre modèle d'attribution des coûts est déjà cassé.
Chaque appelant amont est fusionné sous une seule identité de workload, précisément au moment où la dépense démarre. La facturation du fournisseur, les outils FinOps basés sur les tags et les plateformes de coûts cloud sont incapables de redécouper ce coût par service, équipe, fonctionnalité ou client.
C'est l'angle mort des passerelles LLM. Il s'impose rapidement comme un problème central en DevOps et en FinOps for AI, où les dépenses basées sur les tokens et l'infrastructure partagée font voler en éclats les modèles traditionnels d'attribution des coûts.
C'est la faille qui progresse le plus vite dans l'attribution des coûts cloud, et elle suit le même schéma que celui déjà observé avec Kafka, Snowflake et d'autres systèmes partagés. La différence : la dépense est désormais indexée sur les tokens, en forte croissance et directement liée à l'usage produit.
Pourquoi la chaîne se rompt au niveau de la passerelle
Un appel via une passerelle comporte deux sauts :
upstream-svc ──► llm-gateway ──► api.openai.com
L'identité qui vous intéresse se trouve sur le premier saut : service, tenant, fonctionnalité, client.
L'événement facturable, lui, se produit sur le second saut : la consommation de tokens.
Les factures du fournisseur ne voient que l'identité de la passerelle. Une fois cette fusion opérée, les systèmes en aval ne peuvent plus la défaire.
Toutes les sources de données standard se situent après ce point de fusion :
- Les exports de facturation du fournisseur affichent le coût par clé API ou par projet, pas par service
- La facturation cloud ( CUR, GCP, Azure) ne voit pas la dépense OpenAI, ou l'impute encore à la passerelle
- Les outils FinOps basés sur les tags imputent le coût à la ressource qui l'a engagé : llm-gateway
Résultat : un pot commun de coûts d'infrastructure partagée, au lieu d'une unit economics réellement exploitable.
À quoi cela ressemble en pratique
| Vue | Par défaut (fusionné) | Ce dont l'entreprise a besoin |
| Coût par workload | llm-gateway = X $ | Réparti entre les vrais services selon la consommation de tokens |
| Coût par client | Infra partagée | Coût IA par client |
| Coût par fonctionnalité | L'IA semble gratuite | COGS IA réels par fonctionnalité |
| Signal de pricing | % agrégé du coût | Rentabilité au niveau client |
Ce n'est pas qu'un problème de visibilité. Cela impacte directement :
- L'analyse de la rentabilité client
- Les décisions de pricing
- Le ROI des fonctionnalités
- L'optimisation des coûts cloud
Pourquoi le tagging et les logs ne suffisent pas
La plupart des équipes essaient de résoudre le problème avec de la propagation d'en-têtes et des logs. Ça fonctionne en staging. Ça déraille en production.
1. La propagation dérive. Nouveaux services, retries ou chemins alternatifs créent des trous d'attribution. Au fil du temps, une part croissante de la dépense finit dans la catégorie inconnu.
2. Les logs ne sont pas un système de coûts. L'échantillonnage, les limites de rétention et les biais d'ingestion faussent le jeu de données. Joindre les logs à la facturation devient un pipeline fragile.
3. Les appels partagés ne peuvent pas être découpés par tags. Retries, batching, caching et workflows en fan-out font que plusieurs appelants partagent une même requête vers le fournisseur. Les tags ne peuvent pas répartir le coût équitablement. Seule une comptabilité au niveau du token le permet.
4. Les logs passent à côté de l'espace négatif. Appels échoués, retries et fallbacks pèsent tout de même sur les coûts d'infrastructure, mais ne sont pas capturés intégralement.
C'est pourquoi les équipes qui cherchent à répartir les coûts cloud partagés entre microservices sans tagging se retrouvent bloquées. Le tagging réduit l'écart. Il ne le comble pas.
Attribution au runtime : observer la requête, pas la reconstituer
La seule solution fiable consiste à observer le coût au runtime plutôt qu'à le reconstituer depuis les données de facturation.
Attribute™ s'appuie sur un capteur eBPF qui tourne aux côtés de la passerelle et observe les deux côtés de la requête :
- Premier saut : service amont → passerelle (identité préservée)
- Second saut : passerelle → fournisseur (consommation de tokens et coût)
En corrélant les deux, il rattache le coût du fournisseur au workload d'origine sur la base de la consommation réelle de tokens.
Ce qui rend possible :
- Une visibilité des coûts Kubernetes par workload d'origine
- Une attribution des coûts IA au niveau client
- Des COGS IA au niveau fonctionnalité
- Des signaux de coût en temps réel
- Une allocation précise des coûts cloud sans tagging
Les détails d'implémentation qui comptent
- Capteur en lecture seule
- PII et secrets supprimés avant que la moindre donnée ne quitte l'environnement
- Événements OpenTelemetry minimaux en TLS avec authentification JWT
- Compatible avec vos collecteurs OTel existants
- Aucun sidecar, aucun changement de code, aucune modification de configuration de la passerelle
Résultat : le pot commun llm-gateway disparaît. Chaque dollar OpenAI est rattaché à un workload, une équipe, une fonctionnalité et un client.
Checklist d'évaluation
Si vous évaluez des outils FinOps pour l'IA et l'infrastructure partagée, posez ces questions :
- L'outil sait-il répartir le coût de la passerelle par workload d'origine sans propagation de tags ?
- Sait-il attribuer le coût de l'IA aux clients et aux fonctionnalités ?
- Lit-il le trafic en direct ou les exports de facturation ?
- Sait-il répartir les appels partagés au prorata de la consommation de tokens ?
- La télémétrie peut-elle rester à l'intérieur de votre environnement ?
La plupart des outils échouent sur plusieurs de ces points, parce qu'ils démarrent après l'événement de facturation.
Les passerelles LLM cassent l'attribution des coûts précisément là où la dépense commence. Si votre modèle FinOps part des données de facturation, le signal le plus important est déjà perdu. Le seul moyen de le récupérer, c'est d'observer le système pendant qu'il tourne. Toute la différence est là : entre estimer le coût et le comprendre vraiment.