Comprendre les budgets de tokens IA : préparer prompts, documents et coûts API avant l'envoi

Une requête à un modèle d’IA se limite rarement à un prompt. Les applications ajoutent des instructions, les échanges précédents, des documents, des schémas JSON et des définitions d’outils. Une requête qui paraît courte dans un éditeur peut occuper beaucoup plus de contexte une fois tous ces éléments réunis.

Mesurez le texte avec un tokenizer adapté au modèle, gardez de la place pour la réponse et distinguez l’estimation locale de ce que le fournisseur de l’API facturera. Le compteur de tokens IA et inspecteur de contexte peut vous aider à préparer ce budget. Notre présentation du compteur de tokens en donne un aperçu ; cet article détaille les choix à faire pour planifier vos requêtes.

Pourquoi mots, caractères et tokens sont différents

Les tokenizers découpent le texte selon un vocabulaire précis. Des mots courants peuvent tenir dans un token ; les noms inhabituels, la ponctuation, le code et certaines langues peuvent se répartir sur plusieurs tokens. Un saut de ligne ou un espace peut aussi influencer l’encodage du texte qui suit.

Quelques exemples montrent pourquoi compter les mots ne suffit pas :

• Un paragraphe de prose peut se découper différemment d’un bloc JSON de même longueur.
• L’indentation et les noms de champs répétés ajoutent du texte au compte.
• Les émojis, les caractères accentués et les systèmes d’écriture non anglophones ne suivent pas une règle de conversion de mots anglais en tokens.
• Deux familles de modèles peuvent utiliser des tokenizers différents pour un texte identique.

Le compteur Web2Generators propose o200k_base et cl100k_base. Choisissez l’encodage correspondant à votre modèle, sans considérer l’un ou l’autre comme une norme universelle. Les noms 100k et 200k désignent des familles de vocabulaires, pas une fenêtre de contexte de 100 000 ou 200 000 tokens.

Un outil local compte le texte exact que vous lui fournissez. Une requête API réelle peut ajouter le format des messages, des schémas d’outils, du contenu multimodal et d’autres éléments propres au fournisseur. Si celui-ci propose une API de comptage, utilisez-la pour vérifier la requête complète, puis comparez le résultat à l’usage indiqué après son exécution.

Étape 1 : distinguer les parties de la requête

Avant de raccourcir quoi que ce soit, identifiez les sources du contexte. Pour un assistant de support, la requête peut comprendre les éléments suivants :

N’envoyez pas de données clients confidentielles ou de secrets à un service tiers simplement pour les mesurer. Le compteur Web2Generators traite le texte localement dans le navigateur. Respectez néanmoins les règles de votre organisation, notamment avant d’exporter un rapport qui contient ce texte.

Étape 2 : assembler le contexte plutôt qu’additionner les comptes

Supposons qu’une application construise son prompt à partir de quatre blocs. Voici un exemple en anglais :

INSTRUCTIONS
You are a support assistant. Answer only from the supplied policy.

HISTORY
Customer: Can I change the delivery address?
Assistant: Please confirm whether the order has shipped.

DOCUMENT
Address changes are available before dispatch.

QUESTION
My order has not shipped. Can I update the address?

Les séparateurs et les titres font partie de la requête. Mesurez le texte assemblé, pas seulement quatre extraits comptés séparément. Les limites des tokens peuvent changer à la jonction des blocs ; la somme des comptes individuels peut donc différer du compte final.

Dans le compteur, choisissez Préparer le contexte, saisissez les blocs réels et définissez une capacité cible. L’outil assemble les blocs non vides dans l’ordre affiché, avec deux sauts de ligne entre eux. Si votre application ajoute d’autres délimiteurs, comptez aussi sa représentation finale exacte.

Le compteur ne crée pas automatiquement les objets de messages d’une API de conversation et ne calcule pas tous les surcoûts liés à leur format. Vous pouvez ainsi inspecter le texte que vous contrôlez sans supposer qu’il représente toute la requête réseau.

Étape 3 : réserver les tokens de sortie avant de remplir l’entrée

Prenons une capacité de contexte purement illustrative de 32 000 tokens :

La règle de calcul est simple :

remaining = capacity - input_text - output_reserve - overhead_allowance

Dans cet exemple, input_text vaut 22 000 tokens. La réserve de sortie est un espace prévu, pas une affirmation que chaque appel produira autant de tokens. La marge supplémentaire reste elle aussi une estimation. Les limites de contexte, les limites de réponse de l’API, le raisonnement et le décompte des entrées varient selon le fournisseur et le modèle.

Si le résultat devient négatif, réduisez ou sélectionnez l’entrée avant d’envoyer la requête. Ne résolvez pas un dépassement de contexte en supprimant silencieusement le message actuel de l’utilisateur ou en raccourcissant une instruction de sécurité essentielle.

Étape 4 : réduire le superflu sans perdre l’information utile

Un prompt plus court n’est préférable que s’il conserve les informations nécessaires à une réponse correcte. Procédez dans cet ordre :

1. Retirez les passages récupérés en double. Deux extraits qui répètent la même règle augmentent le coût sans apporter de preuve supplémentaire.
2. Sélectionnez des sections plus précises. Pour une question ciblée, préférez le titre pertinent et son contexte à un manuel complet.
3. Limitez délibérément l’historique. Conservez les décisions, les contraintes et les questions non résolues ; résumez avec prudence les échanges moins utiles.
4. Allégez la structure décorative. Les introductions répétées, les enveloppes verbeuses et les espaces inutiles peuvent ajouter des tokens aux gros contenus JSON.
5. Préservez les identifiants et les valeurs. Ne supprimez pas les dates, codes d’erreur, noms de champs ou citations nécessaires à la réponse.

Pour réviser un prompt, utilisez Comparer des textes avec le brouillon et sa révision sous le même encodage. Le résultat indique l’évolution du compte, pas la qualité de la réponse. Après une réécriture importante, testez les réponses sur des tâches réalistes.

Pour les entrées structurées, distinguez le corps JSON des informations qu’il contient. Compacter le JSON supprime certains espaces, mais conserve les clés, l’imbrication et les valeurs. L’article JSON, données de formulaire ou multipart explique les différences entre ces formats de requête.

Étape 5 : estimer le coût avec des tarifs vérifiables

Les tarifs API distinguent souvent l’entrée hors cache, l’entrée en cache et la sortie générée. Les images, l’audio et les appels d’outils peuvent ajouter des frais ; les tokens de raisonnement peuvent aussi compter dans la sortie facturée, selon le fournisseur. Construisez votre simulation à partir des tarifs publiés plutôt que d’insérer un prix par token arbitraire dans un tableur.

Pour du texte seul, cette formule donne une approximation utile :

cost = (
  uncached_input_tokens * input_rate_per_million
  + cached_input_tokens * cached_rate_per_million
  + output_tokens * output_rate_per_million
) / 1_000_000

Multipliez par le nombre d’appels prévu uniquement si les hypothèses d’entrée et de sortie restent assez stables. Les historiques s’allongent, les documents récupérés changent et l’éligibilité au cache dépend des règles du fournisseur.

La Simulation de coût accepte des tarifs modifiables, une sortie prévue et un nombre d’appels. Ses tarifs initiaux sont des exemples de référence datés, pas des prix actualisés en direct ni une correspondance automatique avec le tokenizer choisi. Le calcul inclut la marge supplémentaire d’entrée ; la sortie prévue est distincte de la réserve de sortie. Notez le modèle, la date des tarifs et vos hypothèses pour permettre une vérification ultérieure.

Une erreur courante consiste à assimiler le contexte inutilisé à une dépense. La capacité décrit ce qui peut tenir dans une requête ; la facturation dépend de ce qui a réellement été traité et généré selon les règles du fournisseur.

Étape 6 : préparer séparément la requête API

Une fois le prompt mesuré, construisez la requête HTTP réelle. Gardez les secrets de l’application hors des captures d’écran, des liens de partage et des fichiers versionnés. Un corps JSON minimal pourrait ressembler à ceci :

{
  "model": "YOUR_MODEL_ID",
  "input": "Summarize the following policy in three sentences: ..."
}

Cet exemple ne suppose pas que tous les fournisseurs d’IA utilisent le même point d’accès ou le même schéma. Vérifiez les champs et les limites dans la documentation de votre fournisseur.

Utilisez le générateur de commandes cURL pour assembler une requête vers votre point d’accès, puis copiez-la dans un environnement de test local. Le générateur prépare les commandes ; il n’exécute pas la requête. Le guide des commandes cURL détaille l’authentification, les en-têtes et les conventions de citation du shell.

Le guide d’inspection réseau permet aussi de vérifier ce que le navigateur envoie. Ne supposez pas qu’un compte local inclut tout le format API du fournisseur ou le contenu non textuel.

Étape 7 : intégrer le budget de tokens aux tests

Une estimation ponctuelle est utile ; une procédure reproductible aide à détecter les régressions :

• Conservez des exemples d’entrée petits, moyens et proches du pire cas, sans données personnelles réelles.
• Mesurez chaque jeu de données avec le tokenizer du modèle ou le service de comptage du fournisseur.
• Réservez assez de place pour la réponse la plus longue acceptable.
• Déclenchez une alerte quand une requête approche du seuil choisi.
• Comparez l’usage API mesuré aux estimations dans des journaux qui excluent les secrets et le texte sensible.
• Examinez la croissance des tokens après toute modification de la recherche documentaire, de la conservation des échanges ou des définitions d’outils.

Pour une application multilingue, incluez des échantillons des langues réellement utilisées. Un même nombre de caractères visibles peut correspondre à des comptes de tokens différents selon l’encodage et le système d’écriture.