Accueil › Glossaire › Context Length

Context Length (Longueur de Contexte)

La context length (ou fenêtre de contexte) est le nombre maximal de tokens qu’un LLM peut traiter en une seule requête, incluant le prompt d’entrée et la réponse générée. Elle détermine la quantité d’information que le modèle peut « voir » simultanément et constitue l’un des paramètres les plus critiques pour le choix d’un modèle en production.

Le concept : un « tableau blanc » limité

Imaginez un tableau blanc sur lequel vous et le LLM écrivez votre conversation. Tout ce que vous tapez, tout ce que le modèle répond, et tout document que vous collez prend de la place sur ce tableau. La context length est la taille de ce tableau. Quand il est plein, le contenu le plus ancien est effacé ou tronqué, et le modèle « oublie » cette information.

Un token représente environ 3 à 4 caractères en anglais, soit environ 0,75 mot. En français, la tokenisation est généralement moins efficace : un mot français moyen peut consommer 1,2 à 1,8 tokens selon le tokenizer. 1 000 tokens en anglais correspondent à environ 750 mots (deux pages A4), contre environ 550 à 650 mots en français.

La context length inclut à la fois l’entrée et la sortie. Si votre modèle a une fenêtre de 128K tokens et que vous envoyez 100K tokens d’entrée, il ne reste que 28K tokens pour la réponse. C’est un piège courant : les utilisateurs envoient un long document et s’étonnent que la réponse soit tronquée.

L’évolution explosive de la context length

La progression des fenêtres de contexte est l’une des évolutions les plus spectaculaires de l’IA ces dernières années :

Cette progression de 4K à 10M tokens (un facteur 2 500x) en 3 ans a été rendue possible par une combinaison d’innovations : FlashAttention (réduction de la complexité mémoire de l’attention), RoPE + YaRN (extension de l’encodage positionnel), GQA (réduction du KV cache), et sliding window attention (bornage du cache).

Ce qui détermine la context length

Le KV cache : le vrai facteur limitant

La context length est principalement limitée par la mémoire GPU disponible pour le KV cache. Chaque token dans la fenêtre de contexte nécessite le stockage de ses vecteurs Key et Value dans toutes les couches d’attention. Pour un modèle 70B en FP16, un prompt de 128K tokens consomme environ 30 à 40 Go de KV cache, soit autant ou plus que les poids du modèle lui-même.

C’est pourquoi la GQA a été si importante : en réduisant le nombre de têtes K/V de 4 à 8x, elle a permis de multiplier d’autant la longueur de contexte supportable avec le même budget mémoire. De même, les techniques de compression du KV cache (quantization, éviction, offloading) permettent de repousser cette limite.

L’encodage positionnel

Les encodages positionnels appris imposaient une limite dure (N_max) à la context length. RoPE avec ses techniques de scaling (YaRN, LongRoPE2) a levé cette contrainte, permettant d’étendre le contexte de 16x à 64x au-delà de la longueur d’entraînement avec un fine-tuning minimal. C’est cette avancée qui a rendu possibles les fenêtres de 1M+ tokens.

Le coût computationnel

L’attention complète a une complexité O(n²) par rapport à la longueur de séquence. Même avec FlashAttention, le prefill d’un prompt de 1M tokens est très coûteux en calcul. La sliding window attention et les architectures hybrides (couches SWA + couches attention complète) atténuent ce coût pour les modèles qui les utilisent.

Le problème de la dégradation : « context rot »

L’effet « Lost in the Middle »

Un phénomène bien documenté par la recherche (Stanford/Berkeley, 2023) est que les LLM récupèrent mieux l’information placée au début et à la fin de leur contexte que celle placée au milieu. L’exactitude pour les éléments en début et fin de contexte atteint typiquement 85-95%, tandis que les éléments au milieu tombent à 76-82%.

Cela signifie qu’un modèle affichant 1M tokens de context length ne récupère pas l’information de manière uniforme sur ces 1M tokens. Il y a un « creux » au milieu du contexte. Ce phénomène est appelé « context rot » ou « context degradation ».

La limite réelle vs la limite annoncée

En pratique, la plupart des modèles deviennent peu fiables bien avant leur limite annoncée. Les tests indépendants montrent typiquement une dégradation significative à environ 65-70% de la fenêtre annoncée. Le benchmark Needle-in-a-Haystack (NIAH) et ses variantes (RULER, LongBench) mesurent cette capacité de récupération effective.

Anthropic a publié des résultats montrant que Claude Opus 4.6 maintient des performances élevées sur l’ensemble de sa fenêtre de 1M tokens, là où GPT-5.4 et Gemini 3.1 Pro montrent des dégradations significatives au-delà de 256K tokens. Ce type de benchmark est cependant à prendre avec précaution : chaque laboratoire a intérêt à choisir les métriques qui flattent son modèle.

Impact sur les coûts API

La context length a un impact direct et souvent sous-estimé sur les coûts d’utilisation des API LLM.

Les surcharges long-contexte

Plusieurs fournisseurs appliquent des surcharges au-delà d’un seuil. GPT-5.4 double le prix de l’input au-delà de 272K tokens (de 2,50 $ à 5 $ par million) et majore l’output de 1,5x (de 15 $ à 22,50 $). Gemini 3.1 Pro applique une tarification spécifique plus élevée au-delà d’environ 200K tokens.

Exception notable : Claude Opus 4.6 et Sonnet 4.6 ont supprimé toute surcharge long-contexte depuis le 13 mars 2026. Une requête de 900K tokens coûte le même prix au token qu’une requête de 9K tokens. C’est un avantage concurrentiel explicitement positionné par Anthropic contre les surcharges de GPT et Gemini.

Stratégies d’optimisation des coûts

Prefix caching / prompt caching. Si vos requêtes partagent un préfixe commun (system prompt, contexte RAG), le cache de préfixe permet de ne payer le prefill qu’une seule fois. Claude offre un cache read à environ 0,1x du prix de base. GPT-5.4 offre un cache input à 50% de réduction.

Batch API. Les API batch (traitement différé) offrent des remises d’environ 50% chez Anthropic et des réductions similaires chez les autres fournisseurs. Idéal pour les traitements de documents en masse qui n’ont pas besoin de réponse temps réel.

Modèles flash/mini. Pour les tâches qui nécessitent un long contexte mais pas la puissance maximale, les modèles compacts (Gemini 3 Flash à 0,50 $/M, Claude Haiku 4.5 à ~1 $/M input) offrent des fenêtres de 128K+ tokens à une fraction du coût des modèles frontières.

Cas d’usage par taille de contexte

Alternatives au long contexte

Un contexte plus long n’est pas toujours la meilleure solution. Plusieurs stratégies alternatives existent :

RAG (Retrieval-Augmented Generation). Au lieu de tout mettre dans le contexte, on indexe les documents dans une base vectorielle et on ne récupère que les passages pertinents. Le RAG est souvent plus fiable que le long contexte car il cible précisément l’information utile, évitant la dégradation « lost in the middle ». Il est aussi beaucoup moins coûteux pour les corpus volumineux.

Résumé et compaction. Pour les conversations longues, résumer périodiquement le contexte ancien et ne conserver que le résumé libère de la fenêtre pour le nouveau contenu. Claude utilise un mécanisme de compaction automatique dans certains cas.

Chunking et traitement séquentiel. Découper un long document en morceaux, traiter chaque morceau séparément, puis synthétiser les résultats. Moins élégant que le long contexte mais plus fiable et moins coûteux.

Le choix entre long contexte et RAG dépend du cas d’usage. Pour la compréhension globale d’un document unique (« résumez ce livre »), le long contexte est préférable. Pour la recherche d’information spécifique dans un large corpus (« trouvez la clause X dans ces 100 contrats »), le RAG est généralement plus efficace et moins cher.

Les techniques qui ont rendu le long contexte possible

L’expansion de 4K à 10M tokens n’est pas juste une question de « plus de mémoire GPU ». C’est le résultat de multiples innovations algorithmiques et architecturales, chacune contribuant à lever un goulot d’étranglement spécifique :

FlashAttention (2022-2026) : réduit la complexité mémoire de l’attention de O(n²) à O(n) et accélère le calcul de 2 à 15x. Sans FlashAttention, les fenêtres de 1M tokens seraient impraticables.

RoPE + YaRN (2021-2024) : encodage positionnel extensible qui permet de dépasser la longueur d’entraînement avec un fine-tuning minimal (0,1% des données).

GQA (2023) : réduit la taille du KV cache de 4 à 8x, permettant de stocker 4 à 8x plus de tokens dans le même budget mémoire.

Sliding Window Attention : borne le KV cache à une taille fixe W, indépendamment de la longueur de séquence. Permet des contextes théoriquement illimités au prix d’une perte d’information au-delà de la fenêtre.

KV cache offloading : décharge les parties inactives du cache vers la mémoire CPU ou le stockage distribué, étendant la capacité effective au-delà de la mémoire GPU. NVIDIA rapporte des gains de TTFT allant jusqu’à 14x pour les longues séquences quand le KV cache est lu depuis le stockage plutôt que recalculé.

Architectures MoE : les modèles Mixture-of-Experts comme Llama 4 Scout n’activent qu’une fraction de leurs paramètres par token, réduisant le coût computationnel par token et rendant les très longs contextes plus abordables.

Conseils pratiques pour exploiter le long contexte

Placez l’information critique au début et à la fin du prompt. C’est là que le modèle la récupère le plus fiablement. Évitez de noyer l’information essentielle au milieu d’un long contexte.

Testez avec NIAH avant de déployer. Injectez un fait spécifique à différentes positions de votre contexte réel et vérifiez que le modèle le retrouve. Le taux de récupération varie considérablement selon le modèle, la longueur, et la position.

Surveillez le ratio entrée/sortie. Si vous envoyez 900K tokens et n’avez besoin que d’une réponse de 200 mots, vous payez pour lire 900K tokens et générer 300 tokens. Assurez-vous que le long contexte est réellement nécessaire pour votre tâche.

Utilisez le prompt caching pour les contextes répétitifs. Si 80% de votre prompt est un system prompt + un document de référence partagé entre requêtes, le prefix caching réduit le coût de 50 à 90% sur les requêtes suivantes.

Considérez les modèles compacts pour le long contexte budgétaire. Gemini 3 Flash (0,50 $/M input, 128K+ contexte) ou Claude Haiku 4.5 (~1 $/M input) offrent des rapports coût/contexte imbattables pour les tâches qui ne nécessitent pas la puissance d’un modèle frontière.

Comparez les surcharges long-contexte. Claude Opus/Sonnet 4.6 n’applique aucun surcoût quelle que soit la longueur. GPT-5.4 double le prix au-delà de 272K tokens. Ce différentiel peut représenter des milliers d’euros d’économie pour les workloads intensifs en long contexte.