Bonsai 2 27Bをローカルで動かす方法：GGUF、必要スペック、ベンチマーク

このガイドでわかること：

• Bonsai 2 27Bとは何か、Qwen 3.8 27Bの通常の4ビットGGUFとどう違うのか
• 実行に必要なハードウェア
• Ollama、LM Studio、Atomic Chatでこれらのファイルを読み込めない理由と、Prism MLのllama.cppフォークでBonsai 2 27Bをローカル実行する方法

元の重みと、それを基に当社が作成したGGUFビルドをお探しなら、Qwen 3.8 27Bをローカルで動かす方法をご覧ください。この記事ではBonsai 2 27Bのみを扱います。

Bonsai 2 27Bとは？

Bonsai 2 27Bは、Prism MLが2026年9月17日にApache 2.0ライセンスで公開した、重みが公開されている3値言語モデルです。Qwen 3.8 27Bを重みあたり1.72ビットに圧縮したもので、Prism MLによるとアーキテクチャは変更されていません。Prism ML自身が圧縮を行い、パッキング済みファイルをリリースとして公開しているため、5.95 GBのダウンロードファイルは同社自身のビルドです。

Bonsai 2 27Bの主な仕様：

同じ重みをFP16で保存すると約54 GBになるため、パッキング済みファイルは27Bという同じパラメータ数で約9分の1のサイズになります。ファイルサイズは4ビットの9Bモデルと同程度で、このクラスは小規模言語モデルのガイドで扱っています。このリリースには複数トークン予測が含まれていないため、ファイル単体で投機的デコーディングを動かす機能はありません。

重みごとに3つの値を持つ場合、理論上はlog2(3)、約1.585ビットになります。128個の重みからなる各グループが持つFP16スケールと、ごく一部の高精度で保持される重みを含めると、実際の値は1.72になります。これはBitNet b1.58と同じ3値方式ですが、BitNetが最初から3値で学習するのに対し、Bonsai 2は学習済みの重みを圧縮します。

重みは回転後の基底で保存されています。各行列には、3値を割り当てる前にアダマール回転が適用されます。回転はオフラインで保存される重みに組み込まれるため、追加のビットは必要ありません。アクティベーションに対応する変換を適用しないランタイムは、誤った基底で重みを読み取ります。このため、Bonsai 2にはこの形式に対応したランタイムが必要です。標準のllama.cppは2つのパッキング済みファイルを即座に拒否し、Prism MLの旧Q2_0パックについては警告なしで読み込んで、意味不明な出力を返します。

このリリースには、同じ重みをパッキングした5.95 GBのPTQ1_0と7.21 GBのPQ2_0の2種類があり、ビジョンタワーは別ファイルです。Prism MLにはBonsaiという名前のモデルが3つあり、混同しやすくなっています。

• Bonsai 2 27Bは、このガイドで扱うモデルです。Qwen3.8-27Bをベースとした9月のリリースで、上記2つのパッキング形式があり、Prism MLのllama.cppフォークが必要です。
• Ternary Bonsai 27Bは、Qwen3.6-27Bをベースとした7月のリリースで、専用ファイルを持つ別のリポジトリです。
• Bonsai 27Bは、7月に併せて公開された1ビットモデルで、現時点でAtomic Chatに読み込めるのはこのモデルだけです。

Apple Silicon向けのMLXパックも別のリポジトリprism-ml/Ternary-Bonsai-2-27B-mlx-2bitにあり、ダウンロードサイズは8.6 GBです。このパックはモデルタイプとしてprism_hadamard_qwen35を宣言しており、mlx-lmでは読み込めません。mlx-vlmでは、2026年9月17日にプルリクエスト#2293で対応がマージされました。このマージはv0.7.1リリースより後なので、MLXを使うにはmainからのビルドが必要です。パックのドキュメントに記載されたpythonスニペットは、リポジトリに同梱されたローダーでは失敗します。ローダーが受け付けるのはschema_version 1ですが、パックはschema_version 2を宣言しているためです。

Bonsai 2 27Bのベンチマーク

モデルカードに掲載されたPrism MLのリリース時の数値では、Bonsai 2 27Bとベースモデルの3つのビルドを比較しています。いずれもNVIDIA H100上でEvalScopeとvLLMを使用し、思考モードで評価されています。

Bonsai 2 27Bは、FP16の参照モデルが54 GBであるのに対して5.95 GBで、フル精度モデルの平均スコアの98.2%を維持しています。画像入力には0.63 GBのビジョンパックが追加されます。この表の測定はPrism ML自身が行っており、同社外での再現結果は公開されていません。同社のホワイトペーパーでも同じ98.2%という結果になっていますが、20のベンチマークにおける83.9対85.4という別の数値を使っています。このガイドではモデルカードに従います。

以下は、同じクラスのローカルモデルを、それぞれの開発元が採点した結果です。

この2つ目の表のスコアはすべて各開発元のモデルカードに基づき、評価環境も開発元ごとに異なるため、列間の小さな差に大きな意味はありません。ハイフンは開発元がその数値を公開していないことを示します。また、GoogleはMMMU Proをパーセント表記しているため、行内の形式を統一するためにパーセント記号を省いています。Prism MLのモデルカードにはLiveCodeBenchのバージョンが記載されていませんが、同社のホワイトペーパーにはrelease_v6とあり、QwenとGoogleが報告しているリリースと同じです。ダウンロードサイズは、Bonsai 2についてはPrism MLのPTQ1_0ファイル、ほかの4列については当社独自の4ビットGGUFビルドの値です。したがって、配布時の精度で採点されている列はBonsai 2だけで、残りは開発元によるフル精度での数値です。

最初の表の平均値だけでは、従来の2ビットビルドがどのように性能を落とすかが十分に伝わりません。Prism MLのモデルカードによると、2ビットビルドはMMLU-Reduxで88.93を維持する一方、AIME26では57.50、LiveCodeBenchでは56.40まで低下します。同じ2つのベンチマークで、Bonsai 2は95.83と90.07を記録しています。どちらも長い推論の連鎖に依存するため、2ビットビルドは短いチャットテストに合格しても、ローカルでのコーディングには不適切なファイルである可能性があります。

Bonsai 2の比較対象としてより役立つのは、前世代のBonsaiです。7月にリリースされたTernary Bonsai 27Bは、Qwen3.8-27BではなくQwen3.6-27Bをベースとしています。Bonsai 2のモデルカードでは、同じ14のベンチマークで旧モデルの平均を再計算しており、Bonsai 2の84.78に対して80.98となっています。この差の一部はベースモデルによるものです。FP16の参照スコアは、前のモデルカードの15のベンチマークでは85.07でしたが、今回の14のベンチマークでは86.32になっています。モデルカードでは、残りの差を生む仕組みとして回転後の基底を挙げています。7月のリリースでは回転を使わず、再帰状態の経路と正規化の重みもほかの部分とともに3値化していました。Bonsai 2はこれら26.2Mのパラメータを3値より高い精度で保持しており、公称の重みあたり1.72ビットにはその分も含まれています。Prism MLは、サイズで調整した独自スコアである知能密度も報告しており、7月のリリースが0.416、今回は0.469です。どちらの行も実際の配布ファイルより小さなサイズで計算されており、5.95 GBのファイルに対して5.80 GB、7.17 GBのファイルに対して5.75 GBを使っています。そのため、この2つの値は測定値ではなく順位付けとして読んでください。

Bonsai 2 27BのGGUF：PTQ1_0とPQ2_0の選び方

12 GB以上ある場合はPQ2_0を選んでください。Prism ML自身のクイックスタートで使われているファイルで、モデルカードでApple Silicon上の測定が行われているのもこの形式だけです。8 GBのマシンや、RTX 4090などのAda世代のカードではPTQ1_0を選んでください。RTX 4090では、PQ2_0の毎秒81.2トークンに対して、PTQ1_0は毎秒91.1トークンでデコードします。

Bonsai 2の量子化版はPrism ML自身が配布しています。同社はモデルを重みあたり1.72ビットで公開しており、ほかの人が量子化できる元のフル精度リリースはありません。ここで選ぶのは、1つの低ビットモデルに対する2つのパッキング形式です。どちらもprism-mlのGGUFリポジトリにあります。

両方のパッキング形式には、同じ3値の重みが入っています。各重みは-1、0、+1のいずれかで、128個の重みからなるグループごとに1つのFP16スケールを共有します。違うのは、これらの値をディスク上に格納する方法です。PTQ1_0は3値の各桁を高密度に詰め込み、モデルカードでは重みあたり1.75ビットとされています。PQ2_0は3値の各桁に専用の2ビット枠を割り当て、重みあたり2.13ビットとなります。容量は増えますが、展開処理の負荷が下がります。モデルカードのベンチマークスコアは、いずれかのGGUFパックではなく、3値の重みをvLLMで実行した結果なので、パッキング形式別の品質スコアはありません。

リポジトリには5つのGGUFファイルがあり、すべてTernary-Bonsai-2-27Bという接頭辞を共有しています。

同じmmprojファイルをどちらの言語モデルのパッキング形式とも組み合わせられます。テキストのみの実行では、mmprojファイルを指定しなければ追加の負荷はかかりません。F16ファイルには、2つのパックと同じ10個のprism.hadamardメタデータキーが含まれています。そのため、このファイルも回転後の基底で重みを保持しており、ほかの環境へそのまま持ち運べるFP16チェックポイントではありません。

トレードオフは帯域幅と演算量の間にあります。PTQ1_0は各ステップで転送する重みデータが17%少ない一方、高密度に詰めた3値の展開には演算が必要です。Ada世代のカードとL4ではPTQ1_0が勝ちますが、H100、A100、Blackwellカードでは負けます。これらのカードでは、バッチサイズ1のデコードが代わりに命令スループットで制限されるためです。プロンプト処理は演算能力によって制限されます。モデルカードで両方のパッキング形式を測定したすべてのプラットフォーム、つまり表のすべてのNVIDIA行では、プロンプト処理でPQ2_0が優位です。また、PQ2_0はllama.cppがCPU向けに再パッキングする際、読み込み中にクラッシュすることがある形式でもあります。これについては後述のトラブルシューティングで説明します。

量子化名が示すのは、公開者が指定した処理方式だけであり、ビット幅を保証するものではありません。こうしたラベルの由来は、GGUFとは何か、量子化はどう動くのかのガイドで説明しています。モデルカード自体にも比較があり、同じベースモデルの広く使われている2ビットビルドは実際には重みあたり2.8ビット、9.4 GBであるのに対し、こちらは1.72ビットとしています。Prism MLは測定したファイル名を明示しておらず、Qwen3.8-27Bの9.4 GBのIQ2_XXSビルドも公開一覧には見当たりません。unslothのUD-IQ2_XXSは7.27 GBで、Prism ML自身のホワイトペーパーでは2ビット参照モデルを重みあたり2.2ビット、7.3 GBとしています。言語モデルのごく一部、0.0976%は高い精度で保持されており、Prism MLが公称する重みあたり1.72ビットにはその分も含まれています。この2つのファイルの重みは同一なので、サイズと実行するプラットフォームで選んでください。

Bonsai 2 27Bのハードウェア要件

Bonsai 2 27Bで確認すべきシステム要件はメモリです。PTQ1_0には約6 GB、PQ2_0には約7.2 GBのVRAMまたは統合メモリが必要で、さらにコンテキスト8Kごとに約0.5 GB、画像入力には追加で0.63 GBが必要です。同じ重みを重みあたり16ビットで保持すると約54 GBになるため、コンシューマー向けカードで動かせるのはパッキングのおかげです。2つのパックは5.95 GBと7.21 GBです。以下の表は、必要となる使用可能なRAMとVRAMの合計、またはApple Siliconの統合メモリを示しています。

注：上のすべての行では、計算用バッファと画面表示のために約1 GBを確保しています。画像入力には3つ目のファイルである0.63 GBのビジョンプロジェクターが必要で、その分だけ最終列のコンテキスト用の空き容量が減ります。

コンテキスト長によってメモリはどれだけ増える？

上記の数値はモデルの重みだけを対象にしています。その上で、エンジンはKVキャッシュを確保します。チャットが長くなるほど、モデルがメモリに保持するコンテキストが増え、必要な容量も増加します。会話に大きな文書やコードベースを貼り付ける場合も同じです。

Bonsai 2はQwen 3.8 27Bのアテンション構成を維持しています。従来型のデンストランスフォーマーでは、64層すべてが各トークンのアテンションデータを保存します。このモデルでは、64層のうち48層が固定サイズの状態を持つ線形アテンションを使い、16層のフルアテンション層が使うKVヘッドはわずか4つです。Bonsai-demoリポジトリ内にある、このモデル向けのPrism ML自身のKVキャッシュドキュメントKV-CACHE.mdによると、アテンションキャッシュはトークンあたり約64 KiBで、同じ構成の標準的なトランスフォーマーが保存する量の4分の1です。

重みは5.95 GBなので、32Kの会話ではモデルファイルの約3分の1に相当する容量をアテンションキャッシュが占めます。最大262Kのコンテキスト長全体では約16 GBが必要です。それでも、24 GBのカードなら小さい方のパックと一緒に収まります。

Bonsai 2 27Bを動かせるハードウェアは？

• 8 GB GPU（RTX 4060、RTX 5060）：PTQ1_0をすべてVRAM上で実行でき、約16Kのコンテキストを確保できます。8 GBのカードに収まるほかのモデルをお探しなら、8GB向けのおすすめローカルLLMのまとめをご覧ください。
• 12から16 GBのGPU（RTX 4070、RTX 5070、RTX 5060 Ti 16 GB）：PQ2_0をすべてVRAM上で実行でき、56Kから118Kのコンテキストを確保できます。その空き容量のうち0.63 GBを使えば、ビジョンプロジェクターも一緒に保持できます。12から16 GBのカードに収まるほかのモデルをお探しなら、16GB向けのおすすめローカルLLMのまとめをご覧ください。
• RTX 3090（24 GB VRAM）：PQ2_0を実行でき、約240Kのコンテキストを確保できます。モデルカードに3090の行はありませんが、同カードに記載された基準ではAmpereでのデコードはPQ2_0が優位なので、ここではPQ2_0を選んでください。
• RTX 4090（24 GB VRAM）：PQ2_0の毎秒81.2トークンに対し、PTQ1_0は毎秒91.1トークンで実行できるため、長いプロンプトを処理するのでなければ小さい方のファイルを選んでください。どちらのパックでも240K以上のコンテキストを確保できます。
• RTX 5090（32 GB VRAM）：PQ2_0を最大262Kのコンテキスト長全体で実行でき、開発元の表で最も高い生成速度である毎秒129.9トークンを記録しています。
• AMD GPU（RX 6800 XT、RX 9070 XT）：Prism MLのフォークのROCmビルドで両方のパッキング形式を実行できます。リリースページではUbuntu x64 ROCmアーカイブとWindows x64 HIP/Radeonアーカイブとして配布されており、ソースからビルドする場合は-DGGML_HIP=ONを使います。Vulkanビルドは避けてください。開発元のリポジトリに寄せられたコミュニティの報告では、パッキングされたテンソルの処理がCPUにフォールバックし、MI50で毎秒0.1トークンになっています。当社ではどちらの結果も再現していません。
• Apple Silicon（16 GB以上）：Prism MLのllama.cppフォークでMetalを使い、PQ2_0を実行できます。統合メモリの約75%を使用可能と見積もるため、16 GBのMacには12 GBの行、32 GBのMacには24 GBの行を当てはめてください。MLXパックは別途8.6 GBのダウンロードが必要で、mainlineのmlx-lmでは読み込めません。mlx-vlmでの対応はv0.7.1リリース後の2026年9月17日にマージされたため、この方法にはmainからのビルドが必要です。リリース済みのランタイムで動作するのはGGUFパックを使う方法です。形式を選ぶ際はGGUFとMLXの比較ガイドを、そのマシン向けに最初から作られたモデルをお探しなら16GB Mac向けのおすすめローカルLLMのまとめをご覧ください。
• スマートフォン：現時点では対応していません。Prism MLのモデルカードでは、Bonsai 2のどちらのパッキング形式についてもスマートフォンでの動作をうたっていません。当社のモバイルアプリでは、代わりに以前の1ビットBonsaiを3.80 GBで提供しています。

実測スループット

Prism MLは、ビジョンタワーを読み込まず、バッチサイズ1、深さ0の条件でllama-benchを使い、両方のパッキング形式を測定しました。

M5 Proのデコード時の消費電力はGPU電源系統で27.5 W、CPUとGPUの合計で34.1 Wです。対して、開発元の全体表にあるNVIDIAカードのボード消費電力はおよそ210から330 W、L4は約72 Wです。

モデルカードには、PQ2_0を実行する3台のノートPCを載せた、2つ目のApple向けの表があります。

Prism MLは、この表全体が回転導入前の旧ビルドで測定され、再測定待ちであると注記していますが、ホワイトペーパーではM4 Proの行にだけその注記があります。M5 Proは両方の表に登場し、こちらでは28.7、上の現行スタックでは28.1となっています。そのため、この3行はリリース版の数値ではなく、ハードウェアの性能傾向を示すものとして読んでください。

自分で起動したllama-serverを使ってAtomic ChatでBonsai 2 27Bを動かす方法

Atomic Chatは、当社が開発した無料のオープンソースのローカルAIアプリです。Hugging Faceのモデルブラウザーとチャット機能を内蔵しており、llama.cppを手動でビルドする必要はありません。

2026年9月のAtomic Chat 2.0.37時点では、同梱エンジンはどのプラットフォームでもBonsai 2 27Bを読み込めません。アプリはowner/repoを直接指定する検索でprism-ml/Ternary-Bonsai-2-27B-ggufを見つけ、選択したファイルをダウンロードしますが、その選択画面にあるものはいずれも、その後読み込めません。2つのパッキング済みファイルのテンソル型142と143は、upstreamのllama.cppにはまったく存在しません。同じリポジトリのF16参照ファイルは、テンソルが通常のF16なので解析できますが、2つのパックと同じprism.hadamardメタデータを持っており、当社のエンジンにはその変換を適用する処理がありません。upstreamに型とアクティベーション変換が追加されれば、当社のエンジンマニフェストが新しいllama.cppビルドをアプリに指定し、アプリ自体のリリースなしでそのビルドを取得できます。

それでも、同梱エンジンを迂回する方法なら、現時点でもアプリ内でこのモデルを使えます。Prism MLのllama-serverを自分で起動し、Atomic Chatをクライアントとして接続します。バージョン2.0.37には、自分で実行するllama-serverへの接続を専用の目的とするプロバイダーが組み込まれています。

Atomic ChatをクライアントとしてBonsai 2 27Bを使う手順は次のとおりです。

ステップ1：Atomic Chatをインストールする

atomic.chatからAtomic Chatをダウンロードし、お使いのプラットフォーム向けのビルドをインストールします。

• macOS：ユニバーサル.dmg（IntelおよびApple Silicon）、macOS 13.6以降
• Windows：x64向けの.exeインストーラー
• Linux：root権限を必要としない、x86_64向けの自己完結型.AppImage

Linuxでは、chmod +xでAppImageに実行権限を付け、そのまま実行してください。初回起動時にアプリがFUSEについてのメッセージを表示した場合は、DebianまたはUbuntuではsudo apt install fuse libfuse2、Fedoraではsudo dnf install fuse fuse-libsでインストールします。

ステップ2：モデルを指定してllama-serverを起動する

Prism MLのフォークを入手し、いずれかのパックをダウンロードして、そのパックを指定してサーバーを起動します。下のllama.cppのセクションに、アーカイブ、ビルドコマンド、フラグ一式を掲載しています。アプリ内のフィールド説明では、短い形式が次のように記載されています。

llama-server -m model.gguf --host 0.0.0.0 --port 8080

起動したままにしておいてください。ポートは任意で、8080はアプリがあらかじめ入力する値にすぎません。

ステップ3：Cloudを開き、llama.cpp serverを選ぶ

左サイドバーのCloudをクリックします。ここには、自分のサーバーも含め、アプリがHTTP経由で接続するすべてのプロバイダーが配置されています。ConnectionカードでSelect a providerドロップダウンを開きます。一覧の先頭にはSelf-hostedグループがあり、選ぶ項目はllama.cpp serverです。この項目はクライアント接続用であり、ファイルを実行する同梱のLlama.cppエンジンではありません。

ここでSettings → Model Providersを開くのは適切ではありません。このサブメニューにはローカルエンジンが並んでおり、そこからこのプロバイダーへ進もうとするとCloudにリダイレクトされます。

ステップ4：接続先のサーバーを指定する

Base URLには、すでにhttp://localhost:8080/v1が入力されています。llama-serverが別の場所で動いている場合はホストまたはポートを変更し、末尾の/v1は残してください。アプリはベースURLに/modelsを追加した場所へモデル一覧を要求するため、プロキシのプレフィックスや末尾のパスがあると何も返ってきません。

API keyは空欄のままにします。この行はプロバイダーがその設定を宣言しているために表示され、アプリはその下に「This endpoint runs on your machine and needs no API key.」（このエンドポイントはお使いのマシン上で動作するため、APIキーは不要です）と表示します。llama-serverを--api-key付きで起動した場合だけ入力してください。

ステップ5：モデル一覧を読み込む

ModelsカードでReload modelsをクリックします。アプリはhttp://localhost:8080/v1/modelsにリクエストを送り、サーバーが公開しているモデルを一覧表示します。何も表示されない場合は、その隣の+ボタンをクリックし、Add New ModelダイアログのModel IDフィールドにllama-serverが受け付けるidを入力して、Add Modelをクリックします。

ステップ6：ローカルでチャットする

チャットを開き、上部の選択欄でモデルを選んで送信します。モデルを選択すると、アプリ自身のローカルAPIサーバーがまだ動いていなければ起動するため、ほかに有効にするものはありません。

リクエストはポート8080へ直接送られるわけではありません。チャットからhttp://127.0.0.1:1337/v1のローカルAPIサーバーを経由し、llama-serverに届きます。Connectionカードに、このアドレスを接続先として設定したすべてのクライアントでもこれらのモデルを使えると書かれているのは、このことを指しています。

この方法で利用できることと、利用できないこと

この方法ではAtomic Chatがクライアントとなり、llama-serverがモデルを実行します。そのため、通常はアプリがローカルモデルに対して行う処理の一部を、自分で行う必要があります。

• llama-serverの起動と停止は自分で行います。このモデルにはアプリ内のStartやStopボタンも、メモリに収まるかどうかの見積もりも表示されません。サーバーが起動するまで、Reload modelsでは何も見つかりません。
• アプリのllama.cpp設定は反映されません。コンテキスト長、GPUレイヤー数、Flash Attention、キャッシュの型は、アプリが自身のエンジンに渡す引数です。この方法では、代わりにそれぞれをllama-serverのフラグとして設定します。
• 対応機能は検出されません。手動で追加したモデルはテキスト補完のみに対応する設定になるため、モデルの編集ダイアログでVisionとToolsを手動でチェックしてください。画像入力には、さらにllama-serverを--mmproj付きで起動する必要があります。
• 同梱エンジンは引き続きパックを読み込めません。この方法は当社のGGUFリーダーを完全に迂回するため、Llama.cppおよびLlama.cpp TurboQuantプロバイダーの動作は変わりません。
• 別のマシン上のサーバーにはキーが必要です。キー不要というルールが対象とするのはループバックアドレスなので、LAN内のマシンではllama-serverを--api-key付きで起動し、そのキーをアプリに入力してください。
• これはデスクトップアプリの機能です。iOS版とAndroid版には、このプロバイダーはありません。

アプリには別のエンジンを読み込むボタンもありますが、この方法では使いません。Settings → Model Providers → Llama.cppのVersion & Backend行にはInstall Backend from Fileがあります。これは、upstreamのllama.cppリリースと同じ構成で、内部にbuild/bin/llama-serverがあるtar.gzまたはzipアーカイブを受け付けます。アプリはそのフォルダーを管理し、自身のエンジン更新時に不要な内容を削除します。当社はPrism MLのフォークをこの方法でインストールしたことはありません。

現時点で同梱エンジン上で動くBonsaiは、前のリリースであるBonsai 27Bです。7月に旧ベースモデルを使って1ビットで公開されました。atomic.chatから入手できるデスクトップアプリではスタッフのおすすめに入っているので、そこから開くか、prism-ml/Bonsai-27B-ggufを検索して、Download OptionsからBonsai-27B-Q1_0.ggufを選んでください。デスクトップでの画像入力には、同じリポジトリのビジョンプロジェクターBonsai-27B-mmproj-Q8_0.ggufが追加で1ファイル必要です。iOSとAndroidでは、モデルカタログの3.80 GBのBonsai (27B)カードが該当します。この項目にはビジョンプロジェクターが含まれているため、モデルの読み込み後すぐに画像を添付できます。

このファイルを同梱エンジンで読み込めるのは、Q1_0パックがupstreamのllama.cppの型であり、そのidが41だからです。

Prism MLのllama.cppフォークでBonsai 2 27Bを動かす方法

次のような要件がある場合は、デモのスクリプトではなく、バイナリを自分で実行する方が適しているかもしれません。

• フラグを明示的に指定できるOpenAI互換のローカルエンドポイント
• GPUオフロードの細かな制御
• 再現可能なサーバー構成

これらのファイルにはPrism ML独自のllama.cppフォークが必要です。標準ビルドはPQ2_0とPTQ1_0を即座に拒否します。3値カーネルはPrismML-Engのllama.cppフォークにあり、現時点でローカルGGUFを動かせる唯一の方法です。

Prism MLのBonsai-demoリポジトリには、各バックエンドでテスト済みのセットアップが記載されており、実行スクリプトがハードウェアに合ったフラグを選びます。クイックスタートは./setup.sh、続いて./scripts/start_llama_server.shという2つのコマンドで、チャットはhttp://localhost:8080で利用できます。このセットアップではOpen WebUIとコードインタープリター環境もインストールされ、ダウンロード量が数ギガバイト増えます。BONSAI_OPENWEBUI=0とBONSAI_CODE_INTERPRETER=0を使うと、それらを省略できます。デモがバイナリに加えて提供するのは、チャットUIで会話ごとに推論強度を選ぶ機能とMCPクライアントです。推論強度の選択肢はOff、Low（512トークン）、Medium（2048）、High（8192）、Max（無制限）です。

ステップ1：バイナリを入手する

ビルド済みのアーカイブは、フォークのリリースページにプラットフォームごとにあります。タグprism-b10685-7dffb15から入手してください。公開初日にreleases/latestが指していたリリースにはCUDAランタイムのzipしか含まれておらず、本文中のプラットフォーム別リンクは存在しないアーカイブを指しているため、アクセスすると404になります。

tar -xzf llama-prism-b10685-7dffb15-bin-<platform>.tar.gz -C bin --strip-components=1

Windows版とiOS版は.zipで配布されているため、それらはzipとして展開してください。現在のファイル構成にはprism-b10658以降が必要なので、古いprism-v5アーカイブは使えません。

もう1つの方法は、フォークを自分でビルドすることです。NVIDIA CUDAの場合：

git clone https://github.com/PrismML-Eng/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build -j

Apple Siliconでは、Metalがデフォルトで有効です。

git clone https://github.com/PrismML-Eng/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build -j

2026年9月18日時点で、このフォークはupstreamのmasterより90コミット先行し、420コミット以上遅れています。そのため、遅れているコミットでllama.cppに追加されたものは、このビルドには含まれていません。

ステップ2：モデルをダウンロードして実行する

リポジトリからパックを1つ取得します。

hf download prism-ml/Ternary-Bonsai-2-27B-gguf Ternary-Bonsai-2-27B-PQ2_0.gguf --local-dir .

次のコマンドは、カレントディレクトリにあるPQ2_0を実行し、すべての層をGPUにオフロードして、Prism推奨のサンプリング設定を適用し、コンテキスト長を32Kに設定します。

./bin/llama-cli -m Ternary-Bonsai-2-27B-PQ2_0.gguf \
    -ngl 99 -fa on -c 32768 \
    --temp 1.0 --top-p 0.95 --top-k 20 \
    -p "Explain quantum computing in simple terms." -n 256

バイナリは、リリースアーカイブを展開した場合は./bin/llama-cli、フォークを自分でビルドした場合は./build/bin/llama-cliです。

大きい方のパックが収まらないマシンでは、ファイル名をTernary-Bonsai-2-27B-PTQ1_0.ggufに置き換えてください。重みは同じです。モデルはデフォルトで思考を行い、--reasoning-budgetで思考の長さに上限を設けます。デモはllama-serverに2048を渡しており、llama-serverはAPI経由でOpenAI形式のツール呼び出しも受け付けます。

ステップ3：ローカルのOpenAI互換APIを公開する

llama-cliをllama-serverに置き換えます。

./bin/llama-server -m Ternary-Bonsai-2-27B-PQ2_0.gguf \
    --alias bonsai-2-27b \
    -ngl 99 -fa on -c 32768 \
    --temp 1.0 --top-p 0.95 --top-k 20 \
    --host 127.0.0.1 --port 8080

次のコマンドでテストします。

curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{ "model": "bonsai-2-27b", "messages": [ { "role": "user", "content": "Explain what a ternary weight is." } ] }'

ネットワーク内のほかのマシンからアクセスする必要がなければ、サーバーを127.0.0.1にバインドしてください。

フォークで画像入力を使う

画像入力には、両方のパッキング形式で共用できるビジョンプロジェクターが追加で1ファイル必要です。リポジトリからTernary-Bonsai-2-27B-mmproj-Q8_0.ggufを一度ダウンロードし、選んだパックと一緒に指定します。

./bin/llama-server -m Ternary-Bonsai-2-27B-PQ2_0.gguf \
    --mmproj Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf \
    --alias bonsai-2-27b \
    -ngl 99 -fa on -c 32768 \
    --host 127.0.0.1 --port 8080

Q8_0ファイルは0.63 GBを追加し、画像が届いたときだけ読み込まれます。デモの実行スクリプトは、このファイルを自動で指定します。BONSAI_MMPROJ_CPU=1を設定すると、プロジェクターとそのバッファをシステムRAMに保持します。デモの測定では、これによって約0.9 GiBのVRAMが解放されますが、画像プロンプトの処理は遅くなります。

OllamaまたはLM Studioで実行する

現時点では、どちらのアプリもこれらのファイルを読み込めません。どちらも内部で標準のllama.cppを動かしており、upstreamには2つの新しい型のどちらも含まれていません。OllamaのGGUFパーサーは型142と143に対して型サイズ0を返すため、ollama createはテンソルサイズのオーバーフローで失敗します。また、OllamaのライブラリにはBonsai 2の項目自体がありません。LM Studioも標準のllama.cppビルドを同梱しているため、同じ理由で2つのパックを拒否します。

8月27日からオープンのままのPrism ML自身のプルリクエスト#27779は、デモのupstream対応状況表にある唯一のBonsai 2の行です。この変更が追加するのは、2つのテンソル型ではなく、CPUのFWHTへのF16入力です。Prism MLはこれを一連の変更の第1弾と呼び、バックエンドカーネルと、より広い変換幅への対応が続くとしています。issue #29058に対応して提出されたコミュニティのプルリクエスト#29077は両方の型を追加しますが、レビューは付いておらず、メンテナーは作業をPrism MLに任せるよう求めています。そのCPUカーネルは参照実装で、GPUカーネルは含まれていません。作者の測定では、27Bを16スレッドで動かすと毎秒約0.4トークンで、フォークのカーネルをRTX 5090で使った場合の約135トークンに対する値です。OllamaとLM Studioにも同じことが当てはまります。どちらも独自のllama.cppを同梱しているため、古いバージョンにファイルを読み込ませようとせず、各アプリの更新を待ってください。

トラブルシューティング

モデルは読み込めるが、出力が意味不明になる

ファイルは警告なしで読み込まれますが、返ってくるテキストが意味不明になります。これは、アダマール変換をアクティベーションに適用する処理経路がないランタイムが、誤った基底で重みを読んでいる状態です。標準のllama.cppでは、旧Q2_0パックでこの現象が起きます。Prism MLは同じ理由から、この形式を別のリポジトリにTernary-Bonsai-2-27B-Q2_0-prism-fork-required.ggufという名前で置いています。メインリポジトリのF16ファイルも、回転後の基底を使っています。フォークのリリースページからバイナリを入手し、それでPTQ1_0またはPQ2_0を実行してください。

llama.cppがテンソル型を不明と表示する

PQ2_0はggmlテンソル型142、PTQ1_0は型143で、どちらもupstreamの型一覧の範囲外です。upstreamの一覧は42までで、GGML_TYPE_COUNTは43です。標準ビルドは、まだテンソルヘッダーを読んでいる段階でファイルを拒否します。

gguf_init_from_reader: tensor 'output.weight' has invalid ggml type 142. should be in [0, 42)
gguf_init_from_reader: failed to read tensor info

このメッセージはQ2_0のマージ以前のビルドによるもので、新しいビルドでは上限がより大きな値で表示されますが、どちらの型も依然として拒否されます。upstreamには、どちらの型もマージされていません。両方を追加するオープン中のプルリクエスト#29077にはレビューが付いていません。ここでもフォークのバイナリを使ってください。

PQ2_0が読み込み中にクラッシュする

ファイルの解析後、output.weightの処理でggml_backend_cpu_repack_buffer_set_tensor内のプロセスが終了コード139で落ちます。これはCPU向けの再パッキング処理経路で発生し、-ngl 99でも同じ問題が起きます。Prism MLはフォークのissue #180で追跡しており、回避策はLLAMA_ARG_REPACK=0または--no-repackです。これでモデルが読み込まれ、スレッドでは再パッキングを無効にしたCPU実行で毎秒約3トークンと報告されています。PTQ1_0は同じ重みを持ちますが、このissueではPTQ1_0のクラッシュは報告されていません。

Ollamaでファイルをインポートできない

ollama createの手順は、どちらのパックでもテンソルサイズのオーバーフローで失敗します。OllamaのGGUFパーサーには、型142と143のサイズが定義されていないためです。Ollamaはissue #18521でこの問題を追跡しており、コメントがないままオープンになっています。公式ライブラリには代わりに取得できるBonsai 2の項目がなく、ollama.comにユーザーが再アップロードしたものも同じように失敗します。最も多くダウンロードされているtobestyledintro/Ternary-Bonsai-2-27Bも、自身の説明にそう記載しています。フォークのllama-serverでモデルを提供してください。Ollamaから移行すると何が変わるかは、Ollamaとllama.cppの比較ガイドで説明しています。

長いコンテキストでメモリ不足になる

重みは収まるのに、長い会話でモデルがクラッシュします。これはKVキャッシュが空き容量を超えて増えている状態です。バイナリを自分で実行する場合、よくある原因はフラグ-c 0です。このフラグはファイルから最大値を読み取り、このモデルでは262,144トークンになります。デモ独自のBONSAI_CTX=0は、代わりにRAM容量の区分に応じたデフォルト値に対応付けられますが、以前のリビジョンでは-c 0を渡していました。コンテキスト長は、チャットなら8,192トークン、コードや文書の作業なら32,768トークンと明示的に設定し、作業に必要な場合だけ増やしてください。Prism MLのKV-CACHE.mdによると、アテンションキャッシュはトークンあたり約64 KiBなので、1ギガバイト解放するごとに約16Kのコンテキストを追加できます。BONSAI_KV4=1を使うと、そのキャッシュをおよそ3.5分の1に削減できます。

ダウンロードしたGGUFが本物のモデルではない

リリースから1日以内に、出典のない再アップロードやabliterationを施したフォークなど、非公式のBonsai 2リポジトリがHugging Faceに現れました。見慣れないリポジトリからダウンロードする前に、公開者がprism-mlまたは自分が知っている量子化の作成者であること、モデルカードが存在すること、ファイル一覧に妥当なサイズのGGUFファイルがあることを確認してください。公開者の確認だけでは、2つのprism-mlリポジトリを区別できません。リリース版はprism-ml/Ternary-Bonsai-2-27B-ggufで、prism-ml/Ternary-Bonsai-2-27B-gguf-devは同社の開発用リポジトリです。公式リポジトリでは、PTQ1_0は5,946,648,928バイト、PQ2_0は7,206,168,928バイトです。Hugging Faceには各ファイルのSHA256が掲載されています。これからダウンロードするファイルのサイズとハッシュを照合してください。3値の27Bモデルが400 MBに収まることはありません。

よくある質問

Bonsai 2 27Bに必要なVRAMはどれくらいですか？

小さい方のパッキング形式で約6 GBです。PTQ1_0は5.95 GB、PQ2_0は7.21 GBなので、12 GBのカードなら大きい方のファイルと約56Kのコンテキストが収まり、24 GBのカードなら約240Kまで確保できます。画像入力には、重みに加えて0.63 GBのビジョンパックが必要です。Prism MLのKV-CACHE.mdによると、アテンションキャッシュはトークンあたり約64 KiBなので、8Kのコンテキストにはファイルに加えて約0.5 GBが必要です。

8GBのVRAMでBonsai 2 27Bを実行できますか？

はい。PTQ1_0は5.95 GBなので、8 GBのカードのVRAM内にすべて収まり、約16Kのコンテキストを確保できます。ビジョンパックも一緒に読み込む場合は約6Kです。7.21 GBのPQ2_0では、同じカードでコンテキストに使える容量がほとんど残りません。そのハードウェアに合うサイズのほかのモデルについては、8GB向けのおすすめローカルLLMのまとめをご覧ください。

Bonsai 2 27BはOllamaやLM Studioで動きますか？

いいえ。現時点では、どちらのアプリもこれらのファイルを読み込めません。OllamaのGGUFパーサーはテンソル型142と143に対して型サイズ0を返すため、ollama createはどちらのパッキング形式でも失敗します。公式ライブラリにも、代わりに取得できるBonsai 2の項目はありません。LM Studioは標準のllama.cppビルドを同梱しており、同じ2つの型を拒否します。現時点でローカルGGUFを動かす唯一の方法は、Prism ML独自のllama.cppフォークです。アプリと、その内部で動くエンジンの違いについては、Ollamaとllama.cppの比較ガイドをご覧ください。

Prism MLのllama.cppフォークはupstreamのllama.cppにマージされますか？

まだマージされておらず、別々の2つのプルリクエストが取り込まれる必要があります。Prism ML自身の#27779が追加するのはCPUのFWHTへのF16入力であり、テンソル型ではありません。コミュニティの#29077は両方の型を追加しますが、レビューは付いておらず、メンテナーは作業をPrism MLに任せるよう求めています。そのCPUカーネルは参照実装で、27Bでは毎秒約0.4トークンです。それまでは、標準バイナリはテンソル型の処理で停止します。また、回転後の基底が2つ目の問題になります。アクティベーションに対応する変換を適用しないランタイムは、解析できるものを読み込んでも、意味不明な出力を返します。

Bonsai 2 27Bのどのファイルをダウンロードすればよいですか？

メモリに余裕があればPQ2_0を選んでください。5.95 GBに対して7.21 GBと1.26 GB大きくなりますが、モデルカードで両方のパッキング形式を測定したすべてのプラットフォームで、プロンプト処理が高速です。8 GBのカードや、5.95 GBは収まっても7.21 GBは収まらないマシンではPTQ1_0を選んでください。RTX 4090では、PQ2_0の毎秒81.2トークンに対してPTQ1_0は毎秒91.1トークンで生成します。一方、RTX 5090では、120.5に対して129.9でPQ2_0が優位です。両方のファイルは同じ3値の重みを持っています。モデルカードでは、両方に対して共通のベンチマークスコアを1組報告しています。

MacでBonsai 2 27Bを実行できますか？

はい。Prism MLのllama.cppフォークのMetalビルドで実行できます。同社がApple M5 ProノートPCでPQ2_0を測定したところ、生成は毎秒28.1トークン、プロンプト処理は387で、GPU電源系統の消費電力は27.5 Wでした。macOSはGPUメモリを統合メモリの約75%に制限するため、16 GBのMacではモデルに約12 GBを使えます。これはPQ2_0と約56Kのコンテキストに十分な容量です。MLXパックは別途8.6 GBのダウンロードが必要で、mainlineのmlx-lmでは読み込めません。2026年9月17日に取り込まれたmlx-vlmの対応はv0.7.1リリースより後なので、この方法にはmainからのビルドが必要です。そのマシン向けのサイズで最初から作られたモデルについては、16GB Mac向けのおすすめローカルLLMのまとめをご覧ください。

Bonsai 2 27BはAMDカードやVulkanで動きますか？

ROCmでは動きます。フォークのリリースページにはUbuntu x64 ROCmアーカイブとWindows x64 HIP/Radeonアーカイブがあり、ソースからビルドする場合は-DGGML_HIP=ONを使います。Vulkanは避けるべきバックエンドです。開発元のリポジトリに寄せられたコミュニティの報告では、パッキングされたテンソルの処理がCPUにフォールバックし、MI50で毎秒0.1トークンになっています。当社ではどちらの結果も再現していません。

Bonsai 2は7月にリリースされたBonsai 27Bとどう違いますか？

違いはベースモデルとパッキング形式です。Ternary Bonsai 27BはQwen3.6-27Bをベースとしており、Bonsai 2のモデルカードでは、同じ14のベンチマークからなる評価セットで旧モデルが80.98、Bonsai 2が84.78、知能密度は0.416対0.469とされています。旧モデルの最小の言語モデルファイルは7.17 GBで、今回は5.95 GBです。現時点でAtomic Chatで動かせるBonsaiは、このどちらでもありません。別のprism-ml/Bonsai-27B-ggufリポジトリにある1ビットのBonsai 27B、Bonsai-27B-Q1_0.ggufで、ファイルサイズは3.80 GBです。Q1_0は2026年4月にupstreamへ取り込まれており、このパックにはランタイムが適用すべきアダマール回転がないため、標準のllama.cppビルドで読み込めます。

Bonsai 2 27Bの性能はフルサイズのQwen 3.8 27Bと同じですか？

完全に同じではありません。14のベンチマークの平均は、FP16の重みの86.32に対して84.78、つまり98.2%です。コーディングと指示追従ではわずかに上回り、それぞれ89.07に対して89.42、81.25に対して82.66です。知識と推論は85.55から79.86へ、画像理解は71.36から66.19へ低下します。元の重みと、それを基に当社が作成したGGUFビルドについては、Qwen 3.8 27Bをローカルで動かす方法のガイドをご覧ください。

98.2%という主張は信頼できますか？

Prism ML自身による測定であり、同社外での再現結果は公開されていません。維持率は、その基となる平均値よりも一貫しています。モデルカードでは14のベンチマークの84.78を86.32で割り、ホワイトペーパーでは20のベンチマークの83.9を85.4で割っていますが、どちらも98.2%になります。2つの評価セットは、どちらももう一方の部分集合ではありません。このガイドのBonsai 2に関する数値は、すべてモデルカードに基づいています。

Bonsai 2 27Bはローカルで画像入力に対応していますか？

はい。0.46Bのビジョンタワーは、Ternary-Bonsai-2-27B-mmproj-Q8_0.ggufという別の0.63 GBファイルで配布され、エンジンは画像が届いたときだけ読み込みます。画像理解は、FP16の重みに対して最も大きく性能が低下する2つのカテゴリのうちの1つです。MMMU-Proは81.73に対して75.49、OCR Bench v2は60.99に対して56.88です。MLXパックにもビジョンタワーが含まれており、回転を適用しないFP16で0.92 GBです。mainlineのmlx-lmではこのパックを読み込めません。対応を追加したmlx-vlmのマージは、貢献者が実際の重みと画像入力で検証していますが、v0.7.1リリース後に取り込まれました。リリース済みのランタイムでMacの画像入力を使う場合は、GGUFファイルを利用します。

Bonsai 2 27Bでツール呼び出しは動作しますか？

モデルカードのBFCL v3スコアは、FP16の重みの76.74に対して74.92で、フォークのllama-serverはAPI経由でOpenAI形式のツール呼び出しを受け付けます。ただし、動作報告はスコアほど確定的ではありません。開発元のHugging Faceリポジトリのあるスレッドでは、ツール呼び出しがまったく動かないと報告されており、同社からの回答がないままオープンになっています。当社では再現していません。

思考モードをオフにできますか？

はい。デフォルトの思考は推論強度xhighで動作し、モデルカードでは短い回答向けにmediumを案内しています。チャットテンプレートはenable_thinkingをfalseに設定すると受け付け、思考ブロックを即座に閉じます。Prism MLのデモは思考を有効にして提供し、チャットUIの電球アイコンにOffと4段階の推論予算を用意しています。モデルカードには、思考を使わない場合の独自のサンプリング値として、temperature 0.7、top_p 0.80、top_k 20、presence_penalty 1.5が記載されています。

Bonsai 2 27Bに無検閲版やabliterationを施した版はありますか？

Prism MLからは公開されていません。リリースから1日以内に、同社とは関係のないアカウントから、abliterationを施した再パッキング版がHugging Faceに公開されましたが、当社ではいずれもテストしていません。これらは作成の仕組み上、リリース版とは異なるファイルなので、上記のサイズとハッシュの確認だけでは、何をダウンロードしたのかはわかりません。この変更の方法と、それに伴う代償については、abliterationを施したモデルのガイドで説明しています。

Bonsai 2 27Bは無料で商用利用できますか？

はい。Bonsai 2 27BはApache 2.0ライセンスで配布されており、商用利用、改変、再配布はいずれも許可されています。ベースモデルのQwen 3.8 27BもApache 2.0です。リポジトリ内のNOTICE.txtは、一般向けにデプロイまたは再配布する際に「Created using Bonsai by Prism ML」という一文を記載するよう求めていますが、これはライセンスの条件ではなく、依頼として書かれています。

まとめ

Bonsai 2をローカルで動かすには、適切なファイルと、それを読み込めるフォークの2つが必要です。マシンに8 GBのVRAM、またはMacに16 GBの統合メモリがあれば、Bonsai 2 27BによってQwen 3.8 27Bを5.95 GBのファイルで利用できます。8 GBのカードではPTQ1_0をダウンロードすると約16Kのコンテキストを確保でき、12 GB以上では7.21 GBのPQ2_0で約56Kを確保できます。コンテキスト長は8,192トークンから始め、作業に応じて増やしてください。RTX 4090では、代わりにPTQ1_0を選んでください。81.2に対して毎秒91.1トークンで生成し、劣るのは長いプロンプトの処理だけです。どちらのパッキング形式にもPrism MLのllama.cppフォークが必要です。開発元のBonsai-demoリポジトリなら、2つのコマンドでセットアップできます。標準のllama.cppバイナリで読み込めるほかのQwenビルドをお探しなら、ローカルで動かせるQwenモデルのまとめをご覧ください。

要点：

• Bonsai 2 27Bは、Prism MLがアーキテクチャを変更せずにQwen 3.8 27Bの重みを3値に圧縮したモデルです。
• PTQ1_0はモデルを重みあたり1.75ビットで5.95 GBに、PQ2_0は2.13ビットで7.21 GBにパッキングします。
• モデルカードの14のベンチマーク全体で、Bonsai 2はFP16の平均スコアの98.2%を維持しています。86.32に対して84.78です。
• mainlineのllama.cppにはテンソル型142と143がまだマージされていないため、OllamaとLM Studioもこれらのファイルを拒否します。
• 長いコンテキストには、ファイルに加えてメモリが必要です。8Kで約0.5 GB、32Kで2 GBが追加されます。