Garder un modèle Ollama chargé en mémoire

Pourquoi Ollama décharge-t-il le modèle après quelques minutes ?

Ollama conserve un modèle en mémoire pendant cinq minutes après la dernière requête, puis le libère. La requête suivante doit relire les poids depuis le disque et les mapper de nouveau dans la RAM ou la VRAM. Elle reste donc en attente avant l’arrivée du premier token. C’est pourquoi une interface de chat ou un agent de programmation semble rapide, reste inactif quelque temps, puis redevient lent au message suivant. Rien n’est défaillant. Le délai d’inactivité a expiré.

Ce délai s’appelle keep_alive. Il est propre à chaque modèle et redémarre à chaque fin de requête. Un modèle qui répond à une requête n’est jamais déchargé, car le serveur n’expire que les modèles qui n’ont aucune requête active. En août 2026, la valeur par défaut est de cinq minutes et s’applique à chaque modèle chargé par ce serveur.

Vous pouvez définir keep_alive à deux endroits : pour une requête donnée ou comme valeur par défaut du serveur. Un drop-in systemd permet de conserver la valeur par défaut du serveur après un redémarrage. Ce guide suppose qu’Ollama fonctionne déjà comme un service. Si ce n’est pas le cas, commencez par installer Ollama sur un VPS, puis revenez ici.

Quels modèles sont actuellement chargés, et quand expirent-ils ?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Une sortie vide signifie qu’aucun modèle n’est chargé. La prochaine requête devra donc effectuer un chargement complet. PROCESSOR indique où les poids ont été chargés. 100% GPU et 100% CPU correspondent aux cas simples. Une répartition telle que 25%/75% CPU/GPU signifie que le modèle ne tient pas dans la VRAM. Une partie s’exécute donc sur le processeur, ce qui ralentit la génération.

UNTIL indique le compte à rebours et affiche une durée relative telle que 4 minutes from now. Il affiche Forever lorsque le modèle a été chargé avec une valeur négative pour keep_alive. Il affiche Stopping... pendant la courte période où le serveur décharge le modèle.

L’ensemble des colonnes a changé entre les releases. Lisez donc l’en-tête au lieu de compter les champs dans un script. Pour toute automatisation, interrogez l’API :

curl -s http://localhost:11434/api/ps

Chaque entrée contient expires_at, un horodatage absolu tel que 2026-08-09T14:38:31.83753Z, ainsi que size_vram, la partie de ce modèle qui se trouve dans la mémoire du GPU. Une valeur size_vram de 0 signifie que le modèle s’exécute sur le CPU.

Coût réel du rechargement

Ne le devinez pas. Ollama indique le temps de chargement dans chaque réponse, sous la forme de load_duration, en nanosecondes.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

Le premier appel charge le modèle, donc sa valeur load_duration est élevée. Divisez-la par 1000000000 pour l’obtenir en secondes. Le deuxième appel s’exécute alors que le modèle réside encore en mémoire et indique une valeur bien plus faible. L’écart entre ces deux valeurs correspond au temps que chaque utilisateur doit attendre une fois le délai d’expiration écoulé. C’est la raison principale de modifier keep_alive. Cet écart correspond en grande partie à la lecture sur disque. Si vous avez déplacé le répertoire du modèle sur un second volume, la vitesse de ce volume détermine la durée minimale de chaque chargement à froid. Pour connaître la vitesse de génération avant et après cette pause, consultez la méthode de mesure du nombre de tokens par seconde sur votre machine.

Garder un modèle Ollama chargé en mémoire pour une requête

Envoyez keep_alive avec la requête. Ce paramètre s’applique à ce modèle dès que la requête est terminée.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Quatre formes de valeur sont acceptées :

• une chaîne de durée : "30m", "24h", "90s"
• un nombre simple, interprété en secondes : 3600
• une valeur négative, -1 ou "-1m", qui désactive complètement le délai d’inactivité
• 0, qui décharge le modèle dès que la requête est terminée

Une valeur définie dans la requête remplace la valeur par défaut du serveur, dans les deux sens. Ce point est important : un client qui envoie son propre keep_alive prend le dessus sur toute configuration définie sur le serveur.

Vous pouvez également charger un modèle sans rien générer. Envoyez uniquement le nom du modèle. Le serveur le charge et renvoie une réponse vide avec "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

C’est la commande à exécuter après un redémarrage ou après avoir récupéré un nouveau modèle, afin que la première requête réelle d’un utilisateur n’attende pas le chargement. La CLI permet de faire la même chose avec une option :

ollama run --keepalive 30m qwen3:8b "hello"

Conservez le modèle chargé par défaut avec OLLAMA_KEEP_ALIVE

Le serveur lit OLLAMA_KEEP_ALIVE au démarrage et l’utilise pour chaque modèle qui ne possède pas sa propre valeur. La variable accepte les mêmes formats que le champ de la requête. 30m, 3600 et -1 fonctionnent donc tous.

Le point important est de définir la variable dans l’environnement du bon processus. Exécuter export OLLAMA_KEEP_ALIVE=30m dans votre session SSH ne change rien, car l’installation packagée exécute le serveur comme un service systemd, avec son propre utilisateur et son propre environnement. Votre shell de connexion et ce service ne partagent pas leur environnement. C’est la cause la plus fréquente lorsque le paramètre semble ignoré.

Rendez-le persistant après un redémarrage avec un drop-in systemd

sudo systemctl edit ollama.service

L’éditeur s’ouvre avec deux marqueurs de commentaire. Saisissez le contenu entre ces deux marqueurs : systemd ignore tout ce qui est écrit sous le second marqueur.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

L’enregistrement écrit /etc/systemd/system/ollama.service.d/override.conf. Il s’agit d’un drop-in, et non d’une modification de l’unité fournie avec le paquet. Une mise à niveau du paquet Ollama qui remplace ollama.service conserve donc votre réglage. Si les drop-ins et les fichiers d’unité sont nouveaux pour vous, le guide des services et timers systemd explique leur fonctionnement.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

La dernière commande affiche l’environnement réel dans lequel le service s’exécutera. Si OLLAMA_KEEP_ALIVE=30m n’apparaît pas sur cette ligne, le drop-in n’a pas été pris en compte. La cause est presque toujours un en-tête [Service] manquant ou des lignes saisies sous le marqueur. Le redémarrage décharge tous les modèles déjà chargés, donc la requête suivante déclenche un chargement à froid. Réchauffez le modèle avec l’appel de préchargement ci-dessus.

Le coût du maintien d’un modèle en mémoire

La colonne SIZE de ollama ps indique la mémoire conservée pendant toute la fenêtre d’inactivité, et pas uniquement pendant une requête. Un modèle 8B en quantification 4 bits occupe environ 5 à 6 GB. Un modèle 27B change complètement la donne, et le calcul de la mémoire nécessaire pour en exécuter un sur un VPS avec CPU uniquement mérite d’être fait avant de décider de le maintenir en mémoire. Définir keep_alive sur -1 revient à décider que le modèle passe en permanence avant tout le reste sur le serveur. Sur un petit VPS, cela réduit directement les ressources disponibles pour votre base de données, votre application web et vos jobs de build.

Contrôlez les valeurs réelles au lieu de vous fier à une estimation. Exécutez cette commande lorsqu’un modèle est chargé, puis de nouveau après ollama stop :

free -h

La colonne available indique la mémoire que le kernel peut encore attribuer à un nouveau processus. Sur un serveur équipé d’un GPU NVIDIA, nvidia-smi montre le même phénomène dans la VRAM. Si le serveur arrive à court de mémoire, le kernel tue un processus pour en récupérer :

sudo dmesg -T | grep -i "out of memory"

Une ligne mentionnant ollama signifie que le model server a été la victime. Une ligne mentionnant votre base de données signifie que le modèle a gagné et qu’un service important a été arrêté. Les deux situations résultent de la même décision : utiliser une longue fenêtre de keep-alive sur un serveur sans marge de mémoire.

Deux coûts sont faciles à négliger. Une longueur de contexte plus importante réserve un KV cache plus grand (key value cache, l’état d’attention par token que le modèle conserve pendant la génération), et ce cache fait partie de la taille résidente. Sa taille dépend de num_ctx. Ainsi, augmenter la fenêtre de contexte augmente la mémoire conservée par un modèle résident pendant toute la période d’inactivité, et pas uniquement lorsqu’il répond. Une valeur de OLLAMA_NUM_PARALLEL supérieure à 1 réserve ce cache une fois par slot parallèle. Si vous prévoyez de servir plusieurs utilisateurs avec un seul modèle, dimensionnez la mémoire pour les slots, et pas seulement pour les poids.

Une valeur par défaut raisonnable consiste à utiliser -1 pour un modèle sur un serveur disposant de marge. Sur un serveur partagé, utilisez une fenêtre qui couvre les intervalles entre vos requêtes, par exemple 30m, afin que la mémoire soit libérée lorsque vous arrêtez de travailler.

Décharger immédiatement un modèle

ollama stop qwen3:8b

La commande ne renvoie aucune sortie et le modèle disparaît de ollama ps. Un nom qui n’est pas chargé renvoie couldn't find model "qwen3:8b" to stop. La forme API est une requête sans invite, avec keep_alive défini sur 0 :

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

La réponse contient "done_reason": "unload". Utilisez cette méthode plutôt que de redémarrer le service. systemctl restart ollama libère également la mémoire, mais décharge tous les autres modèles chargés et interrompt toute requête en cours.

Exécuter plusieurs modèles sur un même serveur

OLLAMA_MAX_LOADED_MODELS limite le nombre de modèles chargés simultanément. En août 2026, la valeur par défaut est de trois modèles par GPU, ou de trois modèles sur une machine uniquement équipée d’un CPU. Cette limite compte les modèles, mais la mémoire reste la contrainte réelle. Un deuxième modèle volumineux peut donc être refusé bien avant d’atteindre trois modèles.

Lorsqu’un nouveau modèle est demandé et que la mémoire disponible est insuffisante, le scheduler décharge l’un des modèles résidents pour libérer de la place. Il privilégie un modèle qui ne traite aucune requête active. Il peut aussi évincer un modèle dont le délai d’inactivité n’a pas expiré, y compris un modèle chargé avec -1. Une valeur négative pour keep_alive signifie donc qu’aucun délai d’inactivité ne s’applique. Elle ne verrouille pas les poids et n’empêche pas le chargement d’un autre modèle.

Cette décision est journalisée au niveau debug. Ajoutez une deuxième ligne Environment="OLLAMA_DEBUG=1" au même drop-in, redémarrez le service, puis surveillez les journaux :

sudo journalctl -u ollama -f

Une ligne indiquant qu’un runner est déchargé pour libérer de la place, à proximité de la requête qui a déclenché l’opération, montre que ces deux modèles ne tiennent pas ensemble sur cette machine. La solution consiste à exécuter moins de modèles sur ce serveur, ou à définir une longue durée de conservation pour celui qui doit répondre rapidement et 0 pour celui que vous appelez rarement.

Des recommandations valables au-delà de la prochaine version

Ollama publie fréquemment de nouvelles versions et ses valeurs par défaut évoluent. Vérifiez donc la version installée plutôt que de mémoriser des numéros :

ollama --version
ollama serve --help

ollama serve --help répertorie les variables d’environnement effectivement lues par cette version, notamment OLLAMA_KEEP_ALIVE. Deux règles sont restées valables au fil des versions et peuvent servir de base. Une valeur définie dans la requête prend le dessus sur la valeur par défaut du serveur. Et ollama ps indique ce qui est réellement chargé, quel que soit le contenu attendu par un fichier de configuration.

Si un éditeur ou un agent pilote votre serveur, vérifiez ce que ce client envoie avant d’incriminer le serveur. Connecter un agent de développement à votre propre serveur Ollama explique où se trouvent ces paramètres de requête.

FAQ

Pourquoi Ollama décharge-t-il mon modèle après 5 minutes ?

Cinq minutes correspond à la valeur par défaut de keep_alive, le délai d’inactivité qu’Ollama démarre lorsqu’une requête se termine. À son expiration, le serveur libère les poids du modèle. La requête suivante doit donc les recharger depuis le disque, ce qui provoque la pause que vous constatez. Augmentez cette valeur pour une seule requête en envoyant "keep_alive": "30m" dans le corps JSON, ou pour l’ensemble du serveur avec la variable d’environnement OLLAMA_KEEP_ALIVE.

Comment conserver un modèle Ollama chargé en mémoire en permanence ?

Utilisez une valeur négative : "keep_alive": -1 pour la requête, ou OLLAMA_KEEP_ALIVE=-1 pour le serveur. ollama ps affiche alors Forever dans la colonne UNTIL. Cela supprime uniquement le délai d’inactivité. Si un autre modèle est demandé et que la mémoire disponible est insuffisante, le scheduler décharge tout de même celui-ci pour libérer de la place.

Pourquoi OLLAMA_KEEP_ALIVE est-il ignoré ?

Vérifiez l’endroit où vous l’avez définie. Exécutez systemctl show ollama --property=Environment. Si la variable n’apparaît pas dans la sortie, le serveur ne l’a jamais reçue, car une variable exportée dans votre shell n’est pas transmise à un service systemd. Définissez-la avec sudo systemctl edit ollama.service, puis exécutez sudo systemctl daemon-reload et sudo systemctl restart ollama. L’autre cause possible est un client qui envoie sa propre valeur keep_alive dans la requête. Celle-ci remplace la valeur par défaut du serveur.

Comment libérer la mémoire sans redémarrer Ollama ?

ollama stop qwen3:8b décharge immédiatement ce modèle et laisse le serveur ainsi que tous les autres modèles chargés fonctionner. Avec l’API, envoyez une requête sans prompt et avec "keep_alive": 0. La réponse contient alors "done_reason": "unload". Vérifiez avec ollama ps : le modèle ne devrait plus être listé.