LLM 推論の Prefill と Decode
LLM 推論は Prefill と Decode の二つの段階に分かれ、それぞれ計算特性がまったく異なる。この違いを理解することが、すべての推論最適化技術を理解する出発点だ。
LLM 推論は一回きりの処理ではない。プロンプトを入力してからモデルが最後のトークンを出力するまで、本質的に異なる二つの段階を経る。Prefill と Decode だ。この両者の違いをはっきりさせることこそ、すべての推論最適化技術を理解する出発点だ。
Prefill(事前充填)は入力を処理する段階だ。モデルがプロンプト全体を受け取り、すべてのトークンの計算を一度に完了する。この段階は並列的で、すべてのトークンが同時に行列積に参加し、GPU の計算力が十分に活用される。例えるなら、引っ越し業者がトラック一台分の人員を派遣し、すべての箱を同時に運ぶようなものだ。効率は最大化される。
入力 Prompt → GPU が全トークンを並列計算 → KV Cache → 出力
Decode(デコード)は出力を生成する段階だ。モデルはトークンを一つずつ生成し、毎回一つだけを産み出す。この段階は直列的で、新しいトークンは毎回前のトークンの出力に依存する。さらに重要なのは、毎回の計算量が非常に小さく、ボトルネックは計算ではなくメモリ帯域幅にあることだ。GPU は大部分の時間、データが VRAM から計算ユニットへ移動するのを待っている。
Step 1: 全 KV Cache を読み取り → 計算 → token_1 を生成
Step 2: 全 KV Cache を読み取り → 計算 → token_2 を生成
Step 3: 全 KV Cache を読み取り → 計算 → token_3 を生成
↑_____________________________________↑
毎ステップ読み取りが必要、メモリ帯域幅がボトルネック
この二つの段階の性能特性は大きく異なる。Prefill は計算律速(compute-bound)で、GPU の計算力が強いほど速い。Decode はメモリ帯域律速(memory-bound)で、VRAM の帯域幅が決定的な要因だ。
具体的な数字で説明する。7B FP16 モデルの場合、重みだけで約 14GB の VRAM を占める。毎回の Decode ステップでこの 14GB を VRAM から計算ユニットへ移動させる必要がある。A100 の HBM 帯域幅は 2 TB/s で、理論上の限界は 14GB ÷ 2TB/s = 7ms/token、つまり約 140 tok/s だ。これが Decode 段階のハードリミットで、計算力とは無関係に、純粋にメモリ帯域幅で決まる。
まさに Decode 段階のこのハードリミットが、各種の最適化技術を生み出した。
この違いを理解すると何の役に立つか。それは「キー・バリューキャッシュ(KV Cache)」が必要な理由を直接説明する。Decode 段階で前のトークンの中間結果を再計算するのを避けるためだ。「ページドアテンション(PagedAttention)」が解決する問題も説明できる。KV Cache の VRAM における断片化管理の問題だ。「プレフィックスキャッシング(Prefix Caching)」の価値も説明できる。複数のリクエストが同じシステムプロンプトを共有する特性を利用し、Prefill 段階の重複計算を減らす。
ある推論フレームワークが性能を最適化したと謳うとき、最初に問うべきはこれだ。最適化したのは Prefill か Decode か。計算量を減らしたのか、メモリ帯域幅の利用率を高めたのか。これをはっきりさせれば、その最適化が本当に意味があるか判断できる。
MN-Core L シリーズチップの 3D stacked DRAM 設計は、本質的に Decode 段階のメモリ帯域幅ボトルネックを解決するものだ。計算力がボトルネックでなくなれば、メモリ帯域幅が推論速度を制約する鍵になる。Preferred Networks が LLM Serving Engine Engineer を専属で採用する理由もここにある。ハードウェアはソフトウェアレイヤーとの深い連携があって初めて全潜力を発揮する。
推論ボトルネックの診断方法
概念を理解したら、次は実践に応用する。以下の手順で推論サービスのボトルネックがどこにあるか判断できる。
1. GPU 利用率とメモリ帯域幅の監視
# NVIDIA GPU 監視
nvidia-smi dmon -s u -d 1 # GPU 利用率
nvidia-smi dmon -s p -d 1 # メモリ帯域幅
2. リクエスト特性の分析
- 入力プロンプトが長い(>1k トークン)→ Prefill ボトルネックの可能性大
- 出力が長い(>500 トークン)→ Decode ボトルネックの可能性大
- 大量の短いリクエスト → 連続バッチ処理(continuous batching)の検討が必要
3. 最適化戦略の選択
- Prefill ボトルネック:より強力な GPU、レイヤー数の削減、量子化圧縮
- Decode ボトルネック:より高いメモリ帯域幅、KV Cache 最適化、Prefix Caching
次回は「キー・バリューキャッシュ(KV Cache)」について書く。LLM 推論において最も重要でありながら最も見落とされやすい仕組みだ。
参考文献:
- Inside LLM Inference: KV Cache, Prefill, and the Decode Bottleneck - Towards AI
- The Two Phases of LLM Inference: Prefill and Decode - Scaling Thoughts
- PagedAttention: Solving LLM KV Cache Memory Fragmentation - Michael Brenndoerfer
- Prefix Caching - SGLang - SGLang Documentation
- PFN Begins Development of Generative AI Processor MN-Core L1000 - Preferred Networks
更新履歴
- 公開