Le KV cache, c'est l'éléphant mémoire du service de LLM en long-contexte. Chaque token produit un tenseur de clés pis de valeurs qui reste résident pour la durée de la séquence, pis en long-contexte avec de gros modèles le cache consomme régulièrement 20 à 30 pour cent du VRAM total. Les solutions existantes (attention grouped-query, PagedAttention, quantification INT4/INT8) aident mais plafonnent. TurboQuant, publié cette semaine en arxiv 2504.19874 chez Google, prétend à environ 4,5 à 5x de compression par rapport aux références FP16 avec une perte de précision quasi-nulle, ce qui, si ça tient en production, est la compression de KV cache utilisable la plus agressive à ce jour.

Le truc, c'est un pipeline en deux étapes. L'étape une fait tourner aléatoirement les vecteurs d'entrée, ce qui concentre les valeurs de coordonnées dans une distribution Beta pis permet d'appliquer un quantificateur scalaire optimal par coordonnée. L'étape deux applique un quantificateur MSE suivi d'une transformation Johnson-Lindenstrauss quantifiée à 1 bit sur le résidu. Le stockage par token se réduit à des indices de quantification, des bits de signe, pis un scalaire de norme L2. À 3,5 bits par canal le papier rapporte une « neutralité de qualité absolue », ce qui veut dire que la perte de précision est statistiquement nulle sur leur évaluation. À 2,5 bits par canal, il rapporte une « dégradation de qualité marginale ». L'étape de rotation, c'est l'astuce architecturale : tu paies un petit coût de compute pour rendre la distribution de coordonnées quantification-friendly, pis la quantification scalaire par coordonnée fait la compression au lieu des approches traditionnelles par groupe ou par tenseur.

Pour quiconque sert des LLM avec du long-contexte, le calcul est direct. Si ta pile actuelle met en cache du KV FP16 pis que t'es limité par le VRAM (le cas commun en service mono-nœud avec 32k+ de contexte), 4,5 à 5x de compression se traduit par environ 5x de requêtes concurrentes au même budget mémoire, ou 5x de longueur de contexte par requête. Le bémol, c'est que l'abstract n'énumère pas quels modèles ont été testés, fait qu'avant de rouler TurboQuant en production, vérifie que l'évaluation couvre ta famille de modèles pis tes longueurs de séquence. Le papier cible aussi la recherche du plus proche voisin comme seconde application, ce qui suggère que le patron rotation-plus-quantification généralise au-delà des caches d'attention.

Le chemin pratique pour une équipe de service en production, c'est de surveiller les implémentations de référence pis de benchmarker contre ce que tu roules déjà. TurboQuant s'insère au même endroit dans ta pile d'inférence où KIVI, KVQuant ou Atom iraient, fait que le coût d'intégration est similaire. Si t'as déjà quantifié le KV cache, compare 3,5 bits par canal à perte de qualité zéro contre ta config actuelle ; c'est un plancher compétitif pour 2026. Si t'as pas encore quantifié, ce papier est le meilleur argument actuel pour commencer tout de suite. La tendance plus large, c'est que la compression du KV cache est plus une optimisation optionnelle. Aux charges long-contexte, c'est la contrainte bloquante, pis la recherche des labos de frontière converge rapidement vers des schémas sous-4-bits qui préservent la précision.