Votre directeur financier vous a demandé de budgéter les appels API aux LLM. Vous avez estimé à partir de vos données de test : 1 000 requêtes par jour, 0,05 $ par requête. Disons 50 $ par jour. Peut-être 1 500 $ par mois.
Puis vous avez déployé en production.
Au deuxième mois, votre facture était de 45 000 $. Au quatrième mois, le conseil d’administration posait des questions.
Ce n’est pas une anomalie. C’est le mode d’échec le plus prévisible dans la planification des coûts en IA. Et ça se passe presque toujours de la même façon.
Là où les calculs déraillent
Votre trafic de production est différent de votre trafic de démo.
Votre démo exécutait probablement une poignée de cas de test soigneusement construits. Les données de production sont plus bruitées, plus remplies de cas limites, et demandent plus de contexte que prévu. Ça change le nombre de tokens immédiatement. Pas de 10 %. Souvent de 2 à 3 fois.
Ajoutez à cela la multiplication invisible : workflows multi-étapes, tentatives de reprise, demandes de clarification, logique de repli, surcharge de tokens liée au découpage et au reclassement.
Une seule requête utilisateur qui ressemble à un appel API est souvent :
- Un appel d’embedding pour trouver le contexte pertinent (1 000 tokens)
- Un appel de récupération pour obtenir les données (500 tokens)
- Un appel de reclassement pour filtrer les résultats (1 000 tokens)
- Un appel d’inférence principal (3 000 tokens en entrée, 1 500 tokens en sortie)
- Un appel de validation pour vérifier la réponse (2 000 tokens)
- Un appel de repli si la première réponse n’était pas assez bonne (3 000 tokens)
Cette seule « requête » a consommé 12 000 tokens. À 0,01 $ par 1 000 tokens sur un modèle de pointe, ça fait 0,12 $ par requête utilisateur. Avec la gestion d’erreurs et les reprises à grande échelle, on se rapproche de 0,15 à 0,20 $.
La plupart des équipes budgètent 0,05 $ et sont choquées à 0,15 $.
Les multiplicateurs invisibles
Les calculs ci-dessus supposent des systèmes efficaces en production. La plupart ne le sont pas, au début.
Surapprentissage des prompts. Vous optimisez un prompt sur votre jeu de test interne, puis vous le déployez. La première semaine de production révèle qu’il hallucine sur les données réelles. Alors vous construisez un prompt plus robuste. Plus de contexte. Plus d’exemples. Plus de tokens.
Boucles de reprise. La production a des défaillances que vos données de test n’avaient pas prévues. Limites de débit, timeouts, cas limites qui font échouer le modèle. Vous ajoutez de la logique de reprise. Un échec devient deux appels API. Deux deviennent trois si la première reprise échoue aussi.
Inflation du contexte. Vous commencez avec une fenêtre de contexte raisonnable. Puis vous réalisez qu’il manque des cas limites. Alors vous ajoutez plus de contexte. Puis encore plus. Au troisième mois, vous envoyez 5 fois le contexte prévu, et le modèle passe 70 % de ses tokens à lire au lieu de raisonner.
Surcharge d’évaluation. Vous devez mesurer si le système fonctionne. Alors vous échantillonnez des réponses et les passez dans un modèle d’évaluation séparé. Encore 1 000 à 2 000 tokens par inférence. Multipliez par votre débit.
Empilement des défenses anti-hallucination. Le modèle génère de fausses certitudes sur 5 % des requêtes. Vous ajoutez des garde-fous — un autre appel au modèle pour valider les sorties. Puis une vérification sémantique. Puis une vérification par règles. Rapidement, vous dépensez autant de tokens en validation qu’en inférence réelle.
Chaque décision a du sens individuellement. Ensemble, elles multiplient la consommation de tokens par 5 à 10 fois.
Le vrai budget
Voici à quoi ressemblent les systèmes d’IA réellement déployés du point de vue des coûts :
- Inférence de base : 30–40 % des tokens
- Récupération et préparation du contexte : 25–35 %
- Évaluation et surveillance : 15–20 %
- Reprises et gestion d’erreurs : 10–15 %
Votre inférence « de base » coûte peut-être 0,05 $ par requête. Mais tout compris, vous êtes à 0,20–0,30 $.
À 10 000 requêtes par jour, ça fait 2 000 à 3 000 $ quotidiennement. Pas 500 $.
La décision de contrôle des coûts
Les équipes qui ne se font pas surprendre prennent des décisions explicites de contrôle des coûts tôt.
Budget de tokens par composant. Combien de tokens pour la récupération ? L’inférence ? La validation ? Fixez des plafonds explicites et respectez-les.
Routage par paliers de modèles. Ne faites pas passer chaque requête par votre modèle de pointe le plus cher. Dirigez 70 % des requêtes vers un modèle plus rapide et moins cher, et réservez le modèle de pointe pour quand vous en avez besoin. Ça seul peut réduire les coûts de 60 à 70 %.
Traitement par lots quand c’est possible. Si vous n’avez pas besoin de réponses en temps réel, traitez par lots pendant la nuit. Des ordres de grandeur moins cher.
Mise en cache de l’intention et du contexte. Ne recalculez pas les embeddings et la récupération pour la même requête deux fois. Cachez agressivement.
Mesurer avant de passer à l’échelle. Obtenez un coût par requête précis avant de monter en charge. La plupart des équipes scalent d’abord et découvrent la structure de coûts après.
Ce que ça signifie
Si vous planifiez de l’IA en production, faites ceci maintenant :
- Calculez le vrai coût par requête avec votre workflow réel — pas juste l’inférence de base
- Intégrez l’attribution des coûts dans votre système dès la première semaine. Mesurez par composant, pas juste le total de tokens
- Fixez des limites de coûts par fonctionnalité et par workflow, puis appliquez-les
- Prévoyez 3 à 5 fois votre estimation initiale dans votre budget
Les équipes qui restent rentables traitent les coûts comme une préoccupation architecturale de premier plan — pas comme quelque chose à régler après le lancement.
Prêt à maîtriser vos coûts d’IA avant qu’ils ne dérapent ? Contactez-nous.