Qu’est-ce que le KV cache
Quand un LLM génère du texte, chaque nouveau token doit « regarder » tous les tokens précédents — c’est le mécanisme d’attention. Sans optimisation, cela imposerait de recalculer, à chaque token, les projections de tout l’historique. Le KV cache évite ce gaspillage : pour chaque token déjà traité, et à chaque couche du modèle, on conserve en mémoire son vecteur clé (K) et son vecteur valeur (V). Le token suivant n’a plus qu’à lire ce cache.
C’est ce qui rend la génération autorégressive praticable. C’est aussi ce qui explique pourquoi un modèle qui « tient » en VRAM au démarrage finit par déborder en cours de route : les poids sont fixes, le KV cache, lui, grandit à chaque token.
Pourquoi il grossit
La taille du KV cache suit une formule simple, et c’est sa linéarité qui pose problème :
Deux variables sont sous votre contrôle à l’inférence : la longueur de contexte et le batch (le nombre de requêtes servies en parallèle). Les deux multiplient la mémoire. Doubler le contexte double le cache ; doubler le batch aussi. C’est pourquoi un service qui fonctionne en démonstration sur une requête courte s’effondre en production sous des contextes longs et de la concurrence.
Le calcul concret
Prenons un modèle de classe 70 milliards de paramètres de type Llama : ~80 couches, attention par groupes (GQA) avec 8 têtes KV, dimension de tête 128. En FP16 (2 octets par valeur) :
| Longueur de contexte | KV / requête (FP16) | KV / requête (FP8) | Batch 32 (FP16) |
|---|---|---|---|
| 2 048 tokens | ≈ 0,64 Go | ≈ 0,32 Go | ≈ 20 Go |
| 8 192 tokens | ≈ 2,6 Go | ≈ 1,3 Go | ≈ 82 Go |
| 32 768 tokens | ≈ 10,2 Go | ≈ 5,1 Go | ≈ 328 Go |
| 128 000 tokens | ≈ 40 Go | ≈ 20 Go | ≈ 1,3 To |
Un contexte de 8k tokens représente déjà ~2,6 Go par requête. Servez 32 requêtes en parallèle et le KV cache réclame ~82 Go — davantage que les poids du modèle quantifié sur la plupart des GPU. À 128k tokens de contexte, une seule requête engloutit 40 Go. La VRAM n’est pas saturée par le modèle : elle l’est par la mémoire de ce que le modèle a déjà lu. Ce mécanisme est au cœur de la raison pour laquelle les LLM sont limités par la mémoire.
PagedAttention : gérer le cache comme un OS
Le problème historique n’était pas seulement la taille du cache, mais sa fragmentation. Réserver un bloc mémoire contigu par requête — dimensionné pour le pire cas — gaspillait l’essentiel de la VRAM.
PagedAttention, introduit par vLLM, applique l’idée de la mémoire virtuelle d’un système d’exploitation : le KV cache est découpé en blocs de taille fixe, alloués à la demande, sans exiger de contiguïté. La fragmentation interne et externe disparaît, et le même GPU sert bien plus de requêtes concurrentes.
PagedAttention et le prefix caching automatique sont aujourd’hui la base commune des principaux runtimes — vLLM, SGLang, TensorRT-LLM. Ce n’est plus un avantage compétitif, c’est un prérequis.
Quantifier le cache : FP8 et au-delà
Puisque le KV cache est un poste mémoire à part entière, on peut le quantifier comme on quantifie les poids. La quantification du cache en FP8 — un octet par valeur au lieu de deux — double la capacité pour une perte de précision négligeable, et exploite directement les Tensor Cores FP8 du matériel récent. C’est devenu un réglage par défaut recommandé sur les piles de production.
La recherche pousse plus loin : des travaux récents (TurboQuant, présenté à ICLR 2026) visent ~3,5 bits par valeur via des rotations et une correction d’erreur, avec des gains annoncés de compression et de vitesse d’attention. Ces approches restent émergentes — pas encore de référence stable en production — mais elles confirment la direction : le cache est désormais une cible d’optimisation de premier plan.
Le prefix caching : ne pas recalculer deux fois
Beaucoup de requêtes partagent un préfixe commun : un long system prompt, des exemples few-shot, un document de contexte réutilisé. Le prefix caching conserve le KV cache de ce préfixe et le réutilise au lieu de le recalculer à chaque appel. Sur des charges où le préfixe représente la majorité des tokens d’entrée, le gain de latence et de débit est considérable — et il est gratuit en qualité, puisque le calcul est strictement identique.
Ce que ça change pour le dimensionnement
Trois réflexes en découlent. Budgéter le KV cache séparément des poids : c’est une ligne mémoire à part entière, fonction du contexte et du batch visés — utilisez le Tableau 1 comme point de départ. Activer FP8 sur le cache dès que le matériel le permet : c’est le doublement de capacité le moins coûteux disponible. Et mesurer le taux de réutilisation des préfixes : s’il est élevé, le prefix caching est le levier le plus rentable avant même de toucher au GPU.
Conclusion
Le KV cache est la pièce qu’on oublie de compter, puis qui décide de tout : la longueur de contexte servable, le nombre de requêtes concurrentes, le coût par token. Les poids déterminent si un modèle démarre ; le KV cache détermine ce qu’on peut réellement en faire en production. Pour le choix du runtime qui gère le mieux ce cache, voir vLLM vs llama.cpp vs TensorRT-LLM.
Sources et méthode
Mécanisme du KV cache et de l’attention : littérature publique sur l’architecture Transformer. PagedAttention : Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) et documentation vLLM. Quantification FP8 du cache et prefix caching : documentation publique vLLM (--kv-cache-dtype fp8, prefix caching), consultée le 14 mai 2026. TurboQuant : Google Research, présenté à ICLR 2026 — travaux émergents, sans implémentation de référence stable à ce jour. Les tailles de KV cache du Tableau 1 sont calculées à partir de la formule donnée et des dimensions publiées des familles Llama ; ce sont des ordres de grandeur, les architectures exactes variant d’un modèle à l’autre.
