PrismML Bonsaiとは？1ビット・三値(ternary)量子化でローカルLLMの常識を変えるモデル【2026年】

Posted on by

はじめに

「ローカルLLMをMacで動かしたいけど、メモリが足りなくて大きなモデルが動かない…」

この悩みを持ったことがある人は少なくないでしょう。実際、私が使っているM4 MacBook Air（24GBメモリ）でも、Qwen3.6-27Bのような27Bクラスのモデルは通常の4ビット量子化（Q4_K_M）で約16.8GB。OSやブラウザを動かしながらだと、事実上動作は困難です。

そんな状況を変えようとしているのが、PrismMLのBonsaiシリーズです。2026年7月14日にリリースされたBonsai 27Bは、重みを1ビット（二値）または三値（1.58ビット）に圧縮することで、27Bクラスのモデルをたった3.9GBで動作させることに成功しました。

この記事では、Bonsaiシリーズの技術的な仕組みと、実際にM4 Macで動作させる方法を紹介します。

Bonsaiとは何か

Bonsaiは、PrismMLが開発した超低ビット量子化モデルシリーズです。

重要なのは、Bonsaiが新しくゼロから学習されたモデルではないという点です。既存のモデル（Qwen3.6-27BやQwen3-8B）の重みを、行列単位で極限まで圧縮したものになります。つまり、ベースとなるモデルの知識や性能をそのまま引き継ぎつつ、メモリ使用量だけを劇的に削減しています。

現在、Bonsaiシリーズには2つのファミリーがあります。

二つのファミリー

ファミリービット幅サイズ（27B）FP16対比品質
1-bit Bonsai（二値）1.125 bpw3.9GB約90%
Ternary Bonsai（三値）1.71 bpw5.9GB約95%

各ファミリーには、27B、8B、4B、1.7Bの4サイズが用意されています。27Bのみマルチモーダル（画像入力対応）で、8B以下はテキスト専用です。

なんでこんなに小さくなるのか

通常のモデルは16ビット（FP16）で重みを保持しています。27Bモデルなら約54GBにもなります。一般的な4ビット量子化（Q4_K_M）でも約17.6GB。スマートフォンはもちろん、多くのノートPCでも厳しいサイズです。

Bonsaiが採用しているのは、各重みをコード値で表現し、グループ単位でスケールを共有する方式です。

128個の重みごとに1つのFP16スケールを持ち、各重みは「−1か0か+1」（三値）または「−1か+1」（二値）のいずれかで表現されます。

  • 三値の場合: log2(3) + 16/128 ≈ 1.71ビット/重み（約9.4倍の圧縮）
  • 二値の場合: 1 + 16/128 = 1.125ビット/重み（約14.2倍の圧縮）

この圧縮をEmbeddings、Attention、MLP、出力層の全行列に適用しています。正規化層など一部のパラメータだけが高精度のまま残ります。

特徴的なのは、この圧縮がポストトレーニングで行われる点です。BitNetのように最初から学習する必要がなく、既存のモデル重みをそのまま変換できます。

従来の量子化との違い

従来の2ビット量子化（IQ2_XXSと呼ぶ方式）は実効2.8ビット/重みで約9.4GB。ところが品質面で問題があり、AIME（数学）で57.5、LiveCodeBench（コーディング）で56.4と大幅に性能が低下します。つまり、短いベンチマークではそこそこ良く見えても、実用的なタスクでは顕著に「崩れる」という問題がありました。

Bonsaiは1.125〜1.71ビットとさらに低いビット幅でありながら、この崩れを起こさない点が革新的です。

実際の性能はどこまで出るのか

PrismMLが公開している15ベンチマークの評価結果（思考モード、H100で測定）を見てみましょう。

カテゴリFP16Ternary1-bit
数学95.3393.4091.66
コーディング88.7485.9681.88
知識・推論83.1576.9673.39
ツール呼び出し80.0074.0166.03
指示追従78.4771.7765.74
視覚72.6165.1959.57

Ternary（三値）版はFP16比で約95%、1-bit版でも約90%の性能を維持しています。特にコーディングと数学は低下が少なく、実用的な範囲に収まっている印象です。

ただし、ツール呼び出し（エージェント的なタスク）は低下が大きい点は注意が必要です。1-bit版では66.03と、FP16の80から約14ポイント下がっています。プログラミングエージェントとして使うならTernary版が無難でしょう。

知能密度という考え方

PrismMLは「知能密度（Intelligence Density）」という指標を提案しています。

密度 = −ln(1 − スコア/100) / サイズ(GB)

Bonsai 8Bの知能密度は0.645。対して通常のQwen3 8B（16ビット、16.38GB）は0.096です。同じ重さ（メモリ使用量）に対して、Bonsaiが約6.7倍の知能を詰め込んでいる計算になります。

この指標は極端ではありますが、「どれだけ効率的に知能を圧縮できるか」という視点では興味深いものです。

M4 Mac（24GB）で動かすには

実際にM4 MacBook Air 24GBで動かす場合の選択肢を整理します。

8B vs 27Bの比較

モデルファイルサイズピークメモリ(100K)M4 24GB判定ツール呼び出し
Ternary Bonsai 8B2.03 GB約2.5GB（短期）✅ 余裕なし（非対応）
1-bit Bonsai 27B3.9 GB約10.8GB✅ 実用的66.03
Ternary Bonsai 27B6.66 GB約13.7GB⚠️ 条件付き可74.01
Qwen3.6-27B Q4_K_M16.8 GB約23GB❌ スワップ必至（基準値）

8Bは確かに軽いですが、エージェント機能（ツール呼び出しやMCP連携）がありません。 単なるテキスト生成として使うなら良いですが、Bonsaiの本領を活かすなら27Bを選びたいところです。

M4 24GBの場合、1-bit Bonsai 27Bがベストバランス。ピーク約10.8GBと余裕があり、ツール呼び出しも一応使えます。

Ternary Bonsai 27Bの場合は、4-bit KVキャッシュを有効にすることでピーク約9.2GBまで抑えられます。「品質重視だけどメモリも気になる」という場合はこの組み合わせが良いでしょう。

セットアップは超簡単

Bonsai-demoという公式リポジトリを使えば、セットアップは驚くほど簡単です。

git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo

# モデルサイズを8Bに変更（デフォルトは27B）
export BONSAI_MODEL=8B

# たった1コマンド
./setup.sh

このsetup.shがやってくれるのは以下の通りです。

  1. Xcodeコマンドラインツールの確認
  2. uv（高速Pythonパッケージマネージャー）のインストール
  3. Python venvの作成と依存関係のインストール
  4. HuggingFaceからモデルのGGUFファイルをダウンロード
  5. PrismMLフォークのllama.cppプリビルドバイナリを取得
  6. （macOSのみ）MLXをビルド
  7. Open WebUIのインストール（オプション）

すべて自動で行われ、再実行しても完了済みのステップはスキップされます。

起動はさらに簡単。

# llama-server起動（OpenAI互換API + チャットUI）
./scripts/start_llama_server.sh

これで http://localhost:8080 にアクセスすれば、すぐにモデルと会話できます。

モデルの切り替え

環境変数でモデルファミリーとサイズを自由に切り替えられます。

# Ternary-Bonsai-27B（デフォルト）
./setup.sh

# 1-bit Bonsai-27B
BONSAI_FAMILY=bonsai ./setup.sh

# Ternary-Bonsai-8B
BONSAI_MODEL=8B ./setup.sh

# 全部入り（8種類全部）
BONSAI_FAMILY=all BONSAI_MODEL=all ./setup.sh

Ollamaは非推奨

コミュニティが作ったOllama用のタグもありますが、現時点では推奨しません。理由は、Ollamaで配布されているタグがF16（16.38GB）版しかなく、Bonsaiの最大の利点である「2GBで8Bクラスが動く」を完全に無視しているからです。

Bonsaiを使うなら、直接GGUFファイルをダウンロードし、llama.cppサーバーで動かすのが正解です。Bonsai-demoがその手順を完全に自動化してくれています。

27Bならではの本格機能

8Bにはなく、27Bのみで使える機能があります。これがBonsai 27Bを選ぶ最大の理由です。

ツール呼び出し（Tool Calling）

OpenAI互換のAPI経由で、ネイティブなツール呼び出しが可能です。標準のtoolsパラメータがそのまま使えます。

curl http://localhost:8080/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "messages": [{"role": "user", "content": "東京の天気を教えて"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "都市の天気を取得",
        "parameters": {
          "type": "object",
          "properties": {"city": {"type": "string"}},
          "required": ["city"]
        }
      }
    }]
  }'

レスポンスの choices[0].message.tool_calls にツール呼び出しの情報が返ってきます。

MCP（Model Context Protocol）対応

llama-serverに内蔵されたMCPクライアントにより、以下のサーバーがプリセットされています。

MCPサーバートークンコスト用途
Hugging Face約2,600モデル・データセット検索
DeepWiki約400GitHubリポジトリのドキュメント
Brave Search約2,900Web検索（オプション）

これらのMCPツールは、チャットごとにオン/オフを選択できます。オフの間はプロンプトにスキーマが含まれないので、無駄なトークン消費がありません。

Vision（画像入力）

27Bはマルチモーダルモデルで、画像を入力として与えられます。チャットUIで画像をアップロードするか、APIで image_url を送信するだけです。

Metalバックエンドではデフォルトで画像が約1024トークンにダウンスケールされます（速度優先）。BONSAI_IMAGE_MAX_TOKENS=0 で無制限にすると、小さな文字の読み取りなどに強くなりますが、その分遅くなります。

Thinking Mode（思考モード）

推論時の思考を可視化できるモードです。チャットUIの「Reasoning effort」でOff / Low / Medium / High / Maxから選択可能。APIからは thinking_budget_tokens パラメータで制御します。

--reasoning-budget 2048 のようにサーバー起動時に上限を設定することもできます。

Meta（おまけ）

今回調査していて面白かったのが、Context Bonsai（コンテキスト管理のOSSプロジェクト）とBonsai 27Bが同じ開発者（Basil Goff）によるものだという点です。「bonsai」という名前への強いこだわりを感じます。

Context BonsaiはHermes Agentのプラグインとしても動作し、セッションのコンテキストをモデル自らが剪定（prune）する仕組みです。27Bの「超圧縮」と「自律的な剪定」という二つのbonsaiは、同じ発想から生まれているんですね。

まとめ

Bonsaiシリーズは、ローカルLLMの実用性を一段階引き上げる重要なリリースです。

  • 27Bクラスのモデルが3.9GB〜6.6GBで動くという事実は、ローカルAI環境の選択肢を広げます
  • 従来の超低ビット量子化で起きていた「崩壊」を起こさない点が技術的なブレイクスルー
  • セットアップは ./setup.sh の1コマンドで完了するお手軽さ

一方で、ツール呼び出し性能が低下する点や、8B版にはエージェント機能がない点は理解した上で選ぶ必要があります。

M4 Mac（24GB）をお使いなら、1-bit Bonsai 27Bが「品質・サイズ・機能」のバランスで最も実用的な選択肢になるでしょう。

関連リンク

Photo by Chris F from Pexels