Les tokens sont créés par un tokenizer, un algorithme séparé qui s'exécute avant que le réseau de neurones ne voie votre texte. L'approche la plus courante aujourd'hui est le Byte Pair Encoding (BPE), utilisé par GPT, Claude et Llama. Le BPE commence avec des caractères individuels (ou des octets) et fusionne itérativement les paires les plus fréquentes en nouveaux tokens. Après suffisamment de fusions, des mots courants comme « the » ou « and » deviennent des tokens uniques, tandis que les mots rares ou spécialisés sont découpés en fragments de sous-mots. Le mot « tokenization » lui-même pourrait devenir « token » + « ization » ou « token » + « iz » + « ation » selon le tokenizer spécifique. Cette approche par sous-mots est ce qui permet aux modèles modernes de gérer raisonnablement les fautes d'orthographe, les néologismes et le code — ils ne rencontrent jamais un mot véritablement « inconnu », juste des combinaisons inhabituelles de fragments connus.
Différents modèles utilisent différents tokenizers avec différents vocabulaires, et cela compte plus que la plupart des gens ne le réalisent. Le tokenizer de GPT-4 (cl100k) possède environ 100 000 types de tokens. Celui de Claude est différent. Llama en utilise encore un autre. La même phrase en anglais peut se tokeniser en un nombre différent de tokens selon le modèle utilisé, ce qui affecte directement l'utilisation de la fenêtre de contexte et les coûts d'API. Le code tend à être moins efficace en tokens que la prose parce que les noms de variables et les tokens syntaxiques n'apparaissent pas assez fréquemment dans les données d'entraînement pour mériter leur propre entrée de vocabulaire. Les langues non anglaises varient énormément — les langues à alphabet latin se tokenisent généralement presque aussi efficacement que l'anglais, mais le chinois, le japonais, le coréen, l'arabe et l'hindi nécessitent souvent plus de tokens par sens équivalent parce que leurs caractères n'étaient pas aussi fortement représentés lors de l'entraînement du tokenizer.
La taille du vocabulaire du tokenizer crée un véritable compromis d'ingénierie. Un vocabulaire plus grand signifie que les mots et expressions courants obtiennent leurs propres tokens dédiés, de sorte que votre texte se compresse en moins de tokens (moins cher, plus rapide, plus de contenu dans le contexte). Mais un vocabulaire plus grand signifie aussi une table d'embeddings plus volumineuse aux couches d'entrée et de sortie du modèle, ce qui augmente la taille du modèle et l'utilisation de la mémoire. La table d'embeddings pour un vocabulaire de 100 000 tokens à une dimension de modèle de 4 096 fait déjà 400 millions de paramètres — une part non négligeable d'un modèle plus petit. C'est pourquoi les tailles de vocabulaire tendent à se regrouper dans la fourchette 32K–128K : c'est le point d'équilibre entre efficacité de compression et surcoût en paramètres.
Quand les fournisseurs annoncent des fenêtres de contexte — 8K, 128K, 1M tokens — ces chiffres incluent tout : votre prompt système, votre historique de conversation, tous les documents que vous collez, et la propre réponse du modèle. Une erreur courante des développeurs est de bourrer la fenêtre de contexte de matériel de référence en ne laissant pas assez de tokens pour que le modèle génère une réponse substantielle. La plupart des API vous permettent de définir un paramètre max_tokens pour la réponse, mais si votre entrée a déjà consommé la majeure partie de la fenêtre de contexte, le modèle peut tronquer sa réflexion ou refuser de répondre. En pratique, il faut budgétiser : connaître la limite de contexte de votre modèle, estimer la taille de votre entrée (la règle des 3/4 de mot est un guide approximatif — pour la précision, utilisez la bibliothèque de tokenization du fournisseur), et réserver assez de place pour la sortie dont vous avez besoin.
Il y a aussi une dimension de coût que la plupart des gens sous-estiment. Les tokens de sortie sont typiquement 3 à 5 fois plus chers que les tokens d'entrée dans les grilles tarifaires d'API, parce que générer chaque token de sortie nécessite un passage complet à travers le modèle, tandis que les tokens d'entrée peuvent être traités en parallèle. Cette asymétrie signifie qu'un chatbot donnant des réponses longues et verbeuses coûte dramatiquement plus cher qu'un chatbot entraîné à être concis. C'est aussi pourquoi des techniques comme le prompt caching (réutilisation des tokens d'entrée traités à travers plusieurs requêtes) peuvent réduire significativement les coûts pour les applications qui partagent un prompt système ou un contexte de document commun entre de nombreuses requêtes. Comprendre l'économie des tokens n'est pas qu'académique — c'est la différence entre une fonctionnalité IA qui coûte 50 $/mois à faire tourner et une qui en coûte 5 000 $.