量子化の形式は「保存の仕方」と「計算の仕方」で分けると整理できる：GGUF・AWQ・GPTQ・FP8・FP4を、公式資料で確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。

先に結論

量子化の名前が並ぶと、同じ種類の選択肢に見えます。でも実際には、次の三つの層が混ざっています。

1. 入れ物（ファイル形式）：GGUF。重みとメタデータ（モデルの付属情報）を一つのファイルにまとめる形式です。
2. 丸め方（重みをどう小さくするか）：AWQ、GPTQ、llama.cppのk-quant（Q4_K_Mなど）。
3. 計算の数の形（実行時にどんな数で掛け算するか）：FP8、FP4（NVFP4、MXFP4）。

見立てです。「どれが一番よいか」ではなく、「自分の道具（推論エンジン）とGPUが、どの形式を読めるか」から決めるのが、現実的な入り口だと思います。理由は、後の表で見るとおり、エンジンとGPUの世代によって、動く形式が違うからです。

前提：量子化とは何か

• 重みは、AIモデルの中にある巨大な数の表です。モデルの大きさの大半は、この重みの数が占めます。
• 量子化は、その数を少ないビット数で持ち直して、ファイルとメモリを小さくする手法です。ビットは、1個の数を表すのに使う0と1の桁数です。16ビットを4ビットにすれば、単純には4分の1になります。
• 代わりに、数が粗くなります。そのぶん答えの質が少し落ちることがあります。落ち方を測る指標として、llama.cppの文書はperplexity（言語モデルの「当たりにくさ」の指標）とKLダイバージェンス（元のモデルの出力とのずれ）を挙げています。ただし、その文書には両者の数値は載っていませんでした。
• キャリブレーションは、丸める前に少量のサンプル文章をモデルに通して、どこを丁寧に丸めるかを決める作業です。形式によって、必要なものと不要なものがあります。

丸め方を比べる：GGUFのk-quant、GPTQ、AWQ

GGUF（入れ物）と、中のk-quant

GGUFの仕様書には、推論用にモデルを保存する二進数のファイル形式で、読み込みと保存が速く、読みやすいように作られた、とあります。以前のGGML、GGMF、GGJTの後継です。ファイルは「ヘッダー、テンソル情報、パディング、テンソルの本体」の順に並びます。ここでテンソルとは、重みの表のことです。

Hugging Faceの文書は、safetensors（テンソルだけを入れる形式）と違って、GGUFはテンソルと標準化されたメタデータの両方を持つ、と説明しています。作ったのは、llama.cppの開発者のggerganov氏とされています。

GGUFの中には、さまざまな量子化の種類を入れられます。Hugging Faceの文書の表では、次のようなものが挙がっていました（1個あたりのビット数は表の値）。

• k-quant：Q2_K（2.625）、Q3_K（3.4375）、Q4_K（4.5）、Q5_K（5.5）、Q6_K（6.5625）
• IQ系（より小さく詰める系統）：IQ1_S（1.56）から IQ4_XS（4.25）まで
• 浮動小数点：F32、F16、BF16
• MXFP4（後述のマイクロスケーリング形式）

古いQ4_0、Q5_0、Q8_0などは「今はあまり使われていない」と同じ文書にあります。ただし、llama.cppの量子化READMEの表にはQ8_0の行があります。

llama.cppのREADMEが載せている、Llama-3.1-8Bの数字は次のとおりです。

見立てです。Hugging Faceの表ではQ4_Kが4.5ビット、READMEの実測ではQ4_K_Mが4.89ビットと、数字が違います。READMEは名前の中身（_Mが何か）を説明していなかったので、理由は確認できていません。モデルの部位ごとに種類を混ぜているためかもしれませんが、これは推測です。ファイルの大きさを知りたいときは、表の「ビット数」ではなく、実際のファイルの大きさを見るのが確実です。

READMEには、imatrix（importance matrix、重要度行列）という仕組みもあります。サンプル文章から「どの重みが答えに効くか」を調べたファイルで、--imatrix で渡すと、量子化による質の低下を減らせる、と書かれています。

GPTQ（論文：2022年）

GPTQは、Frantarら（2022年10月、arXiv:2210.17323）が提案した「ワンショット」の重み量子化です。ワンショットとは、モデルを再学習せず、一回の処理で丸めるという意味です。二次の情報（近似した曲率）を使って、丸めによる誤差が小さくなるように、重みを順に調整します。

論文の要約によると、1750億パラメータのGPT系モデルを、約4GPU時間で3ビットまたは4ビットに圧縮でき、精度の低下は小さいとのことです。1枚のGPUで1750億パラメータのモデルを動かせるようにした、とも書いています。FP16と比べた推論の速さは、A100で約3.25倍、A6000で約4.5倍と報告されています。

AWQ（論文：2023年）

AWQ（Activation-aware Weight Quantization）は、Linら（2023年6月提出、arXiv:2306.00978）の、重みだけを4ビット前後に丸める方法です。「全部の重みが同じように大切なわけではない」という観察から出発します。論文は、重要な重みの約1%を守るだけで、丸めの誤差が大きく減ると報告しています。どの重みが重要かは、重みの値ではなく、活性化（途中の計算で流れる値）の分布から決めます。

論文の要約では、逆伝播（再学習の計算）も再構成も使わないので、キャリブレーションの文章に合わせすぎる問題を避けられる、とあります。論文の著者らは、デスクトップとモバイルのGPUで、Hugging FaceのFP16実装の3倍以上の速さだと述べています。

現場での位置づけ（vLLMの文書から）

• vLLMのAWQのページには「AutoAWQライブラリは非推奨」とあり、同じ機能はvLLMの llm-compressor に取り込まれているので、そちらを勧める、とあります。
• GPTQのページは、ModelCloud.AIのGPTQModelを案内し、4ビットまたは8ビットのGPTQモデルを作れる、と説明しています。AmpereとHopperのNVIDIA GPUでは、MarlinやMachete（高速な計算部品）が使えるとのことです。
• 量子化の案内ページは、まずLLM Compressorを試すことを勧めています。

数の形を比べる：FP8とFP4

AWQやGPTQは、おもに「重みを小さく持つ」工夫です。FP8やFP4は、GPUの計算ユニットが直接扱う「数の形」の話で、重みだけでなく活性化も小さい数で計算することを含みます。

FP8

FP8は、1個の数を8ビットで表す浮動小数点です。2022年の論文（Micikeviciusら、arXiv:2209.05433）が、E4M3（指数4ビット、仮数3ビット）とE5M2（指数5ビット、仮数2ビット）の2種類を提案しています。論文は、FP8での学習が16ビットの学習と同等の品質になったと述べています。

vLLMの文書によると、E4M3の最大値は448、E5M2は57344です。重みと活性化の両方を8ビットにする方式（W8A8）は、Ada、Hopper、Blackwell（演算能力8.9以上）のGPUが必要です。TuringとAmpereでは、重みだけ8ビットのW8A16を、FP8 Marlinカーネルで動かせるとあります。メモリは「2倍減」、スループットは「最大1.6倍」と文書は述べていますが、これは文書の数字で、この記事では測っていません。

FP4：MXFP4とNVFP4

FP4は、1個の数を4ビットで表します。形はE2M1（符号1、指数2、仮数1）で、表せる大きさは0、0.5、1、1.5、2、3、4、6だけです。粗すぎるので、数個ごとに「倍率」を付けて使います。この仕組みを、ここではマイクロスケーリングと呼びます。

NVIDIAのブログは、NVFP4を「4ビットの値＋16個ごとに8ビットの倍率で、1値あたり4.5ビット」と説明しています。僕らの計算です。4＋8÷16＝4.5で、一致します。FP16と比べてメモリが約3.5倍、FP8と比べて約1.8倍減る、とブログは述べています（16÷4.5は約3.6で、ブログの「約3.5倍」と近い値です）。

ブログのDeepSeek-R1-0528の比較では、FP8とNVFP4で、MMLU-PROが85%と84%、GPQA Diamondが81%と80%、AIME 2024が89%と91%でした。NVIDIAは「主要な言語タスクで1%以下の低下」と述べています。これはNVIDIA自身の発表で、第三者の確認は読んでいません。

ハードウェアは、NVFP4がBlackwell世代のGPU向けです。vLLMの表ではMarlin（GPTQ/AWQ/FP8/FP4）の行があり、Turingでは「MXFP4はMarlinで非対応」と注記されていました。

使い分けの目安

見立てです。ここまでの資料から、次のように整理できると思います。

よくあるつまずき

• 「GGUFかAWQか」で迷う：入れ物と丸め方の話が混ざっています。GGUFの中にもk-quantがあり、AWQはまた別の枠組みです。
• vLLMでGGUFを使おうとして遅い：vLLMの文書は「GGUFのサポートは非常に実験的で、最適化が不十分。他の機能と合わないことがある」と書いています。さらに、GGUFの対応は外部プラグイン（vllm-gguf-plugin）に移っていて、先に入れる必要があるそうです。トークナイザー（文章を区切る部品）は、元のモデルのものを使うことが勧められています。
• AutoAWQを新しく採用する：vLLMの文書で非推奨とされています。
• ビット数が小さいほどよいと考える：llama.cppの表でも、サイズだけでなく、書く速さの傾きが形式ごとに違います（例：Q2_K_Sは生成90.01 t/sで、Q4_K_Mの71.93 t/sより速い）。品質は別に測る必要があります。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。数字は、公式ページと論文からそのまま写したものです。
• llama.cppの速度の表は、測定したハードウェアが、取得した文書の中では確認できませんでした。目安にしかなりません。
• NVFP4の精度の表は、NVIDIAが自社ブログで示したものです。第三者の検証は、この記事では読んでいません。
• vLLMの対応表は「変更されることがある」とされています。使う前に最新版を見てください。
• llama.cppのREADMEの「元のサイズ」（8Bで32.1GB）が、どの精度のファイルなのかは、READMEの文面では確認できませんでした。僕らの計算では、8B×4バイトに近い値です。
• 1重みあたりのビット数は、文書によって4.5と4.89のように食い違います。実際のファイルサイズを見るのが確実です。
• 論文の数字（GPTQの約4GPU時間、AWQの約1%など）は論文の主張で、モデルや条件が変わると変わります。
• 精度の低下は、タスクによって違います。日本語や、自分の仕事のデータでの質は、この記事では調べていません。

出典

• Quantization（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• FP8 W8A8（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• GGUF（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• AutoAWQ（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• GPTQModel（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• llama-quantize README（llama.cpp、ggml-org、2026年10月8日確認）
• GGUF specification（ggml、ggml-org、2026年10月8日確認）
• GGUF（Hugging Face Hub Docs、Hugging Face、2026年10月8日確認）
• AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration（arXiv:2306.00978、Linら、2026年10月8日確認）
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers（arXiv:2210.17323、Frantarら、2026年10月8日確認）
• FP8 Formats for Deep Learning（arXiv:2209.05433、Micikeviciusら、2026年10月8日確認）
• Introducing NVFP4 for Efficient and Accurate Low-precision Inference（NVIDIA Technical Blog、NVIDIA、2026年10月8日確認）
• Introducing NVFP4 ...（Edge AI and Vision Alliance、上記ブログの転載、2026年10月8日確認）
• OCP Microscaling Formats (MX) Specification v1.0（Open Compute Project、2026年10月8日確認）

更新履歴

• 2026年10月25日 書き方を直しました。
  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した