Optimisation des performances Ollama : guide complet quantification, batch et mémoire

Mise à jour du 2026-06-08 : variables d’environnement revérifiées dans la doc officielle Ollama — les couches GPU se règlent via l’option de modèle num_gpu (OLLAMA_GPU_LAYERS n’existe pas) ; réservez de la VRAM avec OLLAMA_GPU_OVERHEAD (octets) ; la quantification du KV cache utilise OLLAMA_KV_CACHE_TYPE. Les benchmarks sont indicatifs et varient selon la version et le matériel.

Votre modèle 14B tourne, mais la vitesse d’inférence n’atteint que 10 tokens/s ? Ou pire, OOM et crash direct ? Le ventilateur GPU hurle, l’écran devient noir.

Scénario classique : vous téléchargez llama3 8B avec enthousiasme, vous lancez ollama run, et la VRAM ne suffit pas. Soit erreur et arrêt, soit une lenteur insupportable. Vous passez à une version Q4 quantifiée — ça tourne, mais vous vous demandez : quelle perte de qualité au juste ?

Au début avec Ollama, j’ai fait ces erreurs : 8 Go de VRAM pour un 14B, en pensant naïvement que démarrer suffisait. Résultat : CUDA out of memory, ou un mot à la fois.

Le problème n’est pas le matériel. C’est la configuration.

Cet article couvre trois leviers d’optimisation : choix de quantification, batch, réglage mémoire. Maîtrisez-les et les performances de votre LLM local peuvent facilement doubler — pas du marketing, de vrais tokens/s en plus.

1. Quantification — compromis qualité/vitesse de Q4 à FP16

1.1 Qu’est-ce que la quantification ? Pourquoi GGUF domine

En clair : la quantification « compresse » le modèle.

Un grand modèle téléchargé a des paramètres en FP16 (flottants 16 bits). Un 7B en FP16 : 14 Go de VRAM rien que pour les poids. En passant de 16 à 4 bits par paramètre ? Théoriquement ~3,5 Go. Moins de bits pour représenter les valeurs → moins de mémoire et inférence plus rapide.

Contrepartie : perte de précision. Comme une photo 4K en 720p — des détails manquent, mais ça reste utilisable.

GGUF est devenu standard pour une raison : simplicité. Format conçu par l’équipe llama.cpp, avec mmap : le modèle n’est pas entièrement chargé en RAM, lecture à la demande. Une machine 16 Go peut donc faire tourner un 13B — impensable avec les formats traditionnels.

1.2 Types de quantification : Q4_0, Q4_K_M, Q5_K_M, Q8_0

Q4_0, Q4_1, Q4_K_M, Q5_K_M, Q8_0… lequel choisir ?

Tableau comparatif des types courants :

Type	Ratio compression	Mémoire (modèle 7B)	Perte qualité	Cas d’usage
Q4_0	~4,5x	~4,0 Go	Importante	VRAM très limitée, qualité secondaire
Q4_K_M	~4,5x	~4,7 Go	Très faible	Meilleur rapport qualité/prix, recommandé au quotidien
Q5_K_M	~3,5x	~5,8 Go	Minime	Qualité prioritaire, VRAM suffisante
Q8_0	~2x	~7,2 Go	Quasi nulle	Meilleure qualité, grosse VRAM
FP16	1x	~14 Go	Aucune	Recherche, GPU haut de gamme

En bref : Q4_K_M est le meilleur compromis — perte à peine perceptible, empreinte mémoire minimale. En tests répétés, l’écart Q4_K_M / FP16 ne se voit pas au quotidien sans comparaison serrée.

Q5_K_M si vous avez de la marge VRAM et exigez la qualité. Q8_0 seulement avec 24 Go+ de VRAM — autant viser un modèle plus gros.

1.3 Arbre de décision quantification

Logique simple :

Étape 1 : VRAM

• VRAM ≤ 8 Go : Q4_K_M seulement ; 7B limite, 14B avec CPU offload
• VRAM 12–16 Go : Q4_K_M pour 14B ; Q5_K_M possible pour 7B
• VRAM ≥ 24 Go : Q5_K_M ou Q8_0 ; voire 70B

Étape 2 : besoin

• Dialogue, code : Q4_K_M suffit
• Traduction, rédaction sensible : Q5_K_M
• Recherche, benchmarks : Q8_0 ou FP16

Ordres de grandeur :

• 7B Q4_K_M : ~4,7 Go VRAM
• 14B Q4_K_M : ~9 Go VRAM
• 70B Q4_K_M : ~40 Go VRAM

Conseil : commencez par Q4_K_M. Si la qualité vous gêne, passez à Q5_K_M. Ne visez pas « sans perte » d’emblée — souvent c’est psychologique.

1.4 Télécharger une version quantifiée précise

Ollama télécharge Q4_K_M par défaut. Autre version ?

# Par défaut Q4_K_M
ollama run llama3

# Q5 explicite
ollama run llama3:70b-q5

# Q8 explicite
ollama run llama3:70b-q8

Tous les modèles n’ont pas toutes les quantifications. Consultez la bibliothèque Ollama ou :

# Modèles locaux
ollama list

# Détails (dont quantification)
ollama show llama3 --modelfile

Usage intensif : quantifier vous-même via llama.cpp — avancé, hors scope ici.

2. Configuration batch — débit +50 à 150 %

2.1 Principe : pourquoi ça accélère ?

Image : caisse supermarché. Un client à la fois = scans répétés, faible débit. Dix paniers d’un coup = gestes fluides, meilleur rendement.

Même logique GPU : token par token, le GPU attend souvent la mémoire — unités de calcul sous-utilisées. Le batch regroupe plusieurs tokens pour saturer le GPU.

Le batch augmente le débit, pas la latence d’une requête isolée. Peu visible seul ; en API multi-requêtes, le gain peut doubler ou plus.

2.2 Paramètre num_batch

num_batch est le cœur du batch Ollama, défaut 512.

Plus la valeur est haute, meilleure utilisation GPU et débit — au prix de +20 à 40 % de VRAM.

Situation VRAM	num_batch conseillé	Effet attendu
Serrée	512 (défaut)	Sûr, GPU parfois idle
Moyenne	1024	Débit +50–80 %
Large	2048	Débit +100–150 %

Retour d’expérience : RTX 3080 (10 Go), 7B Q4_K_M, num_batch 1024 stable ; 2048 déclenche parfois OOM. RTX 4090, 14B, 2048 sans souci.

2.3 num_ctx et KV Cache

num_ctx = taille de fenêtre contextuelle, défaut 2048. Impact principal : mémoire KV Cache.

Le KV Cache stocke les calculs passés pour éviter de recalculer. Contexte long → cache volumineux.

Formule approximative :

Mémoire KV Cache ≈ 2 × couches × dim cachée × num_ctx × octets précision

Exemples :

• 7B, num_ctx=4096 : +1–2 Go
• 14B, num_ctx=8192 : +3–4 Go

Contexte 32K/128K : la VRAM grimpe vite. Souvent ce n’est pas les poids mais le KV Cache qui mange la mémoire.

Piège : certains modèles (ex. llama3 jusqu’à 128K) — à cette taille, VRAM saturée. Au quotidien, 4096 ou 8192 suffisent.

2.4 Mise en pratique batch

Méthode 1 : Modelfile

# Depuis le modèle de base
FROM llama3

# Taille batch
PARAMETER num_batch 1024

# Fenêtre contextuelle
PARAMETER num_ctx 4096

# Conserver le prompt système
PARAMETER num_keep 128

Enregistrez Modelfile, puis :

ollama create my-llama3 -f Modelfile
ollama run my-llama3

Méthode 2 : options API

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Expliquez le calcul quantique",
  "options": {
    "num_batch": 1024,
    "num_ctx": 4096
  }
}'

Comparatif (RTX 3080, 7B Q4_K_M) :

num_batch	Débit (tokens/s)	VRAM
512	45	5,2 Go
1024	72	6,1 Go
2048	98	7,4 Go

512 → 1024 : +60 % de débit pour moins de 1 Go VRAM en plus. Bon deal.

3. Réglage mémoire — trois stratégies OOM

3.1 Allocation mémoire GPU

Ollama gère la VRAM intelligemment :

1. Assez de place pour le modèle ?
2. Oui → tout sur GPU
3. Non → offload partiel CPU

Pas infaillible : erreurs de jugement ou cas limites → OOM.

Paramètre clé : num_gpu. Couches sur GPU ; défaut -1 = auto. Ex. num_gpu: 20 = 20 premières couches GPU, reste CPU.

3.2 Stratégie 1 : downgrade quantification

Le plus direct. OOM ? Quantification plus légère.

Chemin :

Q8_0 → Q5_K_M → Q4_K_M → Q4_0

Chaque palier : ~20–25 % VRAM en moins.

Exemple : 14B Q5_K_M ~11 Go, OOM → Q4_K_M ~9 Go (−18 %). Perte qualité difficile à voir au dialogue.

Sur 8 Go, 7B Q4_K_M OK ; 14B Q4_K_M limite, gros contexte → OOM. Compromis : 14B Q4_0, qualité un peu moindre mais utilisable.

3.3 Stratégie 2 : inférence hybride CPU offload

VRAM insuffisante ? Partagez avec le CPU.

num_gpu fixe les couches GPU. Modèle 32 couches, num_gpu: 24 → 8 couches CPU.

Coût : vitesse. CPU ~10× plus lent que GPU — mieux que crash.

Modelfile :

# Modelfile
FROM llama3
PARAMETER num_gpu 24

Ou API :

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Bonjour",
  "options": {
    "num_gpu": 24
  }
}'

Vitesse hybride (14B Q4_K_M, RTX 3080 10 Go + i7-12700K) :

num_gpu	Vitesse	VRAM
40 (GPU total)	OOM	12 Go (dépassement)
30	18 tokens/s	9,2 Go
20	12 tokens/s	6,5 Go
0 (CPU seul)	4 tokens/s	0,5 Go

num_gpu=30 : vitesse acceptable, pas d’OOM — intérêt de l’hybride.

3.4 Stratégie 3 : optimiser KV Cache

Souvent négligé, gros consommateur VRAM.

Méthode 1 : Flash Attention

Attention optimisée, moins de mémoire KV.

# Variable d'environnement
export OLLAMA_FLASH_ATTENTION=1

# Ou Docker
docker run -e OLLAMA_FLASH_ATTENTION=1 ollama/ollama

Effet : KV Cache −30 à 50 %. Fortement recommandé.

Méthode 2 : réduire num_ctx

Contexte long = cache lourd. Sans besoin 32K, réduisez.

PARAMETER num_ctx 2048  # défaut 2048, suffisant au quotidien

Méthode 3 : num_keep pour le prompt système

num_keep = tokens conservés (non tronqués). Alignez sur la longueur du prompt système.

PARAMETER num_keep 128

3.5 Procédure OOM en pratique

Étape 1 : VRAM

nvidia-smi

Étape 2 : paramètres modèle

ollama show llama3 --modelfile

Vérifiez num_ctx, num_batch, etc.

Étape 3 : downgrade progressif

• num_batch : 1024 → 512
• num_ctx : 4096 → 2048
• quantification : Q5_K_M → Q4_K_M

Étape 4 : CPU offload
num_gpu ≈ 70–80 % du total de couches.

Étape 5 : CPU pur

# Forcer le CPU pur via l'option de modèle num_gpu=0 (API ou Modelfile)
curl http://localhost:11434/api/generate -d '{"model":"llama3","prompt":"bonjour","options":{"num_gpu":0}}'

CPU pur ~1/10 de la vitesse GPU — acceptable pour usage occasionnel ou batch.

4. Benchmarks et matériel

4.1 Vitesse d’inférence par hardware

GPU NVIDIA (7B Q4_K_M)

Carte	VRAM	tokens/s	Note
RTX 3060	12 Go	52	Excellent rapport
RTX 3080	10 Go	68	Choix stable
RTX 3090	24 Go	95	14B Q4 possible
RTX 4070 Ti	12 Go	78	Architecture récente
RTX 4090	24 Go	120	Haut de gamme

GPU NVIDIA (14B Q4_K_M)

Carte	VRAM	tokens/s	Note
RTX 3060	12 Go	28	Limite
RTX 3080	10 Go	OOM	CPU offload requis
RTX 3090	24 Go	55	Confortable
RTX 4090	24 Go	72	Très rapide

Apple Silicon (Metal)

Appareil	Mémoire	7B tokens/s	14B tokens/s
M2 Air 8 Go	8 Go	35	OOM
M2 Pro 16 Go	16 Go	48	22
M2 Max 32 Go	32 Go	58	32
M2 Ultra 64 Go	64 Go	65	45

Mémoire unifiée = grosse VRAM effective ; perf unitaire inférieure aux GPU haut de gamme.

CPU seul

CPU	RAM	7B tokens/s	14B tokens/s
i7-12700K	32 Go	6	3
Ryzen 9 7950X	64 Go	8	4
M2 Max (CPU only)	32 Go	12	6

Lent ; adapté au batch, pas au temps réel.

4.2 Impact num_batch sur le débit

Environnement : RTX 3080, 7B Q4_K_M, requêtes concurrentes

num_batch	Latence/requête	Débit concurrent	VRAM
512	22 ms/token	45 tokens/s	5,2 Go
1024	22 ms/token	72 tokens/s	6,1 Go
2048	22 ms/token	98 tokens/s	7,4 Go

Points clés :

• Latence unitaire quasi inchangée
• Débit doublé : 2048 vs 512 → +118 % en concurrence
• Coût VRAM maîtrisé : +118 % pour +2,2 Go

4.3 Variables d’environnement

# Flash Attention (fortement recommandé)
export OLLAMA_FLASH_ATTENTION=1

# Quantification du KV cache : f16(défaut)/q8_0(~moitié)/q4_0(~quart), nécessite Flash Attention
export OLLAMA_KV_CACHE_TYPE=q8_0

# Réserver de la VRAM pour le système/autres apps (octets, défaut 0)
export OLLAMA_GPU_OVERHEAD=1073741824  # réserver 1 Go

# Durée keep-alive modèle (défaut 5 min)
export OLLAMA_KEEP_ALIVE=24h

# Longueur de contexte par défaut (remplace celle du modèle)
export OLLAMA_CONTEXT_LENGTH=4096

# Limite requêtes concurrentes
export OLLAMA_MAX_QUEUE=512

# Niveau log
export OLLAMA_DEBUG=1

Exemple Docker Compose :

version: '3'
services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    restart: unless-stopped
    environment:
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_MAX_QUEUE=512
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  ollama_data:

Enregistrez docker-compose.yml, puis :

docker-compose up -d

À lire aussi

• Guide complet d’accélération GPU pour Ollama
• Embeddings locaux et RAG avec Ollama
• Llama 70B : guide matériel pour modèles locaux

Synthèse

Trois étapes :

1. Quantification
Selon VRAM ; Q4_K_M en premier choix. Q5_K_M si marge.

2. Batch
VRAM disponible → num_batch 1024 ou 2048. Débit doublé, un peu plus de VRAM.

3. OOM
Flash Attention, num_ctx réduit, CPU offload — dans cet ordre.

L’optimisation est itérative : matériel, taille de modèle et usage diffèrent. Quantification d’abord, batch ensuite, variables avancées en dernier.

Question précise sur un modèle ou une erreur ? Commentaires ou doc Ollama — la communauté partage beaucoup d’expérience concrète.