量子化で27B級LLMはVRAM 16GBに載るか｜1bit・Ternary圧縮の実力と精度の代償

27B級LLMの16GB VRAM動作とは、極低ビット量子化で重みを数GBまで圧縮して載せる手法。

27B級のLLMは、1bitやTernary（三値）といった極端な量子化を使えば、重みだけならVRAM 16GBに余裕を持って載ります。PrismMLが2026年7月に公開した「Bonsai 27B」は、Qwen3.6-27Bを三値化した理想サイズ約5.9GB、二値化なら約3.9GBという公称値を掲げました（いずれもPrismML公表値・理想サイズ）。ただし「載る」と「常用に足る」は別の話。圧縮は精度の代償を伴い、長文セッションではKVキャッシュの設定が16GBに収まるかを左右します。以下では、量子化で何が起きるのかを分解し、精度がどこまで落ちるのかを事実ベースで整理します。

27B級LLMがVRAM 16GBに載るかは「量子化」で決まる

「27Bのモデルを16GBのGPUで動かせますか」という問いには、量子化を抜きに答えられません。重みが占める容量は、ざっくり言えば「1つの重みが何ビットを占めるか（bits per weight, bpw）× 重みの数」で決まります。パラメータ数が固定なら、bpwを下げるほど必要な容量は小さくなる、という単純な比例関係。ここが量子化の効きどころです。

元のQwen3.6-27Bは、FP16（16ビット浮動小数点）で保持すると約54GBを占めます（PrismML公表値・理論換算値。GGUF BF16の実重みは約51.25GBとも示されています）。単純な容量換算では16GB GPU約3.4枚分に相当する量で、RTX 5080やRTX 5060 Ti 16GBのような消費者向けカードには到底載りません。ところが同じモデルの重みを、1つあたり2ビット弱まで削れたらどうなるか。単純計算で容量は8分の1以下に縮み、数GB台まで落ちます。これが「極低ビット量子化で16GBに載せる」という発想の骨格です。

注意したいのは、Bonsai 27Bがゼロから学習し直したモデルではないという点。PrismMLの説明によれば、Bonsai 27BはQwen3.6-27Bという既存モデルをベースに低ビット表現へ作り直したもので、ネットワークの構造そのものは変えていません。層の数も、アテンションの仕組みも、ベースのQwen3.6-27Bのまま。ただし性能はFP16と同一ではなく、後述の通りベンチマークではカテゴリによって低下が見られます。

もう1つ、押さえておきたいのがQwen3.6-27Bの位置づけです。Qwen3.6-27Bは、Alibaba Qwenが2026年4月に公開した（Hugging Face公式モデルカード記載）dense（非MoE）の27Bマルチモーダルモデルです。テキストだけでなく画像・動画も扱え、コンテキスト長は262,144トークン、ライセンスはApache 2.0。denseというのは、推論時に原則として全パラメータが計算に関与するタイプを指します。一部の専門家だけが動くMoE（Mixture-of-Experts）とは別の設計です。CPUオフロードを使わずGPU内で完結させる場合は、27Bぶんの重みをGPUメモリに置く必要があります。だからこそ「27B全部を16GBにどう押し込むか」が論点になるわけです。

Bonsai 27Bとは何か（新規学習ではなく低ビット表現）

Bonsai 27Bには2つの変種があります。1つはTernary版で、各重みを{−1, 0, +1}の三値だけで表現するもの。もう1つは1-bit版で、{−1, +1}の二値で表現します。どちらもApache 2.0で公開され、画像入力への対応も引き継いでいます（PrismML公式仕様上、Bonsaiの対応モダリティはテキスト＋画像入力・テキスト出力で、Qwen3.6-27Bにある動画入力は含みません）。

パラメータの内訳は、約24.8Bが言語部分の重み、0.46Bが画像を扱うvision tower、残る2.5Bがembeddings（埋め込み）とLM head（出力層）です（PrismML公表値）。このうち量子化の主対象になるのは、行列演算が支配的な言語部分。vision towerは三値化・二値化せず、4-bit（HQQ）で本体とは別に保持され、PrismML公表の構成では画像入力時にのみロードされるため、テキストのみで使う場合は常時のVRAM負担には含まれません。この点は後述する「公称の圧縮率は言語部分だけの数値」という論点にもつながります。

1bit・Ternary圧縮の仕組みとビット内訳

三値や二値まで削ると聞くと、乱暴に丸めているだけに思えるかもしれません。実際の仕組みはもう少し丁寧です。Bonsaiの圧縮は、重みそのものを整数コードとして持ち、128個の重みをひとまとめのグループにして、そのグループごとにFP16のスケール値を1つ共有します。有効な重みは、コード（三値・二値の値）にグループ共通のスケールを掛けたもの、という形。式で書くと w_i = s_g · t_i になります（PrismML公表）。

ここでビット数の内訳を見ていきます。三値は{−1, 0, +1}の3通りなので、1つの重みが持つ情報量は log2(3) ≈ 1.585ビット。これに128重みごとのFP16スケール分（16 ÷ 128 = 0.125ビット）を足すと、平均で約1.71 bits/weightになります。FP16の16ビットと比べれば約9.4×の削減。二値の場合は情報量が1ビットちょうどで、スケール分を足して 1 + 16/128 = 1.125 bits/weight、こちらは約14.2×の削減です。

計算の骨格を並べると、次のように整理できます。

ただし現在のGGUFでは三値を2-bitスロットに格納するため、Ternaryの実配置はスケール込みで約2.125 bits/weightになります。だからこそ常駐重みサイズは理想値の約5.9GBではなく約7.2GBに膨らみます。表の約1.71は情報表現上の理論値であって、実際のファイル上のビット占有とは別物である点に注意が必要です（1-bit版は格納効率が高く、常駐重みは理想値の約3.9GBに近い約3.8GBに収まります）。

この表現は、embeddings・アテンションの各射影・MLPの各射影・LM headといった、行列演算が中心のコンポーネントに端から端まで適用されます。正規化まわりやスケールといった、ごく一部のパラメータだけが高い精度のまま残される構造。つまりモデルの大部分が極低ビットに落ちるからこそ、あれだけの圧縮率が出るわけです。

サイズの公称値もここで押さえます。PrismMLはTernary版の理想サイズを約5.9GB、1-bit版を約3.9GBと発表しました。ただしこの2つの数字は、あくまで「bpw × パラメータ数」で積んだ理想値であって、実際にGPU上で動かしたときの占有量とは別物です。この区別は次の見出しで扱います。

Bonsai 27BはQwen3.6-27Bから派生した低ビットモデルで、ネットワーク構造は維持されています。低ビット表現を得るための具体的な学習工程については、PrismMLの技術資料を参照する必要があります。

なぜ128個ごとにスケールを1つ持つのか

重みを{−1, 0, +1}の3通りに丸めるだけでは、値の「大きさ」の情報が完全に失われます。ある層では重みが小さくまとまり、別の層では大きく振れる——その振れ幅を復元する役割を担うのが、グループ共有のFP16スケールです。一般にグループを小さくするとスケールのオーバーヘッドが増え、大きくすると量子化誤差が増える可能性があります。Bonsaiは128重みに1つのFP16スケールを採用していますが、128という値を選んだ具体的な理由は公開モデルカードでは説明されていません。

「16GBに載る」の3つの意味（理想サイズ・常駐重みサイズ・実行時ピークメモリ）

「Bonsai 27Bは3.9〜5.9GB」という数字を見て、「16GBのGPUなら10GB以上も余る」と早合点すると、実機で足をすくわれます。サイズには少なくとも3つの意味があり、それぞれ値が違うからです。

1つめが理想サイズ。これは前述の「bpw × パラメータ数」で積んだ理論値で、Ternary約5.9GB・1-bit約3.9GB（PrismML公表）がこれにあたります。数字としては一番小さく出る値。

2つめが常駐重みサイズです。GGUFをロードした時点で、言語モデルの重みそのものが占める容量を指し、KVキャッシュ・活性化・ランタイムバッファは含みません。PrismMLの公表では、Ternary版が約7.2GB（より正確には約7.15GB）、1-bit版が約3.8GB（約3.79GB）。Ternaryが理想サイズの5.9GBより1GB以上大きいのは、前述のとおり三値を2-bitスロットに格納する実配置に起因します。なお、この常駐重みサイズはファイルとして保存したときの容量とほぼ一致します。PrismML公式ドキュメントはTernaryのGGUF（Q2_0）を6.66GiB、1-bitのGGUF（Q1_0）を3.53GiBと表記しますが、6.66GiBは十進換算で約7.15GB、3.53GiBは約3.79GBで、Hugging Faceのファイル一覧が示す7.17GB／3.8GBと同じ容量を単位違い（GiBとGB）で表したものです。オンディスク容量と常駐重みサイズは独立した別カテゴリではなく、ほぼ同じ数字を指しています。ストレージの見積もりにはこの値を使います。

3つめが実行時ピークメモリです。実際に推論を回すと、常駐重みにKVキャッシュ・活性化・ランタイムバッファが上乗せされます。PrismMLの公称値では、Ternary版が4Kコンテキストで約8.4GB・100Kで約14.7GB、1-bit版が4Kで約5.2GB・100Kで約11.6GB（コンテキスト別の内訳は後述の表を参照）。GPUに実際に収まるかを判断すべきなのは、理想サイズでも常駐重みサイズでもなく、このピーク値です。ここに画像入力時のvision tower（mmproj）や投機的デコード用のdrafterを使う場合は、さらに別枠が加わります。

対比として、量子化していない側の数字も並べます。Qwen3.6-27Bの通常の4-bitビルド（Q4_K_XL）は、名前こそ「4-bit」ですが、スケールなどを含めた真の平均は5.2 bits/weightで、常駐の重みサイズは17.6GB（PrismML公表）。この時点で16GBを超えており、PrismMLモデルカードが示す実行時ピークは4Kコンテキストでも約19.2GB、100Kコンテキストでは約25.6GBに達します。なお、Q4_K_XLのこのコンテキスト別ピーク値はPrismMLによる算出値であり、同カード内のTernary版・1-bit版・BF16版のような直接測定値ではない点に留意が必要です。つまりQ4_K_XLは重み単体でも16GB GPUには収まらず、実行時にはさらに余裕がありません。2-bitビルド（IQ2_XXS）でも真の平均は2.8 bits/weightの9.4GBです。「公称2-bit・4-bit」という呼び名と、実際に効いてくるbpwがズレている点は、量子化を語るうえで外せない前提でしょう。

公称サイズをそのまま必要VRAMと読まない

まとめると、こういうことです。カタログ的に一番小さく見える理想サイズだけを見て「16GBに余裕」と結論づけるのは危険。実機で必要になるのは実行時ピークメモリ（常駐重みにKVキャッシュ・活性化分を足した合計）で、これはコンテキスト長や設定次第で膨らみます。「重みは数GB」は正しくても、「実機で常に16GBに余裕」までは言い切れない、というのが正確な読み方です。ストレージの計画にはオンディスク値（＝常駐重みサイズとほぼ同値）、VRAMの計画には実行時ピークメモリを使います。数字の意味を取り違えないことが、選定を誤らないための第一歩になります。

精度の代償：圧縮で何が失われ、何が測られていないか

圧縮率の話だけなら、量子化は万能に見えます。問題は、削ったぶん何が失われるのか。PrismMLは15種類のベンチマークを思考（thinking）モードで、EvalScopeとvLLMを使いH100 GPU上で評価したと公表しています。その結果が、Ternary版はFP16ベースラインの94.6%、1-bit版は89.5%の性能を保持、というもの。数字で言うと、FP16の15ベンチ思考平均が85.07点、Ternary版が80.49点、1-bit版が76.11点です（すべてPrismML公表値）。

一見すると「9割前後を保つなら実用十分」に読めます。ただし、この精度低下はタスクによって一様ではありません。カテゴリ別に見ると、落ち幅の大きい領域と、比較的堅い領域がはっきり分かれます。堅いのはMath（数学）で、FP16の95.33点に対しTernary 93.40点・1-bit 91.66点と踏みとどまります。一方で落ち込みが目立つのがVision（画像）で、72.61点→65.19点→59.57点。Agentic and tool calling（エージェント・ツール呼び出し）も80.00点→74.01点→66.03点と、1-bit版では大きく削れます。Instruction following（指示追従）も78.47点→71.77点→65.74点、Knowledge and reasoning（知識・推論）は83.15点→76.96点→73.39点。つまり「平均9割」の内訳は均等ではなく、使いたいタスクがどのカテゴリに当たるかで体感は変わる、と読むべきでしょう。

もう1つ押さえておきたいのが、Vision towerの扱いです。前述のとおり、Bonsaiはvision towerを三値化・二値化せず、4-bit（HQQ）で別管理しています。したがって、公称の1.71bpw／1.125bpwという圧縮率は言語部分の数値であり、マルチモーダル構成全体にそのまま当てはまるわけではありません。ただし、Vision towerを4-bitに留めた理由（精度上の限界か、開発期間や実装上の選択かなど）を、公開資料だけから断定することはできません。

精度保持の主張はどこまで一般化できるか

「94.6%保持」という数字が語るのは、あくまで測った次元（PrismMLが選んだ15ベンチマークの思考モード平均）での話です。速度やサイズと違い、品質や体感、用途別の適性は測る条件で大きく振れます。参考になるのが、素朴な低ビット量子化の崩れ方。Qwen3.6-27BのIQ2_XXS（2-bit）は、思考平均こそ72.73点ですが、内訳を見るとAIME26で57.5点、LiveCodeBenchで56.4点まで崩落する一方、MMLU-Reduxでは88.93点を維持します（PrismML公表）。短い問題を答えるベンチだけ見ていると崩壊が見えず、長い推論やコード生成で初めて破綻が表面化する、という構図。同じ崩れ方はGemma-4-31B Q2_K_XLでも再現するとされます。

Bonsaiは、単純な事後量子化（IQ2_XXS等）より高い保持率を実際に示しています。それでもVisionやAgenticでは数値上、比較的大きな低下が見られる以上、「あらゆるタスクでFP16と同等」とまでは言えません。載るかどうかを容量だけで判断せず、自分が回したいタスクがどのカテゴリに近いのかを一度当てはめてから——それが極低ビット量子化と付き合う実際的な構えになります。

長文で律速するKVキャッシュ（262Kコンテキストの落とし穴）

重みが数GBに収まっても、それだけで「16GBに載る」とは言い切れません。長い入力を扱うとKVキャッシュがコンテキスト長に比例して膨らみ、16GBの実制約はここで表面化します。

Qwen3.6-27Bはコンテキスト262Kトークンに対応し、アテンションの約75%（64層中48層）が線形のため長文でも実用的に保てます。ただしPrismMLの公表値では、full-attentionキャッシュを持つのは64層中16層。FP16換算で約64 KiB/token、262K窓なら約17.2GBに達し、4-bit KVキャッシュに落として約4.3GBまで削れる計算。4-bit KVキャッシュを使った場合の262Kコンテキストでのモデル全体ピークは、PrismML公表値でTernary版が約12.8GB、1-bit版が約9.4GBです。100Kトークン・FP16キャッシュ時のピークメモリは1-bit版で約11.6GB、Ternary版で約14.7GBというのがPrismMLの示す数字です。この数値はいずれも言語モデル部分のみで、画像入力時のvision tower/mmprojや投機的デコード用のdrafterは含みません。それらを使う場合は別途VRAMが加わります。

つまり常駐重みが約3.8〜7.2GBに収まっても、FP16のKVキャッシュでコンテキストを伸ばすと、残りのVRAMを大きく消費します。一方、4-bit KVキャッシュに落とせば、前述のとおり262KでもモデルをTernary版約12.8GB、1-bit版約9.4GBに抑えられる計算です。実機（RTX 5080単体等の16GB GPU）でも、モデルをロードした直後のGPU全体使用量（nvidia-smi memory.usedで確認できる）と、コンテキストを伸ばした後の使用量では水準が変わります。実機で長文を回すなら、num_ctxを絞るか、KVキャッシュの量子化を前提にするのが現実的でしょう。

llama-server -m Ternary-Bonsai-27B-Q2_0.gguf -c 4096 -ngl 99 --flash-attn on --cache-type-k q4_0 --cache-type-v q4_0

「重みが収まる」と「262Kの長文が回る」は別問題。この線引きを外すと、公称サイズだけ見て安心する典型的な失敗に陥ります。量子化KVキャッシュを使う場合、llama.cpp公式ドキュメントによれば--cache-type-v の指定にはflash attention（-fa on）の有効化が前提になります。実機で試す際は押さえておく必要があります。なお、PrismMLの4-bit KVキャッシュは現時点ではllama.cpp向けの実験的機能で、FP16 KVよりデコードがやや遅くなり、わずかな品質低下を伴う可能性があります。このコマンドはPrismML forkまたはQ2_0_g128対応済みのllama.cppビルドで、対象ファイルを取得済みであることが前提です。ファイル名・対応バックエンドはビルドやフォークによって異なるため、実行前にPrismML公式配布（Hugging Faceモデルカードまたは公式デモリポジトリ）で最新のファイル名を確認してください。

VRAM階層で見る早見表：8GB〜32GBで何が載るか

同じ「載るか」でも、VRAM容量ごとに現実的な選択肢は変わります。一般的な量子化目安として、階層別に整理しました（12GB帯のGemma 4 12Bのみ当サイト実測値を併記）。以下はいずれも短〜中コンテキスト・単発推論・代表的なQ4量子化を前提にした目安で、長文・並列実行・Vision入力・KVキャッシュ量子化なしでは必要VRAMが増えます。

16GBは27B級Denseを載せる最低条件ではありません。PrismML公称のピークメモリは次のとおりです（言語モデルのみ、Vision・drafter・OSや画面表示用のVRAMは含みません）。

公称値上は1-bit版なら短いコンテキストで8GBにも収まり、Ternary版も短いコンテキストなら12GBに収まります。16GBは最低条件ではなく、Ternary版を短〜中コンテキストで扱いやすい容量帯です。公称値上は100Kでも収まりますが、約14.7GBに達するため実機の安全マージンは小さくなります。一方、素の4-bit 27B（Q4_K_XL＝実効5.2bpw・17.6GB）は16GBにわずかに収まらず、1bit／Ternaryなら重みが余裕で載る、という対比自体は変わりません。

対極の巨大MoEと、載せた後に速く回す環境

Bonsaiの逆方向にあるのが巨大MoEです。総パラメータ数百B級のモデルは、GPU内に全重みを常駐させる構成では活性化パラメータが一部でも総重み分のVRAMが必要になるため、単体のコンシューマVRAMには量子化しても載りにくくなります（一方、30B-A3B級など比較的小型のMoEは、量子化タグ次第で24GB級以上のGPUなら扱える場合があります）。MoEの「一部だけ動かす」構造が縮めるのはトークンあたりの計算量であって、VRAM占有そのものではありません。VRAM占有を削る量子化とは別軸の手段であり、Dense 27Bを極限まで削る本記事の方向とは、解決している問題自体が違います。

載せた後の実効性能は、ランタイムとOS・ドライバにも左右されます。Bonsaiはllama.cpp（GGUF）やApple MLXでの動作が案内されており、PrismMLの公表値では1-bit版がApple M5 Proで約44.2 tok/s、H100で約104.8 tok/sという開きです。同じ重みでも、実行環境によって速度は変わります。

まとめ

27B級Denseは、1bit／Ternaryの極低ビット表現なら、言語モデルの常駐重みを約3.8〜7.2GBに抑えられます。実行時ピークは4Kコンテキストで約5.2〜8.4GB、100Kでは約11.6〜14.7GBまで増加します。ただし「載る」は理想サイズ・常駐重みサイズ・実行時ピークメモリの3つを切り分けて読む必要があり、精度保持率94.6%／89.5%はいずれもPrismMLの自己申告です。VisionやAgenticでは数値上、比較的大きな低下が見られます。さらに長文では、16GBに収まるかどうかはKVキャッシュの精度設定（FP16か4-bit量子化か）次第です。なお16GBなら多くの14B級（Q4）は短〜中コンテキストであれば扱いやすいところに収まります。それでも27Bを極低ビットで狙う価値があるのは、精度低下を許容してでも27Bベースモデルの能力特性やマルチモーダル対応が必要な用途に限られます。容量で可否を判断する前に、自分が回すタスクのカテゴリとコンテキスト長を当てはめる——それが極低ビット量子化との現実的な付き合い方です。

よくある質問

Q. 1bit量子化で精度は実用に耐えますか？

PrismML公表値では1-bit版がFP16の89.5%を保持しますが、これは思考モード・特定15ベンチの平均です。VisionやAgentic/tool callingでは数値上、比較的大きな低下が見られるため、タスク次第。実務投入前にご自身の用途で確認するのが安全です。

Q. 16GBあれば262Kの長文も動きますか？

重みは載りますが、262K・FP16キャッシュ時はKVキャッシュだけで約17.2GB（PrismML公表値）に達し、重みを載せる前に16GBを超えます。100Kトークンでも、Ternary版のモデル全体の実行時ピークは約14.7GBに達し、16GB GPUの余裕はほぼ消えます。16GBで262Kコンテキストを使うなら、4-bit KVキャッシュ（約4.3GB）への量子化が前提です。FP16 KVキャッシュを使う場合は、コンテキスト長を短くする必要があります。

Q. Ternaryと通常の4bitは何が違いますか？

Ternaryは{−1,0,+1}の三値で、情報表現上は約1.71bpwです。ただし現行GGUFの実配置は約2.125bpwで、常駐重みは約7.2GBになります。素の4bit（Q4_K_XL）は実効5.2bpwで17.6GBと16GBに収まりません。BonsaiはQwen3.6-27Bから派生し、ネットワーク構造を維持したまま重みを低ビット表現にしたモデルです。低ビットモデルを得るための具体的な学習工程については、PrismMLの技術資料を確認する必要があります。

参考資料

• PrismML公式発表: Announcing Bonsai 27B
• PrismML: Ternary Bonsai 27B (GGUF) – Hugging Face model card
• PrismML: Bonsai 27B (GGUF, 1-bit) – Hugging Face model card
• Qwen: Qwen3.6-27B 公式モデルカード – Hugging Face
• MarkTechPost: PrismML Releases Bonsai 27B（補足記事）
• NVIDIA: GeForce RTX 5080 公式仕様