Vous avez atteint une limite de tokens hier. Pas parce que votre invite était verbeuse, mais parce que vous n’aviez pas compris comment fonctionnent les tokens. Vous avez envoyé un document de 3 000 mots à Claude, l’avez vu traiter les 2 800 premiers mots, puis renvoyer une réponse tronquée. Le problème ne venait pas de votre demande. C’est que vous n’aviez pas pris en compte les tokens de sortie, les invites système et la manière dont différents modèles comptent le même texte différemment.
La tokenisation est la façon dont les LLM décomposent le texte en morceaux avant de le traiter. Comprenez-la, et vous arrêterez de gaspiller des crédits d’API. Ignorez-la, et chaque intégration que vous construirez se comportera de manière inattendue à grande échelle.
Ce que sont réellement les tokens
Un token n’est pas un mot. C’est important.
Dans la plupart des textes anglais, un token ≈ 4 caractères ou 0,75 mot. Mais ce ratio s’effondre rapidement. La ponctuation, les espaces, les chiffres, le code et le texte non anglais se tokenisent différemment. Une virgule peut être un token. Un nombre comme 1 234 567 peut en être trois ou quatre. Le mot tokenisation est un token. L’acronyme CPU est parfois un, parfois trois, selon le modèle.
Différents modèles utilisent différents tokeniseurs. GPT-4o utilise un tokeniseur différent de celui de Claude Sonnet 4. Le tokeniseur cl100k_base d’OpenAI compte le texte d’une manière. Le tokeniseur d’Anthropic le compte d’une autre. La même invite peut coûter 150 tokens dans GPT-4o et 140 tokens dans Claude — ou vice versa.
Cette incohérence explique pourquoi vous ne pouvez pas estimer le nombre de tokens de tête. Vous devez mesurer.
Tokens d’entrée vs de sortie (et pourquoi les deux comptent)
Les limites de tokens ont deux faces : ce que vous envoyez et ce qui revient.
Votre entrée comprend l’invite système, le message de l’utilisateur, l’historique de conversation et tout contexte que vous avez ajouté. Votre sortie est la réponse du modèle. La plupart des plateformes les facturent séparément — les tokens de sortie coûtent souvent plus cher que les tokens d’entrée. GPT-4o, par exemple, facture 5 $ par 1 million de tokens d’entrée et 15 $ par 1 million de tokens de sortie. Ce ratio de 3:1 change la façon dont vous devriez structurer vos requêtes.
Si vous résumez des documents, ces tokens sont principalement des entrées. Si vous générez du code, les tokens de sortie dominent. Si vous avez une conversation à plusieurs tours où vous répétez le contexte à chaque tour, vous payez les coûts des tokens d’entrée de manière répétée pour les mêmes informations.
Limites de tokens en production : où elles posent problème
Les fenêtres de contexte ont grandi — Claude 3.5 Sonnet prend en charge 200 000 tokens, GPT-4o prend en charge 128 000. Mais la croissance ne signifie pas que vos limites ont disparu. Cela signifie que vos limites sont différentes maintenant.
Voici le schéma réel : à mesure que votre fenêtre s’agrandit, vos invites s’agrandissent pour la remplir. Les ingénieurs commencent à inclure des bases de code entières au lieu d’extraits. Les analystes incluent des ensembles de données complets au lieu d’échantillons. Les avocats incluent des documents entiers au lieu d’extraits. Le coût par requête augmente. La latence de réponse augmente. Et quelque part autour de 80-85 % de votre contexte disponible, la plupart des modèles commencent à moins bien performer — pas mieux. Ils perdent leur concentration dans les contextes longs.
La limite pratique n’est pas le maximum technique. C’est le point où le coût ou la latence devient inacceptable, ou où la précision du modèle diminue.
Comment compter les tokens sans deviner
Utilisez le tokeniseur du modèle lui-même. N’estimez pas.
Pour les modèles OpenAI, utilisez la bibliothèque tiktoken :
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o")
text = "Votre texte d'invite ici"
tokens = enc.encode(text)
print(f"Nombre de tokens : {len(tokens)}")
print(f"Coût estimé (entrée) : ${len(tokens) * 0.000005:.4f}")
Pour les modèles Anthropic, utilisez l’API count_tokens ou leur bibliothèque Python :
from anthropic import Anthropic
client = Anthropic()
message = client.messages.count_tokens(
model="claude-3-5-sonnet-20241022",
system="Vous êtes un assistant utile.",
messages=[
{"role": "user", "content": "Votre texte d'invite ici"}
]
)
print(f"Nombre de tokens : {message.input_tokens}")
Ce n’est pas une option. Lorsque vous déployez une intégration, vous avez besoin de comptes exacts, pas d’approximations. La différence entre « environ 100 tokens » et « 106 tokens » est la différence entre rester sous votre limite de lot et échouer à 3 heures du matin.
Stratégies qui permettent réellement d’économiser des tokens
L’économie de tokens ne consiste pas à écrire des invites plus courtes. Il s’agit de structure.
1. Ne répétez pas le contexte dans les conversations multi-tours. Si vous créez un chatbot, envoyez l’invite système une fois et utilisez la mémoire de conversation. Chaque tour où vous la répétez, vous gaspillez des tokens. Lorsque vous créez un flux de service client où vous traitez de nombreuses demandes distinctes, oui, incluez le contexte à chaque fois — mais gardez-le minimal.
2. Utilisez des exemples de manière stratégique. Les invites « few-shot » (incluant des exemples) sont peu coûteuses sur le moment, mais coûteuses sur la durée. Une conversation avec des exemples coûte plus cher au départ que le « zero-shot ». Mais si ces exemples réduisent les taux d’erreur de 30 %, le coût en tokens en vaut la peine. S’ils modifient la sortie de 2 %, ce sont des tokens gaspillés. Mesurez le compromis.
Mauvaise approche :
Vous êtes un classificateur d'e-mails. Classez chaque e-mail comme « vente », « support » ou « spam ».
Exemple 1 : « Découvrez notre nouveau produit ! » → vente
Exemple 2 : « Votre commande est prête à être retirée » → support
Exemple 3 : « Cliquez ici pour de l'argent gratuit » → spam
Exemple 4 : « Offre spéciale à l'intérieur » → vente
Exemple 5 : « Votre mot de passe a été réinitialisé » → support
Classez cet e-mail : [entrée utilisateur]
Meilleure approche (pour une classification unique) :
Classez cet e-mail comme « vente », « support » ou « spam » : [entrée utilisateur]
Le second économise 80 tokens. Si vous classez des milliers d’e-mails, cela représente une réduction de coût significative. N’ajoutez des exemples que si votre taux d’erreur justifie le coût.
3. Utilisez le résumé pour compresser le contexte. Si vous devez passer l’historique d’un document ou une analyse précédente dans une nouvelle requête, résumez-le d’abord. Le résumé coûte des tokens d’entrée au départ, mais économise des tokens sur chaque requête en aval qui a besoin de ce contexte.
4. Traitez par lots des requêtes similaires. Au lieu d’envoyer cinq appels API distincts pour cinq invites différentes, combinez-les lorsque c’est possible. Une requête pour classer dix e-mails coûte moins de tokens que dix requêtes pour classer un e-mail chacune.
Que faire aujourd’hui
Choisissez une intégration ou un flux de travail que vous avez créé au cours du dernier mois. Exécutez les invites réelles dans le compteur de tokens de votre modèle. Calculez les coûts réels des tokens d’entrée et de sortie par requête. Si vous exécutez cela à grande échelle, multipliez par votre volume de requêtes et votre coût par token. Vous constaterez soit que vous avez de la marge pour ajouter du contexte et améliorer la qualité, soit que vous devez réduire drastiquement. La plupart des gens découvrent qu’ils ont massivement sur-tokenisé parce qu’ils devinaient les comptes.
Commencez à mesurer. Tout le reste suivra.