La plupart des équipes qui dimensionnent leur infrastructure GPU pour servir un LLM se concentrent sur la taille du modèle, et sous-estiment massivement la consommation du KV cache. Pourtant, sur un workload à long contexte et à batch élevé, le KV cache peut dépasser la taille du modèle lui-même en mémoire GPU. Résultat typique sans optimisation : un cluster surdimensionné, un throughput effondré, et une facture cloud qui explose. Les techniques de gestion fine du KV cache — PagedAttention, quantization, offloading, partage de préfixe — permettent de servir trois à cinq fois plus de requêtes concurrentes sur la même infrastructure. En 2026, les maîtriser est devenu une compétence incontournable pour toute équipe qui opère son propre serving LLM. Fine-tuning d'embeddings : adapter un modèle de retrieval à votre domaine métier
À retenir en 30 secondes : le KV cache stocke les représentations intermédiaires des tokens déjà traités pour éviter leur recalcul. Sa taille croît linéairement avec le nombre de tokens de contexte et avec le batch size. PagedAttention (vLLM) alloue la mémoire par blocs plutôt que contigue, divisant le gaspillage par 5. La quantization à 8 ou 4 bits divise la taille du cache par 2 ou 4. L’offloading CPU/NVMe permet de dépasser la mémoire GPU au prix d’une latence accrue. Ces techniques se combinent et doivent être calibrées sur chaque workload. LLMOps : guide complet pour déployer et opérer un LLM en production
Pourquoi le KV cache domine la consommation mémoire
Dans un transformer, l’attention à chaque couche nécessite les vecteurs de clés (K) et de valeurs (V) de tous les tokens précédents. Les recalculer à chaque nouveau token serait prohibitif ; on les met donc en cache. La taille de ce cache suit une formule simple : 2 (K et V) × nb_couches × nb_têtes × dim_tête × longueur_contexte × batch_size × précision_bytes. Pour un Llama-3-70B servant 20 requêtes concurrentes avec 8 000 tokens de contexte en bf16, le KV cache dépasse 40 Go. À côté, les poids du modèle (140 Go en bf16) semblent presque abordables au regard d’un cluster multi-GPU. La leçon : négliger le dimensionnement du KV cache, c’est se tromper d’un facteur deux sur ses besoins d’infrastructure.
PagedAttention : la révolution de l’allocation mémoire
Jusqu’à l’introduction de PagedAttention par vLLM en 2023, le KV cache était alloué de manière contigue : un buffer de taille max_seq_length × batch_size était réservé par requête, même pour des contextes bien plus courts. Résultat : 60 à 80 % de la mémoire allouée restait vide. PagedAttention s’inspire directement du mécanisme de mémoire virtuelle paginée des systèmes d’exploitation : la mémoire est allouée par blocs de 16 ou 32 tokens, et une table de mapping associe chaque séquence logique à ses blocs physiques. Résultat : le gaspillage mémoire tombe à 4 %, et le batch size efficace est multiplié par 3 à 5. C’est aujourd’hui le standard de facto dans vLLM, TGI, TensorRT-LLM et SGLang.
Un bénéfice secondaire majeur de la pagination est le partage de blocs entre séquences qui partagent un préfixe commun — c’est le mécanisme sous-jacent au prompt caching qui réduit les coûts d’inférence LLM. Deux requêtes qui partagent 2 000 tokens de prompt système ne stockent ces 2 000 tokens qu’une seule fois dans le KV cache.
Quantization du KV cache : diviser la taille sans sacrifier la qualité
Le KV cache est stocké par défaut en même précision que le modèle (bf16 ou fp16, soit 2 octets par valeur). Les techniques de quantization du KV cache à int8 ou int4 divisent cette consommation par 2 ou 4, avec un impact qualitatif très faible dans la plupart des cas. Les deux approches dominantes sont la quantization statique (facteur d’échelle fixe par couche) et la quantization dynamique (facteur recalculé à chaque token, plus coûteux mais plus précis). vLLM supporte nativement la quantization fp8 du KV cache sur GPU H100 et plus récents, qui offre le meilleur compromis actuel. Les équipes qui déploient Llama ou Qwen à grande échelle gagnent typiquement 40 à 60 % de capacité en activant simplement cette option.
Offloading et stratégies hybrides CPU/GPU
Quand la mémoire GPU reste insuffisante malgré PagedAttention et la quantization, l’offloading d’une partie du KV cache en RAM CPU ou sur NVMe devient une option. Le pattern typique : garder en GPU la portion « chaude » (tokens récents, nécessaires pour la génération en cours), transférer en CPU la portion « froide » (tokens anciens, consultés moins souvent). Cette stratégie permet de servir des contextes bien plus longs que ce que la mémoire GPU seule autoriserait, au prix d’une latence inter-tokens accrue. Elle devient particulièrement pertinente pour les cas d’usage de type long-context LLM dépassant 1 million de tokens en production.
Dimensionner et piloter en production
Trois métriques pilotent la santé du KV cache en production. Le cache hit rate sur les préfixes partagés (idéal : plus de 60 % sur les workloads conversationnels). Le GPU memory utilization rate moyen (viser 80 à 90 % — en dessous, mémoire gaspillée ; au-dessus, risque d’OOM sur pics). Le preemption rate (fréquence à laquelle le serveur suspend ou tronque des séquences pour libérer de la mémoire — doit rester proche de zéro en régime normal). Ces métriques sont exposées par vLLM via Prometheus et doivent être intégrées à votre stack d’observabilité, dans l’esprit de ce que nous décrivons dans notre guide sur l’observabilité des systèmes LLM avec OpenTelemetry.
Pour approfondir côté recherche, l’article fondateur de Kwon et al. sur PagedAttention et vLLM reste la référence incontournable pour comprendre les mécaniques internes.
Mon point de vue d’expert
Je rencontre régulièrement des équipes françaises qui ont surdimensionné leur cluster GPU parce qu’elles ont été incapables de prédire la consommation du KV cache, ou qui tournent avec un throughput artificiellement bas pour éviter les OOM. Mon conseil pour les équipes qui opèrent leur propre serving : passez à vLLM 0.6 ou supérieur si ce n’est déjà fait, activez le PagedAttention (actif par défaut) et la quantization fp8 du KV cache sur GPU récents, instrumentez les trois métriques clés, et calibrez la taille du block et la longueur max de séquence sur votre workload réel. Vous gagnerez souvent 2 à 3 fois en capacité sans toucher un GPU supplémentaire. C’est l’optimisation d’infrastructure la plus rentable que je connaisse sur un serving LLM aujourd’hui, et pourtant encore trop souvent ignorée.
FAQ : KV cache management
- La quantization du KV cache dégrade-t-elle la qualité des réponses ?
- En fp8 sur GPU récents, la dégradation est généralement imperceptible (moins de 0.5 point sur les benchmarks standards). En int4, elle devient mesurable sur certaines tâches de raisonnement complexe. Une évaluation sur votre workload réel reste nécessaire avant généralisation en production.
- Comment estimer la mémoire KV cache nécessaire ex ante ?
- Formule : 2 × nb_couches × nb_têtes × dim_tête × max_tokens × batch_size × bytes_par_valeur. Pour Llama-3-70B avec 8K tokens et batch 32 en bf16 : environ 65 Go. Prévoir une marge de 20 % pour les métadonnées et la fragmentation résiduelle. vLLM expose un script d’estimation automatique via
vllm serve --help. - Quand préférer le batch size plus faible plutôt que la quantization ?
- Si vos SLA de latence sont serrés et que votre workload n’est pas saturé, baisser le batch pour garder la précision maximale est préférable. Si votre contrainte est le throughput global ou le coût par million de requêtes, la quantization du KV cache est systématiquement gagnante.
- PagedAttention fonctionne-t-il avec tous les modèles ?
- Oui, PagedAttention est agnostique à l’architecture : il opère au niveau de l’allocation mémoire, pas au niveau du modèle lui-même. Il fonctionne avec les familles Llama, Mistral, Qwen, GPT-NeoX, Falcon, DeepSeek et toutes les architectures transformer standard supportées par vLLM.