Tokens et tokenization : comprendre ce que mange un LLM

#Pourquoi parler de tokens

Quand vous discutez avec un LLM local via Ollama ou LM Studio, vous tapez des phrases. Le modèle, lui, ne voit jamais vos phrases telles quelles. Avant même le premier calcul, votre texte est transformé en une suite de nombres, chacun représentant un token. Tout ce que fait le modèle — comprendre, générer — se passe au niveau de ces tokens, pas des mots.

Comprendre les tokens n'est pas un détail académique. C'est ce qui explique trois choses très concrètes : pourquoi un document « rentre » ou non dans la fenêtre de contexte, pourquoi votre modèle génère à telle vitesse (les fameux tokens par seconde), et pourquoi une facturation d'API cloud ou une limite de contexte se compte toujours en tokens, jamais en mots.

#Un token, c'est quoi exactement

Un token est un fragment de texte : parfois un mot entier, souvent un morceau de mot, parfois un simple caractère ou un signe de ponctuation. Ce n'est ni une lettre, ni un mot au sens strict — c'est une unité statistique choisie par l'algorithme de tokenization pour représenter le texte le plus efficacement possible.

La règle empirique la plus utile : en anglais, 1 token ≈ 4 caractères ≈ 0,75 mot. Autrement dit, 100 tokens font environ 75 mots anglais. Pour le français, le ratio est nettement moins favorable, on y revient plus bas.

"chat"

Un mot fréquent et court : souvent 1 seul token.

"anticonstitutionnellement"

Un mot rare et long : découpé en plusieurs tokens (anti / constitution / nelle / ment…).

" " (espace)

L'espace est généralement collé au début du token suivant, pas isolé.

"123456"

Les nombres sont souvent découpés chiffre par chiffre ou par petits groupes.

😀

Un emoji peut coûter plusieurs tokens à lui seul.

Les mots très courants héritent d'un token unique parce qu'ils reviennent partout dans les données d'entraînement. Les mots rares, techniques ou dans une langue peu représentée sont reconstruits à partir de sous-morceaux — ce qui les rend plus « chers » en tokens.

#Comment un texte est réellement découpé

La plupart des LLM modernes utilisent une famille d'algorithmes appelée BPE (Byte Pair Encoding) ou ses variantes (WordPiece, Unigram). Le principe : partir des caractères bruts, puis fusionner progressivement les paires de symboles les plus fréquentes du corpus d'entraînement jusqu'à obtenir un vocabulaire de taille fixe — typiquement de 32 000 à 200 000 tokens selon le modèle.

1. 01
   Découpage initial

   Le texte est ramené à ses octets ou caractères de base. Rien n'est perdu : toute chaîne peut être représentée.
2. 02
   Fusions apprises

   Le tokenizer applique la liste de fusions apprise à l'entraînement (par ex. « t » + « ion » → « tion »), dans l'ordre de fréquence.
3. 03
   Conversion en identifiants

   Chaque token final est remplacé par son numéro dans le vocabulaire. Le modèle ne manipule plus que ces entiers.

Conséquence importante : le vocabulaire est figé à l'entraînement. Un modèle entraîné surtout sur de l'anglais aura un vocabulaire optimisé pour l'anglais, et découpera le français en morceaux plus petits et plus nombreux. C'est la racine du surcoût francophone.

#Pourquoi le français coûte plus cher que l'anglais

À contenu équivalent, un texte français consomme couramment 15 à 30 % de tokens de plus que sa traduction anglaise. Sur certains modèles très centrés sur l'anglais, l'écart peut dépasser 50 %. Trois raisons se cumulent.

Vocabulaire déséquilibré

Les tokenizers sont entraînés majoritairement sur de l'anglais : les mots anglais fréquents ont leur token dédié, pas les mots français.

Accents et caractères spéciaux

é, è, à, ç, œ… sont plus rares dans le vocabulaire et sont parfois éclatés en plusieurs tokens (voire en octets).

Morphologie plus riche

Conjugaisons, accords, élisions (l', d', qu') multiplient les formes d'un même mot, moins bien couvertes par le vocabulaire.

Exemple concret : la phrase anglaise « The cat is on the table » fait environ 6 tokens. Sa version française « Le chat est sur la table » en fait plutôt 7 à 8 selon le modèle. Sur un paragraphe entier, l'écart devient significatif — et il se paie deux fois : en place dans la fenêtre de contexte, et en temps de génération.

#Tokens et fenêtre de contexte

La fenêtre de contexte d'un modèle se mesure en tokens, pas en mots ni en caractères. Un modèle annoncé avec 32 768 tokens de contexte peut « voir » à un instant donné l'équivalent de ~24 000 mots anglais — mais seulement ~18 000 à 20 000 mots français, à cause du surcoût de tokenization.

Cette fenêtre inclut tout : le system prompt, l'historique de la conversation, votre message actuel, les documents collés, et la réponse en cours de génération. Quand le total dépasse la limite, le modèle tronque — généralement le plus ancien — et « oublie » le début de l'échange.

System prompt

Compté à chaque appel. Un prompt système bavard grignote le contexte en permanence.

Historique

Chaque tour de conversation s'accumule. Une longue discussion finit par saturer la fenêtre.

Documents (RAG, copier-coller)

Un PDF de 10 pages, c'est vite plusieurs milliers de tokens.

Réponse générée

La sortie occupe aussi de la place : il faut réserver de quoi répondre.

#Tokens et vitesse en local

La vitesse d'un LLM se mesure en tokens par seconde (tok/s). C'est l'unité universelle des benchmarks. Deux moments à distinguer, souvent confondus.

Prompt / prefill

Le temps pour « lire » votre prompt entier. Plus il y a de tokens en entrée, plus la première réponse tarde à démarrer.

Génération / decode

Le rythme auquel les tokens de réponse sortent, un par un. C'est le tok/s qu'on observe à l'écran.

Conséquence directe pour le français : puisque le même contenu représente plus de tokens, votre modèle met mécaniquement plus de temps à traiter un prompt francophone et à générer une réponse francophone de longueur équivalente. Le ressenti « c'est plus lent en français » n'est pas subjectif — c'est du comptage de tokens.

La vitesse de decode dépend surtout du modèle et du matériel (paramètres actifs par token, bande passante mémoire, quantization). Mais à matériel fixe, réduire le nombre de tokens en entrée — prompt système plus court, historique élagué — accélère nettement le time-to-first-token.

#Compter les tokens d'un texte soi-même

Le meilleur moyen d'acquérir l'intuition, c'est de mesurer. Voici trois approches, de la plus simple à la plus précise.

#Estimer à la louche

Pour une estimation rapide sans rien installer : divisez le nombre de caractères par 4 pour l'anglais, par 3 à 3,5 pour le français. C'est grossier mais suffisant pour savoir si un document tient dans une fenêtre de contexte.

#Compter en Python avec le vrai tokenizer

Pour un décompte exact, utilisez le tokenizer du modèle. La bibliothèque tokenizers / transformers de Hugging Face charge le tokenizer réel d'un modèle open-weight :

from transformers import AutoTokenizer

# Remplacez par le modèle que vous faites tourner en local
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B")

texte_fr = "Le chat est sur la table."
texte_en = "The cat is on the table."

print(len(tok.encode(texte_fr)), "tokens (fr)")
print(len(tok.encode(texte_en)), "tokens (en)")

# Voir le découpage réel
print(tok.tokenize(texte_fr))

Lancer ce script sur vos propres textes est l'exercice le plus parlant : vous voyez de vos yeux quels mots français sont éclatés et de combien l'anglais est plus compact.

#Lire le décompte depuis l'API Ollama

Ollama expose déjà les décomptes de tokens dans ses réponses. Le daemon écoute par défaut sur http://localhost:11434 ; un appel à l'API renvoie prompt_eval_count (tokens du prompt) et eval_count (tokens générés) :

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b",
  "prompt": "Explique la tokenization en une phrase.",
  "stream": false
}' | grep -o '"eval_count":[0-9]*'

Vous y retrouvez aussi eval_duration : divisez eval_count par la durée pour obtenir votre vrai débit en tokens par seconde, sur votre machine, avec votre quantization.

#Économiser des tokens sans perdre en qualité

Puisque chaque token coûte en contexte et en vitesse, quelques réflexes simples font une vraie différence, surtout en français.

System prompt concis

Il est renvoyé à chaque appel. Chaque phrase superflue se paie à chaque tour.

Élaguer l'historique

Résumez ou coupez les vieux échanges plutôt que de traîner toute la conversation.

RAG plutôt que tout coller

N'injectez que les passages pertinents d'un document, pas le document entier.

Cibler la longueur de sortie

Demander une réponse courte génère moins de tokens — donc plus vite.

#Pour aller plus loin

Les tokens sont le fil qui relie plusieurs notions de base. Trois guides prolongent directement celui-ci : le premier détaille la fenêtre de contexte que les tokens viennent remplir, le deuxième explique comment la quantization influe sur la vitesse mesurée en tokens par seconde, le troisième montre comment le transformer traite ces tokens en interne.