TurboQuant : décryptage de la compression du cache KV

Temps de lecture : 10 min | Comment la compression 3 bits de Google rend les LLM à contexte long moins coûteux, et ce que cela nous dit des 18 prochains mois de l'inférence IA

Il existe un problème discret au cœur de chaque longue conversation que vous menez avec un grand modèle de langage, et c'est la raison pour laquelle ces conversations coûtent cher. Il s'appelle le cache KV et, aux grandes longueurs de contexte, il peut consommer plus de mémoire que le modèle lui-même. Le 24 mars, une équipe de Google Research a publié TurboQuant, qui comprime ce cache à trois bits par valeur, sans perte de précision mesurable et sans affinage. Six fois moins de mémoire. Une attention jusqu'à huit fois plus rapide sur une H100. Cela vaut la peine d'être bien compris, car la compression du cache KV est aujourd'hui l'un des problèmes à plus fort effet de levier de l'IA déployée, et TurboQuant est le signal public le plus net à ce jour que le domaine a passé un cap.

Je dirige Kentino. Cela consiste notamment à lire attentivement des articles comme celui-ci pour que nos clients — mineurs, intégrateurs, Européens curieux qui suivent la pile IA et crypto — n'aient pas à le faire. Ce texte est ma tentative d'expliquer ce que fait réellement TurboQuant, comment il s'inscrit dans la vague plus large de la recherche 2025-2026 sur la compression du cache KV, et ce qu'une personne raisonnable peut attendre des dix-huit prochains mois.

Le problème du cache KV, énoncé honnêtement

Quand un transformeur génère du texte, chaque nouveau jeton porte son attention sur tous les jetons précédents. Pour éviter de recalculer à chaque étape les tenseurs de clés et de valeurs de ces jetons antérieurs, le modèle les conserve. Ce stockage, c'est le cache KV.

Le cache croît linéairement avec la longueur du contexte. Doublez la conversation, vous doublez le cache. Pour un modèle 8B de taille moyenne exécutant un contexte de 128k jetons en FP16, le cache KV peut facilement atteindre des dizaines de gigaoctets pour une seule session. Les poids en pèsent peut-être seize. Le cache les écrase.

Trois conséquences pratiques en découlent.

D'abord, l'inférence à contexte long est limitée par la mémoire avant de l'être par le calcul. Vous êtes à court de VRAM bien avant d'être à court de FLOPS.

Ensuite, le coût de service passe mal à l'échelle. Chaque utilisateur simultané a besoin de son propre cache. Un GPU qui pourrait traiter par lots cinquante conversations courtes n'en gérera peut-être que cinq longues.

Enfin, l'inférence sur l'appareil et en périphérie reste hors de portée pour les modèles qui y seraient réellement utiles, parce que c'est le cache, et non les poids, qui refuse d'entrer.

Bien comprimer le cache KV — c'est-à-dire agressivement, à bas coût et sans nuire à la qualité des sorties — n'est donc pas une optimisation mineure. Cela change les charges de travail viables et celles qui ne le sont pas. C'est le problème auquel s'attaque TurboQuant.

Ce que fait réellement TurboQuant

TurboQuant est un algorithme en deux étapes. Les deux étapes se passent d'entraînement et sont indépendantes des données : aucun affinage, aucun jeu de calibration, aucun réglage par modèle. Vous l'appliquez et cela fonctionne. Honnêtement, cela compte plus que le taux de compression, car c'est ce qui permet à la méthode de s'insérer sans friction dans une pile d'inférence existante.

Étape une : PolarQuant

La première étape est PolarQuant, un article distinct du même groupe (Zandieh, Mirrokni et al., AISTATS 2026). L'idée est structurelle plutôt que statistique.

Quantifier des vecteurs de grande dimension en coordonnées cartésiennes est malcommode. Le réflexe naturel — normaliser sur la sphère unité, puis quantifier la direction — se révèle coûteux, car calculer la norme de chaque vecteur est précisément le goulot d'étranglement que l'on cherchait à éviter. Les méthodes antérieures payaient ce coût et perdaient malgré tout en précision aux faibles largeurs de bits.

PolarQuant fait deux choses pour éviter le piège. Il applique d'abord une rotation aléatoire, ce qui, de manière un peu contre-intuitive, rend la géométrie de la distribution des vecteurs plus prévisible et plus maniable. Il convertit ensuite en coordonnées polaires — un rayon pour la magnitude, un angle pour la direction — et projette le tout sur une grille circulaire quantifiable sans passer par l'étape de normalisation. Le résultat est une représentation nette, en faible nombre de bits, de chaque vecteur, qui en préserve la géométrie essentielle.

Étape deux : QJL

PolarQuant seul laisse une erreur résiduelle. La deuxième étape, Quantized Johnson-Lindenstrauss (QJL), la corrige avec un bit supplémentaire par valeur.

La transformée de Johnson-Lindenstrauss est un résultat classique : on peut projeter des vecteurs de grande dimension dans un espace de dimension bien inférieure au moyen d'une application linéaire aléatoire, en préservant approximativement les distances deux à deux. QJL pousse l'idée plus loin en ne gardant que le bit de signe de chaque coordonnée projetée — plus un, moins un, rien d'autre. Aucun surcoût de stockage au-delà du bit lui-même.

Ce que QJL apporte, mathématiquement, c'est un estimateur non biaisé des scores d'attention. Il corrige le résidu de PolarQuant sans réintroduire le biais dont souffrent les schémas naïfs à faible nombre de bits. C'est là toute l'astuce. Un bit de signe, choisi avec soin, suffit à nettoyer l'erreur de la première étape.

Les chiffres

Combinées, les deux étapes aboutissent à trois bits par valeur, soit six fois moins que la référence FP16. Sur une NVIDIA H100, le calcul des logits d'attention va jusqu'à huit fois plus vite en 4 bits qu'en 32 bits. Google a testé Gemma, Mistral et Llama-3.1-8B-Instruct sur LongBench, Needle In A Haystack, ZeroSCROLLS, RULER et L-Eval. La précision a été préservée sur les cinq bancs d'essai à contexte long. Un test annexe de recherche vectorielle sur GloVe-200 a également montré un meilleur rappel 1@k face aux références PQ et RabbiQ, ce qui suggère que la méthode se généralise au-delà des seuls caches KV.

L'exposé complet est publié sur le blog de Google Research. TurboQuant sera présenté à ICLR 2026, à Rio de Janeiro.

La vague de fond

TurboQuant n'est pas seul. C'est l'entrée récente la plus visible d'un domaine de recherche qui bouge vite, et le lire hors contexte exagère sa nouveauté. Plusieurs autres méthodes de fin 2025 et début 2026 attaquent le même goulot d'étranglement sous des angles différents.

Chacune vise une niche différente. KVTC sert à la réutilisation hors ligne — stocker le cache d'une conversation pour le recharger dans une autre, là où l'on peut se permettre un encodage plus lourd en échange d'une compression bien supérieure. ChunkKV convient aux cas où il faut comprimer agressivement tout en préservant le sens, ce qui importe pour les tâches où perdre un jeton coûte plus cher que perdre une décimale de précision. PM-KVQ est réglée pour les longues chaînes de raisonnement que produisent les modèles de raisonnement. KVPress est la tuyauterie qui permet au reste d'entre nous de les comparer honnêtement.

La contribution propre à TurboQuant, c'est la combinaison d'un fonctionnement sans entraînement, d'une aptitude à l'inférence en ligne et d'un estimateur dont l'absence de biais est démontrée. C'est la méthode la plus susceptible d'arriver en premier dans les cadres de production, précisément parce qu'elle ne demande rien à l'exploitant du modèle.

Ce que cela débloque

En prenant du recul par rapport à l'article pour réfléchir à la suite : les effets pratiques sont plus faciles à nommer qu'à chiffrer.

L'inférence à contexte long devient nettement moins chère. Si votre cache KV est six fois plus petit, vous pouvez traiter par lots davantage d'utilisateurs sur le même GPU, ou servir des contextes plus longs à budget constant, ou les deux. Quiconque exploite un service d'inférence le ressent sur ses marges dans le trimestre qui suit l'intégration.

Le déploiement en périphérie devient viable pour des catégories de modèles jusqu'ici hors de portée. Un modèle 8B à contexte long sur un GPU de station de travail, ou un modèle 3B sur un portable, passe de « à peine possible » à « courant » quand le cache se réduit d'un tel facteur. Le déploiement sur site pour les entreprises qui ne peuvent pas envoyer leurs données vers des API cloud — juridique, médical, télémétrie industrielle — en profite tout autant.

Le volet matériel en découle directement, et c'est là que cela cesse d'être abstrait. Une compression comme TurboQuant ne change pas les GPU qui existent ; elle change les charges de travail qui tiennent — et aujourd'hui, les charges que l'on veut réellement exécuter sur site sont les modèles chinois de frontière à poids ouverts, qui ont discrètement pris la place d'état de l'art au premier trimestre 2026.

La sélection actuelle mérite d'être nommée explicitement, car c'est ce sur quoi nos clients nous interrogent. Kimi K2.5 de Moonshot AI — 1T de paramètres au total, 32B actifs, MoE, contexte de 256K, licence MIT — sorti le 27 janvier, il domine les bancs d'essai de code et de mathématiques parmi les poids ouverts. GLM-5 de Z.ai — 744B au total / 40B actifs, contexte de 204K, sous licence MIT — actuellement en tête de l'Intelligence Index des poids ouverts et de SWE-bench Verified. MiniMax M2.5 — 229B au total / 10B actifs, contexte de 200K — sorti le 12 février, tarifé agressivement, plus de 80 % sur SWE-bench. Qwen3-Coder-Next d'Alibaba — 80B au total / 3B actifs, contexte de 256K en natif, extensible à 1M avec YaRN — sans oublier la famille Qwen3 au sens large, des modèles denses 0.8B–27B jusqu'au MoE 397B-A17B. Tous à poids ouverts. Tous déployables dès aujourd'hui.

Chez Kentino, nous construisons des machines précisément pour cette charge de travail ; soyons donc concrets sur les calculs. Notre serveur d'inférence phare est une configuration 4× NVIDIA RTX 4090 — 96 GB de VRAM mutualisée, AMD EPYC 7542 sur une ASRock Rack ROMED8-2T, 256 GB de DDR4-2666 ECC RDIMM, 2 TB NVMe, deux alimentations de 2 kW, dans un rack 24U. Au-dessus, nous construisons des configurations 4× RTX 5090 et 8× RTX 5090 (128 GB et 256 GB de VRAM mutualisée) ainsi que des configurations de classe centre de données 4× L40 / L40S (192 GB mutualisés en ECC) pour la charge soutenue de classe entreprise et le service en production 24h/24 et 7j/7.

Ce que TurboQuant change dans ce tableau, c'est le terme du cache KV. Les modèles MoE modernes utilisent déjà une attention compressée (attention latente de type MLA chez Kimi, GQA chez Qwen3) : leur cache KV par jeton est donc déjà plus petit que les chiffres des anciens modèles de classe Llama. Ajoutez TurboQuant par-dessus et vous gagnez encore environ 6×. L'effet pratique, c'est que la fenêtre de contexte qu'une machine donnée peut réellement servir — par opposition à celle qu'elle affiche — augmente sensiblement. Les poids n'ont pas bougé. Le goulot d'étranglement, si.

Deux réserves honnêtes. D'abord, Kimi K2.5 et GLM-5 en FP8 complet (1T et 744B au total de poids respectivement) dépassent encore ce que contiennent ces machines : pour ceux-là, il faut envisager une grappe ou accepter une quantification INT4 agressive. Ensuite, les limites exactes en jetons dépendent de la taille des lots, de la configuration d'attention propre au modèle et du cadre logiciel (vLLM, SGLang et TensorRT-LLM implémentent tous le KV à faible nombre de bits différemment). Mais c'est la tendance qui compte : une machine 4× RTX 4090 qui, il y a un an, se justifiait pour des modèles denses 13B est aujourd'hui la bonne réponse pour Qwen3-Coder-Next avec son contexte de 256K complet. Une 4× RTX 5090 gère confortablement le modèle de code de classe 80B actifs avec de la place pour des utilisateurs simultanés. Une 8× RTX 5090 ou une 4× L40S ouvre la voie à MiniMax M2.5 et aux plus grandes variantes MoE de Qwen3 à l'échelle de la production. Le matériel n'a pas grossi ; c'est la charge de travail qui a rétréci.

Et toute charge d'inférence qui tourne en continu sur de la télémétrie opérationnelle en profite proportionnellement. L'optimisation de flottes de minage en est un exemple concret : des exploitants comme OneMiners font tourner des systèmes d'efficacité pilotés par l'IA sur des milliers d'ASIC, et la couche d'inférence sous-jacente passe à l'échelle en fonction directe du contexte que chaque modèle peut conserver à bas coût. Cette catégorie de recherche ne transforme pas ces charges du jour au lendemain, mais elle déplace la courbe de ce qui est abordable.

La prévision honnête est incrémentale. Une réduction de mémoire de 6× sur un seul goulot d'étranglement ne crée pas un monde nouveau. Elle produit une version légèrement moins chère, au contexte légèrement plus long et légèrement plus déployable du monde que nous avons déjà. Cela représente malgré tout, à l'échelle du secteur, beaucoup d'argent et d'ingénierie économisés.

Ce qu'il faut surveiller en 2026-2027

Quelques points précis, par ordre approximatif de probabilité.

Intégration dans les cadres logiciels. vLLM, TensorRT-LLM et SGLang adopteront des méthodes de type TurboQuant d'ici quelques mois, probablement via KVPress comme couche de référence. L'implémentation Triton open source publiée par l'équipe de Google rend la chose presque mécanique.

Prise en charge au niveau matériel. NVIDIA a signalé son intérêt pour les primitives d'attention à faible nombre de bits, à travers KVTC comme KVPress. Attendez-vous à ce que l'outillage de génération Blackwell traite les formats KV 3-4 bits comme des citoyens de première classe et non comme des expérimentations.

Consolidation des méthodes. Les cinq approches ci-dessus résolvent des problèmes qui se recoupent. Une pile unifiée — compression géométrique de type PolarQuant pour l'attention en ligne, codage entropique de type KVTC pour le stockage hors ligne, regroupement sémantique de type ChunkKV en amont — est l'aboutissement le plus probable. Aucun article ne l'atteint à lui seul ; la pile se forme au fil d'une année de travaux d'intégration.

Baisses réelles des coûts de service. D'ici fin 2026, les coûts de service de l'inférence à contexte long devraient être visiblement inférieurs à ceux d'aujourd'hui, l'essentiel du gain venant de la compression plutôt que d'un nouveau silicium. C'est la façon la plus nette de prédire que cette ligne de travaux aura réussi.

Conclusion

TurboQuant est une avancée réelle sur un goulot d'étranglement réel, et il arrive au sein d'une vague de recherche qui attaque le problème sous plusieurs angles à la fois. Les chiffres phares sont impressionnants en eux-mêmes — trois bits, six fois, huit fois — mais la propriété la plus importante est qu'il n'exige rien de l'exploitant du modèle. Ce sont les méthodes sans entraînement et indifférentes aux données qui finissent déployées.

Si vous exploitez de l'inférence à contexte long, à quelque échelle que ce soit, cela mérite d'être suivi. Sinon, cela mérite tout de même d'être compris, car l'économie des modèles que vous utiliserez un jour se décide, discrètement, dans des articles comme celui-ci.