■ espace · voie prose
100% GPU — le GPU est sain, cessez de lire.
40%/60% CPU/GPU split — ne tenait pas dans la VRAM, utilisez un quant plus petit.
100% CPU — aucun GPU utilisable trouvé : pilote périmé, groupe render/video manquant (AMD), un OLLAMA_LLM_LIBRARY épinglé, ou un conteneur sans drapeaux GPU.
LES DEUX COMMANDES
# in one terminal: load a model
ollama run llama3.2 "hello"
# in another: see where it runs
ollama ps
NAME ID SIZE PROCESSOR UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB 100% GPU 4 minutes from now
Puis lisez 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 boîte NVIDIA saine, vous voulez 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 vous avez trouvé votre problème. La détection arrive une fois au démarrage, pas par requête — après tout fix, sudo systemctl restart ollama avant de re-vérifier.
LA TABLE DES CORRECTIFS
Travaillez les causes dans l'ordre — neuf fois sur dix, la ligne de log vous a déjà dit dans quelle rangée vous êtes :
| Symptôme | Cause probable | Correctif |
|---|---|---|
100% CPU, carte NVIDIA présente | Pilote trop vieux pour le CUDA embarqué | Mettez le pilote à jour, reboot, redémarrez le service |
100% CPU, AMD sur Linux | Groupe render/video manquant | usermod -aG render,video, re-login |
100% CPU, carte AMD non supportée | ROCm rejette la cible gfx | HSA_OVERRIDE_GFX_VERSION=10.3.0 |
40%/60% CPU/GPU split | Modèle + contexte dépassent la VRAM | Quant plus petit ou num_ctx |
| Le GPU marchait hier, CPU aujourd'hui | Épinglé OLLAMA_LLM_LIBRARY ou pilote périmé | Trouvez et retirez la var d'env ; mettez le pilote à jour |
| GPU natif, CPU dans Docker | Conteneur lancé sans drapeaux GPU | Recréez avec --gpus=all (ou devices AMD) |
NVIDIA : LE PILOTE, PAS CUDA
Le coupable habituel est le pilote, pas CUDA. Ollama embarque ses propres bibliothèques du runtime CUDA, vous n'avez donc pas besoin du toolkit CUDA — mais le runtime embarqué exige un pilote assez neuf pour lui parler. Un nvidia-smi qui marche est pas une preuve : il prouve qu'un pilote existe, pas qu'il soit assez récent.
nvidia-smi --query-gpu=driver_version --format=csv,noheader
# Debian/Ubuntu family
sudo apt install nvidia-driver-570
# Arch family
sudo pacman -S nvidia
# then re-detect:
sudo systemctl restart ollama
verify: journalctl -u ollama --no-pager | grep -i "inference compute" → library=CUDA
LE SPLIT : L'OFFLOAD PARTIEL EST DES MATHS, PAS UN BUG
Les poids du modèle plus le cache KV doivent tenir dans la VRAM. Même modèle, contexte plus grand — le cache outrepasse la carte et le surplus coule vers le CPU :
Trois manières de boucher l'écart, la moins chère d'abord : un quant plus petit (Q8 → Q4 divise les poids par deux pour un coût de qualité modeste) ; un contexte plus court (num_ctx domine la taille du cache — du 32K sur une carte de 8 GB veut dire que la plupart des couches restent sur CPU) ; et moins de couches GPU — l'option num_gpu plafonne les offloads, et la régler sous le nombre de couches garantit un split. Si quelqu'un l'a mise dans un Modelfile ou un appel API, déréglez-la. Encore un piège : 100% GPU mais toujours lent — le modèle swappe peut-être sur la RAM système ; comparez ollama ps SIZE à votre VRAM réelle.
AMD SOUS LINUX : TROIS CHOSES CHECKABLES
1. ROCm dans le binaire — le script d'installation officiel l'embarque. Confirmez ce que le serveur a détecté : journalctl -u ollama --no-pager | grep -iE "rocm|inference compute".
2. Appartenance au groupe — le runtime exige /dev/kfd + /dev/dri, c'est-à-dire les groupes render/video :
sudo usermod -aG render,video $USER
# log out and back in, then:
sudo systemctl restart ollama
Le groupe manquant est le post « Ollama n'utilise pas le GPU sur Ubuntu » le plus répandu sur tous les forums — le pilote n'a jamais été le problème.
3. Un GPU supporté — ou un contournement. Les cartes grand public RDNA2 non supportées (gfx1031, gfx1032) échouent à la détection même avec une pile ROCm fonctionnelle. Le contournement standard, c'est se faire passer pour une carte supportée : sudo systemctl edit ollama, puis :
[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"
Puis redémarrez. Non supporté mais très utilisé — si ça se conduit mal, retirez-le. Sous Windows, le support AMD est plus étroit ; vérifiez la liste des GPU supportés d'Ollama avant de conclure que l'installation est cassée.
verify: journalctl -u ollama --no-pager | grep -iE "rocm|inference compute" → votre cible gfx listée
«ÇA MARCHAIT HIER»
Les mises à jour changent une des trois choses suivantes, par ordre de probabilité :
- Une bibliothèque de backend épinglée.
OLLAMA_LLM_LIBRARYforce un runner (cuda_v11,rocm, mêmecpu) et bat en silence l'autodétection. C'est un interrupteur de debug qui persiste dans les profils shell et les fichiers de service bien après que la raison est oubliée. Trouvez-le :systemctl show ollama --property=Environment | grep -i llm_libraryetenv | grep OLLAMA— puis retirez-le. - Le pilote s'est fait dépasser par le runtime. Les mises à niveau d'Ollama embarquent un runtime CUDA plus neuf ; votre pilote ne bouge pas tant que vous ne le bougez pas. Même fix que la section pilote.
- Le service est un conteneur et les drapeaux sont partis. Un conteneur Docker recréé sans drapeaux GPU est un conteneur CPU-only — recréez-le avec
--gpus=all(ou les drapeaux devices AMD).
fin des cinq causes · rien n'a été téléchargé · tout est local