Ollama sur GPU AMD : toutes les couches d'accélération (CPU seul, Vulkan, ROCm)

Sur une machine AMD, Ollama n'a pas de réponse unique « le GPU marche ou pas » comme on le ressent souvent sur NVIDIA. Vous avez plusieurs couches d'accélération distinctes — CPU seul, Vulkan, ROCm — et elles diffèrent énormément en effort d'installation et en performances. Choisir la bonne compte autant que choisir le bon modèle. Ce guide passe en revue chaque option, sa configuration et comment choisir selon que vous codez, faites tourner des agents et selon le matériel que vous possédez.

Pourquoi Ollama a-t-il plusieurs couches d'accélération AMD

Ollama repose sur llama.cpp et llama.cpp ne parle pas directement à votre GPU. Il délègue le gros du travail à une couche d'accélération : CUDA chez NVIDIA et chez AMD soit ROCm (la pile de calcul complète d'AMD, basée sur HIP), soit Vulkan (une API graphique/computing multi-fabricants). Chaque couche s'installe sous forme de bibliothèques différentes, c'est pourquoi une installation peut être accélérée par GPU sur une machine et silencieusement limitée au CPU sur la suivante.

Bonne nouvelle : pas besoin de réinstaller Ollama pour changer. Vous contrôlez le comportement avec des variables d'environnement et, dans certains cas, des builds séparés. Voici d'emblée le tableau qui compare les trois modes — le reste de l'article détaille chacun.

Vue d'ensemble : CPU vs Vulkan vs ROCm

Avant tout, voici comment savoir ce que votre Ollama fait actuellement.

Vérifier ce que vous utilisez actuellement

La vérification tient en deux étapes : lancez un modèle, puis regardez où il tourne.

# Charger un modèle (n'importe lequel fera l'affaire) :
ollama run mistral

Attendez la fin du chargement et générez une réponse. Dans un second terminal, vérifiez où le modèle tourne :

# Le modèle est-il sur GPU ou CPU ?
ollama ps

La colonne PROCESSOR donne la réponse honnête : 100% GPU signifie un déchargement complet, alors que quelque chose comme 48%/52% CPU/GPU signifie que le modèle est réparti — signe qu'il ne tient pas dans la VRAM. Dans ce cas, aucun changement de couche d'accélération ne vous sauvera : choisissez d'abord un modèle plus petit ou une quantization plus basse (voir le guide complet d'Ollama).

Option 1 : CPU seul

Parfois vous voulez forcer le CPU — pour tester, comparer ou parce que le GPU est occupé ailleurs (un jeu, un rendu). Ollama n'a pas d'option « CPU seul » en une ligne, mais vous pouvez le forcer de façon fiable en masquant le GPU au processus.

Comment forcer le CPU seul

Le mécanisme est le même que celui utilisé pour exclure un GPU dans les configurations multi-GPU : masquer les fichiers de périphérique pour qu'Ollama ne les voie pas.

Si vous lancez Ollama comme service systemd (le cas courant sur GNU/Linux), éditez le service :

sudo systemctl edit ollama.service

Plus simple et plus portable : masquez les nœuds de rendu AMD au processus. Arrêtez le serveur, puis lancez-le avec les périphériques masqués :

sudo systemctl stop ollama
# Lancer un serveur CPU seul dans un terminal :
HIP_VISIBLE_DEVICES=-1 ollama serve

HIP_VISIBLE_DEVICES=-1 indique à la couche ROCm que zéro GPU est visible, donc toutes les couches tournent sur CPU. Le build Vulkan a son équivalent — voir l'option 2.

CPU seul : bon ou mauvais choix ?

Option 2 : GPU avec Vulkan

Vulkan est la voie « ça marche direct » : une couche universelle qui tourne sur les GPU AMD, NVIDIA et Intel, sans pile de calcul du fabricant à installer.

Comment le configurer

Le support Vulkan est intégré aux versions récentes d'Ollama et est activé par défaut sur GNU/Linux quand Ollama ne peut pas (ou n'est pas configuré pour) utiliser ROCm. Deux choses à savoir :

1. Assurez-vous que ROCm ne capture pas l'exécution. Si les bibliothèques ROCm sont installées mais que quelque chose cloche, vous pouvez préférer explicitement Vulkan :

# Préférer la couche Vulkan à ROCm
OLLAMA_VULKAN=1 ollama serve

2. Ou passer en Vulkan seul en masquant le GPU à HIP. Si vous voulez forcer le chemin Vulkan (par exemple pour le comparer à ROCm) :

HIP_VISIBLE_DEVICES=-1 OLLAMA_VULKAN=1 ollama serve

Les différences avec ROCm sont résumées dans le tableau de vue d'ensemble en début d'article. En résumé pratique : Vulkan est le choix par défaut — zéro installation, support large et à 10–20 % de ROCm sur la plupart des modèles. ROCm gagne quand vous courez après le dernier token/seconde ou avec de gros modèles où sa meilleure efficacité mémoire vous achète une couche de plus en VRAM.

[Service]
Environment="OLLAMA_VULKAN=1"

Option 3 : GPU avec ROCm

ROCm est la réponse d'AMD à CUDA : la pile de calcul officielle, la mieux optimisée. Quand elle fonctionne, c'est la façon la plus rapide de faire tourner des modèles sur un GPU AMD. Quand elle ne fonctionne pas, c'est la plus exigeante à installer — c'est pourquoi nous avons un article entier sur l'installation de ROCm sur GNU/Linux. La version courte :

amdgpu-install -y --usecase=rocm --no-dkms

(La partie --no-dkms compte : elle évite le module noyau DKMS instable et garde le pilote AMD du noyau.)

Quels GPU sont réellement supportés

C'est la partie qui décide de tout. Les cartes officiellement supportées sont surtout des GPU discrets RDNA2 et RDNA3 — les familles RX 6000 et RX 9000/7000 — plus les cartes Instinct pour datacenter. Beaucoup d'autres cartes fonctionnent quand même via l'astuce HSA_OVERRIDE_GFX_VERSION, qui fait croire à ROCm que votre GPU est un modèle supporté :

Positionnez l'override comme n'importe quelle variable d'env :

HSA_OVERRIDE_GFX_VERSION=11.0.0 ollama serve

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=11.0.0"

Vérifier que ROCm voit votre carte

rocminfo | grep -i gfx
# ou, pour un contrôle santé rapide :
rocm-smi

Si rocminfo liste votre GPU et que ollama ps montre 100% GPU (ou un déchargement partiel), vous êtes sur ROCm. Si Ollama démarre mais que ollama ps montre toujours CPU, vérifiez les deux suspects habituels : l'utilisateur du service doit avoir accès au GPU (ajoutez-le aux groupes render et video) et la version de ROCm doit correspondre à ce que votre build d'Ollama attend.

Réglages spécifiques à ROCm

• OLLAMA_NUM_GPU — nombre de couches GPU à décharger (0 = CPU seul, 999 = tout tenter). Rarement nécessaire ; l'ordonnanceur d'Ollama fait bien le travail.
• OLLAMA_SPLIT_MODE=layer — comment les configurations multi-GPU répartissent le modèle (la valeur par défaut convient à la plupart des cas).
• HIP_VISIBLE_DEVICES=0,1 — restreindre les GPU utilisés par ROCm quand vous en avez plusieurs.

Quelle option pour quel usage

Tableau de décision par matériel

Par cas d'usage

Codage et agents (les cas exigeants). Le codage agentique — celui dont parle notre guide des modèles de code locaux et que des outils comme OpenCode pratiquent avec une couche locale — est la charge la plus exigeante que vous puissiez infliger à une machine locale : prompts longs, énormes contextes, des milliers de tokens par minute de génération soutenue. Chaque % de vitesse se cumule. Sur du matériel supporté, utilisez ROCm ; sur tout le reste, Vulkan. Et dans les deux cas, assurez-vous que tout le modèle tient en VRAM (100% GPU dans ollama ps) — un modèle partiellement déchargé rendra un agent pénible à utiliser, car les allers-retours d'appels d'outils multiplient votre pénalité de latence.

Autocomplétion en ligne. Un petit modèle FIM (1B–3B) veut une latence minimale, pas du débit. Ces modèles sont si petits qu'ils tournent bien sur l'une ou l'autre couche — même sur CPU — mais si le GPU est libre, déchargez-les ; la différence se voit dans la réactivité perçue de l'éditeur.

Chat, RAG, résumé. La vitesse de lecture humaine est le goulot d'étranglement. Même 10–15 tokens/s semblent très bien. Ici, Vulkan vs ROCm compte peu ; choisissez celui qui fonctionne déjà. Priorisez le fait que le modèle + un num_ctx confortable tiennent en mémoire plutôt que la vitesse brute.

Expérimenter / pilotes instables. Si votre installation ROCm est capricieuse, ne vous battez pas des heures : passez à Vulkan et continuez. Le mode d'échec de Vulkan est gracieux (repli CPU), celui de ROCm ne l'est pas.

Aide-mémoire de dépannage