ローカルLLM量子化（Quantization）ガイド 10選 — GGUF/EXL3/AWQの選び方
ローカルLLMの量子化まわりで「結局どれ選べばいいの？」と迷ったときに見返す用。
1. 大原則：量子化した大きいモデル ＞ フル精度の小さいモデル
量子化についてまず押さえておくべき最重要ルール。同じVRAM予算なら、小さいモデルをFP16で動かすより、大きいモデルを量子化して動かした方が良い結果になる。
ただし下限がある。4-bit未満には落とすな。Q3以下になると、特にコンテキスト追従やニュアンスの面で目に見えて劣化する。「quantized larger model wins every time, just don't go below 4bit」というのがコミュニティのコンセンサス。
24GB VRAMで9B FP16を動かすか、27B Q4_K_Mを動かすか迷ったら、基本的には後者を選ぶ。
⚠️ この記事の情報は2026年3月時点のものです。 AI/LLM分野は変化が極めて速いため、モデル名・推奨設定・ベンチマーク値などは記事作成時点から変わっている可能性があります。最新情報は各公式ドキュメント等で確認してください。
2. Q4_Kがスイートスポット
量子化レベルの選択で迷ったらQ4_K_Mを選んでおけば間違いない。品質とサイズのバランスが最も良く、コミュニティでの標準的な推奨。
もう少し品質を上げたければQ4_K_XL（Unslothが提供）という選択肢もある。Q4_K_Mより若干大きくなるが、その分品質が改善される。逆にVRAMが厳しければQ4_K_Sもあるが、Mとの差はわずかなのでMを推奨。
Q5_K_MやQ6_Kに上げるとさらに品質は良くなるが、VRAM消費も増える。Q4_K_Mが「まず試す」レベルとして最適。
3. MoEモデルは量子化に弱い。小型モデルも同様
すべてのモデルが量子化に同じように耐えるわけではない。MoE（Mixture of Experts）モデルは密（Dense）モデルより量子化の影響を受けやすい。エキスパートごとのルーティングが量子化ノイズで乱れるためと考えられている。
また小型モデル（0.8B、2B）をQ4にするのは「would suck hard」。パラメータ数が少ないモデルほど、各パラメータが担う情報量が多いので、精度を落としたときのダメージが大きい。小型モデルを使うならQ6_K以上、できればQ8_0かFP16で動かすのが無難。
大型モデル（27B以上）ほど量子化耐性が高い。これはTip 1の「大きいモデルを量子化しろ」とも整合する。
4. FP8はほぼロスレス。Q8_0は許容範囲。4-bitからは明確に劣化
ベンチマークで見ると、FP8はFP16と比較してほぼロスレス。実用上の差を感じることはまずない。VRAM半減でこの品質はありがたい。
Q8_0も許容できるミドルグラウンド。FP8ほどではないが品質低下は最小限。VRAMに余裕があるならQ8_0を選ぶ価値はある。
一方ですべての4-bit量子化（Q4_K_M含む）はベンチマーク上で有意な品質劣化が確認されている。Tip 2で「スイートスポット」と書いたのはあくまで品質とサイズのトレードオフとしての話で、品質だけで言えばQ4は妥協している。VRAM制約の中で実用的に最善、という意味。
5. Unsloth量子化を使うなら最新版をダウンロードせよ
Unslothの量子化は現在のコミュニティ標準のひとつだが、注意点がある。
まずimatrix（importance matrix）のキャリブレーションデータが品質に大きく影響する。特にtool-calling（関数呼び出し）やlong context（長文脈）でimatrixの有無・品質が効いてくる。Unslothは継続的にキャリブレーションを改善しているので、古いバージョンを使い続けるのは損。
Q4_0/Q4_1は「quite inaccurate and has a much higher KLD/PPL」 とされている。Q4_K系と比べて同じ4-bitでもかなり精度が劣る。Q4_0は避けてQ4_K_Mを使うこと。
HuggingFaceからダウンロードする際、キャッシュされた古いバージョンではなく最新のGGUFを取得するように注意。リポジトリが更新されていても、ローカルキャッシュが古いままということがある。
6. GGUF：最もポータブルな標準フォーマット
GGUFはllama.cpp、Ollama、LM Studioなど主要なローカル推論ツールすべてで使える標準フォーマット。迷ったらGGUFを選んでおけば間違いない。
特徴：
- 最も広い互換性: CPU推論、GPU推論、CPU+GPUハイブリッドすべてに対応
- IQ（Importance Quantization）バリアント: IQ4_XSなど、通常のQ4より賢い量子化方式も利用可能
- HuggingFaceからダウンロード: ほとんどのモデルがGGUF版を公開している。Unslothやbartowskiなどの変換者がメジャーモデルを素早くGGUF化してくれる
GPU 100%オフロードできる場合はEXL3の方が速いこともあるが、「とりあえず動かす」ならGGUFが一番手軽。
7. EXL3（ExLlamaV3）：同じBPWでGGUFより高品質な場合がある
EXL3はExLlamaV3で使われる量子化フォーマットで、TabbyAPIなどと組み合わせて使う。
GGUFと比較したときの利点：同じBPW（bits per weight）で品質が上回るケースがある。特にGPU完全オフロード環境では推論速度も速い。ExLlamaの最適化されたカーネルの恩恵。
ただしGGUFほどエコシステムが広くない。llama.cppやOllamaでは使えない。GPU VRAMにモデル全体が収まる環境で、かつTabbyAPIやExLlamaベースの推論サーバーを使える場合に検討する価値がある。
8. KVキャッシュ量子化：推論モデルではBF16を死守せよ
モデル本体の量子化とは別に、KVキャッシュの量子化も重要なトピック。KVキャッシュを量子化するとVRAM使用量を大幅に減らせるが、品質への影響がある。
推奨レベル：
- BF16: 推論（reasoning）モデルではこれ一択。「I really wouldn't quantise the kv cache on a reasoning model if I could possibly help it」
- Q8_0: 許容範囲。非推論モデルならこれでOK
- Q4以下: 品質劣化が顕著。特にthinking/reasoning系モデルでは思考チェーンが崩れる
推論モデル（DeepSeek-R1系、Qwen3.5の思考モード等）は内部で長い思考チェーンを生成するため、KVキャッシュの精度が思考品質に直結する。ここをケチると「考えているフリをしているだけ」になりかねない。
9. VRAM計算：モデルサイズ + コンテキストのKVキャッシュ
VRAMが足りるかどうかの計算式はシンプル：
必要VRAM ≒ モデルサイズ + (コンテキスト長 × 1トークンあたりのKVキャッシュバイト数)
例えばQwen3.5-27Bの場合、KVキャッシュは1トークンあたり約24KB。つまり：
| コンテキスト長 | KVキャッシュ | モデル（Q4_K_M） | 合計 |
|---|---|---|---|
| 4K tokens | ~96 MB | ~17 GB | ~17.1 GB |
| 8K tokens | ~192 MB | ~17 GB | ~17.2 GB |
| 16K tokens | ~384 MB | ~17 GB | ~17.4 GB |
| 32K tokens | ~768 MB | ~17 GB | ~17.8 GB |
| 64K tokens | ~1.5 GB | ~17 GB | ~18.5 GB |
| 128K tokens | ~3 GB | ~17 GB | ~20 GB |
短いコンテキストならKVキャッシュは無視できるが、長文脈を使うとじわじわ効いてくる。「モデルは載ったのに、コンテキスト伸ばしたらOOM」は量子化あるある。
10. 9B BF16が量子化27Bに勝つケースもある
Tip 1で「大きいモデルを量子化しろ」と書いたが、例外がある。数学やコード生成など精度が命のタスクでは、9B BF16が量子化27Bを上回ることがある。
量子化の影響は「フリンジケース（境界的なケース）」ほど大きくなる。日常会話やシンプルなQAでは差が出にくいが、複雑な数式の推論や厳密なコード生成では量子化ノイズが致命的になりうる。
そしてここでbenchmaxing問題も絡む。公開ベンチマークのスコアはモデル選択の参考にはなるが、ベンチマークに最適化された数値は実タスクでの性能を保証しない。結局のところ自分のユースケースで実際にテストするのが一番確実。他人のベンチ結果を鵜呑みにしない。
おわりに
ざっくりまとめると：
- まず試すなら: Q4_K_M（GGUF）。これが事実上の標準
- 品質を優先するなら: Q8_0かFP8。VRAMが許す限り精度を上げる
- 推論モデルを使うなら: KVキャッシュはBF16で。ここだけはケチらない
- GPU完全オフロードできるなら: EXL3も検討する価値あり
- 小型モデル（2B以下）には: 強い量子化をかけない。Q6_K以上で
- Unslothの量子化は: 最新版を使う。古いキャッシュに注意
量子化は「VRAMとの戦い」であると同時に「品質との妥協点探し」でもある。自分の環境とユースケースに合わせて最適解を見つけるしかない。ベンチマークは参考程度に、実際に試して判断を。
最終更新: 2026-03-29