GPU推論の内部構造
注: この記事は英語版からの翻訳です。コードブロックおよびMermaidダイアグラムは原文のまま保持しています。
TL;DR
LLM推論は、1つのAPIをまとった2つの異なるワークロードです。プリフィル(プロンプトの処理)は計算律速です: 数千のトークンが並列に重みと乗算され、GPUのテンソルコアを飽和させます。デコード(トークンを1つずつ生成)はメモリ帯域律速です: 新しいトークンを1つ生成するたびに、モデル全体 — に加えて成長し続けるKVキャッシュ — をHBMからストリーミングする必要があり、移動するバイトあたりの演算はほとんどありません。H100上でバッチサイズ1の70Bモデルは、利用可能な計算能力の1%未満しか使いません。シングルストリームのトークン/秒の絶対的な上限は メモリ帯域 ÷ トークンあたりの読み出しバイト数 で決まり、プロンプトもフレームワークも巧妙なスケジューリングもこれを変えられません。過去3年の主要な推論最適化 — 連続バッチング、FlashAttention、量子化、投機的デコーディング、テンソル並列、プリフィル/デコード分離 — はすべて、次の2つの手のいずれかです: 算術強度(メモリトラフィック1バイトあたりの有効FLOPs)を上げるか、バイト数を減らすか。この章はそのモデルをハードウェアから積み上げ、ベンチマークの前にスループット上限を予測できる算数を提供します。サービング層のサーベイ(スケジューラ、ルーティング、キャッシュ階層)はLLMインフラ、汎用のモデルサービングスタックはモデルサービング、エージェントワークロードの視点(セッションルーティング、フリートコスト、ファンアウト経済性)はエージェント推論にあります。
5つの数字で見るGPU
この章のすべては、わずかなデータシートの数字から導かれます。H100 SXM(2023〜2026年の推論フリートの主力)とその後継:
| スペック | H100 SXM | H200 SXM | B200 |
|---|---|---|---|
| HBM容量 | 80 GB (HBM3) | 141 GB (HBM3e) | 192 GB (HBM3e) |
| メモリ帯域 | 3.35 TB/s | 4.8 TB/s | 8 TB/s |
| BF16密行列演算 | 989 TFLOPS | 989 TFLOPS | 約2,250 TFLOPS |
| FP8密行列演算 | 1,979 TFLOPS | 1,979 TFLOPS | 約4,500 TFLOPS |
| NVLink帯域(GPUあたり) | 900 GB/s | 900 GB/s | 1,800 GB/s |
(データシートのFLOPSはしばしば「スパース性あり」— 密の2倍の数字 — で引用されます。密なトランスフォーマーの推論に適用されるのは密の数値です。BlackwellのFP4テンソルコアはFP8スループットをさらに2倍にします。)
他のすべてを組織する数字がマシンバランスです: ピーク計算性能をメモリ帯域で割ったもの。
H100 balance (BF16): 989e12 FLOPS / 3.35e12 B/s ≈ 295 FLOPs per byte
H100 balance (FP8): 1979e12 / 3.35e12 ≈ 590 FLOPs per byteHBMトラフィック1バイトあたりの演算がマシンバランスを下回るワークロードはテンソルコアを飽和させられません — メモリ律速であり、実行時間は 移動バイト数 ÷ 帯域 そのものです。バランスを上回るワークロードは計算律速で、実行時間は FLOPs ÷ ピーク計算性能 です。これがルーフラインモデルであり、LLM推論はその両側に同時に住んでいます。
世代間で何が良くなったかに注目してください: H100 → H200 は同じ計算性能のまま帯域が43%、容量が76%増えました — 純粋なデコード向けアップグレードです。ベンダーはボトルネックがどこにあるかを理解していました。
ルーフライン: なぜデコードはメモリ律速なのか
トランスフォーマーのフォワードパスは、トークンあたりおよそ 2 × P FLOPs を実行します(Pはパラメータ数 — 各パラメータが乗算1回と累積1回に参加します)。バイト側はバッチサイズに依存します。重みはフォワードパス1回につきHBMから1回だけ読まれ、バッチ内のすべてのシーケンスで共有されるからです。
バッチサイズ1のデコード。 1つのシーケンスに対して1トークンを生成する場合:
Llama-3.3-70B in FP8: weights ≈ 70 GB
FLOPs = 2 × 70e9 = 140 GFLOPs
Bytes = 70e9 (all weights) + KV cache (see next section)
Arithmetic intensity ≈ 140e9 / 70e9 = 2 FLOPs/byte
Machine balance (H100, FP8): 590 FLOPs/byte → memory-bound by ~300×GPUは乗算ではなく重みのストリーミングに時間を費やします。トークン/秒の上限は直接導かれます:
Single-stream ceiling = bandwidth / bytes per token
= 3.35 TB/s / 70 GB ≈ 48 tokens/secスケジューラもカーネルもフレームワーク設定も、1台のH100上のFP8-70Bシングルストリームを約48 tok/sより先へは押し上げられません — 上限に近づくことしかできません(優れたエンジンは上限の80〜90%に達します)。このレートでGPUが供給するのは 48 × 140 GFLOPs ≈ 6.7 TFLOPS、FP8ピーク1,979 TFLOPSのうちの**計算稼働率0.3%**です。残りの99.7%が、すべてのバッチングと投機のトリックが刈り取る原資です。
バッチサイズBのデコード。 同じ重み読み出しがB個のシーケンスに仕えます: FLOPsはBに比例して増え、重みのバイト数は増えません。算術強度は重み1バイトあたり約 2B FLOPs となり、デコードが計算律速に転じるのは B ≈ バランス / 2 前後 — BF16でおよそ150並行シーケンス、FP8で約300です(KVキャッシュの読み出しを考慮する前の話です。各シーケンスは自分のKVトラフィックを持ち込み、それは償却されないため、交差点はさらに高くなります)。
プリフィル。 Nトークンのプロンプト処理はNトークンにわたる1回のフォワードパスです: 1回の重み読み出しに対して 2 × P × N FLOPs。強度は約 2N FLOPs/byte — 1,000トークンのプロンプトはFP8バランスの約3.4倍(BF16バランスの約7倍)です。数百トークンを超えるとプリフィルは計算を飽和させます。この非対称性 — デコードは計算を飢えさせ、プリフィルは計算を飽和させる — が、チャンクドプリフィル(同時スケジュールされたデコードが停滞しないようプリフィルのチャンクに上限を設ける)の、そして最終的には後述の分離型サービングの根本原因です。
投機的デコーディングは同じ算数を別の角度から利用したものです: 小さなドラフトモデルがkトークンを提案し、大きなモデルが1回のフォワードパスでk個すべてを検証します — 1回の重み読み出しをkトークンで償却する、まさにバッチングと同じ構図を、単一ストリームの内部で行います。だから投機は低バッチ(計算が余っている)で最も効き、高バッチ(計算が既に使われている)では効果が薄れるのです。
KVキャッシュの台帳
Attentionは過去のすべてのトークンのキーとバリューのベクトルを必要とします。毎ステップ再計算すると生成が二次関数的になるため、エンジンはこれをキャッシュします — そしてこのキャッシュは、HBMの容量と帯域の両方で重みと競合します。
グループドクエリアテンション(GQA)モデルのトークンあたりサイズ:
KV bytes/token = 2 (K and V) × layers × kv_heads × head_dim × bytes/param
Llama-3-70B (80 layers, 8 KV heads, head_dim 128, BF16):
2 × 80 × 8 × 128 × 2 ≈ 320 KB per token
→ a 128K-context sequence holds ≈ 40 GB of KV — half an H100.(完全なサイズ表、フラグメンテーションを解消するPagedAttentionの役割、キャパシティプランニングはモデルサービングにあります。)
容量の話はよく知られています。驚かせるのは帯域の話です。デコード中、各ステップは重みに加えてそのシーケンスのKVキャッシュ全体を読み出します。16Kトークンのシーケンス32本のバッチは 32 × 16,384 × 320 KB ≈ 168 GB のKVを運び — それが毎ステップ読まれ、70 GBの重み読み出しを圧倒します。したがって長いコンテキストは、すべてがメモリに収まる場合でもトークン/秒の上限を下げます: トークンあたりバイト数の分母がコンテキスト長とともに成長するのです。GQA(KVヘッドを64ではなく8にしてKVを8分の1に)、DeepSeekのマルチヘッド潜在アテンション(MLA、KVを低ランク潜在表現に圧縮)、FP8 KVキャッシュが、容量の機能であるだけでなくスループットの機能でもあるのはこのためです — そしてコンテキスト管理のプレフィックスキャッシング規律には、ハードウェアレベルの鏡像があります: キャッシュされたプレフィックスとは、GPUが再計算も再格納もしないKVのことです。
カーネル: FlashAttentionとメモリ階層
ルーフラインの論理は1レベル下でも再帰します。GPU内部の階層は HBM(TB/s、数十GB)→ L2(約50 MB)→ SM(ストリーミングマルチプロセッサ)ごとのSRAM/共有メモリ(H100で約228 KB、合計約20 TB/s)です。カーネルが速いのは、中間結果をSRAMに保持しHBMには1回しか触れないときです。
素朴なattentionはN×Nのスコア行列をHBMに実体化します:
One layer, one head, N = 8,192, BF16:
S = QKᵀ: 8192² × 2 B ≈ 134 MB written to HBM, read back for softmax,
written again, read again for ×V — ≈ 0.5 GB of HBM traffic per head,
× 64 heads × 80 layers ≈ multiple TB per single forward pass. Unusable.FlashAttention(Dao et al., 2022; v2 2023; Hopper向けv3 2024)はQ、K、VをSRAMサイズのブロックにタイル化し、softmaxを逐次的に計算(オンラインsoftmax)するため、N×N行列はHBMに一度も存在しません。HBMトラフィックはO(N²)からO(N)に落ち — FLOPsは変わりません。同じ数学をより少ないバイト移動で行う「速い」カーネル、という本章のテーゼの正典的な例です。FlashAttention-3はHopper固有の非同期性(テンソルコアの行列積とsoftmaxを別ワープで重ねる)とネイティブFP8サポートを加えます。
運用上重要なカーネルレベルの事実が他に2つあります:
- カーネル起動オーバーヘッドはデコード税。 デコード1ステップは数千の小さなカーネルであり、起動あたり約5μsのオーバーヘッドでCPUがボトルネックになり得ます。CUDAグラフはステップ全体を一度記録し、単一の起動として再生します — vLLMとTensorRT-LLMはデフォルトで有効にしており、素朴なPyTorchループに対する小バッチでの優位の大部分を占めます。
- Attentionカーネルは今やプラガブルな層。 FlashInfer、FlashAttention、TensorRT-LLMの融合カーネルが、ページドKVレイアウト、GQA特化、投機検証の形状で競っており、エンジンはモデルとハードウェアごとに差し替えます。新しいモデルアーキテクチャの性能が出ないとき、通常の容疑者は特化カーネルの欠如です。
バッチングの経済学
バッチングは遊休計算をスループットに変換します。対価はストリームあたりのレイテンシです。チューニングの前に定量化する価値があります:
# Decode-step time vs batch size, H100 FP8, 70B dense model, 8K avg context
BW, COMPUTE = 3.35e12, 1979e12 # bytes/s, FLOPs/s
W, KV_TOK = 70e9, 160e3 # weight bytes, FP8 KV bytes/token
def step_time(batch, ctx=8192):
bytes_moved = W + batch * ctx * KV_TOK
flops = batch * 2 * 70e9
return max(bytes_moved / BW, flops / COMPUTE) # roofline: slower side wins
for b in (1, 8, 32, 128):
t = step_time(b)
print(f"batch {b:>3}: {b/t:>6.0f} tok/s total, {1/t:>5.1f} tok/s per stream")
# batch 1: 47 tok/s total, 47.0 tok/s per stream
# batch 8: 333 tok/s total, 41.6 tok/s per stream
# batch 32: 958 tok/s total, 29.9 tok/s per stream
# batch 128: 1803 tok/s total, 14.1 tok/s per stream総スループットは急上昇し(重み読み出しが償却される)、ストリームあたりの速度 — 各ユーザーのトークン間レイテンシ — はKVトラフィックが支配的になるにつれ劣化します。トークンあたりコストは総スループットに比例して下がります: H100が約$2/時なら、バッチ1では出力100万トークンあたり約$12、バッチ128では約$0.31。これが推論プロバイダの経済エンジンの全貌であり、正しい目的関数が生のトークン/秒ではなくグッドプット — レイテンシSLOを満たすスループット — である理由です。連続バッチング(バッチ単位ではなく毎ステップでシーケンスを受け入れ・退出させる)が実バッチを満杯に保つ仕組みで、スケジューリングの機構はLLMインフラにあります。
運用上の失敗は、SLOの崖を越えたスループットチューニングです: バッチ256でベンチマークには勝つが、全ユーザーのトークン間レイテンシが70msに座り込む設定。まずSLOを決め(例: TTFT < 1秒、トークン間 < 40ms)、それを守れる最大バッチを探すこと。
量子化: バイトを半分に、上限を2倍に
デコード時間は バイト ÷ 帯域 なので、重みの精度は直接速度に変換されます — パラメータあたりバイト数を半分にするごとに、シングルストリーム上限はおよそ2倍になり、GPUあたりに載るモデルも2倍になります:
| フォーマット | バイト/パラメータ | 70B重み | H100 1ストリーム上限 | 品質コスト(典型) |
|---|---|---|---|---|
| BF16 | 2.0 | 140 GB (GPU 2枚) | 約24 tok/s | ベースライン |
| FP8 (E4M3) | 1.0 | 70 GB | 約48 tok/s | Hopper以降ではごく僅か。本番でほぼ普遍的 |
| INT4 weight-only (AWQ/GPTQ) | 0.5 | 35 GB | 約96 tok/s | 小さいが実在。数学・コード・ロングテール知識に集中 |
| FP4 (NVFP4/MXFP4, Blackwell) | 0.5 | 35 GB | B200でFP8の約2倍 | FP4テンソルコアで計算も削減。QATが差を縮小中 |
節約がどこに落ちるかは機構によって異なります。FP8はHopper/Blackwellのテンソルコアでネイティブに動きます — バイトが減り、かつ計算が2倍。INT4のweight-only量子化(AWQ、GPTQ)は重みを4ビットで格納しますが乗算時に16ビットへ逆量子化します: 純粋な帯域の節約であり、メモリ律速のデコード領域に理想的で、計算律速のプリフィルには効きません。BlackwellのFP4テンソルコアは4ビットを一級の計算フォーマットにします — OpenAIのgpt-ossがMXFP4重みでネイティブに出荷されたのは、オープンウェイトのサービングのデフォルトがどこへ向かうかのシグナルです。KVキャッシュも量子化できます(FP8 KVは日常的で、上の台帳のトークンあたりサイズを半分にします)。これは、KVが帯域予算を支配する長コンテキスト領域でこそ効きます。
モデルサービングの支配的なルールがここでは一層強く当てはまります: パープレキシティは量子化のダメージを隠します。4ビットモデルはBF16とパープレキシティで並びながら、GSM8Kやコード生成スイートで数ポイント落ちることがあります。損失は、まさにそれらのタスクが行使する狭い分布に集中するからです。量子化のロールアウトは自分のタスク評価でゲートし、あらゆるモデル変更と同様にA/Bテストすること(LLM評価)。
並列化: TP、PP、EP
モデルが1枚のGPUを超えたら — 容量においてであれ、必要な上限においてであれ — 分割します。3つの軸は通信プロファイルが鋭く異なります:
テンソル並列(TP) はすべての重み行列をGPU間でスライスし、各層の最後に部分結果を結合するall-reduceを行います。層ごとに2回のall-reduceが毎トークン発生するため、TPは高帯域ドメインの内側でしか成立しません — 900 GB/sのNVLinkであって、PCIeやEthernetではありません。H100/H200クラスのシステムではNVSwitchドメインは8 GPUであり、「TP=8」が標準の最大幅構成である理由です。ラックスケールのNVL72システム(1つのNVLinkドメインに72枚のBlackwell GPU)は境界を緩めますが、原則は変わりません: TPはNVLinkドメインの縁で止まる。見返りとして、TPは帯域問題も分割します — 8枚のGPUがそれぞれ重みの8分の1をストリーミングし、シングルストリーム上限をほぼ8倍にします。
パイプライン並列(PP) は連続する層ブロックを別々のGPUに割り当てます。境界を越えるのはアクティベーション(ギガバイトではなくメガバイト)だけなので、PPは通常のインターコネクトに耐え、ノードをまたげます。コストはパイプラインバブル — 互いを待つ間のステージの遊休 — で、デコードの1トークンずつのリズムはこれを埋めにくくします。典型的な大規模デプロイは両方を組み合わせます: 各ノード内でTP=8、ノード間でPP。
エキスパート並列(EP) はMoE固有の軸です: エキスパートをGPU群に分散し、トークンを担当エキスパートのホストへルーティングします。DeepSeek-V3/R1が参照設計です — 総パラメータ671Bだがトークンあたりアクティブは約37B(共有1 + 256中8のルーテッドエキスパート):
Dense 671B, FP8, hypothetical: 671 GB per token per step → ~5 tok/s ceiling on H100 BW
MoE 671B/37B active: ~37 GB of expert+shared weights per token
→ the ceiling of a 37B model, with 671B of capacity落とし穴: どの37 GBかはトークンごとに異なります。小バッチでは各GPUはフルのエキスパートシャードを保持しながら少数のトークンにしか仕えません — 償却なき容量コスト。大バッチではすべてのエキスパートにトラフィックが流れ、all-to-allのディスパッチ/結合通信が支配的コストになります。MoEの経済はスケールでしか成立せず、だからワイドEPデプロイ(DeepSeek自身のサービングは数十GPUのプリフィルグループで走ります)とエキスパート負荷分散(学習時の補助損失、サービング時のホットエキスパートの冗長配置)はアーキテクチャと不可分なのです。
分離: プリフィルとデコードを切り離す
プリフィルとデコードは同居させると争います: 長いプリフィルはバッチ内のすべてのデコードを停滞させ(トークン間レイテンシのスパイク)、デコードのメモリ律速ステップはプリフィルが使えたはずの計算を浪費します。チャンクドプリフィルは干渉を和らげ、分離型サービングはそれを除去します — プリフィルとデコードに別々のGPUプールを割り当て、プロンプトのKVキャッシュを一方から他方へ輸送します(DistServeがグッドプットの論拠を示し、MooncakeがKimiのためにスケール運用し、NVIDIA Dynamoが製品化し、vLLMとSGLangの両方がサポートします)。
KV転送がエンジニアリングの核心です: 長いプロンプトあたり数十GBを、NVLinkまたはRDMA越しに移動し(DynamoのトランスポートレイヤーがNIXL、vLLMで同じ役割を担うのがLMCache)、レイヤーごとのストリーミングの背後に隠して転送完了前にデコードを開始させます。この勝ちは階層型KVキャッシング — ホットなプレフィックスはHBM、その後ろにDRAMとSSD — と複利します。マルチターンで共有されるシステムプロンプトや、セッションをまたいで再照会される長い文書は、二度とやり直さなくてよいプリフィルだからです。Mooncakeは本番トークンの過半数が再計算ではなくキャッシュから供給されると報告しています。
分離はヘテロジニアスなフリートも解放します: プリフィルは計算を欲し(Blackwell)、デコードは帯域と容量を欲します(H200は構造からしてデコードマシンです)。トラフィックのプリフィル:デコード比に対して2つのプールを独立にサイジングするのは、MLキャパシティ・コスト計画そのもののキャパシティプランニング演習です。これらのプラットフォームのオペレーター視点はLLM推論プラットフォームのケーススタディにあります。
制約付きデコーディングは(ほぼ)無料
構造化出力 — JSONスキーマ、ツール呼び出しの文法 — は、各デコードステップで無効なトークンをマスクすることで強制されます。素朴なコストモデルは「毎トークン128Kの語彙を文法と照合するのは遅いはずだ」と言いますが、実際のシステムはこれをほぼ無料にします。xgrammar(vLLMとSGLangが使用)は文法を事前にプッシュダウンオートマトンへコンパイルし、文脈非依存のトークンマスクを事前計算し、残りのマスク計算をGPUのフォワードパスと重ねます — ロジットが出る前にマスクは準備できています。SGLangのジャンプフォワードデコーディングはさらに進みます: 文法が唯一の継続しか許さないとき(JSONスキーマの固定キーや句読点)、モデルを一切走らせずにそれらのトークンを追記し、構造を税ではなく高速化に変えます。残余のコストケースは、大きな動的生成スキーマ(コンパイルを償却できない)と高度に曖昧な文法(マスクが文脈依存のまま)です。構造化出力のレイテンシが痛いなら、最適化すべきは通常GPUではなくスキーマです。
計測: ルーフラインに対応するメトリクス
各サービングメトリクスはハードウェアのレジームに対応しており、それこそが飾りではなく診断になる理由です:
- TTFT(最初のトークンまでの時間) — プリフィルのレイテンシ: 計算律速、プロンプト長に比例、FLOPs増強・チャンク方針・プレフィックスキャッシュヒットで改善。
- TPOT / ITL(出力トークンあたり時間 / トークン間レイテンシ) — デコード: 帯域律速、バッチサイズと長コンテキストで劣化、量子化・TP幅・投機で改善。
- スループット(GPUあたりtok/s) — 償却のメトリクス。購入時のレイテンシを添えなければ無意味。
- グッドプット — SLO内のスループット。キャパシティプランに載せてよい唯一の数字。
ワークロードの実際の形でベンチマークすること: vllm bench serve とNVIDIAのgenai-perfはどちらもプロンプト/出力長の分布を再生し、パーセンタイルのTTFT/ITLを測ります。MLPerf Inferenceがベンダー横断の参照点を提供します。古典的な落とし穴はすべて分布の不一致です — 固定長の合成プロンプト(チャンクドプリフィルの干渉とKV圧力を隠す)、プレフィックスキャッシュヒット率の無視(本番の50%超のヒット率はTTFTを一変させる)、p99ではなく平均ITLの報告(ユーザーが実際に気づくのはストールの方)。パーセンタイルの規律と負荷試験の方法論は、あらゆるレイテンシ敏感なサービスと同じです(キャパシティプランニング)。
失敗モード
KV圧力のカスケード。 メモリがキャッシュ済みシーケンスで埋まる → スケジューラが1本をプリエンプトしKVを追い出す → そのシーケンスが後でフル再プリフィルで再開する → それが計算負荷を増やし別の誰かを追い出す。症状: 「収まるはずの」負荷でスループットが崩壊しTTFTがスパイクする。プリエンプション/エビクションのカウンタを監視し、最大並行シーケンス数をOOMラインの下に制限し、GPUを買う前にKVを量子化すること。
遅いインターコネクトをまたぐTP。 PCIe越しやノード間のテンソル並列は、層ごとの2回のall-reduceをボトルネックに変えます。デプロイは期待スループットの数分の1で「動いて」しまいます。TPはNVLinkドメインの内側、PPはその外側 — 実測のall-reduceレイテンシが、自分が線のどちら側にいるかを教えてくれます。
量子化の評価ギャップ。 INT4モデルがパープレキシティで並び、スモークテストを通り、出荷される — そして1週間後、数学やコードの多いトラフィックが、どのサービングメトリクスも捉えなかったリグレッションを示す。品質ゲートはタスク評価でなければならず、モデルファミリー単位ではなく量子化アーティファクト単位で実行すること。
SLOを越えたスループットチューニング。 ベンチマークは、p99トークン間SLOが禁じるバッチサイズとチャンクサイズに報酬を与えます。レイテンシパーセンタイルを添えずに引用されるtok/sの数字は、設計レビューにおける危険信号です。
長コンテキストの不意打ち。 ある機能が平均コンテキストを4Kから64Kへ引き上げる。トークンあたりKVトラフィックは16倍になり、デコード上限が下がり、4K向けにサイジングされたフリートが飽和する。コンテキスト長の分布は、QPSと同格の一級のキャパシティ入力です。
ストラグラーエキスパート。 MoEサービングでは、ホットなエキスパート(またはそれをホストする遅いGPU)がall-to-all内のすべてのトークンを堰き止め、p99レイテンシがフリート全体で劣化します。エキスパートごとの負荷メトリクスと、ホットエキスパートの冗長配置が必要です。
意思決定フレームワーク
| 状況 | 手を伸ばすもの |
|---|---|
| シングルストリームのレイテンシが最重要(対話型エージェント) | FP8/INT4重み、NVLinkドメインまでのTP、投機的デコーディング |
| スループット/コストが最重要(バッチ、評価、バックフィル) | 大バッチの連続バッチング、バッチAPI、MoEモデル |
| 長コンテキストが支配的 | GQA/MLAモデル、FP8 KV、プレフィックスキャッシング、H200クラスの帯域 |
| モデルがGPU 1枚に収まる | TPなし — 不要な並列化は純粋なオーバーヘッド |
| モデル > 1 GPU、≤ 1ノード | NVLink内のTP |
| モデル > 1ノード | TP=8 + ノード間PP。MoEならEP |
| 大規模でのプリフィル/デコード干渉 | まずチャンクドプリフィル。フリートが分割に足る規模になったら分離 |
| 計算を買うか帯域を買うかの判断 | プリフィル過多 → 計算(B200)。デコード過多 → 帯域/容量(H200) |
重要なポイント
- デコードはメモリ律速、プリフィルは計算律速。 この一文が推論エンジニアリングの大半を説明します。ベンチマークを信じる前に、マシンバランスとトークンあたりバイト数を計算すること。
- シングルストリームの上限は
帯域 ÷ トークンあたりバイト数。 H100 1枚のFP8-70Bで約48 tok/s — 他のすべては、そこに近づくか、それを償却して越えるかの話です。 - バッチング、投機、量子化は同じ一手 — HBMトラフィック1バイトあたりの有効仕事量を増やす — を、並行性、単一ストリーム、バイトそのものに適用したものです。
- KVキャッシュは容量問題である以上に帯域問題。 長いコンテキストはトークン/秒の上限を下げます。GQA/MLAとFP8 KVはスループットの機能です。
- 並列化はインターコネクトに従う: NVLink内はTP、ノード間はPP、MoEはEP — そしてMoEはバッチスケールでしか儲かりません。
- グッドプットが目的関数。 まずレイテンシSLOを決め、その内側でスループットを最大化する。報告はパーセンタイルで、平均では決してしない。
- 量子化は積極的に、ゲートはタスク評価で。 INT4が何を壊したか、パープレキシティは教えてくれません。
参考文献
- Williams, Waterman & Patterson — Roofline: An Insightful Visual Performance Model (2009)
- Dao et al. — FlashAttention (2022), FlashAttention-2 (2023); Shah et al. — FlashAttention-3 (2024)
- Kwon et al. — Efficient Memory Management for LLM Serving with PagedAttention (vLLM, 2023)
- Zhong et al. — DistServe: Disaggregating Prefill and Decoding (2024)
- Qin et al. — Mooncake: A KVCache-centric Disaggregated Architecture (2024)
- DeepSeek-AI — DeepSeek-V3 Technical Report (2024)
- Leviathan et al. — Fast Inference via Speculative Decoding (2023)
- Dong et al. — XGrammar: Flexible and Efficient Structured Generation (2024)
- NVIDIA H100/H200/B200 データシート; NVIDIA Dynamo アーキテクチャドキュメント
- MLPerf Inference 結果 (mlcommons.org); vLLM、SGLang、TensorRT-LLM ドキュメント
- Attentionとトランスフォーマー — この章が仕えるアーキテクチャ