- ハードと用途から形式・ビット数を決めるまでの 4 ステップ（第 7 章の決定木の要約版）
- GGUF の主要タイプの bpw・8B での実サイズ・perplexity 増分を 1 枚の表で引ける
- 重み・KV キャッシュ・速度上限の 3 つの式と、代表的な数値を入れた早見表
- llama.cpp / Ollama / MLX / LM Studio / vLLM の頻用コマンドを公式の綴りで確認できる
- 本ガイドで使った 38 語の用語を、詳しく説明した章つきで引ける
この章は読み物ではなく参照ページです。理由や導出は各章に置いてあるので、ここには「結論」と「数値」と「綴り」だけを並べます。表の下には必ず「この表の使い方」を添えました。数値の出典は章末の参考リンクにまとめてあります。
選択フロー — 4 ステップで決める
選択肢は膨大に見えますが、実際に決めるべきことは 4 つだけです。① 何に使うか → ② どの形式か → ③ 何ビットか → ④ 入らなければどこを削るか。順番が大事で、①②を飛ばして③のビット数から考えると必ず迷います。
ハードごとの第一候補は次のとおりです。llama.cpp（GGUF）はほぼ全部のハードで動き、vLLM 系の形式はハードで可否が分かれます。Apple Silicon は GGUF（Metal）と MLX の両方が使え、AMD GPU では AWQ / GPTQ が vLLM で未対応、CPU だけの環境では vLLM の GGUF 対応がありません。
- Apple Silicon — GGUF（Metal）または MLX。MLX の既定は affine 4bit（group size 64）
- NVIDIA GPU — 対話なら GGUF（CUDA）、配信なら AWQ / GPTQ（W4A16）か FP8（W8A8）。ただし vLLM の FP8 W8A8 は Ada / Hopper 以降のみ対応で、AWQ は Turing 以降
- AMD GPU — GGUF（HIP / Vulkan）。vLLM では GGUF と FP8 W8A8 のみ対応
- CPU のみ — GGUF。vLLM で配信するなら INT8 W8A8（x86 / Arm）
GGUF タイプ早見表
表の ΔPPL（デルタ・ピーピーエル）は、同じモデルの F16 版に対して perplexity（= 次の 1 トークンを当てるとき実質何択で迷っていたか。第 9 章）がどれだけ増えたかを表します。小さいほど元のモデルに近いという読み方です。
| タイプ | 型の bpw | 8B の実サイズ / 実効 bpw | ΔPPL（Llama 3 8B） | 一言 |
|---|---|---|---|---|
Q8_0 | 8.5 | 8.54 GB / 8.51 | +0.0026 | ほぼ無損失。ただし量子化タイプの中では生成が最も遅い |
Q6_K | 6.5625 | 6.60 GB / 6.57 | +0.0217 | 実質無損失。Q8_0 を選ぶ理由はほぼない |
Q5_K_M | 5.5 | 5.73 GB / 5.71 | +0.0569 | 余裕があるときの一段上 |
Q4_K_M | 4.5 | 4.92 GB / 4.90 | +0.1754 | 既定。3 つの公式ツールの推奨が一致 |
Q4_K_S | 4.5 | 4.69 GB / 4.68 | +0.2689 | Q4_K_M が数百 MB 入らないとき |
IQ4_XS | 4.25 | 4.45 GB / 4.43 | +0.2281（imatrix 有） | 4bit 帯で最小。imatrix 前提の設計 |
Q4_0 | 4.5 | 4.66 GB / 4.64 | +0.4685 | legacy。同サイズ帯で K-quants に負ける |
Q3_K_M | 3.4375 | 4.02 GB / 4.00 | +0.6569 | ここから劣化が体感に出はじめる |
Q2_K | 2.625 | 3.18 GB / 3.17 | +3.5199 | 崖の下。大きいモデル専用の最後の手段 |
IQ2_M | 2.7（混合） | 2.95 GB / 2.94 | +2.3692（imatrix 有） | imatrix 必須。70B を 24 GB 級に載せる用 |
この表の使い方: 自分のメモリ予算から「実サイズ」列を見て収まる行を探し、その行の ΔPPL で覚悟を決めます。型の bpw と実効 bpw が違うのが重要な点で、Q4_K という型は 4.5 bpw ですが、Q4_K_M というファイルは埋め込み層や出力層が上位型で残るため実効 4.90 bpw になります（内訳は第 6 章）。サイズは Llama 3.1 8B Instruct の実ファイルバイト数、ΔPPL は llama-quantize のヘルプが Llama 3 8B・Wikitext-2 で示す F16 比の perplexity 増分です（第 6 章の表と同じ出典。第 9 章のスコアボードは別の測定なので、同じ型でも下 1 桁が違います）。IQ4_XS と IQ2_M の行だけ imatrix ありの値なので、サイズが小さいのに近くの K-quant より ΔPPL が小さく見えます。条件を揃えるなら K-quant 側も imatrix ありで測る必要があり、Q4_K_M は imatrix ありだと +0.1513 まで下がります。
ビット数の目安 — 何ビットで何が起きるか
Q4_0 だけ曲線から外れて上にあるのは、同じサイズで K-quants より悪いことを意味する（だから legacy）。| ビット帯 | 代表タイプ | 8B での目安 | 何が起きるか |
|---|---|---|---|
| 8bit | Q8_0 / W8A8 | 8.5 GB | F16 とほぼ区別できない（ΔPPL +0.0026）。W8A8-FP8 は「全モデル規模で lossless」と報告されている |
| 5bit | Q5_K_M | 5.7 GB | ΔPPL +0.0569。実務ではまず気づかない |
| 4bit | Q4_K_M / W4A16 | 4.9 GB | ΔPPL +0.1754。ただし 1 位トークンが F16 と一致する割合は 91.9%（残る 8% では別の語を 1 位に選ぶ） |
| 3bit | Q3_K_M | 4.0 GB | ΔPPL +0.6569。長い生成で崩れが目に見えはじめる |
| 2bit | Q2_K / IQ2_M | 3.2 GB | ΔPPL +3.5199、1 位一致率 71.1%。同じ予算なら「一段大きいモデルの 4bit」を先に試す |
| 1bit 台 | IQ1_S | 約 2.0 GB（1.88 GiB） | ΔPPL +54.46。llama.cpp の公式スコアボードでも他と桁が違う |
この表の使い方: 「何ビットまで落とせるか」ではなく「4bit が膝である」と覚えるのが実務的です。8bit から 4bit まではサイズが半分になっても品質はほとんど動かず、4bit を割ると急に悪化します。35,000 件以上の実験を行った研究も「総ビット数とゼロショット精度の観点で 4bit がほぼ普遍的に最適」と結論しています。同じメモリ予算で「大きいモデルを強く量子化」と「小さいモデルを軽く量子化」を比べると、前者が勝つことも公式データで確認できます（LLaMA 13B の 2bit が 5.13 GB で PPL 5.85、LLaMA 7B の 6bit が 5.15 GB で 5.91）。指標の意味と限界は第 9 章を参照してください。
メモリ見積り式まとめ
必要メモリは ①重み + ②KV キャッシュ + ③作業領域 + ④マージン の足し算です。①はファイルを選んだ時点で固定、②は設定で伸び縮みします。導出は第 8 章にあるので、ここでは式と代入例だけ置きます。
式 1: 重みのサイズ
パラメータ数に、重み 1 個あたりの平均ビット数（実効 bpw）を掛けて 8 で割ればバイト数になります。
重みのサイズ(GB) = パラメータ数(B) × 実効bpw ÷ 8
計算例: Llama 3.1 8B（8.03B パラメータ）を Q4_K_M（実効 4.90 bpw）にすると 8.03 × 4.90 ÷ 8 = 4.92 GB。実ファイルは 4,920,739,232 バイト = 4.92 GB で一致します。暗算するなら、Q4_K_M の実効 bpw は 5 モデルの実測で 4.82〜4.90 に収まるので、代表値 4.85 を 8 で割って「パラメータ数 × 0.6 GB」（4.85 ÷ 8 = 0.606）と覚えます。8B で 4.87 GB、70B で 42.8 GB と、実測（4.92 / 42.52 GB）に対して誤差 1% 以内です。
式 2: KV キャッシュのサイズ
K と V の 2 本、それを全層ぶん、1 トークンあたり「KV ヘッド数 × head_dim」個の値を持ちます。
KV(バイト) = 2 × 層数 × KVヘッド数 × head_dim × コンテキスト長 × 1要素のバイト数
計算例: Llama 3.1 8B は 32 層・KV ヘッド 8・head_dim 128 です。1 要素 2 バイト（f16）としてコンテキスト長を 1 トークンに置くと、2 × 32 × 8 × 128 × 1 × 2 = 131,072 バイト = 128 KiB / トークン。4k で 0.50 GiB、32k で 4.00 GiB、128k では 16.00 GiB になり重み（4.92 GB）を追い越します。hidden_size（4096）を掛けると 4 倍の過大見積りになるので、必ず num_key_value_heads を使ってください。
式 3: 生成速度の上限
1 トークン生成するたびに全重みをメモリから読むので、上限は「1 秒に重み全体を何回読めるか」で決まります。
tok/s の上限 ≒ メモリ帯域(GB/s) ÷ 重みのサイズ(GB)
計算例: M4 Max（40 コア GPU、546 GB/s）で 8B Q4_K_M（4.92 GB）なら 546 ÷ 4.92 = 111 tok/s。これは上界で、実測は 5〜8 割に落ちます。式そのものは公式文書にある形ではなく、「decode はメモリ帯域律速」という一次記述からの導出です。
| デバイス | 帯域 | 8B Q4_K_M (4.92 GB) | 27B Q4_K_M (16.55 GB) | 70B Q4_K_M (42.52 GB) |
|---|---|---|---|---|
| RTX 5090（32 GB） | 1792 GB/s | 364 | 108 | 42 |
| RTX 5080（16 GB） | 960 GB/s | 195 | 58 | 23 |
| RTX 5070（12 GB） | 672 GB/s | 137 | 41 | 16 |
| M3 Ultra | 819 GB/s | 166 | 50 | 19 |
| M4 Max（40c GPU） | 546 GB/s | 111 | 33 | 13 |
| M4 Pro | 273 GB/s | 56 | 17 | 6 |
| M4 | 120 GB/s | 24 | 7 | 3 |
この表の使い方: 帯域はベンダー公式値、tok/s は上の式に代入した理論上限です。行を横に見れば「モデルを大きくするといくら遅くなるか」、列を縦に見れば「ハードを買い替えるといくら速くなるか」が読めます。作業領域は重みの 1 割程度（公式ログの実例で 13.3 GB のモデルに 1.26 GiB）、マージンは 1 GiB（llama.cpp の既定）を足してください。
コマンド早見表
| ツール | 目的 | コマンド |
|---|---|---|
| llama.cpp | HF から直接実行 | llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF |
| llama.cpp | API サーバを立てる | llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF |
| llama.cpp | HF モデルを GGUF に変換 | python convert_hf_to_gguf.py --outfile out-bf16.gguf --outtype bf16 --remote <repo> |
| llama.cpp | 量子化する | llama-quantize in-bf16.gguf out-Q4_K_M.gguf Q4_K_M |
| llama.cpp | サイズだけ先に見る | llama-quantize --dry-run in-bf16.gguf Q4_K |
| llama.cpp | imatrix を作る | llama-imatrix -m ggml-model-f16.gguf -f calibration-data.txt -ngl 99 |
| llama.cpp | 品質を測る | llama-perplexity -m model.gguf -f wikitext-2-raw/wiki.test.raw |
| llama.cpp | KV を 8bit に | -ctk q8_0 -ctv q8_0 -fa（V の量子化には -fa が必須） |
| Ollama | HF の GGUF を実行 | ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0 |
| Ollama | 量子化する（3 種のみ） | ollama create --quantize q4_K_M mymodel |
| MLX | 量子化する（既定 4bit） | mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q |
| MLX | 生成する | mlx_lm.generate --prompt "How tall is Mt Everest?" |
| LM Studio | 形式とビットを指定して取得 | lms get <model-url>@Q6_K / lms get qwen --gguf |
| vLLM | ロード時に FP8 化 | vllm serve meta-llama/Llama-3.1-8B --quantization fp8_per_tensor |
| vLLM | KV を FP8 に | --kv-cache-dtype fp8 |
この表の使い方: 2026 年の llama.cpp は llama cli のようなサブコマンド形式（スペース区切り）が正式で、従来の llama-cli / llama-quantize といった個別バイナリも併存しています。公式ドキュメント内でも両方の表記が使われているので、手元のビルドでどちらが存在するかを先に確認してください（llama help が使えるコマンド一覧を出します）。なお imatrix はサブコマンド側に無く、llama-imatrix という個別バイナリだけです。Ollama が作れるのは q8_0 / q4_K_S / q4_K_M の 3 種だけで、それ以外は GGUF を持ち込む形になります。
「迷ったら Q4_K_M」が本当に既定なのかを、ダウンロードされるファイル名で確認します。
- llama.cpp を入れた環境で次を実行する。
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUFログに出るファイル名に Q4_K_M が入っていれば期待どおりです。-hf は quant を省略すると Q4_K_M を選び、リポジトリに無ければ先頭のファイルにフォールバックします。
数十分かかる量子化を走らせる前に、出力サイズだけ計算させます。
- bf16 の GGUF を用意し、型名を指定して
--dry-runを付ける。
llama-quantize --dry-run in-bf16.gguf Q4_K量子化は実行されず、最終サイズだけが表示されます。imatrix が必要な型を指定した場合は「実際に完了させるには imatrix が必要」という警告が出るので、着手前に必須オプションを洗い出せるのが利点です。
表の ΔPPL は Llama 3 8B の値です。自分のモデルで測り直す手順を通します。
- Wikitext-2 を
scripts/get-wikitext-2.shで取得する。 - F16 版の logits を保存する（下の 1 行目）。
- 量子化版で KL ダイバージェンスまで出す（2 行目）。
llama-perplexity -m f16.gguf -f wikitext-2-raw/wiki.test.raw --kl-divergence-base f16.kld
llama-perplexity -m q4_k_m.gguf -f wikitext-2-raw/wiki.test.raw --kl-divergence-base f16.kld --kl-divergencePPL と ΔPPL に加え、Mean Δp・RMS Δp・1 位一致率が出ます。logits ファイルは Llama 3 で 37 GiB になるので、先に空き容量を確認してください。
用語集
本ガイドで使う用語を 38 語ぶん並べます。丁寧な説明はカッコ内の章にあります。
| 用語 | 意味（詳しい章） |
|---|---|
| 量子化 | 重みを少ないビット数の整数や低精度浮動小数点に書き直してサイズを縮める操作（第 1 章） |
| bpw | bits per weight。重み 1 個あたりの平均ビット数で、スケール等のメタデータも含む（第 2 章） |
| 実効 bpw | ファイル全体のバイト数 × 8 ÷ パラメータ数。Q4_K_M は 4.9 前後で「4」ではない（第 6 章） |
| scale | 量子化された整数を元の大きさに戻すための倍率。ブロックごとに 1 個持つ（第 3 章） |
| zero-point | 整数のどの値を実数の 0 に対応させるかを示すオフセット。対称量子化では不要（第 3 章） |
| ブロック | scale を共有する重みのまとまり。llama.cpp の legacy 型は 32 個単位（第 3 章） |
| スーパーブロック | K-quants が使う 256 要素の外枠。中を 8×32 または 16×16 のサブブロックに割る（第 6 章） |
| K-quants | サブブロックの scale 自体を 4〜8bit に量子化する llama.cpp の方式。_K が付く（第 6 章） |
| i-quants | 代表ベクトルの表（コードブック）を引く低ビット型。IQ が付き imatrix を前提とする（第 6 章） |
| imatrix | キャリブレーション文を流して測った、入力チャンネルごとの二乗活性化の平均。重要度の重み（第 6 章） |
| GGUF | GGML 系ランタイム向けの単一ファイル形式。テンソルと標準化されたメタデータを一緒に持つ（第 6 章） |
| safetensors | テンソルだけを JSON ヘッダ + バイト列で持つ配布形式。GGUF 変換の入口になる（第 7 章） |
| PTQ | Post-Training Quantization。学習済みモデルを後から量子化する。本ガイドの手法はほぼこれ（第 5 章） |
| QAT | Quantization-Aware Training。学習中に丸めを模擬してモデル自身を量子化に慣らす。学習が必要なので本ガイドでは扱わない（PTQ との対比のみ） |
| RTN | Round To Nearest。最も近い代表値に丸めるだけの素朴な量子化。キャリブレーション不要（第 5 章） |
| GPTQ | 層の出力誤差を Hessian で補償しながら列ごとに量子化する手法。キャリブレーションが必要（第 5 章） |
| AWQ | 活性化が大きいチャネルをスケールアップして守る手法。activation-aware の名の由来（第 5 章） |
| NF4 | 正規分布の分位点で 16 個の代表値を決めた 4bit 型。QLoRA 論文が導入した（第 2 章） |
| QLoRA | 4bit に固めたベースモデルに、LoRA アダプタだけを載せて学習する微調整法（第 5 章） |
| LLM.int8() | 外れ値を含む列だけ FP16 で計算し、残りを INT8 で回す混合精度分解（第 5 章） |
| SmoothQuant | 活性化の量子化の難しさを、数学的に等価な変換で重み側へ移す手法（第 5 章） |
| HQQ | 活性化を見ず、重みの誤差だけを閉形式で最小化する。キャリブレーション不要で速い（第 5 章） |
| W4A16 | 重み 4bit・活性化 16bit の意味。W が weight、A が activation（第 3 章で定義、効き方は第 7 章） |
| W8A8 | 重みも活性化も 8bit。計算まで 8bit で回るのでスループットが上がる（第 3 章で定義、効き方は第 7 章） |
| FP8 | 8bit の浮動小数点。E4M3（指数 4・仮数 3）と E5M2 の 2 種類がある（第 2 章） |
| MXFP4 | FP4（E2M1）32 個に E8M0 の共有スケール 1 個を付ける形式。実効 4.25 bpw（第 2 章） |
| KV キャッシュ | 過去トークンの K と V を保存しておく領域。コンテキスト長に比例して増える（第 8 章） |
| GQA | 複数の Q ヘッドで KV ヘッドを共有する構造。KV キャッシュが共有数ぶん小さくなる（第 8 章） |
| perplexity | 次の 1 トークンを当てるとき実質何択で迷っていたかを表す指標。低いほど良い（第 9 章） |
| KL ダイバージェンス | F16 版と量子化版の出力確率分布の隔たり。0 なら分布が完全に同じ（第 9 章） |
| Same top p | 1 位のトークンが F16 版と一致した割合。Q4_K_M の Llama 3 8B で 91.9%（第 9 章） |
| キャリブレーション | 量子化の前に少量の文章を流し、活性化の統計を取る作業（第 5 章） |
| 外れ値 | 他の要素より桁違いに大きい活性化。低ビット化を壊す主犯（第 4 章） |
| dequantize | 量子化された整数を scale で実数に戻す操作。行列積カーネルの中で行う（第 3 章） |
| mmap | ファイルをメモリ空間に写し、必要なページだけ読む方式。llama.cpp の既定（第 8 章） |
| offload | モデルの一部を GPU に載せること。llama.cpp では -ngl で層数を指定する（第 10 章） |
| unified memory | CPU と GPU が同じメモリプールを直接見る Apple Silicon の構造（第 7 章） |
| MoE | 層ごとに一部のエキスパートだけ使う構造。総パラメータは巨大でも 1 トークンの計算は軽い（第 2 章） |
つまずきポイント
早見表の数字を別のモデルにそのまま当てる。 ΔPPL はすべて Llama 3 8B・Wikitext-2 の値です。perplexity は同じモデルの F16 と量子化版を比べる差分専用で、トークナイザが違うモデル間では比較できません。実効 bpw も、埋め込み層の比率が高い小さいモデルでは上にずれます（Q2_K は 70B で 2.99、7B で 3.36）。
「Q4_K_M で ΔPPL +0.18 なら無害」と読む。 同じ設定で 1 位トークンの一致率は 91.9%、つまり残る 8.1% のトークン（およそ 12 回に 1 回）では F16 と違う語を 1 位に選びます。長い生成では分岐が積み上がります。さらに日本語では、自動指標で −1.7% の差が人間評価では −16.0% になったという測定もあります。平均スコアだけで判断しないでください。
ビット数を下げれば必ず速くなると思う。 速くなるのは生成（decode）だけです。llama.cpp の公式実測では、テキスト生成は F16 の 29 t/s に対し Q4_K_M が 72 t/s に上がりますが、プロンプト処理は F16 が 923 t/s で最速、量子化タイプは 700〜865 t/s に留まります。前者はメモリ帯域律速、後者は計算律速で、逆量子化のコストが乗るからです。
手元の GGUF を再量子化して小さくしようとする。 --allow-requantize は付けられますが、公式ヘルプが「16bit や 32bit から量子化した場合に比べ品質を著しく落としうる」と警告しています。Q8_0 から Q4_K_M を作らず、bf16 の GGUF から作り直してください。
理解度チェック
Q1. 手持ちの GPU が 12 GB のとき、8B モデルを 32k コンテキストで動かす見積りはどうなりますか。
重み 4.92 GB（Q4_K_M）+ KV 4.00 GiB（32k、f16）+ 作業領域 約 0.5 GB + マージン 1 GiB で、合計 10.5 GB 前後。12 GB なら入りますが余裕は小さいので、-ctk q8_0 -ctv q8_0 -fa で KV を 2.125 GiB に落とすと安全域が広がります。
Q2. 「Q4_K_M は 4bit なので 8B なら 4.0 GB」はどこが間違っていますか。
名前の 4 は基本ビット数で、実効 bpw ではありません。Q4_K という型自体が scale のぶんを含めて 4.5 bpw で、さらに _M の配合で一部テンソルが上位型になり、出力層は既定で Q6_K です。結果、モデル全体の実効は 4.90 bpw、実ファイルは 4.92 GB になります。
Q3. VRAM 予算が約 5 GB のとき、13B の 2bit と 7B の 6bit のどちらを選ぶべきですか。
公式データでは大きいモデル側が勝ちます。LLaMA 13B Q2_K（5.13 GB）の Wikitext PPL が 5.85、LLaMA 7B Q6_K（5.15 GB）が 5.91。perplexity は「量子化後のサイズ」のほぼ滑らかな関数なので、同じサイズなら大きいモデルを強く量子化する方が有利です。ただし 2bit 帯では 1 位一致率が大きく落ちるため、実タスクでの確認は必須です。
Q4. 表に載っている IQ2_M を llama.cpp で作ろうとしたらエラーで止まりました。何が足りませんか。
imatrix です。llama.cpp が imatrix を要求するのはテンソルの型で判定され、その一覧は IQ1_S / IQ1_M / IQ2_XXS / IQ2_XS / IQ2_S / IQ3_XXS です。IQ2_M は型ではなく混合レシピの名前で、その土台のテンソル型が IQ2_S なので、この一覧に引っかかって「this quantization requires an importance matrix!」で停止します。K-quants は原則不要で、例外は Q2_K_S ファイル内の Q2_K テンソルだけです。
Q5. Mac で「モデルは RAM に収まっているのに極端に遅い」とき、まず何を疑いますか。
GPU が使える上限（max_recommended_working_set_size）を超えていないかです。unified memory は CPU と GPU で共有されますが、GPU に常駐させられる量には上限があり、超えると性能が落ちます。MLX 公式は sudo sysctl iogpu.wired_limit_mb=<MB> で引き上げる手順を示しています。帯域から出した理論上限（式 3）と実測が桁で違う場合も、この線を疑ってください。
まとめ
- 決めることは 4 つだけ。用途 → 形式 → ビット数 → 削るところ。この順で辿れば選択肢は一意に絞れる
- 迷ったら
Q4_K_M。llama.cpp の-hfと Ollama が Hugging Face の GGUF を引くときの既定、LM Studio の「4bit 以上」推奨が一致する点 - 品質の膝は 4bit。8bit → 4bit はほぼ平らで、4bit を割ると急に落ちる。同じ予算なら「大きいモデルの 4bit」が勝つ
- メモリは 重み + KV + 作業領域 + マージン。長いコンテキストでは KV が重みを追い越す
- 生成速度の上限は 帯域 ÷ 重みサイズ。量子化はメモリ対策であり、同時に生成の高速化策でもある
- 数値は必ず「どのモデル・どのデータセット」の値かを添えて読む。perplexity は同一モデル内の差分専用
これで本ガイドは終わりです。ここから先は自分のタスクで測ることが唯一の正解に近づく道で、Hugging Face の公式ガイダンスも「精度と速度は必ず自分のタスクとハードでベンチマークせよ」と結んでいます。次に読む一次情報を下に挙げます。
参考リンク
- llama.cpp — tools/quantize/README.md（量子化手順・実効 bpw とサイズの実測表）
- llama.cpp — tools/perplexity/README.md（Llama 3 8B スコアボード・KL ダイバージェンスの測り方）
- llama.cpp — tools/imatrix/README.md（imatrix の作り方と全オプション）
- Hugging Face Hub — GGUF（量子化タイプ一覧と GGUF の位置づけ）
- Hugging Face Transformers — Selecting a quantization method（目的別の手法選択とビット数の指針）
- vLLM 公式ドキュメント（対応ハードウェア表・FP8 / INT4 / KV 量子化）
- mlx-lm（Apple Silicon での量子化・生成コマンド）
- LM Studio — Download a model（「4bit 以上を選べ」の出所）
- arXiv:2212.09720 — The case for 4-bit precision（4bit が最適という結論の原論文）
- arXiv:2305.14314 — QLoRA（NF4 と二重量子化）
- arXiv:2310.10537 — Microscaling Data Formats（MXFP4 / MXFP8 の仕様と実測）
- arXiv:2411.02355 — 量子化 LLM の大規模評価（W8A8 / W4A16 の精度回復率）
- arXiv:2407.03211 — 多言語での量子化の影響（日本語の自動指標 −1.7% に対し人間評価 −16.0% の出所）