1bit量子化(BitNet・三値)

1bit量子化は、重み1個あたりを1ビット前後まで削り落とす極端な量子化です。実際に主流なのは -1 / 0 / +1 の三値で、情報量にすると log₂(3) ≈ 1.58ビット。当サイト収録のBonsaiがこの系統で、8Bクラスのモデルが約1.15GBに収まります。

Q4をさらに削ったものではない

ここが最大の誤解ポイントです。GGUFの Q4_K_M などは、学習済みのFP16モデルを後から丸める手法です。同じ調子で1ビットまで丸めれば、モデルは実用にならないほど壊れます。

BitNet b1.58 に代表される系統は逆で、最初から重みが三値である前提で学習します(重みは三値、活性値は8bit整数)。「圧縮した」のではなく「その形で育てた」ため、極端なビット数でも成立します。ただし1bit化の入口はこれだけではなく、既存モデルを事後に1bit化するアプローチも実在します — 当サイト収録の Bonsai 27B は Qwen3.6-27B を全層1bit化したものです。いずれにせよ専用の手法が要る点は共通で、手元のGGUFを自分でQ1に変換すれば同じものが得られる、という話ではありません。

どれだけ小さくなるのか(当サイトの実数)

Bonsai 8B は実効 1.12 bit/重み。8.19Bのパラメータで重みは約1.15GBです。同じモデルサイズを当サイト共通ラダーの Q4_K_M(4.85bit)に当てはめると約4.97GB、FP16なら約16.38GBですから、Q4比で4倍以上、FP16比で14倍以上の差になります。

判定への効き方は劇的です。Bonsai 8B は6GBのGPUで◎ですが、同じ8Bクラスの Llama 3.1 8B は Q4_K_M でも6GBでは×、8GBでようやく△です。27B級の Bonsai 27B でも重みは約3.82GB(Q4換算なら約16.84GB)で、単体GPUどころかスマホ級の射程に入ります。

当サイトが共通ラダーを当てはめない理由

他のモデルページには Q4_K_M / Q5_K_M / … と量子化ごとの必要VRAMが並びますが、1bitモデルにはその表を出しません。これらはその精度でしか存在しないモデルだからです。「もしQ8_0にしたら」という換算に意味がありません。当サイトはこれらに専用のビット数を持たせ、実際に公開されているGGUFのファイルサイズから逆算して必要VRAMを出しています。

「載る」と「動く」は別問題

1bitモデルは通常の量子化とデータの持ち方そのものが違うため、対応したランタイムが必要です。llama.cppの新しい版やMLX、Microsoftの bitnet.cpp などが該当します。当サイトが確認した時点では、Ollama と LM Studio は未対応でした。容量的に載ることと、手元の環境で実際に起動することは別なので、導入前に使っているランタイムの対応状況を確認してください。

過度な期待はしないほうがよい点

公開されている1bitモデルはまだ数が限られており、選択肢という意味では通常の4bit量子化に遠く及びません。また同じモデルでも、品質を優先した三値版が別途公開されることがあり、その場合サイズは大きくなります — 小ささと品質は依然としてトレードオフです。「同じ8Bなら1bitのほうが得」と単純化はできず、VRAMがどうしても足りない場合の選択肢、あるいはオフロードで極端に遅くなるくらいならこちら、という位置づけで考えるのが実用的です。

関連用語

• 量子化とGGUF — モデルを小さく圧縮して少ないVRAMで動かす技術。Q4_K_M などの記号の読み方
• VRAM(ビデオメモリ) — GPUに載っている専用メモリ。ローカルLLMで動くモデルの大きさを決める最重要スペック
• CPUオフロード — VRAMに載りきらない分をメインメモリへ逃がして動かす技術。動くが遅くなる

参考資料(出典)

• https://arxiv.org/abs/2402.17764
• https://github.com/microsoft/BitNet
• https://huggingface.co/microsoft/bitnet-b1.58-2B-4T

▶ あなたのPCで動くモデルを自動判定する(スペック送信なし・ブラウザ内完結)