Ollama pull ou run : où sont stockés les modèles ?

ollama pull par rapport à ollama run

ollama pull télécharge un modèle, puis s’arrête. ollama run télécharge le modèle uniquement s’il est absent, le charge en mémoire, puis ouvre un chat interactif. Le téléchargement est identique et les fichiers sont enregistrés au même emplacement. Seul run poursuit son exécution.

Cette différence détermine la commande à utiliser dans un script et celle à utiliser depuis un terminal.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

La première ligne récupère le modèle, puis se termine. Elle peut donc être utilisée sans risque lors du provisioning ou dans une unité systemd. La deuxième ouvre une session de chat ; saisissez /bye ou appuyez sur Ctrl+D pour la quitter. La troisième envoie un prompt unique, affiche la réponse, puis se termine. C’est la forme adaptée à un script qui a besoin d’une réponse plutôt que d’une session. Les noms de modèles évoluent rapidement. Considérez donc gemma4 comme un espace réservé dans cet exemple : il s’agit de l’exemple utilisé par la documentation officielle d’Ollama en août 2026, et n’importe quel tag de la library se comporte de la même manière.

Pourquoi le premier ollama run semble bloqué

Un premier run sur un VPS vierge peut rester plusieurs minutes sans afficher de sortie. Rien n’est défectueux. L’invite de chat ne peut pas apparaître tant que le modèle n’est pas enregistré sur le disque et chargé en mémoire. run effectue donc un téléchargement de plusieurs gigaoctets avant de pouvoir afficher quoi que ce soit.

Deux éléments masquent cette activité. Ollama n’affiche sa barre de progression que lorsque sa sortie est un terminal. Ainsi, un run exécuté dans un script shell, une tâche cron, une étape CI ou un simple ssh host ollama run ... n’affiche rien pendant le téléchargement. Ensuite, une fois les octets téléchargés, le fichier doit encore être lu depuis le disque et chargé en RAM avant l’émission du premier token. Sur un petit VPS, cette lecture est lente. Si la machine ne dispose pas de suffisamment de mémoire pour le modèle, le kernel commence à utiliser le swap et l’attente s’allonge fortement.

Surveillez l’opération depuis une deuxième session au lieu de supposer qu’elle est bloquée :

df -h /
watch -n5 df -h /

Une baisse de l’espace libre par paliers indique que le téléchargement est toujours en cours. Si l’espace libre cesse de diminuer alors que la commande est toujours active, le téléchargement est terminé et le chargement en mémoire a commencé.

C’est l’argument en faveur d’un téléchargement préalable. La personne qui saisit ollama run ne devrait jamais être celle qui attend la fin du téléchargement.

Récupérer le modèle avant la première requête

Sur une nouvelle machine, utilisez le même script que celui qui installe le serveur pour récupérer le modèle :

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

Si vous installez le serveur pour la première fois, l’installation complète d’Ollama sur un VPS couvre le service lui-même et les personnes autorisées à y accéder. Ensuite, configurez une récupération qui continue après la fermeture de votre terminal. Un téléchargement interrompu en cours de route peut laisser le magasin de modèles partiellement rempli.

Exécutez-la dans tmux ou confiez-la à systemd sous la forme d’une unité one-shot exécutée au démarrage. Écrivez /etc/systemd/system/ollama-pull.service :

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Les deux commandes passent volontairement par /bin/sh -c. Un ExecStart= seul nécessite un chemin absolu, et l’installateur ne place pas toujours le binaire dans le même répertoire. Sur votre machine, command -v ollama est donc la seule réponse fiable. Le passage par le shell utilise le PATH du service plutôt qu’un chemin copié depuis un guide. Le premier ExecStart est également important : After=ollama.service signifie que l’unité du serveur a été démarrée, mais pas qu’elle est prête. La boucle attend donc que ollama list réponde avant de commencer la récupération.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

Le journal doit indiquer que la récupération s’est terminée sans erreur, puis ollama list doit afficher le modèle. Pour maintenir à jour un tag qui évolue, ajoutez un timer systemd ou une entrée cron hebdomadaire qui exécute la même récupération. Récupérer à nouveau un tag qui a évolué télécharge les nouvelles couches et laisse les anciennes sans référence. Elles sont supprimées au prochain démarrage du serveur.

Ce qui se passe lorsqu’un pull est interrompu

Chaque layer d’un modèle est stocké sous un hash correspondant à son propre contenu. Un pull interrompu ne représente donc pas du travail perdu : relancez la même commande ollama pull. Les layers déjà terminés sont reconnus et ignorés. Le téléchargement reprend avec le layer qui a été interrompu.

Une action détruit cette progression. Au démarrage du serveur Ollama, les layers stockés qui ne sont référencés par aucun manifest de modèle sont supprimés. Le layer partiel laissé par un pull interrompu correspond exactement à ce cas. Redémarrer le service avant de réessayer supprime donc la partie déjà téléchargée. Réessayez d’abord le pull, puis redémarrez le service. Si un téléchargement partiel doit réellement survivre à un redémarrage, définissez OLLAMA_NOPRUNE=1 dans l’environnement du service, puis supprimez cette variable ensuite. Ce nettoyage au démarrage empêche les layers orphelins de s’accumuler sur le disque.

Si le pull s’est arrêté avec no space left on device, libérez de l’espace avant de réessayer. Si df signale que le disque est plein et que du sur le répertoire du modèle ne l’explique pas, l’espace est utilisé ailleurs. Consultez les raisons pour lesquelles df et du donnent des résultats différents avant de supprimer quoi que ce soit.

Où Ollama stocke-t-il les modèles sur un VPS ?

Interrogez votre propre serveur au lieu de faire confiance à un chemin indiqué dans un guide, y compris celui-ci. L’emplacement diffère entre une installation par paquet et un conteneur. Il change également si quelqu’un a défini OLLAMA_MODELS.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat affiche le fichier d’unité avec tous les drop-ins. Une ligne OLLAMA_MODELS définie par vos soins ou intégrée à votre image apparaît donc à cet endroit. En l’absence d’une telle ligne, le store se trouve sous le répertoire personnel du compte utilisé pour exécuter le service. getent passwd affiche ce répertoire personnel dans le sixième champ séparé par des deux-points. find recherche le répertoire blobs dans un seul système de fichiers. C’est là que les layers sont réellement écrites. Supprimez -xdev si les modèles se trouvent peut-être déjà sur un mount séparé.

Mesurez maintenant et interprétez vos propres résultats :

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

Le store comporte deux parties. manifests contient un petit fichier pour chaque model tag. Ce fichier répertorie les layers à partir desquelles le tag est construit. blobs contient les layers elles-mêmes. Chacune porte le hash de son contenu, et la quasi-totalité de l’espace utilisé se trouve là. Comme les layers sont partagées entre les tags, deux modèles construits à partir des mêmes weights indiquent chacun leur taille dans ollama list, alors que cet espace n’est occupé qu’une seule fois sur le disque. La somme des tailles indiquées peut donc dépasser la taille renvoyée par du pour le répertoire.

Les fichiers de modèles remplissent un petit système de fichiers root plus rapidement que tout autre élément que vous installerez probablement. Le format des weights est le principal facteur qui détermine leur taille. Choisir entre q4, q8 et fp16 peut faire économiser plusieurs gigaoctets par modèle.

Déplacer les modèles vers un volume de données avec OLLAMA_MODELS

Si le serveur doit recevoir un second disque ou un volume de données plus volumineux, déplacez le store avant de remplir le système de fichiers racine. Arrêtez d’abord le serveur afin de ne pas copier un fichier encore en cours d’écriture.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit ouvre un éditeur sur un fichier drop-in. L’unité fournie par le paquet reste ainsi intacte et une mise à niveau du paquet ne peut pas écraser votre modification. Ajoutez ces deux lignes :

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show doit afficher votre nouveau chemin, et ollama list doit afficher les mêmes modèles qu’avant le déplacement. Une liste vide signifie que le serveur ne peut pas lire le nouveau répertoire. Le service s’exécute avec l’utilisateur ollama. Cet utilisateur doit donc disposer des droits de lecture et d’écriture sur la destination, ce que fait la ligne chown ci-dessus. Consultez journalctl -e -u ollama pour rechercher les erreurs de permissions mentionnant le nouveau chemin. Ne supprimez l’ancienne copie qu’une fois la liste correcte, car un déplacement ayant échoué suivi de la suppression de la source vous obligerait à tout télécharger de nouveau.

L’autre option conserve le chemin d’origine et monte le volume de données dessus :

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

Si findmnt affiche le mount, le bind est actif. Un bind mount est utile lorsqu’un autre élément du serveur attend déjà l’emplacement par défaut. Il présente toutefois un piège : les fichiers que vous avez copiés se trouvent toujours sous le point de montage sur le disque racine, masqués par le montage. L’espace ne sera donc pas récupéré tant que vous n’aurez pas démonté le volume et supprimé ces fichiers. La variable d’environnement est l’option la plus simple à expliquer à la personne qui se connectera ensuite.

Où le conteneur les conserve réellement

L’image officielle stocke les modèles dans le volume que vous montez, et non dans un répertoire de l’hôte appartenant à un utilisateur ollama. La commande documentée est :

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama avant les deux-points est un volume Docker nommé, et /root/.ollama est le chemin d’écriture du serveur dans le conteneur. Ainsi, du exécuté sur les chemins de la section précédente ne trouve rien, car les modèles ne s’y trouvent pas. Affichez l’emplacement réel et sa taille :

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Lisez le champ Mountpoint dans docker volume inspect, puis exécutez sudo du -sh sur cette valeur. Pour stocker les modèles dans un volume de données, remplacez le volume nommé par un répertoire de l’hôte (-v /mnt/data/ollama:/root/.ollama), puis recréez le conteneur. Le conteneur écrit en tant que root ; le répertoire de l’hôte appartient donc à root. Avec Podman rootless, les identifiants sont plutôt mappés dans la plage de subuid de votre utilisateur. La propriété du répertoire sur l’hôte apparaît donc encore différemment : exécuter Ollama avec Podman rootless explique ce mappage.

Attention au nettoyage. docker volume prune supprime tous les volumes auxquels aucun conteneur ne fait référence. Si vous supprimez ou recréez le conteneur ollama sans son volume, un prune exécuté ultérieurement supprime tous les modèles téléchargés, sans possibilité de les récupérer autrement qu’en les téléchargeant de nouveau. Consultez comment réduire l’espace disque utilisé par Docker sur un VPS avant d’exécuter prune sur un serveur qui héberge des modèles.

Supprimez un modèle avec ollama rm, pas avec rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rmsupprime le manifest associé à ce tag, puis les layers auxquels aucun manifest restant ne fait référence. L’espace est de nouveau disponible dès que ces fichiers sont désalloués, et df se termine donc immédiatement. Comme les layers sont partagés, la suppression de l’un de deux tags proches peut libérer beaucoup moins d’espace que la taille ollama list affichée à côté. C’est le comportement attendu, pas un échec de la suppression.

Supprimer des fichiers manuellement rompt cette association. Supprimez un blob avec rm : le manifest le référence toujours, donc ollama list continue d’afficher le modèle, et toute tentative de l’utiliser échoue lors de la lecture du layer manquant. Supprimez un manifest manuellement : ses layers restent sur le disque sans aucun élément qui les référence et occupent de l’espace qu’aucune commande Ollama ne vous indiquera. Si vous l’avez déjà fait, ollama rm sur le tag supprime l’entrée résiduelle, et le redémarrage du serveur supprime les layers auxquels plus rien ne fait référence.

Une dernière distinction est nécessaire, car ces deux opérations sont souvent confondues. ollama rm concerne le disque. ollama stop gemma4 décharge un modèle de la mémoire et ne libère aucun espace disque. La durée pendant laquelle un modèle reste résident en RAM une fois le téléchargement terminé est définie séparément. La section conserver un modèle chargé au lieu de le recharger à chaque requête l’explique.

FAQ

Quelle est la différence entre ollama pull et ollama run ?

ollama pull télécharge un modèle sur le disque, puis se termine. ollama run vérifie si le modèle est déjà présent sur le disque, le télécharge s’il ne l’est pas, le charge en mémoire, puis ouvre une session de chat interactive. Les deux commandes écrivent les mêmes fichiers dans le même répertoire. Utilisez pull pour le provisioning et dans les scripts, et run lorsqu’une personne utilise le clavier. ollama run <model> "your prompt" envoie un prompt, puis se termine. C’est la forme scriptable de run.

Pourquoi mon premier ollama run semble-t-il bloqué ?

Le modèle est en cours de téléchargement. Le prompt de chat ne peut pas s’afficher tant que le modèle n’est pas présent sur le disque et chargé en mémoire. Un modèle occupe plusieurs gigaoctets. Ollama affiche sa barre de progression uniquement lorsque la sortie est un terminal. Ainsi, un run exécuté dans un script, une tâche cron ou un ssh host ollama run ... n’affiche absolument rien pendant l’opération. Ouvrez une deuxième session et exécutez watch -n5 df -h /. Une baisse progressive de l’espace libre indique que le téléchargement est en cours. Téléchargez le modèle à l’avance pour supprimer cette attente.

Où Ollama stocke-t-il ses modèles ?

L’emplacement dépend de l’installation. Affichez-le au lieu de le supposer. Exécutez systemctl cat ollama.service pour vérifier si OLLAMA_MODELS est défini dans l’unité ou dans un drop-in. Si ce n’est pas le cas, le store se trouve dans le répertoire personnel du compte utilisé par le service, que getent passwd ollama affiche. sudo find / -xdev -type d -name blobs 2>/dev/null localise directement le répertoire des layers. Pour l’image de conteneur, le store se trouve dans le volume monté, et docker volume inspect ollama affiche son Mountpoint côté hôte.

Comment déplacer les modèles Ollama vers un autre disque ?

Arrêtez le service, copiez le store vers le nouvel emplacement avec rsync -a, attribuez le répertoire au compte de service avec sudo chown -R ollama:ollama <directory>, puis exécutez sudo systemctl edit ollama.service et ajoutez Environment="OLLAMA_MODELS=<directory>" sous une ligne [Service]. Rechargez la configuration avec sudo systemctl daemon-reload, puis redémarrez. Vérifiez avec systemctl show ollama --property=Environment et ollama list. Une liste vide signifie presque toujours que l’utilisateur ollama ne peut pas lire le nouveau répertoire. journalctl -e -u ollama indiquera le chemin.

La suppression des fichiers de modèle libère-t-elle l’espace disque ?

La suppression manuelle des fichiers libère les octets, mais laisse le store dans un état incohérent. Si vous supprimez un blob, le manifest continue de référencer le modèle. Celui-ci continue donc d’apparaître dans ollama list et échoue lors de son utilisation. Si vous supprimez un manifest, ses layers restent sur le disque sans être référencés. Utilisez ollama rm <model>. Cette commande supprime le manifest, puis les layers dont aucun autre modèle n’a besoin. Si des fichiers ont déjà été supprimés manuellement, exécutez ollama rm sur le tag pour supprimer l’entrée, puis redémarrez le serveur. Celui-ci supprime les layers référencés par aucun manifest.