Bonsai 2 27B: compression ternaire 9x avec 98% des performances
En bref
- PrismML lance Bonsai 2 27B, un modèle de 27 milliards de paramètres compressé à 5,9 GB via des poids ternaires (−1, 0, +1) et scaling FP16, soit 9 fois plus léger que l'original.
- Le modèle conserve 98,2% des performances du Qwen3.8 27B sur un benchmark agrégé couvrant le raisonnement, la programmation, la vision et les agents.
- Il atteint 143 tokens/s sur RTX 5090 et 46,8 tokens/s sur M5 Max, avec 40% meilleure efficacité énergétique qu'un modèle 8B en précision complète.
- Sans dépendance propriétaire majeure : les poids sont libérés en Apache 2.0, mais nécessitent un fork spécifique de llama.cpp pour tourner.
Ce que dit la source
PrismML affirme que la compression ternaire (1,76 bits effectifs par poids) rend les modèles 27B exécutables sur des appareils locaux avec un ratio de compression inédit (9x) tout en préservant 98,2% des capacités du modèle original. L'enjeu mis en avant : cette « quasi-absence de perte » transforme la compression d'optimisation cosmétique en véritable déblocage de déploiement, puisque la même intelligence devient accessible sur bien plus de matériel.
- Ternary Bonsai 2 27B utilise poids ternaires ({−1, 0, +1}) avec scaling groupe en FP16, atteignant 1,76 bits effectifs par poids contre ~32 en précision complète
- Le modèle repose sur Qwen3.8 27B (base plus forte que Bonsai 1), améliore le raisonnement et la vision, supporte un contexte de 262K tokens et images multimodales
- Score agrégé de 83,9 sur benchmark (raisonnement, maths, code, instruction, vision, agents) : retain 98,2% vs Qwen3.8 complet, mais 1,8 points de moins vs baseline
- Déploiement : 143 tokens/s sur RTX 5090, 46,8 tokens/s sur M5 Max, 0,714 mWh/token sur RTX 4090 (40% plus efficace qu'un 8B FP32)
- Licence Apache 2.0, poids disponibles en GGUF, mais tournent uniquement via fork spécifique llama.cpp de PrismML (pas de compatibilité standard llama.cpp)
Dans les commentaires
Débat partagé : enthousiasme sur l'accessibilité matérielle et les benchmarks, scepticisme sur la clarté des comparaisons et les limites réelles sur tâches longues.
- Plusieurs commentateurs contestent la métrique « 9x plus petit » (linguistiquement inexact : c'est 1/9e ou 11%) et demandent des comparaisons directes avec d'autres quantifications basse-bit (Q2) du même modèle, absentes de la source.
- Données empiriques mixtes : un utilisateur rapporte 20–44 tokens/s sur M5 Pro (bien sous les 46,8 annoncés) avec problèmes de détection GPU ; un autre teste déjà le modèle et constate que les performances empiriques sur agents ne confirment pas entièrement le claim « near-lossless ».
- Friction matérielle : dépendance au fork PrismML de llama.cpp, incompatibilité avec l'écosystème standard, freine l'adoption. Plusieurs demandent des chiffres pour AMD/HIP ou comparaisons avec les quantizations Unsloth du même Qwen3.8.
- Tâches longues et agents : deux commentateurs note que même Bonsai 1 « s'effondre spectaculairement » au-delà de tâches courtes, suggérant que le 98,2% en benchmark agrégé ne traduit pas une équivalence fonctionnelle réelle sur problèmes complexes.
- Débat sur la moat : un commentateur soulève l'inquiétude stratégique : si compression ternaire + 27B accessible en consumer hardware peut approcher GPT-level, où réside le moat des labos propriétaires ? Réaction limitée.
Alternatives citées : Mentionnés en commentaires : quantizations Q2 et Q1 standards du même Qwen3.8 (cadre de comparaison demandé mais absent de l'article) ; Unsloth quantizations ; GLM-5.3-Flash (compression appliquée à un modèle plus gros) ; autres compresseurs ternaires non nommés.
Notre lecture
Résultat technique solide pour le déploiement local, mais la synthèse de PrismML lisse les aspérités. Le 98,2% en rétention agrégée masque des écarts plus visibles en vision (78,6 vs 81,6) et raisonnement (83,95 vs 86,66) ; les retours empiriques signalent des chutes réelles sur tâches d'agents multi-étapes. À tester plutôt que croire sur parole. Frein opérationnel majeur : l'obligation du fork propriétaire de llama.cpp complique l'intégration dans les pipelines existants. L'intérêt principal est pour qui a du GPU 16–24 GB et cherche un modèle 27B local sans infra cloud : coding assistants, analyse de documents privés, workflows d'agents simples. Pas d'action imédiate pour une DSI, sauf labs explorant quantification extrême ou déploiement sur nombre massif de petits appareils (edge).