Bonsai 2は、誰も発表する前にOllamaに登場していた

2026年10月17日の未明、Ollamaが提供を開始したBonsai 2 — 9つのタグからなるライブラリエントリで、対象となるのはTernary Bonsai 2 2B、Ternary Bonsai 2 4B、Ternary Bonsai 2 9BおよびBonsai 2 27Bで、それぞれが2種類のパッキングに加えてデフォルトのエイリアスを持つ。Prism MLはこれについて何も述べていない。ベンダーのニュースページに投稿はなく、10月15日の小型モデルに関する発表にも一行も触れられていない — その投稿はランタイムとしてllama.cppとMLX、デモとしてホスト型コンソールを挙げており、Ollamaには一切言及していない。このリストはただ存在しており、9つのタグすべてに同じ「数時間前」の刻印が押されている。これは新たにプッシュされたばかりの姿であり、段階的なロールアウトの姿ではない。

率直に分けるとこうだ。今すぐレジストリとファイルから知り得ること：タグ、その名前、正確なバイトサイズ、コンテンツダイジェスト、そして——OllamaはGGUFを同梱しているので——重み自体の中にあるアーキテクチャとメタデータの文字列。確認されていないこと：誰がそれらをパッケージしたのか、なぜベンダーの発表がプラットフォームに言及していないのか、三値カーネルがOllama自身のエンジンにアップストリームされているのか、それともベンダー提供なのか、そしてベンダーの数字のどれかがその過程を生き残るのかどうか。これらは別々の問いであり、本稿はそれらを別々に扱う。

棚に実際に何が置かれているのか

9つのタグ、4つのサイズ、同じ重みの3つのパッキング。Ollamaのライブラリページには、サイズごとにデフォルトのエイリアスと、-q2_0 サイズごとのバリアントが記載されています:

• bonsai-2:latest — 3.2 GB、9B（ダイジェスト c8b5462f8688）に解決されます

• bonsai-2:2b と bonsai-2:2b-q2_0 — 911 MB、同じダイジェスト de2ccb4e7328

• bonsai-2:4b と bonsai-2:4b-q2_0 — 1.6 GB、同じダイジェスト 93edd652c932

• bonsai-2:9b と bonsai-2:9b-q2_0 — 3.2 GB、同じダイジェスト c8b5462f8688

• bonsai-2:27b と bonsai-2:27b-q2_0 — 8.3 GB、同一ダイジェスト f3c4f4208659

この命名は見た目以上に多くのことを語っている。サイズごとに2つのタグがダイジェストを共有しているのは重複ではない — Ollama がどのパッキングを選んだかについての表明だ。bonsai-2:9b のマニフェストを取得すると、モデルレイヤーは 2.557 GB になる。それは Ternary Bonsai 2 9B の Q2_0 ファイルであり、Hugging Face で計測するとバイト単位まで 2.557 GB だ。PQ2_0 パックは 2.417 GB で、PTQ1_0 パック — 最も小さい 1.997 GB — はここには存在しない。

その選択には、率直に述べておく価値のある帰結がある。というのも、これはサポートスレッドに発展しかねない類の話だからだ。ベンダーのモデルカードによれば、上流の llama.cpp が実行するのは3つのパッキングのうちちょうど1つ、Q2_0 だけだ。「最近の master で、Hadamard アクティベーションランタイムを含む」。それ拒否する——PQ2_0 と PTQ1_0 を未知の型として。というのも、これらには Prism ML の llama.cpp フォークが必要だからだ。Ollama は独自のエンジンを配信している。Q2_0 は、標準的な GGUF コンシューマーが現実的に読み込めるパックであり、そしてその Q2_0 こそ、Ollama が出荷したパックそのものだ。Ollama が独自の三値カーネルを育てたのか、それともベンダー提供のビルドにルーティングしているのかは、レジストリからは分からない。分かるのは、読み込み不能なファイルを彼らが出荷しなかったということだ。

GGUFメタデータは、ページが示すよりも多くのことを教えてくれます

Ollamaのページは、タグごとに4つの事実を示している。バイトサイズ、「256K」コンテキストバッジ、テキスト＋画像の入力タイプ、そして相対タイムスタンプだ。それ以外はすべてファイルの内部にある。各モデルレイヤーのGGUFヘッダーを読むと次のことがわかるが、これには読むべき特定の理由がある。それは、この話の中で誰かのマーケティング上の主張ではない唯一の部分だからだ。

• general.architecture — 4つのサイズすべてで qwen35

• general.name — 小型3モデルでは Ternary-Bonsai-2-2B、-4B、-9B；27Bレイヤーは general.basename = folded とともに汎用文字列 Hf を報告する

• general.file_type — 4つすべてで41、general.quantization_version = 2

• general.size_label — 2B、4B、9B、27B（タグ名に対応）

• テンソル数 — 2B: 320、4B: 426、9B: 427、27B: 851

アーキテクチャ文字列のほうが興味深い。qwen35 は Qwen3.5 のハイブリッドアテンション・バックボーンであり、モデルカードが文章で述べていることをアーティファクト自体から裏づける。すなわち、小さいほうの3つは Qwen3.5-2B、-4B、-9B で、アーキテクチャは変わらず、重みだけが差し替えられている。また、ベンダー自身のリリースノートが覆い隠している命名上の継ぎ目も露呈させる。10月15日の投稿には、新しいモデルは「Qwen3.5 に基づく」とある。27B はまったく別のベースだ——9月17日に発表された Qwen3.8-27B である。4つのサイズ、1つのファミリー名、2つのベースモデル。27B で測定された「Bonsai 2」の挙動について読んだことがあっても、それが自動的に 9B にも当てはまるわけではない。そしてその理由は GGUF ヘッダーを見ればわかる。

27B のメタデータもまた、他より明らかに整っていない。general.name = Hf、general.basename = folded、general.version = v5 で、さらに小さいほうの3つにはない余分なサンプリングキーが1つある。それは、変換パイプラインの中間出力が最終リネームパスなしでプッシュされたときの姿だ。欠陥ではない — テンソルはテンソルだ — が、指紋ではあり、27B のタグが小さいほうの3つとは別の経路を通ってきたことを示唆している。

Ollamaの数値が意味しないもの

ここが、ライブラリのリスティングを扱ったほとんどの解説がつまずくところであり、だからこそ腰を落ち着けて見る価値がある。Ollamaのページに表示されているバイトサイズはコンテナのサイズであり、どのサイズについても、中に入っているモデルファイルより大きくなっている。2Bタグは911 MBと表示されているが、モデルレイヤーは0.547 GB、ビジョンプロジェクターは0.365 GBだ。27Bタグは8.3 GBと表示されているが、モデルレイヤーは7.626 GB、プロジェクターは0.629 GBだ。ライセンスとパラメータのブロブを足せば計算が合う。つまりOllamaは、ビジョンタワーも含めた、プルされるアーティファクト全体のサイズを示しているのだ。

つまり、Ollamaページの9B向け3.2 GBは、同じモデルについてベンダーが示す「2GB」という数値とは比較できない。そしてこの差は報告すべき不一致ではない — 異なる2つのものの、異なる2つの測定値なのだ。Prism MLの0.43 GB / 0.95 GB / 2 GBは言語モデル単体の値だ。ビジョンタワーはオフロードされ、実際に画像が届いたときにだけロードされる。そのためテキストのみのデプロイではその分を負担しないが、ollama pullでは負担する。ベンダーの数値に基づいてデバイスのサイズを決め、そのうえでOllamaからpullする場合、何かを実行する前に予算を0.5～1 GB超過してしまう。

同じ注意は「256K」バッジにも当てはまる。基盤となるコンテキストは262,144トークンで、Qwen3.5バックボーンから継承されている——9Bでは24の線形アテンション層と8のフルアテンション層——そしてOllamaのバッジは表示のためにそれを切り捨てている。コンテキストは実在し、継承されたものであり、Ollamaが追加したものではない。ページのどこにも述べられていないのは、長いコンテキストにどれだけメモリが必要かということだ。そして、層の一部にフルアテンションキャッシュを持つハイブリッドアテンションモデルでは、それは小さな数ではない。Ollamaのページには、262Kが実際に実行したい場所に収まるかどうかは何も書かれていない。

誰がこれをパッケージしたのか、そしてそれは重要なのでしょうか

未回答であり、推測するのではなく未回答としてフラグを立てるべきだ。可能性は三つある。Prism MLがプッシュした、Ollamaが自社カタログ作業の一環としてベンダーの公開GGUFリポジトリから取得した、または第三者が行った、のいずれかだ。レジストリではそのどれなのか判別できない。

確認できるのは成果物の来歴であり、それは一致している。Ollama 自身のモデル説明には「Prism ML の Bonsai 2 は、三値重み（−1、0、+1）向けに構築されたビジョンモデル群であり、標準的な 4 ビットモデルの約半分のサイズで、ほぼフル精度の品質を実現する」と記され、ベンダーの Hugging Face 組織、Bonsai 2 27B のホワイトペーパー、Apache 2.0 へのリンクが添えられている。4 つのサイズ別マニフェストすべてに埋め込まれているライセンスブロブは、Apache 2.0 の文言そのままである。2B、4B、9B のパラメーターブロブは {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} となっており、これはモデルカードにあるベンダー推奨の thinkingモードのサンプリングレシピそのもので、27B のカードが GGUF ファイルではこれを省略していると述べているとおりに min_p が省かれている。それは誰かが推測したものではない。カードを読んで行われた変換なのだ。

それは心強い話ではあるが、あなたの体験を実際に左右するもの——実行しているエンジンに三値カーネルが入っているかどうか——については、依然として何も教えてくれない。正直に言えば、プルが成功したからといって証明されるのは、そのファイルが正しい形式のGGUFであることだけであり、それ以上のものではない。それを前提に何かを構築する前に、自分のハードウェアで検証してほしい。

ベンダーの主張と、確認済みの事項

このファミリーに付されているあらゆる品質数値は、Prism MLによるもので、Prism ML自身のハーネス上で得られたものであり、そのいずれも独立に再現されたものではない。これはこの時期には普通のことだが、暗にほのめかすのではなく、はっきりと明言されるべきだ。10月15日の投稿は、小規模モデルについて6つのスキル領域にわたる19件のベンチマークを、フル精度のQwen3.5ベースラインに対する保持率とともに報告している：

• 2B — エージェント能力 95.5%、数学 107.8%、指示追従 121.5%、コーディング 115.0%、知識 82.9%、視覚 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%

これらのうちいくつかは100%を超えているが、それは誤植でも丸め誤差でもない — そのカテゴリにおいて、三値モデルが派生元のフル精度モデルよりも高いスコアを出したことを意味する。2Bの指示追従が121.5%というのは最も顕著な例だ。それには当然の疑いをもって接するべきだ。圧縮モデルがベンダーの選んだベンチマークで自身のベースラインを上回ることは、少なくとも表現についてと同じくらい、トレーニングとハーネスについての主張である。そして小規模モデルのカテゴリスコアは、27Bのものよりはるかにノイズが多い。27Bの数値はより保守的で、形としてはより信頼できる — FP16の86.32に対して84.78、14のthinking-modeベンチマークにわたる98.2%の保持率、数学は96.57 対 97.06、コーディングレベルは89.42 対 89.07で、損失は知識/推論と視覚に集中している。あるファミリーが1.7ビット表現で能力を犠牲にする場合、それは予測される通りのプロファイルだ。

小規模モデルの投稿の中で、ベンチマークではない唯一の主張こそ、最も真剣に受け止める価値がある：9Bモデルは「標準的な指示追従および日常的な数学タスクで、およそ40%少ないトークンを使う」というものだ。これは能力ではなく冗長性についての主張であり、自分のプロンプトを使えば午後半日で確認できる類のものだ。また、これはベンダー自身のモデルカードにある警告とも関わってくる——思考モードは些細な質問でも3,000トークン以上を消費することがあるので、出力トークンは少なくとも8,192に設定し、思考を有効にしたまま貪欲デコーディングを実行してはならない。推論で行き詰まることがあるからだ。40%冗長性が低いのに、それでも8,192トークンの予算を必要とするモデルは、特定の箇所で冗長だと言っているようなものだ。

これがあなたをどういう立場に置くのか

すでにOllamaを動かしていて、データセンターGPUのないラップトップで27Bクラスのモデルを試したいなら、その4つのタグが現時点で存在する最短ルートです。1回のpullで済み、フォークもカーネルビルドも不要です。実際に最小のパッキングが必要な場合、あるいはベンダーが4Bと9B向けに提供している投機的デコーディング用ドラフターが必要な場合、Ollamaのリストにはそれらはありません。それはHugging FaceからのダウンロードとPrism MLのllama.cppビルドで、10月15日以降そうなっています。

もう一つ知っておく価値があるのは、低ビットモデルを利用する方法はローカルだけではなく、常にそれが正しい選択とは限らないということです。OrcaRouterは200以上のホスト型モデルの前に1つのAPIを、0%のマークアップ——プロバイダーの定価をそのまま適用——に加えてプロバイダー間の自動フェイルオーバー付きで提供するので、あるモデルがノートパソコンに居場所を得る価値があるかどうかを決める前に、実際のワークロードで評価できます。Bonsai 2のどのサイズも現在OrcaRouter経由では提供されておらず、この記事はそう主張しているわけではありません。このファミリーは自分で実行するダウンロードであり、ベンダーがエンドポイントを公開するまではそのままです。ルーティング層があなたにもたらすのは、意思決定のもう半分です——比較対象となるホスト型モデルを1つのキーの背後に置き、単一のモデルでは足りないときにモデルフュージョンとルーティングDSLを利用できるようにします。

何を注視すべきか、状況をどれだけ変えるかを基準に、影響の大きい順に挙げる：Ollamaのタグにptq1_0の兄弟が加わること——これはdense-tritカーネルがアップストリームに入ったことを意味する；プラットフォームを認めるベンダーの投稿——これは来歴の疑問に答えるものになる；そして9Bまたは27Bに関する独立したベンチマーク——これだけが保持率の数値をベンダー報告の列から動かすものだ。これらのいずれかが実現するまで、このリスティングは配信の仕組みであり、新しいモデルではない——そしてそれが配信するモデルは10月15日から公開されている。

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