Bonsai 2 vs Bonsai 27B : l'un d'eux peut être téléchargé, l'autre non.

La différence la plus concrète entre Bonsai 2 et Bonsai 27B n'a rien à voir avec les benchmarks. Le 17 octobre 2026, une entrée de la bibliothèque Ollama a été mise en ligne, couvrant toute la famille Bonsai 2 — Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B et Bonsai 2 27B — et il n'existe aucune entrée équivalente pour la première génération. Cherchez bonsai-27b, ternary-bonsai-27b ou tout autre nom de variante sur ce registre et vous obtenez un 404. Bonsai 27B, publié par Prism ML le 14 juillet 2026, doit être téléchargé depuis les dépôts Hugging Face du fournisseur et exécuté avec le fork llama.cpp de Prism ML. Bonsai 2 dispose d'une installation en une ligne.

Cette asymétrie constitue toute la dimension pratique du choix, et il est facile de passer à côté parce que les deux noms ressemblent à une même gamme de produits avec une simple montée de version. Ce sont deux générations, deux modèles de base, deux ensembles de conditionnements différents et — à compter de cette semaine — deux mécanismes de livraison différents. Ce qui suit présente ce qui a réellement changé entre eux, les cas où l’ancien l’emporte encore, et l’unique configuration où la réponse n’est ni l’un ni l’autre.

Ce que chacun est

Les deux sont des compressions ternaires d’un modèle Qwen à attention hybride. Aucune des deux n’est un modèle nouvellement entraîné — l’architecture, les poids et l’entraînement tenant compte de la quantification proviennent de la base Qwen, et ce que Prism ML apporte, c’est la représentation ternaire et les noyaux qui la consomment.

• Génération — Bonsai 2 (septembre 2026, prolongé en octobre 2026) vs Bonsai 27B (14 juillet 2026)

• Modèle de base à la taille 27B — Qwen3.8-27B vs Qwen3.6-27B

• Modèles de base à travers toute la famille — Qwen3.5-2B, -4B, -9B et Qwen3.8-27B sous Bonsai 2 ; un seul Qwen3.6-27B sous la première génération

• Tailles proposées — quatre (2B, 4B, 9B, 27B) contre une (27B)

• Deux points de fonctionnement à 27B — non, un seul : Bonsai 2 27B n’est proposé qu’en ternaire, tandis que Bonsai 27B était proposé à la fois en version ternaire et en version binaire

• Empreinte la plus réduite de la classe 27B — 5,95 Go en PTQ1_0 dans Bonsai 2, contre 3,9 Go dans la version 1-bit de la première génération

• Contexte — 262 144 jetons hérités du backbone Q​wen sur les deux

• Licence — Apache 2.0 pour les deux

• Livraison — les tags Ollama et Hugging Face pour Bonsai 2 ; Hugging Face plus le fork llama.cpp de Prism ML pour Bonsai 27B

La ligne qui décide de plus de déploiements que toutes les autres est la cinquième. Bonsai 27B était livré avec deux façons de dépenser de la mémoire : une version ternaire à environ 7,2 GB et une version binaire à 3,9 GB. Bonsai 2 27B n'en propose qu'une — une version ternaire à 5,95 GB en conditionnement dense-trit ou 7,21 GB en conditionnement 2-bit-slot — et il n'existe pas d'équivalent binaire dans cette génération. Si vous utilisiez la version 3,9 GB de la première génération en attendant un successeur équivalent, il n'y en a pas à 27B.

Ce que la génération a réellement acheté

Les chiffres de Prism ML, obtenus sur le propre banc d’essai de Prism ML, sans reproduction indépendante disponible : le Bonsai 27B ternaire de première génération affichait une moyenne en mode réflexion de 80,49 contre 85,07 pour sa référence Qwen3.6-27B FP16 — 94,6 % conservés sur 15 benchmarks. Bonsai 2 27B affiche 84,78 contre 86,32 pour Qwen3.8-27B FP16 — 98,2 % sur 14 benchmarks. En termes absolus, le modèle compressé a gagné environ 4,3 points sur l’échelle du fournisseur.

Deux mises en garde vont de pair, car le titre invite à une lecture plus nette que ne le permettent les données. Premièrement, les suites de benchmarks ne sont pas le même ensemble — 15 pour l’une, 14 pour l’autre — et la référence est passée de Qwen3.6-27B à Qwen3.8-27B, qui était lui-même un modèle plus puissant. La fiche modèle 27B du fournisseur elle-même rend le deuxième point explicite en recalculant la version précédente sur la nouvelle suite de 14 benchmarks pour une ligne comparable : sur cette base commune, la version précédente obtient 80,98 et Bonsai 2 27B obtient 84,78. Donc, la lecture honnête du changement est d’environ 3,8 points par rapport au même ensemble de benchmarks, une partie provenant du modèle de base et une autre de l’entraînement ternaire. Le pourcentage de rétention est passé de 94,6 % à 98,2 %, en partie parce que le dénominateur a changé.

Deuxièmement, la forme de la perte est plus informative que le résultat agrégé. Sur la même suite de 14 benchmarks, Bonsai 2 27B ne concède presque rien là où le raisonnement soutenu se manifeste : mathématiques 96,57 contre 97,06, code 89,42 contre 89,07 — au même niveau, légèrement devant — et suivi d’instructions 82,66 contre 81,25, devant. Connaissances et raisonnement tombe de 85,55 à 79,86, et vision de 71,36 à 66,19. C’est le profil que l’on attend d’une représentation à 1,72 bits par poids : le cœur du raisonnement survit, le rappel factuel et la compréhension des images encaissent le choc. Si votre charge de travail est du code et des mathématiques, la compression est presque gratuite. Si elle consiste en des questions-réponses de type récupération sur un corpus, ce n’est pas le cas.

Le slot de 3,9 Go, c’est là que ça devient intéressant.

Voici la partie que le cadrage en deux générations masque. L’artefact le plus distinctif de la première génération était le build binaire : un modèle 27B en 3,9 Go, conservant 89,5 % de FP16 rapportés par le fournisseur sur une moyenne de 76,11 sur 15 benchmarks. Bonsai 2 n’a pas de 27B binaire. Mais Bonsai 2 a bien un 9B à 1,997 Go en packing dense-trit et à 2,42 Go en packing à emplacements de 2 bits — environ la moitié de l’empreinte du 27B binaire, issu de la génération plus récente et du modèle de base plus récent.

Le 9B est-il meilleur que le 27B 1-bit ? Le fournisseur ne rapporte aucun chiffre qui répond à cette question, et vous ne devriez pas en construire un. Les deux modèles ont été évalués sur des suites différentes — 19 benchmarks couvrant six domaines de compétences pour les petits modèles Bonsai 2, 15 pour le 27B de première génération — par rapport à des bases de référence différentes, et les rapports de version des petits modèles présentent une rétention par catégorie face à leurs propres équivalents Qwen3.5 en pleine précision plutôt qu'une moyenne absolue unique comparable au 76,11 du 27B. Les comparaisons qui existent sont par benchmark et vont dans les deux sens. D'après les chiffres du fournisseur, le 9B obtient 71,81 sur BFCLv3 et 73,02 sur Tau2Bench, tandis que le 27B binaire a affiché 74,41 sur BFCL v3 — suffisamment proche pour que la différence entre les suites l'absorbe.

Ce qu’on peut dire sans exagérer est plus restreint, et toujours utile : la classe d’encombrement que le 27B binaire occupait seul a désormais un prétendant moins cher issu de la génération suivante, et les deux sont suffisamment proches pour que personne ne doive choisir entre eux à partir d’un tableau fournisseur. C’est un argument pour mesurer sur vos propres invites, pas pour faire confiance à un chiffre. C’est aussi le seul endroit, dans cette comparaison, où la réponse n’est véritablement aucun des deux modèles du titre.

Les faire tourner : les chiffres et le hic

Les chiffres de débit sont mesurés par les fournisseurs et n'ont pas été obtenus sur une même machine ; il faut donc les interpréter comme des ordres de grandeur plutôt que comme un classement.

• Bonsai 2 27B sur un Apple M5 Max — environ 47 tok/s sur la build pré-rotation antérieure, en attente d'une nouvelle mesure sur la stack actuelle

• Bonsai 2 27B sur un M5 Pro — 28,1 tok/s avec l’empaquetage en slots de 2 bits, à environ 27,5 W sur le rail GPU

• Bonsai 2 27B sur une RTX 5090 — 129,9 tok/s en packing à slots de 2 bits, 120,5 en packing dense en trits

• Bonsai 27B ternaire de première génération sur un M5 Max — 44,0 tok/s ; sur un H100, 98,0 tok/s, atteignant environ 131,8 avec son drafteur DSpark

• Bonsai 27B binaire de première génération sur un iPhone 17 Pro Max — environ 11 tok/s, limité thermiquement

Le hic, c'est l'empaquetage, et il joue de la même manière pour les deux générations. Aucune des deux générations n'a ses noyaux ternaires dans llama.cpp en amont. La première génération a besoin du fork Prism ML pour chaque fichier. Bonsai 2 livre trois empaquetages des mêmes poids, et llama.cpp en amont n'en exécute qu'un seul — Q2_0, dans les master récents — tout en rejetant le PTQ1_0, plus petit, et le PQ2_0, plus rapide, comme des types inconnus. Ainsi, l'empaquetage dense-trit qui se rapproche le plus du taux théorique de 1,72 bit par poids est aussi celui qui exige une compilation issue d'un fork.

Cela mérite qu’on s’y arrête, car cela explique la fiche Ollama. Les tags Ollama pour Bonsai 2 servent du Q2_0 : la couche modèle du tag 9B mesure 2,557 Go, soit octet pour octet la taille du fichier Q2_0 sur Hugging Face, et le plus petit pack PTQ1_0 est totalement absent du registre. Quelle que soit sa nature, cette fiche n’est pas une voie vers l’artefact le plus petit. On échange ici de la commodité contre de l’empreinte, et cet arbitrage est invisible si l’on ne lit pas les tailles de fichiers.

Accéder à l'un ou l'autre

Si vous êtes sur Ollama, la décision est déjà prise pour vous : Bonsai 2, quatre tailles, ollama pull bonsai-2:27b ou :9b, soit environ 8,3 Go et 3,2 Go sur disque, projecteur de vision inclus. Si vous avez besoin du packing dense-trit, des drafters de décodage spéculatif, ou de quoi que ce soit issu de la première génération, c'est un téléchargement Hugging Face et une compilation de fork, et le dépôt de démonstration du fournisseur est la référence testée pour cette voie.

Là où une couche de routage aide vraiment ici, c'est de l'autre côté de la question. Vous ne pouvez router vers aucun de ces deux modèles — ce sont des poids locaux, et OrcaRouter ne sert aujourd'hui aucune taille de Bonsai. Ce qu'OrcaRouter vous apporte, c'est la base de comparaison : une seule API devant plus de 200 modèles hébergés, à 0 % de marge, le prix catalogue du fournisseur répercuté tel quel, avec bascule automatique entre fournisseurs. La séquence la plus sensée pour la plupart des équipes consiste à établir sur un modèle hébergé ce dont une tâche a réellement besoin, puis à décider si un modèle local de 2 Go, 3,9 Go ou 6 Go franchit ce seuil — plutôt que de deviner à partir d'un pourcentage de rétention.

Lequel, concrètement ?

• Vous voulez la toute nouvelle génération ternaire à 27B et une installation en une seule commande — Bonsai 2 27B via Ollama, en acceptant l’empaquetage Q2_0 et la taille sur disque plus importante.

• Vous voulez les artefacts de classe 27B les plus petits possible, ou vous comptez sur le drafter DSpark — Bonsai 27B de première génération depuis Hugging Face, avec le build fork. Rien dans Bonsai 2 ne le remplace en 27B.

• Vous exécutiez la version binaire de 3,9 Go et vous avez besoin que cette empreinte tienne — ne partez pas du principe que Bonsai 2 a un successeur. Soit vous restez, soit vous mesurez Bonsai 2 9B face à vos propres prompts ; il fait la moitié de la taille et est d’une génération plus récent, et le fournisseur n’a pas publié de comparaison qui tranche.

• Vous avez besoin de quatre classes de taille à partir d'un seul runtime — Bonsai 2 est la seule génération à l'offrir.

Une chose à surveiller qui simplifierait tout cela : un tag ptq1_0 apparaissant dans la liste Ollama. Cela signifierait que les noyaux dense-trit ont atteint le moteur qu'Ollama livre, que l'exigence de fork disparaît pour le plus petit pack, et que le compromis entre commodité et empreinte cesse d'être un compromis.

Rien de tout cela n'est hypothétique : les défaillances documentées de l'IA et les incidents d'agents qui sous-tendent des versions comme celle-ci sont recueillis dans l'OrcaRouter AI Incident Archive, où chaque entrée est accompagnée de ses propres sources, de son niveau de gravité, de son degré de confiance et de son indicateur de contestation.