Quand Ollama paraît lent, la question n’est pas seulement “le GPU marche ?”. Il faut savoir quel backend est possible sur votre système : NVIDIA sous Linux avec pilotes compatibles, AMD via ROCm selon cartes et OS supportés, Mac via Metal avec l’application native, ou CPU pur. Docker, Windows, WSL et Linux n’ont pas les mêmes chemins.
Repère documentaire : documentation officielle du fonctionnement présenté.
Ce guide documentaire décrit une procédure à vérifier sur votre installation ; nous ne présentons pas ces manipulations comme un test exécuté.
Lire ollama ps
ollama ps peut indiquer où un modèle est chargé. Une valeur peut montrer GPU, CPU ou un mélange. Un modèle partiellement chargé sur GPU et mémoire système peut afficher une charge GPU élevée tout en restant ralenti par le CPU, la RAM ou le transfert mémoire. 100 % GPU ne signifie pas forcément performance parfaite ; 100 % CPU ne signifie pas forcément erreur si aucun GPU compatible n’est disponible.
NVIDIA Linux
Vérifiez le pilote, la visibilité CUDA et les logs :
nvidia-smi
ollama ps
journalctl -u ollama --no-pager -n 100Après installation ou mise à jour de pilotes, redémarrez le service Ollama, voire la machine si le pilote noyau l’exige :
sudo systemctl restart ollamaNe promettez pas que cela corrige tout. Si la carte est trop ancienne, si le driver ne correspond pas, ou si le modèle dépasse la VRAM, Ollama peut rester CPU ou charger partiellement.
AMD, Windows/Linux et Mac
AMD dépend de ROCm et la compatibilité varie fortement entre Linux, Windows et modèles de cartes. Lisez la documentation Ollama à jour avant d’acheter ou de promettre un support. Sur Mac, l’accélération passe par Metal, pas par NVIDIA. Docker sur Mac n’est pas le chemin à privilégier pour exploiter Metal comme une installation native.
Diagnostic décisionnel
| Symptôme | Lecture probable | Action utile |
|---|---|---|
modèle absent de ollama ps |
pas chargé ou génération terminée | lancer une requête puis relire |
| CPU haut, GPU bas | fallback CPU ou modèle non offloadé | logs, drivers, compatibilité |
| GPU haut, réponse lente | modèle lourd, contexte long, débit limité | réduire contexte, modèle, quantification |
| erreur mémoire | VRAM/RAM insuffisante | modèle plus petit ou quantifié |
Mesurer proprement
Utilisez le même prompt, le même modèle et la même longueur de sortie avant/après changement. Notez version Ollama, OS, GPU, driver, modèle, quantification et contexte. Sans ces informations, “ça utilise le GPU” ne permet pas de décider. L’objectif n’est pas d’obtenir un logo GPU dans un dashboard, mais une latence et un débit acceptables pour votre usage.
Docker ajoute une couche
Si Ollama tourne dans Docker, le GPU visible par l’hôte ne suffit pas. Le conteneur doit recevoir les bons devices, runtimes et variables. Sur NVIDIA Linux, cela renvoie au NVIDIA Container Toolkit. Sur Mac, un conteneur Linux ne bénéficie pas de Metal comme l’application native. Séparez donc toujours diagnostic hôte et diagnostic conteneur.
Quand ne pas insister
Si la carte est limite, que le modèle dépasse la VRAM, ou que la pile ROCm n’est pas supportée, passer des heures sur les pilotes peut coûter plus cher qu’utiliser un modèle plus petit ou une API distante. Le diagnostic doit mener à une décision : corriger driver, réduire modèle, changer runtime, ou accepter CPU/cloud.
Logs à conserver
Gardez les lignes de log autour du chargement modèle, pas seulement la sortie finale. Elles indiquent souvent le nombre de couches offloadées, la mémoire disponible ou le fallback. Avec ces éléments, on peut comparer deux changements sans deviner.
Comparer modèle et quantification
Si le GPU est bien utilisé mais que l’expérience reste lente, testez un modèle plus petit ou une quantification différente avant de changer toute l’infrastructure. Gardez trois prompts fixes : un court, un long, un représentatif de votre usage réel. Notez le temps de départ, le temps total et la qualité perçue. Une option moins ambitieuse peut être plus rentable si elle répond assez bien et libère la machine.
Décision finale
À la fin du diagnostic, classez le cas : compatible et utilisé, compatible mais mémoire insuffisante, non compatible, Docker mal configuré, ou besoin cloud. Cette conclusion est plus utile qu’une pile de commandes. Elle dit quoi faire ensuite : corriger, réduire, déplacer ou arrêter d’investiguer.
Cas long contexte
Un GPU peut charger le modèle mais saturer quand le contexte augmente. Testez donc un prompt court puis un prompt long. Si seul le long contexte échoue, le problème n’est pas forcément le pilote : c’est peut-être la mémoire requise par le cache et la taille de contexte.
Comparer avec CPU
Gardez un résultat CPU de référence sur un petit modèle. Si le GPU produit une latence similaire, le modèle n’est peut-être pas réellement offloadé ou le goulot est ailleurs. Ce point de comparaison évite de juger seulement à l’activité visible dans un moniteur système.
Sortie attendue
Le diagnostic doit finir par une décision opérationnelle : garder ce modèle en local, réduire la taille, changer de machine ou passer en cloud. Sans décision, les commandes GPU ne sont qu’un inventaire.
Changement unique
Changez un seul paramètre à la fois : pilote, modèle, quantification ou contexte. Sinon, une amélioration ou une régression devient impossible à attribuer.
Pour les bases : définition d’un modèle de langage.
