Ternary Bonsai 2 27B vs Qwen3.8-27B IQ2_XXS GGUF : moins de bits, de meilleurs scores

Ternary Bonsai 2 27B est plus petit que la version GGUF IQ2_XXS de Qwen3.8-27B et, d'après les chiffres publiés à son sujet, également meilleur — ce qui ne devrait pas être possible si tout ce qui les séparait était un budget de bits. La version Bonsai transporte 1,76 bit par poids dans un fichier de 5,93 Go. La quantification conventionnelle en 2 bits du même modèle de base transporte environ 2,2 bits par poids dans un fichier d'environ 7,3 Go. Prism ML, qui a annoncé la version ternaire le 17 septembre 2026, rapporte une moyenne sur 20 benchmarks de 83,9 pour son modèle, contre 75,2 pour le point de comparaison IQ2_XXS — un écart de 8,7 points en faveur du modèle qui utilise moins de bits.

Cette inversion est toute l’histoire, et ce n’est pas un tour de passe-passe. Les deux fichiers sont produits par des processus différents à des étapes différentes de la vie du modèle, et la différence entre ces processus vaut plus que la différence de largeur de bits. C’est aussi la comparaison où le conseil populaire — « prenez juste une quantification 2 bits, elles sont très bien maintenant » — se heurte à son contre-exemple le plus clair, et où le contre-exemple s’appuie sur une mesure indépendante plutôt que sur la parole d’un fournisseur.

Le paradoxe est le mécanisme

IQ2_XXS est un format de quantification après entraînement. Le modèle est entraîné jusqu'à convergence en pleine précision, puis, ensuite, ses poids sont arrondis vers une représentation en bits faibles choisie par une procédure d'ajustement. Le modèle n'a jamais la possibilité de s'adapter ; il est mesuré après coup et approximé. La famille i-quant améliore les anciens k-quants en utilisant une matrice d'importance — une passe de calibration qui décide quels poids méritent une plus grande part de la précision disponible — mais l'ordre fondamental des opérations reste inchangé. Entraîner, puis compresser.

Bonsai inverse cet ordre. La description que Prism ML donne de sa propre méthode est qu'elle a entièrement abandonné la quantification après entraînement et imposé la contrainte ternaire pendant l'entraînement : la passe avant calcule avec des poids restreints à {−1, 0, +1}, tandis que la passe arrière transporte toujours des gradients en pleine précision. Le modèle passe son entraînement à apprendre des représentations qui survivent à la contrainte, plutôt que de voir la contrainte imposée à des représentations qui ne l'avaient jamais attendue. L'algorithme est décrit comme de la propriété intellectuelle exclusive, mais sa forme sera familière à quiconque a lu les travaux de la lignée BitNet.

Deux raffinements viennent s'ajouter par-dessus, et tous deux sont visibles dans l'arithmétique. Le premier est la précision sélective : 26,2 millions de paramètres — environ 0,098 % du modèle, environ 52 Mo en bf16, principalement le chemin d'état récurrent des couches d'attention linéaire ainsi que les poids de normalisation — sont conservés en pleine précision plutôt que ternarisés. Le second est une rotation par blocs. Chaque matrice de poids est transformée par une rotation de Walsh–Hadamard avec une taille de bloc de 1 024 avant que les valeurs ternaires ne soient choisies, ce qui répartit les valeurs aberrantes sur les coordonnées et rend une approximation à trois niveaux moins destructrice. La rotation est intégrée aux poids stockés, de sorte qu'elle ne coûte aucun octet supplémentaire ; la transformation correspondante est quant à elle appliquée aux activations à l'exécution.

Ce dernier détail a une conséquence que vous rencontrez dès la première tentative d’exécuter la chose, et c’est le véritable coût de l’approche.

De quel IQ2_XXS parlez-vous, et quel score obtient-il réellement ?

Avant de comparer la qualité, une correction que la plupart des analyses passent sous silence : « IQ2_XXS » n’est pas un artefact unique. Il s’agit d’un type de quantification de llama.cpp, et ce même type appliqué par différentes chaînes d’outils au même modèle de base produit des fichiers qui diffèrent sensiblement en taille et substantiellement en qualité.

La preuve publique la plus claire est une comparaison indépendante publiée le 15 août 2026 par un utilisateur cherchant à savoir si un Qwen3.8-27B sous les 2 bits valait vraiment la peine d'être construit. Le test est une mesure de divergence KL sur wikitext-2, 100 segments en contexte de 512, face à une référence Q8_0 construite localement avec une perplexité de 6,7500, chaque candidat utilisant la même matrice d'importance, le même corpus, la même ligne de base et le même build llama.cpp, en une seule séance. Les résultats :

• unsloth UD-IQ2_XXS — 8,39 Gio, perplexité 7,6528, KLD moyen 0,146, KLD médian 0,076, accord top-1 82,98 %

• bartowski IQ2_XXS — 8,75 GiB, perplexité 8,5352, KLD moyen 0,301, KLD médian 0,162, concordance top-1 76,53 %

La variante dynamique est de 0,36 Gio plus petite que la variante statique et environ 2,1x meilleure sur le KLD moyen — à 1,13x la perplexité de référence. Deux fichiers portant la même étiquette, séparés par un facteur de deux sur la métrique qui mesure à quel point la distribution de sortie a dérivé. Le même test a trouvé que chaque candidat à moins de 2 bits était moins bon que les deux options IQ2 publiées, ce qui explique pourquoi le plancher pratique de ce modèle de base se situe à IQ2 plutôt qu'en dessous.

Cela compte pour la comparaison, car cela change ce que désigne « la build 7,3 GB IQ2_XXS ». Le chiffre de Prism ML provient de sa propre quantification du modèle de base à 2,2 bits par poids. Une build dynamique unsloth de la même famille mesure 8,39 GiB. Une build bartowski mesure 8,75 GiB. L’écart de taille entre Bonsai et « IQ2_XXS » se situe donc entre 1,4x et 1,5x selon la build dont vous parlez — plus grand que le facteur de 1,23x que le titre laisse entendre, et tout cela avant même que la comparaison de qualité ne commence.

Où le build post-entraînement échoue, et pourquoi il est facile de passer à côté

L’écart global de 8,7 points est la manière la moins informative de formuler la différence, car la dégradation dans la version IQ2_XXS n’est pas uniforme. Elle est sélective, et le schéma est à l’opposé de ce que la plupart des gens prédiraient.

• MMLU-Redux — la version post-entraînement tient remarquablement bien, dans la fourchette des 85-89

• GPQA Diamond — environ 65,5, contre 85,76 pour le build ternaire

• AIME26 — dans la plage de 57,5 à 78,6 selon la version, contre 95,83 pour la version ternaire

• LiveCodeBench — dans la plage de 56,4 à 70,05, contre 90,07 pour le build ternaire

Les chiffres exacts d’IQ2 varient entre les suites de Prism ML et les mesures de la communauté, et les plages ci-dessus couvrent les deux, mais la forme reste cohérente d’une source à l’autre : la connaissance superficielle survit, et tout ce qui exige une chaîne de raisonnement soutenue se dégrade fortement. C’est précisément le mode de défaillance qu’un test occasionnel ne révélera pas. Demandez à une version 2 bits de résumer un document ou de répondre à une question factuelle, et elle se comporte comme un modèle bien plus grand. Demandez-lui de suivre une dérivation en plusieurs étapes ou de produire du code non trivial, et l’effondrement est soudain plutôt que progressif. C’est pourquoi « ça semblait correct quand je l’ai essayé » n’est pas une preuve concernant un modèle quantifié — c’est une preuve concernant les prompts que vous avez essayés par hasard.

La version ternaire ne montre pas cet effondrement sur les mêmes benchmarks. Prism ML rapporte AIME26 à 95,83 contre 94,58 pour sa base en pleine précision, et LiveCodeBench à 90,07 contre 90,05 — pratiquement au même niveau, et c'est l'affirmation la plus utile de cette publication, car elle indique que la contrainte imposée pendant l'entraînement a permis d'obtenir ce que celle appliquée après l'entraînement fait perdre.

L'argument contraire, qui est réel et que le tableau de qualité ne capture pas

Tout ce qui précède plaide en faveur de la version ternaire pour la qualité par octet. Il existe une dimension sur laquelle le GGUF conventionnel l’emporte haut la main, et ce n’est pas un détail : il tourne sur les logiciels que vous avez déjà.

Le build IQ2_XXS de Qwen3.8-27B est un artefact standard de llama.cpp. Il se charge dans llama.cpp, Ollama, LM Studio, Jan, et tout autre outil qui se lie à ggml, sur toutes les plateformes prises en charge par ggml, sans fork requis ni noyaux spéciaux. Sa matrice d’importance peut être reconstruite ou remplacée. Il se comporte comme tout autre modèle quantifié que vous avez sur votre disque.

Ternary Bonsai 2 27B ne le fait pas. Les noyaux ternaires pour l’attention hybride de cette architecture résident dans le fork llama.cpp propre à Prism ML. Le llama.cpp standard rejette PTQ1_0 et PQ2_0 comme types non reconnus — et ne sait pas quoi faire de la base tournée que supposent ces packs. La version MLX pour Apple Silicon dispose de noyaux Metal et CPU, mais d’aucun chemin CUDA ; sur une machine NVIDIA, elle retombe donc sur une passe avant CPU qui peut prendre plusieurs minutes. Prism ML mentionne bien une intégration avec plusieurs runtimes, mais le point de fond demeure : l’utilisabilité de ce modèle est limitée par le fait que le runtime de votre choix a été informé de son existence — ou non.

C'est le compromis honnête. Vous choisissez entre une version 1,4 fois plus grosse, mesurablement moins bonne exactement sur les tâches pour lesquelles vous voulez très probablement un modèle 27B, et exécutable partout — et une version plus petite et meilleure, sur un écosystème qui se résume actuellement au fork d'un seul labo, plus les runtimes qui l'ont adopté.

Ce qu'il faut pour faire fonctionner l'un ou l'autre

Le calcul de mémoire est plus serré que ne le suggèrent les tailles de fichiers, car les fichiers ne sont pas la seule chose présente dans la VRAM.

• Version IQ2_XXS — 8,39 à 8,75 Gio de poids, laissant environ 7,5 Go libres sur une carte de 16 Go pour le contexte et les modèles de draft. Le test indépendant ci-dessus précise spécifiquement qu’une version de 8,39 Gio accueille déjà un modèle de draft de 2,1 Go à ses côtés.

• Ternary Bonsai 2 27B — 5,93 Go pour le modèle de langage PTQ1_0, plus 0,63 Go pour la tour de vision si vous utilisez des images, plus le contexte. Le packing PQ2_0 de Prism ML coûte 7,25 Go et constitue l'option la plus rapide sur du matériel limité par le débit d'instructions plutôt que par la bande passante.

En termes de vitesse, les chiffres ternaires rapportés sont de 142,5 tok/s en décodage sur une RTX 5090 et de 46,8 tok/s sur un Apple M5 Max ; les rapports tiers sur la version IQ2 sont plus rares, avec une mesure Vulkan sur deux cartes Radeon d’environ 3,8 tok/s en génération, bien que ce chiffre en dise plus sur ce backend particulier que sur la quantification. Considérez les chiffres de débit des deux côtés comme fortement dépendants du matériel.

Là où OrcaRouter est pertinent, et là où il ne l'est pas

Aucun de ces deux fichiers n'est servi par un routeur. Ce sont des artefacts locaux, et la présentation honnête est qu'OrcaRouter n'héberge ni l'un ni l'autre — il s'agit d'une comparaison de ce qui tourne sur votre propre matériel. Ce qui se trouve de notre côté, c'est le modèle dont ils sont tous deux dérivés. Qwen3.8-27B en pleine précision est disponible via l'infrastructure propre d'OrcaRouter à 0,33 $ par million de tokens en entrée et 2,40 $ par million de tokens en sortie, avec le contexte natif de 262K du modèle et son contrôle de l'effort de raisonnement faible/moyen/élevé intacts.

Cela donne une configuration hybride sur laquelle il vaut la peine d'être concret. Exécutez le build compressé en local pour les tâches pour lesquelles il est performant, et acheminez la requête occasionnelle qui nécessite une précision complète vers le modèle de base hébergé, via la même clé — pas de second contrat avec un fournisseur, aucune modification de code, car les deux côtés parlent la même API. Si le build local s'avère inadapté à une charge de travail, la requête qui échoue peut être basculée automatiquement plutôt que d'être renvoyée comme une erreur, ce qui est un moyen moins coûteux de découvrir qu'une quantification est inadaptée que de le découvrir en production.

La version courte

• En termes de qualité publiée par octet, le build ternaire l'emporte nettement, et cette victoire se concentre sur le raisonnement et le code — les catégories où le build post-entraînement se dégrade le plus.

• En matière de portabilité, la version IQ2_XXS l'emporte tout aussi nettement. Des runtimes standard partout, aucun fork, aucun kernel spécial, aucun mode de défaillance silencieux produisant des résultats inutilisables.

• La comparaison n’est pas « 1,76 bits contre 2,2 bits ». Elle est « une représentation choisie pendant l’entraînement par rapport à une représentation ajustée après coup », et la différence de 0,44 bit est une erreur d’arrondi à côté de cela.

• Chaque chiffre de qualité concernant la version ternaire dans cet article provient des propres mesures de Prism ML, sur une suite que Prism ML a choisie. Les résultats KLD pour les builds IQ2 sont indépendants, en une seule exécution, et spécifiques à un seul modèle de base et à un seul jeu de test ; ils constituent les éléments de preuve tiers les plus solides de cette comparaison et ne disent rien sur Bonsai.

L'écart se comblera aussi dans l'autre sens, et probablement bientôt. Si les kernels ternaires sont intégrés en amont dans llama.cpp, la seule objection sérieuse à Bonsai s'évapore et le choix devient évident. D'ici là, le build IQ2_XXS conserve un véritable avantage qui n'a rien à voir avec sa qualité.

Si vous décidez cette semaine, le test qui tranche prend un après-midi : prenez vingt prompts issus de votre propre charge de travail qui exigent plus d’une étape de raisonnement, exécutez les deux versions, puis évaluez les réponses à l’aveugle. Les tableaux publiés vous indiquent où regarder. Ils ne peuvent pas vous dire si votre travail se situe là.