Poids 1-bit et compression du cache KV : la voie vers des modèles locaux de 200B+
Exécuter localement des modèles d'IA avec 200B+ paramètres devient un objectif réaliste grâce à Bonsai 8B de PrismML et TurboQuant de Google Research. Ces technologies réduisent drastiquement les besoins en mémoire pour les poids et le cache KV tout en conservant une qualité acceptable. Une analyse des principes, des benchmarks et du potentiel de mise à l'échelle.
Bonsai 8B : représentation des poids en 1-bit
PrismML a publié le modèle open-source Bonsai 8B sous licence Apache 2.0. L'architecture de base est Qwen3-8B dense, mais tous les poids (embeddings, projections d'attention, projections MLP, tête LM) sont quantifiés dans un format 1-bit de bout en bout. La taille du fichier GGUF est de 1,15 Go contre 16,38 Go en FP16, soit un taux de compression de 14,2x.
Performances :
- M4 Pro : ~131 tokens/sec
- RTX 4090 : ~368 tokens/sec
- iPhone 17 Pro Max : ~44 tokens/sec
Sur RTX 4090, la vitesse de génération est jusqu'à 6,2x plus rapide qu'en FP16, avec une efficacité énergétique 4–5x supérieure. Benchmarks (moyenne sur 6 catégories) : 70,5 (Bonsai) contre 79,3 (Qwen3 8B), 71,0 (Mistral 3 8B), 67,1 (Llama 3.1 8B). La qualité reste compétitive malgré la compression extrême.
Principe de quantification :
Chaque poids est 1 bit (0 ≈ -échelle, 1 ≈ +échelle), avec une échelle FP16 par groupe de 128 poids. Effectivement 1,125 bits/poids. L'inférence utilise des noyaux de déquantification inline sans matérialisation en FP16. Nécessite des forks de llama.cpp et MLX avec des noyaux personnalisés.
Limitation : La recette complète d'entraînement n'est pas divulguée, mentionnant un cadre mathématique propriétaire pour préserver le raisonnement.
TurboQuant : compression du cache KV à 3,5 bits/canal
Google Research a proposé TurboQuant pour la quantification extrême du cache KV sans réentraîner le modèle. L'objectif est de minimiser l'utilisation de la mémoire pendant l'inférence, qui augmente avec la longueur du contexte.
Résultats clés :
- 3,5 bits/canal : neutralité de qualité (aucune perte sur les tests de Google)
- 2,5 bits/canal : dégradation minimale
- Réduction de la mémoire du cache KV d'au moins 6x
Exemple pour Qwen3-235B-A22B (contexte 128k) :
- Cache KV FP16 : 23,5 GiB
- TurboQuant 3,5 bits : ~5,1 GiB
Économies >18 GiB juste sur le cache.
Mécanisme :
- Rotation des données dans un espace pratique pour la compression.
- Compensation des erreurs de quantification pour préserver les calculs.
L'approche est mathématiquement fondée, testée sur le cache KV.
Combiner les approches pour des modèles 200B+
Combiner la compression des poids de type Bonsai en 1-bit (14,2x) et TurboQuant pour le cache KV ouvre des perspectives pour l'inférence locale.
Calcul pour Qwen3-235B-A22B (poids bfloat16 437,7 GiB, contexte 128k) :
| Composant | FP16/bfloat16 | Compressé |
|-----------|---------------|------------|
| Poids | 437,7 GiB | ~30,8 GiB (14,2x) |
| Cache KV | 23,5 GiB | ~5,1 GiB (3,5 bits) |
| Total | ~461 GiB | ~36 GiB |
Défis restants :
- Surcharge d'exécution
- Bande passante mémoire
- Évolutivité du 1-bit vers 200B+
- Intégration des noyaux dans les frameworks en amont
Cette combinaison repousse la limite : les modèles serveur de 235B s'approchent du matériel grand public.
Points clés à retenir
- Bonsai 8B réduit les poids d'un modèle 8B à 1,15 Go (14,2x), vitesse sur RTX 4090 de 368 tokens/sec, qualité proche du modèle de base 8B.
- TurboQuant compresse le cache KV à 3,5 bits/canal sans perte de qualité, économisant 18+ GiB sur un contexte 128k pour un 235B.
- La combinaison donne ~36 GiB pour un modèle 235B au lieu de 461 GiB—un pas vers les géants locaux.
- Limitations : détails d'entraînement propriétaires, besoin de noyaux personnalisés.
- Perspectives : Développement d'alternatives open-source pour développeurs intermédiaires/seniors.
— Editorial Team
Aucun commentaire pour le moment.