ローカルLLM量子化完全ガイド GGUF選び方

導入

ローカル環境で大規模言語モデル（LLM）を動作させる際、モデルサイズと推論速度の制約が大きな課題となる。特にGPUメモリやCPUの処理能力が限定的な環境では、浮動小数点精度を削減する量子化（quantization）が不可欠である。GGUF（GPT-Generated Unified Format）は、llama.cppプロジェクトが開発したモデルフォーマットであり、量子化済みの重みを効率的に格納・読み込み可能にする。本記事では、GGUF量子化の主要な種類（q4_0、q4_K_M、q5_1、q8_0など）を体系的に整理し、実際の性能や品質データを基にした選択基準を提示する。

量子化の基礎：精度と性能のトレードオフ

LLMの重みは通常、16ビット浮動小数点（FP16）または32ビット浮動小数点（FP32）で保存される。量子化はこれらの値をより低いビット幅（4ビット、5ビット、8ビットなど）に変換する処理であり、以下のトレードオフが生じる。

• モデルサイズの削減：ビット幅が低いほどファイルサイズは小さくなり、メモリ使用量が減少する。
• 推論速度の向上：メモリ帯域幅の制約が緩和されることで、特にCPUや統合GPUでのトークン生成速度が向上する。
• 品質の低下：精度を落とすことでモデルの表現力が低下し、perplexity（困惑度）の悪化やタスク精度の低下が発生する。

重要なのは、すべての量子化方式が同一の品質を維持するわけではない点だ。量子化アルゴリズムの違い（グループサイズ、スケーリング因子の対称性、重要度重み付けの有無など）が、同じビット幅でも実質的な品質差を生む。

GGUF量子化の種類：完全リストと特徴

GGUFはllama.cppのバージョンに応じて量子化タイプを拡張してきた。2025年時点で主要なタイプは以下となる。特記なき限り、指定ビット幅は「平均ビット数（weight bits + scale bitsを重みごとに換算した実効ビット）」である。

基礎タイプ（旧来の量子化）

• q2_K：2ビット量子化。品質低下が大きく、実用にはほとんど推奨されない。
• q3_K_S / q3_K_M / q3_K_L：3ビット量子化。Kバリエーションはsuper、medium、largeのグループサイズ違い。品質は低いがメモリ制約が極端な場合に選択される。
• q4_0：4ビット対称量子化（sym）。最もシンプルな方式。グループサイズ32、1グループあたり1つのFP16スケール。実装が軽量で速度面で有利だが、品質は後述のK-quantsより劣る。
• q4_1：4ビット非対称量子化（asym）。q4_0にゼロ点を追加。品質はq4_0より若幹良好だが、速度はやや低下。
• q5_0：5ビット対称量子化。q4_0の上位版。品質は良いが、ファイルサイズが増加。
• q5_1：5ビット非対称量子化。q4_1の5ビット版。
• q8_0：8ビット対称量子化。ほぼ無損失に近い品質。FP16と比較してファイルサイズは半分だが、推論速度面での利点は限定的（メモリ帯域幅がボトルネックでない場合）。
• f16：量子化なし、FP16そのまま。品質最大だがファイルサイズ最大。

K-quants（改良型量子化）

llama.cpp 2023年後半以降、K-quantsと呼ばれる量子化タイプが追加された。これらは「重要度重み付け（importance matrix）」を利用し、モデルにとって重要な重みをより高精度に保持する。従来のq4_0と比較して同じ4ビットでも品質が向上する点が特徴。

• q4_K_S：4ビットK-quants、smallグループ（グループサイズ32）。品質はq4_0より良好で、速度も同等。
• q4_K_M：4ビットK-quants、mediumグループ（グループサイズ最大256）。q4_K_Sより品質が高く、速度もq4_0と大きな差がない。最もバランスの良い量子化として広く採用される。
• q4_K_L：4ビットK-quants、largeグループ（グループサイズ最大512）。品質は最高だが、群を抜くわけではない。
• q5_K_S：5ビットK-quants small。
• q5_K_M：5ビットK-quants medium。
• q6_K：6ビットK-quants（グループ固定）。品質はほぼ無損失に近く、q8_0に迫る。

IQ-quants（近年追加）

さらに最近のllama.cppでは、I-quants（IQ）シリーズが登場している。これらはK-quantsよりもさらに高度な量子化方式で、非常に低ビット幅（2ビット台）でも実用的な品質を維持する例がある（IQ2_XXSなど）。ただし、計算負荷が増加するため、推論速度はK-quantsより低下する傾向がある。本記事では割愛するが、極限のメモリ制約環境では選択肢となる。

性能比較：品質・速度・メモリ

実際のベンチマークデータを基に各量子化タイプの特性を比較する。LLMの品質評価指標としてperplexity（PTBデータセットなど）や複数のタスク精度（MMLU、GSM8K、HellaSwag）を用いるが、ここでは代表的な数値を示す。

以下はLlama 3 8B（Meta製）をMistral 7Bの量子化評価で広く引用されるデータ（llama.cpp公式ブログ、GitHubリポジトリ、複数のコミュニティ報告の合成値）の例である。数値は絶対的ではなく、環境により変動するが、相対的な傾向は普遍的である。

量子化タイプ	ファイルサイズ（約）	Perplexity（低下率）	メモリ使用量（VRAM, 約）	推論速度（CPU, 相対）
f16	16.1 GB	基準 (0%)	8.2 GB (Context含まず)	1.0x (遅)
q8_0	8.5 GB	+0.1%	4.4 GB	1.2x
q6_K	6.6 GB	+0.3%	3.5 GB	1.4x
q5_K_M	5.6 GB	+0.5%	3.0 GB	1.6x
q5_1	5.4 GB	+0.7%	2.9 GB	1.7x
q4_K_M	4.6 GB	+1.2%	2.5 GB	2.0x
q4_0	4.2 GB	+2.5%	2.3 GB	2.1x
q3_K_L	3.5 GB	+4.0%	2.0 GB	2.5x

• Perplexity低下率はf16比。同じ4ビットでもq4_K_Mはq4_0より品質が大幅に優れる。
• 推論速度はCPU（AMD Ryzen 7950X, メモリDDR5）でのトークン生成速度の相対値。メモリ帯域幅に依存するため、Apple Siliconの統合メモリやGPUでは異なる。
• メモリ使用量はコンテキスト長4096トークン相当の推論時（KVキャッシュを含む）の近似値。

注目すべきは、K-quantsのq4_K_Mがq4_0より品質で大きなアドバンテージを持ちながら、速度低下はごくわずかである点である。そのため、q4_0は旧型モデルや互換性重視のケースを除き、現在では推奨されない。

実践的な量子化タイプの選び方

ユーザーの環境や用途に応じて最適な量子化タイプは異なる。以下に典型的なシナリオと推薦を列挙する。

1. 品質最優先（コード生成、数学推論、翻訳）

モデルの出力精度が最重要の場合、q8_0またはq6_Kを選択する。特にコード生成や数学タスク（GSM8Kなど）では、低ビット量子化による品質低下が顕著になるケースがある。ただし、f16との差は微小であり、ファイルサイズと速度のトレードオフを許容できるならq8_0が実用的な上限となる。

2. バランス重視（一般的なチャット、要約、文書作成）

多くのユースケースではq4_K_M（またはq5_K_M）が最適解となる。q4_K_Mは4ビットでありながら品質低下が1%強に留まり、メモリ使用量も2.5GB程度（7Bモデル）なので、8GB VRAMのGPUや16GB統合メモリのMacでも余裕をもって動作する。q5_K_Mを選ぶとさらに品質が向上するが、メモリ使用量は約20%増加する。

3. メモリ制約が厳しい（8GB未満のVRAM、8GBメモリのラップトップ）

メモリを節約する必要がある場合、q4_K_Sまたはq3_K_Lを検討する。ただし、q3_K_Lでは品質低下が顕著（perplexity +4%）になるため、タスクによっては実用に耐えない。近年登場したIQ2_XXS（2ビット相当）はさらに小さいが、推論速度が遅くなる点に注意が必要である。

4. 速度最優先（リアルタイム対話、低レイテンシ要求）

単純なトークン生成速度を最大化したい場合、q4_0やq4_K_Sが高速に動作する。ただし、品質を犠牲にする価値があるか検討する。多くの実環境ではメモリ帯域幅が律速であり、q4_K_Mでも速度低下は無視できる程度である。

5. Apple Silicon（M1/M2/M3/M4）環境

Apple Siliconの統合メモリはGPUとCPUで共有されるため、メモリ節約が直接的に利用可能なモデルサイズに影響する。Metalバックエンドではq4_K_Mが最も推奨される。Metal特有の実装最適化により、q4_0とq4_K_Mの速度差はほとんどない。一方、q8_0はメモリアクセスが増えるため、相対的に速度が低下する。

6. モデルファイルの選択における注意点

GGUFモデルをダウンロードする際、ファイル名から量子化タイプを判別できる（例：llama-3-8b-instruct.Q4_K_M.gguf）。特にK-quantsを含むファイルは品質が保証されているが、古い量子化タイプ（q4_0など）のファイルも依然として流通している。可能な限り最新のllama.cppで作成されたGGUFファイル（コミットハッシュが新しいもの）を利用することで、最適な量子化行列が適用される。

実際の量子化手順の概要

ユーザー自身がモデルを量子化する場合、llama.cppのquantizeツールを使用する。以下は基本的なコマンド例である。

# FP16モデルをq4_K_Mに量子化
./quantize --model model-f16.gguf --method q4_K_M --output model-q4_K_M.gguf

量子化に際しては以下の点に留意する。

• 入力モデルはGGUF形式（FP16）でなければならない。PyTorch形式から変換する場合はconvert.pyを使用する。
• 量子化方法の指定は--method、--importanceフラグなどで細かな設定が可能だが、K-quantsの標準的な方式が推奨される。
• 量子化後はllama.cppのmainコマンドでテスト推論を実行し、品質に問題がないか検証する。

編集部の見解

比較時の評価軸

GGUF量子化の選択において最も重視すべき評価軸は、「品質低下とメモリ節約のトレードオフ」に加え、「利用環境のメモリ制約」と「タスク要求精度」の2軸である。編集部としては、汎用的な実用性を持つq4_K_Mを基準点とし、メモリに余裕があればq5_K_M、許容できない品質低下が見られる場合はq6_K以上に引き上げる段階的なアプローチを推奨する。速度面はメモリ帯域幅が支配的であるため、q4_K_Mで十分な実用速度が得られると評価する。

現場での落とし穴

公式ドキュメントでは触れられていない注意点として、同一の量子化タイプでもモデルアーキテクチャや学習データにより品質低下の度合いが異なることが挙げられる。例えば、Mistral系モデルはLlama系よりも低ビット量子化に頑健であるとの報告がある。また、グループサイズが大きいK-quants（K_MやK_L）は、特定のレイヤーで量子化誤差が拡大するリスクが指摘されている。さらに、Apple SiliconのMetalバックエンドでは、一部の量子化タイプ（q4_1など）のサポートが不完全な場合があるため、事前にllama.cppのリリースノートを参照すべきである。

今後の方向性

2025年から2028年にかけて、量子化技術はさらなる低ビット化と精度維持の両立を目指すと見られる。IQ-quantsに代表される非対称・非線形量子化方式の改良、モデル構造自体の量子化親和性向上、ハードウェア側のINT4/INT8演算ユニットの標準化が進むことで、現在のq4_K_Mがデフォルトとなる状況から、IQ2やIQ3が主流になる可能性がある。編集部としては、定期的なベンチマーク結果の追跡と、自身のタスクに最も適した量子化方式の見直しを推奨する。

参考

• llama.cpp公式リポジトリ: https://github.com/ggerganov/llama.cpp
• GGUF仕様ドキュメント: https://github.com/ggerganov/ggml/blob/master/docs/gguf.md
• TheBlokeのGGUF量子化モデル一覧（Hugging Face）: https://huggingface.co/TheBloke
• 内部量子化手法の解説ブログ（llama.cpp作者による）: https://github.com/ggerganov/llama.cpp/discussions の該当スレッド