# 量子化のサービング経済学：AWQ vs FP8、KVキャッシュとVRAM予算で本番コストは決まる

> LLMの量子化（AWQ / GPTQ / FP8 / GGUF）の選定は『精度』だけで語られがちですが、本番サービングのコストは『単一GPUのVRAM予算を、モデルの重みとKVキャッシュにどう配分するか』で決まります。量子化が重みを縮め、その分を同時実行・長文脈に回せる——この本質を、VRAM予算の試算コードと、T4 GPUで量子化モデルを本番運用した経験から、サービング経済学として解説します。

- 公開日: 2026-06-25
- 著者: 友田 陽大
- タグ: 生成AI, LLM, vLLM, セルフホスト, コスト最適化, 型安全
- URL: https://tomodahinata.com/blog/llm-quantization-serving-economics-awq-fp8-kv-cache-vram-budget

## 要点

- 量子化の本番選定は『精度』ではなく『サービング経済学』で決まる——単一GPUのVRAM予算を重みとKVキャッシュにどう配分するか
- 量子化は重みを縮め、空いたVRAMをKVキャッシュ（=同時実行数・文脈長）に回せる。これがスループットとトークン単価を左右する
- AWQ（4bit重みのみ）はVRAM削減が大きく、FP8非対応の旧GPU（T4等）でも大きいモデルを載せられる
- FP8は精度劣化が小さく計算スループットが高いが、ネイティブ対応はHopper/Ada世代以降。重みの圧縮はAWQほどではない
- 選定軸はGPU世代 × ワークロード（同時実行・文脈長）× 精度許容度。デコードはメモリ帯域律速で、量子化が速度に効く

---

最初に結論を述べます。**LLMの量子化（AWQ / GPTQ / FP8 / GGUF）の本番選定は、「どれが一番精度が落ちないか」ではなく、「単一GPUのVRAM予算を、モデルの重みとKVキャッシュにどう配分するか」というサービング経済学で決まります。** 量子化の本質は、重み（weights）を圧縮して空いたVRAMを**KVキャッシュ**——すなわち**同時実行数と文脈長**——に回せることにあります。これが、1枚のGPUで捌けるリクエスト数、ひいては**トークンあたりの原価**を直接左右します。精度の議論だけで量子化方式を選ぶと、本番のコスト効率を見誤ります。

本記事は、私が**Qwen3-8B-AWQ を Tesla T4 GPU 上の vLLM で本番運用**した経験をもとに、量子化を「サービング経済学」として捉え直し、VRAM予算の試算コードとともに解説します。量子化方式そのものの精度比較は[Qwen3の量子化比較（AWQ/GPTQ/FP8/GGUF）](/blog/qwen3-quantization-awq-gptq-fp8-gguf-comparison-guide)を、API vs 自前の損益分岐は[生成AIのコストと損益分岐](/blog/generative-ai-cost-api-vs-self-hosting-decision-guide)を参照してください。

---

## 1. GPUのVRAMは「重み」と「KVキャッシュ」で奪い合う

LLMをGPUで動かすとき、VRAM（GPUメモリ）は主に2つに使われます。

| VRAMの用途 | 内容 | 大きさの決まり方 |
|---|---|---|
| **モデルの重み（weights）** | モデルのパラメータそのもの | パラメータ数 × ビット数 |
| **KVキャッシュ** | 生成中の文脈を保持する作業領域 | 文脈長 × 同時実行数 × モデル構成 |

この2つは、限られたVRAMを**奪い合います**。重みが大きければ、KVキャッシュに使える残りが減り、**同時に捌けるリクエスト数や扱える文脈長が小さくなる**。逆に、量子化で重みを縮めれば、その分をKVキャッシュに回せて、**同時実行数を増やせる＝スループットが上がる＝トークン単価が下がる**。

ここが「サービング経済学」の核心です。量子化は単なる「省メモリ技術」ではなく、**GPUという固定費を、どれだけ多くのトークン処理に変換できるか**を決めるレバーなのです。

---

## 2. VRAM予算を試算する

この奪い合いを、数字で見える化します。前提を明示した純粋関数で、VRAM予算を「重み」と「KVキャッシュ」に分解します。

```ts
/**
 * 単一GPUのVRAM予算を「重み」と「KVキャッシュ」に分け、
 * 量子化が同時実行・文脈長にどれだけ余地を生むかを試算する純粋関数。
 * 前提（ビット数・KV単価・オーバーヘッド）はすべて引数で受け取る（再現可能・テスト容易）。
 */
interface VramBudgetInputs {
  readonly paramsBillions: number;        // パラメータ数（B）
  readonly weightBitsPerParam: number;    // 量子化ビット数（AWQ=4, FP8=8, FP16=16）
  readonly gpuVramGiB: number;            // GPU搭載VRAM（例: T4=16, L4=24, H100=80）
  readonly kvBytesPerToken: number;       // 1トークンあたりKVキャッシュのバイト数（モデル構成依存）
  readonly runtimeOverheadGiB: number;    // ランタイム・アクティベーションの固定オーバーヘッド
}

interface VramBudget {
  readonly weightGiB: number;
  readonly kvBudgetGiB: number;           // KVキャッシュに使える残り
  readonly maxKvTokens: number;           // 収容できる総トークン（≒ 文脈長 × 同時実行数）
  readonly fits: boolean;                 // そもそも重みが載るか
}

const BYTES_PER_GIB = 1024 ** 3;

export function estimateVramBudget(input: VramBudgetInputs): VramBudget {
  const weightBytes = input.paramsBillions * 1e9 * (input.weightBitsPerParam / 8);
  const weightGiB = weightBytes / BYTES_PER_GIB;

  const kvBudgetGiB = input.gpuVramGiB - weightGiB - input.runtimeOverheadGiB;
  const maxKvTokens =
    kvBudgetGiB > 0 ? Math.floor((kvBudgetGiB * BYTES_PER_GIB) / input.kvBytesPerToken) : 0;

  return {
    weightGiB,
    kvBudgetGiB: Math.max(0, kvBudgetGiB),
    maxKvTokens,
    fits: kvBudgetGiB > 0,
  };
}
```

この試算が示すのは、たとえば**8BのモデルをFP16（16bit）で載せると重みだけで約16GiBを占め、16GBクラスのGPU（T4）には実質載らない**——という現実です。ところが**AWQ（4bit）にすれば重みは約1/4に縮み**、同じGPUにモデルが載るうえ、KVキャッシュにも余地が生まれます。私がT4でQwenをAWQ（4bit量子化）で動かしたのは、まさにこの「16GBのGPUに、思考できる規模のモデルを載せて、固定費で回す」ためでした（T4はFP8非対応のため、注意機構のバックエンドにも配慮が要ります）。

> **注意**: 上の試算は重みとKVキャッシュの第一次近似です。実際にはアクティベーション・予約メモリ・KVキャッシュ量子化の有無で変動します。`kvBytesPerToken` はモデルの層数・隠れ次元・注意ヘッド構成（GQA等）で大きく変わるため、必ず対象モデルの実測値で較正してください。

---

## 3. AWQ vs FP8 vs GGUF：サービングの観点で選ぶ

量子化方式を「精度」ではなく「サービング経済学」の観点で並べると、こう整理できます。

| 方式 | 重みの圧縮 | 計算スループット | ハード要件 | 向くサービング |
|---|---|---|---|---|
| **AWQ（4bit weight-only）** | 大（約1/4 vs FP16） | デコードのメモリ帯域削減に効く | 旧世代GPU（T4等）でも可 | VRAMが厳しい・旧GPU・大きいモデルを1枚に載せたい |
| **GPTQ（4bit weight-only）** | 大 | AWQと同系統 | 旧世代GPUでも可 | AWQと同様（較正手法が異なる） |
| **FP8（8bit）** | 中（約1/2 vs FP16） | 高い（ネイティブFP8演算） | Hopper/Ada世代以降が必要 | 新世代GPUで精度を保ちつつ高スループット |
| **GGUF（llama.cpp系）** | 可変（多ビット幅） | vLLM比で低めになりがち | CPU+GPUオフロードに強い | ローカル・エッジ・GPUなし/小VRAM |

実務的な指針はこうです。

- **VRAMが厳しい／旧世代GPU（T4等）／大きいモデルを1枚に載せたい** → **AWQ（または GPTQ）**。4bitで重みを大きく縮め、KVキャッシュの余地を最大化する。
- **新世代GPU（L4 / L40S / H100 等）で、精度劣化を抑えつつ高スループット** → **FP8**。ネイティブ演算が速く、精度の落ち方も緩やか。ただし重みの圧縮はAWQほどではないので、VRAMがギリギリの構成には不利なこともある。
- **GPUを持たない／エッジ／個人利用** → **GGUF**（llama.cpp）。CPUとGPUにまたがってオフロードでき、柔軟。ただしサーバ用途の最大スループットでは vLLM + AWQ/FP8 に劣りがち。

**「どのGPU世代を使うか」で、最適な量子化方式は変わります。** FP8非対応のT4でFP8を選んでも意味がなく、H100でわざわざ4bit weight-onlyにすると、せっかくの計算性能を活かしきれないこともあります。

---

## 4. デコードは「メモリ帯域律速」——だから量子化が速度に効く

量子化が「省メモリ」だけでなく「高速化」にも効く理由を、最後に押さえます。LLMの推論は、

- **プレフィル（入力の処理）**——計算律速になりやすい。
- **デコード（1トークンずつ生成）**——**メモリ帯域律速**になりやすい。

デコードでは、トークンを1つ生成するたびにモデルの重みをVRAMから読み出します。つまり**「重みのバイト数」がデコード速度のボトルネック**になりがちです。量子化で重みのバイト数を減らせば、**読み出すデータ量が減り、デコードが速くなる**。これが、量子化が「メモリ節約」と「スループット向上」を同時にもたらすメカニズムです。

サービングのトークン単価は、おおまかに **GPUの時間あたりコスト ÷ スループット（トークン/秒）** で決まります。量子化は、(1) 重みを縮めてKVキャッシュ＝同時実行を増やし、(2) デコードのメモリ帯域を削って1リクエストを速くする——この両面でスループットを押し上げ、**トークン単価を下げます**。「精度が少し落ちるが、コストが大きく下がる」というトレードオフを、ワークロードの精度許容度に照らして選ぶのが、サービング経済学の判断です。

---

## よくある質問（FAQ）

### Q. 量子化方式は、何を基準に選べばいいですか？

「精度」だけでなく「サービング経済学」で選びます。具体的には、GPU世代 × ワークロード（同時実行数・文脈長）× 精度許容度の3軸です。VRAMが厳しい・旧世代GPU（T4等）ならAWQ（4bit）、新世代GPU（H100等）で精度を保ちたいならFP8、GPUなし・エッジならGGUF、が基本線です。量子化は重みを縮めてKVキャッシュ（同時実行・文脈長）に余地を生み、トークン単価を下げるレバーです。

### Q. AWQとFP8は、どちらが良いですか？

ハードウェアとワークロード次第です。AWQ（4bit weight-only）は重みの圧縮が大きく、FP8非対応の旧GPU（T4等）でも大きいモデルを1枚に載せられます。FP8は精度劣化が小さく計算スループットが高い一方、ネイティブ対応はHopper/Ada世代以降で、重みの圧縮はAWQほどではありません。VRAMが厳しいならAWQ、新世代GPUで精度重視ならFP8、が目安です。

### Q. KVキャッシュとは何ですか？なぜ重要ですか？

KVキャッシュは、生成中の文脈を保持する作業領域で、文脈長 × 同時実行数に比例してVRAMを消費します。モデルの重みとVRAMを奪い合うため、重みが大きいとKVキャッシュに使える残りが減り、同時に捌けるリクエスト数や扱える文脈長が小さくなります。量子化で重みを縮めれば、その分をKVキャッシュに回せて同時実行数を増やせる——これがスループットとコストを左右します。

### Q. なぜ量子化すると推論が速くなるのですか？

LLMのデコード（1トークンずつ生成する処理）は、トークンごとに重みをVRAMから読み出すため、メモリ帯域律速になりがちです。量子化で重みのバイト数を減らせば、読み出すデータ量が減り、デコードが速くなります。つまり量子化は「省メモリ」と「高速化」を同時にもたらします。サービングのトークン単価はGPU時間 ÷ スループットで決まるため、これが直接コストに効きます。

### Q. 16GBのGPU（T4）で、8BのLLMは動きますか？

FP16（16bit）では重みだけで約16GiBを占め、実質的に載りません。しかしAWQ（4bit）にすれば重みは約1/4に縮み、モデルが載るうえKVキャッシュにも余地が生まれます。実際にQwen3-8B-AWQをT4で本番運用した実績があります。ただしT4はFP8非対応のため、注意機構のバックエンドなど構成面の配慮が必要です。

---

## まとめ：量子化はVRAM予算の配分問題

LLMの量子化を本番サービングで正しく選ぶために、押さえるべきは次の通りです。

1. **本番選定は「精度」ではなく「サービング経済学」**——VRAM予算を重みとKVキャッシュにどう配分するか。
2. **量子化は重みを縮め、KVキャッシュ（同時実行・文脈長）に余地を生む**——これがトークン単価を左右する。
3. **AWQ（4bit）はVRAM削減が大きく、旧世代GPU（T4等）でも大きいモデルを載せられる**。
4. **FP8は精度劣化が小さく高スループットだが、Hopper/Ada世代以降が必要**。
5. **デコードはメモリ帯域律速**——量子化が省メモリと高速化を同時にもたらす。

「自前GPUでLLMを動かしたいが、どのGPUに・どの量子化で載せれば採算が合うか」——その見極めは、VRAM予算とワークロードの分析で解けます。量子化方式の選定からvLLMでの本番サービング、コスト最適化まで、本番運用品質でお引き受けします。