Fenêtre de contexte (Context Window)

1. Vue d'ensemble du concept et problème systémique

Les développeurs débutants perçoivent souvent la fenêtre de contexte comme l'équivalent d'un disque dur : un espace où l'on peut stocker n'importe quelle quantité de documentation pour que le modèle « la connaisse simplement ».

Pourtant, dans la réalité physique des réseaux de neurones, la fenêtre de contexte est la mémoire vidéo du GPU (VRAM), mobilisée lors de calculs matriciels intenses :

1. Complexité quadratique de l'attention : Dans le mécanisme Attention classique, les relations sont calculées entre chaque paire de tokens ($O(N^2)$). Multiplier par 10 la longueur de l'entrée exige 100 fois plus de ressources de calcul lors de la phase de préfixe (Prefill).
2. Limites matérielles de la mémoire : Lorsque la longueur du dialogue atteint plusieurs centaines de milliers de tokens, la taille du KV-cache dépasse la capacité de la VRAM (Out of Memory - OOM).
3. Limite d'extrapolation positionnelle : Le modèle ne peut pas interpréter correctement les positions des tokens au-delà de celles vues lors de son entraînement sans méthodes spécifiques d'interpolation (RoPE / YaRN).

La Fenêtre de Contexte (Context Window) définit l'horizon de la mémoire vive active du système : tout ce qui se trouve à l'intérieur participe au calcul des probabilités ; tout ce qui reste en dehors n'existe physiquement pas pour le modèle.

2. Taxonomie architecturale et modèle mental

Le traitement de la fenêtre de contexte se divise en deux phases de calcul et optimisations associées :

• 1. Phase de préfixe (Prefill Phase) : Traitement parallèle de l'ensemble de la requête utilisateur. C'est une phase limitée par la puissance de calcul (Compute-bound), optimisée par des technologies telles que FlashAttention-2/3, qui éliminent les accès superflus à la mémoire globale du GPU.
• 2. Phase de décodage (Decode Phase) : Génération séquentielle de nouveaux tokens, un par étape. Cette phase est limitée par la bande passante mémoire (Memory-bandwidth bound), où la vitesse dépend de la récupération des vecteurs depuis le KV-cache.
• 3. Architectures à long contexte :
  • RoPE (Rotary Position Embeddings) : embeddings positionnels rotatifs permettant de faire passer la fenêtre de 8K à 1M de tokens via un scaling fréquentiel.
  • Ring Attention : distribution du calcul du mécanisme d'attention sur un anneau de dizaines de serveurs GPU pour traiter des séquences de plusieurs millions de tokens.
• 4. Structure du budget de la fenêtre : Total Window = System Prompt + Long-term Memory + Ingestion Files + History + Tools Output + Max Generation Tokens.

3. Pipeline technique et mécanique interne

Cycle de vie du contexte traversant le transformer :

1. Tokenization & BPE Mapping (Tokenisation) : La chaîne brute de code ou de texte est convertie en vecteur numérique d'IDs de tokens via un dictionnaire BPE/Tiktoken.
2. Positional Encoding Injection (Injection des coordonnées) : Chaque token reçoit un vecteur de position dans la séquence (via les matrices de rotation RoPE).
3. Multi-Head Self-Attention & KV Cache Allocation (Calcul de l'attention) : Les matrices Query, Key et Value sont calculées. Les vecteurs $K$ et $V$ sont écrits dans le buffer VRAM du KV-cache pour éviter les recalculs aux étapes suivantes.
4. Context Length Enforcement (Contrôle des limites) : Si le nombre total de tokens dépasse max_context_length, le runtime renvoie soit une erreur 400 BadRequest: context_length_exceeded, soit tronque automatiquement les messages les plus anciens (Sliding Window Truncation).

4. Scénarios d'ingénierie pratiques en production

01. In-Context Learning sur l'ensemble du repository projet

Chargement de 200 000 tokens de base de code directement dans la fenêtre du modèle (Cursor / Claude Code). Le modèle visualise simultanément tous les types, imports et patterns architecturaux, générant un nouveau module avec une préservation parfaite des conventions du projet.

02. Analyse de dossiers juridiques M&A et audits

Transmission d'un dossier contractuel de 500 pages dans la fenêtre Gemini 2.5/3 Pro (1M de tokens) pour détecter les contradictions mutuelles, les conditions financières incohérentes et les engagements cachés, sans perte de contexte entre les documents.

03. Optimisation économique via Prompt Caching

Dans les assistants longue durée, le system prompt et la documentation API (par exemple, 40 000 tokens) sont mis en cache par le fournisseur (Anthropic/OpenAI). Grâce à cela, chaque requête suivante est traitée 4 fois plus vite et coûte 90 % moins cher.

5. Pièges courants, erreurs typiques et sécurité

• Troncature silencieuse du contexte (Silent Truncation) : Certains clients naïfs suppriment automatiquement le début du dialogue à l'approche de la limite. Si des règles de sécurité système importantes s'y trouvaient, le modèle devient vulnérable.
• Out of Memory (OOM) sur les serveurs auto-hébergés : Lancer Llama 3 70B sur un nœud dédié avec 80GB de VRAM fonctionne parfaitement sur des tests courts, mais échoue avec une erreur mémoire critique lorsque l'utilisateur envoie une requête de 64K tokens, provoquant l'explosion du KV-cache. Limitez toujours max_model_len dans vLLM.
• Croissance exponentielle de la facture : L'envoi non contrôlé de l'historique à chaque message conduit à ce qu'un simple chat de 20 répliques génère des centaines de milliers de tokens d'entrée facturés.