量子化・モデル形式の用語集:GGUF の Q4_K_M は何が違うのか

ローカルでモデルを動かすときに必ず出てくる「量子化」と「モデル形式」の用語を、 当サイトの記事とVRAM別の早見表を読むのに必要な範囲でまとめました。 定義はこのサイトの編集部が書いたもので、AIモデルが生成した文章ではありません。 ベンチマークのスコアの読み方はベンチマーク用語集にあります。

量子化とは何か

モデルの重み(パラメータ)は、学習時には1つあたり16ビット(BF16 / FP16)や32ビットで 保存されています。量子化は、この重みを4ビットや8ビットなど少ないビット数で表し直して、 ファイルサイズと必要メモリを減らす手法です。ビット数を減らすほど小さく速くなりますが、 精度(出力の質)は少しずつ落ちます。

必要メモリのおおよその目安は「パラメータ数 × 1パラメータあたりのビット数 ÷ 8」で 計算できます。例えば70億(7B)パラメータのモデルは、BF16なら約14GB、8ビットなら約7GB、 4ビットなら約3.5〜4GBです。当サイトの「動作環境」の表と早見表は、配布ファイルの実サイズに 実行時のオーバーヘッドとして20%を上乗せした値を「必要メモリの目安」として載せています。

ビット数(目安) 7Bモデルのサイズ 精度の目安 使いどころ
16ビット(BF16 / FP16) 約14GB 元の精度 精度が最優先のとき、量子化前の基準
8ビット(Q8_0 / FP8 / INT8) 約7GB ほぼ劣化なし メモリに余裕があるとき
5〜6ビット(Q5_K_M / Q6_K) 約5〜6GB わずかに劣化 精度とサイズのバランス
4ビット(Q4_K_M / IQ4_XS / AWQ / GPTQ) 約4GB 実用上ほぼ問題なし 最も一般的な選択
2〜3ビット(Q3_K / IQ2 / IQ3) 約2.5〜3.5GB 劣化が目立ち始める 大きなモデルを無理やり載せるとき

GGUF と llama.cpp の量子化の名前

GGUF は llama.cpp 系のツール(Ollama、LM Studio、KoboldCpp など)が読む モデルファイルの形式です。1つのファイルに重み・トークナイザ・設定がまとまっており、 CPUだけでも、GPUと組み合わせても動かせます。Hugging Face で「◯◯-GGUF」という名前の リポジトリには、同じモデルを様々なビット数で量子化したファイルが並んでいます。

ファイル名に付く Q4_K_M のような記号の読み方は次のとおりです。

  • 先頭の数字(Q4・Q5・Q8): 1重みあたりのおおよそのビット数。
  • K: 「K-quant」と呼ばれる方式で、重みをブロックごとに扱い、重要な部分に
    多めのビットを割り当てます。Q4_0 のような旧方式より同じサイズで精度が良いです。
  • S / M / L: 同じビット数の中でのサイズと精度のバランス(Small / Medium / Large)。
    Q4_K_M は「4ビット、K-quant、中サイズ」で、迷ったらまずこれと言われる定番です。
  • IQ(IQ4_XS・IQ3_M・IQ2_XXS など): 「importance matrix(imatrix)」を使う、より新しい
    方式。同じビット数の Q 系より小さくできる一方、CPUでの推論はやや遅くなることがあります。 XXS XS S M はサイズの段階です。
  • Q8_0: 8ビット。ほぼ劣化が無く、量子化の基準としてもよく使われます。
  • imatrix: 量子化するときに「どの重みが重要か」を測るための補助データ。リポジトリに
    imatrix.dat として置かれていることがありますが、実行には不要です。

当サイトの必要メモリの計算では、量子化の名前ごとに実測に近い「1重みあたりのビット数」 (例: Q4_K_M ≒ 4.8ビット、Q8_0 ≒ 8.5ビット)を使っています。名前どおりの4ビット・8ビット ぴったりにならないのは、ブロックごとのスケール値などが加わるためです。

GGUF 以外の形式

形式 主な実行環境 特徴
safetensors(BF16 / FP16) Transformers、vLLM、SGLang Hugging Face の標準形式。量子化前の重みそのもので、最もサイズが大きい
AWQ vLLM、SGLang、Transformers 4ビットの量子化方式。GPU向けで、活性化の分布を見て重要な重みを守る
GPTQ vLLM、ExLlama、Transformers 4ビット(〜8ビット)の量子化方式。GPU向けの古参で対応環境が広い
EXL2 / EXL3 ExLlamaV2 / ExLlamaV3 NVIDIA GPU専用。ビット数を小数点で細かく指定でき、限られたVRAMに大きなモデルを収めやすい
MLX MLX(Apple Silicon の Mac) Mac のユニファイドメモリ向け。「mlx-community」が変換版を多数配布している
FP8 vLLM、SGLang(Hopper / Ada 以降のGPU) 8ビット浮動小数点。最近のGPUでは速度も出る。公式配布が増えている
NVFP4 / MXFP4 TensorRT-LLM、vLLM(Blackwell 世代のGPU) 4ビット浮動小数点。最新GPUのハードウェア支援を使う
bitsandbytes(bnb 4bit / 8bit) Transformers 読み込み時にその場で量子化する方式。変換済みファイルが無くても使えるが、速度は出にくい
INT4 / INT8 各種 整数量子化の総称。上の方式の多くはこの一種

モデルの大きさを表す言葉

  • パラメータ数(7B・27B・552B): B は billion(10億)。当サイトの記事では
    「70億」のような換算をコードで確定させて書いています。
  • MoE(Mixture of Experts)と「A4B」のような表記: 36B-A4B は「総パラメータ36B、
    そのうち1トークンの処理で実際に使う(active)のは4B」という意味です。必要メモリは 総パラメータ数(36B)で決まり、速度はアクティブ数(4B)に近い挙動になります。 「小さいGPUで動く」とは限らない点に注意してください。
  • コンテキスト長: 一度に扱える入力+出力のトークン数。長くするほど後述の
    KVキャッシュが増えます。

KVキャッシュとコンテキスト長 ―― 表の数値より多く要る理由

推論中は、モデル本体のほかに KVキャッシュ(それまでのトークンの中間状態)を メモリに置きます。この量はコンテキスト長と同時処理数に比例して増え、長い文脈 (数万〜数十万トークン)を使うと、モデル本体と同じくらいになることもあります。

当サイトの「必要メモリの目安」はこの分を一律20%として見込んだ概算です。長い文脈を 使う・複数の要求を同時に処理する場合は、表の値より余裕を持ってください。多くの推論 エンジンには KVキャッシュ自体を8ビットや4ビットに量子化する設定もあります。

当サイトの表の読み方

  • 「動作環境」の表と早見表の必要メモリはモデルカードの公称値ではなく、配布ファイルの
    実サイズから当サイトが機械的に算出した値です(算出方法は編集方針)。
  • 「手持ちのVRAM」の階層(8GB / 12GB / 16GB / 24GB …)は、その量子化がその階層に
    収まる最小の階層を示します。24GBのGPUなら、8GB〜24GBの階層すべてが対象です。
  • CPU実行やAppleシリコンのユニファイドメモリでは、VRAMの代わりにシステムメモリが
    同じ役割をします。数値の読み方は同じです。