Ternary Bonsai 2 27B vs Bonsai 27B : deux mois, deux modèles de base, une variante manquante

Ternary Bonsai 2 27B est arrivé le 17 septembre 2026, deux mois après l'arrivée de Bonsai 27B le 14 juillet 2026, et la comparaison phare entre eux tient à une seule paire de chiffres : la première génération conservait environ 95 % de la moyenne des benchmarks de son modèle de base en pleine précision, et la seconde en conserve 98,2 %. Cela ressemble à une amélioration générationnelle simple, et c'est en grande partie le cas — mais les deux chiffres ne mesurent pas la même chose, car le modèle de base a changé sous eux. La version de juillet compressait Qwen3.6-27B. Celle de septembre compresse Qwen3.8-27B. Une partie du gain de qualité revient à la recette de compression et une autre au plus récent Qwen3.8-27B, et aucun chiffre publié ne sépare les deux.

Il existe une deuxième différence entre les générations qui a suscité bien moins d’attention et qui compte davantage pour un groupe spécifique d’utilisateurs : le premier Bonsai est sorti en deux variantes, le second en une seule. La version de 3,9 Go qui faisait tenir un modèle de classe 27B sur un iPhone 17 Pro n’a pas de successeur dans cette édition. Si cette empreinte est la raison pour laquelle Bonsai vous intéressait, la génération plus récente n’est pas une mise à niveau — c’est un produit différent qui ne couvre pas votre cas.

Ce que la première génération a réellement livré

Bonsai 27B a été publié le 14 juillet 2026 sous Apache 2.0 sous la forme de deux artefacts construits sur le même modèle de base, et leur séparation était tout l’enjeu de cette publication.

• Ternary Bonsai 27B — poids ternaires {−1, 0, +1} avec mise à l'échelle par groupe en FP16, 1,71 bit effectif par poids, une empreinte de 5,9 Go. La version orientée qualité, pensée pour un ordinateur portable du quotidien, avec des capacités complètes de raisonnement, d'appel d'outils et d'agent.

• 1-bit Bonsai 27B — poids binaires {−1, +1} avec la même mise à l'échelle par groupe, 1,125 bits effectifs par poids, une empreinte de 3,9 Go. La version orientée empreinte, dimensionnée pour tenir dans le budget mémoire d'un iPhone 17 Pro.

Tous deux embarquaient un contexte de 262 K tokens, tous deux conservaient une tour de vision compacte en 4 bits afin que le modèle reste multimodal, et tous deux prenaient en charge le décodage spéculatif avec un drafter DSpark. La présentation qu’en faisait Prism ML à l’époque était la suivante : la représentation en bits réduits fonctionnait de bout en bout — embeddings, attention, MLP et tête LM — sans échappatoires vers une précision supérieure, et la version 1 bit était le premier modèle de classe 27 B à tourner sur un téléphone, tout court. Le débit rapporté pour la variante 1 bit était d’environ 11 tokens par seconde sur un iPhone 17 Pro, 87 tok/s sur un Apple M5 Max et 163 tok/s sur une RTX 5090 ; la variante ternaire était annoncée à 58 tok/s sur le M5 Max et 134 tok/s sur la 5090.

Le coût en qualité a été présenté aux côtés de ces chiffres plutôt que passé sous silence. Sur une suite de 15 benchmarks en mode réflexion, la base en pleine précision a obtenu 85,0, la version ternaire 80,5 — environ 95 % — et la version 1 bit 76,1, environ 90 %. La dégradation s’est concentrée sur l’appel d’outils agentiques, qui est passé de 80,0 à 66,0 sur la version 1 bit, et sur la vision, qui est passée de 72,6 à 59,6. Les mathématiques et la programmation ont bien mieux résisté dans les deux variantes.

Ce que la deuxième génération a changé

Ternary Bonsai 2 27B conserve la recette et modifie les entrées. La représentation ternaire est toujours {−1, 0, +1} avec une échelle FP16 par groupe de 128 poids, désormais empaquetée à 1,76 bit par poids dans un fichier de 5,93 Go, avec un contexte de 262K et la même tour de vision séparée — 0,63 Go en 4 bits dans cette version, chargée uniquement lorsqu'une image arrive.

Deux choses sont véritablement nouvelles, et toutes deux sont présentées comme la raison pour laquelle le chiffre de rétention a évolué.

Le premier est la précision sélective. Contrairement à la version de juillet, qui ternarisait pratiquement tout, Bonsai 2 conserve 26 238 464 paramètres en pleine précision — 0,0976 % du modèle de langage, environ 52 Mo en bf16, concentrés dans le chemin d’état récurrent des couches d’attention linéaire, plus les poids de normalisation. C’est une petite concession en octets, et apparemment une grande en comportement.

Le second est une base de poids ayant subi une rotation. Les matrices de poids sont stockées après une rotation de Walsh–Hadamard par blocs de taille 1 024, la transformée correspondante étant appliquée aux activations à l’exécution, selon l’idée que répartir les valeurs aberrantes sur les coordonnées rend une approximation à trois niveaux moins dégradante. Cela n’occasionne aucun stockage supplémentaire, car la rotation est intégrée aux poids, mais elle se trouve bien sur le chemin de calcul.

Ensuite, il y a le changement qui n’est pas une technique du tout : le modèle de base. Qwen3.8-27B est une conception à attention hybride — environ 75 % d’attention linéaire, 25 % d’attention complète — alors que son prédécesseur ne l’était pas. Les scores par catégorie rapportés par Prism ML montrent ce que ce choix a apporté. Le suivi d’instructions se situe à 82,66 pour Bonsai 2, contre 74,53 pour Qwen3.6-27B, la base que la première génération a compressée. Le raisonnement et les connaissances arrivent à 83,95 contre 84,71 pour l’ancienne base, et le codage à 81,58 contre 82,57. Le nouveau modèle de base est nettement meilleur en suivi d’instructions et légèrement en retrait sur deux autres catégories, ce qui est exactement le genre de profil qui rend les pourcentages de rétention entre générations peu utiles à eux seuls.

Pourquoi les deux chiffres de rétention ne sont pas comparables

95 % et 98,2 % ressemblent à deux relevés sur une même échelle. Ce n’est pas le cas, pour trois raisons qu’il vaut la peine de bien distinguer avant de conclure que la recette s’est améliorée de 3,2 points.

• Les dénominateurs diffèrent. Les 95 % de la première génération ont été mesurés sur une suite de 15 benchmarks face à Qwen3.6-27B. Les 98,2 % de la seconde proviennent d’une suite de 20 benchmarks face à Qwen3.8-27B. Des suites différentes, des références différentes, des compositions de difficulté différentes.

• Les lignes de base ont évolué indépendamment. Une partie du gain en rétention vient du fait que le modèle compressé s'améliore en compression, et une autre partie vient du fait que le modèle de base change d'une manière qui se trouve être plus favorable aux poids ternaires. Rien de publié ne sépare ces contributions.

• La rétention est relative, de sorte qu’elle peut augmenter alors que la capacité absolue baisse dans une catégorie. Un modèle qui conserve 99 % d’un parent plus faible peut malgré tout rester derrière un modèle qui conserve 96 % d’un parent plus fort.

La comparaison absolue est plus informative que la relative, et sur cette base, le récit est plus clair. Le score agrégé de 83,9 de Bonsai 2 dépasse le 83,6 obtenu par Qwen3.6-27B en pleine précision sur l’ancienne suite — ce qui signifie que le successeur compressé devance désormais le modèle non compressé qu’il a remplacé une génération plus tôt. La version ternaire de première génération a obtenu 80,5 sur sa propre suite. Ces deux chiffres sont ceux de Prism ML, et les suites diffèrent, donc lisez l’ordre plutôt que les décimales.

La variante qui n'est pas revenue

C’est la partie de la comparaison qui change une décision d’achat plutôt qu’un graphique de benchmark.

Il n'existe pas de Bonsai 2 en 1 bit. La version de septembre propose une build ternaire, en deux conditionnements — PTQ1_0 à 1,76 bit par poids et 5,93 Go, et PQ2_0 à 2,16 bits par poids et 7,25 Go — plus un conteneur MLX pour Apple Silicon. Il n'existe pas de variante binaire de 3,9 Go, et aucune annonce en ce sens. Le chiffre de 3,9 Go pour téléphone qui apparaît dans les articles actuels renvoie toujours au modèle de juillet.

La conséquence pratique est directe. Si votre cible est un iPhone ou un iPad, ou tout appareil où un modèle de langage de 5,9 Go plus une tour de vision de 0,63 Go plus un budget de contexte ne rentrent pas, alors la version 1 bit de première génération reste la seule option de cette famille, et elle le restera jusqu’à ce qu’un Bonsai 2 1 bit existe. Mettre à niveau la voie ternaire ne met pas à niveau cette voie. Quiconque lit « Bonsai 2 est meilleur » et retélécharge sur un téléphone constatera que le fichier ne rentre pas.

Si vous êtes sur un ordinateur portable ou de bureau, le calcul est inverse : il n'y a aucune raison d'exécuter le build ternaire de juillet alors que celui de septembre est plus petit par unité de qualité, meilleur sur les benchmarks qui comptent, et embarque le même contexte de 262K.

Vitesse, où les générations sont vraiment difficiles à classer

Le débit est l'aspect de cette comparaison où la réponse honnête est que les chiffres publiés ne permettent pas un classement net, et il vaut la peine de le dire plutôt que de choisir la paire flatteuse.

Les mesures standardisées de la deuxième génération, à une taille de lot de 1 et tour de vision exclue, sont de 142,5 tok/s en décodage sur une RTX 5090 avec le packing PQ2_0, de 46,8 tok/s sur une Apple M5 Max, de 27,7 sur une M5 Pro et de 18,0 sur une M4 Pro. La première génération annonçait 134 tok/s sur une RTX 5090 et 58 tok/s sur une M5 Max pour sa version ternaire. Le chiffre de la 5090 évolue modestement dans la direction attendue. Celui de la M5 Max va dans l’autre sens — de 58 à 46,8 — ce à quoi ne devrait pas ressembler un saut générationnel de deux mois.

Deux réserves empêchent qu’on y voie un résultat. Les bases de mesure diffèrent d’une version à l’autre, et au moins un chiffre publié pour le M5 Max du modèle plus récent a été attribué à une build antérieure à l’optimisation de rotation. Mais cela vaut la peine de le signaler comme une question ouverte, car le mécanisme qui l’expliquerait est bien présent dans les notes de version : la base rotationnée place une transformation sur le chemin critique de chaque projection avec une taille de lot de 1, et le décodage sur Apple Silicon est le régime où cela nuit le plus. La technique qui apporte de la qualité peut coûter du débit de décodage, et sur du matériel à mémoire unifiée, ce compromis est le plus aigu.

Le conteneur MLX ajoute une complication supplémentaire pour les utilisateurs Apple. Il s'agit d'un format affine à 2 bits dont le bloc stocke à la fois une échelle et un biais pour chaque groupe de 128 poids, mais les poids ternaires n'ont besoin que de l'échelle ; le biais est donc un poids mort — le bloc coûte 36 octets par 128 poids au lieu de 34, et le taux compacté s'établit à 2,25 bits par poids, pour une taille de fichier mesurée de 8,005 Gio. C'est un conteneur différent qui transporte les mêmes valeurs, et c'est le pack que la configuration de démonstration télécharge par défaut.

Exécution de l'une ou l'autre génération

Les deux générations partagent une même contrainte opérationnelle à laquelle aucune version de ce modèle n’a échappé : ni l’une ni l’autre ne fonctionne sur llama.cpp standard. Les kernels ternaires pour cette architecture résident dans le fork propre à Prism ML, llama.cpp standard rejette les packings actuels comme inconnus et — pire — il chargera l’ancien format ternaire sans broncher et produira du charabia fluide, car il n’applique pas la rotation que les poids présupposent. La build MLX embarque des kernels Metal et CPU, mais aucune voie CUDA. Quelle que soit la génération que vous choisissez, la question du runtime trouve sa réponse dans la distribution propre à Prism ML ou dans un runtime ayant adopté ses kernels, pas dans l’écosystème ggml au sens large.

Là où OrcaRouter intervient dans une décision comme celle-ci, c'est un niveau au-dessus. Aucune des générations de Bonsai n'est hébergée ici — ce sont des téléchargements que vous exécutez sur votre propre matériel. L'utilité de la couche de routage réside dans la frontière : les requêtes auxquelles votre modèle local ne devrait pas répondre. Définissez la politique d'escalade une seule fois dans la configuration du routage plutôt que dans le code de l'application, afin qu'un palier servi localement transmette à un modèle hébergé les requêtes à long contexte, à forte composante visuelle ou autrement hors périmètre, au lieu de les faire échouer, et afin que le mécanisme de repli survive quelle que soit la génération de Bonsai que vous avez installée. Le palier local comme le palier hébergé se trouvent alors tous deux derrière une seule clé, et la politique reste centralisée en un seul endroit lorsque la prochaine génération de Bonsai arrivera et que les frontières entre paliers bougeront à nouveau.

Que faire de ceci

• Si vous exécutez la version ternaire de juillet sur un ordinateur portable ou de bureau — passez à Ternary Bonsai 2 27B. C’est un meilleur modèle pour une empreinte à peu près équivalente, et les scores par catégorie sur lesquels il l’emporte sont ceux qui comptent pour le travail agentique et le suivi d’instructions.

• Si vous exécutez le build 1 bit de juillet sur un téléphone — restez. Il n’y a pas de successeur, et le build ternaire de 5,93 Go n’est pas un remplacement direct pour un build de 3,9 Go.

• Si vous évaluez la famille pour la première fois — déterminez d’abord l’empreinte, puis la génération. La variante dont vous avez besoin détermine la version dans laquelle vous ferez votre achat, et cet ordre est l’inverse de celui habituellement utilisé pour décrire cette mise à niveau.

• Si vous faites votre choix à partir de benchmarks — traitez 95 % et 98,2 % comme deux mesures différentes plutôt que comme deux points sur une ligne, et considérez chaque chiffre dans les deux comme provenant du fournisseur lui-même jusqu’à ce qu’apparaisse une évaluation indépendante du modèle de septembre. C’est cette évaluation qu’il faut surveiller, car c’est la première qui pourra comparer les deux générations sur une base commune.