ローカルLLM量子化・VRAM最適化 完全ガイド【2026年版】｜GGUF・AWQ・GPTQ・EXL2の違いと選び方——「このGPUで動く最大のモデル」を見極めてOllama・vLLM・llama.cppで最大性能を引き出す
目次
- はじめに——「動くけど遅い」の原因は量子化の選び方にある
- 量子化とは何か——30秒で理解する基本原理
- 4大フォーマット徹底解説——GGUF・GPTQ・AWQ・EXL2
- GGUFの量子化レベル完全早見表——Q2からQ8まで何が違うのか
- 品質劣化の実態——量子化レベル別ベンチマーク比較
- 「このGPUで動く最大のモデル」早見表
- 実行環境別の最適フォーマット選択——Ollama・vLLM・llama.cpp・ExLlamaV2
- 実践：量子化モデルの入手と実行手順
- 量子化品質を上げるテクニック——imatrix・キャリブレーション・KVキャッシュ量子化
- よくある質問（Q&A）
- まとめ——量子化は「妥協」ではなく「最適化」
- 参考リンク
- はじめに——「動くけど遅い」の原因は量子化の選び方にある
- 量子化とは何か——30秒で理解する基本原理
- 4大フォーマット徹底解説——GGUF・GPTQ・AWQ・EXL2
- 4大フォーマット比較サマリー
- GGUFの量子化レベル完全早見表——Q2からQ8まで何が違うのか
- 品質劣化の実態——量子化レベル別ベンチマーク比較
- 「このGPUで動く最大のモデル」早見表
- 実行環境別の最適フォーマット選択——Ollama・vLLM・llama.cpp・ExLlamaV2
- 実践：量子化モデルの入手と実行手順
- 量子化品質を上げるテクニック——imatrix・キャリブレーション・KVキャッシュ量子化
- よくある質問（Q&A）
- まとめ——量子化は「妥協」ではなく「最適化」
- 参考リンク
はじめに——「動くけど遅い」の原因は量子化の選び方にある
「Ollamaでモデルを動かしてみたけど、思ったより遅い」
「8GB VRAMのGPUで70Bモデルを動かしたい。どの量子化を選べばいい？」
「Q4_K_MとQ5_K_Mで迷っている。実際どれくらい品質が変わるのか？」
ローカルLLM入門やモデル選定ガイドでは、「Q4量子化で○○GB必要」と概要を紹介しました。ハードウェア構築ガイドではMac miniやWindows PCの選び方を解説しました。
しかし、「量子化」そのものに特化した記事がありませんでした。
量子化（Quantization）は、ローカルLLM運用の根幹を支える技術です。同じGPU、同じモデルでも、量子化フォーマットと量子化レベルの選び方一つで、推論速度が2〜3倍変わり、品質の劣化度合いも大きく異なります。
本記事では、2026年現在の4大量子化フォーマット（GGUF・GPTQ・AWQ・EXL2）の技術的な違い、VRAM別の最適モデル早見表、そして品質劣化のベンチマーク比較まで、量子化の実務判断に必要なすべてを網羅します。
量子化とは何か——30秒で理解する基本原理
量子化とは、LLMの重み（パラメータ）を表現する数値の精度を下げることで、モデルサイズを大幅に圧縮する技術です。
たとえるなら、高解像度のTIFF画像をJPEGに圧縮するようなものです。ファイルサイズは劇的に小さくなり、見た目はほとんど変わらない——ただし、圧縮率を上げすぎると画質が劣化します。LLMの量子化もまったく同じトレードオフです。
| 精度 | 1パラメータあたりのサイズ | 7Bモデルの重みサイズ（目安） | 品質 |
|---|---|---|---|
| FP32（32ビット浮動小数点） | 4バイト | 約28GB | 基準（オリジナル） |
| FP16 / BF16（16ビット） | 2バイト | 約14GB | ほぼ劣化なし |
| 8ビット量子化（Q8_0等） | 約1バイト | 約7〜8GB | 微小な劣化 |
| 4ビット量子化（Q4_K_M等） | 約0.5バイト | 約4〜5GB | 軽微な劣化（実用範囲） |
| 2ビット量子化（Q2_K等） | 約0.25バイト | 約2〜3GB | 大きな劣化 |
重要なポイントは、4ビット量子化（Q4_K_M）であれば、オリジナルの90〜95%の品質を維持しながら、モデルサイズを約75%削減できるということです。これにより、本来32GB以上のVRAMが必要な13Bモデルを、8GBのGPUで実用的に動かせるようになります。
4大フォーマット徹底解説——GGUF・GPTQ・AWQ・EXL2
2026年現在、ローカルLLMの量子化フォーマットは主に4種類です。それぞれ設計思想と得意分野が異なります。
GGUF——万能型、Ollama・llama.cppの標準フォーマット
GGUF（GPT-Generated Unified Format）は、llama.cppプロジェクトが開発したフォーマットです。以前のGGMLフォーマットを拡張し、モデルのメタデータ（アーキテクチャ、トークナイザー設定、ハイパーパラメータ）を1つのファイルに格納できるようになりました。
最大の強み： CPU・GPU・Apple Siliconすべてで動作する圧倒的な汎用性。GPU VRAMに収まらない場合、一部のレイヤーをCPUにオフロードするハイブリッド推論が可能です。
量子化方式： K-quant（K量子化）と呼ばれる手法を使います。256個の重みを「スーパーブロック」としてグループ化し、サブブロックのスケール値自体も量子化することで、効率的にビット数を削減します。Q4_K_M、Q5_K_M、Q6_Kなど複数のプリセットが用意されています。2026年には重要度行列（imatrix）を使ったi-quantも普及し、極端な低ビット量子化でも品質を維持しやすくなっています。
対応ツール： Ollama、llama.cpp、LM Studio、kobold.cpp、text-generation-webui
GPTQ——GPU特化、vLLMサーバー向けの定番
GPTQ（GPT-Quantized）は、2023年にFrantar et al.が発表した量子化手法です。近似的な2次情報（ヘッセ行列の逆行列）を使って、量子化誤差を最小化するキャリブレーションベースの手法です。
最大の強み： GPU推論に最適化されており、特にExLlamaカーネルやMarlinカーネルと組み合わせると非常に高速です。vLLMでのマルチLoRAサーブにも対応しています。
注意点： キャリブレーションデータセットが必要で、その選択が量子化品質に影響します。CPUオフロードには対応していないため、モデル全体がGPU VRAMに収まる必要があります。量子化にはGPU上で2〜4時間程度かかります（7Bモデル、A100使用時）。
対応ツール： vLLM、AutoGPTQ、HuggingFace Transformers、ExLlama/ExLlamaV2
AWQ——高品質維持、活性化値ベースの最適量子化
AWQ（Activation-Aware Weight Quantization）は、すべての重みが同じ重要性を持つわけではないという洞察に基づく手法です。推論時の活性化値（activation）を分析し、出力品質に大きく影響する「重要な重み」を特定して、それらを優先的に保護します。
最大の強み： 同じ4ビット量子化でも、GPTQより高い品質を維持する傾向があります。特にInstruction-tunedモデル（対話型モデル）での品質維持に優れます。キャリブレーションデータの量が少なくて済み（128〜512サンプル、GPTQは2048+）、量子化速度もGPTQより高速です。
注意点： エコシステムがGGUFやGPTQに比べてやや小さく、事前量子化済みモデルの選択肢がやや限定的です。
対応ツール： vLLM、AutoAWQ、HuggingFace Transformers
EXL2——レイヤー別可変ビット、ExLlamaV2専用の最速フォーマット
EXL2は、ExLlamaV2の開発者turboderp氏が作った量子化フォーマットです。最大の特徴は、レイヤーごとに異なるビット幅を割り当てられることです。
他のフォーマットが「全レイヤー一律4ビット」のようにほぼ均一な量子化を行うのに対し、EXL2は精度に敏感なレイヤーには多くのビットを、冗長なレイヤーには少ないビットを割り当てます。たとえば「平均4.65ビット/重み」のように、小数点単位でビット幅を指定できます。
最大の強み： 同じ平均ビット幅でも、他のフォーマットより低いパープレキシティ（高い品質）を実現します。GPU推論速度はすべてのフォーマット中で最速クラスです。
注意点： ExLlamaV2専用のため汎用性が低い。CPUオフロードに対応しておらず、モデル全体がGPU VRAMに収まる必要があります。70Bモデルはシングル24GB GPUでは実質使えず、デュアルGPU構成か、30B以下のモデルに限られます。
対応ツール： ExLlamaV2、text-generation-webui（ExLlamaV2バックエンド）
4大フォーマット比較サマリー
| 項目 | GGUF | GPTQ | AWQ | EXL2 |
|---|---|---|---|---|
| 開発元 | llama.cpp / ggml | Frantar et al. | MIT Han Lab | turboderp |
| 量子化方式 | K-quant（混合精度整数） | キャリブレーションベース（2次情報） | 活性化値ベース | レイヤー別可変ビット |
| CPU推論 | ◎（ネイティブ対応） | ✕ | ✕ | ✕ |
| GPU推論 | ○ | ◎ | ◎ | ◎（最速） |
| CPUオフロード | ◎（レイヤー単位） | ✕ | ✕ | ✕ |
| Apple Silicon | ◎（Metal対応） | △（限定的） | △（限定的） | ✕ |
| 品質維持率（4bit） | 約92% | 約90% | 約95% | 約93〜95%（可変） |
| 量子化にかかる時間（7B） | 5〜15分 | 2〜4時間 | 10〜30分 | 30分〜1時間 |
| 事前量子化モデルの豊富さ | ◎（最多） | ○ | △ | △ |
| ライセンス | MIT（llama.cpp） | Apache 2.0 | MIT | MIT |
GGUFの量子化レベル完全早見表——Q2からQ8まで何が違うのか
GGUFは最も選択肢が多いフォーマットです。Q2_KからQ8_0まで10種類以上のプリセットがあり、初めてだと何を選ぶべきか迷います。以下に、7Bモデルを基準とした各レベルの特徴をまとめます。
| 量子化レベル | 平均ビット/重み | 7Bモデルのファイルサイズ（目安） | 品質劣化 | 推奨用途 |
|---|---|---|---|---|
| Q8_0 | 8.5 | 約7.7GB | ほぼなし（FP16に近い） | 品質最優先。VRAM余裕がある場合 |
| Q6_K | 6.6 | 約5.5GB | 微小（多言語で安心） | 非英語（日本語）利用時のベストバランス |
| Q5_K_M | 5.7 | 約4.8GB | 軽微 | 品質重視＋VRAM節約のバランス型 |
| Q5_K_S | 5.5 | 約4.6GB | 軽微 | Q5_K_Mのやや圧縮版 |
| Q4_K_M | 4.8 | 約4.1GB | 小（実用範囲） | ★ 推奨。ほとんどのユースケースで最適 |
| Q4_K_S | 4.6 | 約3.8GB | 小〜中 | VRAM厳しめの環境 |
| Q3_K_L | 3.9 | 約3.6GB | 中（品質低下が目立ち始める） | VRAM非常に限定的な環境 |
| Q3_K_M | 3.3 | 約3.3GB | 中〜大 | 最小限の品質を許容する場合のみ |
| Q3_K_S | 3.0 | 約2.9GB | 大 | 非推奨（品質低下が顕著） |
| Q2_K | 2.6 | 約2.8GB | 極大 | 非推奨（実用性に問題あり） |
結論から言うと、ほとんどのユーザーにとってQ4_K_Mが最適解です。 品質、VRAM効率、推論速度のバランスが最もよく、llama.cppコミュニティでも「推奨（recommended）」とされています。
日本語を主に扱う場合は、Q6_Kを強く推奨します。4ビット量子化では非英語の品質が5〜10%低下する傾向がありますが、Q6_Kであればその劣化をほぼ回避できます。VRAM増加は数GB程度で、品質維持のコストとしては非常に小さいです。
品質劣化の実態——量子化レベル別ベンチマーク比較
「量子化で品質が落ちる」とは言われますが、具体的にどの程度落ちるのでしょうか。パープレキシティ（モデルの予測精度を測る指標、低いほど良い）の変化を見ると、タスクによって劣化の度合いが大きく異なることがわかります。
タスク別の量子化耐性：
| タスク | Q8_0での劣化 | Q4_K_Mでの劣化 | Q3_K_Mでの劣化 | 補足 |
|---|---|---|---|---|
| 常識推論（HellaSwag等） | ほぼ0% | 1〜2% | 3〜5% | 量子化に最も強い |
| 知識問題（MMLU等） | 0.5%未満 | 2〜4% | 5〜8% | 4bit以上なら実用範囲 |
| コード生成 | 1%未満 | 3〜5% | 8〜15% | 4bit未満は要注意 |
| 数学的推論（GSM8K等） | 1〜2% | 5〜10% | 15〜25% | 量子化に最も弱い。4bit以上を推奨 |
| 日本語（非英語全般） | 1%未満 | 5〜10% | 10〜20% | Q6_K以上を推奨 |
重要な知見：
常識推論タスクは量子化に非常に強く、Q4_K_Mでも実用上問題ありません。一方、数学的推論とコード生成は量子化の影響を強く受けます。コーディングアシスタントや思考型（thinking）モデルとして使う場合は、Q4_K_M以上を最低ラインとし、可能ならQ5_K_M以上を推奨します。
日本語利用については前述の通り、Q6_Kが安全な選択です。Q4_K_Mでも通常の会話や文書作成は問題なくこなせますが、微妙なニュアンスの表現や専門的な文章では品質差が体感できることがあります。
「このGPUで動く最大のモデル」早見表
VRAM計算の基本公式
ローカルLLMの実行に必要な総VRAM量は、以下の2つの合計です。
総VRAM = モデルの重みサイズ + KVキャッシュサイズ
モデルの重みサイズは「パラメータ数 × ビット数/重み ÷ 8」で概算できます。たとえば、8Bモデル × 4ビット ÷ 8 = 約4GB。
KVキャッシュはコンテキスト長に比例して増加します。8Bモデルでデフォルトの8Kコンテキストの場合、FP16 KVキャッシュで約1〜2GBを消費します。32Kコンテキストでは約4.5GBにもなります。
実用的な目安： モデルファイルサイズ + 2〜3GB = 必要VRAM量（8Kコンテキスト時）
GPU別・推奨モデルサイズ＋量子化レベル
| VRAM | 代表的なGPU | 推奨モデル × 量子化 | 推論速度の目安 |
|---|---|---|---|
| 6GB | RTX 4060、RTX 3060 (6GB) | 7〜8B × Q4_K_M | 20〜30 tok/s |
| 8GB | RTX 4060 Ti (8GB)、RTX 3070 | 7〜8B × Q5_K_M 13B × Q3_K_M（品質低下注意） | 25〜40 tok/s |
| 12GB | RTX 4070、RTX 3060 (12GB) | 7〜8B × Q8_0 13B × Q4_K_M 32B × Q3_K_M（品質低下注意） | 30〜50 tok/s |
| 16GB | RTX 4070 Ti、RTX 5060 Ti | 13B × Q6_K 32B × Q4_K_M | 25〜45 tok/s |
| 24GB | RTX 4090、RTX 5080、RTX 3090 | 32B × Q6_K 70B × Q4_K_M（CPUオフロード併用） 30B × EXL2 4.0bpw（GPU完結） | 15〜40 tok/s |
| 48GB | RTX A6000、デュアルGPU構成 | 70B × Q5_K_M 70B × Q6_K | 10〜25 tok/s |
※推論速度はモデル、設定、バッチサイズにより大きく変動します。上記はバッチサイズ1、8Kコンテキストの概算値です。
注意： 70Bモデルを24GB GPU単体で動かす場合、GGUF + CPUオフロード（一部レイヤーをシステムRAMで処理）が唯一の選択肢です。GPTQ、AWQ、EXL2はCPUオフロードに対応していないため、70Bモデルには使えません。
Apple Silicon（Mac）ユーザー向けガイド
Apple Siliconは「ユニファイドメモリ」アーキテクチャにより、GPUとCPUが同じメモリプールを共有します。このため、搭載メモリ全体がモデルの格納に使えるという大きなメリットがあります。
| Mac構成 | ユニファイドメモリ | 推奨モデル × 量子化 |
|---|---|---|
| MacBook Air M2/M3（8GB） | 8GB | 7〜8B × Q4_K_M |
| MacBook Pro M3/M4（18GB） | 18GB | 13B × Q5_K_M、32B × Q4_K_M |
| Mac mini M4 Pro（24GB） | 24GB | 32B × Q6_K |
| Mac Studio M4 Max（64GB） | 64GB | 70B × Q5_K_M |
| Mac Studio M4 Max/Ultra（128GB） | 128GB | 70B × Q6_K、120B+ × Q4_K_M |
Apple Siliconでのローカル推論では、GGUFフォーマット一択です。OllamaまたはllでGGUF形式のモデルを使用してください。GPTQやAWQはNVIDIA GPU（CUDA）に依存するため、Macでは実用的に使えません。
Mac mini/Windows PC構築ガイドでハードウェア選びの詳細を解説しています。
実行環境別の最適フォーマット選択——Ollama・vLLM・llama.cpp・ExLlamaV2
量子化フォーマットは「どのツールで実行するか」と密接に結びついています。
| 実行環境 | 推奨フォーマット | ユースケース |
|---|---|---|
| Ollama | GGUF（Q4_K_M推奨） | 個人利用、開発・テスト。ワンコマンドで起動でき最も手軽 |
| llama.cpp | GGUF | CPUオフロード、Apple Silicon、組み込み環境、自分で量子化したい場合 |
| vLLM | GPTQ（Int4）/ AWQ | マルチユーザー対応のAPIサーバー。LoRAアダプター使用時はGPTQ必須 |
| ExLlamaV2 | EXL2 | 最高速のGPU推論。モデル全体がVRAMに収まる場合 |
| HuggingFace Transformers | GPTQ / AWQ / BitsAndBytes | 研究・実験。既存のTransformersパイプラインとの統合 |
選び方のフローチャート：
まず、モデル全体がGPU VRAMに収まるかどうかを確認します。収まらない場合はGGUF一択です（CPUオフロードが必要）。収まる場合は、用途で分岐します。個人利用やテストならOllama + GGUF、マルチユーザーAPIサーバーならvLLM + GPTQ/AWQ、最速を求めるならExLlamaV2 + EXL2。
ローカルLLM×Function Callingの記事で紹介したようなエージェント的な使い方では、Ollama + GGUFの構成がシンプルで実用的です。
実践：量子化モデルの入手と実行手順
Ollamaで量子化モデルを使う
Ollamaは最も簡単な方法です。Ollamaが提供するモデルは基本的にGGUF形式で、デフォルトでQ4_K_Mが選択されます。
# モデルのダウンロード＋起動（Q4_K_Mがデフォルト）
ollama run llama3.1:8b
# 特定の量子化レベルを指定
ollama run llama3.1:8b-q6_K
ollama run llama3.1:8b-q8_0
# コンテキスト長を短くしてVRAMを節約
/set parameter num_ctx 4096
OllamaはFlash Attentionにも対応しており、環境変数OLLAMA_FLASH_ATTENTION=1を設定することで、VRAMの追加消費なしに推論速度を向上できます。
llama.cppで自分で量子化する
HuggingFaceで公開されているFP16/BF16のモデルを、自分でGGUFに変換・量子化する手順です。
# 1. llama.cppをビルド
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make
# 2. HuggingFaceモデルをGGUF（FP16）に変換
python convert_hf_to_gguf.py /path/to/model --outfile model-f16.gguf
# 3. 量子化（Q4_K_Mの場合）
./llama-quantize model-f16.gguf model-Q4_K_M.gguf Q4_K_M
# 4. （推奨）重要度行列を使った高品質量子化
./llama-imatrix -m model-f16.gguf -f calibration-text.txt --chunk 512 -o imatrix.dat -ngl 80
./llama-quantize --imatrix imatrix.dat model-f16.gguf model-Q4_K_M.gguf Q4_K_M
重要度行列（imatrix）を使うことで、特に低ビット量子化（Q3以下）の品質が大幅に改善します。キャリブレーション用テキストは、実際に使うドメインのテキスト（日本語を扱うなら日本語テキスト）を使うのが理想的です。
vLLMでGPTQ/AWQモデルをサーブする
マルチユーザー対応のAPIサーバーを構築する場合、vLLMが最適です。
# GPTQ モデルのサーブ
vllm serve TheBloke/Llama-2-13B-GPTQ --quantization gptq
# AWQ モデルのサーブ
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq
# LoRAアダプターとの併用（GPTQ-Int4のみ対応）
vllm serve model-gptq --quantization gptq --enable-lora --lora-modules lora1=path/to/lora
vLLMはcontinuous batching（連続バッチ処理）により、複数ユーザーからの同時リクエストを効率的に処理します。LoRAアダプターを使ったマルチテナント構成では、GPTQ-Int4が現時点で唯一の選択肢です。
量子化品質を上げるテクニック——imatrix・キャリブレーション・KVキャッシュ量子化
1. 重要度行列（imatrix）の活用
前述の通り、llama.cppのllama-imatrixでキャリブレーションデータを使って重要度行列を計算し、量子化時に--imatrixオプションで指定します。これにより、重要な重みに多くのビットが配分され、特にQ3_K_M以下の低ビット量子化で劇的な品質向上が得られます。
2. キャリブレーションデータの選択
GPTQやAWQの量子化品質は、キャリブレーションデータに大きく依存します。WikiText-2がデフォルトでよく使われますが、実際のユースケースに近いデータ（日本語テキスト、コード、特定ドメインの文書など）を使うことで、そのドメインでの品質を向上できます。
3. KVキャッシュ量子化
KVキャッシュをFP16からINT8やFP8に量子化することで、キャッシュのメモリ消費を最大50%削減できます。これにより、同じVRAMでより長いコンテキストを扱えるようになります。ただし、Keyベクトルの量子化はアテンション精度に影響するため、Valueベクトルのみ量子化するか、INT8程度に留めるのが安全です。Ollamaでは環境変数で設定可能です。
4. Flash Attentionの有効化
Flash Attentionはメモリアクセスパターンを最適化し、品質劣化なしにVRAM使用量を削減して推論速度を向上させる技術です。OllamaではOLLAMA_FLASH_ATTENTION=1、llama.cppではビルド時のオプションで有効化できます。
よくある質問（Q&A）
Q1. Q4_K_MとQ5_K_Mの差は体感できますか？
日常的な会話や一般的な質問応答では、ほとんどの場合体感できません。ただし、数学的推論、コード生成、日本語の長文生成などの高難度タスクでは差が出ることがあります。VRAM余裕が1〜2GBある場合はQ5_K_Mを選ぶのが安全です。VRAMがギリギリならQ4_K_Mで十分実用的です。
Q2. HuggingFaceに大量のGGUFファイルがありますが、どれをダウンロードすればいいですか？
まずQ4_K_Mを試してください。これが推奨デフォルトです。日本語利用が多い場合はQ6_Kを選んでください。VRAMに余裕があり最高品質を求めるならQ8_0、VRAMが厳しいならQ4_K_Sを検討します。Q3以下は品質劣化が大きいため、特別な理由がない限り避けてください。
Q3. GGUFとGPTQで同じ4ビットなら、どちらが品質が良いですか？
GGUFのQ4_K_Mの方がGPTQ 4-bitよりわずかに品質が高い傾向があります。これは、GGUFのK-quant方式がレイヤーの特性に応じて混合精度を使うためです。ただし差は小さく、GPTQの方がGPU推論速度は速い（ExLlamaカーネル使用時）ため、用途に応じて選択してください。
Q4. 量子化モデルをファインチューニングできますか？
量子化モデルそのものを直接ファインチューニングすることは通常できません。ただし、量子化モデルにLoRAアダプターを適用する「QLoRA」という手法が広く使われています。4ビット量子化のベースモデル + LoRAアダプターの組み合わせで、8GB VRAMでも7Bモデルのファインチューニングが可能です。
Q5. vLLMとOllamaの使い分けは？
Ollama： 個人利用、開発・テスト、シングルユーザー。セットアップが簡単で、ワンコマンドで動く。GGUFフォーマット。
vLLM： マルチユーザー対応のAPIサーバー。continuous batchingによる高スループット。GPTQ/AWQフォーマット。LoRAマルチテナント。
個人開発者やテスト用途ならOllama、本番の社内AIサーバーや複数ユーザーがアクセスするAPIならvLLMを推奨します。クラウドAI vs ローカルLLMの記事も参考にしてください。
まとめ——量子化は「妥協」ではなく「最適化」
量子化は、限られたハードウェアリソースでLLMを動かすための「妥協」ではありません。適切なフォーマットとレベルを選べば、オリジナルの90〜95%の品質を維持しながら、モデルサイズを75%削減し、推論速度を向上させる「最適化」です。
本記事のポイントを整理します。
1. フォーマット選びは実行環境で決まる。 Ollama/llama.cpp → GGUF。vLLMサーバー → GPTQ/AWQ。最速GPU推論 → EXL2。Apple Silicon → GGUF一択。
2. ほとんどのユースケースでQ4_K_Mが最適解。 品質・VRAM・速度のバランスが最もよく、推奨デフォルトです。日本語利用時はQ6_Kが安全。数学やコーディングにはQ5_K_M以上を推奨。
3. 「このGPUで動く最大のモデル」を見極める。 VRAM計算の公式とGPU別早見表を使えば、手持ちのハードウェアで最適なモデル × 量子化の組み合わせが判断できます。
4. 品質が気になるならimatrixを使う。 重要度行列による量子化で、特に低ビット量子化の品質を大幅に改善できます。
ローカルLLM入門で基礎を学び、モデル選定ガイドでモデルを選び、ハードウェア構築ガイドで環境を構築し、本記事で量子化を最適化する——このステップで、あなたのローカルLLM環境は実用レベルに到達します。
参考リンク
- llama.cpp GitHub リポジトリ
- llama.cpp 量子化ツール ドキュメント
- vLLM GitHub リポジトリ
- ExLlamaV2 GitHub リポジトリ
- AutoAWQ GitHub リポジトリ
- AutoGPTQ GitHub リポジトリ
- Ollama 公式サイト
- HuggingFace Transformers 量子化ドキュメント
免責事項： 本記事は2026年3月時点の公開情報に基づく情報提供です。量子化技術、モデル、ツールは急速に進化しています。ベンチマーク数値はモデル、ハードウェア、設定により大きく変動するため、実際のユースケースでの検証を必ず行ってください。推論速度やVRAM使用量の数値は概算であり、正確な値は実機テストで確認してください。
コメント