GPU

30秒で分かる

• GPUを見るときは 容量（GB）・帯域（GB/s）・演算性能（FLOPS） の3つを別々に見ます
• 容量が足りなければ、そもそもモデルが載りません（OOM）
• 帯域が生成速度（tok/s）の上限を決めます。デコードはメモリ読み出しが律速だからです
• 演算性能がTTFT（初回応答）を決めます。プリフィルは計算量が律速だからです
• 「大容量＝高性能」ではありません。容量が大きくても帯域が低いGPUは存在します

仕組み

3つの指標が、それぞれ別のものを決める

             GPU
              │
   ┌──────────┼──────────┐
   ↓          ↓          ↓
 容量        帯域       演算性能
 (GB)      (GB/s)     (FLOPS)
   │          │          │
   ↓          ↓          ↓
載るか？   tok/s      TTFT

この対応関係が、GPU選定の骨格です。要件のうちどれが厳しいかによって、優先すべき指標が変わります。

なぜデコードは帯域律速なのか

1トークンを生成するたびに、モデルの重みをメモリから演算器へ読み出す必要があります。ところが1トークン分の計算量はごくわずかです。

1トークンの生成

  重みを読む：数十GB    ← 時間がかかる
  計算する  ：わずか    ← すぐ終わる

  → 演算器は、データ待ちで遊んでいる（memory-bound）

そのため、単一リクエストのデコード速度はおおよそ次式で上限が決まります。

デコード速度の理論上限（tok/s） = メモリ帯域 ÷ 1トークンで読む重みのバイト数

たとえば重み30GB・帯域273GB/sなら、理論上限は約9 tok/sです。実装をどれだけ改善しても、この値を超えることはありません。

なぜプリフィルは演算律速なのか

入力トークンはまとめて処理できるため、重みを1回読み出す間に大量の計算を行えます。計算量はおおよそ次のとおりです。

プリフィルの計算量 ≒ 2 × パラメータ数 × 入力トークン数

例：30B・4,000トークン入力
  = 2 × 30 × 10^9 × 4,000
  ≈ 2.4 × 10^14 FLOPs

これを実効FLOPSで割った値が、TTFTの下限です。帯域を増やしてもTTFTは縮まりません。

メモリの種類

種類	特徴	向いている用途
HBM	容量は控えめだが帯域が極めて高い	本番の高スループット推論
Unified Memory	大容量を確保しやすいが帯域は低め	大きなモデルの検証、開発機
GDDR（コンシューマ）	中程度。容量が小さい	小規模モデルの検証

複数GPUと通信

1台に載らない場合、モデルを分割して複数GPUで動かします。分割方式によって通信量が変わり、GPU間の接続帯域（NVLinkかPCIeか）が性能を左右します。

方式	分け方	通信の重さ
Tensor Parallel	1レイヤを複数GPUで分担	重い（毎レイヤ同期）
Pipeline Parallel	レイヤ群をGPUごとに分担	軽いが待ちが生じる
データ並列（レプリカ）	モデル全体を各GPUに複製	なし

モデルが1台に載るなら、レプリカを並べるのが最も単純で速いというのが基本方針です。分割は「載らないから仕方なく行う」ものです。

設計に効く数字と落とし穴

見積もりに使う式

必要メモリ    = 重み + KV Cache + 上乗せ（10〜20%）
デコード上限  = メモリ帯域 ÷ 1トークンで読む重み
TTFT下限     = (2 × パラメータ数 × 入力トークン数) ÷ 実効FLOPS
必要な重み量  = メモリ帯域 ÷ 目標tok/s     ← 逆算で使う

最後の逆算式が実務では効きます。「この帯域でこの速度を出すには、重みを何GBまで減らす必要があるか」が即座に分かるためです。

落とし穴

• 公称FLOPSは条件付き：疎行列前提や特定精度での値が併記されることがあります。BF16／FP8のどの値かを必ず確認します
• 実効値は公称値を下回る：帯域もFLOPSも、実測では公称の6〜8割程度になることが珍しくありません。理論値は上限であり、達成値ではありません
• メモリは100%使えない：ランタイム、断片化、CUDAコンテキストで1〜2割は消えます
• 消費電力と設置環境：本番でGPUを複数台並べる場合、電源容量と冷却が先に限界へ達することがあります
• 調達リードタイム：性能要件を満たすGPUが、必要な時期に入手できるとは限りません。サイジングと同時に確認すべき項目です