LLM 量子化サイズ計算

GGUF ファイルサイズ = パラメータ × 重みあたりの実効ビット ÷ 8。llama.cpp が測定した 4.89 ビットで、Llama 3.1 8B の Q4_K_M は 4.58 GiB、Q8_0 は 7.95 GiB、F16 は 14.96 GiB です(llama.cpp quantize README、2026 年 10 月 16 日確認)。

実効ビットは llama.cpp(Llama 3.1 8B)の値、確認日 2026-10-16。推定値です。

問題は解決しましたか?
Googleで優先表示

使い方

  1. モデルを選ぶとパラメータ、レイヤー、KV ヘッド、ヘッド次元が入ります。config.json の値を直接入れても構いません。
  2. コンテキスト長、KV キャッシュの精度、オーバーヘッドの割合を設定します。
  3. 表で量子化ごとの実効ビット、ファイルサイズ、合計メモリを確認します。名前の横の % は F16 に対するサイズです。

計算方法

ファイルサイズ = パラメータ × 重みあたりの実効ビット ÷ 8。llama.cpp が Llama 3.1 8B で測定した値を使います:F16 16.00、Q8_0 8.50、Q6_K 6.56、Q5_K_M 5.70、Q4_K_M 4.89、Q3_K_M 4.00、Q2_K 3.16。出典:ggml-org/llama.cpp リポジトリの tools/quantize/README.md、2026 年 10 月 16 日確認。

名前の数字より大きいのは、K-quant が重みのブロックごとにスケールと最小値を持ち、埋め込みや出力層など一部のテンソルを高い精度のまま残すためです。80.3 億パラメータで計算すると Q4_K_M は 4.58 GiB で、README と一致します。

メモリ = ファイルサイズ + KV キャッシュ + オーバーヘッド。KV キャッシュ = 2 × レイヤー × KV ヘッド × ヘッド次元 × コンテキスト × 値あたりのバイト数で、GPU VRAM 計算と同じ式です。オーバーヘッドはバッファやランタイムの分として自分で決める割合です。

結果は GiB(2^30 バイト)です。他のモデルはテンソル構成が違うため、実際のファイルが数 % ずれることがあります。

モデル別のファイルサイズ

量子化Llama 3.1 8BQwen2.5 32BLlama 3.1 70B
F1614.96 GiB61.02 GiB131.41 GiB
Q8_07.95 GiB32.42 GiB69.82 GiB
Q6_K6.14 GiB25.03 GiB53.91 GiB
Q5_K_M5.33 GiB21.75 GiB46.84 GiB
Q4_K_M4.58 GiB18.67 GiB40.20 GiB
Q3_K_M3.74 GiB15.24 GiB32.82 GiB
Q2_K2.95 GiB12.05 GiB25.95 GiB

どれを選ぶか

  • Q4_K_M がよく使われる標準です。サイズは F16 の約 31% です。
  • Q5_K_M と Q6_K は Q4_K_M より 16%、34% 多くメモリを使い、元のモデルにより近くなります。
  • Q8_0 は F16 の約半分で、品質は F16 に最も近い形式です。
  • Q3_K_M と Q2_K は大きなモデルを小さなカードに載せるためのものですが、品質の低下が大きくなります。llama.cpp の README に形式ごとのパープレキシティがあります。

よくある質問

7B モデルを Q4_K_M にするとどのくらい?

10 億パラメータあたり約 0.57 GiB なので、70 億なら約 3.99 GiB です。72.5 億パラメータの Mistral 7B v0.3 は約 4.13 GiB です。

Q4_K_M が 4 ビットより大きいのはなぜ?

重みのブロックごとにスケール値を持ち、一部のテンソルが高い精度のままだからです。llama.cpp は Llama 3.1 8B で重みあたり 4.89 ビットを測定しています。

70B モデルは Q4_K_M で 48 GB に収まる?

ファイルは約 40.2 GiB です。コンテキスト 8,192 トークンで KV キャッシュが 2.5 GiB 増え、オーバーヘッド 10% を加えると約 47 GiB なので、かなりぎりぎりです。

GPU VRAM 計算とどう違う?

同じメモリの式を使いますが、すべての GGUF 形式を実測の実効ビットで 1 つの表に並べ、ひと目で比べられるようにしています。