Vous avez téléchargé Gemma 4, lancé l'exécution, et... c'est douloureusement lent. Peut-être 2 tokens par seconde. Peut-être pire. Avant de blâmer le modèle, cherchons ce qui ne va vraiment pas — car dans la plupart des cas, quelques ajustements de configuration peuvent multiplier votre vitesse par 5 à 10.
Étape 1 : Diagnostiquer pourquoi c'est lent
Il y a cinq raisons courantes pour lesquelles Gemma 4 tourne plus lentement que prévu. Vérifions chacune.
Raison 1 : Fallback sur CPU
C'est le tueur de performance numéro un. Votre modèle tourne sur CPU au lieu du GPU, et vous ne le réalisez peut-être même pas.
Comment vérifier :
# Mac : Moniteur d'activité → Historique GPU (menu Fenêtre)
# Ou vérifier si Metal est utilisé :
sudo powermetrics --samplers gpu_power -n 1
# NVIDIA : L'utilisation GPU devrait être > 0 %
nvidia-smi
# AMD : Même vérification
rocm-smiSi l'utilisation GPU reste à 0 % pendant l'inférence, vous êtes sur CPU. Corrigez ça en premier — rien d'autre ne compte tant que l'accélération GPU ne fonctionne pas.
Raison 2 : Mauvaise quantification
Toutes les quantifications ne se valent pas en termes de vitesse :
| Quantification | Taille fichier (12B) | Vitesse | Qualité | Idéal pour |
|---|---|---|---|---|
| Q4_K_M | ~7 Go | La plus rapide | Bonne | Usage quotidien, la plupart des tâches |
| Q5_K_M | ~8,5 Go | Rapide | Meilleure | Quand la qualité compte |
| Q6_K | ~10 Go | Moyenne | Très bonne | Équilibrée |
| Q8_0 | ~13 Go | Lente | Quasi-originale | Tâches critiques en qualité |
| FP16 | ~24 Go | La plus lente | Originale | Uniquement si vous avez la VRAM |
| IQ4_XS | ~6 Go | La plus rapide | Acceptable | Budget VRAM serré |
Si vous exécutez en Q8 ou FP16 et vous demandez pourquoi c'est lent, passez à Q4_K_M. La différence de qualité est marginale pour la plupart des tâches, mais la différence de vitesse est spectaculaire. Notre guide GGUF contient des benchmarks détaillés pour chaque niveau de quantification.
Raison 3 : Longueur de contexte trop longue
Gemma 4 supporte jusqu'à 256K de contexte, mais un contexte plus long = une inférence plus lente. La relation n'est pas linéaire — ça empire à mesure que le contexte grandit :
| Longueur de contexte | Vitesse relative | Utilisation VRAM (12B Q4) |
|---|---|---|
| 2K | 1,0x (référence) | ~7 Go |
| 8K | ~0,9x | ~8 Go |
| 32K | ~0,7x | ~12 Go |
| 128K | ~0,4x | ~20 Go |
| 256K | ~0,25x | ~30 Go+ |
Solution : Définissez une longueur de contexte raisonnable pour votre tâche :
# Ollama : limiter le contexte
ollama run gemma4:12b --ctx-size 8192
# llama.cpp
./llama-server -m model.gguf -c 8192
# N'utilisez pas 256K sauf si vous en avez vraiment besoinRaison 4 : Gonflement du cache KV
Le cache KV (clé-valeur) stocke les informations d'attention et grandit avec la longueur de la conversation. Les longues conversations consomment de la VRAM et ralentissent les choses.
Solution : Relancez des conversations fraîches régulièrement, ou définissez une limite de cache :
# llama.cpp : limiter le cache KV
./llama-server -m model.gguf -c 8192 --cache-type-k q8_0 --cache-type-v q8_0
# Le cache KV quantifié utilise moins de VRAM avec une perte de qualité minimaleRaison 5 : Problèmes de taille de batch
Si vous servez plusieurs requêtes, des tailles de batch incorrectes nuisent au débit :
# vLLM : ajuster la taille de batch
python -m vllm.entrypoints.openai.api_server \
--model google/gemma-4-12b-it \
--max-num-batched-tokens 4096 \
--max-num-seqs 8Corrections spécifiques par plateforme
Mac (Apple Silicon)
La performance sur Mac dépend entièrement du bon fonctionnement de l'accélération Metal GPU :
# Vérifier le support Metal
system_profiler SPDisplaysDataType | grep Metal
# Ollama utilise Metal automatiquement sur Apple Silicon
# Si c'est toujours lent, vérifiez la pression mémoire unifiée :
memory_pressure
# Pour llama.cpp, s'assurer que Metal est activé
cmake -B build -DGGML_METAL=ON
cmake --build build
# Paramètres recommandés pour M1/M2/M3
./llama-server -m model.gguf -ngl 999 -c 8192| Modèle Mac | Mémoire unifiée | Vitesse 12B Q4 | Notes |
|---|---|---|---|
| M1 8 Go | 8 Go | ~12 tok/s | Utilisable mais serré |
| M1 Pro 16 Go | 16 Go | ~18 tok/s | Confortable |
| M2 Pro 16 Go | 16 Go | ~22 tok/s | Bon usage quotidien |
| M3 Pro 18 Go | 18 Go | ~25 tok/s | Point idéal |
| M3 Max 36 Go | 36 Go | ~30 tok/s | Peut exécuter le 27B Q4 |
| M4 Max 48 Go | 48 Go | ~35 tok/s | Fait tout tourner |
Astuce Mac : Fermez les applications gourmandes en mémoire (Chrome, Docker) avant d'exécuter de grands modèles. Apple Silicon partage la mémoire entre CPU et GPU, il n'y a donc pas de pool VRAM séparé.
Windows (NVIDIA CUDA)
# S'assurer que CUDA est réellement utilisé
# Dans Ollama, vérifier avec :
ollama ps
# Problème courant sur Windows : paramètres d'alimentation
# Passez en "Haute performance" dans les options d'alimentation de Windows
# Les GPU de portables brident agressivement en mode "Équilibré"
# Pour llama.cpp sur Windows :
cmake -B build -DGGML_CUDA=ON
cmake --build build --config ReleaseAstuce Windows : Désactivez l'analyse en temps réel de Windows Defender pour votre répertoire de modèles. Il scanne chaque lecture de fichier et peut ruiner les performances :
# PowerShell (admin)
Add-MpPreference -ExclusionPath "C:\Users\you\models"Linux (NVIDIA ou AMD)
# NVIDIA : S'assurer que le mode persistance est activé
sudo nvidia-smi -pm 1
# Passer le GPU en performance maximale
sudo nvidia-smi -ac 1215,1410 # Les valeurs varient selon le GPU
# AMD : Vérifier que ROCm est actif
rocm-smi
# Pour les deux : s'assurer de ne pas utiliser le compositeur Wayland
# X11 a moins de surcoût GPU pour les tâches de calculChecklist rapide de vitesse
Parcourez cette checklist pour maximiser la vitesse :
1. [ ] L'accélération GPU fonctionne (pas de fallback CPU)
2. [ ] Quantification Q4_K_M utilisée (sauf si la qualité est critique)
3. [ ] Longueur de contexte réglée sur ce dont vous avez besoin (pas 256K par défaut)
4. [ ] Cache KV quantifié (--cache-type-k q8_0)
5. [ ] Flash Attention activé (si disponible)
6. [ ] Pas d'applications gourmandes en arrière-plan
7. [ ] Paramètres d'alimentation en "Haute performance" (portables)
8. [ ] Derniers pilotes installésQuand la lenteur est normale
Parfois Gemma 4 est lent et c'est simplement comme ça :
- Latence du premier token : Le premier token prend toujours plus longtemps (traitement du prompt). C'est normal.
- Prompts très longs : Traiter une entrée de 100K tokens prend du temps quoi qu'il arrive.
- Modèle 27B sur 16 Go : Ça rentre, mais tout juste. Envisagez le 12B à la place.
- Inférence CPU uniquement : Sans GPU, attendez-vous à 1-5 tok/s. C'est la réalité de l'exécution de LLM sur CPU.
Si vous rencontrez des problèmes au-delà de la vitesse, comme des crashs ou des erreurs, consultez notre guide de dépannage pour des solutions aux erreurs OOM, problèmes de détection GPU, et plus.
Étapes suivantes
- Pas sûr que votre matériel suffise ? Consultez le guide de configuration matérielle pour les spécifications minimales et recommandées
- Hésitez sur la taille du modèle ? Lisez Quel modèle Gemma 4 choisir ? pour faire correspondre la taille du modèle à votre matériel
- Vous voulez mieux comprendre la quantification ? Consultez notre guide de quantification GGUF pour des comparaisons détaillées
L'optimisation de la vitesse consiste surtout à bien faire les bases. Corrigez le fallback CPU, choisissez la bonne quantification, et définissez une longueur de contexte raisonnable — ces trois changements à eux seuls résoudront 90 % des plaintes de performance.
