Vous avez envoyé une requête de 12 000 tokens à Claude et reçu une réponse coupée en plein milieu. Ou vous avez conçu un système qui fonctionnait bien en test, puis a commencé à échouer en production car les entrées réelles des utilisateurs dépassaient la limite. Les limites de tokens ne sont pas des cas limites — ce sont des contraintes structurelles autour desquelles vous devez architecturer.
Les tokens ne sont pas des mots. C’est la première chose qui heurte l’intuition.
Ce que sont réellement les Tokens
Un token est un fragment de texte qu’un modèle linguistique traite comme une unité. Un token peut être un caractère unique, une partie d’un mot, un mot entier ou une ponctuation. La répartition exacte dépend du tokenizer — l’algorithme qui divise le texte en morceaux avant que le modèle ne le voie.
Le texte anglais compte en moyenne environ 1,3 tokens par mot, mais ce n’est qu’une moyenne. Le code est plus dense — souvent 1,7+ tokens par mot car les opérateurs et les parenthèses sont tokenisés séparément. Le JSON est encore pire. Un simple espace ou un retour à la ligne peut être son propre token.
Cela est important car vous êtes facturé par token, et votre fenêtre de contexte est mesurée en tokens, pas en mots. Si vous pensez avoir 128K tokens de marge et que vous stockez du texte à 1,5 tokens par mot, vous disposez en réalité d’environ 85 000 mots — pas 128 000.
La plupart des modèles publient leurs limites de tokens comme entrées + sorties. Claude 3.5 Sonnet dispose d’une fenêtre de contexte de 200K tokens. Cela signifie que votre requête (tokens d’entrée) plus la réponse du modèle (tokens de sortie) ne peuvent pas dépasser ensemble 200 000. Si votre requête fait 150K tokens, il vous reste environ 50K tokens pour la réponse avant que le modèle ne coupe.
Pourquoi cela ruine vos plans concrets
L’échec le plus courant : vous concevez un système qui fonctionne avec une requête de 10K tokens isolément, puis vous ajoutez la récupération RAG, l’historique de conversation, les instructions système et les entrées utilisateur, le tout empilé. Vous arrivez maintenant à 45K tokens par requête, et soit vous atteignez les limites, soit vos coûts explosent 4 à 5 fois ce que vous aviez estimé.
Le deuxième échec : vous bourrez tout dans le contexte parce que vous le pouvez, puis la qualité de la sortie du modèle diminue. Les contextes longs nuisent au raisonnement. Ce n’est pas de l’hyperbole — c’est mesurable. Les performances de Claude sur les tâches se dégradent notablement au-delà d’environ 100K tokens, même s’il peut en gérer 200K.
Le troisième échec : vous ne tenez pas compte des tokens de sortie. Vous calculez le coût d’entrée, déployez le système, puis découvrez que les réponses du modèle sont plus longues que prévu. Une requête de 100 tokens peut générer une réponse de 800 tokens si vous demandez une analyse détaillée. Soudain, votre coût par requête est de 900 tokens, pas 100.
Calculer votre utilisation réelle de tokens
Arrêtez de deviner. Mesurez.
Utilisez la bibliothèque de tokenizer du fournisseur du modèle avant de déployer quoi que ce soit. Pour Claude, utilisez le tokenizer du package anthropic. Pour les modèles GPT, utilisez tiktoken. Exécutez vos requêtes réelles via ces outils et enregistrez le nombre de tokens.
from anthropic import Anthropic, messages
import anthropic
client = Anthropic()
# Votre requête
system_prompt = """Vous êtes un analyste. Extrayez les métriques clés des données fournies.
Soyez concis. Formatez en JSON."""
user_input = """Voici les données financières du T3 pour Acme Corp...
[4000 mots de données réelles]
"""
# Comptez les tokens AVANT d'appeler l'API
token_count = len(client.beta.messages.count_tokens(
model="claude-3-5-sonnet-20241022",
system=system_prompt,
messages=[{"role": "user", "content": user_input}]
).input_tokens)
print(f"Votre requête : {token_count} tokens")
# Maintenant, effectuez l'appel
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1000,
system=system_prompt,
messages=[{"role": "user", "content": user_input}]
)
output_tokens = response.usage.output_tokens
print(f"Réponse du modèle : {output_tokens} tokens")
print(f"Coût total : {token_count + output_tokens} tokens")Ce n’est pas une option. Vous avez besoin des chiffres réels avant de concevoir l’architecture du système.
Approches structurelles pour rester sous les limites
Compressez votre requête système. Les instructions inutiles ajoutent des tokens sans apporter de valeur. Comparez :
# Mauvaise requête système (287 tokens)
Vous êtes un représentant du service client serviable. Vous travaillez pour TechCorp,
une entreprise de logiciels. Lorsque les clients vous contactent, il est important que vous
soliez poli, professionnel et serviable. Vous devriez essayer de comprendre leurs
problèmes et les aider à trouver des solutions. Soyez toujours respectueux et patient.
Ne soyez jamais impoli. Vous pouvez fournir des informations techniques sur nos produits.
Assurez-vous de poser des questions de clarification lorsque nécessaire. Si vous ne connaissez pas
la réponse, dites au client que vous allez y jeter un œil.
# Bonne requête système (89 tokens)
Vous êtes le support client de TechCorp. Soyez direct et professionnel.
Posez des questions de clarification. Si vous ne savez pas, dites-le.
Fournissez des informations techniques sur les produits. Restez concentré sur la résolution du problème.Les deux transmettent la même instruction. La seconde est 68% plus petite.
Utilisez la pagination pour les documents volumineux. Ne chargez pas les 50 pages d’un document dans une seule requête. Divisez-le en sections, récupérez uniquement les fragments pertinents par recherche ou correspondance sémantique, et passez-les. C’est pourquoi les systèmes RAG existent — ils sont efficaces en tokens par conception.
Limitez l’historique des conversations. Gardez les 5 à 10 derniers messages dans une conversation multi-tours, pas l’intégralité du chat. Pour la plupart des applications, le contexte plus ancien ajoute du bruit, pas du signal, et coûte des tokens que vous n’avez pas besoin de dépenser.
Structurez le format de sortie dès le départ. Si vous voulez du JSON, dites-le dans la requête système, pas dans le message utilisateur. Si vous voulez exactement 3 points, spécifiez-le. Un formatage explicite évite au modèle de générer du blabla, ce qui réduit les tokens de sortie.
Ce qu’il faut faire dès maintenant
Choisissez l’une de vos requêtes actives — quelque chose que vous utilisez en production ou en test régulièrement. Mesurez son nombre réel de tokens à l’aide du tokenizer du fournisseur. Incluez la requête système, l’entrée utilisateur et estimez la longueur de la réponse.
Calculez votre total : tokens d’entrée + sortie. Multipliez ensuite par votre volume d’utilisation sur un mois. Si ce nombre vous surprend, compressez votre requête système en utilisant les modèles ci-dessus, puis re-mesurez. Vous constaterez souvent des économies de 20 à 30 % de tokens en supprimant les instructions redondantes.
