Points clés
- Désactiver la journalisation/débogage (facile) : ~10% de gain de vitesse.
- Utiliser la quantification Q4 (facile) : même vitesse, moins de VRAM.
- Optimiser la taille de lot (moyen) : 2–3× la vitesse pour le traitement par lot.
- Utiliser vLLM plutôt qu'Ollama (avancé) : 2–5× la vitesse pour les requêtes concurrentes.
- Utilisation mémoire GPU 90%+ (moyen) : gain de 15–20%.
- Combinaison de toutes les techniques : ~2–3× d'accélération totale.
Comment l'utilisation de la mémoire GPU affecte-t-elle la vitesse ?
Par défaut, la plupart des outils utilisent 70–80% du VRAM GPU — laissant la mémoire libre inutilisée. Augmenter à 90–95% améliore la vitesse de 15–20% en permettant au moteur de pré-allouer davantage de cache KV :
# vLLM: increase GPU memory utilization
vllm serve meta-llama/Llama-2-7b-hf \
--gpu-memory-utilization 0.95
# Ollama: environment variable
export OLLAMA_GPU_THRESHOLD=0.95 # Use 95% of GPU
ollama run llama3.2:3b
# LM Studio: Settings → GPU acceleration slider (move to 100%)Quelle taille de lot maximise le débit ?
Pour le traitement par lot (plusieurs prompts), augmenter la taille de lot de 1 à 32 donne 2–4× d'amélioration du débit.
Requête unique = utilisation pipeline limitée. Lot de 32 requêtes = 2–4× de débit.
Compromis : latence plus élevée par requête individuelle (elles attendent la complétion du lot).
| Taille de lot | Débit | Latence/Requête | Cas d'usage |
|---|---|---|---|
| 1 (unique) | 50 tokens/sec | Minimale | Chat temps réel |
| 8 | 120 tokens/sec | Acceptable | Légère concurrence |
| 32 | 200 tokens/sec | Élevée | API par lot |
| 64+ | 250+ tokens/sec | Très élevée | Traitement hors ligne |
Quel moteur d'inférence est le plus rapide : vLLM vs Ollama vs llama.cpp ?
vLLM : 5–10× plus rapide qu'Ollama pour les requêtes concurrentes — pour les API de production avec plusieurs utilisateurs.
llama.cpp : Le plus rapide pour les requêtes uniques sur matériel grand public — pour les configurations locales mono-utilisateur.
Ollama : Meilleure expérience développeur pour usage mono-utilisateur ; comparable à llama.cpp pour les requêtes uniques.
Text-Generation-WebUI : Le plus lent, mais le plus de fonctionnalités — pour l'expérimentation uniquement, pas la production.
La quantification accélère-t-elle vraiment l'inférence ?
Sur les GPU modernes (RTX 40-series), Q4 et Q5 fonctionnent à la même vitesse que FP16 — quantifiez pour réduire le VRAM, pas pour la vitesse.
Avantages de vitesse indirects de la quantification :
- Fichier modèle plus petit = chargement à froid plus rapide depuis le disque
- Bande passante mémoire réduite = légèrement plus rapide (10–15%) sur matériel plus ancien ou limité en mémoire
La quantification est principalement pour la réduction de VRAM, pas le débit de tokens brut.
Quel gain de vitesse est réaliste ?
Exemple : Optimisation d'un modèle 7B sur RTX 4090 — étape par étape :
| Modification | Vitesse | Gain cumulatif |
|---|---|---|
| Ollama par défaut (référence) | 120 tok/sec | — |
| Désactiver journalisation debug | 132 tok/sec | +10% |
| Mémoire GPU → 95% | 150 tok/sec | +25% total |
| Passage à vLLM (lot) | 300 tok/sec (lot) | +2.5× (lot) |
| Toutes optimisations combinées | 300 tok/sec | +2.5× débit |
Erreurs fréquentes d'optimisation de vitesse
- Pousser la mémoire GPU à 100%. Risque de plantages mémoire insuffisante. Maximum sûr : 90–95%.
- Réduire la taille de lot pour la vitesse. La taille de lot n'affecte pas la latence des requêtes uniques. Aide uniquement le débit.
- Sur-quantifier pour la vitesse. Q4 est approximativement à la même vitesse que FP16. Quantifier pour le VRAM, pas la vitesse.
- Changer de moteur d'inférence en cours de déploiement. Passer d'Ollama à vLLM à llama.cpp introduit des bugs. Choisir un moteur et l'optimiser.
Questions fréquemment posées
Quelle est la méthode la plus efficace pour accélérer l'inférence LLM locale ?
Passer d'Ollama à vLLM pour les requêtes concurrentes offre la plus grande accélération — 5–10× d'amélioration du débit pour le traitement par lot. Pour les requêtes uniques, augmenter l'utilisation mémoire GPU de 70% à 90–95% donne 15–20% de gain. Désactiver la journalisation debug apporte 10% supplémentaires.
Le traitement par lot améliore-t-il la latence des requêtes uniques ?
Non — la taille de lot affecte le débit (tokens par seconde sur toutes les requêtes), pas la latence des requêtes uniques. Pour réduire la latence d'une requête, optimisez l'utilisation mémoire GPU et utilisez un moteur plus rapide (vLLM ou llama.cpp).
Combien vLLM est-il plus rapide qu'Ollama ?
Pour les requêtes uniques, vLLM et Ollama ont des performances similaires (tous deux ~120–150 tok/sec sur RTX 4090 avec modèle 7B). Pour les requêtes concurrentes, vLLM est 5–10× plus rapide grâce au batching continu et PagedAttention.
La quantification accélère-t-elle l'inférence ?
L'avantage principal de la quantification est la réduction du VRAM, pas la vitesse. Sur les GPU NVIDIA modernes (RTX 40-series), Q4 et Q5 fonctionnent à la même vitesse que FP16. L'avantage de vitesse indirect : un modèle Q4 plus petit se charge plus vite depuis le disque.
Quelle utilisation mémoire GPU définir pour une vitesse maximale ?
Régler l'utilisation mémoire GPU à 90–95% dans vLLM (--gpu-memory-utilization 0.92). Éviter 100% — cela provoque des plantages OOM. La marge de sécurité de 5–10% est non négociable.
Pourquoi mon LLM local est-il plus lent après le premier prompt ?
Le premier prompt charge le modèle en VRAM (démarrage à froid), ce qui peut prendre 10–30 secondes. Garder le serveur actif entre les sessions. Avec Ollama, définir OLLAMA_KEEP_ALIVE=24h pour éviter le déchargement du modèle.
L'inférence CPU seul peut-elle être accélérée de façon significative ?
Des gains limités sont possibles : utiliser llama.cpp avec -t pour le nombre de threads égal aux cœurs physiques, activer AVX2/AVX-512, utiliser la quantification Q4_K_M. Plafond réaliste : 8–12 tok/sec sur un i9 moderne. Pour le chat interactif, le GPU est la seule voie vers une latence acceptable.
Comment la longueur du contexte affecte-t-elle la vitesse d'inférence ?
Des fenêtres de contexte plus longues ralentissent l'inférence car le mécanisme d'attention évolue quadratiquement avec la longueur du contexte. Un prompt de 4K de contexte est ~4× plus lent à traiter qu'un prompt de 1K. Garder les prompts système sous 500 tokens.
Qu'est-ce que PagedAttention et pourquoi accélère-t-il vLLM ?
PagedAttention est le système de gestion du cache KV de vLLM. Au lieu de pré-allouer un bloc mémoire fixe par requête, il pagine la mémoire dynamiquement — comme la mémoire virtuelle dans un OS. Cela élimine la fragmentation VRAM et améliore l'utilisation GPU de ~55% à 90%+.
Y a-t-il une différence de vitesse entre les formats GGUF et safetensors ?
Oui. GGUF (utilisé par llama.cpp et Ollama) est optimisé pour l'inférence CPU/GPU grand public avec quantification intégrée. Safetensors (utilisé par vLLM et HuggingFace) est plus rapide pour l'inférence GPU en pleine précision. Pour les RTX 40-series avec FP16, safetensors + vLLM surpasse typiquement GGUF + Ollama de 10–20%.
Sources
- Guide d'optimisation vLLM -- docs.vllm.ai/en/dev_guide/performance_tuning.html
- Conseils de performance Ollama -- github.com/ollama/ollama/blob/main/docs/troubleshooting.md