Bonsai 2 対 Bonsai 27B：一方はプルできるが、もう一方はできない

最も具体的な違いは、Bonsai 2とBonsai 27Bの間には、ベンチマークは一切関係ありません。2026年10月17日、Ollama ライブラリに Bonsai 2 ファミリー全体をカバーするエントリが公開されました — Ternary Bonsai 2 2B、Ternary Bonsai 2 4B、Ternary Bonsai 2 9B、およびBonsai 2 27B — そして初代に対応するエントリはありません。確認するには bonsai-27b、ternary-bonsai-27b、あるいはそのレジストリ上の任意のバリアント名を試すと 404 が返ります。Bonsai 27B、2026年7月14日に Prism ML がリリースしたもので、ベンダーの Hugging Face リポジトリからダウンロードし、Prism ML の llama.cpp フォークで実行する必要があります。Bonsai 2 では 1 行でインストールできます。

その非対称性こそが、この選択の実用的な全体像であり、見落としやすい。なぜなら、2つの名前はバージョンアップを伴う1つの製品ラインのように見えるからだ。両者は2つの世代、2つのベースモデル、2組の異なるパッキングであり、そして——今週時点では——2つの異なる配送メカニズムでもある。以下では、両者の間で実際に何が変わったのか、旧モデルが依然として勝る点、そして答えがどちらでもない唯一の構成について述べる。

それぞれが何か

どちらも Q​wen ハイブリッドアテンションモデルの三値圧縮です。どちらも新たに学習されたモデルではありません — アーキテクチャ、重み、量子化対応トレーニングは Q​wen ベースに由来し、Prism ML が提供するのは三値表現と、それを利用するカーネルです。

• 世代 — Bonsai 2（2026年9月、2026年10月に延長）対 Bonsai 27B（2026年7月14日）

• 27Bサイズのベースモデル — Qwen3.8-27B 対 Qwen3.6-27B

• ファミリー全体のベースモデル — Bonsai 2 における Qwen3.5-2B、-4B、-9B、および Qwen3.8-27B。第1世代における単一の Qwen3.6-27B

• 提供サイズ — 4種類（2B、4B、9B、27B）対 1種類（27B）

• 27Bでの動作点は2つ——いや、1つだ。Bonsai 2 27Bは三値のみを提供し、一方Bonsai 27Bは三値ビルドと二値ビルドの両方を提供していた

• 27Bクラス最小のフットプリント — Bonsai 2のPTQ1_0では5.95 GB、第1世代の1ビットビルドでは3.9 GB

• コンテキスト — 両方でQwenバックボーンから継承された262,144トークン

• ライセンス — 両方とも Apache 2.0

• 提供 — Bonsai 2 は Ollama タグと Hugging Face、Bonsai 27B は Hugging Face に加えて Prism ML の llama.cpp フォーク

他のどの行よりも多くのデプロイを左右するのは、5番目の行です。Bonsai 27Bはメモリの消費方法を2通り提供していました。約7.2 GBの三値ビルドと、3.9 GBの二値ビルドです。Bonsai 2 27Bが提供するのは1通りです — dense-tritパッキングで5.95 GB、または2-bit-slotパッキングで7.21 GBの三値ビルド — そしてこの世代には、対応する二値版はありません。第1世代の3.9 GBビルドを使っていて、同等の後継を期待していたなら、27Bにはそれはありません。

その世代が実際に買ったもの

Prism ML 自身の数値であり、Prism ML 自身のハーネスで測定され、独立した再現は得られていない。第一世代の三値 Bonsai 27B は、Qwen3.6-27B FP16 の 85.07 に対して思考モード平均 80.49 を報告した——15 のベンチマーク全体で 94.6% を維持。Bonsai 2 27B は、Qwen3.8-27B FP16 の 86.32 に対して 84.78 を報告——14 のベンチマーク全体で 98.2%。絶対値で言えば、圧縮モデルはベンダーの尺度で約 4.3 ポイント向上した。

2つの注意点は同時に述べるべきだ。見出しは、データが裏付ける以上にすっきりした解釈を誘うからだ。第一に、ベンチマークスイートは同じセットではない——一方は15、もう一方は14——そしてベースラインはQwen3.6-27BからQwen3.8-27Bへと移り、それ自体がより強いモデルだった。ベンダー自身の27Bモデルカードは、前回リリースを新しい14ベンチマークスイートで再計算し、同一条件の行を示すことで、第二の点を明示している。その共通の土台では、前回リリースは80.98、Bonsai 2 27Bは84.78を記録する。したがって、この変化を正直に読めば、同じベンチマークセットに対しておよそ3.8ポイントであり、その一部はベースモデルに、一部は三値トレーニングに由来する。保持率は94.6%から98.2%へ上昇したが、それは分母が動いたことも一因である。

第二に、損失の形は集計値よりも情報量が多い。同じ14ベンチマークスイート上で、Bonsai 2 27Bは持続的推論が発揮される領域ではほとんど何も犠牲にしていない。数学は97.06に対して96.57、コーディングは89.07に対して89.42——同水準、わずかに上回る——そして指示追従は81.25に対して82.66で上回っている。知識と推論は85.55から79.86へ低下し、視覚は71.36から66.19へ低下する。これは重みあたり1.72ビット表現から予想されるプロファイルだ。推論の中核は生き残り、事実の想起と画像理解が打撃を受ける。ワークロードがコードと数学なら、この圧縮はほぼ無料だ。コーパスに対する検索型の質問応答なら、そうではない。

3.9 GBのスロットが、ここから面白くなるところです

ここが、2世代という枠組みが隠している部分だ。第1世代の最も特徴的な成果物はバイナリビルドだった。3.9 GBの27Bモデルで、15ベンチマーク平均76.11において、ベンダー報告でFP16の89.5%を保持していた。Bonsai 2にはバイナリ27Bはない。しかしBonsai 2には、dense-tritパッキングで1.997 GB、2-bit-slotパッキングで2.42 GBの9Bがあり、バイナリ27Bのほぼ半分のフットプリントで、より新しい世代とより新しいベースモデルによるものだ。

9Bは1ビットの27Bより優れているのか？ベンダーはそれに答える数値を報告しておらず、こちらでそれをでっち上げるべきではない。両モデルは異なるスイートで評価されている——小型のBonsai 2モデルでは6つのスキル領域にわたる19のベンチマーク、初世代の27Bでは15のベンチマーク——しかも異なるベースラインに対する評価であり、小型モデルのリリースレポートは、27Bの76.11と比較可能な単一の絶対平均ではなく、自身のフル精度のQwen3.5対応モデルに対するカテゴリ保持率を報告している。存在する比較はベンチマーク単位であり、両方向を指し示している。ベンダーの数値では、9BはBFCLv3で71.81、Tau2Benchで73.02を記録する一方、バイナリの27BはBFCL v3で74.41を記録した——その差はスイートの違いに飲み込まれてしまうほど小さい。

誇張せずに言えることは、より限定的だが依然として役に立つ： binary 27B がかつて単独で占めていたフットプリントクラスに、今や次世代からのより安価な参入者が現れ、両者はベンダーの比較表からどちらかを選ぶべきではないほど近接している。 それは、数字を信頼するのではなく、自分のプロンプトで測定すべきケースだ。また、この比較の中で、答えが本当にタイトルにある2つのモデルのどちらでもない唯一の箇所でもある。

それらを実行する：数字と落とし穴

スループットの数値はベンダーが測定したもので、共通のマシン上で取得されたものではない。そのため、順位付けとしてではなく桁の目安として読んでほしい。

• Apple M5 Max 上の Bonsai 2 27B — 以前の pre-rotation ビルドでは約 47 tok/s、現在のスタックでの再測定は保留中

• M5 Pro 上の Bonsai 2 27B — 2-bit-slot パッキングで 28.1 tok/s、GPU レールで約 27.5 W

• RTX 5090上でのBonsai 2 27B — 2ビットスロットパッキングで129.9 tok/s、高密度トライトパッキングで120.5

• 第一世代の三値Bonsai 27Bは、M5 Max上で44.0 tok/s、H100では98.0 tok/s、そのDSparkドラフターを使うと約131.8まで上昇

• iPhone 17 Pro Max 上の第一世代のバイナリ Bonsai 27B — 約11 tok/s、熱制限あり

問題はパッケージングにあり、それは両方の世代に同じ形で影響する。どちらの世代の三値カーネルも上流のllama.cppには入っていない。第1世代はすべてのファイルについてPrism MLフォークを必要とする。Bonsai 2は同じ重みを3つのパッキングで提供しており、上流のllama.cppが実行できるのはそのうちちょうど1つ──最近のmasterではQ2_0──だけで、より小さいPTQ1_0とより高速なPQ2_0は未知の型として拒否する。つまり、理論上の重みあたり1.72ビットに最も近づくdense-tritパックこそ、フォーク版ビルドを必要とするパックでもある。

これはじっくり考えてみる価値がある。なぜなら、それがOllamaのリスティングを説明しているからだ。Bonsai 2のOllamaタグはQ2_0を配信している。9Bタグのモデル層は2.557 GBで、Hugging Face上のQ2_0ファイルサイズとバイト単位で一致しており、最小のPTQ1_0パックはレジストリにまったく存在しない。あのリスティングが何であれ、最小の成果物への経路ではない。ここでは利便性とフットプリントがトレードオフされており、そのトレードはファイルサイズを読まない限り見えない。

どちらか一方にたどり着くこと

Ollamaを使っているなら、答えはもう決まっています。Bonsai 2、4つのサイズ、ollama pull bonsai-2:27bまたは:9b、ビジョンプロジェクターを含めたディスク上のサイズはおよそ8.3 GBと3.2 GBです。dense-tritパッキング、投機的デコーディング用のドラフター、あるいは第1世代の何かが必要なら、それはHugging Faceからのダウンロードとフォークビルドになります。その道筋については、ベンダーのデモリポジトリがテスト済みのリファレンスです。

ルーティングレイヤーが本当に役立つのは、この問いの反対側です。これらのどちらかへルーティングすることはできません。これらはローカルの重みであり、OrcaRouter は現時点でいかなる Bonsai サイズも提供していないからです。OrcaRouter が与えてくれるのは比較の基準線です。0% のマークアップで 200 以上のホスト型モデルの前面に立つ単一の APIであり、プロバイダーの定価をそのまま透過させ、プロバイダー間の自動フェイルオーバーを備えています。ほとんどのチームにとって理にかなった順序は、まずタスクが実際に何を必要とするかをホスト型モデル上で確立し、その後で 2 GB、3.9 GB、6 GB のローカルモデルがその基準をクリアするかどうかを判断することです。保持率のパーセンテージから推測するのではなく。

具体的にはどれですか？

• 27Bで最新の三値世代と、コマンド1つでのインストールを求めるなら — Ollama経由のBonsai 2 27Bで、Q2_0パッキングとより大きなディスク上サイズを受け入れる。

• 可能な限り小さな27Bクラスの成果物が必要な場合、またはDSparkドラフターに依存している場合は、Hugging Faceの初代Bonsai 27Bを、フォークビルドで使う。Bonsai 2に、27Bでそれに取って代わるものは何もない。

• 3.9 GBのバイナリビルドを実行していて、そのフットプリントを維持する必要がある — Bonsai 2に後継機があると決めつけてはいけない。そのまま留まるか、あるいはBonsai 2 9Bを自分のプロンプトで測定するかだ。サイズは半分で、1世代新しく、ベンダーはそれを決着させる比較を公開していない。

• 1つのランタイムから4つのサイズクラスが必要 — それを提供する唯一の世代は Bonsai 2 です。

これをすべて単純化してくれる、注目すべき点が一つある：ptq1_0タグがOllamaのリストに現れることだ。そうなれば、dense-tritカーネルがOllamaの同梱するエンジンにまで到達したということであり、最小のパックではフォークが必須ではなくなり、利便性とフットプリントのトレードオフはトレードオフではなくなる。

そうした話は決して仮定ではない。このようなリリースの背景にある、記録に残されたAIの障害やエージェントのインシデントはOrcaRouter AIインシデントアーカイブに集められており、各項目には独自の情報源、深刻度、信頼度グレード、係争中フラグが付されています。