ローカルLLMの量子化フォーマットの選び方｜Q4_K_M〜Q8・QATを精度・サイズと16GB VRAMで見極める

量子化フォーマットとは、LLMの重みを低ビットに圧縮し容量と速度を稼ぐ方式。

Hugging Faceで同じモデルのページを開くと、量子化の種類がずらりと並びます。Q4_K_M、Q5_K_M、Q6_K、Q8_0、さらにQAT版――名前だけでは何がどう違うのか、すぐには判断できません。ファイルサイズは数GB単位で変わり、選び方を誤ればVRAMからあふれて速度が落ちる。逆に容量を惜しんで低ビットを選べば、精度が削られることもある。この記事では、bpw・ファイルサイズ・perplexity・VRAM消費という4つの実数から、用途と環境に合わせて量子化を決める基準を整理します。

量子化フォーマットとは｜bpwがファイルサイズとVRAMを左右する仕組み

元のLLMは、FP16やBF16といった高精度な浮動小数点で重みを保持しています。量子化とは、この重みをより少ないビット数で表現し直す圧縮処理のこと。重み1個あたりのビット数を表す指標がbpw（bit per weight）で、これが小さいほどファイルは軽くなり、VRAM消費も減ります。代わりに、表現できる数値の刻みが粗くなるため、精度が削られることがある。ファイルサイズはbpwと強く連動しますが、量子化しないテンソルやスケール情報、メタデータも一緒に入るため、bpwとパラメータ数の掛け算そのものにはなりません。速度と精度の動きも量子化方式やモデル、実行バックエンドによって変わり、単純な比例にはなりません。

なぜサイズとVRAMと速度が同時に動くのでしょうか。モデルの重みはまずストレージ上のファイルとして存在し、GPU推論では、その全部または一部がVRAMへ読み込まれます。bpwが下がればファイルが小さくなり、VRAMに載せる量も減る。さらにローカル推論では、GPUがメモリから重みを読み出す帯域がボトルネックになりやすく、データ量が減ること自体が生成速度の向上につながりやすい。容量を削る選択は、速度にも効いてきます。

GGUFとllama.cppの関係

ローカルでこれらの量子化を実際に動かす土台が、llama.cppと、その標準フォーマットであるGGUF。GGUFはllama.cppが扱うモデルの格納形式で、Q4_K_MやQ8_0といった種類は、そのGGUFに対して指定する量子化方式を指します。量子化済みの重みだけを入れる器ではありません。まず元のモデルをGGUFへ変換し、そのGGUFを量子化するという別々の工程になっていて、F32・BF16・F16のような非量子化の高精度モデルもGGUFとして扱えます。大きなモデルを複数ファイルへ分割することもできるため、「1ファイル」も必須の条件ではありません。llama.cppはWindows（CUDA 12/13）、Linux（ROCm・Vulkan）、Apple Siliconなど幅広い環境向けにビルドが提供され、OllamaやLM StudioからもGGUFのモデルを利用できます。「どの量子化を選ぶか」は、llama.cppが扱えるGGUFのどのスキームを選ぶか、と言い換えられます。

Q4_K_M・Q5_K_M・Q6_K・Q8_0の違いを一覧で比較

実用上よく使われる4つのフォーマットを、bpwとファイルサイズで並べると違いが一目で分かります。次の表はllama.cpp 公式 quantize READMEが公開しているLlama-3.1-8Bでの値です。

数字を見ると、Q4_K_Mの4.8944bpwからQ8_0の8.5008bpwまで、ビット幅は約1.74倍。ファイルサイズも4.58GiBから7.95GiBへと、同じく約1.74倍に開きます。一方で精度の劣化は、ビット幅の差ほど大きくありません。少なくともperplexityで見るかぎり、高ビット側ほど1ビットあたりの改善幅は小さくなります。ただし下流ベンチの平均スコアは単調ではなく、引用した評価ではQ5_0の69.92がFP16の69.47やQ8_0の69.41を上回っています（論文自身も、この程度の差は評価のばらつきの範囲かもしれないと断っています）。

同じLlama-3.1-8Bを4形式ロードして測る

上の表は配布ファイルの大きさで、GPUに載せたときの確保量とは別物です。そこで同じLlama-3.1-8Bを4形式ともロードして測りました（RTX 5080単体・Ollama 0.34.0・num_ctx=8192・KVキャッシュf16・think=false・温度0）。ウォームアップ1回のあと3回測る手順を2周し、計6回の中央値を載せます。4形式とも/api/psのsize_vramが同じAPIのsize（総確保量）と一致したので、Ollamaの表示上は全量がGPUに置かれたと判断しています（表示がそう出るというだけで、CPU側のメモリ利用が皆無であることまでを確かめたものではありません）。ロードしたのはOllamaのllama3.1:8b-instruct-*タグで、ファイルサイズは上の表の値と0.01GiB以内で一致します。同名タグは中身が差し替わることがあるので、計測に使ったdigestを残しておきます——Q4_K_M 46e0c10c039e／Q5_K_M 27fe1b0ab52c／Q6_K 81e7664fda9c／Q8_0 b158ded76fa0。

隣り合う形式の範囲は6回を通して一度も重なりませんでした。Q4_K_MからQ8_0まで上げると生成速度は約0.64倍、1秒あたり50トークンほどの差になります。短い応答では気づきにくく、長い応答ほど待ち時間の差として出ます。

確保量は文脈長で動く｜増える分は量子化で変わらない

/api/psのsize_vramは重みだけの数字ではありません。num_ctxだけを変えて測ると、4形式ともまったく同じだけ増えました。

増分は4形式で0.1MiBまで一致します。文脈長に応じて確保される分（KVキャッシュと、文脈長に連動する作業用の領域を含みます）は、重みの量子化に依存しないということです。ただしこの増分はトークン数に比例しません——+6,144トークンで890.0MiB、+8,192トークンで1,040.0MiBと、1トークンあたりに直すと0.145MiBと0.127MiBで揃いません。表に無いnum_ctxを比例計算で埋めないでください。なおこれらは8B級・KVキャッシュf16・RTX 5080単体での値で、層数やKVヘッド数が違うモデルやKV側を量子化した場合は増分そのものが変わります。したがって確保量の比は、コンテキスト長をいくつにしたかで動きます。Q8_0とQ4_K_Mの比を取ると、num_ctx=2048で約1.67倍、8192で約1.57倍、16384で約1.48倍。ファイルサイズの比（約1.74倍）はそのどれとも一致しません。文脈を長く取るほど量子化に依存しない分の割合が増え、比は1へ近づきます。

ここで挙げた数値はsize_vram、つまりそのモデルのためにVRAMへ確保された分です。後述の検証環境の節で挙げるnvidia-smiのGPU全体使用量とは含む範囲が違うので直接は比べられません（参考までに、この4形式のGPU全体使用量は8,259〜11,646MiB。ただしnum_ctxとOllamaの版が後述の計測と違うため、12B級の値と大小を直接比べることはできません）。

K-quant（_K_M / _K_S）の中身と「_M」「_S」の意味

名前に付く「_K」は、K-quantと呼ばれる方式を指します。K-quantは256値を1つのスーパーブロックとしてまとめ、その中をさらに小さなサブブロックに分ける、階層的なブロック量子化です。ブロックが持つスケール情報の形は方式によって違い、Q4_K・Q5_K はスケール（倍率）と最小値の両方を持ちますが、Q3_K・Q6_K はスケール中心の形を取ります。末尾の「_M」「_S」はMedium・Smallの略ですが、違いはビット数の微調整ではありません。どちらもテンソルごとに量子化の型を変えるプリセットで、_M は一般に、量子化に敏感な一部のテンソルへ _S より高精度な型を割り当て、容量を少し増やして品質を取りにいきます。どのテンソルをどの型に振るかはモデル構造によって分岐し、llama.cpp の更新でも変わるため、具体的な組み合わせは実装側の判断と考えてください。Q4_0などのレガシー量子化より、K-quantの方が同じサイズで精度が高い傾向にあります。Q4_K_M・Q8_0・FP16の速度とVRAMを別条件で実測した結果は前身の比較記事にまとめています。

精度はどれだけ落ちるのか

量子化で精度がどれだけ削られるかは、perplexity（予測の当てにくさ、低いほど良い）とベンチマーク平均スコアで測れます。arXiv:2601.14277のLlama-3.1-8B評価では、次の結果が報告されています。

FP16のperplexity 7.32に対し、Q4_K_Mは7.56。差は0.24にとどまり、平均ベンチスコアも69.47→69.15とほとんど動いていません。Q5_K_Mは7.40、Q6_Kは7.35、Q8_0に至っては7.33とFP16にほぼ並びます。4ビットまで圧縮してもこの範囲に収まる例がある、というのがここで言えることです。ただしこれはLlama-3.1-8Bという特定モデルの数値で、モデルのサイズや構造が変われば劣化幅も変わります。他モデルへこの値をそのまま当てはめるのは避けてください。

VRAMに余裕があり精度を盛りたいならQ5_K_MやQ6_K、perplexityや量子化による挙動変化をFP16へ近づけたいならQ8_0。Q4_K_Mを起点に上下を調整する、と考えると選び分けがすっきりします。

QATが低ビットでも精度を保てる理由｜Gemmaの事例

ここまでは、学習し終えたモデルを後から圧縮するPTQ（ポストトレーニング量子化）の話です。これとは別の発想が、QAT（Quantization-Aware Training／量子化対応学習）。学習後ではなく、学習の最中に低精度演算をシミュレートして圧縮の影響を織り込む手法です。あらかじめ「4ビットになる前提」で重みを整えるため、同じビット幅でも精度が落ちにくくなります。

効果は数字に表れています。GoogleはGemma 3のQAT版で、int4化によるVRAM削減を公表しました。

27Bが54GBから14.1GB、12Bが24GBから6.6GBへ。ただしこの数値は重みをロードする分のVRAMで、実際の推論ではKVキャッシュやランタイム用のメモリが別途上乗せされます。それでも、BF16では手が出ない大きさのモデルがQAT int4なら16GB級GPUの射程に近づくのは確かです（この表はGoogle公式のGB表記で、後述するnvidia-smi実測のMiB/GiBとは単位系が異なります）。精度面でも、Google 公式ブログは、QATによってQ4_0量子化時のperplexity劣化を54%削減できると説明しています（出典は末尾の参考資料）。

Gemma 3 QAT版はOllama・LM Studio・llama.cpp・MLXといった主要ツールで利用できます。Gemma 4にもQAT版があり、llama.cppやOllamaですぐ使えるGGUF版がgoogle/gemma-4-12B-it-qat-q4_0-gguf、変換・研究向けの半精度チェックポイントがgoogle/gemma-4-12B-it-qat-q4_0-unquantizedと、用途別に分かれて提供されています（GGUF/Ollama/llama.cpp/LM Studio 等での利用が確認できます）。ただし、ここで避けたいQ4_0は「学習後に通常のPTQ（ポストトレーニング量子化）でQ4_0へ落としたもの」を指します。GemmaのQAT q4_0は、あらかじめQ4_0で使う前提を学習時に織り込んだ公式モデルで、通常のPTQ Q4_0とは別枠で評価してください。Ollamaでローカル環境を整える手順そのものは、姉妹サイトのローカルLLMとは？Ollama × Gemma 4でコードを外に出さずに使うAI環境の解説が詳しい。ただし「QATなら4ビットでも品質劣化ゼロ」と一般化はできません。Googleが数値で示しているのはGemma 3 QATでのperplexity劣化54%削減で、Gemma 4についてはQAT版の提供と品質改善を説明しているものの、同じ54%という値は示していません。低ビット側の利点が大きいケースで効く、と捉えるのが正確です。

検証環境と16GBで動かせる量子化の現実解

理論値が分かったところで、実際に手元のGPUへ載せるとどうなるか。当サイトの検証環境（RTX 5080＝VRAM 16GB／システムRAM 96GB／NVIDIAドライバ610.47）で、各モデルを既定の量子化のまま動かしたときのVRAM占有と生成速度を計測しました。以下に挙げるのはRTX 5080 単体で動かしたときの値です。

• プロンプト: 全モデル共通の日本語プロンプト・生成上限512トークン・think=false
• 集計: tok/s は Ollama API の eval_count ÷ eval_duration。各モデル3回の中央値（3回では四分位範囲による外れ値判定が定義のしかたに左右されるため、中央値のみ）
• VRAM: nvidia-smi が返すGPU全体の使用量。ロード後に /api/ps の size_vram でGPUに載っていることを確認
• 計測日とOllama: Gemma 4 12B が2026年7月22日・0.32.1、Gemma 3 12B が同7月24日・0.32.3（2モデルで版が異なります）

temperature・num_ctxはOllama既定のまま、seedはモデルによって固定した回と固定していない回が混じるため、ここは厳密な再現比較ではなく参考比較です。この節で示すのは同一モデルを量子化別に振った比較ではなく、各モデルを既定設定で動かしたときの動作エンベロープです（同一モデルを4形式で振った実測は前掲の表）。推論エンジン（llama.cpp）の更新で速度は変わりうるため、数値はその時点の参考値として読んでください。

たとえばGemma 4 12B（Ollama: gemma4:12b）は75.9 tok/s、VRAM占有は9740MiB（約9.51GiB）。同じ12B級のGemma 3 12B（Ollama: gemma3:12b）は78.0 tok/s、11051MiB（約10.79GiB）でした。Gemma 4 12Bを16GBで動かす構成の詳細はRTX 5080/5060 Tiでの実測記事でも扱っています。なお、この占有値はnvidia-smiのmemory.used、つまりデスクトップ表示などのベースラインを含むGPU全体の使用量で、モデル単体のロード増分とは別物。この帯で動くのを確認できたのは検証したGemma系の12B 2モデルで、しかもnum_ctxをOllama既定のままにした範囲です（文脈を長く取れば前節のとおり確保量は増えます。他系列の12B級とそれより大きい領域は未検証）。

16GBで安全圏と攻める量子化の線引き

ここから示すのは、各モデルの既定量子化タグを16GB級GPU環境で動かしたときの参考値です（同一モデルを量子化別に振った実測は前掲の表）。16GBという容量は、12B前後のモデルなら量子化に余裕を持てるラインです。先のLlama-3.1-8Bの例では、Q8_0のファイルがQ4_K_Mの約1.7倍、実測のVRAM確保量は約1.57倍でした（8B級・num_ctx=8192）。この比はコンテキスト長で動くので、係数として他の条件へ持ち込まないでください。同じモデルでも上位ビットを選ぶほどVRAMの消費は増えます。Q5_K_MとQ6_Kは、8B級（Llama-3.1-8B）で実際にロードした値が前掲の表にあります（num_ctx=8192でそれぞれ6,372MiB・7,128MiB）。ただし12B級で同じ形式が収まるかは、重みの分だけをモデルサイズ比で伸ばした概算です（文脈の分はパラメータ数の比では伸びないので、別に足して見積もってください）。12B級での実ロードは未検証です。12B級ならQ5_K_MやQ6_Kも収まる余地がある一方、27B級の重いモデルを16GBで狙うなら、QAT版のint4か、通常のPTQで4ビット帯まで落とした量子化が現実解になります。ただしGemmaのQAT 27Bの14.1GBは重みロード分の数字で、ここに推論時のKVキャッシュ分が乗ります。16GBで実際に動くかはコンテキスト長や実装しだいで本記事では未検証のため、あくまで重みサイズの目安として捉えてください。

VRAMがあふれた時に起きること

VRAMに載りきらない量子化を選ぶと、llama.cppやOllamaは収まらない層をシステムRAMへ退避（オフロード）して実行を続けることがあります。当サイト環境のようにRAMに余裕があれば「動くには動く」状態になる場合があります。ただしGPUとRAMの間でデータをやり取りする分、生成速度はGPU単独に比べて大きく落ちます。挙動は環境と設定しだいで、Ollamaでは空きが足りないときにCPUとGPUへ分割して実行されたり、リクエストが待たされたり、先にロード済みのモデルがアンロードされたりします。503が返るのはこれらとは別で、リクエストキューが上限（OLLAMA_MAX_QUEUE、既定512件）を超えた場合です。さらに容量が尽きると、メモリ不足でロードに失敗する場合があります。容量を1段攻めるか守るかは、この失速とのトレードオフです。実際にVRAMからあふれたモデルを2枚目のGPUで動かすとどう変わるかは、2枚目のGPUであふれを解消した実測が具体例になります。

速度と精度のトレードオフ｜用途別にどの量子化を選ぶか

選び方は用途で変わります。コーディングや事実確認のように出力の正確さが効く作業では、精度寄りのQ5_K_M〜Q6_Kを軸に検討したくなります。ただし量子化別のコーディング・事実確認の精度は本記事では測っておらず、引用した公開評価も推論・知識・指示追従ベンチが中心です。これらの用途ではQ4_K_Mを起点に、必要に応じてQ5_K_M〜Q6_Kを自分のタスクで比べてみてください。一方、ロールプレイや長文の下書きのように、多少のゆらぎより速度と容量が優先される場面では、Q4_K_Mで軽く回す判断が合理的。同じVRAMでより大きなモデルを選べる、という別の選択肢も開けます。

用途によっては、ツール呼び出し（function calling）の安定性も判断材料になります。モデルの種類や量子化の深さで挙動が変わることはありますが、量子化別のツール呼び出し安定性は本記事では検証していません。まず対象モデルがツール呼び出しに対応していることを確認し、同じプロンプト・同じツール定義のままQ4_K_Mで試して、不安定なら1段上げて比べてみてください。

整理すると、精度・速度・VRAMの三角形のどこを優先するかで答えが決まります。perplexityをFP16に寄せたくVRAMに余裕があるならQ8_0、バランス重視ならQ5_K_M、容量と速度を取るならQ4_K_M、そして低ビットで精度の底上げが欲しければQAT版。ただし品質をどの指標で見るかで順位は変わります。引用した評価では、平均ベンチスコアの最高はQ5_0の69.92で、Q8_0の69.41もFP16の69.47も上回りました。著者自身が評価分散の可能性に触れている程度の差ですが、「ビットが多いほど必ず良い」とは言えません。

量子化選びでつまずくポイントと対処

最後に、選定で実際にハマりやすい3点を症状・原因・対処の順で挙げます。

ひとつは、ファイルサイズの大きさを「高性能」と取り違えてQ8_0を選び、VRAMに載りきらず失速するケース。原因は、上位ビットほど精度の伸びが鈍るのにVRAMだけ重くなる構造を見落としている点です。対処は、まずQ4_K_MかQ5_K_Mで動かし、VRAMに余裕があると確認できてから上のビットへ上げること。

次に、量子化方式の違いを意識せずQ4_0を掴んでしまう例。引用した8B評価では同じ4ビット帯でK-quant（Q4_K_S/Q4_K_M）が平均スコアでQ4_0を上回っています。対処は、一般的なGGUF配布ではまずK付き（_K_M/_K_S）を優先候補にすること。ただしQ4_0が常に劣るわけではなく、実効性能はバックエンドやハードウェアでも変わります。GemmaのQAT q4_0のように、Q4_0で使う前提で学習されたモデルは別枠で評価してください。

3つめが、同名タグのまま中身が更新され、いつの間にか挙動が変わるパターン。Ollamaなどでは同じタグでも実体（digest）が差し替わることがあります。取り違えを防ぐには、取得時にdigestを控えておくのが確実です。

# モデルを取得し、ローカルのIDとサイズを確認する
ollama pull gemma4:12b
ollama list

# 量子化やパラメータの中身を確認する
ollama show gemma4:12b

ollama listに出るIDの先頭がdigestの一部で、これを記録しておけば、後日同じタグでも中身が変わったかを照合できます。完全なdigestを記録するなら、curl http://localhost:11434/api/tags（ロード中のモデルはcurl http://localhost:11434/api/ps）のJSONにあるdigestフィールドを控えてください。CLIのollama lsやollama psは短縮ID表示になることがあります。

まとめ

量子化フォーマット選びは、精度・速度・VRAMの三角形のどこを取るかに尽きます。判断の順序はシンプルで、まずQ4_K_Mを基準に置く。VRAMに余裕があり精度を盛りたければQ5_K_MやQ8_0へ上げ、27B級のような大型モデルを16GB級の射程へ近づけたい、あるいは低ビットでも精度を落としたくないならQAT版を検討する（14.1GBは重み分の数字で、16GBに収まるかは本記事では未検証）。Llama-3.1-8B-Instructの公開評価では、Q4_K_Mでもperplexityや平均ベンチの低下は小さく出ています。ただしこれは特定モデル・特定ベンチでの結果。本記事では入手性と品質・サイズのバランスからQ4_K_Mを起点に置きますが、公開評価ではQ4_K_Sや5bitも有力な候補で、最終判断は対象モデルとタスクで確かめるのが前提です。最後に、選んだモデルはdigestを控えて取り違えを防ぐ。ここまで押さえれば、自分のVRAM・モデルサイズ・使うコンテキスト長に対して迷わずフォーマットを決められるはずです。

よくある質問

Q. Q4_K_MとQ8_0、どちらを選べば良い？

VRAMに余裕がなければQ4_K_M、perplexityや量子化による挙動変化をFP16へ近づけたくVRAMが足りるならQ8_0です。Llama-3.1-8Bの評価ではperplexityが7.56対7.33とわずかな差で、ファイルは4.58GiB対7.95GiB、当環境で実際にロードしたときのVRAM確保量も5,660MiB対8,861MiB（RTX 5080・num_ctx=8192）と開きます。Llama-3.1-8Bの公開評価ではQ4_K_Mが有力な候補です。ただし品質重視や、推論・指示追従が敏感な用途ではQ5系やQ6_Kも候補に入れ、対象タスクで確認してください。

Q. VRAM 16GBならどの量子化まで動く？

当サイトの検証では16GB級GPU（RTX 5080 16GB）でGemma系の12B級モデルが既定量子化・num_ctx既定で9〜11GiB帯のGPU全体占有で動作しました（長い文脈を取るとこの帯は上へずれます）。12B前後でQ5_K_MやQ6_Kが収まるかは、8B級の実測（num_ctx=8192でQ5_K_M 6,372MiB・Q6_K 7,128MiB）のうち重みの分だけをモデルサイズ比で伸ばした概算です（文脈の分は別に足す必要があります）。12B級での実ロードは未検証です。27B級などより大きいモデルは量子化を下げるかオフロード前提になります。

Q. QAT版は普通の量子化版と何が違う？

通常の量子化が学習後に圧縮するのに対し、QATは学習中に低精度演算をシミュレートして圧縮を織り込む方式です。GoogleはGemmaのQATでQ4_0時のperplexity劣化を54%削減したと公表しており、同じ4ビット帯でも精度が落ちにくいのが特徴。VRAM削減も大きく、Gemma 3 27BはBF16の54GBからQAT int4の14.1GBになります（いずれも重みをロードする分の数字で、推論時に確保する文脈の分は別に乗ります）。

Q. 量子化するとどれくらい精度は落ちる？

モデルによりますが、Llama-3.1-8Bの公開評価ではFP16のperplexity 7.32に対しQ4_K_Mが7.56、平均ベンチは69.47→69.15と小幅でした。4ビットでもこの評価範囲（perplexity・推論/知識/指示追従ベンチ）での低下は小さく出ています。ただし劣化幅はモデル・量子化方式・タスクによって変わるため、対象モデルごとに確認するのが安全です。

参考資料

• llama.cpp 公式: quantize README（量子化フォーマットのbpw・サイズ一覧）
• arXiv:2601.14277（Llama-3.1-8Bの量子化別 perplexity・ベンチスコアの出典）
• Google Developers Blog: Gemma 3 QAT（QATのVRAM削減とperplexity劣化54%削減の出典）
• Hugging Face: google/gemma-4-12B-it-qat-q4_0-gguf（llama.cpp・Ollama向けGGUF版）
• Hugging Face: google/gemma-4-12B-it-qat-q4_0-unquantized（変換・研究向けの半精度チェックポイント）

三値 (1.75〜2.13ビット) まで下げた例として、Qwen3.8-27B をもとにした Bonsai 2 27B をVRAM 16GB で実測した記事がある。標準の llama.cpp では読み込めない形式である点も扱っている。