Token : définition, ordres de grandeur et coût dans un LLM

Un token est le plus petit morceau de texte qu'un grand modèle de langage sait manipuler. Selon sa fréquence, un mot peut tenir en un seul token (« the », « est », « maison ») ou être découpé en plusieurs fragments (« anticonstitutionnellement » en compte plusieurs). La ponctuation, les chiffres, les espaces et les retours à la ligne sont eux aussi représentés par des tokens.

Ce découpage est fixé par le tokenizer associé à chaque modèle, avec un vocabulaire de plusieurs dizaines de milliers de tokens, voire davantage. La manière dont ce vocabulaire est construit fait l'objet d'une fiche dédiée : la tokenisation. Pour comprendre le token, il suffit de retenir que le modèle ne voit jamais de lettres ni de mots, seulement une suite d'identifiants numériques qu'il transforme en vecteurs, puis qu'il prolonge un token à la fois. C'est ce mécanisme, hérité de l'architecture Transformer, qui explique pourquoi un LLM « écrit » au fil de l'eau.

Le token est aussi devenu l'unité économique de l'IA générative. La mémoire de travail d'un modèle (sa fenêtre de contexte), sa vitesse (en tokens par seconde) et le prix des API (en dollars par million de tokens) s'expriment tous dans cette unité. Savoir estimer le nombre de tokens d'une requête est donc une compétence de base pour concevoir, budgéter et optimiser une application LLM.

À retenir : un token n'est ni un caractère ni un mot. C'est un fragment de texte défini par le vocabulaire du modèle, et c'est lui que l'on compte pour mesurer le contexte, la latence et le coût.

Le nombre exact dépend du tokenizer, mais quelques ordres de grandeur permettent d'estimer rapidement une requête. La règle la plus citée, issue de la documentation d'OpenAI pour l'anglais, est la suivante : un token correspond à environ quatre caractères, soit à peu près trois quarts de mot.

Ces chiffres sont des repères, pas des constantes. Le français mobilise plus de tokens que l'anglais parce que les vocabulaires des tokenizers sont construits sur des corpus majoritairement anglophones : les mots français, leurs accents et leurs flexions y sont moins souvent représentés d'un seul tenant. Les modèles récents, dotés de vocabulaires plus vastes et plus multilingues, réduisent cet écart sans le supprimer. Pour un chiffrage fiable, comptez toujours avec le tokenizer du modèle visé.

Trois contraintes concrètes d'un projet LLM se mesurent en tokens.

La fenêtre de contexte

La fenêtre de contexte est le nombre maximal de tokens que le modèle peut traiter en une fois. Elle englobe les instructions système, l'historique de conversation, les documents injectés, la définition des outils et la réponse générée. Selon les modèles, elle va de quelques milliers à plus d'un million de tokens. Une grande fenêtre ne dispense pas de trier l'information : plus le contexte est long, plus la requête est lente et coûteuse, et plus le modèle risque de négliger un détail noyé au milieu. C'est tout l'enjeu du context engineering et des architectures RAG, qui ne transmettent que les passages utiles.

La facturation au token

Les API de LLM facturent séparément les tokens d'entrée (le prompt complet) et les tokens de sortie (la réponse). Les seconds sont généralement plusieurs fois plus chers que les premiers. Deux subtilités pèsent sur la facture :

• les tokens mis en cache : lorsqu'un long début de prompt est réutilisé à l'identique (instructions, documentation), de nombreux fournisseurs le facturent à tarif réduit ;
• les tokens de raisonnement : les modèles de raisonnement produisent une réflexion intermédiaire, facturée comme de la sortie même quand elle n'est pas affichée.

Pour une analyse complète des arbitrages entre API et auto-hébergement, voir notre article FinOps des LLM.

La latence

Le temps de réponse se décompose en deux phases. La lecture du prompt (prefill) traite tous les tokens d'entrée en parallèle et détermine le délai avant le premier token affiché. La génération (decode) produit ensuite les tokens de sortie un par un : sa durée est proportionnelle à la longueur de la réponse. Une réponse deux fois plus longue prend donc à peu près deux fois plus de temps, d'où l'intérêt de limiter la sortie et de diffuser la réponse en streaming. Côté infrastructure, c'est ce débit en tokens par seconde que des serveurs comme vLLM cherchent à maximiser.

Toutes les API renvoient, avec la réponse, le détail des tokens consommés. L'exemple suivant utilise le SDK Python d'OpenAI, mais la logique est identique chez les autres fournisseurs. Les tarifs sont fictifs : remplacez-les par ceux de votre modèle.

from openai import OpenAI

client = OpenAI()

MODELE = "gpt-4o-mini"      # modèle choisi
PRIX_ENTREE = 0.50          # $ par million de tokens d'entrée (fictif)
PRIX_SORTIE = 2.00          # $ par million de tokens de sortie (fictif)

with open("compte-rendu.txt", encoding="utf-8") as f:
    document = f.read()

response = client.chat.completions.create(
    model=MODELE,
    messages=[
        {"role": "system", "content": "Résume le document en trois points."},
        {"role": "user", "content": document},
    ],
    max_completion_tokens=300,  # plafonne la sortie, donc le coût et la latence
)

usage = response.usage
cout = (usage.prompt_tokens * PRIX_ENTREE + usage.completion_tokens * PRIX_SORTIE) / 1_000_000

print(f"Entrée : {usage.prompt_tokens} tokens")
print(f"Sortie : {usage.completion_tokens} tokens")
print(f"Coût estimé : {cout:.5f} $")

Multipliez ce coût unitaire par le volume attendu et vous obtenez une première estimation budgétaire. En production, ce calcul est automatisé par un outil d'observabilité qui agrège les tokens par fonctionnalité, par utilisateur ou par agent. Les agents, qui enchaînent de nombreux appels et renvoient tout leur historique à chaque étape, sont particulièrement gourmands : notre article sur le coût des agents IA détaille comment les maîtriser.

Optimiser les tokens revient à n'envoyer et ne générer que ce qui est utile. Les leviers, par ordre d'effort croissant :

• Raccourcir les instructions système : supprimer les répétitions et les exemples superflus d'un prompt envoyé à chaque requête.
• Limiter la sortie : fixer une longueur maximale et demander un format concis (liste, JSON compact).
• Sélectionner le contexte : injecter trois passages pertinents plutôt que vingt, grâce à un bon retriever et à un reranking.
• Résumer l'historique : remplacer les anciens échanges d'une conversation par une synthèse.
• Profiter du cache : placer les parties stables du prompt au début pour bénéficier du tarif réduit des tokens mis en cache.
• Router vers le bon modèle : confier les tâches simples (classification, extraction) à un modèle plus petit et moins cher.

En plus des fragments de texte, le vocabulaire d'un modèle contient des tokens spéciaux qui n'apparaissent jamais dans votre prose mais structurent la séquence :

• début et fin de séquence : ils signalent où commence le texte et où le modèle doit s'arrêter de générer ;
• marqueurs de rôle : dans un modèle conversationnel, ils séparent les messages système, utilisateur et assistant selon un format appelé modèle de chat (chat template) ;
• séparateurs et remplissage : les modèles de type BERT utilisent par exemple [CLS], [SEP] et [PAD] pour délimiter et aligner les séquences ;
• appels d'outils et raisonnement : certains modèles disposent de tokens dédiés pour encadrer un appel de fonction ou une phase de réflexion.

Ces tokens comptent dans la fenêtre de contexte et, le plus souvent, dans la facturation. Ils expliquent pourquoi le nombre de tokens d'entrée annoncé par une API dépasse légèrement celui de votre seul texte.