On s’habitue vite aux API LLM. On branche, on envoie un prompt, ça répond. Et puis un matin… la facture. Pas forcément énorme au début, mais assez pour te faire tiquer. Surtout si tu as un produit qui scale, des tests A B, des agents qui bavardent trop, ou juste un script d’automatisation qui tourne en boucle.
Le truc, c’est que « réduire les coûts » ne veut pas dire « rendre le modèle nul ». Ça veut dire apprendre à parler au modèle avec moins de bruit. Moins de tokens. Moins d’allers retours. Et donc moins d’argent qui part en fumée.
Dans cet article, je te partage une approche très terrain, orientée prompt engineering pour API, avec des exemples, des patterns, et des petites habitudes qui font une grosse différence sur la durée. Et oui, c’est le genre de contenu que je garde et j’itère aussi sur Le Blog Tech Pro de Samyn-Antoy ABASSE (si tu veux d’autres checklists et workflows du même style, tu peux aller fouiller sur https://monblog-sa-abasse.blogspot.com).
Pourquoi les tokens coûtent si cher (et pourquoi on en consomme autant)
Un token, c’est grosso modo un morceau de texte. Parfois un mot. Parfois un bout de mot. Et en API, tu payes en général deux choses :
- les tokens en entrée (ton prompt, tes instructions, ton contexte, ton historique)
- les tokens en sortie (la réponse)
Et ce qui plombe souvent un budget, ce n’est pas « une réponse un peu longue ». C’est plutôt :
- des prompts système énormes copiés collés partout
- des historiques de conversation empilés sans limite
- des documents complets passés à chaque requête « au cas où »
- des consignes redondantes (et répétées à chaque call)
- des sorties non bornées (le modèle continue parce qu’il peut)
C’est bête mais courant.
Mesurer avant d’optimiser (sinon tu vas optimiser au hasard)
Avant de toucher aux prompts, il faut voir ce qui se passe vraiment.
Ce que je recommande, même sur un petit projet :
- logger
input_tokens,output_tokens,total_tokenspar endpoint - logger la latence (souvent corrélée au volume)
- logger le taux de réponses « inutiles » (par exemple : réponses trop longues, hors format, reformulations)
Tu peux faire ça dans un middleware, un reverse proxy, ou directement dans ton code.
Un exemple de log minimal (pseudo) :
json { "route": "/summarize", "model": "xxx", "input_tokens": 1240, "output_tokens": 380, "total_tokens": 1620, "ms": 2410, "status": 200 }
Deux jours de logs et tu sais déjà où taper.
Règle numéro 1 : réduire le contexte, pas l’intention
On croit souvent que pour réduire les tokens, il faut enlever des instructions. Mauvaise idée. En fait, tu veux enlever le blabla, pas l’objectif.
Ce qui marche bien :
- une instruction courte, nette, non ambiguë
- un format de sortie strict
- un contexte minimal, ciblé, récupéré à la demande
Le modèle n’a pas besoin de « tu es un expert mondial depuis 20 ans ». Ça flatte. Ça consomme. Et ça n’ajoute pas grand chose.
À la place :
- rôle
- tâche
- contraintes
- format
- critères de qualité
C’est tout.
Pattern 1 : prompts compacts, réutilisables, versionnés
Si tu fais de l’API, tu vas vite avoir 5, 10, 30 prompts. Et là, les dérives arrivent.
Ce que je fais souvent :
- un prompt système court, stable, versionné (
prompt_v3) - des instructions de tâche dans le message user
- des paramètres explicites (langue, ton, longueur)
Exemple « système » compact :
text Tu es un assistant de production. Réponds uniquement avec le format demandé. Si info manquante : retourne "NEED_INPUT".
Et ensuite côté user :
text Tâche : résumer le texte. Contraintes : 5 puces max, 1 phrase par puce, français. Texte : ... Format : JSON { "bullets": [...] }
Ça coûte moins cher qu’un roman d’instructions. Et surtout, ça se contrôle.
Pattern 2 : borner la sortie (sinon tu payes la prose)
Ça paraît évident, mais c’est probablement le levier le plus rentable.
À faire systématiquement :
- limiter
max_output_tokens(ou équivalent) - demander une longueur cible (ex : 80 mots)
- imposer un format fermé (JSON, YAML minimal)
- interdire les explications si tu n’en as pas besoin
Exemple d’instruction :
text Réponds en 120 mots maximum. Pas d’introduction. Pas de conclusion.
Ou encore :
text Retourne uniquement un JSON valide. Aucune phrase hors JSON.
Tu gagnes des tokens et tu simplifies le parsing. Double bénéfice.
Pattern 3 : éviter l’historique complet, passer à un état minimal
Beaucoup d’apps chat envoient tout l’historique à chaque tour. C’est simple. Mais ça explose.
À la place, tu peux :
- faire un résumé d’état (state summary)
- garder uniquement les 3 derniers tours utiles
- stocker les infos importantes côté serveur (pas dans le prompt)
Exemple : au lieu de renvoyer 20 messages, tu renvoies :
text État : utilisateur veut une landing page SaaS, ton direct, cible freelances. Offre : audit SEO. CTA : prise de rendez-vous. Dernière demande : proposer 5 titres.
Ça tient en quelques dizaines de tokens. Et tu gardes le contrôle.
Pattern 4 : RAG sobre, ou comment arrêter d’envoyer des PDFs entiers
Le classique : on colle un document énorme dans le prompt et on demande « réponds avec ça ». Ça marche. Une fois. Et ensuite tu pleures.
Approche plus propre :
- chunking (découper)
- embeddings + recherche
- n’injecter que les passages pertinents (top k)
- demander des citations courtes si nécessaire
Le prompt devient :
text Contexte (extraits pertinents) : [1] ... [2] ...
Question : ... Contraintes : répondre en 6 lignes max.
Ce qui réduit l’entrée, donc le coût, donc la latence aussi.
Petit détail qui change tout : réduis la taille des chunks si ton retrieval est bon. Beaucoup de gens chunkent trop gros « par sécurité ». Et ça repasse à la caisse à chaque fois.
Pattern 5 : compresser le texte avant envoi (oui, parfois c’est ok)
Selon ton cas d’usage, tu peux pré traiter le texte :
- supprimer les balises HTML
- enlever menus, footers, répétitions
- enlever les stop sections (ex : « cookie policy », « related posts »)
- normaliser les espaces
Pour du résumé ou de l’extraction, tu n’as pas besoin de la mise en forme.
Tu peux même faire une passe de « nettoyage » côté code, sans LLM, et économiser énormément.
Pattern 6 : demander de l’extraction, pas de la réécriture
La réécriture pousse le modèle à produire beaucoup. L’extraction, beaucoup moins.
Si ton besoin est :
- récupérer des champs
- classifier
- détecter des intentions
- extraire des entités
Alors formule le prompt en mode extraction structurée.
Exemple :
text Extrait du texte les champs suivants : nom, email, problème principal. Retourne uniquement JSON. Si un champ manque : null.
Le modèle sort 30 tokens au lieu de 300.
Pattern 7 : faire du « cascading » de modèles
Tu n’es pas obligé d’envoyer toutes les requêtes sur le modèle le plus cher.
Une stratégie simple :
- modèle cheap pour filtrer, router, classifier
- modèle plus costaud uniquement si nécessaire
Exemples de routage :
- si la demande est « simple FAQ » : petit modèle
- si la demande nécessite raisonnement long, code, plan détaillé : modèle plus puissant
- si faible confiance (score interne) : escalade
Même un classif basique te fait économiser beaucoup si tu as du volume.
Pattern 8 : utiliser des prompts négatifs (mais courts)
Les gens abusent des listes « ne fais pas ceci, ne fais pas cela ». Ça gonfle. Mais une petite contrainte négative bien posée est rentable.
Exemples :
- « pas de préambule »
- « pas de justification »
- « pas de répétition du contexte »
- « pas de markdown »
C’est court, ça coupe des paragraphes entiers.
Pattern 9 : éviter les métaprompts et les longs cadres « persona »
Le « tu es un consultant McKinsey + un poète + un prof »… ça consomme, et en API ça se paye cash.
Si tu veux un style, décris le style, pas le personnage.
Exemple :
text Style : phrases courtes, ton direct, vocabulaire simple, zéro jargon.
C’est largement suffisant.
Exemple concret : avant après (même tâche, facture différente)
Tâche : générer une réponse support à un client.
Avant (coûteux)
- long prompt système de 400 tokens
- historique complet
- réponse non bornée
Résultat : 1200 tokens entrée, 500 sortie.
Après (optimisé)
Système :
text Assistant support. Respecte le format. Si info manquante : NEED_INPUT.
User :
text Contexte : client a payé, accès non reçu. But : répondre, rassurer, donner étapes. Contraintes : 90 mots max, ton pro, français. Format : JSON { "reply": "..." }
Résultat : 220 tokens entrée, 120 sortie.
Ça paraît petit. Mais sur 50 000 tickets, ça devient énorme. Vraiment énorme.
Petites techniques bonus qui marchent mieux qu’on croit
Utiliser des abréviations internes (quand c’est contrôlé)
Si tu as un backend et que tu contrôles tes prompts, tu peux définir un mini langage.
Exemple :
text Règles : T=ton direct L=limite 80 mots F=JSON
Puis :
text Tâche : reply_support Params : T,L,F Input : ...
Ça économise un peu. Pas magique, mais sur du volume ça compte.
Mutualiser les instructions côté serveur
Si ton frontend envoie des prompts complets, tu perds le contrôle et tu doubles les coûts.
Mieux :
- le client envoie juste les données (payload)
- le serveur reconstruit le prompt versionné
C’est aussi une question de sécurité. Et de gouvernance.
Couper les réponses dès qu’elles sont complètes
Certaines API permettent du streaming. Tu peux arrêter quand ton JSON est complet, ou quand tu as reçu le nombre de puces demandé.
Tu ne payes pas les tokens non générés. Et tu gagnes en latence.
Checklist rapide : réduire les tokens en 30 minutes
- logger tokens entrée sortie par route
- ajouter
max_output_tokens - imposer un format de sortie fermé (JSON)
- supprimer les personas longs
- résumer l’historique en état minimal
- passer en RAG et injecter seulement top k extraits
- nettoyer le texte (HTML, boilerplate) avant envoi
- router les demandes simples vers un modèle moins cher
Si tu appliques juste les trois premiers points, tu verras déjà une baisse.
Conclusion : moins de tokens, c’est aussi plus de clarté
Au fond, le prompt engineering pour API, ce n’est pas juste de la tambouille pour économiser 3 centimes. C’est une discipline de clarté.
Quand ton prompt est court, tu vois tout de suite ce que tu demandes. Tu détectes les contradictions. Tu limites les sorties inutiles. Et tu maîtrises ton produit.
Si tu veux, je peux publier une version « template » de prompts compacts, versionnés, avec quelques patterns RAG et routage, sur Le Blog Tech Pro de Samyn-Antoy ABASSE. Passe y faire un tour, il y a aussi des pages services et des méthodes de travail que je mets à jour au fil des projets : https://monblog-sa-abasse.blogspot.com
Et toi, la plus grosse source de gaspillage tokens dans ton app, c’est quoi. L’historique. Les docs. Les sorties trop longues. Ou un prompt système trop bavard.
Questions fréquemment posées
Pourquoi les coûts liés aux tokens dans les API LLM peuvent-ils rapidement augmenter ?
Les coûts augmentent principalement parce que vous payez pour les tokens en entrée (prompts, contexte, historique) et en sortie (réponses). Des pratiques comme des prompts système trop longs, des historiques de conversation sans limite, ou des documents complets envoyés à chaque requête font exploser la consommation de tokens et donc la facture.
Comment mesurer efficacement la consommation de tokens avant d'optimiser mes prompts ?
Il est crucial de logger les input_tokens, output_tokens, et total_tokens par endpoint, ainsi que la latence et le taux de réponses inutiles. Ces données peuvent être collectées via un middleware, un reverse proxy ou directement dans votre code. Cela permet d'identifier précisément où optimiser sans agir au hasard.
Quelle est la règle numéro 1 pour réduire les coûts liés aux tokens sans sacrifier la qualité du modèle ?
La règle principale est de réduire le contexte inutile tout en conservant l'intention claire. Il faut privilégier une instruction courte, nette et non ambiguë avec un format de sortie strict et un contexte minimal ciblé. Évitez les longues descriptions flatteuses qui consomment beaucoup de tokens sans valeur ajoutée.
Quels sont les éléments essentiels à inclure dans un prompt optimisé pour l'API LLM ?
Un prompt optimisé inclut : le rôle du modèle, la tâche à accomplir, les contraintes spécifiques, le format attendu et les critères de qualité. Ces éléments suffisent à guider efficacement le modèle tout en limitant la consommation excessive de tokens.
Comment gérer plusieurs prompts dans une application utilisant l'API LLM pour éviter les dérives ?
Il est recommandé d'utiliser des prompts compacts, réutilisables et versionnés. Par exemple, maintenir un prompt système court et stable (ex: prompt_v3), ajouter des instructions spécifiques dans le message utilisateur, et utiliser des paramètres explicites comme la langue, le ton ou la longueur pour garder un contrôle précis sur chaque interaction.
Quels bénéfices apporte une approche orientée 'prompt engineering' pour réduire les coûts API tout en gardant une bonne qualité ?
L'approche 'prompt engineering' permet d'apprendre à communiquer avec le modèle de manière efficace : moins de bruit, moins de tokens consommés, moins d'allers-retours inutiles. Cela réduit significativement les coûts sans dégrader la performance du modèle grâce à des prompts bien conçus, ciblés et structurés.
0 Commentaires