約1.15GBに収まる80億パラメータモデル
2026年3月末、Caltech発のスタートアップ PrismML が「1-bit Bonsai 8B」を Apache 2.0 ライセンスで公開しました。80億パラメータの LLM でありながらファイルサイズはわずか 1.15GB。通常の FP16 モデルが 16GB 超を要することを考えると、14倍以上の圧縮率です。
この記事では、Bonsai がなぜこのサイズで動くのか、従来の量子化と何が違うのか、そして実機での性能はどの程度なのかを掘り下げます。
Bonsai の何が画期的か
ローカル LLM を使ったことがある方なら、Q4_K_M や Q5_K_S といった量子化フォーマットに馴染みがあるはずです。これらは 4〜5 ビットに圧縮しても数 GB のサイズになります。Bonsai はそのさらに先、1ビットまで踏み込みました。
従来の量子化が「学習済みモデルの重みを後から丸める」のに対し、Bonsai は学習段階から1ビット精度を前提に設計されています。結果として、8B パラメータのモデルが iPhone のストレージに楽に収まり、クラウド接続なしで推論できます。
はてなブックマークで 392 users を集めたことからも分かるように、「スマートフォンで実用的な LLM が動く」というインパクトは大きいものでした。
1ビット量子化の技術原理
BitNet から始まった流れ
1ビット LLM の基礎技術は、Microsoft Research が発表した BitNet にあります。BitNet b1.58 では、ニューラルネットワークの重みを {-1, 0, +1} の三値（ternary）に制限します。log2(3) ≒ 1.58 ビットなので「1.58ビットモデル」と呼ばれます。
通常のニューラルネットワークでは、行列積の計算で浮動小数点の乗算が大量に発生します。しかし重みが -1, 0, +1 しか取らない場合、乗算は以下のように単純化されます。
- x * 1 = x（そのまま加算）
- x * (-1) = -x（符号反転して減算）
- x * 0 = 0（何もしない）
つまり、GPU が得意とする浮動小数点乗算が不要になり、加算と減算だけで推論が成立します。これが 1ビット系モデルの根幹にある計算上の利点です。
なぜ三値で品質が維持できるのか
「重みを3つの値に潰して大丈夫なのか」という疑問は自然です。直感的な答えは、学習済みモデルの重みの分布にあります。
大規模言語モデルの重み行列を可視化すると、値の大半がゼロ付近の狭い範囲に集中しています。正規分布に近い釣鐘型の分布になり、極端に大きな値や小さな値はごくわずかです。BitNet b1.58 の三値 {-1, 0, +1} は、この分布を「負の領域」「ゼロ付近」「正の領域」の3つに区切る操作に相当します。元の重みの大多数はゼロ近傍にあるため、0 に丸めても情報損失は小さく、正負の方向性さえ保存すれば重みの「役割」は概ね維持されます。
重要なのは、この三値化を後処理ではなく学習時に行う点です。学習中にモデルは「三値しか使えない」という制約下で最適化されるため、各重みの符号（正か負か）と、ゼロにすべき重みの選択を、損失関数を最小化するように調整します。FP16 で学習した後に丸める PTQ とは異なり、モデル自身が三値表現に適応した重みの配置を学習するため、情報の利用効率が根本的に高くなります。
Bonsai 独自のアプローチ
Bonsai は BitNet の三値とは異なり、重みを {-1, +1} の二値に絞っています。ゼロを排除した純粋な1ビット表現です。
具体的なフォーマット（GGUF Q1_0）は以下の構造を持ちます。
| 要素 | 説明 |
|---|---|
| 符号ビット | 0 → -scale、1 → +scale |
| スケールファクタ | 128個の重みごとに FP16 のスケール値を1つ共有 |
| 実効ビット幅 | 1.125 bit/weight（1 bit + FP16 scale / 128） |
128個の重みが1つの FP16 スケールを共有するため、実質的には 1.125 ビット/重みとなります。「完全な1ビット」ではありませんが、FP16 の 16 ビットと比較すれば桁違いの圧縮です。
重要なのは、この1ビット化がエンベディング層、アテンション層、MLP層、LMヘッドの全レイヤーに適用されている点です。部分的に高精度を残す「混合精度」ではなく、ネットワーク全体を1ビットで統一しています。
従来の量子化との根本的な違い
量子化には大きく2つのアプローチがあります。
PTQ（Post-Training Quantization）
学習済みモデルの重みを後処理で低ビットに丸める手法です。GGUF の Q4_K_M や GPTQ がこれに該当します。処理の流れは以下のとおりです。
- FP16/BF16 で通常どおり学習を完了する
- キャリブレーションデータ（数百〜数千サンプル）をモデルに通し、各レイヤーの重みの分布（最大値・最小値）を収集する
- 収集した分布に基づいてスケールファクタとゼロポイントを計算し、重みを目標ビット幅にクリップ・丸め処理する
- 丸め誤差を最小化するために、レイヤーごとに重みを微調整する（GPTQ では逆ヘッセ行列を使って最適な丸め順序を決定する）
この手法の利点は、学習済みモデルさえあれば数分〜数時間で適用できる点です。4ビット程度までは品質劣化が比較的小さいものの、2ビット以下に落とすと「丸め誤差の蓄積」がレイヤーを重ねるごとに増幅され、品質が急激に崩壊する傾向があります。
QAT（Quantization-Aware Training）
学習時に量子化を組み込む手法です。PTQ が「学習後に丸める」のに対し、QAT は学習中のフォワードパスで実際に量子化を行い、その誤差をモデル自身に学習させます。処理の流れは以下のとおりです。
- モデルの各レイヤーに「擬似量子化ノード」を挿入する。これはフォワードパスで重みを目標ビット幅に量子化し、直後に浮動小数点に戻す（量子化 → 脱量子化）操作を行う
- フォワードパスでは量子化済みの重みで推論し、量子化誤差を含んだ損失が計算される
- バックワードパスでは Straight-Through Estimator（STE）を使う。量子化関数は離散的で微分不可能だが、STE は「勾配をそのまま通過させる」近似により、量子化前の高精度な「シャドウウェイト」に勾配を伝播させる
- シャドウウェイトが更新され、次のフォワードパスで再び量子化される。これを繰り返すことで、モデルは量子化誤差に対して頑健な重みの配置を学習する
PyTorch の検証 では、PTQ で失われた精度の最大 96% を QAT で回復できたと報告されています。代償として、フル学習に近い計算コストが必要です。
BitNet 系のモデルはこの QAT の発展形といえます。量子化を「後から適用する制約」ではなく「アーキテクチャの前提条件」として組み込むことで、1ビットという極端な低精度でも品質を維持できます。
Bonsai の学習手法自体は非公開ですが、アーキテクチャは Qwen3-8B をベースとした Dense モデル（36層 Transformer decoder、GQA、SwiGLU MLP、RoPE、RMSNorm）であることが Hugging Face のモデルカード で確認できます。
ベンチマークと実機性能
品質評価
PrismML の公式ベンチマーク では、6つの標準テストで以下のスコアが報告されています。
| モデル | サイズ | 平均 | MMLU-R | MuSR | GSM8K | HumanEval+ | IFEval | BFCL |
|---|---|---|---|---|---|---|---|---|
| Bonsai 8B | 1.15 GB | 70.5 | 65.7 | 50.0 | 88.0 | 73.8 | 79.8 | 65.7 |
| Qwen 3 8B | 16.38 GB | 79.3 | 83.0 | 55.0 | 93.0 | 82.3 | 84.2 | 81.0 |
| Mistral3 8B | 16.0 GB | 71.0 | 73.9 | 53.8 | 87.2 | 67.4 | 75.4 | 45.4 |
| Llama 3.1 8B | 16.0 GB | 67.1 | 72.9 | 51.3 | 87.9 | 75.0 | 51.5 | -- |
平均 70.5 は、14倍のサイズを持つ Llama 3.1 8B（67.1）を上回り、Mistral3 8B（71.0）に迫る数値です。一方で Qwen 3 8B（79.3）との差は約9ポイントあり、「サイズなりの品質低下」は確かに存在します。
PrismML は「Intelligence Density」という独自指標（1GBあたりの性能）を提唱しており、Bonsai は 1.06/GB と、Qwen 3 8B の 0.098/GB を10倍以上上回ります。サイズ効率という観点では突出した存在です。
実機スループット
| デバイス | バックエンド | トークン/秒 | FP16比 |
|---|---|---|---|
| RTX 4090 | llama.cpp CUDA | 368 | 6.2倍 |
| RTX L40S | llama.cpp CUDA | 327 | 6.3倍 |
| M4 Pro Mac | llama.cpp Metal | 85 | 5.4倍 |
| iPhone 17 Pro Max | MLX | 44 | -- |
| iPhone 17 Pro | MLX | 40 | -- |
これらの数値が実際のユーザー体験としてどう感じられるかを整理します。一般的な日本語テキストでは、1トークンが約1〜2文字に相当します。iPhone 17 Pro の 40 tok/s は、毎秒40〜80文字が画面に流れてくる速度です。人間の平均的な読書速度は毎秒10〜15文字程度なので、生成が読む速度を大幅に上回り、体感としてはほぼ「待ち時間なし」に近い状態です。
レスポンスタイムの観点では、100トークン（日本語で約100〜200文字、短い回答1つ分）の生成に 2.5 秒、500トークン（要約や説明文1段落分）でも 12.5 秒で完了します。クラウド API 経由の場合、ネットワーク往復だけで 100〜300ms のオーバーヘッドがあり、サーバー側のキュー待ちも加わるため、短い応答ではオンデバイス推論のほうがむしろ速くなるケースがあります。
RTX 4090 の 368 tok/s は、1秒間に日本語で約400〜700文字を生成できる計算です。これはリアルタイム文字起こしやストリーミング要約など、バッチ処理的な用途でも十分な速度といえます。
参考までに、FP16 の 1B モデル（パラメータ数が8分の1）が同等のデバイスで 23 tok/s 程度であることを考えると、1ビット化による速度向上の恩恵は明確です。パラメータ数で8倍大きいモデルが、小型モデルの倍近い速度で動くという逆転現象が起きています。
エネルギー効率も顕著で、M4 Pro Mac では FP16 比 5.1 倍（0.091 vs 0.471 mWh/tok）、RTX 4090 では 4.1 倍の効率化が確認されています。バッテリー駆動のモバイルデバイスでは、この差が利用可能時間に直結します。
コミュニティの評価と課題
Hacker News や Reddit r/LocalLLaMA での反応をまとめると、Bonsai には明確な得意・不得意があります。
得意な領域は、一般的なチャット、メール下書き、要約、簡単な数学、ストーリー生成です。1GBのモデルとは思えない一貫性があるという評価が多く見られます。
一方、コード生成では「コンパイルが通らないコードを自信満々に生成する」という報告が複数あり、構造化出力（JSON など）も不安定です。事実に関する質問では、実在しない人物名や出来事を混合したハルシネーションが確認されています。
技術的な懸念として、現状では PrismML の llama.cpp フォークが必要で、LM Studio や Ollama などの主要ツールとの互換性がありません。CPU バックエンドでは float-to-int 変換のバグで出力が壊れるケースも報告されており、エコシステムの成熟にはまだ時間が必要です。
Gemma 4 E2B との比較
Bonsai と同時期に注目を集めているオンデバイスモデルとして、Google の Gemma 4 E2B があります。
| 項目 | Bonsai 8B | Gemma 4 E2B |
|---|---|---|
| パラメータ数 | 8.19B | 2B（Effective） |
| メモリ使用量 | 1.15 GB | 1.5 GB 未満 |
| 量子化方式 | 1-bit（学習時） | 2-bit / 4-bit（PTQ） |
| マルチモーダル | テキストのみ | テキスト + 画像 + 音声 |
| コンテキスト長 | 65,536 tokens | 128K tokens |
| ライセンス | Apache 2.0 | Apache 2.0 |
| 配布方法 | Hugging Face / GitHub | Google AI Edge Gallery |
両者は設計思想が異なります。Bonsai は「パラメータ数を維持したまま極限まで圧縮する」アプローチ、Gemma 4 E2B は「パラメータ数自体を小さくし、マルチモーダル対応を重視する」アプローチです。
テキスト生成の品質に限れば、8B パラメータの Bonsai が 2B の E2B より有利と考えられます。しかし E2B は画像・音声入力に対応しており、128K のコンテキスト長は Bonsai の2倍です。用途に応じて使い分けるのが現実的でしょう。
オンデバイス AI の現在地と展望
主要プレイヤーの動向
2026年4月時点で、オンデバイス LLM は3つの方向から急速に進んでいます。
1つ目は、PrismML の Bonsai に代表される極端な量子化です。1ビット化により、クラウド API に匹敵するパラメータ数のモデルをローカルで動かせるようになりました。
2つ目は、Google の Gemma 4 シリーズ と AI Edge Gallery です。E2B / E4B はモバイル向けに最適化されたマルチモーダルモデルで、Android の AICore を通じてシステムレベルで統合されつつあります。
3つ目は、Apple の Foundation Models フレームワーク です。iOS 26 で導入された 3B パラメータのオンデバイスモデルは、Neural Engine を活用してプライバシーを保ちながら推論を行います。サードパーティアプリからも Swift API 経由で利用可能で、推論コストは無料です。
なぜ「今」オンデバイス AI が加速しているのか
オンデバイス AI 自体は以前から研究されていましたが、2025〜2026年にかけて実用化が一気に進んだ背景には、3つの構造的要因があります。
1つ目はプライバシー規制の強化です。EU の AI Act（2025年施行開始）や各国のデータ保護法制により、ユーザーデータをクラウドに送信すること自体がコンプライアンスリスクになりつつあります。医療、金融、法務といった規制産業では、データが端末から出ないオンデバイス推論が「技術的選択」ではなく「法的要件」に近づいています。
2つ目はクラウド API コストの問題です。LLM の API 利用料は、大規模に展開するとアプリ開発者にとって無視できないコストになります。月間アクティブユーザーが数十万を超えるアプリでは、1リクエストあたり数円の API 課金が月額数百万円のインフラコストに膨らみます。オンデバイス推論であれば、初回のモデルダウンロード以降の追加コストはゼロです。Apple が Foundation Models の推論コストを無料としているのは、この経済構造を明確に意識した設計です。
3つ目はネットワーク遅延の壁です。クラウド API は最速でも 100〜300ms の往復遅延が発生し、電波状況が悪い環境ではさらに悪化します。リアルタイム入力補完、音声アシスタント、カメラ連動の画像認識など、数十ミリ秒単位の応答が求められるユースケースでは、クラウドとの通信自体がボトルネックになります。オンデバイス推論はこの遅延を根本的に排除します。
これら3つの要因が同時に作用した結果、「技術的に可能」から「ビジネス上の必然」へとオンデバイス AI の位置づけが変わりました。Bonsai のような極端な量子化技術は、この構造的な需要に対して「8B パラメータを 1GB に収める」という具体的な解を提示したことで注目を集めています。
残された課題
1GB のモデルならアプリにバンドルして配布することも現実的で、ユーザーが意識しない形で LLM が動く世界が近づいています。
一方、課題も明確です。品質面では Bonsai の平均 70.5 と Qwen 3 8B の 79.3 の差は無視できず、コード生成や構造化出力で影響が顕著です。エコシステム面では、Bonsai は専用の llama.cpp フォーク、Gemma は AI Edge Gallery、Apple は Foundation Models と、統一的な推論基盤がありません。また、現状の性能向上は「メモリ削減」由来であり、1ビット演算に特化したハードウェアが実現すればさらに桁違いの効率化が見込めます。
まとめ
Bonsai 8B は、8B パラメータの LLM が 1GB で iPhone 上を走るという事実だけでインパクトがあります。ただし万能ではなく、コード生成や構造化出力では品質低下が目立ちます。現時点では「対話や要約をオフラインで行いたい」ユースケースに適しています。
Gemma 4 や Apple Foundation Models も含め、2026年はオンデバイス AI が実用化する年です。クラウドとローカルの使い分けを設計に組み込むことが、アプリケーション開発の重要な判断ポイントになるでしょう。
参考リンク
- PrismML -- Announcing 1-bit Bonsai
- Bonsai-8B-gguf -- Hugging Face
- Bonsai 1-bit: An 8B LLM that fits in 1 GB -- getdeploying.com
- Show HN: 1-Bit Bonsai -- Hacker News
- PrismML debuts 1-bit LLM -- The Register
- Microsoft BitNet -- GitHub
- BitNet b1.58 Technical Report -- arXiv
- Gemma 4 -- Google Blog
- Gemma 4 E2B -- Hugging Face
- Google AI Edge Gallery -- Google Developers Blog
- Apple Foundation Models -- Apple Developer
- PTQ vs QAT Comparison -- apxml.com
- QAT for LLMs -- PyTorch Blog