Points clés
- Llama 4 Scout (MoE) supporte jusqu'à 10M tokens. DeepSeek V4-Flash et Qwen 3.6 supportent 1M et 256K tokens respectivement (extensible à 1M via YaRN). Mai 2026 marque la première génération de modèles open source capables de millions de tokens.
- Contexte pratique par taille de modèle : les modèles 7B-8B maintiennent une qualité fiable à 16K-32K tokens. Les modèles 70B+ et MoE étendent cela à 256K-1M tokens.
- La RAM évolue avec la longueur du contexte ET la taille du modèle. Qwen 3.6 27B en Q4_K_M nécessite ~22 Go à 128K, ~65+ Go à 1M tokens.
- Le problème "Lost in the Middle" persiste : les LLMs manquent des détails des sections centrales du contexte. Solutions : garder les informations critiques au début du prompt, utiliser le RAG pour la recherche, ou traiter en blocs chevauchants.
- Le long contexte excelle pour l'analyse holistique de documents complets (bases de code, contrats, livres). Le RAG excelle pour les tâches de recherche sur de nombreux documents.
- Ollama utilise 2048 tokens par défaut -- pas 128K ni 1M. Définir num_ctx explicitement dans un Modelfile pour accéder au contexte complet.
Qu'est-ce que la longueur de contexte et pourquoi est-ce important pour les LLMs locaux ?
La longueur de contexte est le nombre maximum de tokens qu'un modèle peut traiter dans un seul appel d'inférence -- la taille combinée de l'entrée (document, historique de conversation, prompt système) et de la sortie (réponse du modèle). Un token ≈ 0,75 mots en français ; 128K tokens ≈ 96 000 mots.
Pour les LLMs locaux, un long contexte permet : résumer des livres entiers ou de longs rapports, analyser des bases de code complètes en un seul prompt, traiter des heures de transcriptions, et maintenir de longues conversations sans perdre le contexte antérieur.
La distinction clé est entre la longueur de contexte annoncée (ce que l'architecture supporte) et la longueur de contexte pratique (où la qualité reste fiable). Un modèle peut techniquement supporter 128K tokens mais montrer une qualité dégradée au-delà de la marque des 100K tokens.
Quels LLMs locaux supportent 128K tokens de contexte en 2026 ?
| Modèle | Fenêtre de contexte | Limite pratique | Commande Ollama |
|---|---|---|---|
| Llama 3.1 8B | 128K | ~32K fiable | ollama run llama3.2 |
| Llama 3.2 3B | 128K | ~16K fiable | ollama run llama3.2:3b |
| Llama 3.3 70B | 128K | ~64K fiable | ollama run llama3.3:70b |
| Qwen2.5 7B | 128K | ~32K fiable | ollama run qwen2.5:7b |
| Qwen2.5 72B | 128K | ~64K fiable | ollama run qwen2.5:72b |
| Mistral Small 3.1 24B | 128K | ~32K fiable | ollama run mistral-small3.1 |
| Gemma 2 2B | 8K | ~6K fiable | ollama run gemma2:2b |
| Mistral 7B v0.3 | 32K | ~16K fiable | ollama run llama3.2 |
Combien de RAM le traitement de long contexte nécessite-t-il ?
L'utilisation RAM évolue avec la taille du modèle et la longueur du contexte. Le cache KV stocke les états d'attention pour tous les tokens traités -- il croît linéairement avec la longueur du contexte.
Un modèle 7B en Q4_K_M avec contexte 4K utilise ~6 Go de RAM. Le même modèle avec contexte 32K utilise ~8-9 Go. Avec contexte 128K : ~12-16 Go.
| Modèle | Contexte 4K | Contexte 32K | Contexte 128K |
|---|---|---|---|
| Llama 3.1 8B Q4_K_M | ~6 Go | ~9 Go | ~14 Go |
| Qwen2.5 14B Q4_K_M | ~9 Go | ~12 Go | ~18 Go |
| Mistral Small 3.1 24B Q4_K_M | ~14 Go | ~17 Go | ~24 Go |
| Llama 3.3 70B Q4_K_M | ~40 Go | ~45 Go | ~55 Go |
Pourquoi le contexte pratique est-il plus court que le maximum annoncé ?
Les LLMs entraînés avec des encodages RoPE (Llama, Qwen, Mistral) peuvent techniquement traiter des tokens jusqu'à leur longueur maximale, mais la qualité se dégrade selon l'effet "perdu au milieu".
Les modèles utilisent le mieux les informations au début et à la fin de la fenêtre de contexte. Les informations au milieu d'un très long contexte sont récupérées moins fiablement. En pratique, un modèle 128K peut répondre fiablement aux questions sur le contenu dans les premiers 32K et derniers 16K tokens, mais rater les détails de la plage 40K-80K.
Limites fiables pratiques par taille : modèles 3B ≈ 8K-16K ; modèles 7B-8B ≈ 16K-32K ; modèles 70B ≈ 64K fiable.
Les longues fenêtres permettent plus d'entrée, mais la structure du prompt détermine l'utilisation effective du contexte. Voir le guide prompt engineering pour les stratégies RAG et de gestion du contexte.
Comment définir la longueur de contexte dans Ollama ?
Ollama utilise par défaut 2048 tokens de contexte sauf configuration contraire. Pour utiliser la fenêtre de contexte complète d'un modèle :
Voir fenêtres de contexte expliquées : pourquoi l'IA oublie pour les stratégies de gestion du contexte.
# Set context length at runtime
ollama run llama3.2 --ctx 32768
# Or create a custom model with a Modelfile
cat << EOF > Modelfile
FROM llama3.1:8b
PARAMETER num_ctx 32768
EOF
ollama create llama3.1-32k -f Modelfile
ollama run llama3.1-32k
LLMs locaux à long contexte : contexte régional
UE / RGPD + Loi IA : La loi IA de l'UE (en vigueur depuis février 2025) classe les systèmes d'IA traitant des données personnelles à grande échelle comme potentiellement à haut risque. L'inférence locale de long contexte pour l'analyse juridique, la synthèse de dossiers médicaux ou le traitement RH relève de ce niveau de risque. L'exécution locale élimine le risque du processeur tiers au titre de l'article 28 du RGPD.
Pour la conformité BSI/ANSSI : la configuration recommandée est un modèle 7B en Q4_K_M avec contexte 32K (~9-10 Go RAM). Llama 3.1 8B et Mistral Small 3.1 sont les choix recommandés pour la conformité UE.
Pour les directives CNIL : l'inférence locale via Ollama sans appels API externes satisfait à l'exigence que les données personnelles ne soient pas traitées par des prestataires tiers sans base légale valide.
Japon (METI) : Les documents japonais nécessitent 1,5-2× plus de tokens que les équivalents anglais. Le tokeniseur japonais natif de Qwen2.5 traite le texte japonais 30-40% plus efficacement que Llama.
Chine : En vertu de la Loi sur la sécurité des données (数据安全法), le traitement de documents sensibles via des APIs cloud nécessite une conformité supplémentaire. L'inférence locale via Qwen2.5 maintient tout le contenu sur site. Qwen2.5 est 30-40% plus efficace en tokens pour les documents en chinois.
Erreurs courantes avec les LLMs locaux à long contexte
- Supposer que le contexte 128K fonctionne aussi bien que 4K : L'effet "perdu au milieu" signifie que les informations présentées 30K-80K tokens auparavant sont moins fiablement récupérées. Découper les longs documents en sections de 16K-32K.
- Ne pas augmenter la taille de contexte par défaut d'Ollama : Ollama utilise par défaut 2048 tokens, quelle que soit la fenêtre maximale du modèle. Toujours définir num_ctx via PARAMETER num_ctx 32768 dans un Modelfile ou --ctx au moment de l'exécution.
- Exécuter un long contexte avec RAM insuffisante : Un modèle 7B avec contexte 128K sur 8 Go total cause une utilisation intensive du swap. Poids du modèle (~4,5 Go) plus cache KV 128K (~8+ Go) dépassent 8 Go.
- Oublier que le TTFT évolue avec la longueur du contexte : À 32K de contexte, le temps jusqu'au premier token peut être de 5-15 secondes sur hardware grand public.
- Utiliser le RAG quand le long contexte est le bon outil (et vice versa) : Le RAG est meilleur pour la recherche sur de nombreux documents. Le long contexte est meilleur pour raisonner sur un document complet et cohérent.
FAQ
Puis-je résumer un livre entier avec un LLM local ?
Un livre typique de 300 pages représente 90 000-120 000 mots -- environ 120K-160K tokens. Cela dépasse le contexte fiable de la plupart des modèles 7B. Pour les 7B, diviser le livre en chapitres de 20K mots, résumer chacun, puis résumer les résumés.
Combien de pages tiennent dans 32K tokens ?
Environ 50-70 pages de texte standard (250 mots par page). Un contexte 32K tient un court roman, un article de recherche complet ou un document de spécification technique.
Augmenter la longueur de contexte ralentit-il l'inférence ?
Oui -- traiter un contexte 32K prend environ 3-4× plus longtemps qu'un 4K sur le même hardware. La vitesse de génération n'est pas significativement affectée, mais le temps jusqu'au premier token évolue avec la longueur d'entrée.
Quel LLM local gère mieux le RAG que le long contexte ?
Pour la recherche documentaire, le RAG est souvent plus efficace. Il récupère 3-5 blocs pertinents (4K-8K tokens au total) et évite le problème "perdu au milieu".
Qu'est-ce que le cache KV et pourquoi grandit-il avec le contexte ?
Le cache KV stocke les états d'attention pour chaque token traité. Un contexte 32K nécessite 8× plus de mémoire qu'un 4K. Les poids du modèle restent identiques -- seul le cache KV croît.
Les modèles locaux peuvent-ils gérer 1M tokens comme Gemini 3.1 Pro ?
Non -- au 1er avril 2026, aucun modèle local ne supporte 1M tokens. La fenêtre 1M tokens de Gemini 3.1 Pro nécessite l'infrastructure TPU de Google. Localement, 128K est le maximum sur hardware grand public.
Qu'est-ce que le problème "perdu au milieu" et comment l'éviter ?
Les LLMs récupèrent fiablement les informations au début et à la fin du contexte, mais ratent les détails du milieu. Pour un contexte 128K, les contenus à 40K-80K tokens sont les plus susceptibles d'être ignorés. Garder les informations critiques au début du prompt, utiliser le RAG ou traiter en sections chevauchantes 16K-32K.
Comment vérifier la longueur de contexte utilisée par Ollama ?
Exécuter `ollama show <modèle>` -- la sortie liste num_ctx. Si c'est 2048, Ollama utilise le défaut. Pour modifier durablement : créer un Modelfile avec PARAMETER num_ctx 32768 et exécuter `ollama create <nom> -f Modelfile`. Vérifier avec `ollama ps`.
Le long contexte ou le RAG est-il meilleur pour les questions-réponses ?
Le RAG est généralement plus efficace et RAM-efficient pour les Q&R documentaires. Il récupère 3-5 blocs pertinents (4K-8K tokens). Le long contexte est meilleur quand le modèle doit comprendre la structure complète du document.
Sources
- Lost in the Middle: How Language Models Use Long Contexts -- Liu et al., 2023
- Ollama Context Length Configuration -- Documentation Ollama
- Llama 3.1 Technical Report -- Meta AI, 2024
- Texte officiel de la Loi IA UE -- Parlement européen, 2024