Optimiser la latence d'un LLM auto-hébergé repose sur trois leviers combinables : bien choisir son serveur d'inférence (vLLM en tête), activer le speculative decoding pour le décodage token par token, et quantifier le modèle pour réduire la pression mémoire. Avec ces techniques, on passe de 20-30 tokens/s sur un serveur naïf à 80-150 tokens/s sur le même GPU - sans changer de modèle, sans sacrifier la qualité des réponses.
Ce guide couvre l'essentiel de l'optimisation d'inférence : la distinction latence vs débit (TTFT, inter-token latency), le continuous batching et PagedAttention de vLLM, le speculative decoding avec modele draft, la quantization, la distillation et les SLM comme levier alternatif, le choix du GPU, et comment mesurer proprement vos performances avant et après optimisation.
Latence vs débit : deux métriques qui s'opposent
Avant d'optimiser quoi que ce soit, il faut savoir ce qu'on mesure. La confusion entre latence et débit est la source de beaucoup de mauvais arbitrages.
Les métriques de latence (expérience utilisateur)
Le TTFT (Time to First Token) est le temps qui s'écoule entre l'envoi de la requête et l'apparition du premier token dans la réponse. C'est la métrique la plus critique pour les applications interactives : un TTFT supérieur à 1-2 secondes brise le sentiment de fluidité. Il dépend principalement du temps de traitement du prompt (prefill) et de la taille du contexte en entrée.
Le TBT / ITL (Time Between Tokens / Inter-Token Latency) mesure l'intervalle entre deux tokens consécutifs en sortie. Pour une perception fluide, la barre psychologique est autour de 50ms (soit 20 tokens/s). En dessous, la génération est perçue comme instantanée. Au-dessus de 100ms, l'utilisateur "voit" le modèle réfléchir token par token.
Les métriques de débit (performance système)
Le débit agrégé (tokens/s total, toutes requêtes confondues) et les requêtes/s mesurent la capacité du système à traiter du volume. Ils sont pertinents pour des pipelines batch ou des APIs à fort trafic, pas pour des chatbots internes mono-utilisateur.
La tension fondamentale : augmenter le batch size (plus de requêtes en parallèle) améliore le débit mais dégrade la latence individuelle. L'optimum dépend de votre cas d'usage.
| Metrique | Ce qu'elle mesure | Cible typique (usage interactif) | Levier principal |
|---|---|---|---|
| TTFT P50 | Temps avant premier token (médiane) | < 500ms | GPU puissant, chunked prefill |
| TTFT P95 | Temps avant premier token (95e percentile) | < 1s | Continuous batching, chunked prefill |
| ITL P50 | Temps entre deux tokens | < 50ms (20+ tok/s) | Speculative decoding, quantization |
| Tokens/s total | Debit agregé toutes requêtes | Maximiser | Batch size, continuous batching |
| VRAM utilisée | Memoire GPU consommee | < 90% de la VRAM dispo | Quantization, PagedAttention |
Continuous batching et PagedAttention : les fondations de vLLM
vLLM est aujourd'hui le serveur d'inférence de référence pour les LLM open-weight. Ses deux innovations de base - le continuous batching et PagedAttention - sont indépendantes du speculative decoding, et leur impact est déjà substantiel.
Continuous batching : garder le GPU occupé en permanence
Un serveur naïf fonctionne en batches statiques : il attend que toutes les requêtes du batch soient terminées avant d'en accepter de nouvelles. Problème : les requêtes ont des longueurs très variables. Quand les requêtes courtes finissent, le GPU attend les longues - GPU idle = argent gaspillé.
Le continuous batching (ou iteration-level batching) fonctionne au niveau de chaque pas de génération : dès qu'une requête se termine, une nouvelle entre dans le batch au cycle suivant. Le GPU reste saturé en permanence. Résultat mesuré : 2 à 4x de débit en plus par rapport à un serveur PyTorch classique sur le même matériel, selon les benchmarks Spheron 2026 sur H100.
PagedAttention : gérer le KV cache comme un OS
Le KV cache (Key-Value cache) stocke les produits d'attention calculés pour chaque token du contexte, évitant de les recalculer à chaque nouveau token généré. Il grossit linéairement avec la longueur du contexte et peut occuper plusieurs gigaoctets de VRAM pour de longs contextes.
Avec les systèmes classiques, ce cache est alloué de façon contigue en mémoire GPU. Le problème : on ne connait pas la longueur finale de la réponse à l'avance, donc on sur-alloue - ce qui fragmente la mémoire et réduit le nombre de requêtes servables simultanément.
PagedAttention, le coeur de vLLM (arXiv 2309.06180), gère ce cache comme un OS gère la RAM : en blocs paginés non-contigus. Les blocs sont alloués à la demande, libérés dès que la requête se termine. Le gaspillage mémoire tombe de 60-80% (cas naive) à moins de 4%. En pratique, on peut servir 2 à 3 fois plus de requêtes simultanées sur le même GPU.
Config minimale recommandée
Pour déployer vLLM avec un modèle 7-8B en production : un GPU avec 24 Go de VRAM (RTX 4090 ou A10G). Passez --max-model-len à la longueur de contexte réelle dont vous avez besoin (pas la longueur maximale du modèle) : chaque token de contexte consomme de la VRAM pour le KV cache, et la réduire libère de la place pour plus de requêtes en parallèle.
Speculative decoding : proposer plusieurs tokens d'un coup
Le speculative decoding est l'optimisation qui cible directement l'inter-token latency. L'idée : le goulot d'etranglement du décodage autorégressif est que le grand modèle génère un seul token à la fois, et que chaque token nécessite un passage complet dans toutes ses couches. Le GPU est sous-utilisé.
Comment ça marche : draft + verify
Le principe repose sur deux modèles :
- Le modèle draft (petit, rapide) propose N tokens en séquence. Un Phi-4-mini ou un Llama 3.2 3B peut proposer 5 à 8 tokens en quelques millisecondes.
- Le modèle verifier (le grand LLM cible) valide ces propositions en un seul passage parallèle. Il accepte ou rejette chaque token en comparant les distributions de probabilité draft vs verifier.
Si le taux d'acceptation est de 80%, on obtient en moyenne 4 tokens validés pour le coût d'un seul passage dans le grand modèle. La qualité est identique : les tokens rejetés sont remplacés par un échantillon direct du verifier, sans dégradation de la distribution de sortie.
Gains mesurés en 2025-2026
Selon le billet officiel de vLLM (octobre 2024), le speculative decoding apporte :
- Jusqu'à 2,8x de speedup sur les tâches de résumé (dataset CNN/DailyMail, forte répétitivité = fort taux d'acceptation du draft)
- 1,5x de speedup sur des conversations générales (dataset ShareGPT, plus varié)
- Environ 20% de réduction de la latence P95 en conditions de production (2026)
Les gains varient fortement selon le domaine : plus le texte généré est prévisible (reformulations, résumés dans un format fixe, génération de code boilerplate), plus le draft anticipe bien et plus le taux d'acceptation est élevé. Sur des tâches créatives très ouvertes, le gain est plus faible.
Speculative decoding dans vLLM : activation
Dans vLLM, le speculative decoding s'active avec --speculative-model (nom du modèle draft) et --num-speculative-tokens (nombre de tokens proposés par le draft, typiquement 5). Une alternative sans modèle draft : le prompt lookup decoding, qui copie des n-grammes depuis le prompt comme tokens candidats - utile pour les tâches de résumé ou de complétion de documents.
Choisir le bon modèle draft
La règle de base : le draft doit être de la même famille que le verifier (pré-entraînement similaire) pour que ses propositions soient pertinentes. Les couples courants :
- Llama 3.1 70B verifier + Llama 3.2 3B draft
- Mistral Large verifier + Ministral 3B draft
- Qwen2.5 72B verifier + Qwen2.5 3B draft
La taille idéale du draft est 10 à 20 fois plus petite que le verifier. En dessous, les propositions sont trop mauvaises. Au-dessus, le draft est trop lent pour apporter un gain net.
Quantization : moins de VRAM, plus de vitesse
La quantization réduit la précision des poids du modèle (de float16 à INT8, INT4 ou FP8), ce qui réduit la VRAM nécessaire et accélère les calculs matriciels. C'est un levier orthogonal au speculative decoding : les deux se combinent.
Pour les détails techniques sur les formats de quantization (GGUF, GPTQ, AWQ, FP8) et leur impact sur la qualité des réponses, notre guide quantization LLM : GGUF, INT4 et INT8 expliqués couvre chaque format avec des benchmarks de perte de qualité. En résumé :
- FP8 : perte de qualité quasi nulle, supporté nativement par vLLM sur H100/A100. Premier choix pour la production.
- INT4 (GGUF/AWQ/GPTQ) : perte de qualité légère (1-3 points sur les benchmarks standards), divise la VRAM par 4 par rapport au float16. Indispensable pour faire tourner un 70B sur deux A100 au lieu de quatre.
Ordre d'optimisation recommandé
1. Déployer vLLM avec les paramètres de base (continuous batching + PagedAttention actifs par défaut). 2. Quantifier en FP8 si le GPU le supporte, sinon INT4. 3. Activer le speculative decoding si la tâche est répétitive ou structurée. 4. Mesurer avant et après chaque étape - ne pas combiner toutes les optimisations sans mesure intermédiaire.
Distillation et SLM : changer de modèle plutôt qu'optimiser
Parfois, la meilleure optimisation de latence n'est pas technique : c'est de se demander si vous avez vraiment besoin d'un modèle 70B pour votre tâche.
La distillation pour créer un modèle ciblé
La distillation transfert les connaissances d'un grand modèle vers un petit. Le "student" est entraîné à imiter les sorties du "teacher" sur votre corpus métier spécifique. Résultat : un modèle compact qui performe au niveau du grand modèle sur votre tâche précise, avec une latence 5 à 10x inférieure. Notre article distillation de modèles LLM en entreprise détaille le processus et les conditions de réussite.
SLM directement : la voie la plus simple
Pour les tâches bien délimitées (classification, extraction structurée, résumé dans un format fixe), un SLM de 3 à 8 milliards de paramètres fine-tuné sur vos données peut atteindre 90 à 95% des performances d'un LLM 70B sur cette tâche spécifique - avec une latence 10 à 30x inférieure et sans speculative decoding ni quantization complexe.
Notre guide benchmark SLM vs LLM sur tâche métier donne une méthode pour mesurer ce gap sur votre propre cas d'usage avant de choisir. Et notre article structured output JSON et constrained decoding montre comment forcer un SLM à produire du JSON valide à chaque appel, sans post-traitement.
Choix du GPU et mesure des performances
Quel GPU pour l'inférence LLM ?
Le facteur le plus important n'est pas la puissance de calcul brute (FLOPS) mais la bande passante mémoire. Le décodage autorégressif est une opération memory-bound : à chaque token généré, le modèle relit tous ses poids depuis la VRAM. Un GPU avec 80 Go de VRAM mais une faible bande passante sera moins rapide qu'un GPU avec 40 Go et une bande passante élevée.
| GPU | VRAM | Bande passante mem. | Cas d'usage typique | Prix indicatif (cloud/h) |
|---|---|---|---|---|
| RTX 4090 | 24 Go GDDR6X | 1 008 Go/s | Dev, SLM 7-14B en prod legere | ~0,50 EUR/h |
| A10G | 24 Go GDDR6 | 600 Go/s | Production SLM 7-14B | ~1,20 EUR/h |
| A100 SXM4 40 Go | 40 Go HBM2 | 1 555 Go/s | LLM 30-34B en INT4 | ~2,50 EUR/h |
| A100 SXM4 80 Go | 80 Go HBM2 | 2 000 Go/s | LLM 70B en INT4 | ~3,50 EUR/h |
| H100 SXM5 80 Go | 80 Go HBM3 | 3 350 Go/s | LLM 70B+ en FP8, fort debit | ~4,50 EUR/h |
Pour un premier déploiement en production, un A10G ou deux RTX 4090 en NVLink sont souvent le meilleur rapport performance/coût pour des modèles 7 à 14B. Les H100 ne s'amortissent qu'à partir de modèles 70B ou de très forts volumes de trafic.
Comment mesurer avant et après optimisation
vLLM fournit deux scripts de benchmark en ligne de commande :
- benchmark_throughput.py : mesure le débit en tokens/s pour un dataset donné en mode offline (toutes les requêtes envoyées d'un coup)
- benchmark_serving.py : simule un trafic réaliste avec arrivée progressive des requêtes et mesure le TTFT P50/P95 et l'ITL P50/P95 en conditions de charge
Pour comparer des serveurs d'inférence entre eux (vLLM vs SGLang vs TensorRT-LLM), notre guide top serveurs d'inférence LLM open source présente les benchmarks comparatifs sur H100 avec des configurations reproductibles. Les outils d'observabilité (traces OpenTelemetry, dashboards Prometheus) sont couverts dans notre article top outils d'évaluation et observabilité LLM.
Besoin d'un avis technique ?
Latence trop élevée, GPU sous-utilisé, architecture d'inférence à choisir : 30 minutes pour diagnostiquer votre configuration et identifier le bon levier.
Pour aller plus loin
- Top serveurs d'inférence LLM open source - comparatif vLLM, SGLang, TensorRT-LLM sur benchmarks H100 2026.
- Quantization LLM : GGUF, INT4 et INT8 expliques - impact sur la VRAM, la vitesse et la qualite des reponses.
- Benchmark SLM vs LLM sur tache metier - methode pour mesurer le gap de qualite sur votre propre cas d'usage.
- Structured output JSON et constrained decoding - forcer un SLM a produire du JSON valide sans post-traitement.
- Distillation de modeles LLM en entreprise - creer un modele compact qui performe comme un grand sur votre tache.
- Small Language Models en entreprise : le guide complet - panorama SLM, comparatif VRAM/cout, quand un SLM suffit.
- Top outils d'evaluation et observabilite LLM - traces, dashboards et metriques pour monitorer un LLM en production.
- Router hybride SLM/LLM : architecture et couts - envoyer les requetes simples vers un SLM, les complexes vers un LLM.
- PagedAttention : Efficient Memory Management for LLM Serving (arXiv 2309.06180) - l'article de recherche original de vLLM.
- Expert IA generative LLM/NLP sur mesure - accompagnement Tensoria pour l'architecture et le deploiement LLM.
