#Les symptômes typiques

Ollama tombe rarement en panne franche : le plus souvent il « marche », mais mal. Le daemon écoute bien sur http://localhost:11434, le modèle répond, mais quelque chose cloche. Savoir reconnaître le symptôme oriente déjà vers la bonne famille de causes.

Réponses très lentes: Quelques tokens par seconde alors qu'on attend des dizaines : le modèle tourne probablement sur le CPU, GPU non détecté ou non utilisé.
GPU à 0 % d'activité: nvidia-smi ou rocm-smi montrent une carte inactive pendant la génération : Ollama ne l'a pas prise en charge.
Erreur out of memory: Le chargement échoue ou le modèle est expulsé avec un message CUDA/HIP « out of memory » : le modèle ou son contexte dépasse la VRAM.
Lenteur soudaine après une mise à jour: Un débit qui s'effondre du jour au lendemain pointe vers un driver, une version d'Ollama ou un conflit CUDA/ROCm.
Offload partiel: Une partie des couches sur GPU, le reste sur CPU : ça fonctionne mais bien plus lentement qu'un offload complet.

#Vérifier que le GPU est vraiment utilisé

Avant de chercher une solution, il faut établir un fait : Ollama utilise-t-il le GPU, oui ou non ? La commande la plus directe est ollama ps, qui affiche les modèles chargés et surtout la répartition entre CPU et GPU pendant qu'un modèle est en mémoire.

Terminal — état des modèles chargés

# Charger un modèle puis, dans un autre terminal, l'interroger
ollama run llama3.1:8b "bonjour"

# Pendant que le modèle est en mémoire, vérifier la répartition
ollama ps

La colonne PROCESSOR est la clé. « 100% GPU » signifie que tout le modèle est sur la carte — c'est ce qu'on veut. « 100% CPU » confirme un fallback complet. Un « 60%/40% CPU/GPU » indique un offload partiel : le modèle ne tient pas entièrement en VRAM.

Lire la colonne PROCESSOR

ollama ps n'affiche la répartition que tant qu'un modèle est chargé en mémoire. Par défaut Ollama décharge un modèle après 5 minutes d'inactivité (keep_alive) — lancez la commande juste après une génération.

Pour croiser l'information, surveillez le GPU côté constructeur pendant une génération. Si l'utilisation grimpe, le GPU travaille ; s'il reste à zéro, Ollama l'ignore.

Terminal — surveiller le GPU

# NVIDIA : rafraîchissement toutes les secondes
nvidia-smi -l 1

# AMD (ROCm)
rocm-smi

# Vue plus lisible et interactive (si installé)
nvtop

#Lire les logs d'Ollama

Les logs du serveur disent exactement quel backend a été chargé et pourquoi un GPU a été retenu ou écarté. C'est la source de vérité quand ollama ps et nvidia-smi se contredisent.

Terminal — consulter les logs

# Linux (service systemd)
journalctl -u ollama -f

# macOS / lancement manuel : les logs vont sur la sortie du serveur
# Relancer le daemon en verbeux pour tout voir
OLLAMA_DEBUG=1 ollama serve

Cherchez les lignes qui mentionnent « inference compute », « library=cuda » ou « library=rocm », et le nombre de couches offloadées (« offloaded X/Y layers to GPU »). Si vous voyez « no compatible GPUs were discovered » ou « library=cpu », vous tenez la cause : Ollama n'a détecté aucun GPU exploitable.

→

Le message qui compte

La ligne « offloaded N/M layers to GPU » vous dit tout : N=M c'est parfait, N<M c'est un offload partiel (VRAM insuffisante), N=0 c'est du CPU pur. Repartez toujours de cette ligne pour diagnostiquer.

#Le fallback CPU et ses causes classiques

Quand Ollama n'arrive pas à utiliser le GPU, il ne plante pas : il bascule silencieusement sur le CPU. C'est le comportement le plus déroutant car « tout marche », en apparence. Voici les causes les plus fréquentes, de la plus banale à la plus subtile.

01
VRAM insuffisante pour le modèle
Si le modèle (poids + contexte) dépasse la VRAM libre, Ollama offload une partie sur CPU, voire tout. Un 14B en Q4 réclame ≈9 Go, un 32B ≈19 Go : sur une carte 12 Go, le 32B ne tiendra jamais entièrement.
02
Driver GPU absent ou trop ancien
Sans driver NVIDIA récent (ou ROCm côté AMD), Ollama ne voit aucun GPU compatible et repart sur CPU. C'est la cause n°1 d'un « ollama gpu non détecté ».
03
GPU occupé par un autre processus
Un autre modèle, un jeu, un notebook Python ou une autre instance Ollama peut déjà saturer la VRAM. nvidia-smi liste les processus et la mémoire consommée.
04
Ollama dans un conteneur sans passthrough GPU
En Docker, sans --gpus all (NVIDIA) ou les devices ROCm exposés, le conteneur ne voit pas la carte. Le daemon fonctionne, mais en CPU.
05
GPU non supporté
Cartes trop anciennes (capacité de calcul CUDA insuffisante) ou GPU AMD hors de la liste ROCm officielle : Ollama les ignore volontairement.

Terminal — qui occupe la VRAM ?

# Voir les processus et la mémoire GPU consommée
nvidia-smi

# Repérer d'autres instances Ollama qui tourneraient déjà
ps aux | grep ollama

Docker et le GPU

Un conteneur Ollama qui tourne en CPU alors que la machine hôte a un GPU vient presque toujours d'un passthrough manquant. Vérifiez le flag --gpus all et l'installation du NVIDIA Container Toolkit sur l'hôte.

#Erreurs out of memory : les lire et les résoudre

Un message « CUDA error: out of memory » (ou « HIP out of memory » sur AMD) signifie que le modèle demande plus de VRAM que disponible. Deux leviers gonflent cette demande : la taille du modèle et la fenêtre de contexte. Réduire l'un ou l'autre résout la plupart des cas.

Modèle trop gros: Passez à une quantification plus légère (Q4_K_M au lieu de Q5/Q8) ou à un modèle plus petit. Repère Q4 : 7B≈5 Go · 14B≈9 Go · 32B≈19 Go · 70B≈40 Go.
Contexte trop long: Un grand num_ctx multiplie la mémoire du cache KV. Réduire la fenêtre de contexte (num_ctx) libère beaucoup de VRAM, surtout sur les gros modèles.
VRAM fragmentée par un autre process: Fermez jeux, notebooks et autres modèles. Redémarrez le daemon Ollama pour repartir sur une VRAM propre.
Mémoire résiduelle: Un modèle précédent encore chargé occupe la VRAM. ollama stop <modèle> le décharge immédiatement au lieu d'attendre le keep_alive.

Terminal — réduire la pression mémoire

# Décharger un modèle tout de suite
ollama stop llama3.1:70b

# Lancer avec un contexte réduit (via l'API ou un Modelfile)
# Exemple : forcer num_ctx à 4096 au lieu de la valeur par défaut
ollama run llama3.1:8b
# puis dans le prompt interactif :
# /set parameter num_ctx 4096

→

Estimer avant de charger

Additionnez la taille du modèle (selon sa quantification) et une marge pour le contexte. Visez à rester sous ~90 % de votre VRAM totale : au-delà, l'offload partiel ou l'OOM guettent. Sur une RTX 4090 24 Go, un 32B Q4 (≈19 Go) passe ; un 70B Q4 (≈40 Go) non.

#Drivers NVIDIA/AMD, CUDA et ROCm à jour

Beaucoup de problèmes « ollama gpu non détecté » se règlent en mettant la couche driver à niveau. Ollama embarque ses propres bibliothèques CUDA/ROCm, mais il dépend du driver du système pour parler au matériel.

Terminal — vérifier le driver NVIDIA

# Doit afficher la version du driver et CUDA
nvidia-smi

# Si la commande échoue : le driver n'est pas installé ou pas chargé
# Vérifier que le module noyau est bien chargé (Linux)
lsmod | grep nvidia

Côté AMD, l'installation ROCm est plus exigeante : la carte doit figurer dans la liste des GPU supportés, et il faut parfois exporter une variable pour forcer la prise en charge d'une architecture proche (HSA_OVERRIDE_GFX_VERSION). Vérifiez d'abord que rocminfo voit bien le GPU.

Terminal — vérifier ROCm (AMD)

# Le GPU doit apparaître dans la liste des agents
rocminfo | grep -i gfx

# État et mémoire du GPU AMD
rocm-smi

# Forcer une architecture proche si la carte n'est pas officiellement listée
export HSA_OVERRIDE_GFX_VERSION=11.0.0

Après une mise à jour de driver, redémarrez le service

Un nouveau driver n'est pris en compte qu'après rechargement du module noyau — le plus sûr est de redémarrer la machine, puis le service Ollama (sudo systemctl restart ollama). Un daemon lancé avant la mise à jour continue de voir l'ancien état.

#Lenteurs soudaines

Un débit qui était bon puis chute brutalement a presque toujours une cause identifiable. Contrairement au fallback CPU permanent, la lenteur soudaine trahit un changement récent d'état.

Offload partiel nouvellement apparu: Vous avez augmenté le contexte ou chargé un modèle plus gros : une partie bascule sur CPU. Vérifiez ollama ps et la ligne « offloaded N/M layers ».
Throttling thermique: Un GPU qui chauffe réduit sa fréquence. nvidia-smi affiche la température et l'état « P-State » ; au-delà de ~83 °C, la carte throttle.
Mise à jour d'Ollama ou du driver: Une régression peut ralentir l'inférence. Notez la version qui marchait (ollama --version) avant de mettre à jour, pour pouvoir revenir en arrière.
VRAM partagée / mémoire système: Sous Windows, quand la VRAM déborde, le driver peut utiliser la RAM système (mémoire GPU partagée), ce qui écroule les performances. Réduisez le modèle plutôt que de laisser déborder.
Rechargement à chaque requête: Un keep_alive trop court recharge le modèle sans cesse. Augmentez OLLAMA_KEEP_ALIVE si vous enchaînez les requêtes.

Terminal — température et fréquence

# Surveiller température, conso et fréquence en continu
nvidia-smi -l 1

# Garder les modèles chargés plus longtemps (ex : 30 min)
export OLLAMA_KEEP_ALIVE=30m
sudo systemctl restart ollama

#Checklist de diagnostic

Quand quelque chose cloche, déroulez ces étapes dans l'ordre : elles vont du plus fréquent au plus rare et évitent de partir dans une mauvaise direction.

01
1. Confirmer le symptôme
ollama ps pendant une génération : la colonne PROCESSOR indique-t-elle CPU, GPU ou un mélange ?
02
2. Vérifier que le GPU existe pour le système
nvidia-smi (ou rocm-smi) répond-il ? Sinon, le problème est au niveau du driver, pas d'Ollama.
03
3. Lire les logs
journalctl -u ollama -f (ou OLLAMA_DEBUG=1 ollama serve) : chercher « library=cuda/rocm/cpu » et « offloaded N/M layers ».
04
4. Vérifier la VRAM disponible
nvidia-smi : un autre process occupe-t-il la carte ? Le modèle rentre-t-il dans la VRAM libre ?
05
5. Réduire la charge si OOM ou offload partiel
Quantification plus légère, modèle plus petit, ou num_ctx réduit. Décharger les modèles inutilisés avec ollama stop.
06
6. Mettre à jour et redémarrer
Driver + Ollama à jour, puis redémarrer le service (et la machine après un changement de driver).

Isoler avant de corriger

La règle d'or : ne changez qu'une chose à la fois et revérifiez avec ollama ps. Modifier driver, contexte et modèle en même temps rend impossible d'identifier ce qui a réellement résolu — ou aggravé — le problème.

#Pour aller plus loin

Une fois le GPU correctement détecté, ces guides du site aident à tirer le maximum de votre configuration et à éviter que les problèmes ne reviennent :

Choisir sa quantification (Q4, Q5, Q8, FP16): Le levier n°1 contre les erreurs mémoire : comprendre le compromis qualité/VRAM pour choisir un format qui tient dans votre carte.
Faire tourner un LLM en local sans GPU (CPU only): Si votre matériel ne permet pas l'offload GPU, ce guide montre comment rester utilisable en CPU pur et quels modèles choisir par RAM.
Installer Ollama : Windows, macOS et Linux: Revoir l'installation propre du daemon et des drivers, souvent la vraie source d'un GPU non détecté.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Premiers pas · 9 min

Dépanner Ollama : GPU non détecté, lenteurs, erreurs mémoire