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. リクエスト特性の分析

3. 最適化戦略の選択

次回は「キー・バリューキャッシュ(KV Cache)」について書く。LLM 推論において最も重要でありながら最も見落とされやすい仕組みだ。


参考文献:

更新履歴

  • 公開