AI
Bonsai2の約1.76bit量子化 — 270億パラメータのモデルを6GB弱に圧縮する三値量子化
2026/09/17
27Bモデルが6GB弱に収まる、という報告
独立系の機械学習プロジェクト「PrismML-Eng」が公開している「Bonsai 2（27B）」は、270億パラメータの言語モデルを、重み1つあたり約1.75ビットという極端な低ビット量子化で圧縮し、GGUF形式のPTQ1_0パッキングで約6GB弱（プロジェクト側の資料では5.9GB前後）まで縮小したと報告しているモデルである。本記事のタイトルにある「約1.76bit」は、この1.75ビット/重みという数値にほぼ対応する。
通常、FP16（16ビット）で保持されるモデルをそのまま27Bパラメータで動かそうとすれば、重みだけで50GBを超えるメモリが必要になる。それが1桁近く圧縮されている計算になる。
「三値量子化」という手法
Bonsai 2が採用しているのは、重みを-1・0・+1という3つの値のいずれかに限定して表現する「三値（ternary）量子化」と呼ばれる手法である。理論上、3つの値のいずれかを表すのに必要な情報量は約1.585ビットであり、そこにグループ単位のスケーリング係数などを加味した結果として、実装上は約1.75ビット/重みという数値に落ち着いている。
Bonsai系のモデルカードによれば、量子化の前段階で「ブロック単位のアダマール回転」と呼ばれる変換を重みに適用し、推論時には対応する変換を活性化値側にも施すことで、通常であれば精度が大きく崩れやすい極端な低ビット領域でも、三値量子化の安定性を保ちやすくする工夫が施されているという。
なお、この三値量子化という考え方自体は、Microsoft Researchが2025年に発表した「BitNet b1.58」など、複数の研究機関がここ数年取り組んできた1ビット台のLLM研究の延長線上にあるものであり、Bonsai 2固有の発明というわけではない。
なぜコンピューターの中に「-1」という値が存在できるのか
「コンピューターは0と1でしか動かないはずなのに、なぜ-1という値が出てくるのか」と疑問に思う読者もいるかもしれない。ここは誤解されやすい部分なので補足しておきたい。
トランジスタのオン・オフという物理的な層では、確かに0と1の2状態しか存在しない。しかし-1は、その0/1の並びに対して「これは-1という意味だと扱う」という解釈上の約束事にすぎない。これは目新しい話ではなく、どんなプログラミング言語で使う普通の負の整数（int x = -5;など）も、内部的には特定のビットパターンを「二の補数表現」という規則で負の数として解釈しているだけであり、CPUに「マイナス専用の特別な回路」があるわけではない。
三値量子化の場合も同じで、例えば2ビット（00・01・10・11の4通り）のうち3通りを使い、「00なら0」「01なら+1」「10なら-1」とソフトウェア側で決めて解釈しているだけだ。計算するときは、そのビットパターンを見て「+1なら足す」「-1なら符号を反転して足す（引く）」「0ならそもそも計算に参加させない」という単純な分岐処理に置き換えている。掛け算という重い演算を、足し算・引き算・スキップという軽い演算に変換できることが、三値量子化が計算コストの面でも有利になる理由である。
性能はどこまで保たれているのか
プロジェクト側の資料では、Bonsai 2 27BがFP16のオリジナルモデル比で「98.2%の性能を維持している」と主張されている。数学ベンチマークではFP16との差が0.5点以内、コード生成ベンチマークでもほぼ同等のスコアを維持しているという。
ただし、これらの数値はプロジェクト自身が公開しているモデルカードに基づくものであり、独立した第三者機関による査読や再現実験を経た数値ではない点には注意が必要だ。PrismML-Engは大手AI研究機関ではなく、コミュニティベースの独立プロジェクトであり、報告されている性能維持率についても、評価に使ったベンチマークの選び方や条件によって数値が変動しうる。実運用を検討する際は、自身のタスクで実測して確認することを強く推奨したい。
ビット数を減らすほど危険、という単純な話ではない
「ビット数を減らせば減らすほど、性能は比例して落ちていく」と考えがちだが、実際の劣化のしかたは坂道のようになっている。
- 16bit → 8bit → 4bit：ほぼ無傷（安全地帯。本誌の量子化記事の実測で1%未満の劣化）
- 4bit → 3bit → 2bit：ここから徐々にリスクが高まる
- 2bit → 1bit台：三値量子化のような特別な工夫をしないと崩れやすい
4ビット程度までは多くのモデルで安全に圧縮できるが、そこから先はモデルごとの個体差も大きくなる。特にパラメータ数が少ない小型モデルは、大型モデルに比べて元々の情報の冗長性が少ないため、同じビット数でも劣化が目立ちやすい傾向が指摘されている。「4ビットでもかなり劣化する印象がある」という体感は、こうした小型モデル特有の傾向として説明がつくことが多い。
Bonsai 2の結果は、他のモデルにそのまま適用できるとは限らない
「Bonsai 2は1.75ビットまで削って性能を維持できた。それなら同じ手法を他のモデルに使っても、同じように性能を維持できるはずだ」と考えたくなるが、これは保証されない。
理由は、Bonsai 2が採用しているのが**すでに学習済みのFP16モデルを、後から三値まで圧縮する（PTQ = Post-Training Quantization）**という、難易度の高いアプローチだからだ。これに対し、Microsoft Researchの「BitNet b1.58」は、最初から三値であることを前提にモデルをゼロから学習させるという、まったく異なるアプローチを取っている。一般的に、低ビットを前提に最初から鍛えたモデルの方が、学習済みのモデルを後から削るよりも性能を維持しやすいとされる。
つまり、「Bonsai 2がこの特定のベースモデル・この特定の量子化アルゴリズムでうまくいった」という事実は、ベースモデルの性質やキャリブレーションデータの質、量子化アルゴリズムの実装が変われば、同じようにうまくいく保証にはならない。これも、独立した第三者検証を待つべき理由の一つである。
「1.76」という数字自体に特殊な意味はない
念のため補足しておくと、「1.76」という数字そのものに何か特別な技術的ブレークスルーが宿っているわけではない。これは、「重みを3つの値（-1/0/+1）だけに制限する」と決めた時点で、情報理論的にほぼ自動的に導かれる値（log₂3 ≈ 1.585ビット）に、スケーリング係数などの実装上の付加情報を足し合わせただけの、結果として出てきた数字にすぎない。特殊なのは1.76という数字ではなく、その少ない選択肢でもモデルが機能し続けるように工夫された、アダマール回転やキャリブレーションといった周辺技術の方である。
なぜこの技術が注目されるのか
三値量子化のような極端な低ビット圧縮が実用レベルに近づいてきていることは、「大規模モデルの知識・性能を保ったまま、より小さなハードウェアで動かしたい」というニーズに直結する。Bonsai 2のケースでは、27Bという中規模のモデルが6GB弱まで縮むことで、8GB程度のVRAMを持つコンシューマー向けGPUでも、より大きなモデルの知識量を活かせる可能性が生まれる（関連: 本誌「ローカルLLMに出来るモデル、8GB GPU編」）。
実際に試すにはどうすればいいか
三値量子化モデルを動かすには、通常のGGUF形式のモデルと同様にllama.cppベースの実行環境が必要になる。ただし、三値量子化は一般的なQ4_K_Mのような量子化形式とは内部表現が異なるため、対応していない古いバージョンの実行環境では正しく動作しない点に注意が必要だ。導入を検討する場合は、配布元が案内している対応バージョンのllama.cpp（またはそのフォークされた対応版）を使うことが前提になる。また、量子化パッキング形式が複数存在する（PTQ1_0やPQ2_0など）ため、自分の実行環境がどの形式に対応しているかを事前に確認する必要がある。
こうした「専用の実行環境が必要」という制約自体が、三値量子化がQ4_K_Mのような標準的な4ビット量子化ほど手軽に普及していない理由の一つでもある。一般的な用途であれば、まずは本誌の量子化解説記事で扱った標準的なQ4_K_M量子化を試し、それでもハードウェアが足りない場合の選択肢として三値量子化を検討する、という順序が実務的だろう。
限界と今後
一方で、極端な低ビット量子化は、量子化手法やキャリブレーションデータの質によって結果が大きく左右されやすい領域でもある。今後、独立した第三者評価やより幅広いベンチマークでの検証が積み重なることで、この種の技術がどこまで実用の主流になるかが見えてくるだろう。