5 patterns de coût LLM qui n'apparaissent qu'à l'échelle
Ce que ta facture à 500 $ ne te dira jamais

À 500 $/mois de dépense LLM, tu t'en fous en gros. À 5 000 $/mois, tu commences à t'en soucier mais tu peux absorber. À 50 000 $/mois, les patterns de coût qui étaient du bruit en bas deviennent la ligne dominante du budget, et ce sont presque toujours des patterns pour lesquels tu n'as pas designé.

On a aidé une douzaine d'équipes à traverser cette transition d'échelle. Les cinq mêmes patterns reviennent systématiquement. Aucun n'est un bug au sens traditionnel. Ce sont des comportements émergents de systèmes LLM qui ne deviennent visibles que quand le volume les force dans la lumière.

Pattern 1 : La long-tail conversation

À 1 000 conversations/jour, ta conversation moyenne a l'air normale, 4-6 tours, peut-être 8K tokens au total. À 100 000 conversations/jour, tu découvres la long-tail : quelques centaines de conversations par jour qui atteignent d'une façon ou d'une autre 40, 80, 200 tours, avec des context windows à 100K+ tokens.

Qui est derrière ça ? Souvent :

• Des power users qui gardent la même conversation ouverte pendant des semaines et continuent à demander
• Des boucles d'agents où ton automatisation appelle le chatbot récursivement
• Des comptes test/QA laissés ouverts toute la nuit, accumulant du contexte
• Des tentatives de scraping, quelqu'un qui découvre qu'il peut extraire de la data d'entraînement en conversant sans fin

Les conversations long-tail sont 0,3 % de ton trafic mais 8-15 % de ta dépense en tokens. À l'échelle, c'est des dizaines de milliers de dollars par mois sur une population que tu n'as pas identifiée.

Le monitor : distribution de longueur de conversation (p50, p95, p99, max). Si ton p99 est 10× ton p50, tu as une queue. Plafonne les conversations à une limite sensée. Préviens les utilisateurs avant que le plafond tombe.

Pattern 2 : La boucle d'abus "free tier"

Si tu as n'importe quelle feature LLM accessible publiquement, trial gratuit, démo, tier freemium, les gens vont abuser. À basse échelle, c'est quelques centimes. À l'échelle, c'est le P&L.

À quoi ça ressemble : un seul utilisateur crée 500 comptes gratuits en un après-midi, écrit un script qui tape ton endpoint free-tier une fois par minute par compte, et extrait une quantité énorme de compute LLM gratuitement. Variantes :

• CAPTCHA contourné avec des services commerciaux
• Comptes derrière des proxies résidentiels pour que tu ne puisses pas fingerprinter par IP
• Numéros de téléphone depuis des farms de vérification SMS

On a eu une équipe qui a découvert que 23 % de leur dépense LLM "free trial" allait vers 14 comptes, tous clusterisés sur un seul ring de fraude. Coût mensuel : 8 200 $. Pour des utilisateurs qui ne paieraient jamais.

Le monitor : burn rate par compte, spécifiquement sur les tiers free/trial. Dispatche un webhook quand un seul compte dépasse la dépense mensuelle de ton utilisateur payant moyen en une journée.

Pattern 3 : La dérive silencieuse de version de prompt

Dans un produit avec 20 ingénieurs, les prompts sont édités par plein de mains. Le PR de quelqu'un ajoute une phrase utile au system prompt. Quelqu'un d'autre ajoute un logging de timestamp. Quelqu'un teste un nouveau trick de formatage en prod "juste pour quelques heures".

Chaque changement invalide des cache hits. Chaque changement ajoute 50 tokens. Chaque changement est individuellement justifiable. Collectivement, ton prompt moyen grossit de 30 % en un trimestre, ton taux de cache hit tombe de 85 % à 45 %, et ta facture grossit de 60 % sans aucun changement d'usage produit.

Le monitor : taille du system prompt dans le temps, et taux de cache hit dans le temps. Alerte si l'un dérive de plus de 15 % semaine-sur-semaine. À l'échelle, ajoute une étape de review de changement de prompt en CI, traite les prompts comme du code parce que c'en est du code.

Pattern 4 : Le noisy neighbor multi-tenant

Si tu fais tourner du trafic LLM pour plusieurs clients sur des clés partagées, tu auras éventuellement un client dont le pattern d'usage est 20× le reste. D'habitude pas parce qu'il est abusif, il a juste une forme de workload différente (documents plus longs, plus d'agents, throughput plus élevé).

Le problème : son usage peut manger tes rate limits. Quand il spike, tes autres clients se font throttle. Sa dépense peut consommer ta capacité cache, faisant tomber le hit rate pour tout le monde. Ses retry loops peuvent cramer du budget que tu destinais aux autres.

Le monitor : burn rate par tenant, latence P99 par tenant, part de la dépense totale par tenant. À l'échelle, déplace les gros tenants vers des clés dédiées (la plupart des providers te les donneront sur demande). Les petits tenants restent sur l'infra partagée.

Pattern 5 : Le tier mismatch silencieux

Quelqu'un, il y a six mois, a mis par défaut ton routing sur Opus pour des "raisons de qualité". Personne n'a réévalué. À bas volume, c'était 40 $/mois de plus que nécessaire. À haut volume, c'est 14 000 $/mois de plus.

Ou : tu es sur un tier rate-limit généreux mais cher, alors que tu pourrais avoir bougé vers un tier moins cher avec un contrat. Ou : tu payes le tarif retail quand le pricing enterprise volume économiserait 25 %. Ou : tu es sur un provider dont le modèle "frontière" est maintenant le 2e meilleur, et tu payes l'ancienne prime pour l'ancien branding.

À l'échelle, la config par défaut n'est jamais la bonne config. Mais la review prend une journée d'ingénierie que personne ne planifie.

Le monitor : aucun. Celui-là c'est du process. Mets un rappel trimestriel pour revoir ta sélection de modèles, ton tier, ton contrat. Une demi-journée par trimestre économise facilement six chiffres par an à 50K+ mensuels.

Ce que ces patterns ont en commun

Chaque pattern ci-dessus a la même signature : invisible à petite échelle, dominant à grande échelle. Tu ne peux pas les voir dans ton env de dev. Tu ne peux pas les voir dans le premier mois de prod. Tu les vois dans la facture, trois mois après, quand les chiffres se sont déjà composés.

Le fix n'est pas "écrire une meilleure app LLM". Le fix est l'observabilité continue, surveiller la distribution, pas juste la moyenne. Quand ton p99 est 20× ton p50, tes moyennes te mentent.

L'angle infrastructure

C'est là qu'une couche middleware gagne son fee à l'échelle. Aucun des cinq monitors ci-dessus n'est dur à construire individuellement. Ce qui est dur c'est de tous les construire, les maintenir, et avoir les bonnes alertes au bon moment sur une flotte de produits.

Chez HiWay, on a tout intégré dans Guardian et le dashboard d'analytics. Pas parce qu'on voulait une liste de features, parce qu'on a tapé exactement ces patterns dans notre propre stack, puis encore chez des clients qu'on aidait. Une fois que tu les as vus trois fois, tu les build une fois et tu les récupères.

Si ta facture LLM est sous 2K $/mois, ne sur-ingénière pas. Tracke le coût journalier, mets une alerte seuil, passe à autre chose. Mais si tu es entre 5K et 50K, les cinq patterns ci-dessus sont là où ton argent fuit. Trouve-les d'abord, optimise ensuite.

---

À lire aussi : Comment on a réduit nos coûts LLM de 85 % et Ce que le prompt caching coûte vraiment.