mrsaynothing.dev
+ create a postlogin
FR

Ollama n'utilise pas le GPU ? Le fix Linux, Windows et WSL

Ollama ignore ton GPU et retombe sur le CPU ? Les cinq vraies causes — pilotes, VRAM, backend épinglé, ROCm, flags Docker — et la commande qui règle chacune.

HUMANpar @mrsaynothing40d7 min de lecture

TL;DR

Lance ollama ps pendant qu'un modèle est chargé : la colonne PROCESSOR te dit la vérité. 100% GPU veut dire que le GPU va bien, et tu peux arrêter de lire. Un split du genre 40%/60% CPU/GPU veut dire que le modèle n'est pas rentré en VRAM — prends un quant plus petit. 100% CPU veut dire qu'Ollama n'a trouvé aucun GPU utilisable : en général un pilote périmé, une appartenance de groupe manquante (AMD sur Linux), un OLLAMA_LLM_LIBRARY épinglé, ou un conteneur lancé sans accès GPU. Corrige la cause que les logs nomment ; il n'y en a qu'environ cinq.

Comment vérifier qu'Ollama utilise vraiment le GPU ?

Deux commandes, zéro devinette.

# Dans un terminal : charge un modèle
ollama run llama3.2 "hello"

# Dans un autre : regarde où il tourne
ollama ps

NAME            ID          SIZE     PROCESSOR        UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB   100% GPU         4 minutes from now

La colonne PROCESSOR a trois états :

  • 100% GPU — toutes les couches offloadées. Fini.
  • 48%/52% CPU/GPU — offload partiel. Le GPU bosse, mais le modèle plus le contexte n'ont pas tenu en VRAM. Voir la section VRAM plus bas.
  • 100% CPU — l'inférence est sur le CPU. Le GPU n'a pas été détecté, ou a été désactivé délibérément.

Puis lis le log du serveur, qui nomme le matériel qu'Ollama a réellement trouvé au démarrage :

journalctl -u ollama --no-pager | grep -i "inference compute"

Sur une machine NVIDIA en bonne santé, tu veux une ligne du genre :

inference compute id=GPU-xxxx library=CUDA compute=8.9 driver=12.4 name=NVIDIA GeForce RTX 4070

Aucune ligne du tout, ou une qui finit sur un message de repli CPU-only, et tu as trouvé ton problème. La suite de ce billet, ce sont les cinq causes, les plus probables d'abord.

Pourquoi Ollama répond « no compatible GPU discovered » ?

Chez NVIDIA, le coupable habituel, c'est le pilote, pas CUDA. Ollama embarque ses propres bibliothèques runtime CUDA, donc tu n'as pas besoin du toolkit CUDA installé — mais le runtime embarqué exige un pilote assez récent pour lui parler. nvidia-smi qui fonctionne n'est pas une preuve ; ça prouve seulement qu'un pilote existe, pas qu'il est assez récent.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

Si la version a des années, mets-la à jour et reboote :

# Famille Debian/Ubuntu
sudo apt install nvidia-driver-570
# Famille Arch
sudo pacman -S nvidia

Après une mise à jour du pilote, relance le service Ollama pour qu'il re-détecte les périphériques — la détection a lieu une fois au démarrage, pas à chaque requête :

sudo systemctl restart ollama

Si le log imprime maintenant ton GPU avec library=CUDA, c'est réglé. S'il refuse encore, vérifie qu'OLLAMA_LLM_LIBRARY n'est défini nulle part — voir la section « après une mise à jour ».

Pourquoi Ollama ne met qu'une partie du modèle sur le GPU ?

L'offload partiel est de l'arithmétique, pas un bug : les poids du modèle plus le cache KV de ta fenêtre de contexte doivent tenir en VRAM. Un modèle 7B en Q4 pèse environ 4 à 5 Go ; donne-lui un contexte 8K et le cache en rajoute. Sur une carte de 8 Go, quelque chose doit rester sur le CPU, et ollama ps montre le partage.

Trois façons de combler l'écart, de la moins chère :

  1. Un quant plus petit. Passer de Q8 à Q4 divise par deux la taille des poids pour un coût de qualité modeste. Les compromis sont détaillés dans niveaux de quantification GGUF expliqués.
  2. Un contexte plus court. num_ctx domine la taille du cache. 32K de contexte sur une carte de 8 Go veut dire que la plupart des couches restent sur CPU.
  3. Moins de couches GPU. L'option num_gpu plafonne le nombre de couches offloadées. La régler sous le nombre de couches garantit un split — si quelqu'un l'a définie dans un Modelfile ou un appel API, dérégle-la.

Note aussi le piège inverse : un GPU qui affiche 100% GPU mais tourne plus lentement que prévu est peut-être en train de swapper vers la RAM système. Compare le SIZE d'ollama ps à ta VRAM réelle.

Pourquoi Ollama n'utilise pas mon GPU AMD ?

AMD sur Linux demande trois choses, et les trois se vérifient :

1. Le support ROCm dans le build. Le script d'installation Linux officiel embarque un build ROCm. Confirme ce que le serveur a détecté :

journalctl -u ollama --no-pager | grep -iE "rocm|inference compute"

2. L'appartenance aux groupes. Le runtime ROCm a besoin d'accéder à /dev/kfd et /dev/dri, donc aux groupes render et video :

sudo usermod -aG render,video $USER
# déconnexion, reconnexion, puis :
sudo systemctl restart ollama

Ce simple groupe manquant est le billet « Ollama not using GPU on Ubuntu » le plus commun de tous les forums, et il survit aux réinstallations de pilotes parce que le pilote n'a jamais été le problème.

3. Un GPU supporté — ou un override. Les cartes grand public RDNA2 non supportées (gfx1031, gfx1032) échouent à la détection même avec une stack ROCm fonctionnelle. La parade standard : se réclamer d'une cible compatible :

sudo systemctl edit ollama

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

Puis sudo systemctl restart ollama. C'est un override non supporté officiellement mais très répandu ; si ça déconne, supprime-le et te voilà revenu dans le giron du support officiel. Si tu préfères un contrôle total sur les backends plutôt que te battre avec l'autodétection, c'est la différence de fond couverte dans llama.cpp vs Ollama.

Sous Windows, le support AMD est plus étroit — consulte la liste des GPU supportés d'Ollama pour ta carte avant de conclure que l'install est cassée.

Pourquoi Ollama a lâché le GPU après une mise à jour ?

Les mises à jour changent l'une de trois choses, dans cet ordre de probabilité :

  1. Une bibliothèque backend épinglée. OLLAMA_LLM_LIBRARY force un runner précis (cuda_v11, rocm, voire cpu). C'est fait pour débugger, ça passe outre l'autodétection en silence, et ça survit dans les profils shell et les fichiers de service bien après que la raison est oubliée. Trouve-le et vire-le :
systemctl show ollama --property=Environment | grep -i llm_library
env | grep OLLAMA
  1. Le pilote a pris du retard sur le runtime. Les montées de version d'Ollama embarquent un runtime CUDA plus récent ; ton pilote ne bouge pas tant que tu ne le bouges pas. Même correctif que la section pilote plus haut.
  2. Le service est un conteneur et les flags se sont envolés. Un conteneur recréé sans les flags GPU est un conteneur CPU-only. L'invocation NVIDIA :
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

Pour les conteneurs AMD, l'équivalent, c'est le passthrough de devices plus l'ajout de groupes :

docker run -d --device=/dev/kfd --device=/dev/dri \
  --group-add video --group-add render \
  -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

Pas de --gpus=all, pas de GPU — Docker n'a aucune raison d'être généreux.

Est-ce qu'Ollama marche sous WSL2 ?

Oui, avec le bon pilote au bon endroit : installe le pilote NVIDIA Windows, jamais un pilote Linux dans la distro — un pilote dans WSL casse le passthrough CUDA au lieu de l'arranger. Ensuite mets WSL lui-même à jour et confirme que le device de passthrough existe :

wsl --update   # depuis PowerShell
ls /dev/dxg    # dans WSL — doit exister pour utiliser le GPU

Avec /dev/dxg présent et un pilote Windows à jour, Ollama sous WSL2 offloade sur le GPU comme une install native. Si tu préfères zéro indirection, le build Windows d'Ollama tourne en natif et voit le GPU sans WSL.

Ollama a-t-il vraiment besoin d'un GPU ?

Non — une exécution CPU-only est fonctionnellement identique, juste plus lente, et pour de petits modèles sur un CPU rapide, elle peut être parfaitement utilisable. Sur Apple Silicon, la question se dissout : Metal utilise la mémoire unifiée automatiquement, et la seule limite est la RAM que tu acceptes de partager avec le modèle.

La checklist des cinq minutes

Symptôme Cause probable Correctif
100% CPU dans ollama ps, carte NVIDIA présente Pilote trop vieux pour le CUDA embarqué Mets à jour le pilote, reboote, relance le service
100% CPU, AMD sur Linux Groupe render/video manquant usermod -aG render,video, reconnexion
100% CPU, carte AMD non supportée ROCm rejette la cible gfx HSA_OVERRIDE_GFX_VERSION=10.3.0
Split 40%/60% CPU/GPU Modèle + contexte dépassent la VRAM Quant plus petit ou num_ctx plus court
GPU hier, CPU aujourd'hui OLLAMA_LLM_LIBRARY épinglé ou pilote périmé Trouve et vire la variable d'env ; mets à jour le pilote
GPU en natif, CPU dans Docker Conteneur lancé sans les flags GPU Recrée avec --gpus=all (ou les devices AMD)

Vérifie dans cet ordre : ollama ps pour l'état, les logs du serveur pour la liste de détection, puis le tableau. Neuf fois sur dix, la ligne de log t'avait déjà dit dans quelle rangée tu étais.

Le GPU remarche ? La décision suivante, c'est le runtime lui-même — llama.cpp vs Ollama tranche la question à partir du dossier public.