KV cache : calcul et dimensionnement

L'essentiel

• Le KV cache stocke, pour chaque token du contexte, les clés et valeurs d'attention de chaque couche. Sa taille est proportionnelle au contexte et au nombre de slots.
• Formule : KV (octets) = 2 × couches × têtes KV × dimension de tête × octets par valeur × tokens ^{1 2}.
• GQA (peu de têtes KV) divise la taille ; MLA (DeepSeek) la réduit de plus de 90 % ³.
• q8_0 divise par deux, q4_0 par quatre, pour une perte faible à modérée ⁵.
• Ordres de grandeur à 32k tokens en f16 : 2,4 Go (gpt-oss-120b), 3,2 Go (Qwen3-30B-A3B), 10,7 Go (Llama 70B) par slot. Estimations, à confirmer par la mesure.

Formule

NVIDIA : « Size of KV cache per token in bytes = 2 × num_layers × (num_heads × dim_head) × precision_in_bytes » ; exemple Llama 2 7B, 4 096 tokens ≈ 2 Go ¹. Databricks donne la même expression pour Llama2-70B en explicitant n_kv_heads ².

Pour un modèle à GQA (grouped-query attention), on remplace le nombre de têtes d'attention par le nombre de têtes KV, bien plus petit (4 à 8 au lieu de 32 à 64). C'est ce qui rend les modèles récents économes en mémoire de contexte.

Octets par valeur : 2 (f16, bf16), 1 (q8_0), environ 0,5 (q4_0).

Cas particuliers :

• Fenêtre glissante : les couches à attention locale (gpt-oss-120b une couche sur deux, Gemma 3) ne gardent que les derniers tokens (128 pour gpt-oss) ; la formule donne alors une borne haute.
• MLA (DeepSeek V2 et suivants) : clés et valeurs sont compressées en un vecteur latent ; réduction de 93,3 % par rapport à DeepSeek 67B ³. La formule par token devient environ couches × (dim latente + dim RoPE) × octets (estimation de la forme).
• Architectures hybrides (Qwen3.5 Gated DeltaNet) : une partie des couches n'a pas de KV classique ; la formule ne s'applique pas telle quelle.

Paramètres des modèles candidats

Tableau d'estimations par slot

Toutes les valeurs sont des estimations (formule ci-dessus, 1 Go = 10⁹ octets). Un slot = une conversation servie en parallèle.

Pour gpt-oss-120b, la valeur réelle est plus basse (fenêtre glissante sur la moitié des couches) ; pour les autres, la formule est exacte à l'implémentation près (alignement des blocs, buffers de calcul).

Impact du nombre de slots

Sans --kv-unified, llama-server réserve pour chaque slot une part du contexte total (-c divisé par -np, formulation du README à vérifier) ; la mémoire KV totale est celle du contexte total, quel que soit le remplissage. Avec --kv-unified, un seul buffer est partagé et se répartit selon l'usage réel ⁴. Dans les deux cas, la mémoire à réserver est celle du contexte total, pas celle d'un slot.

Budget total (poids + KV) pour N slots à 32k tokens chacun, KV q8_0, estimation :

Lecture : avec gpt-oss-120b et 8 slots de 32k en q8_0, on reste sous 70 Go, ce qui laisse de la place pour un modèle d'embeddings, un reranker et la base vectorielle dans les 96 à 110 Go allouables au GPU (Q-011). Avec le 70B dense, 8 slots longs approchent la limite. Ces chiffres ignorent les buffers de calcul (batch, flash attention) et l'occupation système : prévoir une marge de 10 à 15 % (hypothèse).

Quantification du KV cache

Options llama-server : --cache-type-k et --cache-type-v parmi f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1 ⁴. La FAQ Ollama, qui repose sur llama.cpp, résume : q8_0 « environ la moitié de f16 avec une très faible perte de précision », q4_0 « environ le quart, perte faible à moyenne » ⁵. La quantification de V requiert la flash attention.

Position de travail : q8_0 pour K et V par défaut (Q-003), à valider par un test de qualité sur des tâches de citation (le KV quantifié peut dégrader la fidélité des extraits longs ; hypothèse à tester).

Où va cette mémoire sur Strix Halo

Le KV cache vit dans la mémoire GPU, c'est-à-dire dans la part de la mémoire unifiée allouable via GTT. AMD recommande une réservation VRAM BIOS minimale (0,5 Go) et une augmentation de la limite TTM/GTT ¹⁴. Voir Linux / ROCm et Q-011.

Ce qu'il reste à tester

• Mesurer la mémoire réellement allouée par llama-server pour -c 131072 -np 4 avec et sans --kv-unified, en f16 et q8_0, pour gpt-oss-120b et Qwen3-30B-A3B ; comparer aux estimations.
• Vérifier les paramètres de gpt-oss-120b sur le config.json.
• Mesurer l'effet de q8_0 vs f16 sur la fidélité des citations longues.

• Montée en charge de 1 à 10 utilisateurs : gpt-oss-120b et Qwen3-30B-A3BAvec llama-server -np 8 --kv-unified et KV q8_0, gpt-oss-120b sert 3 utilisateurs simultanés à plus de 25 t/s chacun avec un TTFT p95 inférieur à 3 s sur prompts courts ; à 10 utilisateurs, le débit par utilisateur reste au-dessus de 10 t/s. Le comportement suit la courbe publiée pour Qwen3.6-35B-A3B (59 → 20 t/s par utilisateur de 1 à 8 slots) décalée vers le bas.À tester