最初に結論を述べます。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）を、API vs 自前の損益分岐は生成AIのコストと損益分岐を参照してください。
1. GPUのVRAMは「重み」と「KVキャッシュ」で奪い合う
LLMをGPUで動かすとき、VRAM（GPUメモリ）は主に2つに使われます。
| VRAMの用途 | 内容 | 大きさの決まり方 |
|---|---|---|
| モデルの重み（weights） | モデルのパラメータそのもの | パラメータ数 × ビット数 |
| KVキャッシュ | 生成中の文脈を保持する作業領域 | 文脈長 × 同時実行数 × モデル構成 |
この2つは、限られたVRAMを奪い合います。重みが大きければ、KVキャッシュに使える残りが減り、同時に捌けるリクエスト数や扱える文脈長が小さくなる。逆に、量子化で重みを縮めれば、その分をKVキャッシュに回せて、同時実行数を増やせる＝スループットが上がる＝トークン単価が下がる。
ここが「サービング経済学」の核心です。量子化は単なる「省メモリ技術」ではなく、GPUという固定費を、どれだけ多くのトークン処理に変換できるかを決めるレバーなのです。
2. VRAM予算を試算する
この奪い合いを、数字で見える化します。前提を明示した純粋関数で、VRAM予算を「重み」と「KVキャッシュ」に分解します。
/**
* 単一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の量子化を本番サービングで正しく選ぶために、押さえるべきは次の通りです。
- 本番選定は「精度」ではなく「サービング経済学」——VRAM予算を重みとKVキャッシュにどう配分するか。
- 量子化は重みを縮め、KVキャッシュ（同時実行・文脈長）に余地を生む——これがトークン単価を左右する。
- AWQ（4bit）はVRAM削減が大きく、旧世代GPU（T4等）でも大きいモデルを載せられる。
- FP8は精度劣化が小さく高スループットだが、Hopper/Ada世代以降が必要。
- デコードはメモリ帯域律速——量子化が省メモリと高速化を同時にもたらす。
「自前GPUでLLMを動かしたいが、どのGPUに・どの量子化で載せれば採算が合うか」——その見極めは、VRAM予算とワークロードの分析で解けます。量子化方式の選定からvLLMでの本番サービング、コスト最適化まで、本番運用品質でお引き受けします。