Cache KV

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.

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.
• Sur un point de terminaison managé du generative AI hub, le KV cache lui-même est invisible pour le client — le seul levier exposé est le prefix/prompt caching (implicite pour OpenAI et Gemini, points d'arrêt cache_control explicites pour Anthropic Claude et Amazon Nova via l'orchestration v2) ; un déploiement BYOM auto-hébergé sur SAP AI Core (le dépôt d'exemples de SAP documente vLLM, llama.cpp, Ollama et LocalAI) expose au contraire toute la pile PagedAttention et quantisation.
• La taille du cache est un plafond de capacité dur avant d'être une courbe de coût : la concurrence est plafonnée dès que la somme des KV caches actifs dépasse la mémoire GPU, quel que soit le calcul encore inutilisé — c'est pourquoi un déploiement type Joule peut sembler « lent » alors que les graphes d'utilisation GPU montrent de la marge.
• Les modèles à base de GQA (Llama 3, Mistral) réduisent le KV cache de 4-8× face à l'attention multi-tête classique à perte de qualité quasi nulle — un choix d'architecture intégré au modèle, pas une optimisation d'exécution, donc deux modèles de taille similaire ne coûtent pas automatiquement le même prix à servir en contexte long.

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.

Sources

1. Kwon et al. 2023 — Efficient Memory Management for LLM Serving with PagedAttention (vLLM)
2. Zheng et al. 2023 — Efficiently Programming Large Language Models using SGLang (RadixAttention)
3. Zhang et al. 2023 — H2O: Heavy-Hitter Oracle for Efficient Generative Inference
4. Shazeer 2019 — Fast Transformer Decoding: One Write-Head is All You Need
5. NVIDIA H100 SXM Datasheet
6. OpenAI prompt caching documentation
7. Anthropic prompt caching documentation
8. vLLM documentation — PagedAttention and prefix caching
9. GitHub SAP-samples — btp-generative-ai-hub-use-cases: bring-your-own OSS LLM on SAP AI Core (Ollama, LocalAI, llama.cpp, vLLM, custom HF Transformers server)
10. SAP News Center — How SAP and NVIDIA Advance Enterprise AI Transformation (NIM inference optimisation, SAP-ABAP-1, 2026-03-17)
11. PyTorch — torch.nn.functional.scaled_dot_product_attention documentation
12. SAP Help Portal — Orchestration service in SAP AI Core generative AI hub (prompt/document grounding pipeline where prefix caching sits)