Comment j’ai enfin compris les GPU layers sur Ollama (et pourquoi votre modèle rame probablement sur le CPU)

Franchement, au début, je ne comprenais pas pourquoi mon Llama 3.1 ramait autant sur ma bécane alors que j’ai une configuration plutôt correcte. Je lançais une commande, et j’avais le temps de me faire un café avant d’avoir une réponse complète.

En creusant les logs, je suis tombé sur le grand secret de l’optimisation d’Ollama : le “layer offloading” (le déchargement des couches du modèle). Si vous galérez avec des temps de génération infinis, voici un retour d’expérience pour régler ça une bonne fois pour toutes.

Le goulot d’étranglement du CPU (le piège classique)

Par défaut, Ollama essaie de faire de la magie en tâche de fond. Il calcule la VRAM disponible sur votre carte graphique et tente d’y charger le maximum de couches du modèle. S’il n’y a pas assez de place, il bascule gentiment le reste des couches sur votre processeur (le CPU).

Le problème ? Dès qu’une seule couche — oui, juste une seule (parce que les données doivent faire des allers-retours constants sur le bus système) — est déchargée sur le CPU, les performances s’effondrent.

Pour vérifier si vous êtes victime de ça : lancez une génération de texte et tapez immédiatement nvidia-smi (si vous êtes chez Nvidia) ou rocm-smi (chez AMD) dans un second terminal. Si l’utilisation de votre VRAM est basse mais que votre CPU système hurle à 100 %, cherchez pas : Ollama a déchargé trop de couches sur votre processeur.

Comment trouver votre “Sweet Spot” sans s’épuiser

Créer un Modelfile à chaque fois qu’on veut tester un réglage, c’est d’un relou sans nom. Heureusement, il y a une méthode beaucoup plus rapide en passant par la simulation en direct.

Étape 1 : La simulation interactive
Lancez votre modèle normalement :

ollama run llama3.1

Directement dans le chat d’Ollama, vous pouvez surcharger les paramètres à la volée avec la commande /set. Par exemple :

>>> /set parameter num_gpu 32

(Remplacez 32 par votre estimation ou par le nombre total de couches de votre modèle). Envoyez ensuite un long prompt pour tester la réaction du système.

Pendant que ça tourne, ouvrez un autre terminal pour surveiller la mémoire :

• Nvidia : watch -n 0.5 nvidia-smi
• AMD : watch -n 0.5 rocm-smi
• Mac (Silicon) : sudo powermetrics

Ajustez ce nombre en augmentant ou en baissant de 2 ou 3 couches jusqu’à ce que votre VRAM se stabilise idéalement entre 90 % et 95 % sans crasher.

Étape 2 : Analyser les logs pour être précis
Si vous voulez savoir exactement combien de couches physiques possède votre modèle pour ne pas avancer à l’aveugle, lancez le modèle une fois et allez voir les logs d’arrière-plan d’Ollama.

• Sur Linux : journalctl -u ollama --no-pager -n 50
• Sur Windows/Mac : Regardez le fichier log du serveur via l’icône dans la barre des tâches.

Cherchez une ligne qui ressemble à ça :

llm_load_tensors: ggml ctx size =    0.11 MiB
...
gpu layers = 22/32

Ici, le modèle a 32 couches au total, et Ollama en a alloué automatiquement 22 sur le GPU. Sachant que le maximum est 32, vous pouvez tenter une simulation à num_gpu 26 ou 28 pour voir si ça passe en VRAM.

Étape 3 : Le coup de grâce avec ollama ps
Pendant que votre invite interactive tourne, ouvrez un autre terminal et tapez :

ollama ps

Si la colonne “PROCESSOR” affiche 100% GPU, vous avez gagné. Si vous voyez un truc du genre 85% GPU, 15% CPU, ajustez encore votre paramètre num_gpu vers le haut.

Fixer le réglage proprement

Une fois que vous avez identifié le nombre parfait de couches à envoyer sur votre GPU sans faire planter votre machine (erreur Out of Memory), créez un fichier texte nommé Modelfile (sans extension) :

FROM llama3.1
PARAMETER num_gpu VOTRE_NOMBRE_OPTIMAL

(Petite astuce : mettre PARAMETER num_gpu 0 force le modèle à tourner à 100 % sur le CPU, tandis que mettre PARAMETER num_gpu 999 force le chargement de toutes les couches sur le GPU en ignorant les limites de sécurité d’Ollama).

Ensuite, compilez votre modèle personnalisé :

ollama create mon-modele-optimise -f ./Modelfile
ollama run mon-modele-optimise

Le cas du Multi-GPU

Si vous avez la chance d’avoir plusieurs cartes graphiques, Ollama gère cela plutôt bien par défaut avec une stratégie de remplissage séquentiel (il sature le GPU 0, puis déborde sur le GPU 1, etc.).

• Le trick du 999 : Si vous voulez forcer Ollama à utiliser l’intégralité de vos cartes sans qu’aucune couche ne glisse sur le CPU, mettez simplement PARAMETER num_gpu 999 dans votre Modelfile. Il va automatiquement répartir les couches sur toutes vos cartes physiques détectées.
• Équilibrer la charge : Si vous préférez répartir les couches équitablement entre vos cartes au lieu de saturer la première, utilisez la variable d’environnement OLLAMA_SCHED_SPREAD=1 au démarrage d’Ollama.
• Isoler une carte (pour jouer ou bosser à côté) : Si vous voulez masquer une carte pour qu’Ollama ne la touche pas, définissez CUDA_VISIBLE_DEVICES (Nvidia) ou HIP_VISIBLE_DEVICES (AMD).
  • Sur Linux, faites un sudo systemctl edit ollama.service et ajoutez Environment="CUDA_VISIBLE_DEVICES=1" sous le bloc [Service] pour n’utiliser que votre deuxième carte.
  • Sur Windows, configurez cela directement dans les Variables d’Environnement Système avant de relancer Ollama depuis la barre des tâches.
  • Sur Mac (puces M Max/Ultra), pas besoin de vous prendre la tête, macOS gère la mémoire unifiée de manière transparente.

Les erreurs typiques et comment s’en sortir

À force de bidouiller les couches, vous allez forcément tomber sur l’un de ces messages d’erreur :

1. “CUDA error: out of memory” (OOM) : Vous avez été trop gourmand sur le nombre de couches, ou alors votre contexte de discussion a gonflé pendant l’utilisation et a saturé la VRAM restante. Baissez le num_gpu, ou réduisez la taille du contexte dans votre Modelfile avec PARAMETER num_ctx 4096. Vous pouvez aussi allouer une marge de sécurité au démarrage en définissant la variable OLLAMA_GPU_OVERHEAD=512MiB.
2. “500: memory layout cannot be allocated” : Cela arrive souvent en multi-GPU quand on jongle entre plusieurs gros modèles. La VRAM se fragmente et Ollama perd les pédales. La solution est radicale mais efficace : redémarrez le démon/serveur Ollama (sudo systemctl restart ollama sur Linux ou quittez/relancez l’appli sur Windows/Mac).
3. “ggml_cuda_host_malloc: failed to allocate pinned memory” : Votre système n’a plus assez de RAM physique libre pour créer la passerelle de communication rapide avec la VRAM du GPU. Fermez les applications lourdes en arrière-plan (bonjour Chrome et les IDE) ou passez sur une quantification de modèle plus agressive (une version Q4_K_M au lieu d’une Q8 par exemple).
4. “gpu layers = 0/… (Reverted to CPU Only)” : Ollama détecte bien votre carte graphique mais décide de l’ignorer totalement. C’est presque toujours un problème de pilotes obsolètes par rapport à la version de CUDA requise. Mettez vos drivers à jour. Si vous tournez sous Docker, vérifiez bien que le NVIDIA Container Toolkit est correctement installé et configuré, sinon le conteneur ne verra jamais vos puces physiques.