Jetons et tokenisation¶
Pourquoi ni lettres ni mots¶
Un modèle doit manipuler un ensemble fini et fixe de symboles. Deux choix naïfs échouent :
- Les caractères. Vocabulaire minuscule (une centaine de symboles), mais les séquences deviennent très longues : un texte de 1 000 mots fait ~5 000 caractères. Comme le coût de l'attention croît avec la longueur, c'est cher.
- Les mots. Séquences courtes, mais vocabulaire non borné : fautes de
frappe, noms propres, mots composés, identifiants de code (
getUserById), langues sans espaces (chinois, japonais).
La solution universelle est le sous-mot (subword) : un vocabulaire de morceaux de texte fréquents, appris statistiquement sur un corpus.
L'algorithme BPE, en pratique¶
L'algorithme dominant est BPE (Byte Pair Encoding). Le principe :
- Partir de l'alphabet des octets (256 symboles) — cela garantit qu'aucun texte n'est impossible à encoder, y compris des données binaires.
- Compter, dans un grand corpus, la paire de symboles adjacents la plus fréquente.
- Fusionner cette paire en un nouveau symbole, et l'ajouter au vocabulaire.
- Répéter jusqu'à atteindre la taille de vocabulaire voulue.
Sur un corpus français, les premières fusions donnent des choses comme
e+s → es, puis l+e → le, puis +de → de. Les motifs
fréquents deviennent des jetons uniques ; les motifs rares restent découpés en
plusieurs morceaux.
Intuition
BPE est une compression : les séquences fréquentes coûtent un jeton, les séquences rares en coûtent plusieurs. Le vocabulaire est un dictionnaire de raccourcis appris.
Ordres de grandeur¶
| Élément | Valeur pour Kimi K3 |
|---|---|
| Taille du vocabulaire | 163 840 jetons (annoncée « 160 K » dans le rapport) |
| Longueur de contexte | 1 048 576 jetons (soit \(2^{20}\), « 1 M ») |
| Ratio typique, anglais | ~0,75 mot par jeton |
| Ratio typique, français | ~0,6 à 0,7 mot par jeton |
| Ratio typique, code | ~3 à 4 caractères par jeton |
À retenir
1 million de jetons de contexte, c'est de l'ordre de 700 000 mots, soit environ 2 500 pages, ou l'intégralité d'un dépôt logiciel de taille moyenne. C'est ce que Kimi K3 peut lire en une seule requête.
Un détail non anecdotique : les valeurs exactes tirées du fichier de
configuration publié (config.json) sont vocab_size: 163840 et
max_position_embeddings: 1048576. Le rapport arrondit à « 160 K » et « 1 M ».
Les jetons spéciaux¶
Au-delà du texte, le vocabulaire contient des jetons structurels, qui ne correspondent à aucune chaîne de caractères ordinaire. Ils délimitent les rôles de la conversation. Kimi K3 en fait un usage particulièrement systématique avec son format XTML (voir SFT et modèle de conversation) :
| Jeton | Rôle |
|---|---|
[open] |
Ouvre un élément structurel |
[sep] |
Sépare les attributs du contenu |
[close] |
Ferme un élément |
[end_of_msg] |
Marque la fin de génération |
Dans la configuration publiée, on trouve par exemple
bos_token_id: 163584 (début de séquence), eos_token_id: 163586 (fin),
pad_token_id: 163839 et media_placeholder_token_id: 163605 — ce dernier
servant à réserver la place des jetons d'image (voir
chapitre 12).
Erreur fréquente
Croire que ces marqueurs sont du texte que le modèle « lit ». Ce sont des
entrées du vocabulaire à part entière, avec leurs propres vecteurs appris.
Le rapport Kimi K3 insiste sur ce point : remplacer les chevrons XML
(<tag>) par des jetons réservés supprime l'ambiguïté de tokenisation aux
frontières et simplifie le décodage sous contrainte grammaticale.
Pourquoi cela compte pour la suite¶
Trois conséquences directes sur Kimi K3 :
- Le coût se compte en jetons, pas en mots. La tarification API (3 $/M jetons en entrée, 15 $/M en sortie) et la fenêtre de contexte s'expriment ainsi.
- La couche de sortie est énorme. Projeter 7 168 dimensions vers 163 840 logits coûte 1,17 milliard de paramètres à elle seule, et ce calcul est refait à chaque jeton généré.
- Les images deviennent des jetons. Une image de \(3584 \times 3584\) pixels est découpée en carreaux, puis compressée, pour tenir dans un budget de jetons compatible avec le contexte de 1 M (voir chapitre 12).
Vérification de compréhension¶
Pourquoi partir des octets plutôt que des caractères Unicode ?
Parce que l'ensemble des points de code Unicode est immense (>150 000) et évolue. Partir des 256 octets garantit une couverture totale et stable : n'importe quelle séquence d'octets est encodable, y compris un fichier binaire mal formé ou un émoji inconnu du corpus d'entraînement.
Un texte de 4 000 mots tient-il dans 4 000 jetons ?
Non, il en faut plutôt 5 500 à 6 500 en français. Et si le texte contient du code, des tableaux ou des identifiants, le ratio se dégrade encore.
Chapitre précédent : Qu'est-ce qu'un modèle de langage ? · Chapitre suivant : Vecteurs, embeddings, espaces de représentation