LLM locaux à contexte long 2026 : modèles 128K, 256K et 1M comparés

La longueur de contexte est le nombre maximal de tokens qu'un modèle peut contenir dans une requête : votre prompt, les documents, la conversation jusque-là et la réponse qu'il rédige, additionnés. Un token vaut environ 0.75 mot anglais : 128K tokens font donc environ 100 000 mots et 256K tokens environ 200 000 mots.

La fenêtre annoncée est le maximum que l'architecture du modèle prend en charge. La fenêtre utilisable est la longueur à laquelle les réponses restent exactes pour votre tâche, et elle est plus courte.

Les longues fenêtres comptent pour des bases de code entières, des contrats, de longues transcriptions, des chapitres de livre et des sessions d'agents où les sorties d'outils s'accumulent. La documentation d'Ollama recommande au moins 64 000 tokens pour les agents, la recherche web et les outils de code.

Trois éléments fixent la limite sur votre propre machine : la fenêtre du modèle, la mémoire dont son cache KV a besoin à cette longueur et la fiabilité avec laquelle il exploite le texte à cette longueur. Les sections suivantes les traitent tour à tour.

Plusieurs : Qwen3.5, Qwen3.8 et Gemma 4 (à partir de 12B) annoncent des fenêtres de 256K dans la bibliothèque Ollama, NVIDIA Nemotron 3 Nano 30B annonce 1M et Llama 4 Scout annonce 10M. Les modèles publiés avant 2026 s'arrêtent en majorité à 128K.

Le tableau indique la fenêtre annoncée par la fiche du modèle ou la bibliothèque Ollama. Une extension de contexte, comme YaRN, est une option documentée par l'éditeur qui demande une configuration et de la mémoire supplémentaires.

Llama 4 Scout annonce 10M tokens, mais sa fiche rapporte ses benchmarks de contexte long à une fenêtre de 128K, et le téléchargement Ollama fait 67 Go. Llama 4 Maverick annonce 1M mais pèse 245 Go au téléchargement : il exige du matériel de serveur.

Les tags Ollama peuvent différer par la taille de fenêtre : qwen3:8b et qwen3:14b annoncent 40K, tandis que qwen3:4b et qwen3:30b annoncent 256K. Lisez la valeur de contexte sur la page Ollama du modèle avant de planifier.

La mémoire d'un contexte long, ce sont les poids du modèle plus le cache KV, et le cache KV dépend de l'architecture, pas seulement de la fenêtre. Le cache KV stocke les clés et valeurs d'attention de chaque token du contexte et s'alloue en plus des poids.

Octets KV par token = 2 (clés et valeurs) × couches d'attention complète × têtes KV × dimension de tête × octets par valeur (2 pour le cache f16 par défaut). Llama 3.1 8B : 2 × 32 × 8 × 128 × 2 = 131 072 octets (128 Kio) par token, soit 16 Gio à 128K tokens, plus de trois fois son téléchargement de 4.9 Go.

Les architectures récentes réduisent ce coût. Gemma 4 utilise l'attention à fenêtre glissante dans la plupart des couches (fenêtre de 1 024 tokens pour les 12B, 26B et 31B), gpt-oss dans une couche sur deux (128 tokens), Qwen3.5 et Qwen3.8 l'attention linéaire Gated DeltaNet dans trois couches sur quatre, et Nemotron 3 Nano n'a que 6 couches d'attention sur 52. Seules les couches d'attention complète croissent avec la fenêtre.

Les valeurs ci-dessous sont calculées à partir de la configuration publiée de chaque modèle, et non mesurées. Les environnements d'exécution ajoutent des tampons de calcul et les implémentations du cache diffèrent : confirmez l'usage réel avec ollama ps.

Quantifier le cache KV le réduit : selon la documentation d'Ollama, q8_0 utilise environ la moitié de la mémoire de f16 et q4_0 environ un quart, avec une perte de précision faible à moyenne pour q4_0.

Choisissez d'abord selon la mémoire : les poids plus le cache KV au contexte voulu doivent tenir, avec 2 à 3 Go de marge pour le système d'exploitation et l'environnement d'exécution. Les choix ci-dessous sont de l'arithmétique à partir du tableau ci-dessus, pas des classements de qualité ; nous n'avons pas évalué la précision en contexte long.

La fenêtre annoncée est une borne supérieure d'architecture, pas une garantie de qualité. Liu et al. (2023) ont constaté que les modèles de langage répondent le plus précisément quand le texte pertinent se trouve au début ou à la fin de l'entrée, et moins précisément quand il est au milieu : l'effet « lost in the middle ».

RULER (Hsieh et al., 2024) a testé 17 modèles annonçant tous 32K tokens ou plus ; seule la moitié environ a gardé une performance satisfaisante à 32K. NoLiMa (Modarressi et al., 2025) a testé 13 modèles annonçant au moins 128K ; à 32K, 11 d'entre eux sont tombés sous 50 % de leur score en contexte court, et GPT-4o est passé de 99.3 % à 69.7 %.

Ces études précèdent la plupart des modèles de ce guide : voyez-y la preuve du phénomène, pas des scores pour un modèle cité ici. Pour vérifier un modèle vous-même, cachez un fait à 10 %, 50 % et 90 % d'un long prompt, interrogez-le avec d'autres mots et recommencez à 32K, 64K et 128K.

Quand la précision compte, placez les instructions et faits critiques au début ou à la fin du prompt, ne récupérez que les passages pertinents (voir la section RAG ci-dessous) ou traitez les longs documents par sections qui se chevauchent.

Ollama choisit son contexte par défaut selon votre VRAM : 4K tokens sous 24 Gio, 32K de 24 à 48 Gio et 256K à partir de 48 Gio. L'entrée au-delà du contexte actif est tronquée : le modèle ne voit alors jamais le début d'un long document.

Vous pouvez régler le contexte avec le curseur de l'application Ollama, la variable d'environnement OLLAMA_CONTEXT_LENGTH, /set parameter num_ctx dans ollama run, un Modelfile ou l'option num_ctx de l'API. Confirmez le résultat avec ollama ps.

Dans LM Studio, ouvrez My Models, cliquez sur l'icône d'engrenage d'un modèle et réglez la taille de contexte et Flash Attention. Dans llama.cpp, -c fixe la taille de contexte (0 la charge depuis le modèle), -fa contrôle Flash Attention, et --cache-type-k et --cache-type-v quantifient le cache KV.

Ollama ne quantifie le cache KV que si Flash Attention est activé, et le réglage est global pour tous les modèles. OLLAMA_KV_CACHE_TYPE=q8_0 utilise environ la moitié de la mémoire de f16 et q4_0 environ un quart.

Ils le peuvent : Petrov et al. (2023) ont constaté que le même texte peut exiger jusqu'à 15 fois plus de tokens dans une langue que dans une autre, selon le tokenizer. Que le texte japonais, chinois, coréen ou arabe soit concerné dépend du tokenizer du modèle.

Ne convertissez pas les pages en tokens avec la règle anglaise de 0.75 mot par token. Comptez les tokens avec le modèle que vous comptez utiliser : ollama run <model> --verbose affiche le nombre de tokens du prompt après une réponse.

Budgétez la fenêtre par langue et par famille de modèles, car les tokenizers diffèrent d'une famille de modèles à l'autre.

Utilisez le RAG quand la réponse se trouve dans quelques passages d'une grande collection, et le contexte long quand le modèle doit raisonner sur un document cohérent.

Le RAG (retrieval-augmented generation) récupère les segments les plus pertinents, souvent quelques milliers de tokens au total, et garde le prompt court. Le contexte long préserve les renvois, comme les clauses d'un contrat ou les chaînes d'appels d'une base de code, que le découpage peut séparer.

Beaucoup de configurations combinent les deux : récupérer des sections entières plutôt que des fragments et les placer dans une fenêtre de 32K à 128K. Voir Meilleurs outils RAG locaux pour les options locales et Le RAG expliqué pour la méthode.