PrismML et Google rapprochent l’inférence locale des modèles 200B avec Bonsai et TurboQuant

L'exécution locale de très grands modèles de langage cesse d'être une fantaisie pour les enthousiastes disposant d'un rack serveur. Deux approches novatrices — les poids 1 bit de Bonsai par PrismML et la compression de KV-cache TurboQuant de Google Research — s'attaquent directement aux deux parties les plus coûteuses de l'inférence : la mémoire du modèle et la mémoire du contexte long.

Comment les poids sont comprimés

PrismML a présenté Bonsai 8B sous licence Apache 2.0 — un modèle basé sur Qwen3-8B, où presque tous les poids sont stockés en représentation 1 bit. En termes pratiques, cela signifie une chute drastique de la taille : environ 1,15 GB par rapport à 16,38 GB pour la version FP16, soit environ 14 fois plus petit.

L'entreprise souligne que ce n'est pas simplement une compression d'archive. Ce format nécessite des kernels spéciaux pour éviter de dépacker les poids en FP16 complet lors de l'inférence. Le schéma semble brut mais non primitif : chaque poids est codé en un seul bit, et un groupe de 128 poids reçoit une échelle commune en FP16.

En résultat, le coût effectif atteint environ 1,125 bits par poids. Selon les affirmations de PrismML, Bonsai 8B produit jusqu'à 368 tokens par seconde sur RTX 4090, environ 131 tokens par seconde sur M4 Pro, et reste compétitif en qualité parmi les modèles 8B, bien qu'il ne devienne pas le leader absolu sur les benchmarks.

Comment le KV-cache est réduit

Mais des poids légers seuls ne suffisent pas. Les grands modèles développent rapidement le KV-cache — mémoire de travail qui stocke les représentations de tokens et augmente avec la longueur du contexte. C'est là que Google Research propose TurboQuant.

La méthode comprime le KV-cache sans réentraînement du modèle et, selon les résultats des auteurs, maintient la qualité même dans la plage d'environ 3–3,5 bits par canal, où la quantification ordinaire commence déjà à risquer notablement la qualité de la réponse. L'approche repose sur deux idées clés : d'abord, les données sont pivotées vers un espace plus pratique où il est plus facile de comprimer fortement, puis une étape séparée compense l'erreur de compression. Grâce à cela, TurboQuant résout non seulement la question de la taille mais aussi le problème des coûts indirects qui consomment souvent le bénéfice de la quantification vectorielle ordinaire.

Dans les tests de Google, la méthode a montré au minimum une réduction de six fois de la mémoire KV-cache et une accélération du calcul d'attention par rapport à la représentation non comprimée.

Si les approches sont combinées

La partie la plus intéressante commence là où ces deux idées s'empilent. Si l'approche 1 bit de PrismML s'étend un jour à des modèles de classe 200B+, et que TurboQuant conserve ses propriétés sur contexte long, l'exécution locale de tels systèmes cessera d'être le domaine des serveurs avec des centaines de gigabytes de mémoire. En prenant Qwen3-235B-A22B comme exemple, les estimations semblent déjà non pas fantastiques mais techniquement discutables, pourtant tout à fait réalistes. Il ne s'agit pas encore d'un produit fini, mais de la trajectoire du développement matériel et de l'inférence.

• Poids du modèle en bfloat16 : environ 437,7 GiB
• Variante hypothétique 1 bit par analogie avec Bonsai : environ 30,8 GiB
• KV-cache pour contexte 128k en 16 bits : environ 23,5 GiB
• KV-cache avec TurboQuant à 3,5 bits : environ 5,1 GiB
• Total des poids et cache : de l'ordre de 36 GiB au lieu de plus de 460 GiB

Ce n'est pas encore une promesse d'un assistant 235B domestique prêt. Des questions demeurent concernant la bande passante mémoire, la qualité des kernels bas bit, la stabilité sur des tâches réelles et la portabilité du schéma 1 bit de 8B à des modèles sensiblement plus grands. Mais la trajectoire change : auparavant la conversation portait sur la compression de 7B ou 14B pour un ordinateur portable, désormais on en est déjà à se demander si une classe 200B peut être apportée au matériel local.

Que cela signifie

Le marché des LLM locaux passe de l'optimisation cosmétique à des percées architecturalement significatives en inférence. Si Bonsai et TurboQuant s'avèrent être extensibles, les gagnants ne seront pas seulement les enthousiastes mais aussi les entreprises qui ont besoin de confidentialité, de faible latence et d'exécution de modèles puissants sans dépendance constante du cloud. Pour les équipes d'entreprise, c'est déjà un chemin vers des assistants locaux d'une nouvelle classe sur un seul nœud puissant, plutôt que sur un cluster séparé.