Ternary Bonsai 2 compresse un 27B sans trop rogner les performances

PrismML a publié Ternary Bonsai 2 27B, une version à poids ternaires de Qwen3.8 27B, le 18 septembre 2026 selon le dépôt GitHub cité. Le modèle pèse 5,93 Go en PTQ1_0, contre 53,80 Go en FP16, et vise les usages texte, image et agentiques. L’enjeu est simple : faire tourner un 27 milliards de paramètres sur du matériel plus courant, sans trop sacrifier la qualité. Ce genre de compression ne fait pas la une tous les jours, mais il compte pour le déploiement réel.

Un 27B réduit à la taille d’un fichier qu’on envoie encore par messagerie

Ternary Bonsai 2 27B conserve l’architecture de Qwen3.8 27B, avec 27,36 milliards de paramètres au total. PrismML indique que 26,2 millions de paramètres seulement, soit 0,0976 %, restent en précision supérieure pour la voie d’état récurrent et les normalisations. Le reste passe en ternaire, c’est-à-dire avec trois valeurs possibles : -1, 0 ou +1. En clair, le modèle devient beaucoup plus léger sans basculer dans la simple quantification classique.

La fiche technique décrit aussi une répartition hybride de l’attention, avec environ 75 % de couches en attention linéaire et 25 % en attention complète. Côté vision, le tower séparé pèse 0,63 Go en GGUF et n’est chargé qu’en cas d’entrée image. Le contexte annoncé monte à 262 000 jetons, ce qui le place dans la catégorie des modèles à mémoire longue, utile pour des documents volumineux ou des sessions d’agent prolongées.

Pourquoi PrismML mise sur le ternaire plutôt que sur la compression classique ?

Le pari repose sur une logique physique autant que mathématique. PrismML explique qu’un poids prend une valeur parmi trois, tandis qu’un groupe de 128 poids partage une échelle FP16. Selon son calcul, cela amène le format à 1,71 bit par poids en comptant les échelles, et 1,72 avec les tenseurs de plus haute précision. La version PTQ1_0 dense les trits à 1,76 bit par poids, alors que PQ2_0 les stocke sur 2 bits, pour 7,25 Go, avec un déballage plus simple.

Le papier mentionne aussi une rotation de Hadamard par blocs de 1 024 avant l’assignation ternaire. C’est une transformation linéaire qui redistribue l’information pour rendre la compression plus stable. PrismML ne publie pas sa méthode exacte d’assignation des valeurs ternaires, ce qui laisse une petite zone d’ombre dans un ensemble par ailleurs très chiffré. Les maths adorent les détails, les fiches de produit un peu moins.

Des scores proches du modèle source, mais pas partout

Sur 20 benchmarks, PrismML annonce 83,9 de moyenne pour Ternary Bonsai 2 27B, contre 85,4 pour Qwen3.8 27B en FP16, soit 98,2 % de retention. Le modèle fait même mieux en instruction following, avec 82,66 contre 81,25 pour le modèle de référence. En mathématiques, il reste à 96,57 contre 97,06, donc très proche. Sur la connaissance et le raisonnement, il marque 83,95 contre 86,66.

Les écarts se creusent davantage sur les tâches longues ou très agentiques. PrismML donne 77,57 en agentic and tool calling, contre 79,74 pour Qwen3.8 27B, et 78,59 en vision contre 81,64. Plus bas encore, Terminal-Bench 2.1 tombe à 52,8 contre 69,7, et SWE-bench Verified à 60,8 contre 80,6. Ces scores ne sont pas inclus dans la moyenne des 20 benchmarks, mais ils rappellent un point connu : compresser un modèle, ce n’est pas seulement faire fondre sa taille, c’est aussi choisir où il perd un peu de tenue.

Sur le papier, ça tourne sur bien plus de machines

PrismML affirme que le modèle peut fonctionner sur un portable de 16 Go de RAM ou sur un GPU unique de 24 Go, à condition d’utiliser son fork de llama.cpp ou son runtime MLX. Les performances publiées sont mesurées en décodage, avec une taille de lot de 1, sur des kernels maison. Une RTX 5090 atteint 142,5 tokens par seconde, une RTX 4090 monte à 96,7 avec PTQ1_0, et une Apple M5 Max atteint 46,8 tokens par seconde. C’est assez pour rendre le modèle exploitable localement, sans transformer le bureau en centrale électrique.

Le choix du packing compte aussi selon la plateforme. PTQ1_0 serait plus rapide sur les cartes Ada et sur la L4, tandis que PQ2_0 prend l’avantage sur Blackwell, Hopper, Ampere et Apple silicon, ainsi qu’au moment du traitement du prompt. PrismML dit aussi avoir observé une efficacité énergétique supérieure de 40 % à celle d’un modèle 8B en pleine précision. À ce stade, ces résultats restent ceux de l’éditeur et n’ont pas été reproduits de manière indépendante.

Un gain utile pour les équipes qui veulent servir localement

Le message adressé aux développeurs est assez clair : oui, un modèle de 27B peut entrer dans des contraintes matérielles plus modestes, mais avec des compromis bien identifiés. Les usages de chat et de vision semblent mieux préservés que les tâches longues de type agent, où la stabilité et l’outil comptent autant que la simple réponse. Pour les équipes qui cherchent à héberger localement un assistant avancé, c’est un argument de poids. Pour celles qui visent surtout des workflows de production, la question devient moins “est-ce que ça tient ?” que “où accepte-t-on de perdre un peu de précision ?”.

PrismML recommande son propre environnement pour exécuter les fichiers GGUF, car le llama.cpp standard refuse les types PTQ1_0 et PQ2_0. Un dépôt de démonstration fournit aussi un démarrage pour le chat, la vision et les outils, avec une interface locale. Le modèle s’inscrit donc dans une tendance très concrète du marché de l’IA générative : réduire la facture mémoire et ouvrir la porte à du déploiement plus près du poste de travail ou du serveur d’appoint.