Fiche concept

Cache KV

À jour au 2026-07-24T14:00:00Z

É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 Cache KV ?

Le cache KV, pas les poids du modèle, est la contrainte VRAM déterminante en inférence — un contexte de 8 000 tokens sur un modèle 70B consomme déjà ~42 Go, ce qui signifie que doubler la longueur de contexte double approximativement le coût matériel.

Le cache KV — cache clé-valeur — est la structure mémoire qui rend possible une inférence rapide et abordable pour les grands modèles de langage, et elle se trouve directement à l'origine des décisions de coût et de latence pour tout déploiement SAP Joule ou AI Foundation fonctionnant à un volume d'utilisateurs réel. Le comprendre, c'est ce qui distingue un architecte capable d'expliquer pourquoi une fenêtre de contexte plus longue coûte cher d'un architecte qui ne peut que pointer du doigt une facture.

Ce que c'est et pourquoi cela compte

Lorsqu'un modèle transformer génère une réponse token par token, chaque nouveau token doit « porter attention » à tous les tokens qui l'ont précédé — la conversation entière jusque-là, y compris le prompt système et tout contenu de grounding récupéré. Recalculer les projections de clé et de valeur pour tout cet historique à chaque étape rendrait la génération de plus en plus lente à chaque token, un effet qui s'aggrave nettement sur les longs prompts d'entreprise chargés de contexte SAP. Le cache KV évite cela : il stocke les projections de clé et de valeur pour chaque token dès qu'elles sont calculées pour la première fois, de sorte que générer le millième token ne nécessite de traiter que ce seul nouveau token, sans recalculer les neuf cent quatre-vingt-dix-neuf précédents. C'est le mécanisme unique qui rend possible, tout simplement, la génération multi-tours de type chat.

Comment cela fonctionne

Pourquoi c'est important

Sans cache, générer le token N imposerait une explosion de recalcul en O(N²) — le cache est ce qui rend possible la génération autorégressive à l'échelle entreprise.
Le prefix/prompt caching est directement pertinent pour Joule : les sessions préfixées par le même bloc de contexte d'entreprise peuvent réutiliser les projections KV en cache au lieu de les recalculer à chaque appel.
La formule mémoire concrète (2 × L × H × d × octets) permet à un architecte de dimensionner le matériel (A100-80GB unique vs pod multi-GPU) avant de s'engager sur une exigence de longueur de contexte.

Points clés

Mémoire du KV cache = 2 × n_layers × n_kv_heads × d_head × seq_len × batch × dtype_bytes.
PagedAttention (vLLM) fait passer l'utilisation GPU de ~40% à ~90% en virtualisant le KV cache.
Le prefix caching (RadixAttention) réutilise les représentations KV des préfixes de prompt partagés entre appels — critique pour les system prompts de SAP Joule.
La quantisation INT8 du KV divise par deux la mémoire de cache avec ~1% de perte de qualité quand une quantisation dynamique par token est appliquée.
L'éviction H2O réduit le cache de 20× pour les tâches de génération longue avec <5% de perte de qualité en ne conservant que les tokens à forte attention.
KV Cache n'est maîtrisé que lorsqu'il change une décision d'acheteur nommée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.
Utiliser les signaux SAP, analystes, études, KG et actualité comme preuve, pas comme décoration.
Séparer les faits vérifiés des tendances directionnelles et des hypothèses modélisées.
Définir le propriétaire, la métrique, le seuil, le chemin de support et le plan de retour arrière avant de passer à l'échelle.

Termes employés sur cette page

KV cache: Tampon mémoire stockant les matrices de clés et de valeurs de tous les tokens passés ; permet un coût de génération par étape en O(seq_len) au lieu d'un recalcul complet en O(seq_len²).
PagedAttention: Allocation du KV cache inspirée de la mémoire virtuelle (Kwon 2023, vLLM) qui stocke le cache en pages non contiguës, éliminant la fragmentation et relevant l'utilisation GPU.
Prefix caching: Mécanisme (RadixAttention, Zheng 2023) qui indexe les représentations KV des préfixes de prompt partagés afin que les appels répétés réutilisent le calcul mis en cache.
H2O: Heavy Hitter Oracle (Zhang 2023) : politique d'éviction du KV cache qui conserve les tokens à plus forte masse d'attention cumulée, réduisant la taille du cache par 20× avec moins de 5 % de perte de qualité.
INT8 KV quantisation: Compression des entrées du KV cache de BF16 (2 octets) à INT8 (1 octet), divisant la mémoire par deux avec ~1 % de perte de qualité lorsque des échelles dynamiques par token sont maintenues.
Decision owner: La personne responsable qui accepte l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, indicateurs, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique les politiques, les accès, la traçabilité, la supervision et l'escalade sur l'ensemble du 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 · les chiffres à citer.

Ouvrir dans l'application →