形式マップ — GGUF / MLX / GPTQ / AWQ / FP8

なぜ形式が複数あるのか

Hugging Face で気に入ったモデルを検索すると、同じモデル名に -GGUF、-MLX-4bit、-AWQ、-FP8-dynamic といった複数のリポジトリがぶら下がっています。これは「同じ中身の別パッケージ」ではありません。走らせるエンジンとハードウェアが違うので、別々のファイルが必要なのです。

ファイル形式とは、次の 3 つを束ねたセットだと考えてください。

• 量子化手法 — どう丸めたか。第 5 章の RTN / GPTQ / AWQ / NF4 がここに入ります
• 格納形式 — 丸めた結果をディスク上でどう並べるか。第 6 章で開けた GGUF の Q4_K ブロックがここです
• 対応カーネル — その並びを読んで行列積を回す GPU コード

初心者がまず混乱するのは、前の 2 つが別のレイヤーの話だという点です。Q4_K_M は GGUF という格納形式の名前で、GPTQ 4bit は量子化手法の名前です。だから「Q4_K_M と GPTQ 4bit はどちらが上か」という問いは、そのままでは比べられません（実際 AutoRound のように、手法は GPTQ 系で出力形式は GGUF、という組み合わせも存在します）。

そして 3 つ目のカーネルが、実務では一番きつい制約になります。vLLM のソースには「候補のカーネルを性能順に上から試し、compute capability やテンソルの形が合わなければ次を試し、全部落ちたら例外を投げる」という実装が入っています（Failed to find a kernel that can implement the WNA16 linear layer）。形式が用意されていることと、そのハードで速く動くことは、まったく別の話なのです。

手元で動かす 2 つ — GGUF と MLX

GGUF は llama.cpp 系の形式です。第 6 章で見たとおり、重みだけでなくトークナイザやチャットテンプレートまで 1 ファイルに同梱するので、URL 1 本で配れます。もう 1 つの強みは llama.cpp の README が機能として挙げている次の一文です。

CPU+GPU hybrid inference to partially accelerate models larger than the total VRAM capacity

つまり VRAM に収まりきらないモデルを、層単位で GPU と CPU に分けて走らせられる。これは GGUF 系だけの持ち味で、VRAM 容量を超える大きさのモデルでも起動できる理由です（GPU に載らなかった層は CPU で計算するので、そのぶん遅くなります。どれだけ遅いかは第 8 章で扱います）。GGUF を動かす部分は、Ollama も LM Studio も実体がこの llama.cpp です。Ollama の量子化機能は内部で llama-quantize バイナリを呼び出しているだけで、中身は完全に同じものです。

「世の中の記事がだいたい Q4_K_M なのはなぜか」にも一次情報の答えがあります。llama.cpp の -hf オプションは量子化名を省略すると Q4_K_M を取りに行き、Hugging Face 経由で GGUF を引く Ollama も既定が Q4_K_M です（どちらも公式ドキュメントに明記）。誰かが選んだのではなく、ツールの既定値がそうなっているのです。

一方 MLX は Apple 純正の配列フレームワークで、Apple Silicon 専用です。最大の違いは unified memory です。MLX 公式ドキュメントはこう書いています。

In MLX, rather than moving arrays to devices, you specify the device when you run the operation.

CUDA の .to("cuda") に相当する「GPU へ転送する」操作が存在しません。したがって「VRAM に収まるか」という判定が、そのまま「システム RAM に収まるか」に置き換わります。36GB の Mac は 36GB の GPU メモリを持っているようなものだ、というのが MLX を選ぶ最大の理由です。ただし全量が GPU に回るわけではありません。実際の上限は MLX が max_recommended_working_set_size（性能を落とさずに確保できるメモリ量）として報告する値で、これを超えたいときだけ手動で引き上げます（第 8 章）。

MLX 形式の実体は GGUF のような単一バイナリではなく、safetensors + config.json のディレクトリです。量子化の設定は config.json に {"group_size": 64, "bits": 4, "mode": "affine"} のような形で書かれます。ここが GGUF との思想差で、GGUF が Q4_K_M というレシピ名を配るのに対し、MLX はビット数とグループサイズを利用者が直接指定する設計です。既定は affine モード・group 64・4bit で、mlx_lm.convert に -q を付けるだけでこの設定になります。

mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q

配布は Hugging Face の mlx-community に集まっており、mlx-lm の既定モデルも mlx-community/Llama-3.2-3B-Instruct-4bit です。LM Studio では同じモデルの GGUF 版と MLX 版が並んで表示されますが、量子化の呼び名が形式ごとに違います。LM Studio の API が返す値を見ると、MLX は "quantization": "4bit"、GGUF は "quantization": "Q4_K_M" です。同じ「4 ビット」を指していても命名体系が別物だと分かっていないと、比較のしようがありません。

Mac なら MLX 一択、というわけでもありません。2026-08 時点で LM Studio の並列リクエスト処理（複数の同時リクエストをまとめて回す機能）は llama.cpp エンジン側だけの対応で、MLX は「coming soon」と公式に書かれています。1 人で対話するなら MLX、Mac を小さなサーバにするなら GGUF、という分かれ方になります。

サーバで配る形式 — GPTQ / AWQ / FP8

複数ユーザに配信する側の形式は、NVIDIA GPU と vLLM を前提に発達しました。

GPTQ と AWQ の成果物は safetensors + config.json で、quantization_config に "quant_method": "awq" のような印が付きます。GGUF ではありません。どちらも W4A16（重み 4bit・活性化 16bit）で、vLLM の対応表（2026-08 時点）では GPTQ が Volta 以降、AWQ が Turing 以降、いずれも AMD GPU は非対応です。速さの源は専用カーネルで、代表格の Marlin は FP16 × INT4 の行列積カーネルとして「バッチサイズ 16〜32 まで理想に近い 4 倍の高速化」を掲げています（これは Marlin 作者リポジトリの README の主張で、vLLM に統合された版での実測値ではありません）。Hopper 向けにはその後継の Machete が用意されています。

ここで最頻の落とし穴を先に潰しておきます。量子化モデルを HF Transformers で読み込んだだけでは速くなりません。llm-compressor の FAQ が明言しています。「forward passes of the model are done with the model decompressed」— つまり読み込み時に展開され、計算は 16bit で行われます。速度を取りたいなら vLLM のような推論サーバで走らせる必要があります。

bitsandbytes は毛色が違います。事前に量子化ファイルを作らず、モデルをロードする瞬間に量子化する（on-the-fly）ので最も手軽で、NF4 は QLoRA の標準です。ただし速度は期待してはいけません。Hugging Face の手法選択ガイドは bitsandbytes の欠点欄に Inference speedup isn't guaranteed. と書いています。裏付けとして LLM.int8() 論文の実測では、model dimension 4096（6.7B 相当）で 16bit 比 0.86 倍、つまり遅くなります。速くなるのは 13B・175B クラスの大きな行列積に入ってからです。bitsandbytes はメモリと手軽さと学習のための形式で、速度のための形式ではありません。

compressed-tensors は、乱立を収めるために作られた統一形式です。Hugging Face の定義をそのまま引きます。

compressed-tensors extends safetensors files to compressed tensor data types to provide a unified checkpoint format for storing and loading various quantization formats such as dense, int-quantized (int8), float-quantized (fp8), and pack-quantized (int4 or int8 weight-quantized packed into int32).

この枠の中で FP8 W8A8 と INT8 W8A8 が配られています。要件はハードウェア世代でくっきり切れます。FP8 の W8A8 演算は compute capability 8.9 以上（Ada Lovelace・Hopper）で、vLLM は「メモリ要件の 2 倍削減と最大 1.6 倍のスループット改善」と書いています。INT8 W8A8 は 7.5 以上（Turing 以降）ですが、compute capability 10.0 以上（Blackwell）では INT8 が非対応で、公式ドキュメントが「FP8 を使え」と警告しています。「新しい GPU なら何でも通る」という直感の逆です。llm-compressor が示す世代別の推奨はこうです — Blackwell は NVFP4 か MXFP4、Hopper は W8A8-FP8、Ampere は W4A16、Turing は W8A8-INT8。

4bit の浮動小数点形式（第 2 章の MXFP4）が実配布された例が gpt-oss です。公式 README は「MoE 重みを MXFP4 量子化で post-train し、120b は単一の 80GB GPU で、20b は 16GB のメモリ内で動く」と述べ、MoE 層以外は BF16 のままだと明記しています。モデルカードは「重みは 1 パラメータあたり 4.25 ビット」「MoE 重みは総パラメータ数の 90% 以上」と書いており、なぜ 20B が 16GB に収まるのかがこの 2 行で説明できます。Transformers 側の要件は compute capability 7.5 以上と Triton 3.4 以上で、満たさない場合は BF16 にフォールバックし「MXFP4 の約 4 倍のメモリ」を要求します。ただしこの 7.5 は「Triton カーネルで動く」条件であって、FP4 のネイティブ Tensor Core があるという意味ではありません。

同じ「4bit」でも中身と実効 bpw が違う

形式を跨いで比べるとき、名前の「4bit」は当てになりません。比べるべきは実効 bpw（bits per weight = 重み 1 個あたりに実際に使われるビット数）です。第 3 章で見たとおり、量子化は必ずブロックごとのスケールを別に持つので、その分がここに乗ります。

言葉で言えば「1 ブロックに使った総ビット数を、そのブロックが表す重みの個数で割る」。式にするとこうなります。

実効 bpw = 要素 1 個のビット数 + （ブロック 1 個の付属データのビット数 ÷ ブロックの要素数）

数値を入れてみます（以下はいずれも公式が示すブロック構造から起こした計算例です）。MLX の affine 4bit・group 64 は、64 要素ごとに scale と bias を入力と同じ 16bit で 1 つずつ持ちます。したがって 4 + (16 + 16) ÷ 64 = 4.5 bpw。AWQ の既定は 4bit・group 128 で zero_point あり（非対称）なので、128 要素ごとに FP16 の scale と 4bit の zero point が付いて 4 + (16 + 4) ÷ 128 = 4.156 bpw。GPTQ は同じ group 128 でも sym の既定が True（対称量子化）で zero point を持たないため、4 + 16 ÷ 128 = 4.125 bpw です。Marlin が高速化の上限として書いている「3.87 倍」はこの 4.125 bpw に対する 16 ÷ 4.125 で、数字がぴったり合います。MXFP4 は 32 要素ごとに 8bit の共有スケール 1 個だけなので 4 + 8 ÷ 32 = 4.25 bpw です。

圧縮率も同じ考え方で出せます。

圧縮率（BF16 比） = 16 ÷ 実効 bpw

MLX の 4bit なら 16 ÷ 4.5 = 約 3.56 倍。「4bit だから 4 分の 1」ではありません。mlx-community の配布ファイルを実測すると 4.5005〜4.5008 bpw で、この式どおりの値になります。

W4A16 と W8A8 — どこを量子化するかで効き方が変わる

サーバ向けの形式名にはほぼ必ず W4A16 や W8A8 という記号が付いています。表記の意味は第 3 章のとおり、W が重み、A が活性化のビット数です。ここまで扱ってきた GGUF・MLX・GPTQ・AWQ・NF4 は、すべて重みだけを量子化する A16（weight-only）です。第 3 章では「保存は 4bit・計算は 16bit」という読み方を押さえましたが、この節で見たいのはその先 — その構成が性能にどう効くかです。

この違いが性能の効き方を決めます。llm-compressor の公式ドキュメントは、量子化の利益を 2 つに分けて書いています。

Lower latency from data movement: Quantized weights are faster to load from memory
Higher throughput via Tensor Cores: Quantized activations enable faster computation using specialized hardware

weight-only が稼ぐのは前者だけです。重みは 4bit でメモリに置かれますが、行列積をする直前にカーネル内で 16bit に戻されるので、演算量は 16bit のまま減りません。活性化も 8bit にする W8A8 で初めて、Tensor Core の低精度演算パスに乗って計算そのものが速くなります。

公式ドキュメントはこの分かれ目を「バッチサイズ」ではなく QPS（1 秒あたりのリクエスト数）という言葉で書いています。W4A16 は「low queries per second (QPS)」のワークロードに有用、INT8 W8A8 は「high-QPS or offline serving」に最適、という言い方です。バッチサイズで断言しているのは論文側で、Llama-3.1 ファミリを 50 万回超評価した研究はこう結論しています。

W4A16 is the most cost-efficient for synchronous setups, while W8A8 dominates in asynchronous continuous batching.

なぜそうなるのか。vLLM の最適化ドキュメントが理由を一言で書いています — prefill（プロンプトを読む段）は計算律速、decode（1 トークンずつ生成する段）はメモリ律速。1 人が対話しているときは重みを読み出す時間が支配的なので、重みを小さくする weight-only が素直に効きます。同時リクエストが増えて 1 回の行列積に多くの入力が乗るようになると、演算そのものが天井になり、重みを小さくしても報われなくなります。

この非対称性は実測にはっきり出ています。llama.cpp 公式の Llama-3.1-8B の測定では、テキスト生成が F16 の 29.17 t/s に対し Q4_K_M で 71.93 t/s（約 2.5 倍）に伸びる一方、プロンプト処理は F16 の 923.49 t/s が Q4_K_M では 821.81 t/s に落ちています。MLX 公式のベンチマーク（M4 Max・Qwen3-4B）も同じ形で、生成は bf16 の 52.47 から q4 の 134.52 t/s へ 2.56 倍になるのに、プロンプト処理は 1780.63 から 1622.27 t/s へむしろ微減します。量子化は生成を速くしますが、プロンプトを読む速度は速くしません。

もう 1 つ、「対応している」と「その速度で走る」の差にも注意が必要です。FP8 のチェックポイントは compute capability 8.9 未満（Turing・Ampere）でも読めますが、その場合は W8A8 ではなく FP8 Marlin による W8A16（weight-only）として走ります。NVFP4 も、対応する FP4 GEMM カーネルが無い GPU では Marlin 経由の W4A16 にフォールバックし、vLLM が「may reduce throughput for compute-heavy workloads」と警告を出します。ロードできたことは、想定の速度が出ていることの証明にはなりません。

比較表と選び方

表を縦に読むより、上から順に質問に答えていく方が早く決まります。形式は好みではなく、ハードウェアと用途からほぼ一意に決まります。

ビット数まで踏み込むと、公式のガイダンスは意外に素朴です。LM Studio のドキュメントが書いているのは「Choose a 4-bit option or higher if your machine is capable enough for running it.（マシンが許すなら 4bit 以上を選べ）」の一行だけです。自分のマシンで何が動くかは第 8 章、4bit と 8bit で品質がどれだけ違うかは第 9 章で数字を出します。

変換の向き — 戻り道はない

図 7-1 に右向きの矢印しか描かれていないことには意味があります。変換は実質的に一方通行です。

GGUF を作る手順は 2 フェーズです。llama.cpp の公式ドキュメントが「Quantization is done in two phases」と明言しています。

python convert_hf_to_gguf.py --outfile model-bf16.gguf --outtype bf16 --remote google/gemma-4-E2B-it
./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M

1 行目の --remote は「Hugging Face のリポジトリ名を直に渡す」ためのフラグです。すでにローカルへダウンロード済みなら、これを外してディレクトリのパスを渡します（公式ドキュメントの注記どおり）。

1 行目の convert_hf_to_gguf.py で選べる --outtype は f32 / f16 / bf16 / q8_0 / tq1_0 / tq2_0 / auto だけで、Q4_K_M はここでは作れません。K 系量子化は必ず 2 行目の llama-quantize の仕事です。この 2 段構えを知らないと、1 行目で詰まります。また 1 行目の出力は 16bit の中間ファイルなので、変換には量子化後のファイルとは別にそのぶんのディスクが要ります。公式ドキュメントも「大きいモデルでは中間ファイルを置く容量を確保せよ」と明記し、Llama 3.1 70B の例として元モデル 280.9 GB / Q4_K_M 43.1 GB という表を載せています（この 280.9 GB は 32bit 換算の元サイズなので、bf16 の中間ファイルはその半分ほどです）。

逆向きはどうか。llama.cpp のドキュメントには GGUF から safetensors へ戻す公式スクリプトが載っていません。MLX 側には mlx_lm.fuse --export-gguf がありますが、実装が対応しているのは F16 出力のみ、しかもアーキテクチャは llama / mistral / mixtral に限られます。逆に GGUF を mlx-lm で読む公式パスもありません。GGUF や MLX は「推論用の出力形式」であって、そこから作業を再開するための形式ではないと割り切るのが正しい理解です。

さらに、すでに量子化されたファイルを別のビット数に再量子化するのも避けるべきです。llama-quantize にはそれを許すフラグがありますが、公式の説明に警告が添えられています。

--allow-requantize: allow requantizing tensors that have already been quantized. Warning: This can severely reduce quality compared to quantizing from 16bit or 32bit

理由は第 3 章の丸めの話に戻ります。4bit へ丸めた時点で細かい差は消えています。その上からさらに丸めれば、誤差の上に誤差を重ねることになり、16bit から直接その精度に落とした場合より必ず悪くなります。Ollama の ollama create --quantize が入力を FP16 / FP32 に限っているのも同じ理由です（受け付ける出力型も q4_K_S / q4_K_M / q8_0 の 3 つだけです）。

学習に戻せないことにも、はっきりした技術的理由があります。MLX の QuantizedLinear の実装コメントはこう書いています — 「For now its parameters are frozen and will not be included in any gradient computation（当面そのパラメータは凍結され、いかなる勾配計算にも含まれない）」。量子化した重みには勾配が流れないので、そのまま学習することはできません。Hugging Face も「純粋な 4bit 学習を行うことは不可能」と書いています。だから微調整は、量子化した重みを凍結したまま小さな低ランク行列だけを学習する QLoRA の形になります。将来の微調整まで視野に入れるなら、元の safetensors を捨てないこと。これが形式選びで一番後戻りが効かない判断です。

つまずきポイント

理解度チェック

まとめ

• ファイル形式は「量子化手法 + 格納形式 + 対応カーネル」のセット。Q4_K_M（格納形式）と GPTQ 4bit（手法）は別のレイヤーの名前で、そのままでは比べられない
• 手元で動かすなら GGUF（全 OS・CPU と GPU の混在可・単一ファイル）か MLX（Apple Silicon 専用・unified memory・ビット数とグループサイズを直接指定）
• サーバで配るなら GPTQ / AWQ（W4A16・低 QPS 向け）と compressed-tensors の FP8 / INT8（W8A8・高 QPS 向け）。要件は compute capability で切れる（FP8 は 8.9 以上、INT8 は 10.0 以上で不可、NVFP4 は Blackwell）
• bitsandbytes は手軽さと QLoRA のための形式。公式が「推論の高速化は保証されない」と書いている
• 同じ「4bit」でも実効 bpw は 4.125〜4.89。比較は名前ではなく bpw と実ファイルサイズで行う
• 量子化は生成（decode）を速くするが、プロンプト処理（prefill）は速くしない。公式実測でも F16 の方が prefill は速い
• 変換は一方通行。safetensors から各形式へは進めるが、戻る公式経路はなく、再量子化は品質を大きく損なう。元の safetensors を捨てない

形式が決まっても、まだ「自分のマシンで何 bit のどのサイズが動くのか」は決まっていません。次章では重み・KV キャッシュ・作業領域を足し上げる見積り式を組み立てて、その答えを数字で出します。

参考リンク

• GGUF 仕様（ggml-org/ggml）
• llama.cpp: quantize ツールの README（bits/weight とサイズの実測表）
• MLX: mlx.core.quantize（量子化モードと group size の表）
• mlx-lm README（mlx_lm.convert と大きいモデルの扱い）
• vLLM: 量子化形式とハードウェア対応表
• llm-compressor: scheme の選び方（GPU 世代別の推奨）
• Hugging Face: compressed-tensors
• Hugging Face: 量子化手法の選び方
• OpenAI gpt-oss README（MoE 重みの MXFP4 量子化）
• "Give Me BF16 or Give Me Death"? Accuracy-Performance Trade-Offs in LLM Quantization