La mémoire du cache KV a dépassé les poids du modèle comme contrainte porteuse pour l'inférence LLM en production à grande échelle. Les chiffres d'un survol technique Marktechpost publié mercredi : un modèle 30 milliards de paramètres qui roule batch 128 avec des inputs de 1 024 tokens a besoin d'environ 180 Go juste pour l'état du cache KV. Pour un modèle 7B, le cache KV (72 Go), c'est 5x plus gros que les paramètres du modèle eux-mêmes (14 Go en FP16). C'est l'inversion qui drive un champ de recherche actif — compresse le cache KV sans réentraîner le modèle de base, pis tu récupères de la marge de batch size, augmentes le débit pis sers plus d'utilisateurs concurrents sur le même matériel. Le survol couvre 10 techniques pertinentes en production à travers quatre familles de stratégies.

Famille un, c'est l'éviction — garde des tokens, jette les autres. H2O (Heavy Hitter Oracle, NeurIPS 2023) a observé qu'une petite fraction de tokens porte la plupart de la masse d'attention pis retient dynamiquement ceux-là plus les tokens récents, atteignant 29x de débit sur HuggingFace Accelerate sur OPT-6.7B/30B. StreamingLLM garde les premiers tokens (qui agissent comme « puits d'attention ») plus une fenêtre glissante de récence — rapide pis matériel-friendly mais aveugle à l'importance sémantique dans le contexte du milieu. SnapKV utilise une fenêtre d'observation à la fin des longs prompts pour compresser spécifiquement la phase prefill, attaquant une phase que H2O laisse intacte. PyramidKV / PyramidInfer alloue des tailles de cache différentes par couche basées sur des patterns d'attention observés, prétendant 2,2x de débit pis 54 pour cent de réduction de mémoire GPU. Le mode d'échec de la famille éviction, c'est la perte d'information : tout ce qui est jeté est parti pour le reste de la génération, fait que la qualité dégrade sur les tâches qui ont besoin de rappel mid-contexte dispersé.

Famille deux, c'est la quantification — garde tous les tokens, baisse les bits par token. KIVI, c'est de la quantification KV 2-bit plug-and-play sans fine-tuning, quantifiant les clés par canal pis les valeurs par token ; rapporte 2,6x de réduction de mémoire pic, 4x batches plus gros pis 2,35-3,47x de gains de débit. KVQuant ajoute de la précision mixte calibrée (quant clé par canal, quant pré-RoPE, décomposition dense-sparse) pis pousse à de la précision sub-4-bit pour des contextes jusqu'à 10 millions de tokens. TurboQuant — la méthode récente de Google — utilise une rotation orthogonale aléatoire (PolarQuant) plus une correction Johnson-Lindenstrauss quantifiée 1-bit, prétendant 6-8x de réduction de mémoire à 3-bit sans étape de calibration offline. Famille trois, c'est architectural : Grouped-Query Attention (GQA) pis Multi-Query Attention (MQA) réduisent la taille du cache KV par design — plusieurs têtes de query partagent moins de têtes key/value. GQA, c'est maintenant le défaut de facto dans Llama 3, Mistral pis la plupart des modèles open-weight. Le Multi-head Latent Attention (MLA) de DeepSeek va plus loin : projette les clés pis les valeurs dans un vecteur latent compressé pendant l'inférence pis rapporte 93,3 pour cent de réduction de cache KV dans DeepSeek-V2 sans perte de qualité. Famille quatre — la décomposition de poids low-rank de Palu / LoRC — applique de la projection low-rank de groupe-tête pis est orthogonale à la fois à la quantification pis à l'éviction, ce qui veut dire que ça peut s'empiler avec les autres familles.

Pour les builders, trois takeaways. Premièrement, la bonne technique dépend de quelle phase te crée des goulots. Si la latence prefill est la contrainte (prompts très longs), SnapKV pis les méthodes classe Pyramid aident ; si le débit decode est la contrainte (longues générations, beaucoup d'utilisateurs concurrents), H2O, KIVI pis StreamingLLM dominent. Si tu entraînes un nouveau modèle de zéro, le fix architectural (GQA/MLA), c'est le premier levier — c'est gratuit au temps d'inférence pis ça s'empile avec tout le reste. Deuxièmement, surveille quelles stacks d'inférence intègrent quelles techniques : vLLM, TensorRT-LLM, SGLang, llama.cpp pis TGI ont chacun des ensembles supportés différents, pis l'écart entre « le papier de recherche prétend X » pis « la bibliothèque de production livre X avec des kernels qui marchent sur ton GPU » est réel. Troisièmement, l'inversion (cache KV > poids du modèle), c'est la raison architecturale pour laquelle chaque sortie de modèle frontière en 2025-2026 a livré avec des modifications d'attention cuites dedans (le GQA de Llama 3, le MLA de DeepSeek-V2/V3, l'hybride GDN-plus-attention de Qwen3). Les « poids ouverts » que tu télécharges maintenant incluent des paris implicites de compression KV-cache ; si tu compares des modèles entre eux, comparer le coût d'inférence demande de mesurer l'empreinte du cache KV à ta taille de batch pis ta longueur de séquence spécifiques, pas juste le compte de paramètres. La leçon builder : quand la mémoire est le goulot, le compte de poids du modèle est plus la bonne unité de comparaison.