手を動かす — 選ぶ・落とす・自分で量子化する

最短経路は 4 段のはしごになっている

量子化の実務は一本道ではなく、目的の深さに応じた 4 段のはしごです。大半の人は 1 段目で用が足ります。上に登るのは、下の段で具体的な不満が出たときだけです。

そう言い切れるのは、主要ツールの既定値が独立に一致しているからです。llama.cpp の -hf は量子化を省略すると Q4_K_M を取りに行き、Ollama を Hugging Face 経由で使ったときも公式が「By default, the Q4_K_M quantization scheme is used」と明記し、LM Studio 公式の選び方ガイダンスは「Choose a 4-bit option or higher if your machine is capable enough for running it.」の 1 行です。3 つのツールが同じ場所を指しているので、1 段目は「Q4_K_M を落として動かす」で終わって構いません。

段①: 既製の量子化モデルを落として動かす

経路 A — Ollama

モデル指定は <モデル名>:<タグ> で、タグの中身はパラメータ数・チューニング種別・量子化タイプをハイフンでつないだものです。llama3.2:3b-instruct-q4_K_M なら「Llama 3.2 の 3B 版／指示追従チューニング済み／GGUF の Q4_K_M」。text はチューニング前の素のモデルです。

ここで情報の質を区別します。「Ollama の既定量子化は Q4_K_M」と明文で書いた公式ページは存在しません。言えるのは「latest / 3b / 3b-instruct-q4_K_M の digest が一致している」という実測までです。Hugging Face 経由の既定 Q4_K_M だけは公式に明記されています。

いま何が動いているかは ollama show で見ます。出力の Model テーブルに architecture / parameters / context length と並んで quantization の行が出ます（API なら details.quantization_level）。

ollama pull llama3.2:3b-instruct-q4_K_M
ollama show llama3.2
ollama run  hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0   # HF から直接、大文字小文字は不問

効き目はサイズに出ます。llama3.2 の 3B instruct は fp16 の 6.4GB が q4_K_M で 2.0GB、約 3 分の 1（q8_0 は 3.4GB、q2_K は 1.4GB。いずれもライブラリページ実測）。旧方式の q4_1 は 2.1GB で q4_K_M より大きいという逆転もあります（命名の中身は第 6 章）。なお選択肢の数はモデル依存で、llama3.2 は 15 種のタグを持つ一方、qwen3 は 3 種、gpt-oss は量子化タグを持ちません。新しいモデルでは実質「Q4_K_M か Q8_0 か fp16」の 3 択です。

Ollama 自身にも量子化機能がありますが、作れるのは q8_0 / q4_K_S / q4_K_M の 3 種だけで、入力は FP16 か FP32 に限られます（中身は llama-quantize にシェルアウトしているだけ）。

# Modelfile に FROM /path/to/my/gemma/f16/model と書いてから
$ ollama create --quantize q4_K_M mymodel
transferring model data
quantizing F16 model to Q4_K_M
writing manifest
success

ollama pull llama3.2:3b-instruct-q4_K_M
ollama show  llama3.2:3b-instruct-q4_K_M
ollama run   llama3.2:3b-instruct-q4_K_M
ollama ps    # 別ターミナルで

NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
gemma4:latest    c6eb396dbd59    9.6 GB    100% GPU     131072     2 minutes from now

経路 B — LM Studio

llama.cpp の上に作られた GUI で、Apple Silicon では MLX も動かせます。モデル検索では 1 つのモデルに複数の量子化が並び、公式はそれを「These are all copies of the same model, provided in varying degrees of fidelity」と説明します。Q4_K_M と Q5_K_M の優劣についての公式記述はありません（あるのは「4bit 以上」の 1 行だけ）。

混乱しやすいのは形式で量子化の呼び名が違う点です。REST API のレスポンス例がそれを端的に示します。

{ "id": "qwen2-vl-7b-instruct",       "compatibility_type": "mlx",  "quantization": "4bit"   }
{ "id": "meta-llama-3.1-8b-instruct", "compatibility_type": "gguf", "quantization": "Q4_K_M" }

GGUF は Q4_K_M のような K-quant 名、MLX は 4bit のような素朴なビット数表記です。CLI では形式と量子化を絞れます（lms は本体を 1 度起動しないと使えません）。GPU offload（= モデルの層を GPU 側メモリに載せること）は 0.0〜1.0 の比率で、--gpu 0.5 は llama.cpp の -ngl <層数> を比率で言い換えたものです（換算式は非公開）。

lms get qwen --mlx
lms get llama-3.1-8b@q4_k_m
lms load --estimate-only gpt-oss-120b --context-length 8192

最大の実務メリットは --estimate-only で「収まるか」を事前に見られることです。公式の出力例は Estimated GPU Memory: 65.68 GB を返し、この見積りがコンテキスト長・Flash Attention・vision 対応を勘案していると明記されています。つまり「ファイルサイズ = 必要メモリ」ではありません（内訳は第 8 章）。

段②: llama.cpp を直に叩いて設定を詰める

最初の段差はコマンド名です。2026 年の llama.cpp は llama という単一ディスパッチャを持ち、README は llama cli（スペース区切り）で書かれています。一方で従来の llama-cli / llama-server / llama-quantize も生きていて、Hugging Face 側の公式ドキュメントはそちらの表記です。公式内に両方の書き方が併存しているので、まず llama help で自分の環境を確認してください。

curl -LsSf https://llama.app/install.sh | sh   # 公式ワンライナー
brew install llama.cpp                          # Mac / Linux
winget install llama.cpp                        # Windows

git clone https://github.com/ggml-org/llama.cpp   # ソースから（CPU ビルド）
cmake -B build && cmake --build build --config Release

Apple Silicon では Metal が既定で有効（「On MacOS, Metal is enabled by default」）、NVIDIA なら -DGGML_CUDA=ON を付けます。実行はファイルを落とさず Hugging Face のリポジトリ名を直接渡すのが最短です。-hf <user>/<model>[:quant] の quant は省略可で、既定が Q4_K_M、無ければリポジトリ内の最初のファイルにフォールバックします。

ここで古い常識を捨ててください。-ngl の既定はもう 0 ではなく auto で、--fit が既定 on として「デバイスごとに 1024 MiB のマージンを残して収まるよう」引数を調整します。手で大きな値を固定すると自動調整を潰し、VRAM 溢れを招きます。メモリが足りないときに削る順序も公式に書かれています。--ctx-size を下げる → --parallel を下げる → 最後の手段として -ngl を下げる（残りは CPU で走り「much slower」になる）。この痛みは実測されていて、A6000 + 7 物理コアで 30B の 4bit を回すと CPU のみ 1.7 tokens/s、GPU 全載せ 9.1 tokens/s で約 5.4 倍。同じ表の GPU 全載せ同士を比べると -t 7（8.7）は -t 4（9.1）より遅く、CPU スレッドも多いほど速いわけではありません（公式も「It's extremely important that this parameter is not too large.」と書き、まず 1 から倍々に増やして探せと助言しています）。

llama help
llama cli -hf ggml-org/gemma-3-1b-it-GGUF
llama cli -hf bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0
llama serve -hf ggml-org/gemma-3-1b-it-GGUF

curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer no-key" \
-d '{"messages": [{"role": "user", "content": "Write a limerick about Python exceptions"}]}'

段③④: 自分で変換して、自分で量子化する

ここからは「欲しい量子化が配布されていない」ときの領域です。まず地図として、元の safetensors（= Hugging Face が標準にしている重みファイル形式）から先は、目的の形式ごとに別のツールへ分岐します。形式そのものの選び分けは第 7 章、ここでは「どのコマンドがどれを作るか」だけを押さえます。

GGUF は必ず 2 段階を通る

公式の言い方は「Quantization is done in two phases: Convert the original model to GGUF format. / Quantize the converted GGUF file.」です。いきなり Q4_K_M は作れません。一度 bf16 や f16 の「量子化前の GGUF」を作り、それを入力にします。

python3 -m pip install -r requirements.txt

python convert_hf_to_gguf.py --outfile gemma-4-E2B-it-bf16.gguf \
  --outtype bf16 --remote google/gemma-4-E2B-it

./build/bin/llama-quantize gemma-4-E2B-it-bf16.gguf \
  gemma-4-E2B-it-Q4_K_M.gguf Q4_K_M

公式は「16-bit で配布されている通常のケースでは --outtype auto（または省略）でもうまく動く」と述べています。すでにローカルにあるならディレクトリを指定して --remote を外します。型名は大文字小文字を区別せず、走らせる前にサイズだけ見たいときは --dry-run が使えます。

ここが最大の落とし穴です。量子化作業には、元モデルが丸ごと入るディスクと RAM が要ります。公式の注記は「you will need adequate disk space to save them and sufficient RAM to load them. At the moment, memory and disk requirements are the same.」です。

この表の「元サイズ」は1 パラメータ 4 バイト（FP32）換算だと読めます。Llama 3.1 8B は約 80.3 億パラメータで、80.3 億 × 4 バイト = 32.1 GB になるからです（計算例）。bf16 で配布されているモデルならダウンロード自体はその半分（約 16 GB）で、そこから作る中間の bf16 GGUF がもう約 16 GB。合計するとやはり 30 GB 台を触ることになります。

つまり 「4.9 GB を作るために 30 GB 台を用意する」のが 8B の実情で、ノート PC の作業ではありません。だから公式自身が逃げ道を用意しています。llama.cpp の main から 6 時間ごとに同期される Space「GGUF-my-repo」なら、セットアップなしでブラウザから量子化できます。

imatrix — 「どの重みが効くか」を測って渡す

imatrix（importance matrix、重要度行列）は、実際のテキストを流したときにどの重みが出力に大きく効いたかを実測した表です。量子化時にこれを渡すと、効く重みの誤差を優先して小さくできます。

./llama-imatrix -m ggml-model-f16.gguf -f calibration-data.txt -ngl 99

./llama-quantize --imatrix imatrix.gguf ggml-model-f16.gguf \
  ./ggml-model-q4_k_m.gguf q4_k_m

重要なのは、imatrix が「あった方がいい」ではなく型によっては必須だという点です。ソース（tensor_requires_imatrix()）が対象を 6 種に確定しています。IQ1_S / IQ1_M / IQ2_XXS / IQ2_XS / IQ2_S / IQ3_XXS を imatrix なしで指定すると ERROR: this quantization requires an importance matrix! で処理が中断します。IQ2_M や IQ3_S は「IQ」でも必須ではないので、頭文字ではなく型名そのもので覚えてください。もう 1 つ例外があり、Q2_K_S を指定したときにその中で使われる Q2_K テンソルだけは必須になります（ソースのコメントが「as a general rule, the k-type quantizations don't require imatrix data. the only exception is Q2_K tensors that are part of a Q2_K_S file.」と明言しています）。

Q4_K_M のような k-quant は無くても作れますが、品質は変わります。Llama 3 8B の公式スコアボードでは Q4_K_M の PPL 増分が imatrix あり 0.1513、なし 0.1755（差 0.024）。ところが Q2_K は 2.416 対 3.520 で差が 1.10 に開きます。効き幅はビット数が下がるほど大きいので、4bit なら「あれば少し良い」、2bit なら「無いと話にならない」と読めます（PPL の読み方は第 9 章）。一方、キャリブレーションデータを増やす方向には投資しないでください。公式の観察は「There seems to be no consistent improvement from using more Wikitext tokens」で、Q2_K の PPL は 1 千トークンで 8.683、1 千万トークンで 8.648 と誤差レベルです。

python3 -m pip install -r requirements.txt
python convert_hf_to_gguf.py --outfile model-bf16.gguf --outtype auto ./local-model-dir

./build/bin/llama-quantize --dry-run model-bf16.gguf Q4_K_M
./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M

./scripts/get-wikitext-2.sh
./build/bin/llama-perplexity -m model-Q4_K_M.gguf -f wikitext-2-raw/wiki.test.raw

別ルート: Apple Silicon の MLX と GPU サーバの vLLM

経路 C — MLX（Apple Silicon）

Apple 製の MLX では変換と量子化が 1 コマンドで終わり、中間ファイルが要りません。--hf-path と --model は同じ引数の別名です（HF 側ドキュメントは前者の表記）。python -m mlx_lm.convert の直呼びは非推奨です。

pip install mlx-lm

mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q
mlx_lm.convert --model Qwen/Qwen3-8B -q --q-bits 4 --q-group-size 64 --mlx-path ./q3-4bit
mlx_lm.generate --model ./q3-4bit --prompt "hello"

指定するのは主に --q-bits（affine で使えるのは 2 / 3 / 4 / 5 / 6 / 8。7 は無い）、--q-group-size（32 / 64 / 128）、--q-mode（affine / mxfp4 / nvfp4 / mxfp8）です。ヘルプに既定値が出ませんが、affine の実際の既定は bits = 4、group_size = 64（実装のテーブルで確定）。--mlx-path の既定は mlx_model で、既存パスを指定すると失敗します。

group size を意識すべき理由は算術で説明できます。affine では group_size 個の重みごとに scale と bias を 1 組持ち、その 2 つは入力と同じ dtype（bf16 = 16bit）で保存されます。つまりグループ 1 個につき 16 + 16 = 32 ビットが重みとは別に必要で、これを group_size 個の重みで割り勘します。したがって 1 重みあたりの実効ビット数は次のようになります。

bpw = bits + 32 ÷ group_size

既定値を入れると bpw = 4 + 32 ÷ 64 = 4.5（計算例）。配布されている mlx-community/Qwen3-8B-4bit の実測は 4.5005 bpw で式と一致します。--q-group-size 32 にするとスケールの数が倍になって 4 + 32 ÷ 32 = 5.0 bpw に増え、group 32 で配布されている別モデルの実測も 5.0007 bpw です。MLX の「4bit」は 1/4 ではなく、bf16 比で約 3.56 分の 1（16 ÷ 4.5）です。llama.cpp の _M に相当する混合ビットは --quant-predicate mixed_3_6 などで選べ、実装コメントも「similar choices to, for example, llama.cpp's Q4_K_M」と明言しています。

pip install mlx-lm
mlx_lm.convert --model Qwen/Qwen3-4B-Instruct-2507 -q --mlx-path ./q3-4bit
mlx_lm.convert --model Qwen/Qwen3-4B-Instruct-2507 -q --q-bits 6 --mlx-path ./q3-6bit
du -sh ./q3-4bit ./q3-6bit
mlx_lm.generate --model ./q3-4bit --prompt "3 行で自己紹介して"

経路 D — vLLM（GPU サーバ）

複数リクエストを同時に捌くサーバ用途で GGUF は使いません（公式が「GGUF support in vLLM is highly experimental and under-optimized」と明記）。使うのは compressed-tensors 形式で、W4A16 は「重みを 4bit、活性化（層を流れる中間の数値）は 16bit のまま」を意味します。まずは既製を引くのが正解で、発行元のモデルカードが削減率と精度回復率を公表しています。RedHatAI/Meta-Llama-3.1-8B-Instruct-quantized.w4a16 は「reducing the disk size and GPU memory requirements by approximately 75%」（128 パラメータごとの per-group、OpenLLM v1 回復率 98.9%）、...-quantized.w8a8 は約 50% 削減に加えて「matrix-multiply compute throughput (by approximately 2x)」です。

選び分けには根拠があります。重みだけを量子化した A16 は GPU メモリからの読み出し量を減らす最適化で、演算そのものは 16bit のままなので減りません。W8A8 は活性化も 8bit なので低精度の演算パスに乗り、計算自体が速くなります。開発チームの論文（arXiv:2411.02355）の結論は「W4A16 is the most cost-efficient for synchronous setups, while W8A8 dominates in asynchronous continuous batching」。1 件ずつ順に処理するなら W4A16、大量同時なら W8A8 です。

自分で作る最小レシピはこうなります。vLLM と llm-compressor は別の環境に入れてください（公式が「Please use separate environments for vLLM and llm-compressor as they might not work together.」と全ページに書いています）。

from llmcompressor import oneshot
from llmcompressor.modifiers.quantization import GPTQModifier

recipe = GPTQModifier(targets="Linear", scheme="W4A16", ignore=["lm_head"])

oneshot(model=model, dataset=ds, recipe=recipe,
        max_seq_length=2048, num_calibration_samples=512)
model.save_pretrained(SAVE_DIR, save_compressed=True)

キャリブレーション（= 実データを流して量子化パラメータを決める工程）の規模は公式の定数どおり 512 サンプル・最大長 2048 で、助言は「It's best to use calibration data that closely matches your deployment data.」。所要時間の目安は「Calibration for 8B model takes ~20 minutes on one A100 gpu」です。キャリブレーションを省きたいなら、チェックポイントを作らずロード時に落とす vllm serve <model> --quantization fp8_per_tensor もあります。

やってはいけないこと と、詰まったときの逆引き

つまずきポイント

理解度チェック

まとめ

• 実務は 4 段のはしご。①既製を落とす → ②設定を詰める → ③自分で変換する → ④自分で量子化する。登る条件は「遅い・載らない」「欲しい量子化が無い」「低ビットを追い込む」で、条件が出ていないなら下の段で止まってよい
• ①の答えは Q4_K_M。llama.cpp の -hf 既定、Ollama の HF 経由の既定、LM Studio の「4bit 以上」推奨が独立に一致している
• 確認手段は ollama show の quantization 行、ollama ps の PROCESSOR 列、lms load --estimate-only。-ngl は既定 auto なので手で 99 と書かない
• GGUF 化は必ず 2 段階（convert_hf_to_gguf.py → llama-quantize）で、元モデルが丸ごと入る RAM とディスクが要る（8B なら 32.1 GB）。無理なら GGUF-my-repo Space へ
• imatrix は IQ1_S / IQ1_M / IQ2_XXS / IQ2_XS / IQ2_S / IQ3_XXS で必須、k-quant では任意。効き幅はビット数が下がるほど大きく、キャリブレーションデータを増やしても改善は一貫しない
• MLX は 1 コマンドで完結し、実効 bpw は bits + 32 ÷ group_size（既定の「4bit」は 4.5 bpw）。vLLM は逐次なら W4A16、大量同時なら W8A8

次章では、ここまでの選択と数値を 1 枚に畳んだ選択フロー・ビット数対応表・用語辞典をまとめます。

参考リンク

• llama.cpp — tools/quantize/README.md（2 フェーズの手順・bits/weight とサイズの実測表）
• llama.cpp — tools/imatrix/README.md（imatrix の作り方とオプション）
• llama.cpp — tools/perplexity/README.md（Llama 3 8B スコアボード）
• llama.cpp — tools/cli/README.md（-hf と -ngl の既定値）
• llama.cpp — docs/install.md（パッケージマネージャ別の入手方法）
• llama.cpp — docs/multi-gpu.md（メモリを削る順序・-fa が必須になる条件）
• llama.cpp — token_generation_performance_tips.md（CPU のみ 1.7 t/s と GPU 全載せ 9.1 t/s の実測表）
• Ollama — Importing a Model（--quantize と対応量子化）
• Hugging Face Hub — Use Ollama with GGUF Models
• LM Studio — Download an LLM（「4bit 以上を選べ」）
• mlx-lm — README（mlx_lm.convert の使い方）
• vLLM — Quantization（対応ハードウェアと llm-compressor）
• GGUF-my-repo（セットアップ不要の量子化 Space）