サイジングガイド・10分で読了

# 実際にどの量子化フォーマットを使うべきか。

推論スタックは、他の何よりも先に数値形式を尋ねてきます。その答え一つで月額料金は最大8倍変わります。重みが最も小さい形式が、必ずしも最も小さいモデルを意味するとは限りません。

簡潔な答え

- **経験則:** 重みは名前の通りの比率で縮小します—BF16 / FP16 **2 B/param** · FP8 **1 B/param** · 4-bit (AWQ, GPTQ) **0.5 B/param**。それ以外は縮小しません。
- **その価値:** Qwen 3 32Bには、フル精度で[NVIDIA A100 PCIe](https://gpuserver.io/ja/gpu/a100-80gb)が**$1,091**/月、4ビットで[NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4)が**$125**/月必要です。モデルもコンテキストも同じです。
- **落とし穴:** key/valueキャッシュは重みほどには縮小しません。128kコンテキストでは、4-bitのLlama 3.3 70Bは**53 %**がキャッシュで、重みはわずか47 %です。
- **4ビットが完全に劣る場面:** Llama 3.1 8B(128k)は、4ビットで**23.0 GB**を必要とし、FP8の**18.4 GB**を上回ります—メモリを多く使うのに、品質は劣ります

## ここから始める

このページの大部分は計算ですので、まず結論から述べます。形式を決めるのは4つの質問であり、それぞれが単独で結論を出せるため、この順番で尋ねます。

**モデルはすでにフル精度で、コンテキスト分の余裕を持って収まっていますか?**それならBF16のまま実行して、ここで読むのをやめてください。量子化とはより小さいマシンを買うための手段であり、あなたはすでに動くマシンを買っています。収まっているモデルを圧縮しても、得られるものはありません。

**コンテキストが短く、モデルは大きいですか?**ここが4-bitの評判通りの実力を発揮する領域です。メモリの大半を重みが占めており、それを4分の1に削ることは、マシンを4分の1に削ることにほぼ等しくなります。

**コンテキストが長く、モデルは小さいですか?**対応するカードでFP8を使ってください。FP8は重みだけでなくキャッシュも半減させ、ある長さを超えると重要になるのはこの2つ目の半減の方です—下の表は、それが4-bitを上回る正確な地点を示しています。

**1台のマシンで1人にサービスを提供していますか?**Ollama経由のGGUFが群を抜いて手間が少なく、犠牲になるスループットも、1人の利用者ではもともと使い切れなかった分です。

この先の内容はすべて、その4つの答えがなぜそうなるのかを説明し、当社のモデルではなくあなた自身のモデルに対して検証できる数値を示すものです。そもそも自分のモデルにどれだけのメモリが必要かをまだ把握していない場合、その計算は[別のガイド](https://gpuserver.io/ja/guides/vram-sizing)にまとめてあり、そちらを先に読むべきです。

## 3つの形式、4つの名称

推論に一般的に使われる数値形式は3つしかなく、違いはただ1つ、パラメータ1つあたり何バイトかかるかです。それ以外のAWQ、GPTQ、GGUF、bitsandbytes—はすべて、この3つのいずれかを生成するための手法であり、4つ目の形式ではありません。

**3つの数値形式と、それぞれのバイト数がどこに適用されるか**

| 形式 | 重みあたりのバイト数 | キャッシュ要素あたりのバイト数 | 用途 |
|---|---|---|---|
| BF16 / FP16 公開されたままの重み | 2 | 2 | リファレンス品質 |
| FP8 推論スタック自体が生成 | 1 | 1 | リファレンス設計に近い、HopperおよびBlackwell |
| 4-bit (AWQ, GPTQ) あらかじめ用意されたチェックポイント | 0.5 | 2 | 最小の重み、キャッシュはFP16のまま |

2つの数値列は対として読んでください。最初の2行では等しく、3行目では*等しくありません*。この1つの非対称性が、このページの後半で見られる意外な結果の大半の原因です。

モデルリポジトリで実際に目にする4つの名称は、この表に次のように対応します。

### AWQとGPTQ

同じ4ビットという行き先へ至る二つの経路です。AWQはアクティベーションを観測して重要な重みを判断し、それらを保護します。GPTQは層ごとに圧縮し、その都度誤差を補正します。どちらもvLLMとSGLangがそのまま読み込めるチェックポイントを生成し、どのモデルでも両者の差は、どちらか一方と16ビットとの差より小さくなります。

### GGUF

llama.cppファミリーであり、Ollamaが内部で使っているものです。単一の方式というより、コンテナ形式です。1つのファイルに十数種類の精度のいずれかで重みを保持でき、カードが小さすぎる場合はレイヤーをシステムRAMに退避させます。1台のマシンで1人のユーザーに使う分には無敵ですが、実際の同時実行下では3つの中で最も弱くなります。

### FP8

チェックポイント形式というより、モードに近いものです。推論スタックに16-bitの重みを渡すと、読み込み時にFP8へキャストします。別途ダウンロードもキャリブレーションも不要です。4つの中で唯一キャッシュも圧縮できる形式であり、そのため以下では意外な場所に登場します。

### BF16とFP16

著者が公開した、そのままの重みであり、他のすべての行が比較される基準です。パラメータ1つあたり2バイト、キャリブレーションセットは不要、カーネル対応の確認も不要、品質をめぐる議論も生じません。これで収まるなら、それが正解であり、このページの残りは気にする必要がありません。

それぞれを指定するのはフラグ1つだけです。これらは[vLLMガイド](https://gpuserver.io/ja/guides/serve-llama-70b)で詳しく扱っているのと同じオプションです。ここで言いたいのは、その違いがいかに小さいかということだけです。

同じサーバーを4通りに

```
# 1. Reference. The weights as published, nothing to prepare.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16

# 2. FP8, quantised while it loads. No second download, no calibration.
#    --kv-cache-dtype is the half everyone forgets: it is what
#    halves the CACHE as well as the weights.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct \
    --quantization fp8 --kv-cache-dtype fp8

# 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else.
$ vllm serve casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin

# 4. Four-bit GPTQ. Same idea, different repository and flag.
$ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \
    --quantization gptq_marlin
```

## 縮まらない半分

重みを4 bitに量子化しても、key/valueキャッシュは量子化されません。AWQとGPTQは重みだけを圧縮対象とし、キャッシュを別途FP8にするよう指定しない限り16 bitのままです。そして4-bitのチェックポイントでは、ほとんどの人がそれを行いません。これが上の表の3列目であり、以下の計算が誰の予想通りにもならない理由です。

その帰結が最もわかりやすいのは、1つのモデルで見た場合です。以下は、[コンフィギュレーター](https://gpuserver.io/ja/configure)が提供する各コンテキスト長における4-bitのLlama 3.3 70Bです—重みとキャッシュを対比しています。

**4ビット70Bモデルの重みとキャッシュ（コンテキスト長別）**

| コンテキスト | 重み | KVキャッシュ | キャッシュの割合 |
|---|---|---|---|
| 4kトークン | 35.0 GB | 1.3 GB | 3 % |
| 8kトークン | 35.0 GB | 2.5 GB | 7 % |
| 32kトークン | 35.0 GB | 10.0 GB | 22 % |
| 128kトークン | 35.0 GB | 40.0 GB | 53 % |

重みの列は動きません—それこそが量子化する意味そのものです。キャッシュの列はコンテキストに比例して増え続け、最後の行では、そのモデル自体よりも大きくなります。

**128kでは、4-bitのLlama 3.3 70Bは53 %がキャッシュです。** 重みを4分の1のサイズに量子化しても、必要なマシンはほとんど変わりません。すでに問題ではなくなっていた部分を圧縮しただけだからです。重みの数値だけを根拠に長いコンテキストの構成をサイジングすると、半分以上も見積もりを誤ることになります。

それを十分押し進めると、4-bitはまったく優位を保てなくなります。FP8は両方の半分を半減させますが、4-bitは一方の半分を4分の1にし、もう一方には手を付けません。そのため、どのモデルにも両者が逆転するコンテキスト長が存在し、モデルが小さいほどそれは早く訪れます—小さいモデルは節約できる重みが少ない一方で、トークンあたりのキャッシュの増え方は変わらないからです。

**FP8と4-bitのメモリ総量（モデル・コンテキスト長別）**

| モデル | 4k | 8k | 32k | 128k |
|---|---|---|---|---|
| Llama 3.1 8B 8Bパラメータ·32層·8KVヘッド | 5.24-bit、4.3 GB差 | 5.84-bit、4.0 GB差 | 9.24-bit、2.3 GB差 | 23.0FP8が優位—18.4 GB |
| Qwen 3 32B 32Bパラメータ·64層·8KVヘッド | 19.54-bit、17.8 GB差 | 20.74-bit、17.2 GB差 | 27.64-bit、13.8 GB差 | 55.2互角 |
| Llama 3.3 70B 70Bパラメータ·80層·8KVヘッド | 41.74-bit、39.5 GB差 | 43.14-bit、38.8 GB差 | 51.74-bit、34.5 GB差 | 86.34-bit、17.2 GB差 |

数値はギガバイト単位で、2つの形式のうち小さい方を示し、負けた方の形式は下に記載しています。左から右へ読み進めると、コンテキストが伸びるにつれて4-bit列の優位性が失われていく様子がわかります。

最後の行はどこでも優位を保ち続けます。700億パラメータともなれば、節約できる重みの量が非常に大きいからです。中央の行は互角に終わります。128kでは、Qwen 3 32Bはどちらの形式でも費用がまったく同じになり、品質を考えればFP8を選ぶことになります。そして最初の行は完全に逆転し at 128k、そこでは4-bitがFP8より*多くの*メモリを要求しながら、忠実度は2つのうち低い方になります。この組み合わせ—メモリは多く、出力は劣る—が、当社が目にする中で最もよくある量子化の失敗であり、重みファイルのサイズだけを見ていては気づけません。

## お使いのカードが実際にできること

FP8は、ソフトウェアの機能である以前に、ハードウェアの機能です。テンソルコアがFP8に対応していないカードでも、FP8のチェックポイントを読み込むこと自体はできます—スタックが乗算の前に重みを16 bitに展開するからです—ですが、得られるのはダウンロード容量の節約だけで、速度面の恩恵はなく、FP8キャッシュもまったく使えません。4-bitはその逆で、どこでも動作します。演算の前にどのみち重みが16 bitに展開されるからです。

**カタログ内のカードを世代別に、FP8対応状況とともに**

| 生成 | 当社が貸し出しているカード | FP8 |
|---|---|---|
| Ampere | NVIDIA RTX A6000 48GB, NVIDIA A100 PCIe 40GB, NVIDIA A100 PCIe 80GB, NVIDIA A100 SXM4 80GB | ハードウェアには対応なし—16-bitに展開 |
| Ada Lovelace | NVIDIA L4 24GB, NVIDIA RTX 4090 24GB, NVIDIA L40S 48GB | テンソルコア内で—重みとキャッシュ |
| Hopper | NVIDIA H100 PCIe 80GB, NVIDIA H100 SXM5 80GB, NVIDIA H200 SXM5 141GB | テンソルコア内で—重みとキャッシュ |
| Blackwell | NVIDIA RTX 5090 32GB, NVIDIA B200 SXM6 180GB | テンソルコア内で—重みとキャッシュ |

この列が説明しているのはシリコン側の話であり、FP8がどこで有効かという問いとは、実は少し違います。カタログ自身がこの形式に添えている注記はHopper and Blackwellを挙げていますが、これはテンソルコアではなく推論スタックについての言明です。つまり、FP8カーネルとFP8キャッシュが最も多く使われ、最も予想外の事態が少なかった世代だということです。Ada Lovelaceでも動作します。HopperとBlackwellは、それに依存するデプロイを置くべき世代です。

**Ampereのカードでは、FP8はダウンロード容量の節約以上の意味を持ちません。** NVIDIA RTX A6000, NVIDIA A100 PCIeとNVIDIA A100 SXM4のテンソルコアにはFP8の処理経路がありません。そのいずれかでキャッシュを半減させるつもりだったとしても、それは実現しません—そして上のFP8列にあるメモリ数値は、そのハードウェアでは到達できない数値です。カードと形式は、この順番でセットで選んでください。

カードを選ぶ前に知っておく価値がある、もう1つの点です。Llama 3.3 70BをFP8で8kコンテキストにて動かすには81.9 GBが必要ですが、80 GBのカード—中でもNVIDIA A100 PCIe—はそれに1.9 GB足りません。表計算上は目立つほどの不足ではありませんが、実機では確実に失敗するだけの不足です。単独でこれをクリアできるカードは1つ上のクラスであり、[コンフィギュレーター](https://gpuserver.io/ja/configure)を使えば、支払う前にどのカードかがわかります。

## 速度面で得られるもの

1つのトークンを生成するとは、アクティブな重みをメモリから1回読み出すことを意味します。重み1つあたりのバイト数が少ないほど読み出すバイト数も少なくなり、毎秒のトークン数は増えます—1つの非バッチストリームでは、この関係はほぼ線形です。カードが他に何も待つ必要がないからです。これは、[トークン単価ガイド](https://gpuserver.io/ja/guides/api-vs-self-hosting)が割り算に使っているのと同じメモリ帯域幅の上限であり、意図的に保守的な値です。以下では、当社が貸し出しているすべてのシングルカードマシンで動作するほど小さいモデルにこれを適用しており、形式とカードを同じ表から読み取れるようにしています。

**8Bモデルのシングルストリーム生成レート（カード・形式別）**

| カード | 帯域幅 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|---|
| NVIDIA L4 24 GB·$125/月 | 300 GB/s | ~ 8 tok/s | ~ 17 tok/s | ~ 34 tok/s |
| NVIDIA RTX A6000 48 GB·$286/月 | 768 GB/s | ~ 22 tok/s | ~ 43 tok/s | ~ 86 tok/s |
| NVIDIA L40S 48 GB·$714/月 | 864 GB/s | ~ 24 tok/s | ~ 49 tok/s | ~ 97 tok/s |
| NVIDIA RTX 4090 24 GB·$193/月 | 1008 GB/s | ~ 28 tok/s | ~ 57 tok/s | ~ 113 tok/s |
| NVIDIA A100 PCIe 40 GB·$392/月 | 1555 GB/s | ~ 44 tok/s | ~ 87 tok/s | ~ 175 tok/s |
| NVIDIA RTX 5090 32 GB·$335/月 | 1792 GB/s | ~ 50 tok/s | ~ 101 tok/s | ~ 202 tok/s |
| NVIDIA A100 PCIe 80 GB·$1,091/月 | 1935 GB/s | ~ 54 tok/s | ~ 109 tok/s | ~ 218 tok/s |
| NVIDIA H100 PCIe 80 GB·$1,469/月 | 2000 GB/s | ~ 56 tok/s | ~ 113 tok/s | ~ 225 tok/s |

Llama 3.1 8Bを1枚のカードで、同時に1ストリームずつ。掲載されているすべてのマシンが三つのフォーマットすべてに対応しているため、行は縦方向だけでなく横方向にも比較できます—そして三列の比率はどの行でも同じです。それは重みあたりのバイト数だけで決まるからです。

この表を読む際に注意すべき点が2つあります。1つ目は、この表が1度に1リクエストの場合を記述している点です。実際には1度に1リクエストだけを処理することはほとんどなく、連続バッチ処理のもとでは重みはバッチ全体につき1回しか読み出されないため、制約はメモリではなく演算能力になり、列間の比率は縮まります。2つ目は、逆量子化にはコストがかかるという点です。4-bitの重みは乗算の前に展開する必要があり、小さいモデルでバッチサイズが小さい場合、その展開処理が、読み出しが小さくなったことで得られた分の目に見える割合を食いつぶすことがあります。この表が示す方向性は信頼できますが、正確な倍率までは保証されません。

## かかるコスト

この話題においては、自信満々な数値ほど疑ってかかるべき部分であり、それは当社の数値も例外ではありません。量子化による誤差は、手法よりもモデルにはるかに大きく左右され、公開されている比較結果同士が食い違うのは、異なるモデルを異なるタスクで測定しているからです。正直に言えるのは、その大まかな傾向だけです。

**FP8は、議論の余地がないと言える程度には十分近い値です。**FP8はあくまで浮動小数点形式であり—指数部と仮数部のビット数がそれぞれ少なくなっているだけで—4-bitのチェックポイントのようにグループごとのスケールを使って整数グリッドへマッピングする必要はありません。だからこそ劣化がごく穏やかであり、キャリブレーションも不要です。多くのチームは評価を行わずに採用し、その多くはそれで問題なく済ませています。

**4-bitは現実のトレードオフであり、その影響は一様には現れません。**ベンチマークの平均スコアは通常ほとんど変化しません。変化するのはテール部分です。長い推論の連鎖、正確な算術、まれな言語、厳密な出力フォーマットなどが影響を受けます。多肢選択式のベンチマークでは高いスコアのままでも、JSONを正しく閉じられなくなることがあります。

**大きいモデルほど劣化を吸収しやすくなります。**70Bでの4-bitはごく普通のデプロイです。一方、各パラメータがより多くの情報を担う8Bでの4-bitは劣化が顕在化しやすく—上の表が示す通り、得られる利得も最小です。

**キャリブレーションデータの方が、方式の名前よりも重要です。**AWQもGPTQも、サンプルコーパスに対して圧縮を行います。英語の文章でキャリブレーションされたチェックポイントをコード用途に使うと、その方式が本来持つはずの性能より劣化しますが、そのことをベンチマーク表は教えてくれません。

そこから導かれる、このページで唯一計算によらない推奨は「両方動かしてみる」ことです。rootアクセスがあり、従量課金も一切ないマシンを借りているのですから、同じモデルを2つのポートでそれぞれ立ち上げ、自分の手で百件のプロンプトを流し込んでも、かかるのは一晩だけです。それによって、他人ではなく自分のワークロードについて答えが出ます。これはどんな表よりも、この表を含めて、実質的に優れた答えです—だからこそ私たちは、スコアよりも計算式をお見せしたいのです。

**コストが最も低い順に試してください。** そもそも収まるなら、まずBF16から始めてください。それが他の実行結果と比較する際の基準になります。次にFP8へ切り替えます—同じチェックポイントのまま、フラグ1つで、ダウンロードも不要です。4-bitのチェックポイントに手を伸ばすのは、上の2つがメモリの制約で除外された場合だけにし、その際は自分の予想ではなくFP8の実行結果と比較してください。

## それが意味するマシン

これらすべてが重要になるのは、結局のところ請求書のためです。以下は、[当社のカタログ](https://gpuserver.io/ja/#catalog)の中で、8kコンテキストにおいて各モデルを3つの形式それぞれで*まるごと*収容できる最安のマシンです—「まるごと」とは1枚のカードに収まり、分割しないという意味です。カードをまたいで分割されたモデルは[インターコネクト](https://gpuserver.io/ja/guides/nvlink-vs-pcie)の話を持ち込むことになり、それは別のガイドの範囲です。

**各モデルをまるごと収容できる最安のマシン（形式別）**

| モデル | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B | [NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) $125/月·19.5 GB必要 | [NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) $125/月·9.8 GB必要 | [NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) $125/月·5.8 GB必要 |
| Qwen 3 32B | [NVIDIA A100 PCIe](https://gpuserver.io/ja/gpu/a100-80gb) $1,091/月·75.9 GB必要 | [NVIDIA RTX A6000](https://gpuserver.io/ja/gpu/rtx-a6000) $286/月·37.9 GB必要 | [NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) $125/月·20.7 GB必要 |
| Llama 3.3 70B | [4 × NVIDIA B200 SXM6](https://gpuserver.io/ja/gpu/b200) $11,790/月·163.9 GB必要 | [4 × NVIDIA H200 SXM5](https://gpuserver.io/ja/gpu/h200) $8,405/月·81.9 GB必要 | [NVIDIA RTX A6000](https://gpuserver.io/ja/gpu/rtx-a6000) $286/月·43.1 GB必要 |

8kコンテキストにおいて、実際に当社が貸し出しているマシンでの数値です。セルにカードが複数記載されている場合、それはモデルの分割ではなく、そのカードが提供される最小のノード構成を意味します。最も大きなカードは4枚組や8枚組でしか販売されておらず、フル精度の70Bを分割せずに済ませる最も安い方法は、4枚組を1台買って1枚だけ使うことです。これはまさに、量子化が回避しようとしている出費そのものです。

**中央の行を横に見ていきます。$1,091対$125、およそ9×です。** 同じQwen 3 32B、同じ8kコンテキスト、同じ1枚のカード、同じrootアクセス—違うのは数値形式だけです。これが量子化の商業的な意義のすべてであり、だからこそ半日読むより一晩測定する方に価値があるのです。

この表を正しく使えるかどうかを分けるのは、二つの習慣です。モデルの最大値ではなく、実際に運用するコンテキストでサイズを決めること—このページの二番目の表は、両者を混同した人に何が起きるかを示しています。そしてフォーマットは注文前にカードと照合すること、後からではありません。NVIDIA RTX A6000, NVIDIA A100 PCIeとNVIDIA A100 SXM4は、どのフラグを渡してもFP8の数値を返しません。[コンフィギュレーター](https://gpuserver.io/ja/configure)は、支払いの前に、あらゆるノードとあらゆるフォーマットについて、必要なメモリ量と1枚のカードに収まるかどうかを教えます。そもそもレンタルするかトークン課金のAPIを使うかを比較しているなら、[その損益分岐点](https://gpuserver.io/ja/guides/api-vs-self-hosting)は別途計算されており、量子化はそれをハードウェア側に大きく有利に動かします。

## 形式とマシンは併せて確認してください。

コンフィギュレーターは、支払いを行う前に、各精度であなたのモデルが何を必要とするか、そしてどのノードなら1枚のカードに収まるかを示します。

[コンフィギュレーターを開く](https://gpuserver.io/ja/configure) [ガイドを読む](https://gpuserver.io/ja/guides)

## その他のガイド

- [サイジング · 10分 混合エキスパートモデルを運用する 総パラメータ数がマシンを決め、アクティブパラメータ数が速度を決めます。DeepSeek V3とQwen 3 235Bが必要とするVRAM容量と、借りるべきノードを解説します。 ガイドを読む](https://gpuserver.io/ja/guides/mixture-of-experts)
- [コスト · 6分 月額レンタルが時間貸しに勝つのはどんな時か 実際の数字で算出した損益分岐点、時間単価が請求書が来るまで隠している3つのコスト、そして見積もりを3倍に膨らませるアイドル時間の落とし穴。 ガイドを読む](https://gpuserver.io/ja/guides/monthly-vs-hourly)
- [コスト · 9分 セルフホスティングとトークン課金APIの比較 トークン課金APIとGPUレンタルの損益分岐点を、自社の価格とスループットで算出。そして、その計算が見落としている4つの要素。 ガイドを読む](https://gpuserver.io/ja/guides/api-vs-self-hosting)

---

出典: https://gpuserver.io/ja/guides/awq-vs-gptq-vs-fp8/。このファイルはウェブサイトと同じデータから生成されています。ここに記載された数値がページの内容と異なる場合、ページの内容が正となり、このファイルは古い情報です。正式な出典はhttps://gpuserver.io/です。