Comprendre la fenêtre de contexte

#Ce que contient la fenêtre de contexte

Selon la documentation d'Ollama, la longueur de contexte est le nombre maximal de tokens auxquels le modèle a accès en mémoire. Tout s'additionne dans ce budget unique : le message système, l'historique de la conversation, les fichiers ou passages de documents que vous collez, votre dernière question et la réponse que le modèle est en train d'écrire. Pour un modèle de raisonnement, les tokens de réflexion comptent aussi. Quand le total dépasse la fenêtre, quelque chose doit sauter : les outils tronquent généralement le début, ou refusent la requête. Le modèle n'a aucune mémoire hors de cette fenêtre, sauf si un système extérieur (résumé, RAG) lui réinjecte des informations.

#Le token : l'unité qui remplit la fenêtre

Un token n'est pas un mot : c'est un fragment de texte défini par le tokenizer du modèle, souvent une syllabe ou un mot courant. Un mot rare ou long en occupe plusieurs. Le français consomme en général plus de tokens que l'anglais pour un contenu équivalent, parce que la plupart des tokenizers sont entraînés surtout sur de l'anglais. Le rapport exact varie d'un modèle à l'autre : plutôt que de vous fier à une règle de pouce, mesurez. L'API d'Ollama renvoie prompt_eval_count, le nombre de tokens du prompt, à chaque requête.

curl http://localhost:11434/api/generate -d '{"model":"qwen3:8b","prompt":"Bonjour le monde","stream":false}'
# lisez prompt_eval_count et eval_count dans la réponse JSON

Règle de pouce

Une page A4 de texte français dense représente de l'ordre de un millier de tokens, selon le tokenizer : validez avec prompt_eval_count sur votre propre document.

Un livre

Plusieurs centaines de milliers de tokens : hors de portée d'une fenêtre de 32 000 ou 64 000 tokens sans découpage.

Une réponse

Un modèle de raisonnement peut produire des milliers de tokens de réflexion avant la réponse visible, qui consomment la fenêtre.

#Quelle taille de fenêtre choisir

Ollama fixe sa valeur par défaut selon la mémoire vidéo : 4 000 tokens environ (4k) sous 24 Gio de VRAM, 32k entre 24 et 48 Gio, 256k à partir de 48 Gio. La même page recommande au moins 64 000 tokens pour les tâches qui exigent un grand contexte, comme la recherche web, les agents et les outils de codage. Les modèles récents annoncent des maxima bien plus élevés : le catalogue QuelLLM indique par exemple environ 256 000 tokens pour Kimi K2.5 et environ 1 million pour Kimi K3, DeepSeek V4 Flash et GLM 5.2. Mais un maximum annoncé n'est pas un contexte utilisable sur votre machine : la mémoire, et parfois la qualité, s'y opposent.

Deux pièges de dimensionnement reviennent souvent. D'abord, la fenêtre doit contenir la réponse : si vous remplissez 31 000 des 32 000 tokens avec un document, il ne reste presque rien pour répondre, et un modèle de raisonnement s'arrêtera en pleine réflexion. Ensuite, dans une conversation, l'historique grossit à chaque tour : une fenêtre qui suffit au premier message peut être saturée au vingtième. Prévoyez donc le pire cas de votre usage, pas le cas moyen, et gardez une marge d'environ un cinquième de la fenêtre.

#Combien de mémoire coûte le contexte

Chaque token présent dans la fenêtre laisse dans chaque couche du modèle une clé et une valeur, stockées dans le cache KV. Le coût par token se calcule à partir de quatre nombres de l'architecture : le nombre de couches, le nombre de têtes clé-valeur, la dimension d'une tête, et la taille d'un nombre (2 octets en FP16). La formule est : 2 (clé et valeur) × couches × têtes KV × dimension de tête × 2 octets. Attention : ce sont les têtes clé-valeur qui comptent, et non les têtes d'attention, car les modèles récents en partagent plusieurs (grouped-query attention). Le calcul avec les têtes d'attention surestime le cache d'un facteur de quatre pour le modèle ci-dessous.

Prenons Qwen3-8B, dont la fiche officielle indique 36 couches et 8 têtes clé-valeur (contre 32 têtes de requête), la configuration publique fixant la dimension d'une tête à 128. Le coût est de 2 × 36 × 8 × 128 × 2 = 147 456 octets par token, soit 144 Kio.

Deux leviers réduisent le cache. Le premier est la quantification du cache : la FAQ d'Ollama indique que le type q8_0 consomme environ la moitié de la mémoire du FP16 avec une perte très faible, et q4_0 environ un quart avec une perte plus visible aux grands contextes ; ils exigent que Flash Attention soit activée. Le second est de réduire la fenêtre à ce dont vous avez besoin. Notre guide sur le KV cache détaille les réglages.

#Régler la longueur de contexte

#Sous Ollama

Ollama permet de fixer la longueur par défaut au démarrage du serveur, de la changer pour une session ou de la préciser requête par requête via l'API.

# Valeur par défaut pour tout le serveur
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Pour une session interactive
>>> /set parameter num_ctx 16384

# Pour un modèle personnalisé (Modelfile)
FROM qwen3:8b
PARAMETER num_ctx 16384

Après le chargement, exécutez ollama ps : la colonne CONTEXT affiche la longueur allouée et la colonne PROCESSOR indique la répartition entre GPU et CPU. Si une part passe sur le CPU, réduisez le contexte ou prenez un modèle plus petit.

#Sous LM Studio

Dans LM Studio, la longueur de contexte se règle au chargement du modèle, dans les paramètres de chargement. Changer la valeur oblige à recharger le modèle. Surveillez l'estimation de mémoire affichée avant de valider.

#Une procédure de réglage en quatre étapes

1. 01
   Mesurer le besoin réel

   Envoyez votre document ou votre historique typique et lisez prompt_eval_count. Ajoutez la longueur de réponse attendue, et de la réflexion si le modèle en produit.
2. 02
   Choisir la fenêtre

   Prenez la plus petite valeur qui contient ce total avec 20 % de marge, au moins 64 000 tokens si vous utilisez un agent ou un outil de codage, comme le conseille Ollama.
3. 03
   Vérifier la mémoire

   Chargez le modèle avec cette fenêtre et lancez ollama ps. Le processeur doit afficher 100 % GPU ; sinon, réduisez la fenêtre, quantifiez le cache ou changez de modèle.
4. 04
   Tester le rappel

   Placez un fait précis au milieu d'un long texte et demandez-le. Si le modèle le manque, la fenêtre annoncée dépasse ce qu'il exploite, et un découpage ou un RAG s'impose.

#Grande fenêtre ne veut pas dire lecture fidèle

Une étude de 2023, « Lost in the Middle », montre que les performances des modèles peuvent se dégrader nettement selon la position de l'information dans le contexte : elles sont souvent meilleures quand l'information se trouve au début ou à la fin, et se dégradent quand elle est au milieu, même pour des modèles annoncés comme à long contexte. Le benchmark RULER, publié en 2024, va plus loin : presque tous les modèles testés perdent beaucoup en précision quand la longueur augmente, et seule la moitié d'entre eux garde un niveau satisfaisant à 32 000 tokens, alors que tous annonçaient 32 000 ou plus.

Ces travaux portent sur des modèles de leur époque et ne disent rien des modèles de 2026, dont plusieurs sont entraînés spécifiquement pour le long contexte. Mais la conduite à tenir reste valable : placez la consigne et les faits critiques au début, rappelez la question à la fin, et mesurez sur vos documents avant de vous fier à une fenêtre annoncée de plusieurs centaines de milliers de tokens. Le test le plus simple consiste à glisser une information précise au milieu d'un long texte de votre domaine, puis à la redemander : si le modèle la retrouve à chaque essai, la fenêtre est exploitable pour votre usage ; s'il la rate, réduisez le texte envoyé ou passez par un découpage.

#Quand le contenu déborde

Résumer au fil de l'eau

Faites produire un résumé de l'échange tous les quelques tours et repartez avec ce résumé en tête de contexte : vous perdez du détail, mais vous gardez le fil.

Découper le document

Un long PDF se traite section par section, puis les réponses partielles sont agrégées. Le guide sur le chunking détaille les tailles utiles.

Passer à un RAG

Quand le corpus dépasse largement la fenêtre, on récupère les quelques passages pertinents au lieu de tout envoyer.

Choisir un modèle à plus grand contexte

Seulement si la mémoire suit : reportez-vous au calcul du cache KV plus haut avant de doubler la fenêtre.

#Pour aller plus loin

• Quantifier le KV cache : gagner de la VRAM
• Tokens et tokenization : comprendre ce que mange un LLM
• Choisir sa quantification (Q4, Q5, Q8, FP16)
• Le RAG, c'est quoi et comment ça fonctionne
• Stratégies de chunking
• Calculateur de VRAM

• Source : documentation Ollama, longueur de contexte
• Source : FAQ Ollama (cache KV, Flash Attention)
• Source : Lost in the Middle (arXiv 2023)
• Source : RULER, benchmark de long contexte (arXiv 2024)