Compteur de tokens et estimateur de coûts

Ce qu'est réellement un token

Un token est un fragment de texte que le modèle traite comme une unité. Ce n'est ni une lettre ni tout à fait un mot. En anglais, la moyenne de travail tourne autour de quatre caractères, soit à peu près trois quarts de mot : 1 000 tokens correspondent donc à quelque 750 mots de prose ordinaire.

Les règles de découpage sont moins nettes que cette moyenne le laisse croire :

• Les mots courants forment en général un seul token. « The », « water », « because » coûtent un chacun.
• Les mots longs ou rares se fragmentent. Un mot comme « unbelievable » peut se découper en trois morceaux.
• L'espace qui précède un mot voyage normalement avec lui : « cat » et « cat » précédé d'un espace sont deux tokens différents.
• Les nombres se découpent souvent chiffre par chiffre, ce qui rend les identifiants de commande, les empreintes et les horodatages coûteux au regard de leur brièveté.

Les autres langues n'ont pas droit au même traitement. Les tokenizers sont entraînés surtout sur de l'anglais : le français, l'espagnol et l'allemand pèsent typiquement 1,5 à 2 fois plus lourd à sens égal. Le japonais, le chinois, le coréen, l'arabe et les alphabets cyrilliques peuvent faire pire encore, un seul caractère coûtant parfois deux ou trois tokens.

Le code se comporte différemment lui aussi. Indentation, crochets, guillemets et identifiants en camelCase se fragmentent tous. Du JavaScript minifié ou une chaîne base64 peut être plusieurs fois plus dense que de la prose de même longueur en caractères — bon à savoir avant de coller un fichier entier dans une fenêtre de chat.

Pourquoi les limites et les tarifs se comptent tous deux en tokens

Deux choses distinctes se mesurent dans la même unité, et c'est là que naît la confusion.

La première est la fenêtre de contexte : le texte total qu'un modèle peut garder en tête pour une requête. Tout compte — vos instructions, la conversation jusqu'ici, les fichiers joints et la place réservée à la réponse. En cas de dépassement, les messages les plus anciens sautent ou la requête échoue. Un contexte perdu est invisible, et c'est pourquoi une longue discussion finit parfois par contredire ce que vous aviez acté vingt messages plus tôt.

La seconde est la facturation. Les fournisseurs facturent au million de tokens, en séparant entrée et sortie. Si vous évaluez la viabilité d'une automatisation à grande échelle, c'est ce partage qui compte, et les fondamentaux du prompt engineering méritent d'être lus en parallèle — un prompt plus serré est en général un prompt moins cher.

Entrée, sortie, et le coût discret de l'historique

Les tokens de sortie coûtent presque toujours plus cher que ceux d'entrée — couramment cinq fois plus. Il y a une raison mécanique. L'entrée est traitée en un seul passage parallèle, tandis que la sortie est générée token par token, chacun exigeant une traversée complète du modèle. Vous payez le travail séquentiel.

La conséquence pratique surprend : un prompt de 3 000 mots revient souvent moins cher qu'une requête qui produit une réponse de 3 000 mots. Si votre facture grimpe, regardez ce que le modèle écrit avant de regarder ce que vous envoyez. Plafonner la longueur dans le prompt est le levier le plus rapide dont vous disposez :

Reste l'historique de conversation. Le chat est sans état en dessous : chaque tour renvoie le fil entier. Au dixième tour, vous payez pour retraiter les tours un à neuf, encore une fois. Vingt tours de 500 tokens, ce n'est pas 10 000 tokens d'entrée, c'est plutôt 100 000 une fois les renvois comptés. Les longs fils coûtent cher en silence, sans qu'aucun message paraisse volumineux. Cassez le cycle en reportant le fil vous-même :

Réduire les tokens sans perdre en qualité

La plupart des prompts contiennent du mou qui coûte de l'argent sans rien apporter :

• Supprimez les politesses de remplissage. « Je me demandais si tu pourrais éventuellement m'aider à » représente une douzaine de tokens pour rien.
• Réduisez le matériel collé à la partie utile. Deux paragraphes du contrat, pas le contrat entier, quand votre question porte sur une clause.
• Ouvrez une nouvelle conversation quand le sujet change. Vous cessez de payer un historique devenu inutile.
• Déplacez les instructions stables dans un system prompt au lieu de les répéter à chaque tour.
• Demandez de la structure. Une sortie JSON ou un simple tableau tient généralement en moins de place que la même information en prose, et se réutilise mieux ensuite.

Ce qu'il ne faut pas couper : le contexte que le modèle ne peut pas deviner — votre public, vos contraintes, ce que vous avez déjà tenté. C'est cette partie qui travaille. Le flou fait partie des erreurs de prompting les plus courantes, et il vous coûte une seconde tentative, plus chère que les mots économisés. Passez un brouillon trop lourd dans l'optimiseur de prompt pour le raccourcir, ou partez léger avec le générateur de prompts ChatGPT.

Pourquoi il s'agit d'une estimation

Chaque famille de modèles utilise son propre tokenizer, et les fournisseurs les mettent à jour d'une version à l'autre. Deux modèles peuvent lire le même paragraphe et compter différemment. Un compteur qui tourne entièrement dans votre navigateur applique une approximation bien calibrée plutôt que d'embarquer une douzaine de fichiers de vocabulaire — et plutôt que d'envoyer votre texte ailleurs.

Pour la planification quotidienne — est-ce que ça rentre, combien ça coûtera à peu près, ce prompt fait-il le double de la taille nécessaire — l'estimation est assez proche pour décider. Comptez sur quelques pourcents près pour de la prose anglaise, moins précis pour du code et les alphabets non latins. Quand il vous faut un chiffre exact pour la facturation, consultez le tokenizer d'OpenAI ou le décompte renvoyé dans la réponse de l'API elle-même.