Le coût du cache clé-valeur¶

Pourquoi ce poste existe, comment il croît, et les quatre façons de le réduire.

Pourquoi le cache existe¶

Un modèle de langage génère un jeton à la fois. Pour produire le jeton n° 1 001, il a besoin des clés et des valeurs des mille jetons précédents.

Ces clés et ces valeurs ne changent jamais : la clé du jeton n° 3 est la même que le texte fasse 10 ou 100 000 jetons. Les recalculer à chaque étape rendrait la génération quadratique. On les stocke donc.

sans cache :  chaque nouveau jeton recalcule tout l'historique   → O(n²)
avec cache :  chaque nouveau jeton lit le cache et l'étend       → O(n)

Le gain en calcul est payé en mémoire, et cette mémoire croît linéairement avec la longueur du texte.

Ce n'est pas un défaut d'implémentation

Le cache est la bonne solution. Il faut simplement le compter quand on dimensionne — ce que ne fait aucun des tableaux de VRAM publiés depuis la sortie.

Comment il croît, ici¶

\[ c = L_{kv} \times 2 \times H_{kv} \times d_h \times b_c = 16 \times 2 \times 4 \times 256 \times 2 = 65\,536\ \text{octets par jeton} \]

Contexte	Cache BF16
4 096	0,27 Go
32 768	2,15 Go
131 072	8,59 Go
262 144	17,18 Go
524 288	34,36 Go
1 000 000	65,54 Go

Deux propriétés à retenir :

Linéaire en longueur. Doubler le contexte double le cache. Pas d'économie d'échelle.
Linéaire en concurrence. Dix conversations simultanées, dix caches.

Les quatre leviers¶

Deux sont décidés par Alibaba et se lisent dans config.json. Deux sont à votre main au déploiement.

Levier 1 — L'attention hybride (décidé)¶

Seules les couches d'attention complète produisent un cache.

Architecture	Couches avec cache	Cache à 262 144
Attention complète	64 / 64	68,72 Go
Hybride 3:1 (réel)	16 / 64	17,18 Go

C'est le levier le plus puissant, et il est déjà appliqué

75 % d'économie, sans rien faire. C'est la différence entre un modèle local utilisable à contexte long et un modèle qui sature à 30 000 jetons.

Levier 2 — L'attention à requêtes groupées (décidé)¶

24 têtes de requête pour 4 têtes clé-valeur — un ratio de 6:1.

Configuration	Cache à 262 144
24 têtes clé-valeur (sans GQA)	412,3 Go
4 têtes clé-valeur (réel)	17,18 Go

Un facteur 24. Combinés, les deux leviers d'architecture divisent le cache par 24 par rapport à un Transformer classique de mêmes dimensions.

Levier 3 — Quantifier le cache (à votre main)¶

C'est le premier réglage à activer sur un déploiement local à contexte long.

Format du cache	Par jeton	À 262 144 jetons
BF16	64 KiO	17,18 Go
FP8	32 KiO	8,59 Go
INT4	16 KiO	4,29 Go

vllm serve Qwen/Qwen3.8-27B-FP8 --kv-cache-dtype fp8

L'effet combiné avec les poids en 4 bits

Configuration	Total à 262 144 jetons
Poids 4 bits + cache BF16	31,2 Go
Poids 4 bits + cache FP8	22,6 Go

Une carte de 24 Go tient alors la fenêtre native complète — ce que le seul passage des poids en 4 bits ne permettait pas.

Avec la même réserve que pour les poids

Un cache en INT4 dégrade le rappel précis. Sur une tâche de recherche d'information dans un long document — exactement l'usage qui motive le contexte long — c'est contre-productif.

FP8 pour le cache est le bon compromis par défaut.

Levier 4 — Réduire le contexte (à votre main)¶

Le plus simple, et le plus souvent le bon.

La question à se poser avant de dimensionner

Usage	Contexte typique
Conversation, questions-réponses	4 000 à 16 000
Analyse d'un fichier de code	8 000 à 32 000
Agent sur un dépôt moyen	50 000 à 150 000
Analyse d'un corpus documentaire	200 000 et plus

Dimensionner pour 262 144 jetons quand on en utilise 20 000 revient à acheter beaucoup trop de matériel.

Le récapitulatif¶

Configuration	Cache à 262 144 jetons
Sans GQA ni hybride, BF16	412,3 Go
GQA seul, BF16	68,7 Go
GQA + hybride, BF16 (réel, par défaut)	17,2 Go
GQA + hybride, cache FP8	8,6 Go
GQA + hybride, cache INT4	4,3 Go

Un facteur 96 entre les deux extrêmes.

Le cas de la vidéo¶

Une particularité de ce modèle : la voie visuelle consomme aussi du contexte.

Entrée	Coût en jetons
Image 448 × 448	~196 jetons
Image haute résolution	plusieurs milliers
Vidéo	~196 jetons par paire d'images

Une vidéo remplit le contexte vite

À 196 jetons par paire d'images, une séquence de 30 images par seconde consomme environ 2 900 jetons par seconde de vidéo.

Une minute de vidéo représente donc de l'ordre de 176 000 jetons — les deux tiers de la fenêtre native, et 11,5 Go de cache.

Pour l'analyse vidéo, échantillonnez les images plutôt que de tout envoyer.

À retenir¶

Ce chapitre en cinq points

Le cache croît linéairement avec le contexte et la concurrence.
Ici : 64 KiO par jeton, soit 17,18 Go au contexte natif.
Hybride et GQA sont déjà appliqués et divisent le cache par 24.
Quantifier le cache en FP8 est le levier le plus rentable côté déploiement : une carte de 24 Go tient alors la fenêtre native complète.
La vidéo consomme ~2 900 jetons par seconde : échantillonnez.

Chapitre suivant : Quantification.