9月19日、MarkTechPostが「GGUF vs GPTQ vs AWQ vs EXL2: LLM Model Formats Explained (2026)」と題した記事を公開した。ローカルでLLMを動かす際、Hugging FaceのモデルページにはQ4_K_M.ggufや4bit-128g、4.65bpwといった記法が並ぶ。これらは一見似ているが、コンテナ形式と量子化手法という異なるレイヤーが混在している。本記事はその整理から始まる。

まず概念を分離する：コンテナ vs. 量子化手法

• コンテナ（ディスク上の格納形式）：safetensors、GGUF、PyTorch pickle（.bin / .pt）
• 量子化手法（重みを少ないビット数に圧縮する方法）：GPTQ、AWQ、bitsandbytes NF4、llama.cpp K-quants / I-quants
• 両方を兼ねるもの：EXL2・EXL3は手法と格納レイアウトが一体化しており、特定のInferenceライブラリに紐づく

メモリの概算式はシンプルだ：

重みのメモリ ≈ パラメータ数 × ビット数 ÷ 8

これはKVキャッシュやランタイムのオーバーヘッドを含まない、重みのみの数値だ。

GGUF（llama.cpp）— ローカル運用の事実上の標準

GGUFは2023年8月21日にllama.cppの作者Georgi Gerganovが旧GGML形式の後継として導入したバイナリ形式だ。旧GGML・GGMF・GGJTはアーキテクチャ情報を持てず、ハイパーパラメータを追加するたびに既存ファイルが壊れていた。GGUFは型付きキー・バリューのメタデータに切り替え、後方互換性を確保した。

トークナイザ、特殊トークン、Jinjaチャットテンプレートまで1ファイルに収められる点が特徴で、mmapによる部分ロードも可能だ。

Q4_K_Mなどの命名を読み解く

_S / _M / _Lサフィックスは新しいタイプではなく、テンソルごとに量子化レベルを混在させたミックスだ。たとえばQ4_K_Mはattention.wvとfeed_forward.w2の半分にQ6_Kを使い、残りにQ4_Kを使う。そのため平均ビット数は4.5を超える。

実際の品質トレードオフ（Llama-2-7Bクラスでの参考値）

Q8_0が「ほぼ無損失」の実用的な上限、Q4_K_Mが精度とサイズのバランス点という目安になる。

GGUFはllama.cpp・LM Studio・GPT4All・Ollamaで動作する。vLLMサポートは存在するが「実験的・最適化不足」と明記されており、vllm-gguf-pluginが別途必要だ。

GPTQ — Hessian情報を使った高精度量子化

GPTQは2022年10月にIST Austria・ETH Zurichの研究者らが発表し、ICLR 2023で採択された手法だ。重みの丸め誤差を二次（ヘッセ行列）情報で補正するのが核心で、175Bモデルを約4GPU時間で3〜4ビットに量子化できる。FP16比でNVIDIA A100上で約3.25倍、A6000上で約4.5倍の推論高速化が報告されている。

2026年時点の注意点：オリジナルのAutoGPTQはメンテナンス終了。現在はGPTQModelがTransformers・vLLM・SGLangに対応した後継として機能している。Hugging Faceによれば8BモデルのGPTQキャリブレーションはA100×1枚で約20分だ。

ファイル名の128gはグループサイズ（128重みにつき1スケール）、desc_actはカラムを重要度順に量子化するAct-orderオプションを指す。

AWQ — アクティベーションで「重要な重み」を見つける

AWQ（Activation-aware Weight Quantization）はMITのSong Hanグループが2023年6月に発表し、MLSys 2024 Best Paper Awardを受賞した手法だ。

全重みが等しく重要なわけではない、という観察が出発点だ。重みの約1%の「顕著なチャネル」を守るだけで量子化誤差が大幅に減る。AWQはその顕著なチャネルをアクティベーションの大きさから特定する点がGPTQと異なる。高精度で別保存するのではなく、数学的に等価な変換でスケールアップしてハードウェアフレンドリーな均一フォーマットを維持する。逆伝播・再構築を使わないためキャリブレーションデータへの過学習が起きにくい。

実装はAutoAWQが広く使われており、vLLM・SGLang・Transformersで推論できる。GPTQと比べてキャリブレーション時間が短く、ローカル環境での量子化コストを抑えたい場面に向く。すでに量子化済みのモデルをダウンロードして使う場合は体感差が出にくいが、自前でキャリブレーションを回す場合はAWQのほうが手軽という整理になる。

EXL2 / EXL3 — コンシューマGPUで限界を攻める

EXL2

ExLlamaV2のネイティブ形式。2〜8 bitsの任意の平均ビットレートを指定できるのが最大の特徴だ。レイヤー内のカラム単位でビット数を混在させ、キャリブレーションデータへの誤差を最小化しながら目標ビットレートを達成する。そのためファイル名は4-bitではなく4.65bpwのような表記になる。推奨サーバーはOpenAI互換APIを提供するTabbyAPIだ。ただしテンソルの内部的なリネームがあるため、他フレームワークへの移植性は低い。

EXL3

EXL3はCornell RelaxMLのQTIP（NeurIPS 2024）をベースにした後継だ。トレリス符号化量子化と非整合処理を使う。

注目すべき数字は：Llama-3.1-70Bが1.6 bits/weightで動作し、3-bit出力レイヤーと4,096トークンキャッシュ込みで16GB VRAMに収まる。変換コストはRTX 4090クラス1枚で70B以上でも数時間程度。比較対象としてREADMEに挙げられているAQLMは70Bモデルに約720 A100 GPU時間を要する。

EXL2と異なりEXL3は元のテンソル構造をほぼ維持するため移植性が高い。ただしCUDA 12.4以降が必須で、ROCmサポートはTODOのままだ。

その他のフォーマット早見表

結局どれを選ぶか

フォーマットの選択は環境と目的で決まる。大まかな判断軸を整理する。

• 手軽にローカルで動かしたい（CPU混在可） → GGUF（Q4_K_M〜Q6_K）。Ollama・LM Studioで即座に動く
• NVIDIA GPU + vLLM / SGLangで本番運用したい → GPTQ（GPTQModel）またはAWQ（AutoAWQ）。どちらもvLLM対応済み
• 自前でキャリブレーションを回す時間・リソースを節約したい → AWQ。GPTQより短時間で済む
• コンシューマGPU（16〜24GB VRAM）で可能な限り大きなモデルを動かしたい → EXL2（ExLlamaV2 + TabbyAPI）またはEXL3
• 超低ビット（2bit前後）まで攻めたい → EXL3。1.6 bpwで70Bが16GBに収まる
• Macで動かしたい → MLXまたはGGUF（llama.cpp / Ollama）
• QLoRAでファインチューニングしたい → bitsandbytes NF4。量子化ベースのLoRAアダプタ訓練に最適化されている

safetensorsとPickleの違いは見落としやすい

フルプレシジョン（16-bit）モデルの配布形式としてpytorch_model.bin（Pickleベース）とsafetensorsが存在する。Pickleは任意コード実行が可能なため、信頼できないチェックポイントはセキュリティリスクになる。Hugging Faceが開発したsafetensorsは実行可能コードを持たず、現在はPyTorch Foundationプロジェクトとしてホストされている。

また、GPTQ・AWQ・EXL2・EXL3・MLXのほとんどは内部的にsafetensors形式で保存されており、量子化情報はテンソルの内容とconfigファイルに埋め込まれている点も押さえておきたい。

詳細はGGUF vs GPTQ vs AWQ vs EXL2: LLM Model Formats Explained (2026)を参照していただきたい。