Dépannage d IA auto-hébergée : GPU non détecté, OOM, tokens lents

L’IA auto-hébergée casse. C’est correct. Le firmware casse aussi. Les hashboards cassent. Le PSU que vous avez acheté sur un lien Alibaba douteux en 2021 casse. Si vous avez passé un peu de temps à opérer votre propre matériel de minage, vous avez déjà développé le muscle du dépannage : lire les logs, isoler la variable, remplacer ce qui est cassé, passer à autre chose. Ce billet ne fait que traduire les modes de panne courants de l’IA dans un vocabulaire que vous utilisez déjà.

Chaque section qui suit a la même forme qu’une entrée de code d’erreur : Symptôme, Cause, Correction. Défilez jusqu’au vôtre. Pas de cérémonie.

Avant de plonger dans un problème précis, lancez ce balayage diagnostic d’abord. Neuf fois sur dix, la réponse est déjà à l’écran :

ollama list                    # quels modèles sont installés
ollama ps                      # qu'est-ce qui est chargé, CPU ou GPU ?
nvidia-smi                     # NVIDIA : pilote + VRAM + processus
rocm-smi                       # équivalent AMD
# macOS : Moniteur d'activité → Fenêtre → Historique GPU
docker ps                      # Open WebUI ou autres conteneurs actifs ?
journalctl -u ollama -n 50     # utilisateurs de systemd : 50 dernières lignes de log

La colonne PROCESSOR de ollama ps à elle seule vous dit si votre GPU est utilisé. Si elle indique 100% CPU, sautez à la section 2 ou 3 selon votre matériel. Le reste, c’est du détail.

1. « ollama: command not found » après installation

Symptôme : Vous avez lancé le script d’installation officiel, il a affiché un succès, et ollama n’est toujours pas reconnu comme commande dans votre shell.

Cause : Le PATH de votre shell n’a pas pris /usr/local/bin dans la session courante, ou le script d’installation a rencontré un échec silencieux en cours de route — généralement une glibc non prise en charge sur une distribution ancienne, ou une erreur d’écriture sous /usr/local/bin.

Correction :
– Ouvrez un nouveau terminal ou exécutez source ~/.bashrc (ou ~/.zshrc). Neuf cas sur dix, c’est tout.
– Confirmez que le binaire a atterri : ls -la /usr/local/bin/ollama. S’il manque, l’installation a échoué.
– Relancez avec journalisation pour voir ce qui a cassé : curl -fsSL https://ollama.com/install.sh | sh 2>&1 | tee install.log, puis lisez install.log de haut en bas.
– Si vous êtes sur une LTS plus ancienne avec glibc <2.31, mettez à jour la distribution ou compilez llama.cpp depuis les sources. Les builds statiques d’Ollama visent une libc raisonnablement moderne.

Crédit à qui de droit : l’équipe Ollama empaquette llama.cpp et une UX d’installation qui « Just Works » sur ~95 % des systèmes. Quand ce n’est pas le cas, c’est presque toujours un souci de PATH ou de glibc, pas la faute d’Ollama.

2. GPU non détecté (NVIDIA)

Symptôme : Ollama tourne, les modèles se chargent, mais ollama ps affiche 100% CPU dans la colonne PROCESSOR. Les tokens sortent au compte-goutte à 2–4 tok/s sur un modèle 8B qui devrait faire 60+.

Cause : L’une des quatre, par ordre de fréquence :

1. Le pilote NVIDIA n’est pas installé (ou mauvaise version).
2. Désaccord de version du runtime CUDA — le llama.cpp embarqué par Ollama veut une CUDA plus récente que ce que votre pilote expose.
3. Les nœuds de périphérique /dev/nvidia* ne sont pas présents ou lisibles par l’utilisateur ollama.
4. Vous êtes sous Docker ou WSL2 et la plomberie de passthrough GPU n’est pas configurée.

Correction :
– D’abord, nvidia-smi depuis le shell de votre Hashcenter. Si ça échoue, aucune config d’Ollama n’aidera — corrigez le pilote avant d’aller plus loin. sudo apt install nvidia-driver-570 (ou la version courante) sous Debian/Ubuntu, dnf install nvidia-driver sur la famille RHEL.
– Lisez directement les logs de détection CUDA d’Ollama : journalctl -u ollama | grep -i cuda. Ça vous dira clairement « compute capability X detected » ou « no CUDA devices found ».
– Docker : ajoutez --gpus=all à votre invocation docker run, et installez d’abord le NVIDIA Container Toolkit (nvidia-ctk depuis le dépôt apt de NVIDIA). Sans le toolkit, --gpus=all est ignoré silencieusement.
– WSL2 : le pilote doit être installé sous Windows, pas dans WSL. Puis nvidia-smi dans WSL doit fonctionner. Si oui, Ollama trouvera le GPU.
– Nœuds de périphérique : ls -la /dev/nvidia*. S’ils n’existent pas après installation du pilote, sudo nvidia-modprobe -c0 -u ou redémarrez.

Crédit : NVIDIA pour CUDA et pour avoir fait de nvidia-smi l’outil diagnostic le plus utile de toute pile GPU.

3. GPU non détecté (AMD / ROCm)

Symptôme : Idem que la section 2, sur matériel AMD. ollama ps indique CPU, les tokens sont lents.

Cause :
1. Version ROCm trop vieille — le llama.cpp d’Ollama a besoin de ROCm 5.7+.
2. Votre GPU n’est pas sur la liste officielle de prise en charge ROCm d’AMD (vérifiez avant d’acheter, pas après).
3. L’utilisateur ollama ne peut pas lire /dev/kfd ou /dev/dri/renderD128.
4. GPU plus ancien qui a besoin de l’échappatoire HSA_OVERRIDE_GFX_VERSION.

Correction :
– rocm-smi doit lister votre carte. Sinon, votre installation ROCm est cassée — réinstallez depuis le dépôt d’AMD, pas le paquet de la distribution.
– Vérifiez la version : rocminfo | grep -i version ou apt show rocm-libs. Sous 5.7, mettez à jour.
– Permissions : sudo usermod -aG render,video ollama. Redémarrez le service ollama après (systemctl restart ollama).
– Liste prise en charge : les fleurons RDNA3 (7900 XTX, 7900 XT, 7900 GRE) fonctionnent d’emblée. RDNA2 (6800/6900 XT) fonctionne le plus souvent. Les Vega/RDNA1 plus anciens ont souvent besoin de HSA_OVERRIDE_GFX_VERSION=10.3.0 (ou similaire) défini dans l’environnement du service ollama.
– Si vous utilisez un override, placez-le dans /etc/systemd/system/ollama.service.d/override.conf :
[Service] Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"
Puis systemctl daemon-reload && systemctl restart ollama.

Crédit : AMD pour ROCm, et l’équipe llama.cpp pour avoir livré le support ROCm aux côtés de CUDA — ce n’est pas trivial.

4. Mémoire insuffisante (OOM) au chargement du modèle

Symptôme : Le modèle se télécharge bien, puis ollama run <modèle> affiche quelque chose comme Error: llama runner process has terminated: exit status 2 ou failed to load model: out of memory.

Cause : Les poids du modèle plus le cache KV ne tiennent pas dans votre VRAM. En général, l’une de ces causes :

• Le modèle est simplement trop gros pour votre carte (70B Q4 sur un GPU 16 Go : non).
• La fenêtre de contexte est réglée énorme (128K de contexte sur Llama 3.1 70B avale ~16 Go de cache KV en plus des poids).
• Un autre processus retient de la VRAM — une instance ComfyUI oubliée, un onglet de navigateur avec une démo WebGL, votre compositeur de bureau.

Correction :
– Une plus petite quantification est le premier levier. Passez Q8 → Q4 → Q3 avant de paniquer. Voyez La quantification expliquée pour les compromis à retenir.
– Réduisez le contexte : ollama run llama3.1 --num_ctx 2048. Le défaut est souvent 4096 ou 8192 selon le Modelfile du modèle.
– Libérez de la VRAM : nvidia-smi affiche la liste des processus en bas. Identifiez le squatteur, tuez-le.
– Descendez vers une variante plus petite : Llama 3.1 70B → Llama 3.1 8B; Gemma 3 27B → Gemma 3 12B → Gemma 3 4B. Les plus petits sont étonnamment bons en 2026.
– Déchargement CPU+GPU mixte : réglez num_gpu à un nombre inférieur au total de couches dans un Modelfile. Ollama met ce nombre de couches sur GPU et renvoie le reste à la RAM système. Plus lent que le GPU pur, mais beaucoup plus rapide que le CPU pur.

Règle du pouce : VRAM nécessaire ≈ (taille du modèle en Go) + (0,1 × contexte en milliers de tokens × nombre de milliards de paramètres). Approximatif, mais vous met dans le bon quartier.

5. Tokens lents / inférence limitée par le CPU

Symptôme : Modèle chargé, pas d’OOM, mais les tok/s restent sous 5 sur ce qui devrait être un 8B facile.

Cause :
– Le nombre de couches déchargées est 0 — Ollama a décidé que rien ne tenait sur GPU et est passé tout CPU.
– Le GPU est détecté mais num_gpu a été fixé à 0 quelque part (Modelfile, variable d’environnement, drapeau CLI).
– Étranglement thermique — une carte enterrée dans une baie chaude se sous-cadencera fortement.
– Manque de voies PCIe — un riser x1 hérité du matériel d’ère minage.

Correction :
– ollama ps d’abord. Si PROCESSOR indique CPU, revenez à la section 2 ou 3.
– Forcez le déchargement maximal : créez un Modelfile avec PARAMETER num_gpu 999. Ollama déchargera chaque couche qui tient. Construisez avec ollama create mymodel -f Modelfile.
– Surveillez pendant l’inférence : nvidia-smi dmon -s put dans un autre terminal. Vous voulez voir la mémoire utilisée ET une utilisation de 80 %+. Si la mémoire est utilisée mais l’utilisation est au repos, le modèle ne tourne pas réellement sur GPU — il est chargé puis relu vers le CPU (quelque chose est mal configuré).
– Vérification thermique : nvidia-smi dmon -s t pendant une requête lourde. Si la carte touche ses limites thermiques (83 °C+) et que les fréquences chutent, le flux d’air de votre Hashcenter a besoin de travail. Territoire familier — c’est la même raison pour laquelle un Bitmain S19 se dérate quand l’air d’admission dépasse 40 °C.
– Vérification PCIe : nvidia-smi -q | grep -i "Link Width". x16 ou x8 suffit. x1 fera un goulot d’étranglement sur les temps de chargement de gros modèles et sur l’inférence à long contexte.

6. Modèle introuvable / « manifest not found »

Symptôme : ollama pull llama3.1:70b-instruct-q4_K_M renvoie Error: manifest not found.

Cause : Faute de frappe dans l’étiquette, étiquette renommée en amont, ou votre réseau ne joint pas registry.ollama.ai.

Correction :
– Parcourez ollama.com/library et copiez l’étiquette exacte. Ne devinez pas les suffixes de quantification — ils changent d’un modèle à l’autre.
– Test réseau : curl -v https://registry.ollama.ai/ doit réussir. Si ça pend, vérifiez votre pare-feu, proxy ou DNS. Le filtrage DNS d’entreprise ou de FAI le bloque à l’occasion.
– Derrière un proxy : définissez HTTPS_PROXY dans l’environnement du service ollama.

7. Le service Ollama ne démarre pas

Symptôme : systemctl status ollama affiche failed ou activating (auto-restart) en boucle. Le port 11434 n’écoute pas (ss -tulpn | grep 11434 ne renvoie rien).

Cause :
– Conflit de port — quelque chose d’autre a pris 11434.
– Stockage de modèles corrompu — un téléchargement tué en cours de route a laissé un blob défectueux.
– Permissions sur le répertoire de données d’ollama.

Correction :
– journalctl -u ollama -n 100 est votre meilleur ami ici. Lisez la vraie erreur avant de faire quoi que ce soit.
– Vérification de port : ss -tulpn | grep 11434. Si autre chose est là, arrêtez-le ou changez le port d’Ollama (OLLAMA_HOST=0.0.0.0:11435 dans l’environnement du service).
– Vérification de stockage : ls -la ~/.ollama/ ou /usr/share/ollama/.ollama/ (l’installation systemd la place sous le répertoire personnel de l’utilisateur ollama). L’appartenance doit être ollama:ollama. Si c’est root après un ollama pull manuel en root, corrigez : chown -R ollama:ollama /usr/share/ollama/.ollama/.
– Blob corrompu : si les logs mentionnent un hash de blob qui échoue à l’intégrité, écrasez les blobs et retéléchargez : rm -rf /usr/share/ollama/.ollama/models/blobs && systemctl restart ollama && ollama pull <modèle>.

8. Multi-GPU : une seule carte utilisée

Symptôme : Vous avez un rig 4× 3090 dans votre Hashcenter, mais nvidia-smi pendant l’inférence ne montre que GPU 0 actif. Les trois autres restent au repos avec ~100 Mo utilisés.

Cause : Ollama moderne gère le multi-GPU automatiquement, mais seulement quand le modèle est assez gros pour nécessiter le débordement. Un modèle 8B Q4 tient confortablement sur une 3090 (24 Go) et Ollama ne le répartira pas sur plusieurs cartes sans raison. C’est le comportement attendu — il vous faut simplement un modèle plus gros ou une configuration llama.cpp directe pour exploiter le rig.

Correction :
– Mettez Ollama à jour d’abord — le support multi-GPU a mûri significativement dans les sorties 2024–2025. ollama --version, puis curl -fsSL https://ollama.com/install.sh | sh pour mettre à niveau.
– Chargez un modèle qui a vraiment besoin de plusieurs cartes : Llama 3.1 70B Q4 (~40 Go) s’étale proprement sur 2× 3090. Un quant 405B en exige les quatre.
– Pour un contrôle fin, utilisez llama.cpp directement : llama-server -m model.gguf --tensor-split 1,1,1,1 -ngl 99. Les ratios --tensor-split vous permettent d’équilibrer sur des cartes de tailles différentes.
– CUDA_VISIBLE_DEVICES=0,1,2,3 (ou un sous-ensemble) délimite ce que chaque processus peut voir. Utile quand vous voulez un modèle sur les GPU 0–1 et un autre sur 2–3.
– Pour un service en production avec requêtes concurrentes en file, vLLM ou SGLang surpassent Ollama et llama.cpp — le coût de configuration en vaut la peine si vous opérez un endpoint partagé.

Crédit : les mainteneurs de llama.cpp pour l’implémentation du tensor-split. L’inférence multi-GPU sur des cartes hétérogènes est sincèrement difficile, et ils l’ont livrée.

9. Open WebUI ne voit pas Ollama

Symptôme : Le conteneur Open WebUI tourne, vous pouvez vous connecter, mais la liste déroulante de modèles dit « No models available » ou le clavardage renvoie simplement une erreur.

Cause : OWUI ne joint pas le backend Ollama. Le réseau entre conteneur et hôte est le coupable le plus fréquent, suivi d’un Ollama lié à localhost seulement alors qu’OWUI s’attend à le joindre par le réseau.

Correction :
– Si Ollama est sur la même machine que Docker : ajoutez --add-host=host.docker.internal:host-gateway à votre docker run. Sur Docker Desktop (Mac/Windows), ça marche d’emblée. Sur Docker Linux natif, il vous faut le drapeau.
– Définissez la variable d’environnement dans le conteneur : -e OLLAMA_BASE_URL=http://host.docker.internal:11434.
– Si Ollama est sur une autre machine : OLLAMA_BASE_URL=http://192.168.1.50:11434 (ou l’IP du LAN), et assurez-vous qu’Ollama se lie à toutes les interfaces : Environment="OLLAMA_HOST=0.0.0.0" dans l’override systemd du service ollama. Redémarrez ollama après.
– Confirmez depuis la perspective du conteneur OWUI : docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags. Si ça renvoie une liste JSON de modèles, OWUI les verra. Si ça pend ou renvoie 404, le chemin réseau est cassé.
– Marche à suivre complète dans Open WebUI : l’expérience ChatGPT.

Crédit : l’équipe Open WebUI pour avoir bâti la meilleure UI LLM auto-hébergée de l’écosystème. Leur doc de dépannage est aussi excellente.

10. Troncation de contexte / le modèle « oublie » le début du clavardage

Symptôme : Longue conversation, et quelque part passé le tour 10 le modèle commence à ignorer le début. Des faits que vous aviez établis tôt sont oubliés. Le modèle répond comme si la première moitié du clavardage n’avait jamais eu lieu.

Cause : Vous avez dépassé la fenêtre de contexte du modèle. Ollama tronque silencieusement les plus anciens tokens d’abord — pas d’avertissement, pas d’erreur, juste une amnésie silencieuse.

Correction :
– Vérifiez la limite réelle de contexte du modèle. Llama 3.1 et 3.3 : 128K. Gemma 2 : 8K. Gemma 3 : 128K. Mistral 7B v0.3 : 32K. Qwen 2.5 : 32K natif, 128K avec YaRN. La bibliothèque des modèles IA a les spécifications par modèle.
– Réglez num_ctx explicitement si vous voulez plus que le défaut d’Ollama (souvent 4096, parfois 8192). Dans un Modelfile :
FROM llama3.1:8b PARAMETER num_ctx 32768
Puis ollama create llama3.1-32k -f Modelfile.
– Contrôle de réalité VRAM : les grands contextes coûtent cher. Un contexte de 128K sur un 70B Q4 ajoute à peu près 16 Go à l’empreinte VRAM par-dessus les poids. Le plus gros de ce que vous économisez en Q4 est mangé par une fenêtre de contexte complète.
– Si vous avez vraiment besoin d’un travail à long contexte, louez un GPU infonuagique pour cette tâche précise ou bâtissez un pipeline RAG qui ne récupère que les morceaux pertinents à chaque tour.

11. Erreurs de permission Docker / WSL au téléchargement

Symptôme : ollama pull échoue avec « permission denied » ou « read-only file system » dans un conteneur.

Cause : Vous avez monté un répertoire hôte dans le conteneur, et l’UID/GID à l’intérieur ne le possède pas sur l’hôte. Piège de permission de volume Docker classique.

Correction :
– Utilisez un volume Docker nommé, pas un bind mount : -v ollama:/root/.ollama. Docker gère la propriété et vous n’avez pas à y penser.
– Si vous avez besoin d’un bind mount (pour raison de sauvegarde), faites correspondre l’UID : docker run --user $(id -u):$(id -g) ... et chown le répertoire hôte pour correspondre.
– WSL2 : si vous opérez Ollama dans un conteneur Docker dans WSL, envisagez simplement de faire tourner Ollama nativement dans WSL. Moins de couches, moins de jeux de permission. Le script d’installation Linux natif fonctionne très bien sous WSL2.

12. Problèmes spécifiques à ComfyUI / Stable Diffusion

Symptôme : ComfyUI lève CUDA out of memory en générant à 1024×1024 sur SDXL ou FLUX, même sur une carte 12–16 Go qui devrait suffire.

Cause : Les modèles de diffusion atteignent un pic de VRAM au milieu du réseau quand les têtes d’attention matérialisent des tenseurs pleine résolution. La VRAM moyenne pendant la génération est modeste; c’est le pic qui casse les choses. FLUX.1 dev en fp16 est particulièrement brutal.

Correction :
– Drapeaux de lancement : --lowvram pour 8 Go ou moins, --medvram pour 12 Go. ComfyUI bascule les composants en VRAM à la demande — plus lent, mais ça rentre.
– Réduisez la résolution : générez en 768×768 ou même 512×512, puis redimensionnez avec un nœud d’upscaler dédié. La qualité finale est souvent meilleure de toute façon, et vous évitez l’OOM.
– Pour FLUX.1 dev en particulier : utilisez la variante fp8, pas fp16. À peu près la moitié de la VRAM, perte de qualité imperceptible pour la plupart des flux.
– Fermez tout le reste. Onglets de navigateur avec WebGL, un modèle Ollama en cours, votre compositeur de bureau — tout ça prend de la VRAM.
– Configuration de base : ComfyUI pour plebs.

Crédit : l’équipe ComfyUI pour avoir bâti l’UI de diffusion la plus extensible de l’écosystème, et pour la conception par nœuds qui rend les flux partageables et débogables.

Pour clore : même compétence, nouveau vocabulaire

Si vous êtes rendu ici, vous avez probablement remarqué : chaque catégorie de panne ci-dessus se projette proprement sur des choses que vous connaissez déjà en opérant des mineurs.

• GPU non détecté = hashboard qui ne s’initialise pas. Même arbre de causes : pilote/firmware, permissions, détection physique.
• OOM au chargement = le PSU ne peut pas livrer assez de watts au démarrage. Prenez une charge plus petite (modèle plus petit / plus petite quantification) ou une alim plus grande (contexte plus petit / plus grosse carte).
• Tokens lents = mineur sous-cadencé. Étranglement thermique, mauvaise config, mauvais lien PCIe.
• Service qui ne démarre pas = mineur coincé en boucle de boot. Lisez les logs, quelque chose sera évident.
• Multi-GPU : une seule carte utilisée = une seule hashboard qui hache dans une unité à trois. Le modèle est-il assez gros pour toutes les exiger ? Vérifiez la charge avant de blâmer le rig.

Le dépannage, c’est la même compétence. L’IA a son propre vocabulaire pour les mêmes catégories de panne : détection, mémoire, débit, réseau, permissions. Vous avez déjà les instincts. Vous avez maintenant les mots-clés.

Quand vous êtes coincé et que ce billet ne couvre pas votre cas, les communautés sont actives et réactives :

• github.com/ollama/ollama/issues — cherchez avant de poster; la réponse est probablement déjà là.
• r/LocalLLaMA sur Reddit — le meilleur signal en temps réel sur ce qui fonctionne et ce qui casse en IA auto-hébergée.
• Discord d’Open WebUI — triage rapide pour les bizarreries spécifiques à OWUI.
• Pages de modèles HuggingFace — regardez toujours l’onglet des discussions d’un modèle; les problèmes connus y vivent souvent.

D’ici, si vous assemblez encore la pile, revenez au Guide du pleb pour l’IA auto-hébergée pour la carte globale, ou à Installer Ollama en 10 minutes pour repartir propre. Si vous choisissez où le faire tourner, RTX 3090 usagée pour LLM en 2026 et LM Studio vs Ollama vs llama.cpp couvrent les compromis matériel et runtime.

La souveraineté est une pratique, pas un produit. Casser, diagnostiquer, réparer — voilà la pratique. Voyez le Manifeste pour une IA souveraine des Bitcoiners pour savoir pourquoi ça compte.

Pour aller plus loin : la même infrastructure de niveau pleb qui opère l’inférence locale opère aussi une chaufferette Bitcoin. Plusieurs lecteurs arrivent du côté minage — voyez Du S19 à votre premier Hashcenter IA pour la passerelle.