量子化（Quantization）

量子化とは「目盛りを粗くする」こと

LLMの中身は、数十億〜数千億個の小数（重み、weights）の集まりです。学習するときは1個あたり16bitや32bitで細かく持っていますが、推論で使うだけなら、そこまで細かい目盛りは要らないことが多いのです。

具体的には、重みをいくつかのまとまり（ブロック）に分け、ブロックごとに「ものさしの長さ」にあたるスケール（scale）を1つ決めます。各重みは「スケール × 小さな整数」で表すので、整数の部分だけを少ないビットで保存すれば済みます。

ブロックを小さくするほど、外れ値に引っ張られずに精度が上がります。そのかわりスケールを保存する分の「おまけ」が増えます。量子化の種類がたくさんあるのは、この精度とサイズの綱引きのバランスが方式ごとに違うからです。

数値形式の図鑑：FP16からNVFP4まで

まずは「1個の数字を何ビットでどう表すか」という数値形式を整理します。浮動小数点（FP）は「符号・指数・仮数」の3つに分けてビットを割り振ります。指数が多いほど大きな数・小さな数を扱え（範囲が広い）、仮数が多いほど細かく表せます（精度が高い）。

FP8の2種類は2022年の論文「FP8 Formats for Deep Learning」で提案され、NVIDIAのHopper世代（H100など）以降のGPUが計算に対応しています。4bitの浮動小数点 E2M1 は、表せる値が 0, 0.5, 1, 1.5, 2, 3, 4, 6 とその負の数だけ。これを単独で使うのは無理があるので、小さなブロックごとにスケールを掛ける「マイクロスケーリング」と組み合わせます。

MXFP4は32個ごとに2のべき乗のスケールを1つ共有し、NVFP4は16個ごとにFP8（E4M3）のスケールと、テンソル全体用のFP32スケールの2段構えで誤差を減らします。NVIDIAはNVFP4の実質サイズを「1値あたり4.5bit」、FP16比で約3.5分の1と説明しています。OpenAIの gpt-oss は、MoE層の重みをMXFP4で量子化した状態で公開され、gpt-oss-120b が80GBのGPU 1枚に収まるとされています。

どれだけ小さくなる？ 計算してみよう

重みのサイズはざっくり「パラメータ数 × 1個あたりのビット数 ÷ 8」バイトです。8B（80億）モデルなら、16bitで 8 × 16 ÷ 8 = 16GB、4bitなら約4GB。ただし実際の量子化ファイルはスケールなどの「おまけ」を含むので、4bit系でも1個あたり4.5〜5bit程度になります。

上のウィジェットは、パラメータ数とビット幅から重みだけのおおよそのサイズを計算し、8GB〜128GBのメモリに対して何%を占めるかをバーで示します。初期状態の「8B・Q4_K_M（約4.9bit）」では約4.9GBと表示され、llama.cpp のドキュメントにある Llama 3.1 8B の Q4_K_M サイズ（4.9GB）とほぼ一致します。選択肢のビット数（Q8_0 は約8.5bit、Q6_K は約6.6bit など）も、同じドキュメントにある Llama-3.1-8B での実測値です。

試しにプリセットを70Bにして、FP16とQ4_K_Mを切り替えてみてください。FP16では約140GBで、80GBのGPUにも入りません。Q4_K_Mにすると約43GBまで縮み、48GBクラスなら収まる計算になります。ただしバーが90%を超えると赤くなるのは、実際には第15章で扱うKVキャッシュや作業用メモリの余裕も必要だからです。

どうやって量子化する？ PTQとQAT

量子化のやり方は、大きく2つに分かれます。

• PTQ（Post-Training Quantization、学習後量子化）: 学習済みのモデルを、あとから丸める。手軽で、配布されている量子化モデルのほとんどはこちら。
• QAT（Quantization-Aware Training、量子化を考慮した学習）: 学習中から「丸められること」を前提に重みを調整する。手間はかかるが、低ビットでも劣化しにくい。

QATの例として、Googleは2025年4月に Gemma 3 のQAT版を公開し、BF16で54GBあった27Bモデルをint4で約14.1GBにして、RTX 3090のような家庭用GPUで動かせるとしました。Googleによると、約5,000ステップのQATで、Q4_0に量子化したときのパープレキシティの悪化を54%減らせたそうです。前述の gpt-oss も、MXFP4にした状態で学習の後半（post-training）を行っています。

いちばん単純なPTQは、ブロックごとに最大値でスケールを決めて四捨五入するだけの方法（RTN: round-to-nearest）です。8bitならこれでも十分なことが多いのですが、4bit以下では工夫が必要になります。代表的な方式を見ていきましょう。

どれも「誤差をゼロにする」のではなく、「出力に効くところの誤差を優先して減らす」工夫だと考えると整理しやすくなります。

重みだけじゃない：活性化とKVキャッシュの量子化

量子化の対象は重みだけではありません。表記として「W4A16」のような書き方がよく使われます。Wは重み（weights）、Aは活性化（activations、計算途中の値）のビット数です。

• W4A16: 重みだけ4bit、計算は16bit。GPTQ・AWQ・GGUFの多くはこれ。メモリと読み込み量が減る。
• W8A8（FP8やINT8）: 重みも活性化も8bitで、掛け算そのものを8bit演算器で行う。サーバーでの大量処理（スループット）に効く。
• KVキャッシュの量子化: 会話の文脈を覚えておくKVキャッシュを8bitなどにする。vLLMは kv_cache_dtype="fp8"、llama.cpp は --cache-type-k q8_0 のような指定ができます。

長い文脈や多人数の同時処理では、重みよりKVキャッシュのほうが大きくなることもあります。その計算は第15章のウィジェットで確かめられます。

なぜ速くなるのか、いつ速くならないのか

文章を1トークンずつ生成する段階（デコード）では、GPUやCPUは「計算」より「重みをメモリから読み出すこと」に時間を取られています。重みが3分の1になれば、読み出す量も3分の1。だから量子化すると生成が速くなりやすいのです。

llama.cpp のドキュメントに載っている Llama-3.1-8B の計測例では、同じ環境で F16 の生成速度が毎秒約29トークン、Q4_K_M が約72トークンでした。一方、プロンプトを一気に読む処理（プロンプト処理）は F16 が約923、Q4_K_M が約822トークン毎秒と、むしろ F16 のほうが速くなっています。こちらは計算量が支配的で、丸めた値を戻す手間が効いてくるためです。

また、FP8やFP4の「計算」を速くするには、それに対応した演算器を持つハードウェアが必要です。対応していないGPUでは、読み込み時に16bitへ戻して計算するため、メモリは減っても計算は速くなりません。ハードウェアの違いは第17章で扱います。

どれを選べばいい？

flowchart TD
  A["どこで動かす？"] --> B["手元のPC・Mac"]
  A --> C["GPUサーバー"]
  B --> D["GGUF
Q4_K_M から試す"]
  D --> E["余裕があれば
Q5_K_M・Q6_K"]
  C --> F["対応GPUなら
FP8 W8A8"]
  C --> G["メモリ重視なら
AWQ・GPTQ 4bit"]
  C --> H["最新GPUなら
NVFP4・MXFP4"]

ローカルで試すなら、まずは GGUF の Q4_K_M が定番の出発点です。Q8_0 はほぼ劣化なし、Q2 台は小さいけれど劣化がはっきり出やすい、と覚えておくとよいでしょう。llama.cpp の llama-quantize の一覧では、Llama-3-8B で Q8_0 のパープレキシティ（予測の当たらなさ）の悪化は +0.0026、Q4_K_M は +0.1754、Q2_K は +3.5199 と示されています。

同じ「4bit」でも、モデルの大きさで影響は変わります。大きなモデルほど量子化に強い傾向があるので、「小さいモデルを高精度で」より「大きいモデルを4bitで」のほうが賢いことも珍しくありません。最後は、自分の用途で実際に答えを比べるのがいちばん確かです。