Fiche concept

Optimisation du cache KV — PagedAttention, KV quantifié, cache spéculatif

À jour au 2026-07-23

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Optimisation du cache KV — PagedAttention, KV quantifié, cache spéculatif ?

À 32K de contexte, le cache KV de Llama 3 70B pèse à lui seul ~20 Go par requête — plusieurs fois les poids du modèle en INT8 — faisant de l'optimisation du cache KV le levier le plus puissant de l'économie d'inférence LLM.

De quoi il s'agit

Pendant l'inférence LLM autorégressive, les tenseurs key et value de chaque token précédemment généré doivent rester en mémoire GPU afin que les tokens futurs puissent y porter attention (mécanisme d'attention) — le cache KV. À de longues longueurs de contexte, le cache KV domine l'utilisation mémoire totale : pour Llama 3 70B à 32K contexte, le cache KV fait ~20 Go par requête, plusieurs fois plus grand que les poids du modèle eux-mêmes en INT8. L'optimisation du cache KV est donc le domaine à plus haut levier pour l'économie d'inférence LLM — chaque technique ici se traduit directement soit par plus d'utilisateurs concurrents sur le même GPU, soit par un contexte plus long au même coût.

Pourquoi c'est important

PagedAttention élimine la fragmentation mémoire et permet un débit jusqu'à 24× supérieur en chevauchant plusieurs séquences en toute sécurité — la plus grande avancée du service d'inférence de 2023-2024.
La quantification KV en INT8 divise par deux la mémoire du cache pour moins de 1 % de perte de qualité; INT4 la divise par quatre pour 2-3 % de perte.
Le caching de préfixe réutilise l'état KV d'un préfixe de prompt partagé entre requêtes, offrant souvent un gain de débit 5-10× pour les charges chatbot avec un prompt système commun.

Points clés

Le cache KV (tenseurs K + V par token gardés en mémoire GPU pour l'attention future) domine la mémoire long contexte — Llama 3 70B à 32K contexte = ~20 Go de cache KV par requête.
PagedAttention (vLLM, 2023) — allocation KV style table de pages élimine la fragmentation, amélioration de débit 24× ; maintenant standard dans vLLM, TensorRT-LLM, SGLang.
Quantification KV — INT8 divise par deux la mémoire avec <1% de perte qualité, INT4 divise par quatre à ~2-3% de perte ; standard dans les stacks de service modernes.
MQA (K/V unique pour toutes les têtes) et GQA (groupes de têtes partagent K/V, utilisé dans Llama 2/3, Mistral, Mixtral) rétrécissent le cache KV 4-8× au niveau architectural.
Caching préfixe / spéculatif — cacher le KV du préfixe partagé une fois, réutiliser entre requêtes ; gain de débit 5-10× pour charges chatbot avec prompts système partagés.

Termes employés sur cette page

KV cache: Les tenseurs clé et valeur mis en cache de tous les tokens générés précédemment, conservés en mémoire GPU pour que les tokens futurs puissent y prêter attention pendant l'inférence autorégressive ; domine la consommation mémoire sur les longs contextes.
PagedAttention: Technique de service d'inférence introduite par vLLM (Kwon et al., 2023) qui alloue le KV cache par blocs de taille fixe, à la manière des pages de mémoire virtuelle d'un OS, éliminant la fragmentation et permettant un débit 24× supérieur à une allocation contiguë naïve.
Grouped-Query Attention (GQA): Variante architecturale d'attention où des groupes de têtes de requête partagent un unique ensemble de tenseurs K/V (par ex. 8 groupes K/V pour 32 têtes de requête) ; utilisée dans Llama 2/3, Mistral, Mixtral, elle réduit le KV cache de 4 à 8× avec une perte de qualité quasi nulle.
Multi-Query Attention (MQA): Variante d'attention extrême où toutes les têtes de requête partagent un unique tenseur K et V ; réduit le KV cache d'un facteur H (nombre de têtes, typiquement 32 à 128) mais avec une perte de qualité mesurable par rapport à la GQA.
Prefix caching: Optimisation d'inférence qui stocke une seule fois le KV cache d'un préfixe de prompt partagé et le réutilise pour toutes les requêtes qui partagent ce préfixe ; canonique dans les charges de type chatbot avec prompts système partagés ; gain de débit typique de 5 à 10×.
Decision owner: La personne responsable qui assume l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, l'accès, la traçabilité, la supervision et l'escalade à travers le modèle opérationnel.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code.

Ouvrir dans l'application →