量子化フォーマットとは、LLMの重みを低ビットに圧縮し容量と速度を稼ぐ方式。
Hugging Faceで同じモデルのページを開くと、量子化の種類がずらりと並びます。Q4_K_M、Q5_K_M、Q6_K、Q8_0、さらにQAT版――名前だけでは何がどう違うのか、すぐには判断できません。ファイルサイズは数GB単位で変わり、選び方を誤ればVRAMからあふれて速度が落ちる。逆に容量を惜しんで低ビットを選べば、精度が削られることもある。この記事では、bpw・ファイルサイズ・perplexity・VRAM消費という4つの実数から、用途と環境に合わせて量子化を決める基準を整理します。
- 量子化はbpw(重み1個あたりのビット数)でファイルサイズが決まり、精度も大きく左右される
- 実用域はQ4_K_M〜Q8_0。迷ったら広く使われるQ4_K_Mを起点にしつつ、公開評価ではQ4_K_SやQ5_0も有力候補
- 低ビットでも精度を保ちたいなら、学習時に圧縮を織り込むQAT版が有力
量子化フォーマットとは|bpwがファイルサイズとVRAMを左右する仕組み
元のLLMは、多くがFP16(16ビット浮動小数点)で重みを保持しています。量子化とは、この重みをより少ないビット数で表現し直す圧縮処理のこと。重み1個あたりのビット数を表す指標がbpw(bit per weight)で、これが小さいほどファイルは軽くなり、VRAM消費も減ります。代わりに、表現できる数値の刻みが粗くなるため、精度はわずかに削られる。ファイルサイズはbpwと強く連動しますが、速度と精度の動きは量子化方式やモデル、実行バックエンドによって変わり、単純な比例にはなりません。
なぜサイズとVRAMと速度が同時に動くのでしょうか。モデルの重みはまずストレージ上のファイルとして存在し、推論時にVRAMへ読み込まれます。bpwが下がればファイルが小さくなり、VRAMに載せる量も減る。さらにローカル推論では、GPUがメモリから重みを読み出す帯域がボトルネックになりやすく、データ量が減ること自体が生成速度の向上につながりやすい。容量を削る選択は、速度にも効いてきます。
GGUFとllama.cppの関係
ローカルでこれらの量子化を実際に動かす土台が、llama.cppと、その標準フォーマットであるGGUF。GGUFは量子化済みの重みを1ファイルにまとめた形式で、Q4_K_MやQ8_0といった種類は、このGGUFの中の量子化スキームを指します。llama.cppはWindows(CUDA 12/13)、Linux(ROCm・Vulkan)、Apple Siliconなど幅広い環境向けにビルドが提供され、OllamaやLM Studioも内部でこの仕組みを使っています。「どの量子化を選ぶか」は、llama.cppが扱えるGGUFのどのスキームを選ぶか、と言い換えられます。
Q4_K_M・Q5_K_M・Q6_K・Q8_0の違いを一覧で比較
実用上よく使われる4つのフォーマットを、bpwとファイルサイズで並べると違いが一目で分かります。次の表はllama.cpp 公式 quantize READMEが公開しているLlama-3.1-8Bでの値です。
| フォーマット | bpw(ビット/重み) | ファイルサイズ | 傾向 |
|---|---|---|---|
| Q4_K_M | 4.8944 | 4.58GiB | 容量最小・実用の基準 |
| Q5_K_M | 5.7036 | 5.33GiB | サイズと精度のバランス |
| Q6_K | 6.5633 | 6.14GiB | FP16に近い(8B評価) |
| Q8_0 | 8.5008 | 7.95GiB | フル精度に最接近 |
数字を見ると、Q4_K_Mの4.8944bpwからQ8_0の8.5008bpwまで、ビット幅はほぼ倍。ファイルサイズも4.58GiBから7.95GiBへと開きます。一方で精度の劣化は、ビット幅の差ほど大きくありません。ここが量子化選びの肝で、上位ビットほど「払うVRAMの割に得られる精度」が逓減していく構造になっています。
K-quant(_K_M / _K_S)の中身と「_M」「_S」の意味
名前に付く「_K」は、K-quantと呼ばれる方式を指します。K-quantはllama.cpp 公式によれば256値を1つのスーパーブロックとしてまとめ、その中をさらに小さなサブブロックに分け、ブロックごとにスケール(倍率)と最小値を持たせる構造。限られたビット数を、値のばらつきが大きい部分へ重点的に配分できるため、単純な丸めよりも精度が保たれます。末尾の「_M」「_S」はMedium・Smallの略で、同じビット帯でも_Mの方がやや多くビットを使い精度寄り、_Sは容量寄り。Q4_0などのレガシー量子化より、K-quantの方が同じサイズで精度が高い傾向にあります。Q4_K_M・Q8_0・FP16の速度とVRAMをさらに細かく実測した結果は前身の比較記事にまとめています。
精度はどれだけ落ちるのか
量子化で精度がどれだけ削られるかは、perplexity(予測の当てにくさ、低いほど良い)とベンチマーク平均スコアで測れます。arXiv:2601.14277のLlama-3.1-8B評価では、次の結果が報告されています。
| フォーマット | perplexity | 平均ベンチスコア |
|---|---|---|
| FP16(基準) | 7.32 | 69.47 |
| Q4_K_M | 7.56 | 69.15 |
| Q5_K_M | 7.40 | — |
| Q6_K | 7.35 | — |
| Q8_0 | 7.33 | 69.41 |
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ビットまで圧縮しても精度がここまで保たれるのは、K-quantが効いている証拠。ただしこれはLlama-3.1-8Bという特定モデルの数値で、モデルのサイズや構造が変われば劣化幅も変わります。他モデルへこの値をそのまま当てはめるのは避けてください。
VRAMに余裕があり精度を盛りたいならQ5_K_MやQ6_K、限界までフル精度へ近づけたいならQ8_0。Q4_K_Mを起点に上下を調整する、と考えると選び分けがすっきりします。
QATが低ビットでも精度を保てる理由|Gemmaの事例
ここまでは、学習し終えたモデルを後から圧縮するPTQ(ポストトレーニング量子化)の話です。これとは別の発想が、QAT(Quantization-Aware Training/量子化対応学習)。学習後ではなく、学習の最中に低精度演算をシミュレートして圧縮の影響を織り込む手法です。あらかじめ「4ビットになる前提」で重みを整えるため、同じビット幅でも精度が落ちにくくなります。
効果は数字に表れています。GoogleはGemma 3のQAT版で、int4化によるVRAM削減を公表しました。
| モデル | BF16でのVRAM | QAT int4でのVRAM |
|---|---|---|
| Gemma 3 1B | 2GB | 0.5GB |
| Gemma 3 4B | 8GB | 2.6GB |
| Gemma 3 12B | 24GB | 6.6GB |
| Gemma 3 27B | 54GB | 14.1GB |
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%削減できる。(Google Developers Blog: https://developers.googleblog.com/en/gemma-3-quantized-aware-trained-state-of-the-art-ai-to-consumer-gpus/)
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 3でコードを外に出さずに使うAI環境の解説が詳しい。ただし「QATなら4ビットでも品質劣化ゼロ」と一般化はできません。Googleが数値で示しているのはGemma 3 QATでのperplexity劣化54%削減で、Gemma 4についてはQAT版の提供と品質改善を説明しているものの、同じ54%という値は示していません。低ビット側の利点が大きいケースで効く、と捉えるのが正確です。
検証環境と16GBで動かせる量子化の現実解
理論値が分かったところで、実際に手元のGPUへ載せるとどうなるか。当サイトの検証環境(RTX 5080=VRAM 16GB、これにRTX 5060 Ti 16GBをOculinkで足した2枚構成/システムRAM 96GB/NVIDIAドライバ610.47/Ollama 0.30.7、2026年6月18日に計測)で、各モデルを既定の量子化のまま動かしたときのVRAM占有と生成速度を計測しました。測定は全モデル共通の日本語プロンプトを使い、生成上限512トークン・think=falseに統一。tok/sはOllama APIが返すeval_count÷eval_durationで算出し、各モデル3回のうちIQR(四分位範囲)で外れ値を除いた中央値を採りました。temperature・seed・num_ctxはOllama既定のままで固定していないため、ここは厳密な再現比較ではなく既定設定どうしの参考比較です。各モデルは個別にロードして計測しています。各モデルはロード後にOllamaのAPI(/api/ps)でGPUへ載っていること(size_vram)を確認し、VRAM占有はnvidia-smiが返すGPU全体の使用量、モデルのdigestも控えて同名タグの中身差し替えに備えています。ここで示すのは同一モデルを量子化別に振った比較ではなく、各モデルを既定設定で動かしたときの動作エンベロープです。なお計測時点のOllamaは0.30.7で、本稿公開時点では0.30.10が出ています。推論エンジン(llama.cpp)の更新で速度は変わりうるため、数値は0.30.7時点の参考値として読んでください。
たとえばGemma 4 12B(Ollama: gemma4:12b)は44.52 tok/s、VRAM占有は8542MiB(約8.34GiB)。同じ12B級のGemma 3 12B(Ollama: gemma3:12b)は47.8 tok/s、9430MiB(約9.21GiB)でした。Gemma 4 12Bを16GBで動かす構成の詳細はRTX 5080/5060 Tiでの実測記事でも扱っています。なお、この占有値はnvidia-smiのmemory.used、つまりデスクトップ表示などのベースラインを含むGPU全体の使用量で、モデル単体のロード増分とは別物。それでも12B級モデルが概ね8〜10GiB帯のGPU全体占有で動くことは、検証で確認できた範囲です(それより大きい領域は未検証)。
16GBで安全圏と攻める量子化の線引き
ここから示すのは同一モデルを量子化別に比較した結果ではなく、各モデルの既定量子化タグを16GB級GPU環境で動かしたときの参考値です。16GBという容量は、12B前後のモデルなら量子化に余裕を持てるラインです。先のLlama-3.1-8Bの例ではQ8_0のファイルがQ4_K_Mの約1.7倍でしたから、同じモデルでも上位ビットを選ぶほどVRAMの消費は跳ね上がります。ただし本記事で実ロードを確認したのは既定量子化の12B級2モデルで、Q5_K_M/Q6_Kが収まるかはファイルサイズ比からの見積もりです(実ロードは未検証)。12B級ならQ5_K_MやQ6_Kも収まる余地がある一方、27B級の重いモデルを16GBで狙うなら、QAT int4のような圧縮の効いたフォーマットか、低ビット量子化が現実解になります。ただしGemmaのQAT 27Bの14.1GBは重みロード分の数字で、ここに推論時のKVキャッシュ分が乗ります。16GBで実際に動くかはコンテキスト長や実装しだいで本記事では未検証のため、あくまで重みサイズの目安として捉えてください。
VRAMがあふれた時に起きること
VRAMに載りきらない量子化を選ぶと、llama.cppやOllamaは収まらない層をシステムRAMへ退避(オフロード)して実行を続けることがあります。当サイト環境のようにRAMが96GBあれば「動くには動く」状態にはなる。ただしGPUとRAMの間でデータをやり取りする分、生成速度はGPU単独に比べて大きく落ちます。挙動は環境と設定しだいで、Ollamaでは空きが足りないときにリクエストが待たされたり、先にロード済みのモデルがアンロードされたり、過負荷時に503やロード失敗になることもある。さらに容量が完全に尽きるとロード自体が失敗し、いわゆるOOM(メモリ不足)で停止します。容量を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の三角形のどこを優先するかで答えが決まります。精度を最大化したくVRAMに余裕があるならQ8_0、バランス重視ならQ5_K_M、容量と速度を取るならQ4_K_M、そして低ビットで精度の底上げが欲しければQAT版。この4つの軸で考えれば、自分の環境に対する解は自然と絞れます。
量子化選びでつまずくポイントと対処
最後に、選定で実際にハマりやすい3点を症状・原因・対処の順で挙げます。
ひとつは、ファイルサイズの大きさを「高性能」と取り違えてQ8_0を選び、VRAMに載りきらず失速するケース。原因は、上位ビットほど精度の伸びが鈍るのにVRAMだけ重くなる構造を見落としている点です。対処は、まずQ4_K_MかQ5_K_Mで動かし、VRAMに余裕があると確認できてから上のビットへ上げること。
次に、古いレガシー量子化(Q4_0など)を掴んでしまう例。同じ4ビット帯でもK-quant(Q4_K_M)の方が精度が高いため、知らずにQ4_0を選ぶと損をします。対処は、配布ページでK付き(_K_M/_K_S)のファイルを選ぶこと。
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版を検討する。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、フル精度に近づけたくVRAMが足りるならQ8_0です。Llama-3.1-8Bの評価ではperplexityが7.56対7.33とわずかな差で、ファイルは4.58GiB対7.95GiBと大きく開きます。Llama-3.1-8Bの公開評価ではQ4_K_Mが有力な候補です。ただし品質重視や、推論・指示追従が敏感な用途ではQ5系やQ6_Kも候補に入れ、対象タスクで確認してください。
Q. VRAM 16GBならどの量子化まで動く?
当サイトの検証ではRTX 5080(16GB)で12B級モデルが既定量子化で8〜10GiB帯のGPU全体占有で動作しました。12B前後ならQ5_K_MやQ6_Kも収まる余地があり、27B級などより大きいモデルは量子化を下げるかオフロード前提になります(検証範囲外は未確認)。
Q. QAT版は普通の量子化版と何が違う?
通常の量子化が学習後に圧縮するのに対し、QATは学習中に低精度演算をシミュレートして圧縮を織り込む方式です。GoogleはGemmaのQATでQ4_0時のperplexity劣化を54%削減したと公表しており、同じ4ビット帯でも精度が落ちにくいのが特徴。VRAM削減も大きく、Gemma 3 27Bは54GBから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・サイズ一覧)
- Google Developers Blog: Gemma 3 Quantization-Aware Trained models
- Hugging Face: google/gemma-4-12B-it-qat-q4_0(Gemma 4 QAT版)
- arXiv:2601.14277: ローカルLLM量子化の品質評価(プレプリント)
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

