Bonsai 2 est arrivé sur Ollama avant que quiconque n'annonce qu'il allait arriver.

Quelque part au cœur de la nuit du 17 octobre 2026, Ollama a commencé à servir Bonsai 2 — une entrée de bibliothèque à neuf tags couvrant Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B et Bonsai 2 27B, chacun en deux packagings plus un alias par défaut. Prism ML n'en a rien dit. Il n'y a aucun article sur la page d'actualités du fournisseur, aucune ligne dans l'annonce du 15 octobre des petits modèles — cette publication cite llama.cpp et MLX comme moteurs d'exécution et une console hébergée comme démo, et ne mentionne jamais Ollama. L'entrée existe simplement, avec les neuf tags portant tous le même horodatage de quelques heures, ce qui ressemble à un push récent et non à un déploiement progressif.

Donc la répartition honnête est la suivante. Ce que l’on peut savoir dès maintenant, à partir du registre et des fichiers : les tags, leurs noms, leurs tailles exactes en octets, leurs empreintes de contenu, et — parce qu’Ollama distribue des GGUF — l’architecture et les chaînes de métadonnées à l’intérieur des poids eux-mêmes. Non confirmé : qui les a empaquetés, pourquoi l’annonce du fournisseur omet la plateforme, si les noyaux ternaires font partie du moteur d’Ollama en amont ou sont intégrés comme code tiers, et si l’un des chiffres du fournisseur survit au passage. Ce sont des questions distinctes, et cet article les maintient séparées.

Qu'y a-t-il réellement sur l'étagère

Neuf tags, quatre tailles, trois conditionnements des mêmes poids. La page de la bibliothèque d’Ollama répertorie un alias par défaut par taille et une -q2_0 variante par taille :

• bonsai-2:latest — 3,2 Go, correspond au 9B (empreinte c8b5462f8688)

• bonsai-2:2b et bonsai-2:2b-q2_0 — 911 Mo, même digest de2ccb4e7328

• bonsai-2:4b et bonsai-2:4b-q2_0 — 1,6 Go, même empreinte 93edd652c932

• bonsai-2:9b et bonsai-2:9b-q2_0 — 3,2 Go, même empreinte c8b5462f8688

• bonsai-2:27b et bonsai-2:27b-q2_0 — 8,3 Go, même empreinte f3c4f4208659

Le nommage en fait plus qu'il n'y paraît. Deux tags par taille partageant un digest ne sont pas un doublon — c'est une indication du packing qu'Ollama a choisi. Récupérez le manifeste pour bonsai-2:9b et la couche du modèle fait 2,557 Go. C'est le fichier de Ternary Bonsai 2 9B, Q2_0, mesuré sur Hugging Face à 2,557 Go à l'octet près. Le PQ2_0 pack fait 2,417 Go et le PTQ1_0 pack — le plus petit à 1,997 Go — n'est pas ici du tout.

Ce choix a une conséquence qu'il vaut la peine d'énoncer clairement, car c'est le genre de chose qui finit en fil de support. Sur la fiche de modèle du fournisseur, llama.cpp en amont exécute exactement l'un des trois empaquetages : Q2_0, « recent master, which includes the Hadamard activation runtime ». Il rejette PQ2_0 et PTQ1_0 comme types inconnus, car ceux-ci nécessitent le fork Prism ML de llama.cpp. Ollama fait tourner son propre moteur. Q2_0 est l'empaquetage qu'un consommateur GGUF standard peut plausiblement charger — et Q2_0 est précisément l'empaquetage qu'Ollama a livré. Qu'Ollama ait développé ses propres noyaux ternaires ou qu'il passe par une build vendored, le registre ne vous le dit pas. Ce qu'il vous dit, en revanche, c'est qu'ils n'ont pas livré le fichier qui ne peut pas se charger.

Les métadonnées GGUF vous en apprennent plus que la page

La page d'Ollama rapporte quatre informations par tag : une taille en octets, un badge de contexte « 256K », un type d'entrée texte-plus-image, et un horodatage relatif. Tout le reste se trouve dans le fichier. Lire l'en-tête GGUF de chaque couche du modèle donne ce qui suit, et cela vaut la peine d'être lu pour une raison précise : c'est la seule partie de cette histoire qui ne soit pas une affirmation marketing de quelqu'un.

• general.architecture — qwen35 sur les quatre tailles

• general.name — Ternary-Bonsai-2-2B, -4B, -9B sur les trois petits ; la couche 27B rapporte la chaîne générique Hf avec general.basename = folded

• general.file_type — 41 sur les quatre, avec general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, correspondant aux noms des tags

• Nombres de tenseurs — 320 pour le 2B, 426 pour le 4B, 427 pour le 9B, 851 pour le 27B

La chaîne d'architecture est la plus intéressante. qwen35 est le backbone hybride à attention de Qwen3.5, et il confirme depuis l'artefact lui-même ce que les fiches modèles disent en prose : les trois petits sont Qwen3.5-2B, -4B et -9B, avec l'architecture inchangée et les poids remplacés. Il révèle aussi une couture de nommage que les propres notes de version du fournisseur passent sous silence. L'article du 15 octobre dit que les nouveaux modèles sont « basés sur Qwen3.5 ». Le 27B repose sur une base entièrement différente — Qwen3.8-27B, annoncé le 17 septembre. Quatre tailles, un nom de famille, deux modèles de base. Tout ce que vous lisez sur le comportement de « Bonsai 2 » qui a été mesuré sur le 27B ne se transpose pas automatiquement au 9B, et l'en-tête GGUF est l'endroit où vous pouvez voir pourquoi.

Les métadonnées du 27B sont aussi visiblement moins ordonnées que les autres : general.name = Hf, un general.basename = folded, un general.version = v5, et une clé d’échantillonnage supplémentaire que les trois petits ne comportent pas. C’est à cela que ressemble la sortie intermédiaire d’un pipeline de conversion lorsqu’elle est poussée sans passe de renommage finale. Ce n’est pas un défaut — les tenseurs sont les tenseurs — mais c’est une empreinte, et cela suggère que le tag 27B est passé par un chemin différent de celui des trois petits.

Ce que les chiffres d'Ollama ne signifient pas

C'est ici que la plupart des analyses d'une fiche de bibliothèque font fausse route, et il vaut donc la peine de prendre le temps. Les tailles en octets affichées sur la page d'Ollama sont des tailles de conteneur, et pour chacune d'elles, elles sont supérieures au fichier de modèle qu'elles renferment. L'étiquette 2B indique 911 Mo contre une couche de modèle de 0,547 Go et un projecteur de vision de 0,365 Go. L'étiquette 27B indique 8,3 Go contre une couche de modèle de 7,626 Go et un projecteur de 0,629 Go. Ajoutez les blobs de licence et de paramètres et le calcul tombe juste : Ollama cite l'artefact téléchargé dans son intégralité, tour de vision comprise.

Cela signifie que les 3,2 Go indiqués sur la page Ollama pour le 9B ne sont pas comparables au chiffre « 2 Go » du fournisseur pour le même modèle, et l'écart n'est pas une divergence à signaler — il s'agit de deux mesures différentes de deux choses différentes. Les 0,43 Go / 0,95 Go / 2 Go de Prism ML ne concernent que les modèles de langage. La tour de vision est déchargée et n'est chargée que lorsqu'une image arrive réellement, donc un déploiement uniquement textuel ne paie jamais ce coût, mais un ollama pull, si. Si vous dimensionnez un appareil d'après les chiffres du fournisseur, puis effectuez un pull depuis Ollama, vous serez de 0,5 à 1 Go au-dessus du budget avant même d'exécuter quoi que ce soit.

La même prudence s'applique au badge « 256K ». Le contexte sous-jacent est de 262 144 jetons, hérité du socle Qwen3.5 — 24 couches d'attention linéaire et 8 couches d'attention complète sur le 9B — et le badge d'Ollama l'arrondit à la baisse pour l'affichage. Le contexte est réel et il est hérité, ce n'est pas quelque chose qu'Ollama a ajouté. Ce qui n'est pas indiqué nulle part sur la page, c'est la quantité de mémoire que coûte un contexte long, et sur un modèle à attention hybride doté d'un cache d'attention complète sur un sous-ensemble de couches, ce n'est pas un petit nombre. Rien sur la page d'Ollama ne vous dit si 262K tient réellement là où vous comptez l'exécuter.

Qui a empaqueté ceci, et est-ce que cela importe ?

Sans réponse, et il faudrait le signaler comme sans réponse plutôt que de le deviner. Trois possibilités : Prism ML l'a poussé, Ollama l'a récupéré depuis les dépôts GGUF publics du fournisseur dans le cadre de son propre travail de catalogue, ou un tiers l'a fait. Le registre ne peut pas vous dire lequel.

Ce qui peut être vérifié, c'est la provenance de l'artefact, et elle concorde. La description du modèle d'Ollama elle-même indique « Bonsai 2 de Prism ML est une famille de modèles de vision conçus pour des poids ternaires (−1, 0 ou +1) : environ la moitié de la taille des modèles 4 bits standard, avec une qualité proche de la précision complète » et renvoie vers l'organisation Hugging Face du fournisseur, le livre blanc Bonsai 2 27B et Apache 2.0. Le blob de licence intégré dans chacun des quatre manifestes de taille est le texte d'Apache 2.0 mot pour mot. Le blob de paramètres pour les 2B, 4B et 9B se lit {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — qui correspond à la recette d'échantillonnage en mode réflexion recommandée par le fournisseur, tirée des fiches de modèle, avec min_p omis exactement comme la fiche du 27B indique que les fichiers GGUF l'omettent. Ce n'est pas une supposition faite par quelqu'un ; c'est une conversion qui a lu la fiche.

Ce qui est rassurant, et ne vous apprend toujours rien sur ce qui détermine réellement votre expérience : la présence ou non des noyaux ternaires dans le moteur que vous exécutez. La position honnête est qu’une opération pull réussie prouve que le fichier est un GGUF bien formé, et rien de plus. Vérifiez sur votre propre matériel avant de vous appuyer dessus.

Les affirmations du fournisseur, et ce qui a été vérifié

Chaque chiffre de qualité associé à cette famille provient de Prism ML, sur le propre harnais de Prism ML, et aucun n’est reproduit indépendamment. C’est normal à ce stade, et il faut le dire explicitement plutôt que de le sous-entendre. La publication du 15 octobre rapporte 19 benchmarks répartis sur six domaines de compétences pour les petits modèles, avec une rétention par rapport aux références Qwen3.5 en pleine précision :

• 2B — agentique 95,5 %, mathématiques 107,8 %, suivi d'instructions 121,5 %, codage 115,0 %, connaissances 82,9 %, vision 89,0 %

• 4B — 90,0 % / 99,3 % / 106,0 % / 100,7 % / 90,9 % / 91,3 %

• 9B — 92,4 % / 98,2 % / 100,0 % / 100,1 % / 93,0 % / 92,5 %

Plusieurs d'entre eux dépassent 100 %, ce qui n'est ni une faute de frappe ni un artefact d'arrondi — cela signifie que le modèle ternaire a obtenu un meilleur score que le modèle en pleine précision dont il est dérivé, dans cette catégorie. Le suivi d'instructions, à 121,5 % pour le 2B, est l'exemple le plus flagrant. À traiter avec la suspicion qui s'impose : qu'un modèle compressé dépasse sa propre référence sur un benchmark choisi par le fournisseur en dit au moins autant sur l'entraînement et le harnais que sur la représentation, et les scores par catégorie des petits modèles sont bien plus bruités que ceux du 27B. Les chiffres du 27B sont plus prudents et plus crédibles dans leur profil — 84,78 contre 86,32 pour FP16, une rétention de 98,2 % sur 14 benchmarks en mode réflexion, avec les mathématiques à 96,57 contre 97,06 et le niveau de codage à 89,42 contre 89,07, et la perte concentrée dans les connaissances/raisonnement et la vision. Là où une famille perd des capacités sous une représentation à 1,7 bit, c'est le profil que l'on prédirait.

La seule affirmation, dans l'article sur les petits modèles, qui n'est pas un benchmark est celle qu'il faut prendre le plus au sérieux : le modèle 9B « utilise environ 40 % de tokens en moins sur les tâches standard de suivi d'instructions et de mathématiques du quotidien ». C'est une affirmation sur la verbosité, non sur la capacité, et c'est le genre de chose que l'on peut vérifier en un après-midi sur ses propres prompts. Elle interagit aussi avec un avertissement figurant sur les fiches de modèle du fournisseur lui-même — le mode réflexion peut consommer plus de 3 000 tokens sur une question triviale, alors fixez au moins 8 192 tokens en sortie, et n'utilisez pas le décodage glouton avec la réflexion activée, car le modèle peut se retrouver bloqué à raisonner. Un modèle qui est 40 % moins verbeux et qui a pourtant besoin d'un budget de 8 192 tokens vous dit qu'il est verbeux à un endroit précis.

Où cela vous laisse

Si vous utilisez déjà Ollama et que vous vouliez essayer un modèle de classe 27B sur un ordinateur portable sans GPU de datacenter, les quatre tags sont le chemin le plus court qui existe actuellement : un seul pull, pas de fork, pas de compilation de noyau. Si vous avez besoin du packing qui est réellement le plus petit, ou des drafters de décodage spéculatif que le fournisseur livre pour les 4B et 9B, le catalogue Ollama ne les propose pas — c'est un téléchargement Hugging Face et le build llama.cpp de Prism ML, et c'est le cas depuis le 15 octobre.

L'autre chose à savoir, c'est que le local n'est pas la seule façon de consommer un modèle à faible précision, et ce n'est pas toujours la bonne. OrcaRouter place une seule API devant plus de 200 modèles hébergés avec 0 % de marge — le prix catalogue du fournisseur est répercuté tel quel —, ainsi qu'un basculement automatique entre fournisseurs, afin que vous puissiez évaluer un modèle sur une charge de travail réelle avant de décider s'il mérite une place sur votre ordinateur portable. Aucune des tailles de Bonsai 2 n'est aujourd'hui servie via OrcaRouter, et cet article ne prétend pas le contraire : la famille est un téléchargement que vous exécutez vous-même, et cela restera le cas jusqu'à ce que l'éditeur publie un point de terminaison. Ce que la couche de routage vous apporte, c'est l'autre moitié de la décision — les modèles hébergés auxquels vous le comparerez, derrière une seule clé, avec la fusion de modèles et le DSL de routage disponibles quand un seul modèle ne suffit pas.

Points à surveiller, par ordre d'impact sur la situation : une balise Ollama obtenant un ptq1_0 frère, ce qui signifierait que les kernels dense-trit ont été intégrés en amont ; un billet d'un fournisseur reconnaissant la plateforme, ce qui répondrait à la question de la provenance ; et tout benchmark indépendant du 9B ou du 27B, la seule chose qui ferait sortir les chiffres de rétention de la colonne des données rapportées par le fournisseur. Jusqu'à ce que l'un de ces éléments se concrétise, la fiche n'est qu'un mécanisme de livraison, pas un nouveau modèle — et le modèle qu'elle livre est public depuis le 15 octobre.

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.