Bonsai-8B考察 — 1-bit LLMは使い物になるのか
自分用メモとして書きました。PrismML（Caltech発）がリリースした真の1-bit LLM「Bonsai-8B」。モデルサイズわずか1.15GB。海外LLMコミュニティの議論を調べ、技術的な仕組みから実用性までまとめたもの。
1. Bonsai-8Bとは — Caltech発1-bit LLMの衝撃
PrismMLが開発した真の1-bit LLM。重みが0か1のみ。モデルサイズ1.15GB、MMLU-R 65.7。
PrismMLはCaltech（カリフォルニア工科大学）発のAIラボで、"intelligence density"（バイトあたりの知能密度の最大化）をコアミッションに掲げている。Bonsai-8Bはそのフラッグシップモデルであり、真の1-bit重み（バイナリ: 0と1のみ）を持つ大規模言語モデルだ。ここで重要なのは「真の1-bit」という点。後述するMicrosoftのBitNet（-1, 0, 1のternary）とは根本的に異なり、重みの値は0か1しか存在しない。
スペックとしては8Bパラメータを持ちながら、メモリ上のフットプリントはわずか1.15GB。MMLU-Rベンチマークでは65.7を達成し、コンテキスト長は65Kトークンをサポートする。ベースモデルにはQwen3-8B（Qwen3.5ではない）を採用しており、ホワイトペーパーはGitHub（PrismML-Eng/Bonsai-demo）で公開されている。
PrismMLはBonsaiを「ロボティクス、リアルタイムエージェント、エッジデプロイメント向けに設計された、商業的に実用可能な初の1-bit重みモデル」と位置づけている。つまり、デスクトップでの汎用LLM利用ではなく、極端にリソースが制限された環境で「LLMが使えるか使えないか」の境界を押し広げることが本来の目的だ。1.15GBという数字は、スマートフォンの空きメモリにすら収まるサイズであり、これが8Bアーキテクチャの品質を（ある程度）維持しているという点が革新的なのである。
この記事の情報は2026年4月時点のものです。 AI/LLM分野は変化が極めて速いため、モデル名・性能評価・対応状況などは記事作成時点から変わっている可能性があります。最新情報はPrismML公式等で確認してください。
2. 1-bit vs BitNet vs 通常量子化 — 何が違うのか
通常の量子化（Q4等）は重みを圧縮するだけ。1-bitは重みそのものが0/1。BitNetのternary（-1,0,1）とも異なる。
LLMの「軽量化」と一口に言っても、技術的なアプローチは大きく3つに分かれる。まず通常の量子化（Q4_K_M、Q8_0など）は、FP16やFP32で学習された重みを、推論時に4bitや8bitに圧縮する手法。学習自体はフル精度で行われており、量子化は「あとから圧縮する」プロセスだ。精度は量子化レベルに応じて劣化するが、Q4程度なら実用上の差は小さいとされている。
次にBitNet。Microsoftが2023年に発表したBitNetは当初バイナリ（-1, 1）の2値だったが、2024年のBitNet b1.58で**ternary（-1, 0, 1）**に拡張された。0という値を加えたことで「不均衡な性能向上」が得られたとされ、これがBitNet系の主流となった。重要なのは、BitNetは学習段階から低ビットで行う「ネイティブ量子化」であり、後処理ではないという点だ。
そして Bonsai-8Bの1-bit。重みは純粋なバイナリ（0と1）だが、活性化（activation）にはint8を使用する。「重みは1-bitだが、活性化はint8」という構成だ。これは「普通のモデルを1-bitに量子化した」のとは全く異なる。後者は使い物にならないレベルに劣化するが、Bonsaiは学習プロセス自体が1-bit重みを前提に設計されている。過去最大のBitNetモデルが約3Bパラメータだったことを考えると、8Bスケールでの1-bitモデルは大幅なスケールアップである。なお、UAEのFalcon-Eも2025年にbitnetsをリリースしたが、コミュニティでの注目度はBonsaiほどではなかった。
3. ベンチマーク性能 — GPT-3.5 turbo級が1GBで？
MMLU-Rで65.7、コーディングは得意だが推論・数学は弱い。「GPT-3.5 turbo級の知能が1GBで」は半分本当。
HuggingFaceページで公開されているベンチマーク結果は一見すると優秀だ。コミュニティでも「ベンチマークは良い」という評価が出ている。しかし実際のユーザー体験を踏まえた評価はもう少し複雑になる。
まず総合能力。コミュニティの検証では、Bonsai-8Bの実力は「2Bモデルと4Bモデルの間」に位置するという評価が多い。8Bモデルをベースにしているにもかかわらず、1-bit化による情報損失で実効的な能力は半分以下になっているということだ。コーディングタスクでは比較的強い結果を出す。一方で推論・数学は明確な弱点として複数のユーザーから報告されている。「Bonsai 8bモデルはコーディングには優れているが、推論や数学は得意ではない」という評価がコミュニティの共通認識になりつつある。
興味深い発見として「Qwen3.5-4BがBonsai-8Bを上回る」という結果が報告された。ただしこの比較は公平ではないという指摘もある。BonsaiのベースモデルはQwen3であり、Qwen3.5世代との直接比較は不適切だからだ。公正な比較対象はQwen3-2Bあたりになる。
「かつてのGPT-3.5 turbo程度の知能が、わずか1GBで、しかも無料で動く」——この事実にコミュニティは興奮しているが、同時にその限界も冷静に認識している。デスクトップ用途なら素直にQ4量子化の8Bモデルを使うべきで、Bonsaiの真価はメモリ制約が厳しい環境で発揮される。
4. Qwen3ベース — なぜQwen3.5ではないのか
BonsaiはQwen3-8Bをベースに1-bit化。Qwen3.5世代との直接比較は不公平。
Bonsai-8BのベースモデルがQwen3-8Bであり、最新世代のQwen3.5ではないという点は、性能評価において極めて重要なファクターだ。コミュニティでは「BonsaiはQwen3のdenseモデルがベースであり、おそらくPrismMLには独自の学習データセットすらないのではないか」という分析が出ている。つまり、PrismMLの技術的貢献は「1-bit化の手法」であり、ベースモデルの知能はQwen3から受け継いでいるという見方だ。
この事実は比較の文脈で重要になる。Qwen3.5-4BとBonsai-8Bを比較して「4Bモデルに負ける8Bモデル」と結論づけるのは不公平だ。Qwen3.5はQwen3から大幅に改善された世代であり、世代の違うモデル同士の比較は意味が薄い。公正な比較対象はQwen3-2BやQwen3-4Bであり、その枠で見ればBonsaiは相応の性能を示している。
コミュニティの期待は当然ながらQwen3.5ベースのBonsaiに向けられている。「PrismMLがQwen3.5のdenseモデルからBonsaiを作れるのは間違いないだろう」という楽観的な見方がある。Qwen3.5の基礎能力がQwen3より大幅に向上していることを考えると、Qwen3.5ベースのBonsaiが登場すれば性能は確実に跳ね上がるはずだ。
一方で「8Bモデルを1-bit化して2B〜4Bの間の性能になるなら、最初からQ4量子化の4Bモデルを使えばいいのでは？」という根本的な疑問も提起されている。この問いに対する答えは明確で、速度とメモリ効率。同じメモリ枠なら1-bitモデルのほうがパラメータ数（=知識の幅）で勝り、特にエッジデバイスではこの差が決定的になる。
5. 動かし方 — llama.cppの特定ビルドが必要
通常のGGUFとは異なるフォーマット。llama.cppの最新ビルドが必須。LM Studioでは現時点でエラー。
Bonsai-8Bを動かす際の最初の壁は、通常のGGUFモデルとは異なるフォーマットへの対応だ。量子化タイプはq1_0_g128という専用フォーマットであり、一般的なQ4_K_MやQ8_0とは互換性がない。このため、HuggingFaceのモデルページに記載されている特定バージョンのllama.cppをビルドする必要がある。
現時点で最も確実な方法は、llama.cppのソースコードから直接コンパイルすること。「descriptionに書いてあるllamacppバージョンをコンパイルする必要がある」というのがコミュニティの共通認識だ。HuggingFaceページの指示に正確に従うことが重要で、適当に最新のllama.cppを使っても動かない可能性がある。
LM Studioでの動作は現時点では問題がある。GGUFバージョンとMLXバージョンの両方で「モデルの読み込みに失敗しました」というエラーが報告されている。LM Studioの内部で使われているllama.cppのバージョンがq1_0_g128フォーマットに対応していないためと推測される。今後のアップデートで対応される可能性はあるが、現時点では生のllama.cppを使うのが唯一の確実な方法だ。
パフォーマンスの参考値として、RTX 3090での推論速度の報告がコミュニティに上がっている。1.15GBというモデルサイズを考えると、GPUのVRAMには余裕で収まるため、推論速度はメモリ帯域幅よりも演算速度がボトルネックになる場合がある。コミュニティではRaspberry Pi 5での動作テストも提案されており、本来のエッジデバイス用途での検証が進められている。Ollamaへの対応も現時点では未確認であり、メインストリームの推論スタックへの統合はこれからの課題だ。
6. Mac / Apple Siliconでの動作 — 16GB M1で余裕
1.15GBのモデルなのでMac 16GBでも余裕。マルチターンチャットも問題なし。
Apple SiliconでのBonsai-8B動作は、このモデルの「軽さ」を最も実感できるシナリオの一つだ。あるユーザーは「16GB M1 Macで動かしたが、マルチターンチャットでもほとんど負荷を感じなかった」と報告している。1.15GBのモデルサイズは、M1の16GBメモリに対してわずか7%程度しか占有しない。通常の8Bモデル（Q4_K_Mで約5GB）と比較すると、メモリフットプリントは約4分の1以下だ。
この軽さが意味するのは、MacのUnified Memoryに十分な余裕が生まれるということ。LLMの推論中でも他のアプリケーションを快適に使い続けられる。メモリ8GBのエントリーモデルMacでも理論上は動作可能であり、これは通常の8Bモデルでは考えられないことだ。
コンテキストウィンドウの65Kトークンも、このサイズのモデルとしては非常に寛大だ。ただし「小さいモデルが速く感じるからといって、長いコンテキストでのニュアンスを失っていないかどうか、正しいものを測定しているのだろうか？」という指摘もある。確かに、65Kコンテキストでの品質は8Bフル精度モデルには及ばないだろう。特にコンテキストの後半での情報保持能力（いわゆる"lost in the middle"問題）は、1-bitモデルではより顕著になる可能性がある。
それでも、MacBook Airクラスのマシンで8Bアーキテクチャのモデルをストレスなく動かせるという体験は、ローカルLLMの敷居を大幅に下げるものだ。初心者が「とりあえずローカルLLMを体験してみたい」という場合に、最も手軽な選択肢の一つになりうる。
7. エッジデバイス・ロボティクス — 本来の用途
Bonsaiの真の狙いはエッジデバイスとロボティクス。スマホ、Raspberry Pi、IoTデバイスで動くLLM。
PrismMLが明示している主要ターゲットは、ロボティクス、リアルタイムエージェント、エッジデプロイメントの3つだ。これはBonsaiをデスクトップ向けの汎用LLMと比較すること自体がミスリーディングであることを意味する。Bonsaiが本当に競合しているのは、Gemma 4やQwen 3.5ではなく、「エッジデバイスでLLMがまったく使えない」という現状そのものだ。
1.15GBというモデルサイズで動作可能なデバイスの範囲は極めて広い。スマートフォン（バジェット機を含む）、Raspberry Pi（4以降）、IoTデバイス（十分なRAMがあるもの）、組み込みシステム——これらのプラットフォームで8Bアーキテクチャクラスのモデルが動くというのは、従来の常識を覆すものだ。
ロボティクス分野では、リアルタイムの意思決定にLLMを使いたいがクラウドへのレイテンシが許容できないというケースが多い。Bonsaiならオンデバイスで推論を完結でき、ネットワーク遅延ゼロで応答が得られる。自律走行ロボット、ドローン、産業用ロボットアームなど、レイテンシがクリティカルな用途での可能性は大きい。
「これらの用途では、8Bクラスのモデルが1-2GBに収まるということが革命的」というのがコミュニティの見方だ。デスクトップ用途では品質面で通常量子化に勝てないが、「LLMが使えるか使えないか」の二択を迫られるエッジ環境では、Bonsaiは「使える」側に立てる唯一の選択肢になりうる。これは根本的に異なる市場であり、Gemma 4やQwen 3.5とは競合しない独自のポジショニングだ。
8. 公正な比較 — 同じGBサイズで何と戦えるか
1.15GBという同じメモリ枠で比較すると、Bonsaiの優位性が見える。
Bonsaiの評価で最も重要なのは「同じGBサイズのモデルと比較する」という視点だ。コミュニティでも「同じサイズ（GB）のモデル同士で比較すべき」という意見が出ており、これがBonsaiの真の立ち位置を理解する鍵になる。
1GB枠（Bonsaiの領域）: 通常のアプローチでは0.5B〜1Bモデルの量子化版（Q4）しか選択肢がない。Bonsai-8Bはこの枠で8Bアーキテクチャの知識幅を提供する。知識量とパラメータの多様性で圧倒的に有利。
2GB枠: Qwen3.5-0.8BのFP16（約1.6GB）かBonsai-8Bの1-bit（1.15GB）。この比較ではBonsaiが勝つ。0.8Bモデルでは知識量とタスク対応力に限界があるが、8Bアーキテクチャはより広い知識を保持している。
4GB枠: ここからが分岐点。Qwen3.5-4BをQ4量子化すると約2.5-3GBに収まり、この時点でBonsaiの総合性能を上回り始める。メモリに4GBの余裕があるなら、素直にQwen3.5-4B Q4を選ぶほうが賢明だ。
8GB枠以上: この領域ではBonsaiを選ぶ理由はほぼない。Qwen3-8B Q4（約5GB）やLlama 3.1-8B Q4は、あらゆるベンチマークでBonsai-8Bを上回る。
つまりBonsaiのスイートスポットは「2GB以下」の極端にメモリが制約された環境だ。デスクトップで16-24GBのVRAMがある場合は、通常のQ4量子化8Bモデルのほうがはるかに高品質。Bonsaiは「メモリが少ないほど相対的な価値が上がる」という逆説的な特性を持つモデルであり、この特性こそがエッジデバイス向けという位置づけを裏付けている。
9. Bankai（卍解）— 1-bit モデルのファインチューニング手法
PrismMLはBankaiという1-bitモデル向けのpost-training adaptation手法も発表。
PrismMLはBonsaiと同時に「Bankai」という手法を発表した。これは「真の1-bit LLMのための初のpost-training adaptation手法」と位置づけられている。名前の由来はBLEACH（ブリーチ）の卍解で、「最終解放形態」という意味が込められている。PrismMLがアニメ文化に親しいチームであることが窺える命名だ。
Bankaiの技術的な意義は大きい。従来、1-bitモデルのファインチューニングは困難とされてきた。重みが0か1しかないため、通常のgradient descentベースの学習が適用しにくい。微小な勾配更新が「0のまま」か「1のまま」に量子化されてしまい、学習が進まないのだ。BankaiはこのPost-training適応問題に対するアプローチを提供する。
これにより、Bonsai-8Bを特定タスク向けにカスタマイズできる可能性が開ける。例えば、特定のプログラミング言語に特化させたり、特定ドメインの知識を強化したり、ロボティクス向けの応答パターンを学習させたりといった用途が考えられる。
ただしコミュニティの反応はまちまちだ。一部は「1-bitモデルのファインチューニングは画期的」と評価する一方、「MicrosoftのBitNetやUAEのFalcon-Eが既に類似の領域をカバーしている」という冷静な指摘もある。技術的な詳細はホワイトペーパーに記載されているが、実際にBankaiでファインチューニングした結果報告はまだコミュニティに上がっていない。手法の有効性は今後の実証待ちという段階だ。まだ非常に初期段階であることは間違いなく、プロダクション環境での利用は時期尚早だろう。
10. 今後の展望 — Qwen3.5版とスケールアップの可能性
Qwen3.5ベースのBonsai、16B以上へのスケールアップ、エコシステムの成熟が次のステップ。
Bonsai-8Bは「1-bit LLMが実用レベルに到達しうる」ことを示した最初のモデルだが、まだ発展の初期段階にある。コミュニティが期待する次のステップはいくつかある。
第一にQwen3.5ベースのBonsai。現行のQwen3ベースからQwen3.5ベースに移行するだけで、ベースモデルの基礎能力向上分がそのまま反映されるはずだ。Qwen3からQwen3.5への改善幅は大きく、特に推論と数学——Bonsaiの現在の弱点——が強化されている。Qwen3.5-Bonsaiが登場すれば、「2Bと4Bの間」から「4Bクラス」に実効性能が上がる可能性がある。
第二にスケールアップ。8Bの次は16B以上が期待されるが、「16Bで良いベースモデルが何かわからない」という声もある。Qwen3には16Bのdenseモデルが存在しないため、別のアーキテクチャを採用するか、Qwen3.5世代を待つ必要がある。
第三にツールチェーンの成熟。LM StudioやOllamaでBonsaiが正常に動作するようになれば、技術的なハードルが大幅に下がる。現状のllama.cppソースビルドは、一般ユーザーにとって敷居が高い。
最後に実世界での検証。「有効性が証明されれば」という条件付きで、1-bitアプローチはエッジデバイスでのモデルデプロイメントの考え方を根本的に変える可能性がある。しかしデスクトップやサーバー用途では、従来の量子化手法が依然として最適解であり続けるだろう。Bonsaiの真の評価は、エッジデバイスやロボティクスの現場で実際に使われ始めてから決まる。
- PrismML公式 (GitHub) — ホワイトペーパーとデモ
- Hugging Face - Bonsai-8B — モデルのダウンロードとベンチマーク
- llama.cpp — ローカル推論エンジン（q1_0_g128対応ビルドが必要）