Bonsai 27B : le modèle 27B de la famille Bonsai, expliqué

Bonsai 27B est le modèle à 27 milliards de paramètres de la famille Bonsai de PrismML, et c'est celui que les gens désignent lorsqu'ils tapent « bonsai 27b » — mais le nom seul ne vous y mènera pas, car trois choses différentes répondent à quelque chose d'approchant. Bonsai 27B est une reconstruction à faible nombre de bits de Qwen3.6-27B, datée du 14 juillet 2026 selon l'annonce du fournisseur lui-même, et il est livré en deux packs du même modèle : Bonsai 27B 1-bit, qui stocke des poids binaires {−1, +1} dans environ 3,9 Go, et Ternary Bonsai 27B, qui stocke des poids ternaires {−1, 0, +1} à 1,71 bits effectifs par poids — 5,9 Go dans le chiffre phare du fournisseur, 7,165 Go pour le pack tel qu'il est réellement livré. Ce n'est pas Ternary Bonsai 2 27B, la deuxième génération nommée séparément, construite sur Qwen3.8-27B, et ce n'est pas le modèle vision-langage de 2 milliards de paramètres que PrismML a construit pour les lunettes connectées Snapdragon AR1 Gen 1. Les deux packs de Bonsai 27B embarquent un contexte de 262 000 tokens, une tour de vision compacte en 4 bits et une licence Apache 2.0. Le modèle est Bonsai 27B ; la décision qui suit est de savoir lequel de ses deux packs correspond à votre budget mémoire.

Cette page est la référence pour ce modèle. Il ne s'agit pas d'une annonce : Bonsai 27B est disponible depuis juillet 2026, et les questions auxquelles il vaut la peine de répondre à son sujet sont celles avec lesquelles un lecteur arrive — ce qu'il est exactement, ce que son nom permet de distinguer, et ce que son exécution coûte réellement.

Lequel est le 27B ?

La confusion est bien réelle ici, et il vaut la peine de la résoudre avant toute autre chose, car une mauvaise supposition vous oriente vers un modèle à 2 milliards de paramètres ou vers la mauvaise génération du bon modèle.

• Bonsai — le nom de la famille, et celui que le fournisseur lui donne. À lui seul, il n'identifie rien que vous puissiez télécharger. PrismML a livré Bonsai 1.7B, Bonsai 4B, Bonsai 8B, Bonsai 27B et Bonsai Image, ainsi que le modèle pour lunettes de 2 milliards de paramètres, et une version antérieure d'avril 2026 appelée Ternary Bonsai pour la gamme plus petite. Une recherche sur le mot seul tombe au hasard dans cet ensemble.

• Bonsai 27B — le sujet de cette page. Première génération de la gamme 27B, dérivée de Qwen3.6-27B, datée du 14 juillet 2026. Lorsqu'une page mentionne « Bonsai 27B » sans autre qualificatif et sans « 2 », c'est le modèle dont il s'agit, et c'est le nom à utiliser.

• Ternary Bonsai 27B — pas un modèle différent. Il s'agit du pack orienté qualité de Bonsai 27B : le même modèle 27B, la même architecture et la même base, avec des poids ternaires au lieu de poids binaires. Le dépôt s'appelle Ternary-Bonsai-27B-gguf, et sa fiche modèle désigne Qwen3.6-27B comme base, exactement comme la fiche binaire. « Ternary » désigne ici un format de poids, pas une version.

• Ternary Bonsai 2 27B — un modèle véritablement à part. La deuxième génération de la gamme 27B, basée sur Qwen3.8-27B et annoncée le 17 septembre 2026, avec une répartition des paramètres différente et une promesse de qualité différente. Le « 2 » porte à lui seul toute la distinction.

• 1-bit Bonsai 2B — un autre membre de la famille à une échelle différente : un modèle vision-langage de 2 milliards de paramètres pour du matériel de classe lunettes, et non un modèle 27B à quelque précision que ce soit.

Donc, si vous êtes venu ici pour déterminer lequel de ces éléments est le modèle 27B, la réponse est que les troisième et quatrième lignes ci-dessus sont le même modèle en deux formats de poids, et la cinquième est celui qui ne l’est pas. En pratique : appelez-le Bonsai 27B, et ajoutez le pack quand cela compte.

La spécification, issue de la fiche du modèle

Chaque chiffre de cette section provient des fiches modèle publiées par PrismML pour les deux packs, et il s'agit de la déclaration du fournisseur lui-même au sujet de son propre modèle. Lorsqu'un chiffre est une affirmation plutôt qu'une mesure, il est étiqueté comme tel.

• Paramètres — environ 27,3 B au total, et le « 27B » désigne l'ensemble. La répartition vaut la peine d'être connue, car elle explique le comportement mémoire : environ 24,8 B se trouvent dans le backbone linguistique, répartis sur 64 blocs, environ 2,5 B dans l'embedding et la tête LM, et environ 0,46 B dans une tour de vision à 27 blocs. La représentation à faible nombre de bits est appliquée de bout en bout — les embeddings, l'attention, les MLP et la tête LM — sans aucune échappatoire vers une précision supérieure, où que ce soit dans le réseau linguistique.

• Contexte — un total de 262 000 tokens, sans variante à contexte long ni version à contexte réduit. Le coût de cette fenêtre est maîtrisé plutôt que payé d'emblée : le backbone est hybride, donc seules 16 de ses 64 couches conservent un cache d'attention complet, et ce cache est stocké sous une forme 4 bits quasi sans perte. À la fenêtre complète de 262K, c'est le cache compressé qui maintient le modèle sous environ 9,4 GB sur le pack binaire et 12,8 GB sur le ternaire.

• Modalité — texte et images, les deux packs. La tour de vision est livrée sous une forme compacte en 4 bits (0,63 Go), accompagnée d'une copie BF16 (0,93 Go). C'est aussi sur la vision que la compression coûte le plus, comme expliqué ci-dessous.

• Format et taille des poids — Bonsai 27B à 1 bit utilise des poids binaires {−1, +1} avec une mise à l’échelle par groupes en FP16, empaquetés au format GGUF Q1_0_g128 à un taux réel de 1,125 bit effectif par poids ; le fichier livré fait 3,803 GB, et la fiche arrondit l’empreinte déployée à environ 3,9 GB. Bonsai 27B ternaire utilise des poids ternaires {−1, 0, +1} avec la même mise à l’échelle par groupes ; une valeur ternaire porte log₂3 ≈ 1,585 bit d’information, donc le plancher de la représentation est d’environ 1,71 bit par poids, ce qui donne 5,9 GB dans l’idéal. Le paquet ternaire publié est plus volumineux que cet idéal, car les noyaux actuels stockent chaque valeur ternaire dans un emplacement de 2 bits — 2,125 bits par poids déployés — et le fichier livré fait 7,165 GB. PrismML indique les deux chiffres plutôt que seulement celui qui flatte, et l’écart entre eux tient à une limitation des noyaux plutôt qu’à un choix de modélisation.

• Licence — Apache 2.0 sur les deux packs, comme indiqué sur les deux dépôts et dans l'annonce de l'éditeur. Il s'agit d'une licence permissive sans restriction de domaine d'utilisation, ce qui compte davantage à cette taille de poids que dans la plupart des cas.

• Modèle de base — Qwen3.6-27B dans les deux cas. Il s'agit d'une recompression du modèle de quelqu'un d'autre plutôt que d'un modèle entraîné à partir de zéro, et la conséquence est que le plafond de capacités de Bonsai 27B et sa cadence de mise à jour suivent tous deux la lignée 27B en amont plutôt que celle de PrismML.

La relation ternaire, énoncée une fois

Les deux packs sont un seul et même modèle, et le résumé honnête est que le ternaire achète la qualité et le binaire achète l’empreinte, avec un écart entre eux plus petit que ne le suggère la différence de taille de 3,9 Go contre 7,2 Go.

Dans la suite de 15 benchmarks en mode réflexion propre à PrismML, la référence FP16 Qwen3.6-27B obtient 85,07. Ternary Bonsai 27B obtient 80,49 — soit 94,6 % de rétention, que le fournisseur arrondit à environ 95 %. 1-bit Bonsai 27B obtient 76,11 — 89,5 %, arrondi à environ 90 %. Ainsi, le pack orienté qualité récupère environ la moitié de l'écart entre le pack binaire et la précision complète, tout en coûtant environ 3,3 Go de plus, et c'est le pack binaire qui tient sur un téléphone de 12 Go. La même suite montre qu'une build 4 bits Q4_K_XL de la même référence atteint 84,99, soit 99,9 % de rétention, en 17,6 Go — c'est la comparaison qui explique pourquoi l'un ou l'autre pack à faible nombre de bits existe tout court, puisqu'elle les surpasse en qualité et perd sur tout appareil qui dispose de moins de 18 Go à consacrer à un modèle.

Là où le pack binaire cède du terrain est inégal, et la répartition par catégorie est la partie utile. Par rapport à la référence FP16, il chute de 95,33 à 91,66 en mathématiques et de 88,74 à 81,88 en codage, mais de 78,47 à 65,74 en suivi d’instructions, de 80,00 à 66,03 sur le travail agentique et d’appel d’outils, et de 72,61 à 59,57 en vision. Si votre charge de travail relève de l’arithmétique ou de la complétion de code, 3,9 Go ne coûte presque rien. S’il s’agit d’agents d’appel d’outils ou de compréhension d’images, c’est là que la compression se paie réellement.

La fiche de modèle publie aussi un chiffre dérivé qu'elle appelle densité d'intelligence — score agrégé par gigaoctet, normalisé de sorte qu'un score parfait tende vers l'infini. Selon cette mesure, 1-bit Bonsai 27B atteint 0,530 et Ternary Bonsai 27B 0,400, contre 0,199 pour une version 2 bits IQ2_XXS de la même base, 0,155 pour une version 4 bits Q4_K_XL, et 0,051 pour le modèle FP16. Le chiffre intéressant dans cette liste est la première comparaison : le paquet binaire bat la version 2 bits conventionnelle en qualité agrégée avec moins de la moitié de l'empreinte, ce qui résume en une ligne toute la thèse de la famille.

Le face-à-face complet entre les deux packs, et l’origine des chiffres de chacun, est exposé dans la page Bonsai vs Bonsai 27B de ce blog, aux côtés du modèle à 2 milliards de paramètres qui partage le nom de la famille.

Une question qui se pose avec ce modèle mérite une réponse factuelle et rien de plus. Les packs sont des encodages à faible nombre de bits du même modèle sous-jacent plutôt qu'une variante réentraînée, et les dépôts ne publient à côté d'eux aucun checkpoint spécifiquement ajusté ou non censuré — le seul artefact en pleine précision proposé est une conversion FP16 non empaquetée des mêmes poids, publiée pour que vous puissiez comparer un pack compressé à sa propre référence avec des outils standards.

Poids et licence, depuis les dépôts

Les poids de Bonsai 27B sont publiés sur Hugging Face sous l'organisation prism-ml, et la liste des fichiers est l'élément le plus concret de cette publication. Le dépôt du pack binaire contient le modèle lui-même à 3,803 GB, un GGUF FP16 du même modèle à 53,808 GB pour comparaison, un draft de décodage spéculatif DSpark à 1,787 GB en 4 bits et 7,292 GB en BF16, ainsi que des tours de vision à 0,931 GB et 0,629 GB. Le dépôt ternaire contient son propre pack de 7,165 GB ainsi qu'un second empaquetage à 7,585 GB, qui est en group-64 plutôt qu'en group-128 et compatible avec l'amont plutôt qu'optimal, ainsi que les mêmes fichiers de draft et de vision. Les deux dépôts sont sous Apache 2.0 et tous deux indiquent Qwen3.6-27B comme base.

Deux choses découlent de cette liste. La première, c’est que 53,808 Go contre 3,803 Go correspond au rapport de 14,2x que la fiche modèle met en avant, et c’est vérifiable plutôt qu’affirmé — le fichier en pleine précision est juste là. La seconde, c’est que la version publiée est plus lourde que le modèle : si l’on inclut aussi le drafter et la tour de vision, ce qu’exige la voie multimodale, on ajoute environ 2,4 Go à un modèle de 3,9 Go. Le chiffre phare de 3,9 Go correspond aux poids linguistiques, et non au déploiement.

Les téléchargements sont le seul domaine où le pack orienté qualité arrive en tête : en octobre 2026, le dépôt GGUF ternaire a dépassé les 590 000 téléchargements, contre un peu plus de 400 000 pour le pack binaire, tandis que les conteneurs MLX des deux se situent au-dessus du million chacun. La répartition suggère que l’essentiel de ce modèle est exécuté sur du matériel Apple plutôt que sur des serveurs, et que les personnes qui le téléchargent privilégient les cinq points de rétention supplémentaires plutôt que le fichier le plus petit possible — ce pour quoi le fournisseur a à peu près conçu ces deux packs.

En train de l'exécuter.

Ce que vous pouvez obtenir aujourd'hui, ce sont quatre types d'artefacts par pack, et celui que vous voulez est déterminé par votre environnement d'exécution plutôt que par la qualité.

• GGUF pour llama.cpp — la voie principale, et celle pour laquelle les noyaux à bas bit ont été écrits. Les deux packs sont des builds llama.cpp pour CUDA, Metal et CPU, mais les noyaux 1 bit et ternaires résident dans le fork propre à PrismML plutôt que dans l'amont, donc un llama.cpp standard ne les chargera pas correctement pour l'instant. Le conditionnement ternaire group-64 existe précisément pour les cas où vous avez besoin de la compatibilité amont et acceptez de prendre 7.585 GB au lieu de 7.165 GB pour l'obtenir.

• MLX pour Apple silicon — conteneurs distincts livrés, à 5,129 Go pour le pack binaire et 8,491 Go pour le ternaire. Notez que le conteneur binaire MLX est plus volumineux que le pack binaire GGUF, ce qui tient à une différence de surcharge de conteneur plutôt qu'à un modèle différent.

• AWQ 4 bits pour les frameworks serveur — une version 4 bits de chaque modèle pour les frameworks de service qui attendent un checkpoint AWQ, en neuf shards totalisant 18,70 Go, y compris une recette multi-GPU. Ce n'est pas un artefact en précision réduite ; c'est le même modèle à une précision qui a du sens sur une baie, et cela sacrifie la raison même d'exister du modèle.

• Safetensors FP16 non compressés — le modèle complet d'environ 54 Go au format Hugging Face standard, publié explicitement pour les frameworks qui ne prennent pas encore en charge nativement les poids 1 bit. Le fournisseur indique que cet artefact sera retiré une fois que les noyaux bas bit seront intégrés en amont.

Le débit de décodage mesuré sur le pack binaire, d'après le tableau de la fiche modèle elle-même, est de 66,4 tokens par seconde sur un M5 Max, 44,2 sur un M5 Pro, 26,0 sur un M4 Pro et 104,8 sur un H100, avec un prefill de 874, 421, 133 et 2 755 tokens par seconde, respectivement. La page d'annonce cite des pics plus élevés — jusqu'à 87 tokens par seconde sur un M5 Max et 163 sur un RTX 5090 — qui correspondent à la configuration la plus favorable du fournisseur plutôt qu'à celle du tableau. Considérez les deux ensembles comme des conditions de mesure différentes, et non comme une contradiction, et considérez-les tous les deux comme déclarés par le fournisseur. La mémoire de pointe, toujours d'après la fiche, est de 5,2 Go pour un contexte de 4K, 5,6 Go à 10K et 11,6 Go à 100K sur le pack binaire, et de 8,4, 8,7 et 14,7 Go sur le pack ternaire — avec la réserve que ces chiffres sont antérieurs au cache KV 4 bits, ce qui ramène la fenêtre complète de 262K sous les dix gigaoctets.

Le drafter DSpark est facultatif et mérite d'être compris avant de l'activer, car il ne change rien aux sorties : c'est un transformer parallèle par blocs à six couches, conditionné sur des états cachés prélevés sur cinq couches cibles régulièrement espacées ; il ajoute environ 0,5 Go à la précision de service, et il vérifie ses propositions auprès du modèle cible plutôt que d'échantillonner de son côté. C'est pourquoi l'éditeur peut annoncer un gain de vitesse de 1,37x sous CUDA sans toucher aux chiffres de qualité. Il n'est pas activé par défaut sur Apple silicon.

Là où le modèle local arrive au bout de sa route, voilà la question d'ingénierie intéressante, et c'est une question de routage plutôt qu'une question de modèle. Un modèle de 3,9 Go sur un ordinateur portable traite ce qui tient dans son contexte ; tout le reste doit bien aller quelque part, et ce quelque part est un modèle hébergé derrière une API. OrcaRouter est cette couche — un seul point d'accès pour plus de 200 modèles hébergés avec 0 % de marge sur les prix catalogue des fournisseurs, un basculement automatique entre fournisseurs, et la règle d'escalade d'un palier local vers un palier hébergé exprimée sous forme de configuration plutôt qu'assemblée à la main. C'est la couche au-dessus d'un modèle local, pas un remplacement.

L'indice de comparaison

Bonsai 27B s'inscrit dans une famille où chaque voisin répond à une question différente, et voici les pages qui traitent chacune d'elles — aucune n'y est réargumentée.

• Bonsai vs Bonsai 27B — le modèle pour lunettes de 2 milliards de paramètres face à celui-ci : seize fois plus de paramètres et deux cent cinquante-six fois plus de contexte, et pourquoi le nom de famille n'indique rien sur ce que vous téléchargez. La page est ici un article de blog, et non un modèle hébergé, une distinction qu'il vaut mieux garder en tête dans cette famille.

• Bonsai 27B face à Qwen3.8-27B — le duel entre ce modèle et la base plus récente qu'il n'utilise pas. Une page dédiée de ce lot contient cette comparaison, et comme les deux modèles répondent à des noms similaires et se situent à une génération d'écart, il vaut la peine de la lire pour elle-même plutôt que comme un prolongement de cette spécification.

• Bonsai vs Ternary Bonsai 2 27B — le saut générationnel, et le fait que les deux versions publient leur qualité selon deux référentiels différents : la conservation d'une base de référence dans un cas, une affirmation comparative dans l'autre.

• Ternary Bonsai 2 27B — la deuxième génération à part entière, sur Qwen3.8-27B, pour les lecteurs qui ont décidé qu'ils veulent le modèle plus récent plutôt que celui-ci.

Qu'est-ce qui n'est pas réglé ?

Tous les chiffres de qualité figurant sur cette page sont ceux de PrismML, mesurés sur la propre suite de 15 benchmarks de PrismML, et personne en dehors de l'entreprise n'en a publié de reproduction. C'est la plus grande lacune dans ce que l'on sait de Bonsai 27B : les affirmations sur la compression sont inhabituellement précises et inhabituellement vérifiables, et elles restent non vérifiées par un tiers. Le fournisseur précise par ailleurs explicitement que le codage agentique — les flux de travail à long horizon, multi-fichiers, exécuter-et-réparer — n'est pas une cible forte de cette version et qu'une variante optimisée pour cela est la prochaine chose sur la feuille de route, ce qui est cohérent avec les pertes en appel d'outils et en suivi d'instructions dans la répartition par catégorie ci-dessus. Tant qu'il n'existe pas d'évaluation indépendante, le chiffre de rétention comme le classement de densité doivent être lus comme la position du fournisseur plutôt que comme un résultat établi.

Ce qui est établi est plus petit et plus utile : les poids existent, les tailles peuvent être vérifiées par rapport à la liste des fichiers, la licence est Apache 2.0, et les deux packs diffèrent d'environ 3,3 Go en échange d'environ cinq points de qualité conservée. Cela suffit pour choisir entre eux. Lequel des deux vous convient dépend de si votre charge de travail ressemble davantage à de l'arithmétique ou davantage à de l'appel d'outils, et les chiffres par catégorie ci-dessus constituent la meilleure preuve disponible pour cette décision aujourd'hui.