Fenêtre de contexte et mémoire d’un LLM local

Fenêtre de contexte et mémoire d’un LLM local

La fenêtre de contexte limite ce qu’un LLM (Large Language Model) local peut lire et utiliser pour produire la réponse suivante. Le compromis central est brutal : une fenêtre plus grande conserve davantage d’informations, mais augmente la mémoire consommée, le temps de préremplissage et la surface de déni de service.

La recommandation par défaut est de dimensionner la fenêtre pour la tâche, pas pour la fiche marketing du modèle. Pour une conversation opérationnelle, 8 000 à 16 000 jetons, complétés par un résumé contrôlé et une recherche documentaire, battent généralement 128 000 jetons ouverts à tous vents.

Explication de la marmotte

Une discussion longue ressemble à un bureau sur lequel on empile des dossiers. Plus on garde de feuilles sous les yeux, plus on risque de chercher lentement et de rater la feuille décisive. Il faut conserver les décisions, pas transformer le bureau en décharge administrative.

→ Lire l’explication complète de la marmotte

Fenêtre de contexte, jetons et cache KV

Un jeton est une unité de texte découpée par le modèle avant traitement. Un mot français courant occupe souvent un à trois jetons, mais les identifiants, extraits de code, données structurées et chaînes encodées peuvent en consommer beaucoup plus. Compter les caractères au lieu des jetons produit des limites fictives, puis des erreurs que personne ne retrouve dans les tableaux de capacité. La poésie des quotas, en somme.

La fenêtre de contexte comprend tout ce qui est envoyé au modèle : instruction système, historique de conversation, documents récupérés, appel d’outil, réponse d’outil et espace réservé à la génération. Une API qui accepte context_length=32768 ne garantit pas 32 768 jetons disponibles pour l’historique. Si 4 000 jetons sont réservés à la réponse et 2 000 aux instructions, il reste 26 768 jetons pour le reste.

Pendant l’inférence, le moteur conserve généralement un cache KV (Key Value), contenant les représentations intermédiaires des jetons précédents. Son coût mémoire est approximativement :

taille_cache_KV = 2 × couches × jetons_contexte × têtes_KV × dimension_tête × octets_par_valeur

Pour un modèle de 32 couches, 8 têtes KV, une dimension de tête de 128 et des valeurs en précision 16 bits, 8 192 jetons occupent environ 1 Gio de cache KV. Doubler la fenêtre double ce cache. Les poids du modèle quantifiés ne changent pas ce calcul : charger un modèle en 4 bits ne transforme pas automatiquement son cache KV en plume de colibri.

Le préremplissage, phase qui traite le contexte existant avant de générer, devient coûteux lorsque la fenêtre augmente. Selon l’architecture et l’implémentation, l’attention peut faire croître le coût bien plus vite que linéairement. La génération jeton par jeton ralentit aussi car chaque nouveau jeton consulte le cache existant. Une fenêtre de 128 000 jetons est donc une capacité, pas une invitation à remplir 128 000 jetons.

Les modèles annonçant un contexte étendu reposent parfois sur une adaptation de positions, telle que RoPE (Rotary Position Embedding) mise à l’échelle. Cette extension peut dégrader la qualité hors de la plage d’entraînement native, surtout pour le raisonnement multi-étapes, les références éloignées et le code. Tester uniquement la capacité à ne pas planter ne mesure rien d’utile : il faut vérifier que le modèle retrouve une contrainte placée au début, au milieu et à la fin du contexte.

Pour choisir le modèle et le moteur d’inférence, consulter aussi la page IA locale. Le format des poids, le backend matériel et le serveur exposé déterminent autant la capacité réelle que le nombre imprimé sur une carte produit.

Compromis mémoire, latence et capacité matérielle

La mémoire vidéo d’un GPU (Graphics Processing Unit) doit accueillir les poids, le cache KV, les buffers de calcul et une marge pour le runtime. Dépasser cette capacité entraîne un basculement vers la mémoire centrale, une fragmentation, une erreur d’allocation ou une latence qui transforme chaque réponse en séance de contemplation. Selon le moteur, le basculement peut être silencieux. C’est pire qu’un échec net.

Une politique de capacité doit réserver la mémoire avant de fixer le nombre de requêtes simultanées. Si un modèle consomme 10 Gio de poids et 1 Gio de cache KV par session à 8 192 jetons, une carte de 24 Gio ne sert pas quatorze conversations : il faut intégrer les buffers, la marge d’allocation et les pics de longueur. Limiter le contexte par requête sans limiter la concurrence est une demi-mesure, donc une mesure décorative.

Trois profils sont défendables :

• Conversation interactive : 8 000 à 16 000 jetons, réponse réservée de 1 000 à 4 000 jetons, résumé périodique et recherche externe.
• Analyse de document : 16 000 à 32 000 jetons si le document doit être lu en continuité, avec découpage si plusieurs documents sont comparés.
• Traitement spécialisé : 64 000 jetons ou davantage seulement si une évaluation prouve que les références lointaines sont nécessaires et si le budget mémoire est réservé par session.

La fenêtre longue ne remplace pas la recherche. Pour une base documentaire, indexer les sources avec des embeddings, puis injecter les passages pertinents, reste plus prévisible. Les embeddings et la recherche sémantique réduisent le contexte envoyé et permettent de conserver les citations, la fraîcheur des documents et les droits d’accès. Le RAG (Retrieval-Augmented Generation) mal conçu reste toutefois un distributeur automatique de paragraphes : sans filtrage d’autorisation et sans citation de source, il accélère aussi la fuite de données.

Conversation dépassant la fenêtre disponible

Une conversation durable doit séparer quatre objets : le journal brut, l’état structuré, le résumé narratif et les documents externes. Le journal brut est immuable et sert à l’audit ou à la reprise. L’état structuré contient les paramètres qui doivent survivre, par exemple une cible technique, des contraintes d’architecture, des décisions validées et des éléments à confirmer. Le résumé narratif préserve le raisonnement récent. Les documents externes restent référencés par identifiant et version, pas recopiés indéfiniment.

À l’approche de la limite, ne pas supprimer aveuglément les premiers messages. Une instruction métier, une restriction de sécurité ou une décision validée peut s’y trouver. La stratégie robuste consiste à :

1. compter les jetons avant chaque appel et réserver la sortie ;
2. extraire les faits durables dans un état typé et validable ;
3. résumer les échanges anciens avec une provenance vers les messages d’origine ;
4. récupérer à nouveau les extraits nécessaires depuis le journal ou l’index documentaire ;
5. reconstruire un contexte borné avec instructions, état, derniers échanges et sources citées.

Le résumé doit être traité comme une donnée dérivée, jamais comme une vérité souveraine. Une hallucination introduite dans un résumé persiste ensuite pendant des dizaines de tours. Chaque fait critique doit conserver une référence vers son message, son document ou son appel d’outil d’origine. Sans cette provenance, une conversation longue devient un jeu du téléphone arabe piloté par une carte graphique.

Les données structurées doivent avoir un schéma : valeur, source, date de mise à jour, niveau de confiance et statut de validation. Une phrase libre telle que « le certificat expire bientôt » ne permet ni alerte ni contrôle. Une date ISO 8601, un identifiant de certificat et une source permettent les deux.

Exemple reproductible de limite de contexte avec llama.cpp

llama.cpp permet d’imposer une fenêtre de contexte au serveur local. Épingler un commit ou une version du binaire dans l’automatisation : les noms d’options et les performances changent, parfois avec l’enthousiasme d’un framework JavaScript un mardi matin.

# Pré-requis : binaire llama-server et modèle GGUF local compatible.
# La fenêtre totale est limitée à 8192 jetons.
# -ngl 99 délègue autant de couches que possible au GPU disponible.
llama-server \
  --model ./models/model.gguf \
  --ctx-size 8192 \
  --n-gpu-layers 99 \
  --port 8080

# Appel compatible avec l'API de conversation.
# max_tokens réserve 1024 jetons pour la réponse : le reste sert aux messages.
curl --fail --silent http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local",
    "max_tokens": 1024,
    "messages": [
      {"role": "system", "content": "Répondre en français avec des faits vérifiables."},
      {"role": "user", "content": "Résumer ce document sans inventer de source."}
    ]
  }'

Le serveur doit être exposé derrière une authentification et un proxy, même sur un réseau interne. Une API locale sans contrôle d’accès devient rapidement une API partagée, puis une dépendance non inventoriée. Le réseau interne est un emplacement, pas une politique de sécurité. Les principes de segmentation et de journalisation restent décrits dans les sections réseaux et architecture cyber.

Mesurer au minimum : jetons d’entrée, jetons générés, durée de préremplissage, jetons générés par seconde, mémoire GPU, mémoire centrale, taux de requêtes rejetées et longueur de contexte au percentile 95. Sans ces métriques, augmenter la fenêtre revient à déplacer un curseur dans le noir avec une confiance admirable.

Surface d’attaque et conditions d’exploitation

Le contexte est une entrée non fiable, même lorsqu’il provient d’une conversation authentifiée. Une attaque par injection d’instructions place dans un document ou un message des directives visant à modifier le comportement du modèle, exfiltrer un extrait précédent ou appeler un outil. Les instructions système ne créent pas une frontière de sécurité : elles orientent le modèle, elles ne contraignent pas un processeur.

Les contre-mesures sont architecturales. Séparer les contenus non fiables des règles de contrôle, réduire les droits des outils, exiger une validation humaine pour les actions destructrices et appliquer les autorisations au niveau de la source documentaire. Un modèle ne doit jamais décider seul qu’un document est autorisé parce qu’il l’a reçu dans son contexte.

Le bourrage de contexte vise la disponibilité : un client envoie un historique gigantesque pour monopoliser mémoire et calcul. Imposer une limite de jetons par requête, une limite de sessions, des quotas par identité et un délai d’exécution. La concurrence doit être bornée par le cache KV réellement alloué, pas par la valeur optimiste d’un tableau de bord.

Les journaux constituent une fuite fréquente. Les prompts peuvent contenir des secrets, des tickets, des extraits de configuration et des données personnelles. Chiffrer les sauvegardes, contrôler les accès, définir une durée de rétention et masquer les jetons d’accès avant journalisation. Une clé d’API dans un prompt ne cesse pas d’être une clé d’API parce qu’elle participe à une conversation philosophique avec un modèle.

La reprise doit restaurer le journal brut, l’état structuré et les références documentaires dans des stockages distincts. Sauvegarder seulement le résumé rend la reprise non vérifiable. Sauvegarder tout sans politique de rétention fabrique un dépôt de données sensibles dont personne ne veut assumer l’existence. La fenêtre de contexte ne garantit ni exactitude, ni confidentialité, ni mémoire persistante : ces propriétés doivent venir respectivement de la validation, des contrôles d’accès et du stockage.

🐝 Ce qui arrive si on s’en passe

Sans bornage du contexte envoyé au modèle, la fenêtre devient une surface de déni de service et de fuite. Un client qui pousse un historique gigantesque monopolise mémoire et calcul, car le cache KV croît avec la longueur du contexte et le préremplissage coûte de plus en plus cher : sans limite de jetons par requête, quotas par identité et délai d’exécution, une seule session épuise la mémoire GPU et fait basculer le service vers un ralentissement ou un refus généralisé. Le contexte reste par ailleurs une entrée non fiable, et sans séparation des contenus hostiles des règles de contrôle, une instruction cachée dans un document détourne le comportement du modèle ou déclenche un appel d’outil. Les journaux de prompts, s’ils ne sont ni masqués ni contrôlés, conservent secrets, tickets et données personnelles : une clé d’API dans une conversation reste une clé d’API exposée.

🦫 Explication de la marmotte 🍫

Un modèle de langage local reçoit un texte découpé en petites unités. Il garde ces unités en mémoire pendant qu’il prépare sa réponse. Cette mémoire de travail a une taille maximale appelée fenêtre de contexte. Elle contient à la fois les règles données au modèle, les messages précédents, les documents ajoutés et la place nécessaire pour écrire la réponse.

Plus cette fenêtre est grande, plus le modèle peut relire d’éléments anciens. En contrepartie, la machine doit conserver davantage de données en mémoire et effectuer davantage de calculs. Si la mémoire manque, la réponse ralentit fortement ou le service refuse la demande.

Quand une discussion devient trop longue, il ne faut pas seulement supprimer les premiers messages. Il faut conserver le journal complet ailleurs, extraire les décisions et les paramètres dans une forme structurée, puis produire un résumé contrôlé des échanges anciens. Les documents nécessaires sont recherchés à nouveau au lieu d’être gardés en permanence dans la mémoire de travail.

Cette organisation évite de perdre une contrainte ancienne tout en limitant la charge de la machine. Elle ne rend pas le modèle infaillible. Le modèle peut mal résumer, ignorer une information ou suivre une instruction cachée dans un document. Les données sensibles doivent donc être protégées avant d’être envoyées, les accès aux documents doivent être vérifiés, et les actions risquées doivent exiger un contrôle extérieur au modèle.

À lire aussi

• Dimensionner GPU et RAM pour un LLM localMéthode pratique pour calculer la mémoire requise, choisir CPU ou GPU et valider un serveur d’inférence locale de grand modèle de langage.
• Fine-tuning local ou RAG pour données internesComparer le fine-tuning local et le RAG pour exploiter des données internes sans augmenter inutilement le risque de fuite.
• Calculer le coût d’un LLM local à grande échelleMéthode de dimensionnement et d’optimisation économique d’un déploiement local de modèles de langage à grande échelle.
• Comment fonctionne l'inférence d'un modèle de langagePréremplissage, décodage, cache de clés et valeurs, batching et surface d'attaque d'un serveur d'inférence, avec les compromis de latence et de débit à trancher avant la mise en production.

Pages voisines

La citent

• Dimensionner GPU et RAM pour un LLM local
• Comment fonctionne l'inférence d'un modèle de langage
• Différence entre IA et LLM : un champ entier, un type de modèle

Fenêtre de contexte et mémoire d’un LLM local

Elle cite

• ⇄Lien dans les deux sens :Comparer GGUF GPTQ et AWQ pour LLM local
• Embeddings : vecteurs, recherche sémantique et RAG
• Sécuriser un corpus RAG contre l’injection indirecte
• Mettre en place un rate limiting anti-DDoS L7

⇄ : les deux pages se citent l’une l’autre.