Optimisation des tokens : coût, fenêtres de contexte et compression

Les modèles de langage lisent et écrivent des tokens, et vous êtes facturé pour les deux. Optimiser les tokens, c’est les dépenser là où ils améliorent la réponse et nulle part ailleurs. Bien fait, cela réduit le coût et la latence et améliore souvent la qualité, car un prompt ciblé est plus facile à suivre.

Ce qu’est un token

Un token est un fragment de texte du vocabulaire du modèle : un mot, une partie de mot, un signe de ponctuation, ou une espace suivie d’un mot. Pour la prose anglaise, une règle approximative est de quatre caractères, soit trois quarts de mot, par token. Cette règle échoue souvent :

• Le code, le JSON et les identifiants inhabituels utilisent plus de tokens que la prose.
• Les langues autres que l’anglais utilisent souvent plus de tokens par mot.
• Chaque fournisseur a son propre tokeniseur ; un même texte a donc un décompte différent selon le modèle.

Comptez avec le vrai tokeniseur

Les estimations conviennent pour une première idée et sont fausses pour un budget. OpenAI publie ses tokeniseurs ; les décomptes peuvent donc être exacts hors ligne. Anthropic et Google fournissent des points d’accès de comptage de tokens ; sans eux, un décompte n’est qu’une approximation.

PromptFlowEngine suit cette distinction : les décomptes pour les modèles OpenAI sont calculés avec leur tokeniseur et étiquetés comme exacts, tandis que ceux des autres fournisseurs sont étiquetés comme approximatifs. Vous pouvez vérifier un prompt dans l’espace de travail ou via l’API HTTP :

curl -s https://promptflowengine.com/api/v1/tokens \
  -H 'content-type: application/json' \
  -d '{"prompt":"Summarize the notes below in 5 bullets.","model":"gpt-4.1"}'

D’où vient le coût

Le coût par appel est le nombre de tokens d’entrée multiplié par le prix d’entrée, plus le nombre de tokens de sortie multiplié par le prix de sortie. Trois faits façonnent toute optimisation :

1. Les tokens de sortie coûtent généralement plusieurs fois plus cher que les tokens d’entrée. Limiter la longueur de la réponse fait souvent économiser plus que raccourcir le prompt.
2. La partie fixe d’un prompt est payée à chaque appel. Cinquante tokens gaspillés dans un prompt système exécuté un million de fois, ce sont cinquante millions de tokens.
3. Dans une conversation ou une boucle d’agent, l’historique est renvoyé à chaque tour. Le coût croît plus vite que le nombre de tours.

Compression de prompt : que retirer

Allez de la coupe la plus sûre à la plus risquée.

Remplissage et politesses. « Bonjour », « s’il vous plaît », « je voudrais que vous », « il est important de noter que ». Cela ne porte aucune instruction.

Before: Hello! I would like you to please summarize the notes below.
        Please make sure to keep it brief.
After:  Summarize the notes below in 3 sentences.

Répétition. La même instruction énoncée deux fois, souvent dans des sections différentes après des mois de modifications.

Tournures verbeuses. « Afin de » devient « pour ». « En raison du fait que » devient « parce que ».

Contexte inutilisé. Un contexte dont aucun cas de test ne dépend. Retirez-le et relancez vos tests.

Exemples en excès. Essayez trois exemples au lieu de huit et mesurez.

Formats verbeux. Un JSON indenté avec de longues clés coûte plus qu’un JSON compact avec des clés courtes. Pour les données insérées dans un prompt, un format compact économise des tokens à chaque appel.

Les trois premières sont mécaniques. L’optimiseur de prompts PromptFlowEngine les applique et vérifie que chaque phrase, exigence, bloc de code et variable de l’original est toujours présent, ce qui est la partie fastidieuse à contrôler à la main.

Ce qu’il ne faut pas retirer

• Les exigences et contraintes. Un prompt plus court qui abandonne une règle est un autre prompt.
• Le format de sortie. Le retirer économise dix tokens et vous coûte un analyseur.
• Les délimiteurs autour de l’entrée. Ils sont peu coûteux et préviennent l’injection.
• La structure. Les titres de section coûtent quelques tokens et peuvent améliorer le respect des consignes. Un texte sur-compressé, sans articles ni connecteurs, devient ambigu pour le modèle et illisible pour la personne qui le modifiera ensuite.

Optimisation de la fenêtre de contexte

La fenêtre de contexte est le nombre maximal de tokens qu’un modèle peut considérer à la fois, entrée et sortie confondues. Les fenêtres sont devenues très grandes, ce qui a fait passer le problème de « est-ce que ça tient » à « est-ce que ça doit y être ».

Plus de contexte n’est pas gratuit. Outre le coût et la latence, la qualité peut baisser quand l’entrée grossit : un passage pertinent entouré de milliers de tokens hors sujet est plus difficile à exploiter pour le modèle. Envoyez ce dont la tâche a besoin.

Récupérez plutôt que tout inclure. Cherchez les passages pertinents pour la question et n’insérez que ceux-là. Voir le prompting pour RAG.

L’ordre compte dans les longs prompts. De nombreux modèles accordent plus d’attention au début et à la fin d’une longue entrée. Placez les longs documents en premier et la question ou les instructions après, ou répétez l’instruction clé à la fin.

Gérez l’historique de conversation. Résumez les anciens tours, supprimez les résultats d’outils devenus inutiles et ouvrez une nouvelle conversation quand le sujet change.

Réservez de la place pour la réponse. Si l’entrée remplit la fenêtre, la sortie est tronquée. Laissez de la place pour la réponse la plus longue que vous attendez.

Découpez le travail. Une chaîne de prompts donne à chaque étape seulement le contexte dont elle a besoin.

Utilisez le cache

Les principaux fournisseurs proposent la mise en cache de prompts : quand le début d’un prompt correspond à une requête récente, la partie répétée est facturée à tarif réduit et traitée plus vite. Pour en profiter :

• Placez le contenu stable en premier : prompt système, définitions d’outils, exemples, documents de référence.
• Placez le contenu variable en dernier : la question de l’utilisateur et les données propres à chaque requête.
• Évitez de modifier quoi que ce soit dans la partie stable, comme un horodatage, entre les appels.

Le cache rend un long prompt fixe beaucoup moins cher. Il n’annule pas le coût en qualité d’un contexte hors sujet.

Contrôlez la longueur de sortie

• Donnez un nombre : « moins de 100 mots », « exactement 5 puces ».
• Ne demandez que ce dont vous avez besoin : une étiquette, pas une étiquette avec explication.
• Réglez le nombre maximal de tokens de sortie de l’API comme arrêt strict.
• Pour les modèles de raisonnement, baissez l’effort de raisonnement sur les tâches simples.

Fixez un budget et appliquez-le

Décidez du nombre de tokens que peut utiliser chaque prompt de production et vérifiez-le automatiquement. La barrière de test de prompts fait échouer un build quand un fichier de prompt dépasse sa limite de tokens :

{ "include": ["prompts/**/*.md"], "model": "gpt-4.1", "maxTokens": 1500 }

Cela transforme la croissance des tokens, qu’on découvrait sur une facture, en quelque chose qu’on relit dans une pull request. Pour le processus plus large d’amélioration d’un prompt par la mesure, voir l’optimisation de prompts.