Aller au contenu principal
Les basesIntermédiaire7 min de lecture

KV cache : pourquoi la RAM sert à plus que le seul modèle

i
iaLocale Team
•
KV cache : pourquoi la RAM sert à plus que le seul modèle

Tu as téléchargé un modèle 8B en Q4, tu l'as chargé dans Ollama ou llama.cpp, et le programme t'indique une occupation mémoire bien supérieure au poids du modèle. Ce n'est pas un bug : c'est la KV cache (key-value cache). On va voir ce que c'est, combien elle occupe et comment la gérer, avec les chiffres d'un modèle qui tient sur un laptop.

Si tu veux la « mathématique » de la compression du modèle lui-même — ce que fait la quantisation et où elle perd de la qualité — l'article sur la Quantisation couvre ce terrain. Ici on parle d'autre chose : la mémoire que le modèle utilise en générant, token après token.

Qu'est-ce que la KV cache

Un modèle transformer lit un texte en « têtes » (tokens) et, pour chaque nouveau token, regarde les précédents grâce à l'attention. Pour cela, il calcule trois matrices par token : Query (Q), Key (K) et Value (V). S'il repartait de zéro à chaque nouveau token, il recalculerait K et V pour tous les tokens déjà lus : le coût croîtrait de façon quadratique et la génération serait inutilement lente.

La KV cache est le raccourci : les valeurs K et V de chaque token, une fois calculées, sont sauvées en mémoire. Quand le token suivant arrive, le modèle lit la cache au lieu de recalculer. C'est la mémoire à court terme de la conversation : plus le contexte est long, plus elle occupe d'espace.

Combien d'espace : la formule

La taille de la KV cache dépend de quatre paramètres que tu trouves dans le fichier de configuration du modèle (le config.json sur Hugging Face) et de la précision avec laquelle elle est stockée :

octets par token = 2 × niveaux × têtes_KV × dimension_tête × octets par valeur

Le « 2 » correspond aux deux matrices, K et V. « Têtes_KV » est le nombre de têtes utilisées par la cache : dans les modèles avec GQA (Grouped-Query Attention) il est différent du nombre de têtes de requête, et généralement plus petit — mais pour la mémoire totale, c'est toujours le nombre de têtes_KV qui compte. « Dimension_tête » est la dimension de chaque tête. « Octets par valeur » vaut 2 en fp16, 1 en int8.

Faisons le calcul avec de vrais chiffres. D'après le config.json de Llama 3.1 8B : 32 niveaux, 8 têtes_KV, dimension_tête 128, fp16.

2 × 32 × 8 × 128 × 2 = 131 072 octets = 128 KiB par token

Même modèle, int8 pour la KV cache : 65 536 octets, soit 64 KiB par token — la moitié.

Pour comparer un autre modèle, le config.json de Qwen3 8B : 36 niveaux, 8 têtes_KV, dimension_tête 128.

2 × 36 × 8 × 128 × 2 = 147 456 octets = 144 KiB par token (fp16)

Exemple concret : 8B, 8K ou 128K de contexte

On multiplie maintenant par la longueur du contexte, qui est le multiplicateur principal.

Llama 3.1 8B (128 KiB par token en fp16) :

ContexteTokensKV cache
8K8 192≈ 1,0 Gio
32K32 768≈ 4,0 Gio
128K131 072≈ 16 Gio

Qwen3 8B (144 KiB par token en fp16) :

ContexteTokensKV cache
8K8 192≈ 1,1 Gio
32K32 768≈ 4,5 Gio
128K131 072≈ 18 Gio

C'est ici que ça surprend : un modèle 8B qui pèse 5–6 Go en Q4 sur disque peut demander 20 Go de mémoire totale si on le fait tourner avec 128K de contexte en fp16. À long contexte, la KV cache pèse plus que le modèle lui-même.

C'est la raison pour laquelle, quand on dimensionne la mémoire nécessaire à un setup, il faut additionner poids + KV cache + activations. Les poids sont une constante (ils dépendent du modèle et de la quantisation) ; la KV cache est variable (elle dépend du contexte et de sa précision). Pour comprendre comment lire la VRAM requise par un modèle, l'article Matériel pour l'IA locale part de là.

Comment la configurer

Tu as trois leviers principaux.

1. La longueur du contexte. C'est le plus évident. Dans Ollama on le règle avec num_ctx dans le fichier Modell, dans LM Studio c'est le curseur « Context length », dans llama.cpp c'est le flag -c (par exemple -c 8192). Si tu ne fais pas de très longues conversations ou que tu ne charges pas des documents entiers, 8K ou 16K sont souvent largement suffisants, et la KV cache reste sous les 2 Gio.

2. Quantiser la KV cache. C'est le levier le plus efficace. Dans llama.cpp, les flags --cache-type-k et --cache-type-v permettent de stocker les matrices K et V en int8 (Q8_0) au lieu de fp16. La moitié de la mémoire, avec une perte de qualité négligeable pour la plupart des modèles. Ollama et LM Studio ont des options équivalentes dans leur panneau de configuration. Résultat : un contexte de 128K qui occupait 16 Gio en fp16 descend à 8 Gio en Q8_0, sur Llama 3.1 8B.

3. Flash Attention. Il ne réduit pas la taille de la KV cache, mais rend le calcul de l'attention plus efficace en pic de mémoire : au lieu de matérialiser la matrice complète des attentions, Flash Attention la traite par blocs. Dans llama.cpp on l'active avec --flash-attn (ou -fa). La documentation de llama.cpp le décrit comme une optimisation à recommander toujours que le backend le supporte.

GQA : pourquoi les modèles récents occupent moins

Les modèles « anciens » (GPT-3, Llama 2 7B) utilisaient le MHA : chaque tête de requête avait ses propres K et V, donc le nombre de têtes_KV était égal au nombre de têtes de requête (par exemple 32). Les modèles avec GQA (Llama 3, Qwen3, Mistral) regroupent plusieurs têtes de requête sous un seul groupe K-V, réduisant le nombre de têtes_KV à 8 ou 12. Cela ne change pas le comptage total de mémoire par token (la formule est la même), mais rend le décodage plus rapide car le modèle lit moins de tenseurs séparés en mémoire à chaque pas.

Ce qu'il faut retenir

La KV cache n'est pas un détail secondaire : c'est la partie de la mémoire que tu contrôles, car elle dépend du contexte que tu choisis. Les poids du modèle sont fixes ; la KV cache est variable. Quand un modèle n'entre pas dans ta RAM, le premier endroit à regarder est le contexte, pas le poids du modèle : souvent il suffit de le réduire de 128K à 32K, ou de quantiser la KV cache en int8, et le problème disparaît.

Le modèle 8B que tu as sur ton laptop occupe 6 Go de poids. Mais la RAM qu'il faut pour le faire tourner correctement dépend du contexte que tu lui donnes — et c'est cette partie que tu peux régler toi-même, sans changer de matériel.

Article généré par IA

#inferenza#kv-cache#llama-cpp#memoria#ottimizzazione
Partager :

Vous avez aimé cet article ?

Abonnez-vous à la newsletter pour recevoir de nouveaux tutoriels et guides.

Après l'inscription, vous recevez un e-mail de confirmation (double opt-in). Sans confirmation, nous n'envoyons rien. Pas de spam, promis.

Articles Correlés

Décodage spéculatif et MTP : la vitesse sans compromis
Les bases6 min de lecture

Décodage spéculatif et MTP : la vitesse sans compromis

Le décodage spéculatif accélère l'IA locale sans changer la qualité de la sortie : un modèle esquisse les jetons, le grand modèle les vérifie. Voici comment fonctionne le schéma-verification, les têtes MTP de Qwen, EAGLE sur Mistral Medium 3.5 et comment activer le tout en trois commandes.

iaLocale Team - 12 octobre 2026Lire la suite
RAG : posez des questions à vos documents
Les bases5 min de lecture

RAG : posez des questions à vos documents

Le RAG (Retrieval Augmented Generation) est le moyen le plus simple de faire répondre un modèle local à des questions sur vos documents : encodage sémantique, base vectorielle et boucle de récupération, avec un exemple concret.

iaLocale Team - 24 septembre 2026Lire la suite