Omniprésent dès qu’on parle d’IA générative, le token sert à découper ce que les modèles traitent, mais aussi à mesurer leur capacité et leur consommation. Une petite unité sur laquelle repose une bonne partie de leur fonctionnement.
Modèle capable de traiter jusqu’à 200 000 tokens à la fois, tarif de quelques dollars par million de tokens, consommation de tokens en entrée ou en sortie… Si vous vous êtes déjà intéressé un tant soit peu au fonctionnement de ChatGPT, Claude, Gemini ou d’autres modèles d’intelligence artificielle générative, vous avez forcément déjà croisé ce terme à un moment ou à un autre. Et pour cause, le token constitue l’une des unités fondamentales sur lesquelles reposent les grands modèles de langage. Vous voilà bien avancé, n’est-ce pas ? Non. Alors concrètement, un token, c’est quoi ?
Un mot, deux tokens… ou parfois beaucoup plus
Quand on parle de modèle de langage, un token correspond à une unité dans laquelle les données sont découpées avant d’être traitées. Pour du texte, il peut s’agir d’un mot entier, d’une partie de mot, d’un signe de ponctuation, voire de quelques caractères, espaces compris.
À titre d’exemple, une phrase toute simple comme « Windows installe une mise à jour et fait planter les PC. » n’est donc pas nécessairement découpée comme nous le ferions spontanément, à savoir :
Windows / installe / une / mise / à / jour / .
Le résultat dépend du tokenizer utilisé, c’est-à-dire de l’outil chargé de segmenter le texte. Chaque modèle, ou famille de modèles, s’appuie sur un tokenizer donné, si bien qu’une même phrase ne sera pas forcément décomposée de la même manière par deux IA différentes. Il faut donc oublier l’équivalence « un token = un mot ». Pour vous donner un ordre de grandeur, chez OpenAI, Google et Anthropic, il faut compter environ quatre caractères par token, soit trois quarts d’un mot en anglais. En anglais, oui, car la langue utilisée influence elle aussi la manière dont le texte est découpé.
Si vous avez bien suivi, la logique voudrait donc qu’un mot long soit découpé en davantage de tokens qu’un mot court. Sauf que non. Ou du moins, pas forcément. Un mot long mais très courant peut tout à fait n’être représenté que par deux tokens, quand un terme plus court, mais rare ou inhabituel, en nécessitera quatre.
Pourquoi ? Parce que, malgré les estimations citées plus haut, le tokenizer ne se fie pas à la longueur des mots. Il s’appuie sur un vocabulaire, c’est-à-dire un ensemble fini d’unités qu’il sait reconnaître.
Dans les méthodes de tokenisation courantes, ce vocabulaire privilégie notamment les séquences fréquemment rencontrées dans les données : plus une suite de caractères revient souvent, plus elle a de chances d’exister comme une unité à part entière. Une terminaison très courante comme « ing » en anglais aura ainsi plus de chances de figurer telle quelle dans ce vocabulaire, ce qui permet au tokenizer de la réutiliser dans une multitude de mots, là où il devra généralement représenter une séquence plus rare à l’aide de plusieurs tokens.
Un joyeux casse-tête, qui n’est en fait qu’une affaire de compromis. Si le modèle devait uniquement travailler à partir de mots entiers, le vocabulaire du tokenizer devrait alors prévoir une entrée pour chaque terme, mais également pour ses différentes formes, les noms propres, les néologismes ou les fautes de frappe. Il enflerait à une vitesse folle. À l’inverse, le faire travailler caractère par caractère produirait des séquences beaucoup trop longues à traiter. Avec les tokens, on coupe donc la poire en deux.
Des tokens pour lire, d’autres pour répondre
Une fois le texte découpé, le tokenizer passe la main au modèle. On parle alors de tokens d’entrée (input tokens) pour désigner tout ce qu’il reçoit et doit traiter. Votre prompt en fait évidemment partie, mais le compteur peut aussi inclure les échanges précédents, des instructions, le contenu d’un document, en bref tout ce qui compose le contexte transmis au modèle.
À chaque token correspond alors un identifiant numérique, à partir duquel le modèle accède à une représentation mathématique. Il analyse les relations entre ces tokens et calcule, étape après étape et selon une logique probabiliste, ceux qui composeront sa réponse. À mesure qu’il la génère, il produit cette fois des tokens de sortie (output tokens), ensuite reconvertis en texte.
De manière très schématique, lorsqu’on envoie un prompt à une IA, le processus ressemble donc à ceci :
1. découpage du texte et du contexte en tokens d’entrée ;
2. conversion de ces unités en représentations mathématiques ;
3. calcul probabiliste à partir du contexte fourni ;
4. génération progressive des tokens de sortie, un après l’autre ;
5. conversion du résultat en texte lisible.
Cette capacité à prédire la suite ne naît évidemment pas au moment où vous envoyez votre prompt. Elle résulte de l’entraînement du modèle sur d’immenses quantités de données, dont il tire des régularités statistiques sur l’enchaînement et l’association des tokens.
Voilà aussi pourquoi il faut se garder d’associer un token à une « pensée », une idée ou une quantité fixe d’information. Un même token compte toujours pour une unité, mais peut porter nombre de significations très différentes suivant le contexte.
Cache et raisonnement, la face cachée des tokens
À cette distinction entre entrée et sortie viennent s’ajouter deux notions que vous croiserez souvent dans les grilles tarifaires et les compteurs d’utilisation : les tokens mis en cache et, pour certains modèles, les tokens de raisonnement.
La mise en cache concerne des tokens d’entrée déjà traités. Lorsqu’une nouvelle requête reprend à l’identique une portion de contexte envoyée précédemment, le système peut réutiliser une partie du travail effectué au lieu de tout recalculer. On parle alors de tokens mis en cache (cached tokens).
Les tokens de raisonnement (reasoning tokens) sont utilisés par certains modèles pendant les étapes intermédiaires qui précèdent la production de leur réponse. Ils ne se retrouvent pas nécessairement dans le texte finalement affiché à l’utilisateur. Une réponse de quelques lignes peut donc avoir mobilisé bien plus de tokens que son seul texte ne le laisse supposer.
Au final, entre ce que vous envoyez, ce que le système réutilise, ce que le modèle mobilise pour raisonner et ce qu’il finit par afficher, vous n’avez qu’une vision très partielle du nombre de tokens réellement en jeu dans un échange avec une IA.
De l’unité de découpage à l’unité de mesure, l’autre rôle du token
Jusqu’ici, nous avons essentiellement parlé du token comme d’une unité de découpage et de traitement. Mais puisqu’on peut les compter, les tokens servent aussi à mesurer la quantité d’informations qu’un modèle est capable de manipuler. C’est ce qui se cache derrière les fameuses capacités annoncées en dizaines, centaines de milliers, voire plus d’un million de tokens selon les modèles.
Ces chiffres désignent la taille de ce qu’on appelle la fenêtre de contexte, c’est-à-dire tout ce que le modèle peut prendre en compte simultanément pour traiter une requête (rappelez-vous, votre prompt, les instructions, l’historique de la conversation, le contenu d’un document, etc.).
Une fenêtre de contexte de 200 000 tokens signifie donc que le modèle dispose d’un espace de travail pouvant accueillir jusqu’à 200 000 tokens. Une partie est déjà occupée par les informations qu’on lui fournit ; l’espace restant doit aussi laisser de la place à la génération de sa réponse et, selon le modèle, au raisonnement.
Forcément, une conversation qui s’allonge grignote progressivement cette fenêtre. Et lorsqu’on finit par en atteindre la capacité maximale, il faut faire de la place. Selon le service, les échanges les plus anciens peuvent alors être écartés, condensés ou tronqués.
Voilà pourquoi une IA peut finir par perdre le fil d’une très longue conversation, oublier une consigne donnée plus tôt ou passer soudainement à côté d’un détail qu’elle avait jusque-là correctement intégré à ses réponses.
Attention toutefois à ne pas confondre fenêtre de contexte et mémoire. La première correspond aux informations auxquelles le modèle a accès pour traiter la requête en cours. La mémoire, lorsqu’un service en propose une, lui permet au contraire de conserver certaines informations au-delà de ce contexte, y compris d’une conversation à l’autre. Une fenêtre de 200 000 tokens ne signifie donc pas que l’IA « se souvient » durablement de 200 000 tokens de vos échanges.
Par ailleurs, plus grand ne veut pas nécessairement dire meilleur. Une fenêtre de contexte plus généreuse permet au modèle de travailler avec davantage d’informations en même temps, par exemple un long document ou un historique conséquent. Elle ne garantit cependant pas qu’il saura exploiter chaque élément avec la même précision, ni qu’il produira une réponse de meilleure qualité.
Deux dollars le million de tokens en entrée, dix en sortie… qui dit mieux ?
Évidemment, générer et traiter tous ces tokens n’est pas gratuit. Sur un chatbot grand public, le coût de chaque échange se fait plutôt discret : on paie éventuellement une somme fixe chaque mois, puis on discute avec ChatGPT ou Google Gemini sans voir le compteur défiler à chaque message.
Avec les API, en revanche, c’est le token qui fait les comptes : chaque requête est facturée selon le nombre et le type de tokens mobilisés. Car le tarif varie selon leur rôle. Les tokens générés en sortie coûtent généralement plus cher que ceux fournis en entrée : le modèle doit les produire un à un, quand il peut traiter une grande partie des tokens d’entrée en parallèle.
Ce mode de facturation colle aussi à des usages bien plus gourmands qu’une discussion avec un chatbot. Une API peut servir à passer au crible des milliers de documents, automatiser des traitements qui sollicitent le modèle en continu ou alimenter des agents capables de consulter des bases de données, manipuler des logiciels et enchaîner plusieurs actions de manière quasi autonome. Bref, des ordres de grandeur qui n’ont plus grand-chose à voir avec une recette de lasagnes végétariennes générée par ChatGPT.
Et pour les images, l’audio ou la vidéo ?
Nous n'avons que parlé de texte, mais les modèles multimodaux ne se limitent évidemment plus aux mots. Ils peuvent aussi, selon leurs capacités, traiter ou générer des images, de l’audio et de la vidéo. Là encore, ces contenus doivent être convertis sous une forme que le modèle peut manipuler, et leur consommation peut elle aussi être exprimée en tokens.
Le calcul est en revanche encore moins intuitif que pour du texte. Il n’existe pas d’équivalence universelle permettant de convertir une image ou une minute d’audio en un nombre donné de tokens. Selon le modèle et le fournisseur, le nombre de tokens consommés peut varier en fonction de la résolution d’une image, de la durée d’un enregistrement ou d’une vidéo, mais aussi de la façon dont ces contenus sont découpés et traités.
Alors, peut-on savoir combien de tokens un échange avec une IA consomme réellement ? Oui, à condition de connaître le modèle utilisé et la manière dont il traite les contenus. Pour le texte, le décompte dépend notamment du tokenizer, et les fournisseurs proposent des outils pour compter les tokens en entrée avant même l’envoi d’une requête. Pour connaître le nombre exact de tokens en sortie, il faut en revanche attendre que le modèle ait finalisé sa réponse.
