● Korben 📅 01/04/2026 à 17:00

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

Data Science 👤 Korben
Illustration
TurboQuant - Un LLM de 104B sur un MacBook, merci Google1 avril 2026 / PAR KORBEN ✨ / 5 MIN DE LECTURE / À lire plus tard SauvegardéCe qu’il faut retenirTurboQuant compresse le KV cache des LLMs de 3,8x à 6,4x sans réentraînement, permettant un Command-R+ 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 configs 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 IAVous faites tourner des LLMs en local comme le gros fifou de Hipster IA que vous êtes et, Ô drame, la VRAM de votre ordinateur explose dès que le contexte dépasse 8000 pauvres malheureux tokens ?Le problème c'est le KV cache les amis ! Le KV cache c'est ce truc qui stocke les clés et valeurs d'attention et qui grossit linéairement avec la longueur du prompt. C'est pour gérer ce problème que Google a annoncé sous la forme d'un whitepaper uniquement un algo qui compresse tout ça de 3,8 à 6,4 fois... et youpi pour nous, y'a un dev qui l'a déjà implémenté dans un fork de llama.cpp .Concrètement ça donne :llama-server -m model.gguf -ctk turbo3 -ctv turbo3 -fa onEt vous venez de diviser la mémoire du cache par 4,6. Et voilà comment un énoooorme 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.Pour bien comprendre pourquoi c'est costaud, faut revenir au problème de base. En fait quand 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. Et ça s'accumule vite... Par exemple, sur un Llama 70B avec 128K tokens de contexte, le KV cache en fp16 bouffe à lui seul plus de 40 Go de RAM. Du coup votre modèle Llama 3.1 ou Qwen3 rentre évidemment en mémoire, mais le cache, lui, fait tout déborder comme vous quand vous vous incrustez dans la mini piscine Intex des gosses.Google a publié son papier TurboQuant fin mars et leur idée c'est de compresser ces vecteurs K et V en 3-4 bits au lieu de 16, sans ré-entraîner le modèle. En fait l'algorithme fait ça en deux étapes...D'abord PolarQuant : on applique une rotation Walsh-Hadamard aux vecteurs pour "gaussianiser" leur distribution, genre transformer des données qui partent dans tous les sens en une forme bien ronde et prévisible.Puis on convertit les coordonnées cartésiennes en coordonnées polaires, rayon + angle. Le rayon capture alors l'essentiel de l'information, et l'angle se compresse très bien parce que sa distribution est connue à l'avance.Ensuite, deuxième étape, QJL (Quantized Johnson-Lindenstrauss) : Il s'agit d'un correcteur d'erreur à 1 bit qui élimine le biais résiduel, le tout sans overhead mémoire pour les constantes de quantification, contrairement aux méthodes classiques comme q4_0 ou q5_1 qui perdent 1-2 bits rien qu'en stockant leurs propres paramètres.Et c'est là qu'intervient notre développeur de génie, TheTom, qui a pris ce document académique de Google et l'a transformé en code C avec des kernels Metal pour Apple Silicon et CUDA pour NVIDIA. Et c'est pas juste un portage bête et méchant puisqu'il a vraiment poussé les expériences bien au-delà du document original avec une couverture de tests de 100% et des benchmarks sur des modèles de 1.5 à 104 milliards de paramètres.Et ses découvertes les plus intéressantes c'est justement ce qui n'est PAS dans le paper. Première trouvaille : la compression des valeurs V est gratuite. Compresser V à 2 bits sur Qwen, Llama, Mistral ou Command-R+ n'a aucun impact mesurable sur la qualité d'attention, tant que les clés K restent en q8_0.Et cela a été confirmé sur Metal M5 Max 128 Go, CUDA RTX 4090 et RTX 3090 par plusieurs testeurs indépendants. C'est franchement contre-intuitif, mais cela veut dire que toute la dégradation de qualité vient de la compression des clés K, et pas de leurs valeurs. Du coup une config asymétrique (K en q8_0, V en turbo3) arrive à récupèrer des modèles où la compression symétrique échoue.Deuxième trouvaille : les couches limites sont hypersensibles. Protéger les 2 premières et 2 dernières couches en q8_0 pendant qu'on compresse le reste en turbo2 permet de récupérer jusqu'à 91% de la perte de qualité. Et plus le modèle est gros, mieux ça marche. C'est seulement 15 lignes de code, et là encore, y'a aucun impact sur la vitesse.Troisième trouvaille : 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. Et zéro dégradation de la qualité.Côté chiffres bruts, y'a 3 modes : turbo4 compresse 3.8x et le modèle répond quasi pareil qu'avant. turbo3 compresse 4.6x avec une perte de qualité à peine détectable. turbo2 pousse à 6.4x mais là faut l'utiliser malin (uniquement sur les valeurs V, pas les clés K).Et dire que pour l'instant Google n'a toujours pas publié de code officiel (mais c'est prévu pour le second trimestre 2026)... Donc pour le moment, cette implémentation communautaire est le seul moyen de tester TurboQuant dans un fork llama.cpp. Ça tourne sur Apple Silicon M1 à M5, NVIDIA RTX 3080 Ti à 5090 et AMD 6800 XT / 9070 XT et visiblement, pas mal de monde a testé sur du matériel varié et les résultats sont au rendez-vous.Donc voilà, si vous faites de l' inférence LLM locale et que la mémoire vous limite, c'est le moment de tester ça !Référenceshttps://cohere.com/blog/command-r-plus-microsoft-azurehttps://research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression/https://en.wikipedia.org/wiki/Hadamard_transformCet article peut contenir des images générées à l'aide de l'IA - J'apporte le plus grand soin à chaque article, toutefois, si vous repérez une boulette, faites-moi signe !Vous avez aimé cet article ?Alors rejoignez ma communauté sur Patreon et accédez à des articles exclusifs, des tutos avancés et plein d'autres surprises que je réserve à mes soutiens. C'est grâce à vous que je peux continuer à partager ma passion depuis 20 ans !Rejoindre l'aventure Développeurs, découvrez les offres taillées pour vos projetsContenu partenaireVous êtes développeur web ? Alors vous allez adorer les nouvelles offres de o2switch, conçues spécialement pour vous !Profitez d'une puissance inégalée : Cloud avec 12 CPU et 48 Go de RAM à 1,86 € HT/mois, ou Pro avec 24 CPU et 64 Go de RAM à 6,25 € HT/mois. Déployez vos projets en quelques clics grâce à Softaculous et ses + de 300 scripts prêts à l'emploi.La vitesse, vous aimez ? Eux aussi ! C'est pour ça qu'ils vous font fait profiter de la technologie NVMe dernière génération et de puissants caches comme Varnish et LiteSpeed. Tout ça avec la sérénité d'un hébergement français sécurisé par un WAF sur-mesure, des sauvegardes jusqu'à 90 jours (selon l'offre) et un support prioritaire 24/7 (N2 à N2+3 selon l'offre).Et vous savez quoi ? Les offres démarrent à seulement 1,86 € HT/mois. Foncez, c'est le moment de coder sans limites et de donner vie à vos projets les plus fous grâce à o2switch !Découvrez les nouvelles offres o2switch
← Retour