Ollama ne fonctionne pas ? 9 erreurs, le message exact et la solution

Quand Ollama plante, son journal dit le plus souvent pourquoi. Voici neuf pannes et leur solution : port 11434 déjà pris, client qui ne trouve pas le serveur, modèle coincé sur le processeur, carte NVIDIA ou AMD introuvable, mémoire saturée quand le contexte grandit, première réponse interminable, téléchargements ou dossiers récalcitrants.

Faire tourner un modèle sur sa propre machine, c’est un vrai plaisir… jusqu’au moment où, à la place d’une réponse, s’affiche une erreur. Bonne nouvelle : les messages d’Ollama sont courts, plutôt francs, et chacun renvoie à une cause précise. Vous trouverez ci-dessous, pour chaque problème, le texte exact qui apparaît, son origine et la solution sur Mac, Windows et Linux, avec les commandes de la version stable actuelle, la 0.40.10 (publiée le 23 octobre 2026). Chaque message d’Ollama cité ici a été revérifié dans le code et la documentation de chaque version stable depuis la 0.40.0, la dernière fois sur la 0.40.10, le 24 octobre 2026, et aucun n’a changé ; ce qu’apporte la 0.40.0, c’est une colonne RUNNER dans ollama ps et MLX par défaut sur les Mac Apple Silicon, et les parties où cela compte le signalent. L’installation, la vérification du serveur et la façon de lui passer des variables d’environnement sont dans notre guide pour démarrer Ollama en local ; cette page prend le relais là où il s’arrête.

OllamaFiche logiciel→

D’abord, lisez le journal

L’erreur affichée dans le terminal, c’est le titre ; le journal (le log), c’est l’article entier. Il se trouve ici :

# macOS
cat ~/.ollama/logs/server.log

# Linux (service systemd)
journalctl -u ollama --no-pager --follow --pager-end

# Docker
docker logs <nom-du-conteneur>

# Windows : ouvre le dossier qui contient server.log (l'actuel)
# et server-#.log (les précédents)
explorer %LOCALAPPDATA%\Ollama

Si vous avez lancé ollama serve à la main, le journal s’affiche dans ce même terminal. Pour plus de détail, OLLAMA_DEBUG=1 le passe en niveau débogage et OLLAMA_DEBUG=2 en niveau trace. La manière de transmettre cette variable à l’application ou au service dépend du système ; tout est expliqué pas à pas dans le guide d’installation. Sous Windows, le plus rapide : quitter l’application depuis la zone de notification, puis, dans PowerShell :

$env:OLLAMA_DEBUG="1"; & "ollama app.exe"

Si vous préférez voir la manœuvre avant de la faire, cette courte vidéo montre comment consulter les journaux quand Ollama ne répond plus. Elle est en anglais ; là où elle diffère de cette page, c’est la version 0.40.10 qui fait foi.

« bind: address already in use » sur le port 11434

Vous tapez ollama serve, et voici la réponse :

Error: listen tcp 127.0.0.1:11434: bind: address already in use

C’est la formulation de Linux ; sur d’autres systèmes, la fin peut varier. Le sens, lui, ne change pas : un serveur Ollama tourne déjà. Sous macOS et Windows, l’application de bureau lance ollama serve toute seule, et sous Linux l’installateur laisse actif un service systemd nommé ollama. Deux serveurs pour un seul port : c’est la chaise musicale, avec une seule chaise.

La plupart du temps, inutile de lancer ollama serve. Vérifiez plutôt que celui qui tourne déjà répond :

curl http://127.0.0.1:11434
Ollama is running

Si vous tenez vraiment à votre propre serveur au premier plan, par exemple pour suivre sa sortie en direct, arrêtez d’abord l’autre : sudo systemctl stop ollama sous Linux, ou quittez l’application depuis la barre des menus (Mac) ou la zone de notification (Windows). Autre solution : lui donner un autre port, et pointer vos clients vers cette même adresse :

OLLAMA_HOST=127.0.0.1:11435 ollama serve

Sous Linux, cette commande indique quel processus occupe le port :

sudo ss -ltnp | grep 11434

« could not connect to ollama server »

Le cas inverse : la commande est installée, mais aucun serveur n’écoute.

Error: could not connect to ollama server, run 'ollama serve' to start it

ollama -v annonce la même nouvelle avec plus de douceur : Warning: could not connect to a running Ollama instance. Sous Linux, la ligne de commande ne démarre jamais de serveur d’elle-même : le message signifie simplement que le service est arrêté. Sous macOS et Windows, elle essaie d’abord d’ouvrir l’application, et l’erreur n’apparaît que si elle n’y parvient pas.

# Linux
sudo systemctl start ollama
sudo systemctl status ollama

Sur un Mac ou un PC Windows, ouvrez l’application Ollama. Si le serveur se trouve sur une autre machine ou un autre port, le client a besoin du même OLLAMA_HOST que le serveur ; sans lui, il frappe à la porte de 127.0.0.1:11434 et personne n’ouvre.

Tourne-t-il sur le GPU ? Regardez la colonne PROCESSOR

Un modèle qui répond au ralenti est souvent un modèle qui n’est pas sur la carte graphique. Les ventilateurs de votre portable vous préviendront avant n’importe quelle commande, mais ollama ps le dit avec des chiffres. Ses colonnes sont NAME, ID, SIZE, PROCESSOR, CONTEXT, RUNNER (nouvelle dans la 0.40.0 : llamacpp ou mlx) et UNTIL, et c’est PROCESSOR qui compte :

• 100% GPU : le modèle est entièrement sur la carte. Tout va bien.
• 100% CPU : il est dans la mémoire système, soit parce que la carte n’a pas été détectée (les deux parties suivantes), soit parce qu’il n’y a pas de carte à utiliser.
• Un partage comme 48%/52% CPU/GPU : le modèle et son contexte ne tenaient pas dans la mémoire de la carte, et une partie tourne sur le processeur.
• Sur un Mac Apple Silicon avec mlx sous RUNNER : 100% GPU, car MLX ne répartit pas un modèle. Si le modèle lui-même ne tient pas dans la mémoire libre, il ne se charge pas, et l’erreur contient model requires … but only … are available.

En cas de partage, trois portes de sortie : réduire le contexte (deux parties plus bas), choisir une compression plus forte ou un modèle plus petit, ou libérer de la mémoire en déchargeant les modèles inutilisés avec ollama stop <modèle>. Le trouveur de modèle vous dit à l’avance quels modèles tiennent sur votre machine, et avec quel contexte.

Carte NVIDIA non détectée

Commencez par les prérequis : ils éliminent beaucoup de cas. Pour la version 0.40.10, Ollama demande une carte NVIDIA de compute capability 5.0 ou plus et un pilote 550 ou plus récent ; les cartes de compute capability 5.0 à 6.2 exigent le pilote 570 ou plus récent. NVIDIA publie la compute capability de chaque carte sur sa page des GPU CUDA.

Si la carte est compatible et qu’Ollama retombe malgré tout sur le processeur, le journal contient en général un code d’erreur : 3 (non initialisé), 46 (périphérique indisponible), 100 (aucun périphérique) ou 999 (inconnu). Procédez dans cet ordre :

# 1. Le pilote doit voir la carte
nvidia-smi

# 2. Vérifier que le module de mémoire unifiée (UVM) est chargé
sudo nvidia-modprobe -u

# 3. Recharger le module de mémoire unifiée (le remède documenté après une mise en veille sous Linux)
sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm

Si rien n’y fait, redémarrez et mettez le pilote à jour. Pour plus de détail, lancez le serveur avec CUDA_ERROR_LEVEL=50 et consultez sudo dmesg | grep -i nvrm. Et si quelqu’un a laissé traîner CUDA_VISIBLE_DEVICES=-1 quelque part, c’est précisément la méthode officielle pour forcer le processeur : supprimez-la.

Sous Docker, docker run --gpus all ubuntu nvidia-smi doit fonctionner avant qu’Ollama puisse voir quoi que ce soit. Si le conteneur démarre sur le GPU puis bascule sur le processeur au bout d’un moment, ajoutez "exec-opts": ["native.cgroupdriver=cgroupfs"] à /etc/docker/daemon.json et redémarrez Docker.

Carte AMD non détectée sous Linux

Avec une carte AMD, deux lignes du journal trahissent le problème :

msg="failure during GPU discovery" ... error="failed to finish discovery before timeout"
msg="bootstrap discovery took" duration=30s

La cause la plus courante est la version du pilote. Ollama 0.40.10 embarque les bibliothèques ROCm 7 ; avec un pilote noyau ROCm 6.x ou plus ancien, la recherche du GPU se bloque et finit sur le processeur. La solution : passer au pilote ROCm 7 avec amdgpu-install, redémarrer la machine, puis Ollama.

L’autre cause, ce sont les droits sur /dev/kfd : l’utilisateur qui fait tourner Ollama doit appartenir au groupe render (sur certains systèmes, video). L’installateur officiel ajoute déjà l’utilisateur ollama aux deux groupes s’ils existent ; après une installation manuelle, faites-le vous-même :

sudo usermod -a -G render ollama

Si ROCm ne prend pas en charge votre carte, vous pouvez la faire passer pour une proche cousine. L’exemple documenté est une RX 5400 (gfx1034) présentée comme une gfx1030 :

HSA_OVERRIDE_GFX_VERSION="10.3.0"

Avec plusieurs cartes, une variable numérotée comme HSA_OVERRIDE_GFX_VERSION_0 le règle carte par carte. L’autre voie est Vulkan, actif par défaut quand son moteur est présent (OLLAMA_VULKAN=0 le désactive) ; pour qu’Ollama lise la vraie mémoire libre via Vulkan, exécutez sudo setcap cap_perfmon+ep /usr/local/bin/ollama. Pour tout voir à la loupe : AMD_LOG_LEVEL=3, OLLAMA_DEBUG=1 et sudo dmesg | grep -i amdgpu.

Mémoire insuffisante quand on augmente le contexte

Le contexte (la quantité de texte que le modèle garde sous les yeux) a un coût en mémoire, le cache KV, et avec llama.cpp (llamacpp dans la colonne RUNNER d’ollama ps) il se paie d’avance, au chargement du modèle. Si vous en demandez trop, Ollama s’arrête avec un message du genre llama-server reported out-of-memory during startup: …, ou un message contenant out of memory, cudaMalloc failed ou hipMalloc failed. Parfois, aucune erreur : le modèle se répartit en silence entre processeur et GPU.

La version 0.40.10 choisit le contexte par défaut selon la mémoire graphique détectée : 4 096 tokens sous 23 Gio, 32 768 à partir de 23 Gio et 262 144 à partir de 47 Gio. Le journal note ce choix sous default_num_ctx. Pour le modifier :

# Pour tout le serveur
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dans une session ollama run
/set parameter num_ctx 8192

# Requête par requête, via l'API
"options": {"num_ctx": 8192}

L’application de bureau propose un curseur pour cela dans ses réglages. Vérifiez le résultat dans la colonne CONTEXT de ollama ps.

Sur un Mac Apple Silicon, avec un modèle qui tourne sur MLX (mlx sous RUNNER), ces réglages fonctionnent autrement : MLX ne réserve pas le contexte au chargement, son cache KV grandit au fil de la conversation, et le chiffre sous CONTEXT ne réserve pas de mémoire et ne coupe rien de la conversation ; le plafond, c’est le contexte maximal du modèle lui-même. La mémoire s’y remplit à mesure que la conversation s’allonge, pas d’un coup au chargement.

Combien ça coûte ? Nous avons fait le calcul avec notre propre outil pour un Mac de 16 Go, qui laisse 13,0 Gio au modèle, en compression Q4_K_M et avec le cache KV en f16, le réglage par défaut d’Ollama :

Mac avec M4 et 16 Go unifiésFiche matériel→

Modèle	4k	8k	32k	64k	De 8k à 32k
Qwen3 8B	5,92 Gio	6,56 Gio	10,38 Gio	15,48 Gio ✗	+3,82 Gio
Gemma 4 12B	7,68 Gio	7,82 Gio	8,65 Gio	9,75 Gio	+0,82 Gio
gpt-oss-20b	11,60 Gio	11,77 Gio	12,78 Gio	14,13 Gio ✗	+1,01 Gio

Mémoire totale nécessaire (fichier du modèle + cache KV + consommation propre du logiciel). Calcul de Local AI Scope du 5 octobre 2026 (la ligne Gemma 4 12B, du 15 octobre 2026) : tailles de fichier mesurées, cache KV calculé d’après l’architecture de chaque modèle, consommation propre estimée. ✗ = ne tient pas dans les 13,0 Gio disponibles.

Sur un Mac Apple Silicon, depuis la 0.40.0, ollama pull gemma4:12b récupère à la place la version MLX (compression NVFP4, 7,18 Gio à télécharger contre 7,47 Gio pour la GGUF), qui paie son contexte au fil de la conversation, comme expliqué plus haut ; la ligne Gemma 4 12B correspond à la version GGUF, celle que reçoivent Windows, Linux et les Mac Intel. Au 7 octobre 2026, Qwen3 8B et gpt-oss-20b n’existent qu’en GGUF et tournent sur llama.cpp, Mac compris.

Cette dernière colonne n’est pas un détail : pour les agents et les tâches de programmation, Ollama recommande un contexte d’au moins 64 000 tokens. Sur une carte graphique de 8 Go, l’histoire se répète plus tôt : Qwen3 8B tient à 4k, de justesse à 8k, et plus du tout à 32k. Le trouveur de modèle fait ce calcul pour votre propre machine.

PC avec RTX 4060 8 GoFiche matériel→

Première réponse lente : le modèle a quitté la mémoire

La première question après la pause café prend une éternité, la suivante file. Ce n’est pas une panne : Ollama garde un modèle en mémoire 5 minutes après sa dernière utilisation, puis le décharge, et la question suivante paie un nouveau chargement. La colonne UNTIL de ollama ps indique le temps qu’il lui reste.

OLLAMA_KEEP_ALIVE côté serveur, ou keep_alive dans chaque requête, change ce délai : une durée comme 10m ou 24h, un nombre de secondes, un nombre négatif pour le garder chargé en permanence, ou 0 pour le décharger dès qu’il a répondu. La valeur de la requête l’emporte sur la variable. Pour précharger un modèle et l’y laisser :

curl http://localhost:11434/api/generate -d '{"model": "llama3.2", "keep_alive": -1}'

Remplacez llama3.2 par votre modèle. Pour libérer la mémoire : ollama stop <modèle>. Si c’est le chargement qui n’en finit pas, le message commence par timed out waiting for llama-server to start : par défaut, il abandonne après 5 minutes sans progrès, et OLLAMA_LOAD_TIMEOUT permet d’allonger ce délai. Avec un modèle sur MLX, le message commence plutôt par timeout waiting for mlx runner, et c’est la même variable qui fixe le délai, mais il porte alors sur tout le chargement, pas seulement sur le temps sans progrès.

Téléchargements bloqués derrière un proxy et droits des dossiers sous Linux

Derrière le proxy de l’entreprise, ollama pull a besoin du proxy dans l’environnement du serveur, pas dans votre terminal :

HTTPS_PROXY=https://proxy.example.com

Elle se définit comme n’importe quelle autre variable du serveur, et le certificat du proxy doit être installé comme certificat système. Sous Docker, passez-la avec -e HTTPS_PROXY=https://proxy.example.com, ou construisez une image qui ajoute le certificat et exécute update-ca-certificates.

Le téléchargement dépasse pulling manifest puis s’arrête ? Vérifiez ollama -v. Jusqu’à la 0.40.5 (depuis la 0.35.0 pour les modèles GGUF), les fichiers du modèle ne passaient pas par ce proxy : Ollama les récupérait directement sur le serveur de téléchargement, après avoir résolu son nom sur la machine elle-même. Sur un réseau où seul le proxy a accès à Internet, le téléchargement échouait donc, avec redirect target not allowed: resolving …: no such host quand la machine ne pouvait pas résoudre ce nom. Depuis la 0.40.6, les fichiers passent eux aussi par le proxy : une mise à jour règle le problème.

Vous avez déplacé vos modèles et plus rien ne se charge ? Par défaut, ils se trouvent dans ~/.ollama/models sous macOS, dans /usr/share/ollama/.ollama/models sous Linux et dans C:\Users\%username%\.ollama\models sous Windows, et OLLAMA_MODELS permet de les déplacer. Sous Linux, le service tourne avec son propre utilisateur, ollama, qui doit pouvoir lire et écrire dans le nouveau dossier :

sudo chown -R ollama:ollama /chemin/vers/vos/modeles

Si ce dossier a grossi depuis la mise à jour, voici pourquoi : dans les versions 0.40.0, 0.40.1 et 0.40.2, un modèle téléchargé avec une version antérieure pouvait être converti pour llama.cpp en arrière-plan la première fois que vous le lanciez, si le disque avait la place pour la copie, et Ollama gardait l’original dans le même dossier en sauvegarde au cas où vous reviendriez à une version antérieure ; les poids d’un modèle converti sont donc deux fois sur le disque. La 0.40.3 a mis cette conversion en pause, et la 0.40.10 ne l’a toujours pas relancée : elle ne se lance plus au chargement d’un modèle, et ce qui a déjà été converti reste sur le disque, copie et sauvegarde comprises. Depuis la 0.40.2, ollama list n’affiche chaque modèle qu’une fois, et les notes de version de la 0.40.2 donnent une commande qui supprime ces sauvegardes (ensuite, revenir à une version antérieure à la 0.40 oblige à retélécharger ces modèles).

Messages, commandes et valeurs par défaut tirés des pages dépannage, FAQ, GPU, Linux et longueur de contexte d’Ollama et de son code source, version 0.40.10, lus le 24 octobre 2026 (première lecture sur la 0.35.1, le 3 octobre 2026) : les messages n’ont pas changé, et la colonne RUNNER comme les remarques sur MLX viennent de la 0.40.0.

Ce qu’Ollama envoie de lui-même pendant que tout cela fonctionne, et comment il se situe face aux autres logiciels : tout est dans sa fiche.