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 chargé en mémoire pendant cinq minutes après la dernière requête, puis libère cette mémoire. 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 bloquée avant l’arrivée du premier token. C’est pourquoi une interface de chat ou un agent de codage semble rapide, reste silencieux quelque temps, puis redevient lent au message suivant. Rien n’est défectueux. Le délai d’inactivité a expiré.

Le délai s’appelle keep_alive. Il est propre à chaque modèle et redémarre chaque fois qu’une requête se termine. Un modèle qui traite actuellement 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. Elle s’applique à tous les modèles chargés 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 s’exécute déjà comme 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 requête suivante doit donc effectuer un chargement complet. PROCESSOR indique où les poids ont été placés. 100% GPU et 100% CPU correspondent aux cas simples. Une valeur fractionnée 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 et la génération est plus lente.

UNTIL indique le compte à rebours. Il affiche une durée relative telle que 4 minutes from now. Il affiche Forever lorsque le modèle a été chargé avec une valeur keep_alive négative. Il affiche Stopping... pendant le court intervalle durant lequel le serveur décharge le modèle.

L’ensemble des colonnes a changé entre les versions. Consultez 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 présente dans la mémoire GPU. Une valeur size_vram égale à 0 signifie que le modèle s’exécute sur le CPU.

Ce que coûte réellement le 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. Sa valeur load_duration est donc élevée. Divisez-la par 1000000000 pour l’obtenir en secondes. Le deuxième appel s’exécute alors que le modèle est encore résident et indique une valeur bien plus faible. L’écart entre ces deux valeurs correspond au coût supporté par chaque utilisateur après l’expiration du délai. C’est la raison principale de modifier keep_alive. Pour connaître la vitesse de génération avant et après cette pause, consultez comment mesurer le nombre de tokens par seconde sur votre propre serveur.

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 se termine.

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é comme un nombre de 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 se termine

La 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 sa propre valeur keep_alive prend le dessus sur toute configuration définie sur le serveur.

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

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

Exécutez cette commande après un redémarrage ou après avoir récupéré un nouveau modèle. La première requête réelle d’un utilisateur n’aura ainsi pas à attendre le chargement. La CLI permet de faire la même chose avec une option :

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

Le conserver chargé par défaut avec OLLAMA_KEEP_ALIVE

Le serveur lit OLLAMA_KEEP_ALIVE au démarrage et l’utilise pour tous les modèles qui n’ont pas leur propre valeur. Ce paramètre accepte les mêmes formats que le champ de la requête. 30m, 3600 et -1 fonctionnent donc tous.

Le point important concerne l’environnement dans lequel la variable doit être définie. Exécuter export OLLAMA_KEEP_ALIVE=30m dans votre session SSH ne change rien, car l’installation empaquetée exécute le serveur comme un service systemd, avec son propre utilisateur et son propre environnement. Votre shell de connexion et ce service n’utilisent pas le même environnement. C’est la raison la plus fréquente pour laquelle le paramètre semble ignoré.

Rendre le réglage 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 que vous écrivez 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 par le paquet. Une mise à niveau du paquet Ollama qui remplace ollama.service ne modifie donc pas votre réglage. Si les drop-ins et les fichiers d’unité sont nouveaux pour vous, le guide des services et des 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 avec lequel le service s’exécutera réellement. 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 chargés. La requête suivante doit donc les charger à froid. Réchauffez le service avec l’appel de préchargement ci-dessus.

Ce que coûte le maintien d’un modèle en mémoire

La colonne SIZE de ollama ps correspond à la mémoire occupée pendant toute la fenêtre d’inactivité, et pas uniquement pendant une requête. Un modèle 8B avec une quantification sur 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 tâches de build.

Surveillez les valeurs réelles au lieu de vous fier à une estimation. Exécutez cette commande pendant qu’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 la même situation dans la VRAM. Si le serveur n’a plus de mémoire disponible, le kernel tue un processus pour en récupérer :

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

Une ligne qui mentionne ollama indique que le model server a été la victime. Une ligne qui mentionne votre base de données indique que le modèle a pris le dessus et qu’un service important a été sacrifié. Ces deux situations résultent de la même décision : définir une longue fenêtre de keep-alive sur un serveur sans marge de mémoire.

Deux coûts sont faciles à manquer. Une longueur de contexte plus élevée réserve un cache KV plus important (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. 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 personnes avec un seul modèle, dimensionnez la mémoire pour les slots, et pas uniquement pour les poids.

Une valeur raisonnable par défaut : un modèle sur un serveur disposant d’une marge suffisante peut utiliser -1. Un serveur partagé devrait utiliser 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 cessez 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. Si le nom indiqué n’est pas chargé, elle renvoie couldn't find model "qwen3:8b" to stop. La forme API est une requête sans prompt, 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. Depuis août 2026, la valeur par défaut est de trois modèles par GPU, ou de trois modèles sur une machine équipée uniquement d’un CPU. Cette limite porte sur le nombre de 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’expiration n’est pas écoulé, notamment un modèle chargé avec -1. Ainsi, une valeur négative pour keep_alive signifie qu’aucun délai d’inactivité n’est appliqué. Cela ne réserve pas les poids du modèle contre les demandes d’un autre modèle.

Cette décision est enregistrée au niveau de 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

Un message 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 peuvent pas tenir simultanément sur cette machine. La solution consiste à exécuter moins de modèles sur ce serveur, ou à définir une fenêtre longue pour celui qui doit répondre rapidement et 0 pour celui que vous appelez rarement.

Des conseils qui restent valables au-delà de la prochaine release

Ollama publie régulièrement de nouvelles versions et ses valeurs par défaut évoluent. Vérifiez donc le build utilisé 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 le build, notamment OLLAMA_KEEP_ALIVE. Deux règles restent valables d’une release à l’autre et peuvent servir de base. Une valeur définie dans la requête prend le pas sur la valeur par défaut du serveur. Et ollama ps indique ce qui est réellement chargé, quelle que soit la configuration déclarée dans un fichier.

Si un éditeur ou un agent pilote votre serveur, vérifiez ce que ce client envoie avant d’incriminer le serveur. Configurer un agent de développement pour utiliser 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 correspondent à 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 les recharge depuis le disque, ce qui provoque la pause que vous ressentez. Augmentez cette valeur pour une 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 en permanence un modèle Ollama chargé en mémoire ?

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é alors que la mémoire est insuffisante, le scheduler décharge tout de même celui-ci pour libérer de la place.

Pourquoi OLLAMA_KEEP_ALIVE est-elle ignorée ?

Vérifiez 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, ce qui 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 "done_reason": "unload". Vérifiez avec ollama ps : le modèle ne devrait plus apparaître dans la liste.