TurboQuant - Un LLM de 104B sur un MacBook, merci Google

TurboQuant - Un LLM de 104B sur un MacBook, merci Google

TurboQuant compresse le KV cache des LLMs de 3,8x à 6,4x sans réentraînement, permettant un Command-R+ de 104B sur MacBook M5 Max avec 128K tokens de contexte et 74 Go de RAM max. Les valeurs V se compressent gratuitement en 2 bits sans perte de qualité, seules les clés K dégradent la performance, ce qui ouvre des configurations asymétriques (K q8_0 + V turbo3). L'implémentation communautaire TheTom dans llama.cpp est le seul moyen de tester TurboQuant aujourd'hui sur Apple Silicon, NVIDIA et AMD, Google ne sortant son code officiel qu'en Q2 2026.

Résumé généré par IA

Vous faites tourner des LLMs en local et, ô drame, la VRAM de votre ordinateur explose dès que le contexte dépasse 8000 tokens ? Le problème, c'est le KV cache ! Le KV cache stocke les clés et valeurs d'attention et grossit linéairement avec la longueur du prompt. Pour gérer ce problème, Google a annoncé un algorithme qui compresse tout ça de 3,8 à 6,4 fois. Un développeur a déjà implémenté cela dans un fork de llama.cpp.

Concrètement, cela donne :

llama-server -m model.gguf -ctk turbo3 -ctv turbo3 -fa on

Et vous venez de diviser la mémoire du cache par 4,6. Ainsi, un énorme Command-R+ de 104 milliards de paramètres arrive à tourner à 128K tokens de contexte sur un MacBook M5 Max, avec un pic mémoire max de 74 Go.

Comprendre le problème

Lorsque un LLM génère du texte, il stocke pour chaque token passé 2 vecteurs (la clé K et la valeur V) dans un cache. Plus le contexte est long, plus ce cache grossit. Par exemple, sur un Llama 70B avec 128K tokens de contexte, le KV cache en fp16 consomme plus de 40 Go de RAM. Votre modèle Llama 3.1 ou Qwen3 rentre en mémoire, mais le cache déborde.

Google a publié son papier fin mars, proposant de compresser ces vecteurs K et V en 3-4 bits au lieu de 16, sans ré-entraîner le modèle. L'algorithme fonctionne en deux étapes :

• PolarQuant : Applique une rotation Walsh-Hadamard aux vecteurs pour "gaussianiser" leur distribution.
• QJL (Quantized Johnson-Lindenstrauss) : Correcteur d'erreur à 1 bit qui élimine le biais résiduel sans overhead mémoire pour les constantes de quantification.

Les découvertes de TheTom

TheTom a transformé le document académique de Google en code C avec des kernels Metal pour Apple Silicon et CUDA pour NVIDIA. Ses découvertes les plus intéressantes ne figurent pas dans le papier :

• Compression des valeurs V : Compresser V à 2 bits n'affecte pas la qualité d'attention, tant que les clés K restent en q8_0.

• Couches limites hypersensibles : Protéger les 2 premières et 2 dernières couches en q8_0 pendant que le reste est compressé en turbo2 permet de récupérer jusqu'à 91% de la perte de qualité.

• Sparse V : Un décodage du cache qui saute les positions V à faible poids d'attention permet de gagner environ 23% de vitesse de décodage à 32K tokens de contexte, sans dégradation de la qualité.

Modes de compression

Il existe 3 modes :

• turbo4 : compresse 3.8x avec une réponse quasi identique.

• turbo3 : compresse 4.6x avec une perte de qualité à peine détectable.

• turbo2 : pousse à 6.4x, mais doit être utilisé avec précaution (uniquement sur les valeurs V, pas les clés K).

Pour l'instant, Google n'a toujours pas publié de code officiel (prévu pour le deuxième trimestre 2026). Cette implémentation communautaire est le seul moyen de tester dans un fork llama.cpp. Cela fonctionne sur Apple Silicon M1 à M5, NVIDIA RTX 3080 Ti à 5090 et AMD 6800 XT / 9070 XT. De nombreux utilisateurs ont testé sur du matériel varié et les résultats sont prometteurs.

Si vous faites de l'inférence LLM locale et que la mémoire vous limite, c'est le moment de tester ça !