128k de contexte sur desktop : mensonge. Le cache KV l'a mangé.

Chaque fiche de modèle local se vante désormais d’une fenêtre de 128k. Sur un desktop, ce chiffre est un bail que votre RAM signe sans lire. Ce qui décide de la longueur réelle de vos documents, ce ne sont pas les poids — c’est le cache KV, et il scale avec le contexte comme un impôt convenu dans une devise étrangère.

La fenêtre de contexte n’est pas une fonctionnalité qu’on active. C’est un bail mémoire que vous payez chaque seconde où le serveur tourne.

Combien de RAM utilise réellement un contexte de 128k ?

L’arithmétique est publique et courte. Comme le détaille Transformer Inference Arithmetic, le cache KV stocke deux tenseurs — clés et valeurs — pour chaque couche, chaque tête KV, chaque token :

cache_bytes = 2 × couches × contexte × têtes_kv × head_dim × octets_par_élément

Prenons Llama 3.1 8B : 32 couches, 8 têtes KV, head_dim 128, directement depuis le config.json sur Hugging Face. À 131 072 tokens en fp16 (2 octets) :

2 × 32 × 131072 × 8 × 128 × 2 = 17 179 869 184 octets ≈ 16 Go

Les poids de ce même modèle en fp16 pèsent environ 16 Go. À contexte maximum, le cache est aussi gros que le modèle auquel il appartient. Le « modèle 8B qui tient dans 16 Go » devient discrètement un problème de 32 Go dès que vous poussez num_ctx à 128k.

Pourquoi le cache grandit-il avec la fenêtre ?

Parce que l’attention doit comparer chaque token à tous ceux qui le précèdent, et que l’inférence est autorégressive — rien n’est recalculé, tout est retenu. C’est toute l’astuce qui rend la génération rapide : les clés et valeurs de chaque token sont calculées une fois puis stockées. Le stockage par token est constant, donc le stockage total est linéaire en contexte. 128k n’est pas « un plus grand nombre » — c’est 128× le cache d’une fenêtre de 1k, alloué pour toute la durée de la session.

La grouped-query attention (GQA) est la remise côté modèle : moins de têtes KV, cache plus fin. Qwen2.5 7B utilise 28 couches avec seulement 4 têtes KV (config ici), donc la même fenêtre de 128k coûte environ 7 Go en fp16 — un vrai soulagement, et une raison pour laquelle ces modèles semblent plus accommodants sur des machines modestes.

Modèle (fp16)	Couches × têtes KV	Cache KV @ 128k	Poids	Cache vs poids
Llama 3.1 8B	32 × 8	~16 Go	~16 Go	~100 %
Qwen2.5 7B	28 × 4	~7 Go	~15 Go	~47 %

Faites le calcul vous-même — voilà toute la vérification :

def kv_cache_gib(layers, kv_heads, head_dim, ctx, bytes_per=2):
    return 2 * layers * ctx * kv_heads * head_dim * bytes_per / 2**30

print(kv_cache_gib(32, 8, 128, 131_072))  # Llama 3.1 8B  -> 16.0
print(kv_cache_gib(28, 4, 128, 131_072))  # Qwen2.5 7B    -> 7.0

Ce que le chiffre marketing passe sous silence

Voici le registre honnête de cet argument — y compris là où il plie :

• Le prefill est la seconde facture. Avant le premier token de réponse, tout le prompt est traité d’un bloc. Un prompt de 100k tokens, c’est 100k tokens à mâcher avant le premier caractère. Sur une 3060, c’est des minutes, pas des millisecondes.
• Les modèles sliding-window cassent le calcul — en votre faveur. Les architectures à la Mistral plafonnent l’attention à une fenêtre fixe par couche, donc le cache cesse de croître. La formule simple les surestime. Ce billet vise les transformers à attention pleine, c’est-à-dire l’essentiel de ce que les gens font tourner.
• La quantization du KV est réelle mais partielle. llama.cpp peut cacher le KV en q8_0, divisant à peu près le cache par deux avec un risque qualité. La moitié de 16 Go, c’est encore 8 Go.
• Les specs disent rarement les têtes KV. Vous fouillerez le config.json pour les trouver — ce qui en dit long sur la façon dont ce chiffre est censé être lu.

Rien de tout cela ne rend le contexte long inutile. Le RAG existe précisément parce que remplir une fenêtre est la façon coûteuse de dire « lisez la section 4 ». Mais une fiche qui imprime « 128k » sans imprimer la facture mémoire vend une voiture par sa vitesse de pointe sans jamais mentionner le réservoir.

Personne ne lit 128 000 tokens. Votre RAM les paie quand même, un par un.

Le remède est ennuyeux : réglez le contexte sur ce que votre charge de travail utilise vraiment. Une fenêtre de 32k coûte un quart du cache 128k et couvre presque tous les prompts qu’un développeur isolé envoie réellement. C’est la même discipline de registre que l’arithmétique RAM pour les LLM locaux — la taille du modèle n’est que la moitié du budget, et les niveaux de quantization rapetissent les poids sans toucher au calcul du cache.

Si le cache est le vrai prix du contexte, pourquoi les fiches vendent-elles la fenêtre sans jamais vendre la facture ? Et tour confessionnel : quel est le plus grand contexte que vous ayez réellement rempli jusqu’au dernier token — et la sortie valait-elle les gigaoctets ? Les commentaires sont ouverts ; le prochain billet de la série prendra le camp perdant.