Vous faites tourner des LLMs en local comme le gros fifou de Hipster IA que vous \u00eates et, \u00d4 drame, la VRAM de votre ordinateur explose d\u00e8s que le contexte d\u00e9passe 8000 pauvres malheureux tokens ?<\/p>\n
Le probl\u00e8me c’est le KV cache les amis ! Le KV cache c’est ce truc qui stocke les cl\u00e9s et valeurs d’attention et qui grossit lin\u00e9airement avec la longueur du prompt. C’est pour g\u00e9rer ce probl\u00e8me que Google a annonc\u00e9 sous la forme d’un whitepaper uniquement un algo qui compresse tout \u00e7a de 3,8 \u00e0 6,4 fois… et youpi pour nous, y’a un dev qui l’a d\u00e9j\u00e0 impl\u00e9ment\u00e9 dans Concr\u00e8tement \u00e7a donne :<\/p>\n Et vous venez de diviser la m\u00e9moire du cache par 4,6. Et voil\u00e0 comment un \u00e9noooorme Pour bien comprendre pourquoi c’est costaud, faut revenir au probl\u00e8me de base. En fait quand un LLM g\u00e9n\u00e8re du texte, il stocke pour chaque token pass\u00e9 2 vecteurs (la cl\u00e9 K et la valeur V) dans un cache. Plus le contexte est long, plus ce cache grossit. Et \u00e7a s’accumule vite… Par exemple, sur un Llama 70B avec 128K tokens de contexte, le KV cache en fp16 bouffe \u00e0 lui seul plus de 40 Go de RAM. Du coup votre mod\u00e8le Llama 3.1 ou Qwen3 rentre \u00e9videmment en m\u00e9moire, mais le cache, lui, fait tout d\u00e9border comme vous quand vous vous incrustez dans la mini piscine Intex des gosses.<\/p>\n Google a publi\u00e9 son papier D’abord PolarQuant<\/strong> : on applique une Puis on convertit les coordonn\u00e9es cart\u00e9siennes en coordonn\u00e9es polaires, rayon + angle. Le rayon capture alors l’essentiel de l’information, et l’angle se compresse tr\u00e8s bien parce que sa distribution est connue \u00e0 l’avance.<\/p>\n Ensuite, deuxi\u00e8me \u00e9tape, QJL<\/strong> (Quantized Johnson-Lindenstrauss) : Il s’agit d’un correcteur d’erreur \u00e0 1 bit qui \u00e9limine le biais r\u00e9siduel, le tout sans overhead m\u00e9moire pour les constantes de quantification, contrairement aux m\u00e9thodes classiques comme q4_0 ou q5_1 qui perdent 1-2 bits rien qu’en stockant leurs propres param\u00e8tres.<\/p>\n Et c’est l\u00e0 qu’intervient notre d\u00e9veloppeur de g\u00e9nie, TheTom, qui a pris ce document acad\u00e9mique de Google et l’a transform\u00e9 en code C avec des kernels Metal pour Apple Silicon et CUDA pour NVIDIA. Et c’est pas juste un portage b\u00eate et m\u00e9chant puisqu’il a vraiment pouss\u00e9 les exp\u00e9riences bien au-del\u00e0 du document original avec une couverture de tests de 100% et des benchmarks sur des mod\u00e8les de 1.5 \u00e0 104 milliards de param\u00e8tres.<\/p>\n Et ses d\u00e9couvertes les plus int\u00e9ressantes c’est justement ce qui n’est PAS dans le paper. Premi\u00e8re trouvaille : la compression des valeurs V est gratuite<\/strong>. Compresser V \u00e0 2 bits sur Qwen, Llama, Mistral ou Command-R+ n’a aucun impact mesurable sur la qualit\u00e9 d’attention, tant que les cl\u00e9s K restent en q8_0.<\/p>\n Et cela a \u00e9t\u00e9 confirm\u00e9 sur Metal M5 Max 128 Go, CUDA RTX 4090 et RTX 3090 par plusieurs testeurs ind\u00e9pendants. C’est franchement contre-intuitif, mais cela veut dire que toute la d\u00e9gradation de qualit\u00e9 vient de la compression des cl\u00e9s K, et pas de leurs valeurs. Du coup une config asym\u00e9trique (K en q8_0, V en turbo3) arrive \u00e0 r\u00e9cup\u00e8rer des mod\u00e8les o\u00f9 la compression sym\u00e9trique \u00e9choue.<\/p>\n Deuxi\u00e8me trouvaille : les couches limites sont hypersensibles. Prot\u00e9ger les 2 premi\u00e8res et 2 derni\u00e8res couches en q8_0 pendant qu’on compresse le reste en turbo2 permet de r\u00e9cup\u00e9rer jusqu’\u00e0 91% de la perte de qualit\u00e9. Et plus le mod\u00e8le est gros, mieux \u00e7a marche. C’est seulement 15 lignes de code, et l\u00e0 encore, y’a aucun impact sur la vitesse.<\/p>\n Troisi\u00e8me trouvaille : Sparse V, un d\u00e9codage du cache qui saute les positions V \u00e0 faible poids d’attention permet de gagner environ 23% de vitesse de d\u00e9codage \u00e0 32K tokens de contexte. Et z\u00e9ro d\u00e9gradation de la qualit\u00e9.<\/p>\n C\u00f4t\u00e9 chiffres bruts, y’a 3 modes : turbo4 compresse 3.8x et le mod\u00e8le r\u00e9pond quasi pareil qu’avant. turbo3 compresse 4.6x avec une perte de qualit\u00e9 \u00e0 peine d\u00e9tectable. turbo2 pousse \u00e0 6.4x mais l\u00e0 faut l’utiliser malin (uniquement sur les valeurs V, pas les cl\u00e9s K).<\/p>\n Et dire que pour l’instant Google n’a toujours pas publi\u00e9 de code officiel (mais c’est pr\u00e9vu pour le second trimestre 2026)… Donc pour le moment, cette impl\u00e9mentation communautaire est le seul moyen de tester
\nun fork de llama.cpp<\/a>
\n.<\/p>\nllama-server -m model.gguf -ctk turbo3 -ctv turbo3 -fa on<\/code><\/p>\n
\nCommand-R+ de 104 milliards de param\u00e8tres<\/a>
\narrive \u00e0 tourner \u00e0 128K tokens de contexte sur un MacBook M5 Max, avec un pic m\u00e9moire max de 74 Go.<\/p>\n
\nTurboQuant<\/a>
\nfin mars et leur id\u00e9e c’est de compresser ces vecteurs K et V en 3-4 bits au lieu de 16, sans r\u00e9-entra\u00eener le mod\u00e8le. En fait l’algorithme fait \u00e7a en deux \u00e9tapes…<\/p>\n
\nrotation Walsh-Hadamard<\/a>
\naux vecteurs pour “gaussianiser” leur distribution, genre transformer des donn\u00e9es qui partent dans tous les sens en une forme bien ronde et pr\u00e9visible.<\/p>\n
\nTurboQuant<\/a>
\ndans un fork llama.cpp. \u00c7a tourne sur Apple Silicon M1 \u00e0 M5, NVIDIA RTX 3080 Ti \u00e0 5090 et AMD 6800 XT \/ 9070 XT et visiblement, pas mal de monde a test\u00e9 sur du mat\u00e9riel vari\u00e9 et les r\u00e9sultats sont au rendez-vous.<\/p>\n