こんにちは、パレイド技術部です。
Caltech 発の AI ラボ PrismML が、世界初の商用レベル 1-bit LLM「Bonsai 8B」 を Apache 2.0 ライセンスで公開しました。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
Bonsai 8B とは
8B パラメータの LLM でありながら、全重みが 1ビット（0 or 1）で構成されています。モデルサイズはわずか 1.15GB。通常の FP16 8B モデル（約16GB）の 14分の1 です。
これは後付けの量子化（GPTQ、AWQ 等）ではなく、最初から1ビット精度でトレーニングされたモデルです。Caltech で開発された新しい数学的フレームワークに基づいており、各重みは -scale か +scale の二値で、128個ごとに1つの FP16 スケール値を共有する構造（Q1_0_g128）になっています。
1ビットの技術的なポイント
1ビット LLM の先行研究としては、Microsoft Research の BitNet（2023年）と BitNet b1.58（2024年）が知られています。BitNet b1.58 は重みを {-1, 0, 1} の三値（1.58ビット）にする手法で、理論上はメモリ・速度ともに大幅な改善が見込めることを示しました。ただし BitNet はモデル重みが公開されなかったため、論文とアーキテクチャの提案に留まっています。
Bonsai 8B は BitNet とは異なるアプローチ（{-scale, +scale} の純粋な二値、1.0ビット）を採用しつつ、GGUF / MLX 形式で実際に動くモデルを Apache 2.0 で公開した点が最大の違いです。「1ビットでも実用になる」ことを論文ではなく動くモデルで証明した、という意味で注目されています。
従来の量子化との違い
従来の GPTQ や AWQ は、FP16 で学習済みのモデルを後から低ビットに圧縮する手法です。精度劣化は避けられず、4bit（Q4_K_M）あたりが実用の下限とされてきました。
Bonsai はトレーニング段階から1ビットです。ベースモデルは Qwen3-8B のアーキテクチャ（36層、GQA、SwiGLU）を採用し、PrismML 独自の学習手法で全層（埋め込み、アテンション、MLP、LMヘッド）を1ビット化しています。
なぜ1ビットで品質が保てるのか
PrismML は3つの要因を挙げています。
- Caltech 発の新しい数学理論: 1ビット精度での学習を安定させる理論的裏付け
- 十分なスケール: 8B パラメータ以上であれば、1ビットでも知識を保持できる
- 標準フォーマット対応: GGUF / MLX で配布し、既存エコシステムに乗る
ホワイトペーパーは GitHub リポジトリ で公開されています。
Qwen3 ベースの設計と日本語対応
Bonsai 8B のアーキテクチャは Qwen3-8B がベースです。36層の Transformer デコーダ、GQA（32 query / 8 KV heads）、SwiGLU、RoPE という構成はそのままに、全層の重みを1ビット化しています。
日本語に対応しているのも Qwen3 ベースの恩恵といえます。Qwen のトークナイザ（vocab 151,936）は中国語・日本語を含む多言語データで学習されており、日本語トークンの分割効率が良いため、1ビット化後も日本語での応答が可能になっています。
ただし後述の検証で分かる通り、1ビット化による品質劣化は日本語で特に目立ちます。英語ベンチマークのスコアほどには日本語の実用性は高くない、というのが正直な印象です。
なぜ注目なのか
ベンチマーク比較（PrismML 公式発表）
| モデル | 開発元 | サイズ | 平均スコア |
|---|---|---|---|
| Qwen 3 8B | Alibaba | 16 GB | 79.3 |
| Ministral3 8B | Mistral | 16 GB | 71.0 |
| Olmo 3 7B | AI2 | — | 70.9 |
| Bonsai 8B | PrismML | 1.15 GB | 70.5 |
| LFM2 8B | — | — | 69.6 |
| Llama 3.1 8B | Meta | 16 GB | 67.1 |
出典: PrismML 公式ブログ / Hugging Face モデルカード 評価項目: IFEval, GSM8K, HumanEval+, BFCL, MuSR, MMLU-Redux の6指標平均
1.15GB で Llama 3.1 8B（16GB）を上回り、Qwen 3 8B とも約9ポイント差に収まっています。サイズあたりの知能密度（PrismML の提唱する指標）では Qwen 3 8B の10.8倍 という数字です。
なお、これは PrismML 自身による計測値であり、第三者による独立検証はまだ出ていません（2026年4月時点）。
ツール呼び出し（Function Calling）対応
6指標の1つである BFCL（Berkeley Function Calling Leaderboard） はツール呼び出しの精度を評価するベンチマークです。個別スコアを見ると、ここが Bonsai の弱点であることが分かります。
| モデル | BFCL スコア |
|---|---|
| Qwen 3 8B（FP16） | 81.0 |
| Bonsai 8B（1-bit） | 65.7 |
ベースの Qwen3 8B から約2割の劣化です。平均スコア（70.5 vs 79.3）の差が約1割であることを考えると、ツール呼び��しは1ビット化の影響を特に受けやすい領域と言えます。
Bonsai は Qwen3 のアーキテクチャとトークナイザをそのまま使っているため、ツール呼び出しの形式は Qwen3 の <tool_call> / <tool_response> タグがそのまま使えるはずです。ただし PrismML からツール呼び出しに関する公式ドキュメントやサンプルは今のところ出ていません。
エージェント用途（自動でAPIを叩く、関数を選択して実行する等）を想定する場合、BFCL 65.7 は実用にはやや心もとない数字です。ツール呼び出しの信頼性が重要な場面では、素直に Qwen3 8B（FP16）を使う方が安全でしょう。
推論速度（公式値）
| 環境 | 生成速度 | FP16比 |
|---|---|---|
| RTX 4090 (CUDA) | 368 tok/s | 6.2x |
| M4 Pro (MLX) | 131 tok/s | 8.4x |
| M4 Pro (GGUF) | 85 tok/s | 5.4x |
| iPhone 17 Pro Max | 44 tok/s | — |
出典: 同上（PrismML 公式ブログ）
M4 Pro の MLX で 131 tok/s は驚異的です。通常の 8B モデルが 15〜20 tok/s 程度であることを考えると、体感が全く違います。
Mac で動かす3つの方法
早速、MacBook Air M5 で動くか試してみました。
方法1: Ollama — 現時点では動かない
コミュニティによるアップロード（digitsflow/bonsai-8b）が Ollama に登録されており、ダウンロード自体は成功します。しかし 2026年4月時点の Ollama v0.20 では実行時にクラッシュします。
$ ollama show digitsflow/bonsai-8b
quantization: unknown ← Q1_0 を認識できていないOllama 本体が1ビット（Q1_0）フォーマットに未対応なのが原因です。正式対応を待つ必要があります。
方法2: MLX — 現時点ではフォーク版のビルドが必要
標準の MLX（v0.31）は1ビット量子化に対応しておらず、モデルのロード時にエラーになります。
ValueError: [quantize] The requested number of bits 1 is not supported.
The supported bits are 2, 3, 4, 5, 6 and 8.PrismML が1ビットカーネルを実装したフォーク版 MLX を提供しています。
pip install mlx @ git+https://github.com/PrismML-Eng/mlx.git@prismただし、今回の検証環境（macOS 15.4 / Python 3.12）では C++ ビルドに失敗し、インストールできませんでした。環境依存の可能性がありますが、すんなり動く状態ではありません。
公式ベンチマークの M4 Pro 131 tok/s はこの MLX フォーク版で計測されています。upstream への PR は審査中とのことで、正式統合されればインストールの手間はなくなるはずです。
方法3: llama.cpp（Metal バックエンド）★唯一動いた方法
PrismML のフォーク版 llama.cpp を使います。今回の検証で唯一動作を確認できた方法です。
git clone https://github.com/PrismML-Eng/llama.cpp
cd llama.cpp
cmake -B build -DGGML_METAL=ON && cmake --build build -jGGUF ファイルは Hugging Face (prism-ml/Bonsai-8B-gguf) からダウンロードします。ファイル名は Bonsai-8B.gguf（1.1GB）です。
# Hugging Face からダウンロード
pip install huggingface-hub
python -c "
from huggingface_hub import hf_hub_download
hf_hub_download('prism-ml/Bonsai-8B-gguf', 'Bonsai-8B.gguf', local_dir='.')
"
# 実行
./build/bin/llama-cli \
-m Bonsai-8B.gguf \
-p "こんにちは" -n 256 \
--temp 0.5 --top-p 0.85 --top-k 20 -ngl 99対話テスト
プロンプト: 「こんにちは」
こんにちは！私はBonsaiです。私はPrismMLによって開発されたAIアシスタントで、低レイテンシーと低メモリ使用量のために最適化されています。
自己紹介してきました。1ビットモデルであることをちゃんと認識しています。
プロンプト: 「日本の首都はどこですか？」
日本の首都は東京です。東京は日本の政治、経済、文化の中心であり、東京府、千葉県、神奈川県、埼玉県…
正しい答えの後、県名の羅列が始まって128トークンの上限まで続きました。ストップ制御が甘い印象です。短い事実質問には答えられるものの、「いつ止めるか」の判断は 16GB クラスのモデルに及びません。
プロンプト: 「Pythonでフィボナッチ数列を生成する関数を書いてください」
thinking モードに入り、考え始めました（Qwen3 ベースなので thinking 機能あり）。ただし -n 128 の上限内で thinking が終わらず、コード出力には至りませんでした。
プロンプト: 「量子コンピュータの原理を100文字以内で説明してください」
量子コンピュータはビットではなく量子ビット（ビット）を使用し、重ね合わせと量子もたらしの特性を持ちます。これにより、特定の問題に対して非常に高速に処理できます。
方向性は正しいですが、「量子もたらし」（量子もつれ→もたらし）と日本語がやや怪しいです。
ベンチマーク結果
PrismML 版 llama.cpp で4つのプロンプトを実行した結果です。直接比較すべきではありませんが、前回MLXでの記事と同じ指標（TTFT / TPS）で整理しました。
| タスク | TTFT (秒) | TPS (tok/s) | 生成トークン数 | 総時間 |
|---|---|---|---|---|
| 挨拶 | 0.23 | 26.5 | 65 | 2.7秒 |
| 事実質問 | 0.26 | 30.1 | 127 | 4.5秒 |
| コード生成 | 0.28 | 29.9 | 127 | 4.5秒 |
| 説明 | 0.34 | 25.8 | 50 | 2.3秒 |
※ TTFT = 最初の応答トークンが返るまでの時間、TPS = 生成速度（tokens/sec）
TTFT は 0.23〜0.34秒で非常に高速。生成速度は約 26〜30 tok/s で、公式の M4 Pro GGUF 値（85 tok/s）には届いていません。原因として考えられるのは：
- PrismML のフォーク版 llama.cpp の Metal カーネルが M5 に最適化されていない可能性
- 公式値は異なるコンパイル設定やバッチサイズで計測されている可能性
Qwen3.5 との比較（参考）
前回記事の Qwen3.5 と並べてみます。推論エンジンが異なる（Bonsai = PrismML 版 llama.cpp、Qwen = Ollama MLX）ため、純粋な速度比較ではありません。同じ M5 Mac 上でそれぞれ動かした場合の実測値として参考にしてください。
| モデル | モデルサイズ | 生成速度 (tok/s) | 実メモリ消費 | 推論エンジン |
|---|---|---|---|---|
| Bonsai 8B | 1.1 GB | 26〜30 | 約10.6 GB | PrismML llama.cpp (Metal) |
| qwen3.5:9b (think OFF) | 6.6 GB | 19.8 | 約10 GB | Ollama MLX |
| qwen3.5:35b (think OFF) | 23 GB | 16.4 | 約30 GB | Ollama MLX |
モデルサイズは qwen3.5:9b の 6分の1、メモリ消費はほぼ同等です。生成速度は数字上は Bonsai が上回っていますが、エンジンが違うため単純な優劣は言えません。Ollama が Q1_0 に対応して同じエンジンで比較できるようになれば、より正確な評価ができるはずです。
回答品質（特に日本語の正確さや出力制御）では qwen3.5:9b に明確に軍配が上がります。
モデルファミリー
PrismML は 8B 以外にも2つの小型モデルを公開しています。
| モデル | サイズ | 速度（M4 Pro） | 用途 |
|---|---|---|---|
| Bonsai 8B | 1.15 GB | 131 tok/s | デスクトップ・サーバー |
| Bonsai 4B | 0.57 GB | 130 tok/s | ラップトップ・タブレット |
| Bonsai 1.7B | 0.24 GB | 130 tok/s | スマートフォン |
1.7B で 0.24GB、iPhone 上で動作するとのこと。エッジ AI の世界が一気に現実味を帯びてきます。
まとめ
- Bonsai 8B は世界初の商用レベル1ビット LLM。サイズ 1.1GB で Llama 3.1 8B を超えるベンチマーク性能
- Apache 2.0 ライセンスで商用利用可能
- Ollama は現時点では動かない（Q1_0 未対応でクラッシュ）。PrismML フォーク版の llama.cpp か MLX が必要
- M5 Mac + llama.cpp で 生成 26〜30 tok/s、プロンプト処理 88〜132 tok/s。モデルサイズ比では驚異的な速度
- qwen3.5:9b の 6分の1のサイズで、生成速度は1.3〜1.5倍速い
- ただし日本語の品質はまだ粗い。県名の羅列や「量子もたらし」のような表現崩れが見られる
- 1.1GB という軽さは、スマートフォンや IoT デバイスでの LLM 実行を現実的にする
速度とサイズでは文句なし。日本語品質が今後改善されれば、エッジ AI のゲームチェンジャーになり得るモデルです。Ollama の正式対応と、MLX upstream への1ビットカーネル統合を待ちたいところです。
