Accueil › Glossaire › Max Tokens

Max Tokens : comprendre les limites de longueur des LLM

Le paramètre max_tokens définit le nombre maximal de tokens que le modèle peut générer dans sa réponse. C’est un plafond de sortie, pas la taille de la fenêtre de contexte. Il est distinct de la limite de contexte totale du modèle, qui inclut à la fois l’entrée (prompt) et la sortie. Bien comprendre ces distinctions est essentiel pour maîtriser les coûts, éviter les réponses tronquées et exploiter pleinement les capacités des LLM.

Trois concepts à distinguer

La confusion entre ces trois termes est la source d’erreur la plus fréquente chez les développeurs qui débutent avec les API de LLM :

1. Fenêtre de contexte (context window)

C’est la capacité totale du modèle : le nombre maximum de tokens qu’il peut traiter en une seule requête, entrée et sortie combinées. Par exemple, si un modèle a une fenêtre de contexte de 128K tokens, la somme de votre prompt et de sa réponse ne peut pas dépasser 128 000 tokens.

La fenêtre de contexte est une caractéristique du modèle, fixée lors de l’entraînement (puis éventuellement étendue). Vous ne pouvez pas l’augmenter via un paramètre d’API.

2. Limite de sortie (max output tokens)

C’est le nombre maximal de tokens que le modèle peut générer en une seule réponse. Ce plafond est souvent inférieur à la fenêtre de contexte. Par exemple, GPT-4o a une fenêtre de 128K tokens mais une limite de sortie de 16K tokens. Même si votre prompt ne fait que 100 tokens, la réponse ne peut pas dépasser 16K tokens.

3. Le paramètre max_tokens

C’est le paramètre que vous configurez dans votre appel API pour plafonner la longueur de la réponse. Il doit être inférieur ou égal à la limite de sortie du modèle. Si vous le fixez à 500, la réponse ne dépassera pas 500 tokens, même si le modèle pourrait en générer 16 000.

Résumé des relations :

  Fenêtre de contexte = tokens d'entrée + tokens de sortie
  Limite de sortie ≤ fenêtre de contexte
  max_tokens (votre paramètre) ≤ limite de sortie du modèle

Exemple concret :
  Modèle : GPT-4o (fenêtre 128K, limite sortie 16K)
  Votre prompt : 2 000 tokens
  max_tokens configuré : 500

  → Le modèle génère au maximum 500 tokens
  → Espace inutilisé dans la fenêtre : 128K - 2K - 0.5K = ~125.5K
  → Espace inutilisé dans la limite de sortie : 16K - 0.5K = 15.5K

Fenêtres de contexte et limites de sortie des principaux modèles

Qu’est-ce qu’un token ?

Un token n’est pas un mot. C’est l’unité de base du tokenizer du modèle, qui peut être un mot complet, une partie de mot, un signe de ponctuation, ou un espace. Les règles de conversion varient selon la langue et le tokenizer :

Anglais : ~1 token = 0,75 mot. « Hello world » = 2 tokens. « Unbelievable » = 3 tokens (« Un », « believ », « able »).

Français : ~1 token = 0,5 à 0,6 mot. Le français utilise plus de tokens par mot car les accents, la conjugaison complexe et les caractères spéciaux créent des sous-mots supplémentaires.

Code : très variable. Les identifiants longs (noms de variables, imports) consomment plusieurs tokens. Un fichier Python de 100 lignes peut facilement consommer 500 à 1000 tokens.

Langues non latines : le japonais, le chinois, le coréen, l’arabe et d’autres langues non latines utilisent significativement plus de tokens par mot (souvent 2 à 7× plus que l’anglais). C’est un facteur important pour le calcul des coûts dans les applications multilingues.

Impact sur les coûts

Les LLM facturent par token, avec des prix différents pour l’entrée et la sortie (la sortie est généralement 3 à 5× plus chère que l’entrée). Le paramètre max_tokens est votre principal levier de contrôle des coûts de sortie :

Exemple de calcul de coût (Claude Sonnet 4.6) :
  Prix : $3 / 1M tokens input, $15 / 1M tokens output

  Requête avec prompt de 1 000 tokens, réponse de 500 tokens :
  Coût = (1000 × $3/1M) + (500 × $15/1M)
       = $0.003 + $0.0075
       = $0.0105 par requête

  1 000 requêtes/jour = $10.50/jour

  Si max_tokens=200 au lieu de 500 (réponses plus courtes) :
  Coût = (1000 × $3/1M) + (200 × $15/1M) = $0.006
  1 000 requêtes/jour = $6/jour → économie de 43%

Configurer max_tokens au juste nécessaire (pas trop bas pour éviter les troncatures, pas trop haut pour éviter les coûts inutiles) est un exercice d’optimisation propre à chaque cas d’usage.

Que se passe-t-il quand max_tokens est atteint ?

Quand le modèle atteint la limite de max_tokens, la génération s’arrête brutalement, même au milieu d’un mot ou d’une phrase. L’API retourne finish_reason: "length" pour signaler que la réponse est potentiellement incomplète.

Comment gérer ce cas dans votre application :

Détecter : vérifiez systématiquement le finish_reason. Si c’est "length", la réponse est probablement tronquée.

Continuer : relancez une requête avec le texte généré comme contexte pour obtenir la suite. Certaines applications implémentent une boucle de continuation automatique.

Prévenir : ajustez max_tokens en fonction de la tâche. Pour une question factuelle courte, 200 tokens suffisent. Pour un article de blog, 2000 à 4000 tokens sont nécessaires. Pour une analyse complète d’un document, la limite de sortie du modèle peut être atteinte.

Combiner avec une stop sequence : une stop sequence bien choisie arrête la génération proprement (à un point logique) avant que max_tokens ne la coupe brutalement.

Le problème du « lost in the middle »

Avoir une grande fenêtre de contexte ne signifie pas que le modèle utilise toutes les informations de manière uniforme. Des recherches (dont « Context Rot » de Chroma Research, 2025) ont montré que les LLM traitent mieux les informations placées au début et à la fin du contexte, et tendent à « oublier » celles placées au milieu.

Les implications pratiques :

Placez les informations critiques en début de prompt : le système prompt, les instructions clés, et les documents les plus importants doivent être en premier.

Répétez les instructions clés en fin de prompt : un rappel des consignes juste avant la question améliore la conformité.

N’utilisez pas tout le contexte par réflexe : un contexte de 50K tokens ciblé (via RAG) est souvent meilleur qu’un contexte de 500K tokens qui noie l’information pertinente.

Max tokens et context engineering

Le « context engineering » est l’art de gérer efficacement l’espace disponible dans la fenêtre de contexte. Le paramètre max_tokens en est un levier clé :

Budget de contexte : pour chaque requête, calculez le budget disponible. Si votre fenêtre est de 128K tokens, votre system prompt fait 500 tokens, votre historique de conversation fait 3 000 tokens, et vous fixez max_tokens à 2 000, il vous reste 128K – 500 – 3000 – 2000 = ~122 500 tokens pour les documents RAG ou le contexte additionnel.

Conversation multi-tour : dans un chatbot, l’historique de conversation consomme du contexte à chaque tour. Avec un historique de 20 messages (environ 5 000 à 10 000 tokens), l’espace disponible pour la sortie diminue. Des stratégies comme la compaction (résumé automatique de l’historique) ou la fenêtre glissante (ne garder que les N derniers messages) permettent de maintenir un espace suffisant pour max_tokens.

Streaming et max_tokens : en mode streaming, les tokens sont envoyés au fur et à mesure de la génération. Le paramètre max_tokens contrôle le nombre total de tokens streamés. Si vous streamez une réponse longue avec max_tokens=4000, l’utilisateur voit le texte apparaître progressivement pendant plusieurs secondes. Ajustez max_tokens pour que le temps de streaming reste acceptable pour votre expérience utilisateur.

Max tokens pour les modèles locaux

Quand vous déployez un LLM localement (via Ollama, vLLM, llama.cpp ou LM Studio), la fenêtre de contexte et max_tokens ont un impact direct sur la consommation de VRAM :

Cache KV : chaque token dans le contexte consomme de la mémoire pour stocker les clés et valeurs d’attention (le cache KV). Pour un modèle 8B en FP16, augmenter le contexte de 4K à 32K tokens peut ajouter 4 à 6 Go de VRAM au-delà des poids du modèle. En quantification 4-bit, l’overhead est réduit mais reste significatif.

Valeurs par défaut souvent basses : Ollama configure par défaut un contexte de 2048 tokens, bien en dessous de la capacité réelle de la plupart des modèles. Si vos réponses sont tronquées avec un modèle local, vérifiez d’abord la configuration du contexte avant de blâmer le modèle.

Flash Attention : activez Flash Attention (disponible dans vLLM, llama.cpp, Ollama) pour réduire significativement la consommation mémoire du cache KV, permettant des fenêtres de contexte plus larges avec le même matériel.

Guide de réglage par cas d’usage

Implémentation dans les principales API

# OpenAI
from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Résume ce texte en 3 phrases."}],
    max_tokens=200,  # plafond de sortie
)
print(response.usage)
# CompletionUsage(prompt_tokens=15, completion_tokens=87, total_tokens=102)

# Anthropic (Claude)
import anthropic
client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,  # obligatoire dans l'API Anthropic
    messages=[{"role": "user", "content": "Explique le concept de tokenisation."}]
)
print(message.usage)
# Usage(input_tokens=12, output_tokens=234)

# Hugging Face Transformers
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-v0.1")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1")

inputs = tokenizer("Explique la tokenisation :", return_tensors="pt")
output = model.generate(
    **inputs,
    max_new_tokens=200,    # HF utilise "max_new_tokens" (sortie seule)
    # vs max_length qui inclut l'entrée + la sortie
)