Quand j’ai commencé à faire tourner mes premiers modèles de langage en local avec Ollama, j’ai vite compris que la vitesse de génération n’était pas le fruit du hasard. Pour obtenir des réponses fluides, tout repose sur une règle d’or : faire tenir l’intégralité des poids du modèle dans la mémoire VRAM de votre carte graphique et ajuster intelligemment les paramètres de contexte.
Dès qu’un modèle dépasse cette capacité, Ollama est contraint de déverser une partie des couches dans la mémoire RAM du système ou sur le disque de stockage, ce qui provoque une chute brutale des performances.
Voici les étapes indispensables que j’applique pour optimiser les performances, classées des plus cruciales aux plus avancées.
L’essentiel pour maximiser la vitesse
- Faire tenir le modèle dans la VRAM : C’est la condition absolue pour exploiter la puissance des cartes graphiques dédiées (NVIDIA, AMD ou Apple Silicon).
- Réduire la fenêtre de contexte : Un historique de conversation trop volumineux ralentit considérablement la génération de chaque token.
- Garder le modèle chargé en mémoire : Éviter le délai de chargement initial (cold load) lors de requêtes successives.
- Activer l’Attention Flash : Optimiser mathématiquement le calcul du contexte pour accélérer le traitement.
1. Veiller à ce que le modèle s’intègre parfaitement dans la VRAM
Si vous possédez un GPU dédié, vous n’obtiendrez une vitesse d’exécution élevée que si le modèle réside intégralement dans sa mémoire dédiée.
Pour cela, j’utilise systématiquement des versions quantifiées des modèles (comme le format Q4_K_M). La quantification permet de réduire la taille du fichier d’environ 20 à 25 % tout en conservant une qualité de réponse presque identique à celle du modèle d’origine.
Il faut également adapter la taille du modèle à son matériel. Avec un GPU de 8 Go, je me cantonne à des modèles de 3 milliards (3B) ou 8 milliards (8B) de paramètres. Si l’on dispose de 12 Go à 16 Go de VRAM, on peut alors envisager des modèles de 14B. Pour savoir exactement comment Ollama répartit les couches de votre modèle, il suffit de lancer la commande ollama run [nom-du-modele] et d’observer les statistiques de chargement qui s’affichent.
Comprendre la différence entre VRAM et RAM système
Pour comprendre pourquoi ces ajustements sont si efficaces, il faut regarder ce qu’il se passe sous le capot. Un grand modèle de langage (LLM) est constitué de milliards de variables mathématiques appelées “poids”. Pour générer du texte rapidement, le système doit accéder à ces poids à des vitesses extrêmes.
La VRAM de votre carte graphique est extrêmement rapide, transférant les données à plusieurs centaines de gigaoctets par seconde (Go/s). À l’inverse, la RAM système de votre ordinateur est beaucoup plus lente (environ 50 à 100 Go/s).
Si un modèle nécessite par exemple 9 Go d’espace mais que votre carte graphique n’en possède que 8, Ollama va diviser le modèle : il placera 8 Go sur le GPU et le gigaoctet restant dans la RAM système. C’est le processeur (CPU) qui devra alors traiter ce dernier gigaoctet. Ce mécanisme de débordement crée un goulet d’étranglement majeur, capable de réduire la vitesse de génération de 80 à 90 %.
La quantification résout précisément ce problème en compressant la précision des poids (qui passent de valeurs flottantes sur 16 bits à des entiers sur 4 bits pour le format Q4_K_M). C’est ce qui permet à un modèle de 8 milliards de paramètres de passer de 16 Go à seulement 4,8 Go, le rendant ainsi parfaitement compatible avec les cartes graphiques grand public.
2. Réduire la fenêtre de contexte
La fenêtre de contexte désigne la quantité de mémoire allouée par le modèle pour stocker l’historique de la conversation en cours. À chaque fois que vous envoyez un nouveau message, Ollama ne se contente pas de lire cette phrase : il relit l’intégralité de l’historique pour garder le fil de la discussion.
Par défaut, de nombreux modèles de base s’accompagnent de fenêtres de contexte gigantesques pouvant atteindre 128 000 tokens. Si vos requêtes restent courtes, cette allocation automatique mobilise une quantité phénoménale de VRAM pour rien. En limitant manuellement cette fenêtre à 2048 ou 4096 tokens, on libère de l’espace mémoire précieux et on réduit la charge de calcul du GPU.
Pour modifier ce paramètre, il suffit de configurer la variable num_ctx 4096 dans le fichier de configuration Modelfile de votre modèle (ou directement dans votre interface utilisateur, comme Open WebUI).
3. Conserver les modèles chargés en mémoire
Par défaut, Ollama décharge automatiquement un modèle de la mémoire après 5 minutes d’inactivité. Lors de la requête suivante, il faut alors patienter durant une phase de chargement initial assez frustrante.
Je contourne ce comportement en utilisant la variable d’environnement OLLAMA_KEEP_ALIVE. En lui attribuant la valeur -1, le modèle reste stocké indéfiniment en RAM/VRAM, ce qui garantit une réponse instantanée dès la première sollicitation.
4. Activer l’Attention Flash
Sur les versions récentes d’Ollama, l’activation de l’Attention Flash permet d’accélérer significativement l’inférence tout en réduisant la consommation de mémoire.
Il suffit d’activer la variable d’environnement OLLAMA_FLASH_ATTENTION=1 dans vos paramètres système avant de lancer l’application.
5. Mettre à jour les pilotes graphiques
Pour qu’Ollama puisse détecter et exploiter pleinement l’architecture de votre carte graphique, vos pilotes doivent être parfaitement à jour :
- NVIDIA : Installez les derniers pilotes officiels ainsi que le toolkit CUDA.
- AMD : Assurez-vous d’avoir le support ROCm à jour.
- Mac (Apple Silicon) : Ollama tire automatiquement parti du GPU unifié. Cependant, je vous conseille vivement d’éviter de faire tourner Ollama dans un conteneur Docker sur Mac, car cela bloque le passthrough du GPU. Une exécution native s’avère bien plus rapide.
Comment appliquer ces variables d’environnement
Voici la marche à suivre pour configurer ces instructions de performance avant de lancer le serveur Ollama.
Sur Windows (via PowerShell) :
$env:OLLAMA_FLASH_ATTENTION="1"
$env:OLLAMA_KEEP_ALIVE="-1"
ollama serveSur Linux ou macOS (via le Terminal) :
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KEEP_ALIVE=-1
ollama serveOptimisations avancées pour aller plus loin
Pour pousser la configuration dans ses derniers retranchements et maximiser le nombre de tokens générés par seconde (t/s), on peut affiner l’architecture mémoire et la gestion de la concurrence.
Optimiser le type de cache Key-Value (KV)
Le cache KV stocke l’attention des tokens passés pour éviter de devoir les recalculer à chaque échange. Par défaut, Ollama utilise une précision f16 très gourmande en VRAM. En quantifiant ce cache, on libère de l’espace pour les modèles plus volumineux ou les contextes plus larges.
Pour cela, on utilise la variable d’environnement : OLLAMA_KV_CACHE_TYPE=q8_0 (ou q4_0 pour une empreinte encore plus faible). Ce réglage nécessite que l’Attention Flash soit préalablement activée.
Définir une marge de sécurité pour la VRAM
Si vous utilisez votre ordinateur pour l’affichage système ou d’autres applications pendant qu’Ollama génère du texte, des pics de consommation de VRAM peuvent survenir et provoquer des plantages pour manque de mémoire (OOM). Je conseille de réserver une portion de VRAM pour le système d’exploitation avec la variable OLLAMA_GPU_OVERHEAD=1073741824 (la valeur s’exprime en octets, cet exemple réserve précisément 1 Go).
Ajuster le multi-threading pour le processeur
Si un modèle déborde malgré tout dans la mémoire RAM, Ollama va solliciter votre processeur. Laisser le nombre de threads en négociation automatique peut générer des conflits d’accès et ralentir l’exécution. Il est préférable de verrouiller cette valeur sur le nombre de cœurs physiques de votre CPU moins 2 (pour laisser de la marge au système) : OLLAMA_NUM_THREADS=6 (à adapter à votre processeur).
Gérer la concurrence et les accès parallèles
Si plusieurs requêtes arrivent simultanément sur votre serveur Ollama, les performances peuvent s’effondrer :
- OLLAMA_NUM_PARALLEL : Définit le nombre d’emplacements d’attention disponibles pour traiter des requêtes en parallèle. Attention, augmenter cette valeur multiplie le besoin en VRAM par la longueur du contexte.
- OLLAMA_MAX_LOADED_MODELS : Détermine combien de modèles différents restent chargés simultanément en mémoire. Si vous n’utilisez qu’un seul modèle à la fois, fixez cette variable à 1 pour éviter qu’un second modèle ne vienne encombrer la mémoire.
Tableau de synthèse des variables avancées
| Variable | Valeur recommandée | Impact sur les performances |
|---|---|---|
OLLAMA_FLASH_ATTENTION | 1 | Accélère significativement les calculs sur les contextes longs. |
OLLAMA_KV_CACHE_TYPE | q8_0 | Compresse l’historique des tokens pour économiser de la VRAM. |
OLLAMA_GPU_OVERHEAD | 1073741824 | Conserve 1 Go de VRAM pour préserver la stabilité du système. |
OLLAMA_NUM_THREADS | Nombre de cœurs physiques – 2 | Évite les conflits de threads lors du calcul CPU. |
OLLAMA_MAX_LOADED_MODELS | 1 | Empêche les modèles secondaires de saturer la RAM. |
Rendre ces variables persistantes sous Linux (systemd)
Sur Linux, configurer ces variables dans le fichier .bashrc ne suffit pas pour le service s’exécutant en arrière-plan. Il faut modifier la configuration du service système :
sudo systemctl edit ollama.serviceDans l’éditeur qui s’ouvre, insérez les lignes suivantes sous la section [Service] :
[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_GPU_OVERHEAD=1073741824"Enregistrez le fichier, fermez l’éditeur, puis rechargez la configuration pour appliquer les changements :
sudo systemctl daemon-reload
sudo systemctl restart ollamaCréer un Modelfile optimisé pour la vitesse
Pour éviter d’avoir à configurer ces options au niveau du système, j’intègre souvent ces paramètres directement au sein d’un fichier Modelfile personnalisé. Le modèle appliquera ainsi ces optimisations de manière autonome à chaque démarrage.
Voici le modèle de fichier de configuration que j’utilise :
# 1. SPECIFIER LE MODELE DE BASE
FROM llama3.1:8b
# 2. PARAMETRES DE PERFORMANCE AU RUNTIME
PARAMETER flash_attention true
PARAMETER num_ctx 4096
PARAMETER num_parallel 1
PARAMETER num_gpu -1
# 3. SECURITE POUR LE DEBORDEMENT CPU (si dépassement de VRAM)
PARAMETER num_thread 6
# 4. TEMPERATURE ET CREATIVITE
PARAMETER temperature 0.7
PARAMETER top_p 0.9Une fois ce fichier enregistré sous le nom Modelfile (sans extension) dans votre dossier de travail, vous pouvez générer et lancer votre version optimisée avec ces commandes :
ollama create modele-optimise -f ./Modelfile
ollama run modele-optimiseCe modèle personnalisé s’exécute plus rapidement car :
num_gpu -1force Ollama à exploiter pleinement la carte graphique sans chercher à réserver des couches par précaution pour le processeur.num_ctx 4096maintient l’empreinte mémoire dans des limites prévisibles, évitant l’expansion exponentielle de la mémoire.num_parallel 1concentre l’intégralité de la puissance de calcul du GPU sur une seule conversation à la fois.
Diagnostiquer et résoudre les lenteurs soudaines
Si la vitesse de génération est correcte au départ mais chute soudainement ou se fige, cela s’explique généralement par un débordement vers le processeur ou par une mauvaise configuration du streaming de l’API.
Utiliser la commande de diagnostic ollama ps
Pendant que le modèle génère une réponse lente, ouvrez un autre terminal et saisissez :
ollama psAnalysez attentivement les données de la colonne “Processor” :
- 100% GPU : Le modèle réside entièrement dans la mémoire graphique. La lenteur provient probablement de votre application ou de l’interface utilisateur.
- 100% CPU ou un ratio mixte (ex: 70% GPU / 30% CPU) : Vous subissez un goulet d’étranglement mémoire. Même une faible sollicitation du processeur (10 %) dégrade la vitesse d’affichage d’environ 80 %. Pour y remédier, passez à un modèle comprenant moins de paramètres (par exemple de Llama 3 8B à Llama 3.2 3B) ou optez pour une quantification plus agressive comme q4_0.
Activer le streaming de l’API
Lorsque vous interrogez Ollama via un script Python ou une requête HTTP sans activer le streaming, l’API attend que l’intégralité de la réponse soit rédigée avant de renvoyer le texte. Cela peut donner l’impression d’un blocage complet durant de longues secondes.
Pour éviter cela, veillez à passer explicitement le paramètre de streaming dans le corps de votre requête :
{
"model": "llama3.2",
"prompt": "Pourquoi l'eau est-elle mouillée ?",
"stream": true
}Le cas des modèles de raisonnement (Reasoning Models)
Les modèles orientés vers le raisonnement (comme DeepSeek-R1 ou certaines déclinaisons de Qwen 2.5 Coder) effectuent une phase de réflexion interne invisible avant d’afficher leur réponse définitive. Si votre interface (comme Open WebUI) n’affiche pas par défaut ces étapes de réflexion, l’écran restera totalement vide pendant de longs instants alors que le GPU travaille à plein régime.
Pensez à activer l’option d’affichage de la pensée (“Show Thinking”) dans l’interface ou utilisez une déclinaison de modèle classique pour obtenir un retour textuel immédiat.
Surveiller la température du matériel
Sur les ordinateurs portables, si la baisse de vitesse survient après quelques requêtes rapides, il s’agit souvent d’une régulation thermique (thermal throttling). Les composants graphiques réduisent automatiquement leur fréquence de fonctionnement dès qu’ils franchissent le cap des 85 °C pour éviter tout dommage physique.
Sur les configurations NVIDIA, vous pouvez surveiller l’évolution des températures en temps réel avec la commande nvidia-smi -l 1. Surélever légèrement l’arrière de la machine ou utiliser un support ventilé aide généralement à maintenir de meilleures fréquences de fonctionnement.
Sélectionner le modèle le plus rapide selon votre configuration
Le choix du modèle le plus véloce dépend de vos objectifs de performance et de votre équipement matériel.
Pour une vitesse brute maximale (Modèles de moins de 4B)
Si vous recherchez un affichage instantané de l’ordre de 60 à plus de 100 tokens par seconde sur du matériel grand public, orientez-vous vers des modèles très légers comme gemma3:4b ou phi4-mini:3.8b. Leur faible empreinte leur permet de résider en totalité dans la mémoire cache de votre processeur graphique.
La meilleure option sur Mac Apple Silicon
Grâce aux optimisations de l’architecture de mémoire partagée des puces M-Series, les versions de gemma4 se montrent particulièrement performantes. Ollama y intègre la prédiction multi-token (MTP), qui permet de générer des tokens prévisionnels en parallèle pour obtenir un gain de vitesse de près de 90 % par rapport aux méthodes classiques.
L’alternative pour les GPU de bureau (RTX / AMD)
Si vous possédez une carte graphique de milieu ou haut de gamme (RTX 4060 ou supérieure), l’architecture Mixture-of-Experts (MoE) de modèles comme qwen3:30b-a3b ou qwen3-coder:30b offre un excellent compromis. Bien qu’il s’agisse sur le papier d’un modèle de 30 milliards de paramètres, il n’en active que 3,3 milliards par token généré. Vous profitez ainsi de la pertinence d’un grand modèle avec la réactivité d’une version très légère.
L’option accélérée par le cloud
Si vos contraintes matérielles locales ne vous permettent pas d’obtenir des temps de réponse satisfaisants, le modèle gpt-oss:20b (via Ollama Turbo) redirige vos instructions vers des nœuds de calcul distants optimisés, permettant d’atteindre des débits supérieurs à 300 tokens par seconde.
Aide-mémoire des vitesses par modèle
| Modèle | VRAM requise | Vitesse estimée | Usage recommandé |
|---|---|---|---|
gemma3:4b | ~3 Go | 70 – 110 t/s | Traitement de texte simple, configurations légères |
phi4-mini | ~3,5 Go | 60 – 95 t/s | Calculs mathématiques et logique sur PC portables |
qwen3-coder:30b | ~19 Go | 40 – 55 t/s (MoE) | Développement logiciel et raisonnement complexe |
gemma4 (Mac) | RAM unifiée | Gain jusqu’à 90 % (MTP) | Agents multilingues, écosystème Apple |