On ne va pas se mentir : la première fois qu’on lance Ollama, on a l’impression que c’est magique. Tu télécharges un modèle, tu lances un prompt, et ça répond. Mais dès que tu tentes un modèle un peu trop costaud pour ta carte graphique, c’est le drame. Les ventilateurs se taisent, ton processeur se met à hurler, et tu te retrouves avec une vitesse d’écriture digne d’un escargot asthmatique.
Le coupable ? L’offloading automatique d’Ollama. Par défaut, l’outil calcule combien de couches (layers) du réseau de neurones peuvent entrer dans ta VRAM de GPU, et balance tout le reste (les couches “qui débordent”) dans ta RAM système et ton CPU. Et cette répartition hybride crée un goulot d’étranglement monumental pour les performances.
Après avoir passé des nuits entières à bidouiller mes fichiers de config et à pester contre mes cartes graphiques, voici un retour d’expérience complet pour optimiser tout ça.
📋 Comment vérifier où tourne réellement votre modèle ?
Avant de tout casser, il faut poser un diagnostic. Lancez une génération de texte, ouvrez un terminal à côté et tapez :
ollama psRegardez attentivement la colonne Processor.
- Si elle affiche 100% GPU, c’est parfait. Le modèle est entièrement hébergé sur votre carte graphique.
- Si vous voyez un truc du genre 72% GPU / 28% CPU, c’est là que le bât blesse. Votre modèle est coupé en deux, et la partie CPU ralentit l’ensemble du pipeline.
📊 Comprendre les besoins en VRAM (Sortez les calculatrices)
Pour éviter que ça déborde, il faut savoir ce qu’on manipule. À l’état brut (non quantifié, en 16-bit), la règle de base est de compter 2 Go de VRAM pour 1 milliard de paramètres, plus un petit bonus de 1 à 2 Go pour le contexte.
Heureusement, on tourne presque tous avec des modèles quantifiés (généralement en 4-bit, le standard par défaut d’Ollama qui offre le meilleur compromis entre précision et taille mémoire).
1. Calculer le poids brut d’un modèle
Pour obtenir la taille brute des poids du modèle en Go ($M$), on applique cette formule rapide :
$$M = \frac{P \times B}{8}$$
- $P$ = Nombre de paramètres en milliards.
- $B$ = Précision en bits (4, 8 ou 16).
- $8$ = Facteur de conversion de bits à octets.
Exemple concret : un modèle de 7 milliards de paramètres (7B) quantifié en 4-bit aura besoin de :
$$M = \frac{7 \times 4}{8} = 3,5 \text{ Go}$$
2. Prendre en compte le contexte (KV Cache)
C’est l’erreur classique du débutant. On oublie de compter la mémoire nécessaire pour retenir l’historique de la conversation :
- Petit contexte (2k à 4k tokens) : ajoute environ 1 à 2 Go de surcharge.
- Grand contexte (8k à 32k tokens) : peut ajouter de 4 à plus de 16 Go de VRAM selon la taille du modèle.
3. Appliquer la marge de sécurité système
Votre système d’exploitation (Windows ou Linux desktop) consomme déjà entre 1 et 2 Go de VRAM pour afficher votre écran et faire tourner les applications en arrière-plan. Si votre calcul de VRAM tombe pile-poil sur la capacité totale de votre carte, le système va saturer et forcer Ollama à rejeter des couches vers la RAM classique.
La formule finale à garder en tête :
$$\text{VRAM Totale Requise} \approx \text{Poids du modèle} + \text{Taille du Contexte} + 1,5 \text{ Go de marge système}$$
Pour vous repérer, voici un tableau récapitulatif des besoins réels en VRAM :
| Taille du Modèle (Paramètres) | Quantifié 4-bit (Recommandé) | Quantifié 8-bit | Non quantifié (FP16/BF16) |
|---|---|---|---|
| 1B – 3B (ex. Llama 3.2 3B) | ~3 Go | ~4 Go | ~7 Go |
| 7B – 9B (ex. Llama 3.1 8B, Gemma 2 9B) | ~6 Go | ~10 Go | ~18 Go |
| 12B – 14B (ex. Phi-4, Qwen 2.5 14B) | ~9 Go | ~16 Go | ~30 Go |
| 32B – 34B (ex. Qwen 2.5 32B) | ~20 Go | ~36 Go | ~70 Go |
| 70B – 72B (ex. Llama 3.3 70B, Qwen 72B) | ~43 Go | ~76 Go | ~145 Go |
⚙️ Comment forcer l’offloading sur le GPU ?
Si vous estimez qu’Ollama est un peu trop timide et n’utilise pas assez votre VRAM, vous pouvez le forcer à tout envoyer sur la carte graphique.
1. Créez un fichier nommé Modelfile (sans extension) dans votre dossier de travail :
FROM llama3.1
# Force Ollama à envoyer un nombre précis de couches au GPU.
# En mettant une valeur volontairement trop haute (ex. 99), on force l'intégralité du modèle sur le GPU.
PARAMETER num_gpu 992. Compilez et lancez ce modèle personnalisé :
ollama create mon-modele-gpu-force -f ./Modelfile
ollama run mon-modele-gpu-force🚀 Optimiser sa config pour gratter de la VRAM
Si vous êtes un peu juste en mémoire, au lieu de laisser les couches déborder sur le CPU, essayez plutôt de réduire l’empreinte mémoire d’Ollama grâce à ces variables d’environnement.
- Activer Flash Attention : Permet de réduire drastiquement la consommation mémoire sur les longs contextes.
export OLLAMA_FLASH_ATTENTION=1- Limiter les requêtes parallèles : Par défaut, Ollama réserve de la mémoire pour traiter jusqu’à 4 requêtes en même temps. Si vous êtes le seul utilisateur sur votre machine, forcez cette valeur à 1 pour économiser une tonne de VRAM :
export OLLAMA_NUM_PARALLEL=1- Réduire la taille du contexte : Vous pouvez réduire la fenêtre de contexte par défaut directement dans votre
Modelfile:
PARAMETER num_ctx 2048*(Si vous utilisez Docker, n’oubliez pas de passer l’argument de GPU pour éviter que le conteneur n’ignore vos cartes graphiques :)_
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama🧠 Gestion Multi-GPU : Comment ça marche ?
Ollama gère très bien le multi-GPU de manière native, sans configuration complexe ni pont NVLink/SLI physique. Il cumule la VRAM disponible en passant par les lignes PCIe de votre carte mère.
Les règles d’allocation d’Ollama :
- Priorité à la carte unique : Si un modèle rentre entièrement dans la VRAM d’un seul GPU, Ollama le laissera sur ce GPU pour s’épargner des communications lentes entre cartes.
- Cumul de VRAM (Spanning) : Si le modèle est trop grand pour une seule carte, Ollama répartit les couches sur toutes les cartes détectées pour éviter de basculer sur la RAM du PC.
- Mélange asymétrique : Vous pouvez mixer une RTX 4090 avec une vieille RTX 3060. Ollama va évaluer la vitesse des cartes et charger en priorité le plus gros paquet sur la plus rapide.
Variables de configuration utiles :
- Répartir équitablement la charge (au lieu de remplir la première carte au maximum avant de passer à la suivante) :
export OLLAMA_SCHED_SPREAD=1- Restreindre l’accès à certaines cartes (pour préserver un GPU pour le gaming ou le montage vidéo pendant qu’Ollama tourne sur un autre) :
- NVIDIA/CUDA :
export CUDA_VISIBLE_DEVICES=0,1(indiquez les identifiants de vos cartes). - AMD/ROCm :
export ROCR_VISIBLE_DEVICES=0 - Intel/Vulkan :
export GGML_VK_VISIBLE_DEVICES=1
Comment injecter ces variables de manière permanente ?
- Sur Linux (systemd) :
Lancez l’édition du service :
sudo systemctl edit ollama.serviceAjoutez vos variables d’environnement sous le bloc [Service] :
[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"
Environment="OLLAMA_SCHED_SPREAD=1"Sauvegardez, puis rechargez et redémarrez le service :
sudo systemctl daemon-reload
sudo systemctl restart ollama- Sur Windows :
Ouvrez votre menu Démarrer, cherchez “Variables d’environnement”. Cliquez sur “Variables d’environnement…” en bas à droite. Sous “Variables utilisateur”, cliquez sur “Nouvelle…” et ajoutez vos clés (par exemple Nom :OLLAMA_SCHED_SPREAD, Valeur :1). Quittez complètement Ollama depuis l’icône dans la barre des tâches, puis relancez-le.
Attention toutefois : Comme le multi-GPU force des échanges de données constants via votre carte mère, veillez à ce que vos cartes secondaires soient branchées sur des ports câblés au moins en PCIe 3.0 x8 ou PCIe 4.0 x4 (~5 Go/s minimum). Sinon, vous risquez de subir de grosses pertes de vitesse d’exécution.
🛑 Forcer le fonctionnement 100% RAM / CPU (Mode économie de GPU)
À l’inverse, il m’arrive parfois de vouloir libérer complètement mon GPU pour jouer ou faire un rendu 3D tout en laissant tourner Ollama en tâche de fond sur mon processeur.
Option A : Via un Modelfile
Créez un modèle qui refuse d’utiliser le GPU en réglant le paramètre de couches à 0 :
FROM llama3.1
PARAMETER num_gpu 0Compilez-le et lancez-le :
ollama create mon-modele-ram -f ./Modelfile
ollama run mon-modele-ramOption B : Cacher le matériel (Linux / Docker)
Vous pouvez démarrer le serveur en masquant vos cartes graphiques :
export CUDA_VISIBLE_DEVICES="" && ollama serve(Si vous utilisez Docker, lancez simplement le conteneur sans passer le paramètre --gpus).
Améliorer la réactivité CPU grâce au mmap
Par défaut, Ollama utilise le memory-mapping (mmap) pour lire les modèles dans la RAM. C’est pratique car le modèle se lance instantanément, mais si vous avez des disques durs un peu lents, cela peut créer des saccades affreuses en cours d’utilisation.
Si vous disposez de beaucoup de RAM système libre, vous pouvez désactiver ce comportement dans votre Modelfile :
FROM llama3.1
# Désactive le mapping standard pour forcer le chargement complet en mémoire RAM au démarrage
PARAMETER mmap 0Le pour : La génération de texte est bien plus stable sur CPU.
Le contre : Le modèle mettra beaucoup plus de temps à réagir lors de votre tout premier prompt (le temps de charger la totalité du fichier en mémoire vive).
Note réaliste sur les perfs : Même si vous avez de la RAM DDR5 ultra rapide, la bande passante de la RAM système n’a rien à voir avec celle d’une carte graphique. Attendez-vous à tourner péniblement entre 2 et 7 tokens par seconde en mode CPU pur.
🔍 Résolution des problèmes : Pourquoi Ollama boude mon GPU ?
Si vous lancez un modèle léger et qu’ollama ps vous affiche désespérément 100% CPU, ou que vos temps de réponse sont catastrophiques, suivez cette checklist de secours.
Étape 1 : Le diagnostic initial
Vérifiez l’affichage de la commande ollama ps pendant une génération.
- Si c’est un pourcentage mixte (ex. 60% CPU / 40% GPU), pas de panne : c’est simplement que votre modèle dépasse les capacités de votre VRAM actuelle. Réduisez le contexte ou prenez un modèle plus compressé (quantifié en 4-bit).
- Si c’est écrit 100% CPU, Ollama ne voit pas du tout votre carte graphique au démarrage.
Étape 2 : Vérification des pilotes et couches logicielles
- Pour les cartes NVIDIA :
Lancez la commande :
nvidia-smiSi la commande renvoie une erreur, vos pilotes graphiques système ont un problème. Faites une réinstallation propre des pilotes propriétaires NVIDIA les plus récents.
Le bug Linux classique : Sur Linux, après une mise en veille (suspend), le lien UVM (Unified Video Memory) d’NVIDIA a tendance à planter, bloquant l’accès CUDA pour Ollama. Vous pouvez résoudre ça en rechargeant le module à chaud :
sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm
sudo systemctl restart ollama- Pour les cartes AMD (Linux) :
Assurez-vous d’avoir installé la suite ROCm d’AMD. Si vous utilisez une carte grand public (Radeon non certifiée pro), Ollama va l’ignorer d’office. Pour contourner ce problème, forcez l’usurpation de version matérielle avant de lancer le serveur :
export HSA_OVERRIDE_GFX_VERSION=10.3.0
ollama serveÉtape 3 : Docker et variables d’environnement sournoises
Si vous tournez sous Docker, vérifiez bien deux choses :
- Avez-vous écrit l’option
--gpus alldans votre commande de lancement ? - Avez-vous installé le paquet
nvidia-container-toolkitsur votre système hôte ? Sans ce toolkit, Docker ignorera tout simplement l’accès à la carte graphique.
Pensez également à vérifier que vous n’avez pas une variable d’environnement oubliée dans vos fichiers de configuration système (comme un CUDA_VISIBLE_DEVICES="" ou réglé à -1) qui rendrait votre GPU invisible pour l’application.
Étape 4 : L’inspection finale des logs
Si rien ne marche, lancez manuellement le serveur Ollama en avant-plan pour lire ses logs en direct :
ollama serve(Vous pouvez aussi activer les logs détaillés en tapant d’abord export OLLAMA_DEBUG=1).
Lisez attentivement les vingt premières lignes d’initialisation. Si vous voyez passer un message d’avertissement du genre "no NVIDIA GPU detected" ou "cannot look up libnvidia-ml.so", vous saurez exactement quel chemin de bibliothèque dynamique ou quel pilote est actuellement corrompu sur votre machine.