Le modèle annonce une grande fenêtre, le logiciel affiche un curseur et la conversation commence à ralentir. Le contexte Ollama mérite alors un contrôle concret : quelle capacité est réellement allouée pendant cet essai ? La valeur annoncée par une fiche de modèle ne répond pas à cette question.
Ce guide documentaire propose un protocole de vérification, pas un benchmark réalisé sur le PC de l’auteur. Les références officielles ont été relues le 24 octobre 2026. L’objectif est de rendre un réglage compréhensible et reproductible, sans recommander une taille universelle.
Contexte Ollama : vérifier avant d’augmenter
La documentation officielle d’Ollama définit le contexte comme le nombre maximal de tokens accessibles au modèle en mémoire. Elle précise qu’une augmentation demande davantage de mémoire, propose un réglage dans l’application et indique comment examiner l’allocation avec ollama ps. Il faut donc séparer la limite du modèle, le réglage demandé et l’état effectivement observé.
Le dimensionnement du matériel est un autre sujet. Le dossier LLM local : VRAM, RAM et contexte sert à préparer une configuration. Ici, on garde la même machine et le même modèle : on cherche à comprendre ce qui change quand le réglage change.
Préparer une fiche d’essai minimale
Je préfère une petite fiche complète à une capture impressionnante mais impossible à expliquer. Avant de modifier quoi que ce soit, noter la version d’Ollama, le nom exact du modèle, l’interface utilisée et la valeur actuellement choisie. Ajouter la question test et conserver le texte du document envoyé. Si ce document est privé, utiliser une copie de travail expurgée.
Le nom d’un modèle ne suffit pas à identifier toutes les conditions. Garder également les réglages de génération identiques pendant la comparaison. Sinon, une réponse différente pourrait venir du tirage ou d’une consigne modifiée, pas du contexte. Le guide sur les réglages d’une IA locale complète cette préparation.
| À noter | Pourquoi le garder |
|---|---|
| Modèle et interface | Ne pas comparer deux chemins d’utilisation différents |
| Contexte demandé | Retrouver le point de départ |
| Contexte observé | Vérifier l’allocation pendant l’essai |
| Document et question | Rejouer la même tâche |
| Résultat et gêne constatée | Juger l’utilité, pas seulement une capacité |
Observer le contexte Ollama pendant une tâche
Lancer une demande suffisamment représentative pour que le modèle soit chargé, puis ouvrir un second terminal sur la même machine. La commande suivante consulte les modèles en cours d’exécution ; elle n’est pas une commande d’installation ou d’effacement :
ollama psDans la sortie documentée par Ollama, les colonnes CONTEXT et PROCESSOR permettent d’examiner respectivement le contexte alloué et la répartition processeur/GPU. Conserver la sortie associée au bon modèle, sans recopier les chiffres d’un exemple trouvé sur Internet comme s’ils venaient de sa machine.
Si aucun modèle n’est listé, cette observation ne prouve pas que le réglage est ignoré. Il faut d’abord vérifier que la demande a bien été traitée par cette instance et que le modèle n’a pas déjà été déchargé. Une capture faite après la fin d’une session ne raconte pas nécessairement son état pendant le travail.
Changer une seule chose dans l’application
Pour un premier contrôle, le curseur de longueur de contexte de l’application évite d’ajouter un deuxième mode de configuration. Noter l’ancienne valeur, choisir une autre valeur compatible avec le modèle et les ressources disponibles, puis relancer le même essai. Réexaminer l’allocation au lieu de supposer que le simple déplacement du curseur suffit à valider le résultat.
Si une interface tierce ou une API intervient, la noter comme une condition supplémentaire. Ne pas mélanger un résultat obtenu dans l’application et un résultat envoyé par un autre client sans vérifier ses paramètres. La référence de génération Ollama distingue notamment le modèle, le prompt, les options d’exécution et les compteurs de réponse. Un comparatif utile doit préciser le chemin utilisé.
Tester la tâche utile, pas une mémoire magique
Voici un scénario fictif, à adapter sans données sensibles. Préparer un document contenant trois références uniques : une au début, une au milieu et une à la fin. Demander au modèle de retrouver ces références et de citer la section correspondante. Vérifier la réponse dans le document original, pas avec une deuxième réponse du même modèle.
Faire ensuite un essai plus proche du vrai besoin : retrouver une contrainte dans un compte rendu, comparer deux passages ou produire une synthèse accompagnée des sections utilisées. Les références artificielles contrôlent un comportement simple ; elles ne suffisent pas à démontrer une compréhension fiable d’un dossier entier.
Cette méthode est une proposition de contrôle, pas un résultat acquis. Une référence retrouvée ne garantit ni l’absence d’omission ailleurs ni la justesse d’une conclusion. Si la tâche exige une preuve précise, garder le passage source à côté de la réponse.
Décider avec trois critères
- La tâche utile est-elle mieux réalisée sur le même document ?
- L’attente et l’occupation mémoire restent-elles acceptables ?
- Peut-on reproduire et expliquer la différence observée ?
Le protocole de benchmark IA locale aide à séparer latence, génération et qualité. Il n’est pas nécessaire de transformer chaque réglage en concours de débit. Si une capacité plus grande n’améliore pas le travail et rend la machine pénible à utiliser, revenir au réglage précédent est une décision raisonnable.
Le bon contexte Ollama n’est donc pas le plus grand nombre que l’on peut afficher. C’est un réglage observé, associé à une tâche et conservé avec ses limites. Cette petite discipline évite de confondre promesse du modèle, configuration du logiciel et résultat réellement utile.
