Optimiser la taille du contexte des LLM : entre dilution cognitive et contraintes matérielles

Le dilemme de la taille du contexte

L’intégration opérationnelle des grands modèles de langage (LLM) est régie par un compromis fondamental entre la capacité d’assimilation des données et l’efficacité de calcul. Les architectures contemporaines proposent des fenêtres de contexte de plus en plus vastes (de 128 000 jetons à plus d’un million pour certains modèles frontières), mais la simple expansion quantitative de ces fenêtres ne garantit aucune amélioration proportionnelle des performances applicatives.

Deux écueils opposés guettent l’ingénieur qui conçoit un système fondé sur un LLM :

• L’insuffisance de contexte, qui prive le modèle des points d’ancrage factuels indispensables à la précision de ses réponses et le renvoie à ses connaissances paramétriques, sujettes à l’hallucination.
• La dilution du contexte, une pathologie où l’excès d’informations redondantes ou parasites sature les mécanismes attentionnels du transformeur et dégrade activement la qualité du raisonnement, y compris lorsque l’information recherchée est bel et bien présente dans le prompt.

Ce compromis prend une dimension critique dans deux contextes d’exploitation très différents. Pour les modèles exécutés localement sur du matériel aux ressources limitées, la gestion de l’empreinte mémoire du cache Key-Value (KV) constitue un goulot d’étranglement physique : la VRAM d’un GPU est une ressource finie, pas un curseur qu’on repousse en changeant un paramètre. Pour les modèles frontières facturés au jeton, l’ingestion de données superflues engendre des coûts et une latence directement proportionnels au bruit injecté. Dans les deux cas, l’optimisation de la taille du contexte relève d’une ingénierie de précision, pas d’un réglage empirique.

La zone critique de l’insuffisance de contexte

Lorsqu’un modèle est sollicité avec un volume d’informations trop faible pour la tâche demandée, il perd sa capacité à fonder ses réponses sur des données vérifiables. En l’absence de données de référence explicites dans le prompt, le système s’en remet exclusivement aux connaissances mémorisées dans ses paramètres lors du pré-entraînement, avec trois conséquences directes pour un usage en entreprise :

La dépendance à la loi de puissance de l’entraînement. La capacité d’un modèle à restituer un fait précis dépend directement de la fréquence à laquelle les documents associés à ce fait apparaissaient dans son corpus d’apprentissage. Les informations de la « longue traîne » (données de niche, faits hautement spécialisés, documentation technique confidentielle d’une PME) y sont mal représentées et donc sujettes à une défaillance de restitution pure et simple.

La dérive d’hallucination factuelle. Sans contexte d’ancrage, le modèle comble les lacunes en générant des suites de jetons statistiquement probables mais factuellement erronées. C’est précisément la raison d’être de la génération augmentée par récupération (RAG) : réduire cette dépendance en injectant des documents pertinents dans le prompt plutôt que de compter sur la mémorisation brute.

L’échec des pivots sémantiques. Si la fenêtre de contexte est trop restreinte pour contenir l’ensemble des éléments de logique nécessaires à la résolution d’un problème complexe (les dépendances d’un graphe symbolique, l’historique complet d’une transaction), le modèle échoue à établir les connexions requises, ce qui produit des ruptures de cohérence ou des réponses incomplètes.

Niveau de contexte	Comportement cognitif	Risques opérationnels	Utilité en production
Indigent (< 1 000 jetons)	Dépendance exclusive aux poids paramétriques	Hallucinations élevées, obsolescence des faits, incapacité à traiter des données privées	Faible : limité aux requêtes génériques
Optimal (haute densité)	Alignement précis sur les sources réinjectées, activation des capacités de raisonnement	Risque minime d’erreur factuelle, latence maîtrisée	Maximale : RAG de précision, agents décisionnels spécialisés
Surchargé (> 32 000 jetons de bruit)	Dilution attentionnelle, « Lost in the Middle », glissement du raisonnement	Explosion de la latence, dégradation de la précision, coûts prohibitifs	Faible : gaspillage de ressources matérielles

La dilution du contexte et la pathologie du « Lost in the Middle »

À l’autre extrémité du spectre, l’injection massive et non triée de données dans la fenêtre d’entrée engendre une pathologie cognitive désignée sous le nom de dilution du contexte. Les travaux de Nelson F. Liu et de ses coauteurs (Stanford, Liu et al., TACL 2024 ; initialement publiés sur arXiv en juillet 2023) ont mis en évidence un biais positionnel en forme de « U » : les modèles de langage sont très performants pour exploiter les données situées au tout début ou à la toute fin de la fenêtre de contexte, mais leurs performances s’effondrent lorsque l’information critique est positionnée au milieu d’un prompt volumineux, y compris pour des modèles explicitement conçus pour le long contexte.

Plusieurs facteurs physiques et structurels expliquent cette dégradation systématique.

La normalisation softmax à somme nulle. Le mécanisme d’auto-attention calcule des scores de similarité convertis en probabilités via la fonction softmax, dont la propriété centrale est que la somme de l’attention allouée à l’ensemble de la séquence est strictement égale à 1. Chaque jeton non pertinent injecté dans le prompt « vole » donc une fraction de l’attention qui aurait dû se concentrer sur les informations clés, dégradant le rapport signal-sur-bruit des représentations internes.

Les puits d’attention (attention sinks). Xiao et al. (« Efficient Streaming Language Models with Attention Sinks », arXiv:2309.17453, ICLR 2024) montrent que les modèles développent, lors de l’entraînement, une tendance à sur-allouer des poids d’attention aux tout premiers jetons de la séquence, quelle que soit leur pertinence sémantique. Ces jetons initiaux agissent comme des décharges pour l’attention superflue, ce qui exacerbe artificiellement le biais de primauté au détriment des données centrales.

La distraction sémantique. L’introduction d’informations hors sujet mais thématiquement proches de la requête principale (des entités partageant des rôles similaires, des plages de valeurs numériques comparables) perturbe la sélection des chemins de raisonnement. Le benchmark GSM-IC (Grade-School Math with Irrelevant Context, construit sur GSM8K par Shi et al., « Large Language Models Can Be Easily Distracted by Irrelevant Context », ICML 2023, arXiv:2302.00093) montre que l’exactitude arithmétique et la sélection des trajectoires de résolution chutent sévèrement face à ce type d’interférence.

La dégradation brute liée à la longueur. Même en l’absence de toute distraction sémantique (et même quand les jetons non pertinents sont masqués ou remplacés par des espaces vides), la simple augmentation de la longueur de l’entrée impose une taxe cognitive au modèle. Une étude récente (Du et al., « Context Length Alone Hurts LLM Performance Despite Perfect Retrieval », arXiv:2510.05381, Findings of EMNLP 2025 ; testée sur Llama 3.1 8B Instruct, Mistral 7B v0.3 Instruct, GPT-4o, Claude 3.7 Sonnet et Gemini 2.0 sur GSM8K, MMLU, HumanEval et une tâche synthétique) mesure une dégradation de performance de 13,9 % à 85 % à mesure que la taille du prompt s’accroît, à récupération pourtant parfaite.

Le glissement de raisonnement (reasoning shift). Face à des prompts volumineux contenant de longs historiques ou des données d’arrière-plan denses, les modèles entraînés pour le raisonnement par test-time scaling modifient leur comportement de manière parfois invisible. Un préprint de 2026 non encore relu par les pairs (Rodionov, Garipov et Yakushev, « Reasoning Shift: How Context Silently Shortens LLM Reasoning », arXiv:2604.01161) observe une réduction pouvant atteindre 65 % de la longueur des traces de raisonnement interne (thinking traces) lorsque le modèle est confronté à un contexte alourdi par du texte non pertinent, des conversations multi-tours ou des sous-tâches imbriquées, sans que cela dégrade nécessairement la précision sur des tâches faciles. Cette compression s’accompagne d’un recul mesurable des comportements d’auto-vérification, ce qui la rend plus préjudiciable sur des problèmes logiques ou mathématiques complexes. À traiter comme un signal de recherche préliminaire et non comme un résultat établi.

L’impact matériel sur les LLM locaux : le mur de la VRAM et la physique du cache KV

Pour les professionnels exploitant des LLM en local, la taille de la fenêtre de contexte n’est pas qu’un paramètre d’optimisation logique : c’est une barrière matérielle absolue, définie par la mémoire vidéo (VRAM) disponible sur la carte graphique. Lors de l’inférence, l’empreinte mémoire d’un modèle se compose de deux éléments : une charge statique (les poids du modèle) et une charge dynamique hautement volatile, le cache Key-Value (KV).

Pour chaque jeton traité, l’architecture transformeur calcule et mémorise des vecteurs de Clé (Key) et de Valeur (Value) pour chaque couche d’attention. Ce cache évite de recalculer l’intégralité des relations d’attention de manière quadratique (O(n²)) à chaque nouveau jeton généré, ramenant la phase de décodage à une complexité linéaire (O(n)). Mais sa taille augmente de manière strictement linéaire avec la longueur de la séquence et la taille de lot (batch).

L’empreinte mémoire du cache KV se calcule précisément via la formule suivante :

M_KV = 2 × L × H_kv × D_head × N_seq × B × P_bytes

où L est le nombre de couches d’attention du modèle, H_kv le nombre de têtes d’attention allouées aux clés et valeurs (fortement réduit dans les architectures modernes utilisant l’attention par requêtes groupées, Grouped-Query Attention ou GQA, par rapport à l’attention multi-têtes classique), D_head la dimension de chaque tête, N_seq la longueur cumulée de la séquence, B la taille de lot, et P_bytes le nombre d’octets par élément selon la précision (2 octets pour du FP16/BF16, 1 octet pour de l’INT8, 0,5 octet pour de l’INT4). Le multiplicateur 2 correspond au stockage distinct des tenseurs Clé et Valeur.

À titre d’illustration, Llama 3.1 8B Instruct expose une configuration GQA de 32 couches, 8 têtes KV et une dimension de tête de 128 [6]. Pour une unique requête (batch = 1) sur un contexte de 32 768 jetons en BF16 natif, le calcul donne :

M_KV = 2 × 32 × 8 × 128 × 32 768 × 1 × 2 octets = 4 294 967 296 octets = 4 Gio, exactement.

Ce calcul illustre pourquoi l’espace résiduel allouable au cache KV s’amenuise drastiquement dès qu’on exécute un modèle plus imposant sur un GPU grand public à 12 ou 16 Go de VRAM, ou qu’on allonge fortement le contexte. Dès que la somme du poids du modèle et du cache KV excède la capacité physique de la VRAM, l’exécution bascule vers la mémoire système du CPU (CPU spill), un débordement qui franchit la frontière entre la mémoire HBM ultra-rapide du GPU et les lignes d’accès DRAM classiques, d’une bande passante inférieure d’un ordre de grandeur. La vitesse de décodage s’effondre alors quasi instantanément.

Modèle de référence	Poids (quantification)	Contexte	Cache KV (calculé)	Total estimé	Statut sur GPU grand public (RTX 4090, 24 Go)
Llama 3.1 8B Instruct [6]	~16 Go (BF16 natif)	4 096 jetons	~0,5 Go	~16,5 Go	Fonctionnement optimal, marge confortable
Llama 3.1 8B Instruct [6]	~16 Go (BF16 natif)	32 768 jetons	4 Go (calcul exact ci-dessus)	~20 Go	Tendu mais stable
Phi-4, 14B [7]	~8-9 Go (INT4)	16 384 jetons (contexte natif maximal)	~2,5 Go (BF16)	~11,5 Go	Confortable
Qwen 3 32B [8]	~19,8 Go (GGUF Q4_K_M, poids seuls)	40 960 jetons (contexte natif)	10 Gio ≈ 10,7 Go (calcul : 2×64×8×128×2 o = 256 Kio/jeton)	~30,5 Go	Déjà hors budget sur un GPU 24 Go, poids seuls proches de la limite ; nécessite une quantification plus agressive (Q3/Q2), au prix de la qualité
Llama 3.3 70B [9]	~40-46 Go (INT4 selon la méthode)	128 000 jetons	≈ 39 Gio ≈ 42 Go (BF16)	~75-90 Go	Impossible sans matériel d’entreprise (multi-GPU ou VRAM de classe centre de données)

Pour contourner ce goulot d’étranglement, la quantification du cache KV s’impose comme une technique indispensable : convertir les Clés et Valeurs au format INT8 ou INT4 réduit mécaniquement l’occupation mémoire de 50 % à 75 % (une conséquence directe du terme P_bytes dans la formule ci-dessus), pour une dégradation de perplexité généralement décrite comme mineure sur la majorité des tâches. L’ordre de grandeur le plus souvent cité est de 1 à 3 %, sans qu’une source unique ne fasse référence sur ce chiffre précis pour l’ensemble des architectures.

Pour optimiser ces économies sans trop dégrader la fidélité de génération, une piste explorée par la recherche consiste à quantifier plus agressivement les couches profondes du réseau que les couches initiales, une adaptation par profondeur documentée notamment par PyramidKV [11], qui montre qu’un budget de cache réduit dans les couches supérieures affecte moins la qualité que dans les couches précoces. C’est une approche distincte de la quantification à 2 bits par canal/jeton proposée par KIVI [10], qui cible la précision plutôt que la profondeur. Les deux techniques sont complémentaires plutôt que concurrentes.

L’impact financier sur les modèles frontières : prompt caching et économies d’échelle

Pour les équipes exploitant des API de modèles frontières, chaque jeton envoyé dans la fenêtre d’entrée représente une charge financière directe. Le modèle de facturation classique impute un coût pour le traitement du prompt (la phase de prefill) et un coût supérieur pour la génération des jetons de sortie (decode). Dans les systèmes d’agents autonomes, de RAG d’entreprise ou d’assistants de codage, l’ingestion répétée de longs contextes identiques (règles de typage, base de code de référence, instructions système) engendre un gaspillage budgétaire massif si rien n’est fait pour l’éviter.

Le prompt caching consiste à conserver, côté serveur, le cache KV correspondant au pré-remplissage d’un préfixe de prompt stable. Lorsque des requêtes successives partagent ce même préfixe, l’API facture le traitement de ces jetons à un tarif fortement réduit. Les conditions d’accès et de tarification varient sensiblement d’un fournisseur à l’autre.

Anthropic impose l’insertion de marqueurs explicites cache_control dans la structure de la requête pour indiquer quelles sections du contexte doivent être mises en cache. C’est une approche manuelle qui offre un contrôle fin, avec un seuil d’éligibilité qui varie selon le modèle (2 048 jetons minimum pour Claude Sonnet 4.6, 4 096 jetons pour la famille Opus). Une remise de 90 % s’applique sur les jetons lus en cache, avec une légère pénalité d’écriture : 25 % de surcoût sur le préfixe mis en cache pour la première fois (durée de vie de 5 minutes), amortie dès la deuxième requête identique.

OpenAI détecte automatiquement les correspondances de préfixes sur les requêtes entrantes, sans marqueur ni surcoût de mise en cache : si les 1 024 premiers jetons du prompt correspondent à une séquence déjà soumise récemment, le système applique une remise de 90 % sans adaptation du code applicatif. Ce mécanisme, confirmé sur GPT-5.5 (avril 2026), a toutefois évolué : depuis le 9 juillet 2026, GPT-5.6 (qui a succédé à GPT-5.5 quelques jours seulement avant la publication de cet article) introduit une surcharge d’écriture de cache de 1,25×, mettant fin à la gratuité totale de la mise en cache chez OpenAI. Un signal à surveiller : les conditions tarifaires des fournisseurs évoluent presque aussi vite que les modèles eux-mêmes.

Google dispose en réalité de deux mécanismes distincts, une nuance souvent négligée. Une mise en cache implicite et automatique s’applique par défaut dès 4 096 jetons de préfixe partagé (aucune configuration requise), tandis qu’une mise en cache explicite, à activer manuellement via l’API, garantit une durée de rétention fixe (TTL) pour des contextes RAG volumineux et stables, avec un seuil d’éligibilité nettement plus élevé, à partir de 32 768 jetons. Sur Gemini 3.1 Pro (encore en Preview mi-2026), la remise atteint 90 % dans les deux cas pour les prompts jusqu’à 200 000 jetons.

DeepSeek offre le mécanisme le plus agressif : la détection de préfixe est automatique et gratuite à l’écriture, avec un seuil d’éligibilité minimal de seulement 64 jetons, bien plus permissif que les seuils à quatre chiffres des autres fournisseurs. Sur DeepSeek-V4-Flash, une lecture de cache coûte 0,0028 $ pour un million de jetons contre 0,14 $ en écriture standard, soit une remise de 98 %.

Fournisseur	Modèle de référence	Prix entrée standard (/1M jetons)	Prix entrée en cache (/1M jetons)	Remise	Activation	Seuil minimum
Anthropic	Claude Sonnet 4.6	3,00 $	0,30 $	-90 %	Manuelle (cache_control)	2 048 jetons
OpenAI	GPT-5.5 (avril 2026)	5,00 $	0,50 $	-90 %	Automatique (préfixe)	1 024 jetons
Google	Gemini 3.1 Pro (Preview)	2,00 $ (≤ 200K)	0,20 $	-90 %	Automatique (implicite) ou manuelle (explicite, TTL garanti)	4 096 jetons (implicite) / 32 768 jetons (explicite)
DeepSeek	DeepSeek-V4-Flash	0,14 $	0,0028 $	-98 %	Automatique (préfixe)	64 jetons

Pour exploiter efficacement ces grilles tarifaires, la structure sémantique des requêtes doit être rigoureusement ordonnée : instructions globales, données d’arrière-plan stables et schémas de sortie en tête de prompt ; requêtes dynamiques (horodatage, identifiant utilisateur, question de l’utilisateur) en fin de message. Toute modification du préfixe, même minime, invalide le cache en aval et provoque un échec de cache coûteux. En combinant un ordonnancement soigné des requêtes avec des pipelines de traitement par lots (Batch APIs, qui octroient une remise forfaitaire supplémentaire chez plusieurs fournisseurs), les équipes peuvent réduire significativement leur facture d’inférence.

Vers une architecture du contexte optimal : reranking, compression et multi-agents

Pour résoudre la tension entre besoin de données factuelles et risque de dilution attentionnelle ou de surcoût matériel, les architectures modernes appliquent des traitements successifs pour raffiner le flux d’informations entrant, plutôt que de saturer la fenêtre de contexte par une approche brute.

Le ré-ordonnancement de précision (reranking). Dans un système de RAG standard, les modèles d’intégration vectorielle (embeddings) effectuent une première sélection rapide de documents pertinents, mais ces modèles bi-encodeurs n’analysent pas les interactions fines entre la question et chaque passage. Un modèle de ré-ordonnancement (reranker) à encodeur croisé évalue précisément la pertinence relative de chaque extrait par rapport à la question posée, ne conserve que les passages au score le plus élevé, puis positionne délibérément les extraits les plus critiques en tête et en fin de prompt, laissant le centre de la fenêtre vide de tout contenu d’importance moyenne, pour contourner directement le phénomène Lost in the Middle documenté en Figure 1.

La compression algorithmique de prompts. Trois outils de la famille LLMLingua (Microsoft Research), souvent confondus, répondent à des besoins distincts :

• LLMLingua [16] (la version originale) s’appuie sur un petit modèle de langage local pour calculer la perplexité de chaque segment du prompt : les mots hautement prévisibles (faible perplexité) sont éliminés, tandis que les pivots syntaxiques et sémantiques porteurs de sens (haute perplexité) sont préservés. Les benchmarks de Microsoft Research annoncent une compression jusqu’à 20× avec une perte de performance limitée.
• LLMLingua-2 [17] abandonne l’approche par perplexité au profit d’un classifieur binaire (garder/supprimer) de type BERT, entraîné par distillation de données générées par GPT-4. Explicitement conçu comme agnostique à la tâche (il compresse sans jamais voir la question finale), il vise une compression plus modeste (de l’ordre de 2× à 5×) mais plus rapide et plus robuste que l’approche par perplexité.
• LongLLMLingua [18] est la variante conçue spécifiquement pour les scénarios de long contexte et de RAG : à la différence de LLMLingua-2, elle est sensible à la question (question-aware). Elle réordonne et filtre grossièrement les segments de documents en fonction de leur pertinence par rapport à la question posée, avant une compression fine, et intègre une stratégie explicite de réordonnancement des documents pour réduire le biais positionnel. C’est, avec le reranking, l’une des rares techniques conçues pour s’attaquer frontalement au phénomène Lost in the Middle.

Les topologies multi-agents. Pour contourner la dégradation des capacités d’auto-vérification et la compression des traces de raisonnement induites par les contextes volumineux (voir la section précédente), une tâche complexe peut être segmentée en un réseau d’agents spécialisés. Au lieu d’adresser une requête globale à un modèle unique doté d’une fenêtre de plusieurs centaines de milliers de jetons, le problème est découpé en sous-objectifs indépendants confiés à des instances autonomes, chacune recevant un contexte ultra-ciblé et rigoureusement filtré, idéalement sous la barre des 25 000 jetons, soit la zone « optimale » identifiée en Figure 2. L’orchestration de ces agents et la synthèse finale de leurs travaux visent un traitement à la fois complet et robuste sur le plan de l’exactitude logique.

Approche d’optimisation	Objectif	Compromis / coût d’implémentation
Ré-ordonnancement (reranking)	Éliminer le bruit, positionner l’essentiel aux extrémités du prompt	Latence additionnelle liée au passage dans l’encodeur croisé
Compression de prompt (LLMLingua) [16][17]	Éliminer la redondance linguistique par analyse de perplexité ou classification token par token	Nécessite l’exécution d’un petit modèle de compression en amont ; jusqu’à 20× pour LLMLingua, 2-5× pour LLMLingua-2
Compression sensible à la question (LongLLMLingua) [18]	Réordonner et filtrer les segments selon leur pertinence pour la question posée	Ajoute une étape de scoring par requête ; cible spécifiquement le biais positionnel
Architecture multi-agents	Répartir un contexte massif sur des agents spécialisés à mémoire restreinte (idéalement < 25 000 jetons)	Complexité accrue de l’orchestration et frais de routage des messages

Conclusions et recommandations stratégiques

La gestion de la taille du contexte s’est imposée comme un pilier de l’ingénierie des systèmes d’intelligence artificielle. Saturer de manière désordonnée la fenêtre d’entrée d’un transformeur nuit à ses capacités cognitives réelles : l’attention est une ressource à somme nulle, sensible aux biais positionnels et vulnérable aux interférences sémantiques. À l’opposé, une réduction excessive du contexte engendre des dérives factuelles et des hallucinations.

Concilier exactitude logique, réactivité des systèmes locaux et rentabilité des architectures distribuées suppose une gestion dynamique et qualitative du contexte : ré-ordonnancement pour placer l’information critique aux extrémités de la séquence, compression pour éliminer les redondances linguistiques inutiles, et architectures multi-agents pour fragmenter les tâches volumineuses en sous-problèmes à faible empreinte mémoire. En structurant rigoureusement les données d’entrée pour maximiser les technologies de mise en cache des prompts, les équipes peuvent bâtir des solutions robustes et à forte valeur ajoutée, sur le plan matériel comme sur le plan financier.

C’est très exactement la logique de la Méthode MATIA™ : la taille du contexte n’est pas un curseur qu’on pousse au maximum par réflexe, mais une variable d’ingénierie qu’on dimensionne à la tâche.

Pour aller plus loin

Le Diagnostic IA Express (60 minutes en visioconférence, sans engagement) inclut une revue de votre architecture de contexte et de coûts d’inférence : fenêtre de contexte, cache KV, prompt caching et choix de modèle.

Sur le volet FinOps (budgets tokens, passerelles LLM, routage dynamique), voir l’article Budgets tokens et API IA : le guide FinOps des PME en 2026.

Le livre blanc « Maturité IA des PME françaises 2025-2026 » est disponible sur croissance-transitions.fr.

Sources

[1] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang, Lost in the Middle: How Language Models Use Long Contexts (TACL 2024, vol. 12, p. 157-173 ; arXiv:2307.03172, juillet 2023), biais positionnel en U sur la récupération d’information en long contexte. https://arxiv.org/abs/2307.03172

[2] Guangxuan Xiao, Yuandong Tian, Beidi Chen, Song Han, Mike Lewis, Efficient Streaming Language Models with Attention Sinks (ICLR 2024 ; arXiv:2309.17453, sept. 2023), sur-allocation d’attention aux premiers jetons de la séquence. https://arxiv.org/abs/2309.17453

[3] Freda Shi, Xinyun Chen, Kanishka Misra, Nathan Scales, David Dohan, Ed H. Chi, Nathanael Schärli, Denny Zhou, Large Language Models Can Be Easily Distracted by Irrelevant Context (ICML 2023 ; arXiv:2302.00093, fév. 2023), benchmark GSM-IC, distraction sémantique. https://arxiv.org/abs/2302.00093

[4] Yufeng Du, Minyang Tian, Srikanth Ronanki, Subendhu Rongali, Sravan Bodapati, Aram Galstyan, Azton Wells, Roy Schwartz, Eliu A. Huerta, Hao Peng, Context Length Alone Hurts LLM Performance Despite Perfect Retrieval (Findings of EMNLP 2025 ; arXiv:2510.05381, oct. 2025), dégradation de 13,9 % à 85 % à récupération pourtant parfaite, testée sur 5 modèles. https://arxiv.org/abs/2510.05381

[5] Gleb Rodionov, Roman Garipov, George Yakushev, Reasoning Shift: How Context Silently Shortens LLM Reasoning (préprint non relu par les pairs ; arXiv:2604.01161, avril-juin 2026), réduction pouvant atteindre 65 % des traces de raisonnement interne sous contexte alourdi. Résultat préliminaire à traiter avec prudence. https://arxiv.org/abs/2604.01161

[6] Meta, Llama 3.1 8B Instruct, configuration du modèle (32 couches, 8 têtes KV en GQA, dimension de tête 128) ; calcul du cache KV dérivé de cette configuration.

[7] Microsoft, Phi-4 Technical Report (arXiv:2412.08905, déc. 2024), 14B paramètres, 40 couches, 8 têtes KV, contexte natif de 16 384 jetons.

[8] Alibaba, Qwen3-32B, carte du modèle (avril 2025, licence Apache 2.0 ; 64 couches, 8 têtes KV, dimension de tête 128, contexte natif de 40 960 jetons).

[9] Meta, Llama 3.3 70B, configuration du modèle (déc. 2024 ; 80 couches, 8 têtes KV, dimension de tête 128, contexte de 128 000 jetons).

[10] Zirui Liu et al., KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache (arXiv:2402.02750, fév. 2024), quantification à 2 bits par canal (clés) / par jeton (valeurs).

[11] Zefan Zhang et al., PyramidKV: Dynamic KV Cache Compression based on Pyramidal Information Funneling (arXiv:2406.02069, 2024), compression du cache adaptée à la profondeur des couches.

[12] Documentation Anthropic, Prompt Caching, seuils par modèle, remise de 90 % en lecture, surcharge d’écriture de 25 % (TTL 5 min) ou 100 % (TTL 1h).

[13] Documentation OpenAI, Prompt Caching + annonce de GPT-5.6 (9 juillet 2026), détection automatique de préfixe, introduction d’une surcharge d’écriture de 1,25× sur GPT-5.6.

[14] Google DeepMind, Gemini 3.1 Pro, fiche modèle (19 février 2026, statut Preview) ; documentation de la mise en cache implicite et explicite.

[15] Documentation DeepSeek, tarification et mise en cache de contexte, DeepSeek-V4-Flash (avril 2026), seuil minimal de 64 jetons.

[16] Huiqiang Jiang, Qianhui Wu, Chin-Yew Lin, Yuqing Yang, Lili Qiu, LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models (EMNLP 2023 ; arXiv:2310.05736), compression par perplexité, jusqu’à 20×. https://arxiv.org/abs/2310.05736

[17] Zhuoshi Pan, Qianhui Wu, Huiqiang Jiang et al., LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression (ACL 2024 Findings ; arXiv:2403.12968), classifieur BERT distillé de GPT-4, agnostique à la tâche. https://arxiv.org/abs/2403.12968

[18] Huiqiang Jiang, Qianhui Wu, Xufang Luo, Dongsheng Li, Chin-Yew Lin, Yuqing Yang, Lili Qiu, LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression (arXiv:2310.06839, 2024), compression sensible à la question et réordonnancement des documents. https://arxiv.org/abs/2310.06839

Article rédigé par Paul-Antoine TUAL, AI Transformation Leader, créateur de la Méthode MATIA™.