Accueil › Glossaire › KV Cache Optimization

KV Cache Optimization

L’optimisation du KV-cache (Key-Value cache) regroupe les techniques qui réduisent la consommation mémoire GPU du cache d’attention des LLM pendant l’inférence, permettant de traiter des contextes plus longs, des batchs plus grands, et un throughput plus élevé sur le même matériel.

Le KV-cache : pourquoi il existe et pourquoi il pose problème

Un transformer génère du texte token par token. Pour chaque nouveau token, le mécanisme d’auto-attention a besoin de « regarder » tous les tokens précédents. Sans cache, le modèle devrait recalculer les vecteurs Key et Value de tous les tokens précédents à chaque étape de génération. Pour une séquence de 10 000 tokens, cela signifierait recalculer 10 000 × 10 000 paires d’attention, une complexité quadratique O(n²) qui rendrait l’inférence impraticablement lente.

Le KV-cache élimine ce recalcul. À chaque étape de génération, les vecteurs K et V du nouveau token sont calculés et ajoutés au cache. Les K et V des tokens précédents sont simplement lus depuis le cache. Le modèle ne calcule l’attention que entre le nouveau token et les K/V cachés, ce qui ramène la complexité à O(n) par token généré.

Le problème : la mémoire. Le KV-cache grossit linéairement avec la longueur du contexte et le nombre de couches du modèle. La formule de taille :

Taille KV-cache = 2 × nb_couches × nb_têtes × dim_tête × nb_tokens × octets_par_valeur

# Exemple : Llama 3 70B, contexte 8K tokens, FP16
# 2 × 80 couches × 8 têtes GQA × 128 dim × 8192 tokens × 2 octets
# ≈ 20 Go par requête

# Pour un batch de 32 requêtes simultanées :
# 32 × 20 Go = 640 Go de KV-cache

Pour un modèle de 70B paramètres avec un contexte de 8K tokens, le KV-cache consomme environ 20 Go par requête. Avec un batch de 32, c’est 640 Go, soit plus que la VRAM de la plupart des configurations GPU. Le KV-cache dépasse souvent la taille des poids du modèle eux-mêmes en consommation mémoire. C’est le goulot d’étranglement principal de l’inférence LLM à grande échelle.

PagedAttention : la révolution vLLM

PagedAttention, introduit par vLLM en 2023, est l’optimisation la plus impactante de l’histoire de l’inférence LLM. Le principe est directement inspiré de la gestion de la mémoire virtuelle dans les systèmes d’exploitation.

Le problème de la fragmentation

Sans PagedAttention, chaque requête reçoit un bloc contigu de mémoire GPU pour son KV-cache, dimensionné pour la longueur maximale possible de la séquence. Si le contexte maximum est 8K tokens mais que la requête n’en utilise que 2K, 75 % de la mémoire allouée est gaspillée. De plus, les séquences de longueurs variables créent de la fragmentation : des « trous » de mémoire inutilisable entre les blocs alloués. En production, 60 à 80 % de la mémoire KV-cache est gaspillée par la fragmentation et la sur-allocation.

La solution : pagination

PagedAttention découpe le KV-cache en blocs de taille fixe (« pages »), exactement comme la mémoire virtuelle d’un OS. Les séquences voient une mémoire logique continue, mais les blocs physiques peuvent être non contigus et alloués dynamiquement. Quand une séquence a besoin de plus de mémoire, de nouvelles pages sont allouées à la demande. Quand une séquence se termine, ses pages sont libérées et réutilisables immédiatement.

Résultat : le gaspillage mémoire passe de ~70 % à moins de 4 %. Le throughput augmente de 2 à 4× sur le même matériel, car plus de requêtes peuvent être traitées simultanément avec la mémoire libérée.

# vLLM avec PagedAttention (activé par défaut)
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=4,          # 4 GPU en parallèle
    gpu_memory_utilization=0.90,     # Utiliser 90 % de la VRAM
    max_model_len=32768,             # Contexte max
    enable_prefix_caching=True,      # Activer le prefix caching
)

# PagedAttention gère automatiquement l'allocation/libération des pages

Partage de préfixes

PagedAttention permet aussi le partage de pages entre requêtes qui ont un préfixe commun. Si 100 requêtes partagent le même system prompt de 2 000 tokens, les pages correspondant à ce préfixe sont stockées une seule fois et référencées par les 100 requêtes. C’est l’implémentation technique du prefix caching côté serveur d’inférence.

Quantification du KV-cache

Réduire la précision numérique des vecteurs K et V dans le cache réduit directement sa taille en mémoire. C’est complémentaire à PagedAttention : PagedAttention élimine le gaspillage, la quantification réduit la taille utile.

NVIDIA a introduit NVFP4 sur l’architecture Blackwell, un format 4 bits spécifique qui utilise des facteurs d’échelle FP8 par bloc pour une meilleure précision que le MXFP4. Les benchmarks montrent moins de 1 % de perte de qualité sur LiveCodeBench, MMLU-PRO, et Ruler 64K (contexte long), tout en doublant la capacité de contexte disponible.

La quantification du KV-cache se distingue de la quantification des poids du modèle. Quantifier les poids (AWQ, GPTQ, bitsandbytes NF4) réduit la taille du modèle en mémoire, libérant indirectement de l’espace pour le KV-cache. Quantifier le KV-cache directement réduit la taille du cache lui-même. Les deux techniques se cumulent.

Stratégies d’éviction du KV-cache

Quand la mémoire GPU est pleine, le système doit décider quels éléments du KV-cache supprimer pour faire place aux nouveaux. C’est le problème de l’éviction du cache. Les politiques classiques (LRU, LFU) ne sont pas optimales pour les LLM car les patterns d’attention sont spécifiques.

H2O (Heavy-Hitter Oracle). Modélise l’éviction comme un problème d’optimisation sous-modulaire. Les tokens qui reçoivent le plus d’attention (« heavy hitters ») sont conservés, les tokens peu regardés sont évincés. Gains de throughput > 40 % sur les modèles Llama.

SnapKV. Identifie les tokens les plus importants en analysant les patterns d’attention des couches profondes, puis compresse le KV-cache en ne gardant que ces tokens clés. Particulièrement efficace pour les longs contextes où la majorité des tokens sont peu pertinents pour la requête courante.

Streaming LLM. Pour la génération de longueur théoriquement infinie, maintient uniquement les premiers tokens (les « attention sinks », typiquement les 4-8 premiers tokens qui reçoivent une attention disproportionnée) et les tokens récents dans une fenêtre glissante. Le contexte intermédiaire est supprimé. La mémoire reste fixe quelle que soit la longueur de la génération, mais la qualité se dégrade pour les tâches nécessitant des dépendances à longue portée.

PagedEviction. Algorithme d’éviction par blocs conçu spécifiquement pour PagedAttention. Au lieu d’évincer token par token, il identifie et supprime des blocs entiers de pages à faible importance, sans modifier les kernels CUDA.

Éviction guidée par l’entropie. Alloue le budget de cache de manière non uniforme entre les couches. Les couches dont l’attention est « diffuse » (entropie élevée) reçoivent plus de cache. Les couches dont l’attention est concentrée sur quelques tokens reçoivent moins de cache, car la perte d’information est moindre.

Offloading : GPU → CPU → SSD

Quand la VRAM GPU ne suffit pas, le KV-cache peut être déchargé vers des niveaux de mémoire moins coûteux mais plus lents :

LMCache est l’outil de référence pour l’offloading de KV-cache. Il s’intègre avec vLLM et permet de stocker le KV-cache dans un système multi-niveaux (GPU → CPU → disque). Les benchmarks montrent des réductions de latence (TTFT) de 3 à 10× pour les workloads à long contexte, en évitant le recalcul du prefill quand le cache peut être récupéré depuis le CPU ou le disque.

Le pattern typique : les requêtes actives ont leur KV-cache en VRAM GPU. Quand une session est inactive (l’utilisateur ne parle plus), le cache est déplacé vers la RAM CPU. Si l’utilisateur revient, le cache est rechargé en GPU (10-50 ms de latence) au lieu de recalculer tout le prefill (plusieurs secondes). Pour les sessions très longues ou les archives, le cache peut descendre jusqu’au SSD.

Optimisations au niveau du modèle

Certaines optimisations sont intégrées dans l’architecture du modèle et réduisent structurellement la taille du KV-cache.

GQA (Grouped-Query Attention). Au lieu d’avoir un jeu de K/V par tête d’attention (Multi-Head Attention classique), GQA partage les K/V entre plusieurs têtes. Llama 3 utilise GQA avec 8 groupes KV pour 64 têtes d’attention, réduisant le KV-cache de 8× par rapport au MHA. C’est l’optimisation architecturale la plus impactante et elle est adoptée par quasiment tous les modèles modernes.

MQA (Multi-Query Attention). Cas extrême de GQA : un seul jeu de K/V partagé entre toutes les têtes. Réduction maximale du KV-cache mais perte de qualité potentielle. Utilisé par certains modèles de code (StarCoder).

MLA (Multi-Head Latent Attention). Technique utilisée par DeepSeek-V3 qui compresse les K/V dans un espace latent de dimension réduite avant de les stocker. Le KV-cache est significativement plus petit, et les K/V complets sont reconstruits à la volée lors de l’attention. Cela a contribué à l’efficacité remarquable de DeepSeek sur les longs contextes (128K tokens).

FlashAttention : l’autre pilier

FlashAttention n’optimise pas directement le KV-cache, mais il optimise la façon dont le cache est lu pendant le calcul de l’attention. En réorganisant les accès mémoire pour minimiser les transferts entre la mémoire HBM (lente, grande) et les registres/SRAM du GPU (rapide, petite), FlashAttention réduit le nombre de lectures/écritures et accélère le calcul d’attention de 2 à 4×.

FlashAttention est complémentaire à PagedAttention. vLLM utilise les deux simultanément : PagedAttention gère l’allocation mémoire du KV-cache, FlashAttention optimise les opérations d’attention sur ce cache.

Guide pratique : optimiser le KV-cache

Arbre de décision

Votre modèle est-il déjà en GQA/MQA ?
├── Non → Envisagez un modèle plus récent avec GQA (Llama 3, Mistral, Qwen)
└── Oui → Continuez

Utilisez-vous vLLM ou TensorRT-LLM ?
├── Non → Migrez vers vLLM (PagedAttention activé par défaut)
└── Oui → PagedAttention est déjà actif

La VRAM est-elle le goulot d'étranglement ?
├── Non → Augmentez le batch size jusqu'à saturation GPU
└── Oui →
    ├── Activez la quantification KV (FP8 sur H100, NVFP4 sur Blackwell)
    ├── Activez le prefix caching (--enable-prefix-caching dans vLLM)
    ├── Réduisez max_model_len au minimum nécessaire
    └── Si toujours insuffisant → Offloading KV vers CPU (LMCache)

Métriques à surveiller

KV cache utilization : pourcentage de la mémoire KV-cache effectivement utilisée (vs allouée). Avec PagedAttention, visez > 96 %.

Throughput (tokens/s) : le nombre total de tokens générés par seconde sur toutes les requêtes du batch. C’est la métrique d’efficacité principale.

TTFT (Time To First Token) : impacté par le prefill et la récupération du KV-cache (si offloading ou prefix caching).

Batch size effectif : le nombre de requêtes traitées simultanément. Plus le KV-cache est optimisé, plus le batch peut être grand, et plus le throughput est élevé.

GPU memory utilization : pourcentage de VRAM utilisée. Visez 85-95 %. En dessous de 80 %, vous sous-utilisez le GPU. Au-dessus de 95 %, vous risquez des OOM (Out of Memory).

Bonnes pratiques

Utilisez vLLM ou TensorRT-LLM. PagedAttention est la baseline non négociable pour l’inférence en production. HuggingFace Transformers natif gaspille 60 à 80 % de la mémoire KV-cache. La migration vers vLLM apporte un gain de throughput de 2 à 24× selon le scénario, pour un effort d’intégration minimal.

Activez le prefix caching si vos prompts partagent des préfixes. Le prefix caching de vLLM partage automatiquement les blocs de KV-cache entre requêtes avec des préfixes communs. Pour les workloads avec un system prompt constant (chatbots, RAG), le gain mémoire est proportionnel au nombre de requêtes concurrentes × taille du préfixe partagé.

Quantifiez le KV-cache sur H100+. La quantification FP8 du KV-cache (supportée nativement par TensorRT-LLM et vLLM sur H100) réduit la taille du cache de 50 % avec une perte de qualité négligeable. Sur Blackwell, NVFP4 offre une réduction supplémentaire de 50 % (75 % total vs FP16).

Dimensionnez max_model_len au minimum nécessaire. La mémoire réservée pour le KV-cache est proportionnelle à max_model_len. Si vos requêtes n’excèdent jamais 8K tokens, ne configurez pas 128K. Chaque token de contexte inutilisé réserve de la mémoire qui pourrait servir à augmenter le batch size.

Monitorez et itérez. Les benchmarks publiés ne reflètent pas votre workload réel. Mesurez le throughput, la latence, et l’utilisation mémoire sur VOS requêtes, avec VOTRE distribution de longueurs de prompt. Ajustez les paramètres (gpu_memory_utilization, max_model_len, quantification) en fonction des données réelles.