Glossaire des tokens IA

Un token est la plus petite unité qu'un modèle de langage lit et génère. Plutôt que de traiter des caractères individuels ou des mots entiers, les LLM modernes découpent le texte en fragments de sous-mots et attribuent à chaque fragment un identifiant entier. Le modèle opère ensuite entièrement sur ces identifiants.

En anglais, un token équivaut à environ 4 caractères ou aux trois quarts d'un mot. Les mots courts et courants comme « the », « is » et « in » ne forment souvent qu'un seul token. Les mots plus longs ou plus rares sont divisés en deux fragments ou plus. La ponctuation, les espaces et les nombres comptent chacun séparément, et le code ou les écritures non latines peuvent se tokeniser de façon plus coûteuse que la prose anglaise.

Les fournisseurs d'API facturent au token à la fois l'entrée (ce que vous envoyez) et la sortie (ce que le modèle génère). Cela signifie qu'un texte plus long coûte plus cher et utilise davantage la fenêtre de contexte du modèle. Comprendre les tokens est la première étape pour prévoir et maîtriser les coûts d'API.

Un tokenizer est l'algorithme ou le programme chargé de convertir du texte brut en une séquence de tokens (et inversement). Il construit un vocabulaire fixe de fragments de sous-mots durant l'entraînement, puis, au moment de l'inférence, découpe chaque nouvelle entrée selon ce vocabulaire et associe chaque fragment à un identifiant entier unique.

Chaque famille de modèles est livrée avec son propre tokenizer et son propre vocabulaire. Cela compte car le même texte peut produire des comptages de tokens différents selon le modèle utilisé. Une phrase qui se tokenise en 50 tokens avec GPT-4o pourrait produire 47 ou 55 tokens avec Claude ou Gemini. La différence provient de la taille du vocabulaire, des règles de fusion apprises durant l'entraînement et de la façon dont le tokenizer traite les espaces et les caractères spéciaux.

Pour un texte en anglais, les comptages des principaux fournisseurs se situent généralement à 5 à 15 % les uns des autres. L'écart se creuse pour le code, les écritures non latines et le contenu fortement mis en forme. C'est pourquoi les calculateurs de tokens destinés aux modèles autres qu'OpenAI utilisent souvent un facteur d'échelle estimé plutôt que le tokenizer exact du modèle.

Le Byte-Pair Encoding (BPE) est un algorithme inspiré de la compression qui construit un vocabulaire de sous-mots en fusionnant itérativement la paire d'unités adjacentes la plus fréquente. Le processus part d'octets ou de caractères individuels et applique des milliers d'opérations de fusion jusqu'à ce que le vocabulaire atteigne une taille cible (par exemple 50 000 ou 100 000 entrées).

Le résultat est un vocabulaire dans lequel les mots et fragments de mots courants en anglais obtiennent chacun leur propre token, tandis que les mots rares sont découpés en fragments plus petits qui figurent tout de même dans le vocabulaire. Cela équilibre deux objectifs concurrents : un petit vocabulaire est efficace, mais découper chaque mot en caractères rend les séquences très longues et coûteuses. Le BPE se situe entre les deux, gardant les séquences gérables tout en traitant n'importe quel mot, même un mot jamais rencontré à l'entraînement.

Les modèles GPT d'OpenAI utilisent le BPE via leur bibliothèque tiktoken. De nombreux autres modèles utilisent également des variantes du BPE, dont certains modèles Llama et Mistral. Les règles de fusion et le vocabulaire précis diffèrent selon les implémentations, ce qui explique qu'un texte identique produise des comptages différents selon les modèles, même lorsque les deux utilisent le BPE.

SentencePiece est une bibliothèque de tokenisation développée par Google qui adopte une approche différente du BPE façon tiktoken. Plutôt que d'exiger une étape de prétokenisation spécifique à la langue (comme découper selon les espaces avant d'appliquer les règles de fusion), SentencePiece traite l'intégralité de l'entrée comme un flux brut de caractères Unicode, espaces compris. Les espaces sont représentés par un marqueur spécial ressemblant à un tiret bas, que l'on peut voir dans la sortie tokenisée (souvent affiché comme le caractère « _ » ou un symbole Unicode spécial).

Cette conception rend SentencePiece indépendant de la langue. Il gère le japonais, le chinois, l'arabe et d'autres écritures qui n'utilisent pas les espaces comme limites de mots aussi naturellement que l'anglais. Il prend en charge deux algorithmes principaux : le BPE et la tokenisation par modèle de langage unigramme.

Des modèles comme Gemini, Llama, T5 et de nombreux modèles multilingues utilisent SentencePiece. Comme il traite les espaces différemment, la même phrase en anglais peut se tokeniser avec un comptage légèrement différent de celui obtenu avec le BPE de tiktoken, même à taille de vocabulaire similaire. C'est l'une des principales raisons pour lesquelles les comptages de tokens ne sont pas interchangeables entre fournisseurs.

tiktoken est la bibliothèque de tokenizer BPE rapide et open source publiée par OpenAI. C'est ce qu'utilise l'API d'OpenAI elle-même pour compter les tokens à des fins de facturation, si bien qu'utiliser tiktoken dans un calculateur produit des comptages exacts pour les modèles OpenAI plutôt que des estimations.

tiktoken est livré avec plusieurs encodages nommés correspondant à différentes générations de modèles. Les deux plus importants sont cl100k_base, qui couvre GPT-3.5 Turbo et les modèles de la série GPT-4, et o200k_base, qui couvre GPT-4o, GPT-5 et les modèles de raisonnement de la série o. Le nombre dans le nom fait référence à la taille approximative du vocabulaire : 100 000 et 200 000 tokens respectivement. Le vocabulaire plus large permet au nouvel encodage de représenter davantage d'éléments en un seul token, produisant souvent des comptages de tokens légèrement plus bas pour le même texte.

Ce calculateur de tokens exécute des encodages compatibles tiktoken directement dans votre navigateur grâce à une compilation WebAssembly, si bien que votre texte ne quitte jamais votre appareil et que les comptages pour les modèles OpenAI sont exacts.

La fenêtre de contexte est le nombre maximal de tokens qu'un modèle peut conserver dans sa « mémoire de travail » à un instant donné. Elle couvre tout ce qui se trouve dans une seule requête : le message système, l'historique de la conversation, les documents éventuellement joints, le message de l'utilisateur et la sortie du modèle. Si le total dépasse la fenêtre, vous devez raccourcir l'entrée, faute de quoi l'API renvoie une erreur.

La taille des fenêtres de contexte a augmenté rapidement d'une génération à l'autre. Le premier GPT-3 disposait d'une fenêtre de 4 096 tokens. Les modèles de pointe actuels prennent en charge des fenêtres se mesurant en centaines de milliers, voire en millions de tokens, ce qui permet de faire passer des bases de code entières ou des livres entiers dans une seule requête.

Une fenêtre de contexte plus grande vous permet de fournir davantage de documents, de maintenir des conversations plus longues et de donner au modèle plus d'exemples pour travailler. La contrepartie est le coût : davantage de tokens d'entrée signifie une facture plus élevée. Certains éléments suggèrent également que des contextes très longs peuvent réduire la qualité de l'attention portée aux informations situées au milieu d'un prompt, un phénomène parfois appelé « perdu au milieu ». Garder des prompts aussi concis que nécessaire est généralement une bonne pratique, tant pour le coût que pour la qualité de la sortie.

Les fournisseurs d'API divisent la facturation des tokens en deux catégories. Les tokens d'entrée (aussi appelés tokens de prompt) sont tout ce que vous envoyez au modèle dans une requête : le message système, l'historique complet de la conversation, tout document ou contexte que vous joignez, et le message le plus récent de l'utilisateur. Les tokens de sortie (aussi appelés tokens de complétion) sont les tokens que le modèle génère dans sa réponse.

Ils sont tarifés séparément car générer des tokens est plus coûteux en calcul que les lire. Les tokens de sortie coûtent généralement plusieurs fois plus par million que les tokens d'entrée, même si le ratio exact varie selon le fournisseur et le modèle.

La formule du coût d'une requête est simple :

Coût total = (tokens d'entrée / 1 000 000) x prix d'entrée par million + (tokens de sortie / 1 000 000) x prix de sortie par million

Pour estimer les coûts d'une application, vous devez tenir compte des deux côtés. Les coûts d'entrée dominent pour les applications avec de longs messages système ou de grands contextes récupérés. Les coûts de sortie dominent pour les tâches produisant des réponses verbeuses, comme la rédaction de documents ou la génération de code. Le calculateur de tokens vous permet de définir séparément les longueurs d'entrée et de sortie attendues afin de modéliser les deux.

La mise en cache de prompt est une fonctionnalité proposée par plusieurs fournisseurs (dont Anthropic et OpenAI) qui vous permet de marquer une partie de votre prompt comme pouvant être mise en cache. Lorsque l'API revoit le même préfixe en cache dans une requête ultérieure, elle facture un prix nettement réduit pour ces tokens au lieu de les traiter à plein tarif. Les succès de cache coûtent généralement une fraction du tarif d'entrée normal, souvent autour de 10 à 25 % du tarif standard, selon le fournisseur.

Certains fournisseurs facturent une petite prime pour écrire une nouvelle entrée dans le cache (car le stockage de l'état clé-valeur a un coût), mais ce coût d'écriture est généralement rentabilisé rapidement si vous réutilisez le préfixe plus d'une ou deux fois.

La mise en cache de prompt est particulièrement utile lorsqu'un préfixe volumineux et statique apparaît dans de nombreuses requêtes : un long message système, un document de référence, un fichier de code ou un ensemble d'exemples few-shot. Si votre application ajoute toujours un document de 10 000 tokens avant chaque question de l'utilisateur, mettre ce document en cache peut réduire substantiellement les coûts d'entrée par requête.

Elle est moins utile pour les charges de travail où le prompt est unique à chaque fois ou où le préfixe pouvant être mis en cache change fréquemment. Les caches expirent également après une période d'inactivité (les durées de vie exactes varient selon le fournisseur), donc les requêtes très peu fréquentes pourraient ne pas en bénéficier.

Une API par lot est un mode de traitement asynchrone où vous soumettez de nombreuses requêtes à la fois (généralement sous forme de fichier JSONL) et recevez les résultats plus tard, dans une fenêtre de temps promise généralement jusqu'à 24 heures. Comme le fournisseur peut planifier vos requêtes pendant les périodes de capacité creuse, il offre une remise substantielle, souvent d'environ 50 % par rapport à l'API synchrone en temps réel.

Le traitement par lot convient bien aux charges de travail qui n'ont pas besoin de réponse instantanée : évaluer un grand jeu de données, générer des descriptions pour un catalogue de produits, classer des milliers de tickets d'assistance, exécuter une suite de tests de régression sur un nouveau modèle, ou traiter de gros volumes de documents pendant la nuit.

Il convient mal à tout ce qui est destiné à l'utilisateur et nécessite une réponse en temps réel, ou aux pipelines où chaque étape dépend de la sortie de la précédente (car vous pourriez devoir attendre de nombreuses heures entre les étapes).

Lors de la budgétisation des charges de travail par lot, diviser par deux le prix par token peut faire une différence significative à grande échelle. Si vous traitez des millions de tokens par jour dans des tâches non urgentes, les acheminer via l'API par lot plutôt que via le point d'accès synchrone est l'un des moyens les plus simples de réduire les coûts d'infrastructure.

Un budget de tokens est un plafond planifié du nombre de tokens qu'une tâche, une requête ou une application donnée est autorisée à utiliser. Fixer un budget répond à deux objectifs : garder les coûts prévisibles et empêcher les requêtes de dépasser par inadvertance la fenêtre de contexte du modèle.

Un budget de tokens pratique couvre généralement trois domaines : le message système et le contexte statique (fixe par déploiement), le contexte dynamique ajouté par requête (documents récupérés, historique de conversation, saisie utilisateur), et la longueur de sortie maximale (contrôlée via le paramètre max_tokens). Additionner ces trois éléments et les comparer à la limite de contexte du modèle indique si votre conception tiendra.

Les techniques courantes pour rester dans un budget incluent raccourcir les messages système, limiter le nombre de fragments récupérés dans les pipelines RAG, tronquer ou résumer les anciens tours de conversation, et plafonner le paramètre max_tokens pour éviter des sorties incontrôlées.

Estimer votre budget avant de construire est bien plus simple que de déboguer un dépassement en production. Utilisez le calculateur de tokens pour mesurer vos prompts et voir exactement où se situe votre nombre de tokens avant de vous engager sur un modèle ou un niveau tarifaire.