GGUF量子化：どのレベルを選ぶべきか？

デフォルトはQ4_K_M。VRAMに余裕があり、品質の最後の数%が要るならQ6_KかQ8_0へ。 GGUF量子化はモデルの重みを16bitから少ないbitへ縮めます——Q4_K_Mは重みあたり約4.85bitで、7Bモデルは~14 GBから~4.1 GBに落ち、パープレキシティの悪化は典型的に1%未満です。「どのgguf量子化を使うべきか」の答えは退屈なほど安定していて、ネット上のドラマの大半はそれを隠しています。以下、量子化が重みに実際何をするか、レベルごとの品質コスト、サイズ計算のやり方、そして他人のベンチマークを信用せず自分のハードウェアで被害を測るコマンド1つです。

GGUF量子化は実際何をしている？

モデルは16bit浮動小数点（FP16かBF16）で学習されています: 数十億ある重みの1つ1つが2バイトの数値です。量子化は各重みをより少ないbitへ圧縮します。素朴なやり方——全重みを4bit整数へ丸める——は小さいけれど重要な値を壊してしまうので、GGUFは2つの工夫を使います:

1. ブロックスケーリング。 重みをブロック（通常32個）にグループ化し、各ブロックに専用のスケール係数を与えます。4bitの値はブロック内のオフセットなので、広い大きさの範囲が生き残れます。
2. 重要度対応のk-quants。 Q4_K_Mの「K」はスケールのスーパーブロックを意味し、さらにattention層とfeed-forward層を別扱いします——圧縮への耐性が層ごとに等しくないためです。

「I」ファミリー（IQ4_XSなど）は画像圧縮から借りた情報理論のコードブックでさらに進みます。発想は同じ、符号化が凝っている: 同程度の品質で重みあたりのbitを減らし、代償は一部のバックエンドでわずかに遅い推論です。

ほとんどの混乱を防ぐ釈明が1つ: 量子化が変えるのは保存された重みだけです。アーキテクチャ、トークナイザ、コンテキスト処理には触れません。同じモデルのQ4ファイルとQ8ファイルは、別のコートを着た同じモデルです。

Q4 vs Q8：量子化は高い方が良い？

技術的にはイエス、体感ではノー。llama.cpp自身のLlamaモデルのパープレキシティ実測を基準にすると: Q8_0はFP16の~0.02%以内——実用上はロスレスです。Q6_Kはほぼ区別不能。Q4_K_Mは約1〜2%のパープレキシティ増、Q4_0はやや多く、Q2_Kは小さいモデルで一貫した回答が崩れ始める水準です。

数字が導く2つのルール:

• モデルサイズが量子化の余地を買う。 70Bモデルは7BモデルよりQ2/Q3にはるかに耐えます——大きなモデルほど冗長だからです。7BをQ2にするのは切断、70BをQ3にするのは仕立て直しだ。
• 品質の下限はタスクと共に動く。 チャットはQ4に耐えます。正確なコード生成、数学、精密ドキュメント上のRAGは量子化ノイズを早く露出します。Q4モデルが微妙に間違ったコードを書き続けるなら、モデルを責める前に同じモデルをQ6_Kで試してください。

レベル	bit/重み	FP16比サイズ	品質劣化	使う場面
Q2_K	~3.4	~21%	13B未満では深刻	他に収まるものがない、大モデル限定
Q3_K_M	~3.9	~25%	目に見える	VRAMが厳しい、≥14Bモデル
Q4_K_S	~4.6	~29%	小さい	Q4_K_Mが収まらず、差が僅かなとき
Q4_K_M	~4.85	~30%	~1%パープレキシティ	デフォルト。品質/サイズの最適点
Q5_K_M	~5.7	~35%	~0.5%	VRAMあり、品質重視のタスク
Q6_K	~6.6	~41%	ほぼゼロ	コード/数学、まだ余裕を持って収まる
Q8_0	~8.5	~53%	実質なし	リファレンス実行、ファインチューニングのベース
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_Mが僅かに大きい、バックエンドがi-quant対応

レベルごとにどれだけVRAMが要る？

表を暗記するより、サイズ計算は自分でやる方が早い——1行です:

size_GB ≈ (bits_per_weight × params) / 8
# 8Bモデル @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8Bモデル @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

次に、式が外に置いた部分を足します: KVキャッシュ（コンテキスト長と共に伸びる——数百MBから数GB）、アクティベーション、computeバッファ。実用的なマージンはこうです: 「4.9 GB」のモデルは4kコンテキストで6 GBカードを欲しがり、16kでそこに留まるにはflash-attentionとKVキャッシュ量子化が要ります。重みは見出しであって、請求書の全体ではありません。

どのGGUF量子化を使うべき？

決定順序です。暗記に値する例外はありません:

1. まずコンテキスト + KVの予算を計算し、それから重み。 収まらないコンテキストは、測れない品質より悪い。
2. デフォルトはQ4_K_M。 コミュニティのデフォルトであるのには理由があります——サイズの70%で約1%のパープレキシティ。Ollamaのレジストリを含む全レジストリがこれをベースラインとして出荷します。
3. タスクがノイズを罰するならQ6_Kへ一歩上がる。 コード、数学、抽出、パイプラインへ無人で流すもの全てです。
4. Q8_0はリファレンス専用 —— A/Bテスト、量子化被害の測定、ファインチューニングのベース。日々の相棒にしては、VRAMセンサーの表示を温める以外の役に立たないことが多い。
5. Q4未満は窮迫時のみ、かつ大モデル限定。信用する前に、既知の難プロンプトで試す。

Hugging Faceでどのファイルを落とすか選んでいるなら、アップローダがsharded分割しか出していないのでない限り、単一の Q4_K_M.gguf を選ぶ方がいい——可動部が少ない方がいい。そしてどこで動かすかを選んでいるなら、エンジンの選択は別の軸です: llama.cpp vs Ollama をどうぞ。

量子化の被害を自分で測るには？

ベンチマークはバラバラ、あなたのプロンプトは一定です。llama.cppを一度ビルドし、同じモデルの2レベルをダウンロードし、パープレキシティ（低いほど良い）とtokens/秒の両方を測ります:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# wiki-textのチャンクでのパープレキシティ（低い = 元モデルに近い）
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# 同じハードウェアでの速度も
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Q4_K_Mの数字はQ8_0より数百分の一ポイントほど悪く、ファイルは~40%小さい。下流のタスクが違いを言い当てられないなら——大半は言い当てません——誰かのリーダーボードを読まずに答えは出ています。

量子化はプライバシーやローカル完結の主張を傷つける？

いいえ —— 重みへの算術で、完全にオフライン、量子化済みファイルは同じパラメータのより小さい容器にすぎません。Q4_K_Mをローカルで動かす漏れは、フル精度モデルをローカルで動かす漏れと正確に同じ（つまりゼロ）です。マシンから何も出ていきません。プライバシーに関係する変数は推論がどこで走るかであって、bit幅ではありません。モデルの出所に関するいつもの注意は、全量子レベルに等しく当てはまります: 盗んだベースの「uncensored」ファインチューンがQ8でも、同じ重みのQ4より安全なわけではありません。ファイル形式側の話は how to run GGUF models locally をどうぞ。

どのレベルを選ぶべき？

Q4_K_M、そしてフォーラムを読むのをやめる。 VRAMが許せば精度の飢えた仕事にはQ6_Kへ、A/B比較用にQ8_0を1つキープ、Q4未満は大モデル限定の非常食として扱う。避ける価値のある唯一の過ちは対称形です: Q4対Q5を心配しながらコンテキスト長を無視すること——こちらがローカルセットアップを壊す件数は、どの量子化も足元にも及びません。