Token (Unité de traitement LLM)

Aucune règle universelle ne donne une conversion exacte mots → tokens : le ratio dépend du tokenizer (tiktoken pour OpenAI, count_tokens pour Anthropic, tokenizer SentencePiece pour Mistral et Llama) et de la langue. En pratique, retenir trois ordres de grandeur fiables. Un, en anglais, 1 token vaut en moyenne 0,75 mot et 4 caractères. Deux, en français, 1 token vaut en moyenne 0,5 mot, soit deux fois plus de tokens consommés à contenu équivalent. Trois, pour un chiffrage sérieux, ne jamais se fier à une règle de trois mentale : passer le texte cible au tokenizer officiel du modèle visé (tiktoken expose des encodings cl100k_base, o200k_base ; Anthropic expose count_tokens via l'API ; Mistral fournit son tokenizer en open source). C'est la seule méthode pour cadrer un budget API sans dérive.

Deux raisons cumulatives. D'abord, le français a une morphologie nettement plus riche que l'anglais : accords genre/nombre, conjugaisons en six personnes et une vingtaine de temps, accents, élisions, mots composés avec traits d'union, articles et déterminants nombreux. Le tokenizer doit donc multiplier les sous-mots pour représenter une même information sémantique. Ensuite, les tokenizers majeurs (BPE de GPT, SentencePiece de Llama et Mistral) ont été entraînés sur des corpus très majoritairement anglo-saxons : leurs vocabulaires fusionnent efficacement les motifs anglais en un seul token, alors que les motifs français sont fragmentés en deux, trois ou quatre tokens. Conséquence directe sur la facturation : un même contenu traduit du français vers l'anglais coûte moins cher en tokens, et inversement, traiter le français coûte structurellement plus cher à qualité égale.

Les économies dépendent du fournisseur, du ratio cache hit et de la stabilité du contexte mis en cache. Anthropic prompt caching applique une tarification dégressive : écriture du cache à environ 1,25× le tarif input standard, lecture du cache à environ 0,1× le tarif input standard, soit jusqu'à 90 % d'économie sur les tokens cachés à partir de la deuxième requête. OpenAI flex caching propose une logique similaire avec un cache automatique sur les préfixes répétés (cache discount de l'ordre de 50 %). Cas d'usage typique à fort ROI : un prompt système stable de 10 000 à 50 000 tokens (charte, référentiel, FAQ produit, base de connaissances RAG fixe) réutilisé des centaines ou milliers de fois par jour. Cas à faible ROI : prompts uniques, faible répétition, ou contexte qui change à chaque requête. La règle de pouce Nehos : activer le caching dès qu'un préfixe est réutilisé plus de 10 fois dans la journée.

L'écart de tarification, de l'ordre de 3 à 5× selon les fournisseurs (Anthropic, OpenAI, Mistral, Google), reflète une différence de coût de calcul. Lire un token d'input correspond à un passage forward « parallélisable » sur le prompt entier, opération relativement bon marché en GPU. Générer un token d'output exige un décodage séquentiel autorégressif : chaque token produit dépend de tous les précédents, ce qui empêche le batching massif et mobilise davantage de mémoire GPU et de latence par token. Implication pratique pour la conception d'un produit : préférer toujours, à qualité égale, les architectures qui réduisent la longueur de sortie — instructions de concision dans le prompt système, formats structurés (JSON Schema, sorties limitées), résumés intermédiaires plutôt que verbosité, et routage modèle pour réserver les grands modèles aux sorties courtes à forte valeur.

Les deux approches résolvent un problème différent. Le cache de tokens (prompt caching Anthropic, flex caching OpenAI) optimise la réutilisation d'un préfixe stable — un prompt système, une charte éditoriale, un grand contexte injecté en intégralité. Il est très efficace dès lors que le contexte ne change pas entre deux requêtes proches. À l'inverse, le RAG (Retrieval-Augmented Generation) sélectionne à la volée les passages pertinents dans une base documentaire externe ; il est indispensable dès que la base dépasse le context window, qu'elle évolue dans le temps (fraîcheur), ou qu'il faut tracer et citer les sources. En pratique, les architectures Nehos combinent les deux : RAG pour aller chercher les bons chunks dans une base massive, prompt caching pour mettre en cache le prompt système et les blocs invariants. La complémentarité est la norme, pas l'exclusivité.