Ce que coûte vraiment un LLM en production, et cinq leviers qui divisent la facture

Une fonctionnalité IA se prototype en une soirée et se budgète très mal. La démo tourne pour quelques euros par mois ; la même fonctionnalité ouverte au public peut coûter cent fois plus. L'écart ne vient presque jamais du modèle choisi.

J'exploite plusieurs produits dont l'IA est le cœur : un assistant qui trie des emails et rédige devis et factures, un standard téléphonique qui tient une conversation, une analyse d'annonces automobiles qui rend un verdict argumenté. Voici où part réellement l'argent.

Le prompt système coûte plus cher que la réponse

C'est le contre-intuitif fondamental. Sur une fonctionnalité de classification ou d'extraction, la sortie fait 200 tokens. Le prompt système — les consignes, le format de sortie attendu, les exemples, le contexte métier — en fait souvent 3 000. À chaque appel.

Autrement dit : 95 % de ce que vous payez, c'est la partie de la requête qui ne change jamais. C'est aussi une excellente nouvelle, parce que c'est exactement la partie qu'on peut mettre en cache.

Levier 1 — Le cache de prompt

Tous les grands fournisseurs proposent aujourd'hui de mettre en cache le préfixe stable d'une requête. Les tokens ainsi réutilisés sont facturés une fraction de leur prix normal.

La condition est structurelle : le préfixe doit être identique octet pour octet. Ce qui impose une discipline d'écriture précise — tout ce qui est stable en premier, tout ce qui varie ensuite :

[ consignes système ]        ← stable, mis en cache
[ schéma de sortie ]         ← stable, mis en cache
[ exemples ]                 ← stable, mis en cache
─────────────────────────────
[ données de l'utilisateur ] ← variable

Une horodatage glissé en tête du prompt, un identifiant de session, une date au format long : chacun suffit à invalider le cache à chaque appel. C'est l'erreur la plus fréquente, et la plus chère.

Levier 2 — Le cache de résultat

Le cache de prompt réduit le prix d'un appel. Le cache de résultat en supprime le besoin.

Sur une fonctionnalité d'analyse de contenu, une part importante des requêtes porte sur un contenu déjà vu : la même annonce analysée par trois acheteurs, le même email type, la même question. Un hash du texte d'entrée comme clé, la réponse en valeur, et ces appels deviennent gratuits et instantanés.

Le gain dépend entièrement du taux de répétition de votre domaine. Il vaut la peine d'être mesuré avant d'être supposé — dans un sens comme dans l'autre.

Levier 3 — Le bon modèle par tâche

Router toutes les requêtes vers le modèle le plus capable est confortable et coûteux. La plupart des produits mélangent en réalité trois natures de tâches :

• Classer, extraire, router — un petit modèle rapide suffit, pour une fraction du prix.
• Rédiger, reformuler, résumer — un modèle intermédiaire.
• Raisonner, arbitrer, produire un verdict argumenté — là, et là seulement, le modèle haut de gamme se justifie.

Le tri par nature de tâche est presque toujours le levier au meilleur rapport effort/économie. Il ne demande aucune infrastructure, seulement de décider explicitement.

Levier 4 — Le pare-feu de coûts

C'est le levier qui ne réduit pas la facture moyenne, mais qui empêche la facture catastrophique.

Trois plafonds, à trois échelles différentes :

• Un quota par utilisateur, mensuel — la protection contre l'usage anormal.
• Un rate-limit par utilisateur, à la minute — la protection contre la boucle accidentelle côté client, qui n'a rien de malveillant et coûte tout aussi cher.
• Un plafond global journalier — le disjoncteur. Au-delà, la fonctionnalité se dégrade proprement au lieu de continuer à dépenser.

Sans le troisième, un bug d'intégration ou un script tiers peut consommer un budget mensuel en une nuit. Il ne coûte rien à écrire et n'est jamais regretté.

Levier 5 — Traiter la réponse tronquée

Moins un levier de coût qu'un correctif de fiabilité, mais il apparaît dans les mêmes factures : quand la génération atteint la limite de tokens de sortie, le modèle s'arrête au milieu. Si la sortie attendue est du JSON, vous recevez du JSON invalide.

Le mauvais réflexe est de réessayer aveuglément : on paie deux fois pour le même échec. Le bon réflexe est de tester explicitement le motif d'arrêt, et de traiter la troncature comme un cas métier — pas comme une erreur de parsing.

if (response.stop_reason === "max_tokens") {
  // Sortie tronquée : relancer avec une consigne plus courte,
  // ou découper l'entrée — pas réessayer à l'identique.
}

Ce qui ne marche pas

Deux fausses bonnes idées, souvent proposées :

Raccourcir le prompt système à la main. Économiser 300 tokens sur un prompt appelé mille fois par jour représente moins qu'une heure de travail — et dégrade généralement la qualité, donc augmente les reprises. Mettre le prompt en cache rapporte bien davantage sans rien sacrifier.

Auto-héberger un modèle ouvert « pour économiser ». Le calcul ne devient favorable qu'à un volume soutenu et prévisible. En dessous, on paie un GPU à l'heure pour qu'il attende, et on hérite d'une charge d'exploitation — mises à jour, supervision, capacité — qui coûte bien plus que la facture qu'on voulait éviter. C'est un arbitrage de passage à l'échelle, pas un arbitrage de démarrage.

La bonne question

Avant d'optimiser, mesurer une seule chose : le coût par action métier réussie. Pas le coût par appel, pas le coût par token — le coût d'un email correctement classé, d'une annonce analysée, d'un appel qualifié. C'est la seule métrique qui se compare à la valeur produite, et donc la seule qui dise si la fonctionnalité tient économiquement.