細分化されたプレフィルおよびデコード サービング
大規模な言語モデルの推論を 2 つの異なるフェーズ (プリフィルとデコード) に分割し、それらを GPU の異なるプールで実行するサービング アーキテクチャ。
概要
これら 2 つのフェーズではハードウェアの要求が相反するため、これらのフェーズを同じマシンに強制すると容量が無駄になり、遅延が発生するため、これが重要です。
ディープダイブ
LLM が応答すると、2 段階で動作します。プレフィルはプロンプト全体を一度に読み取り、キー/値 (KV) キャッシュを構築します。これは、GPU の演算ユニットを飽和させる、大規模な並列計算処理のバーストです。次に、デコードは一度に 1 つずつトークンを生成し、各ステップで KV キャッシュ全体を読み取ります。つまり、メモリ帯域幅に制限があり、計算量が少ないトリクルです。一緒に実行すると、長いプリフィルによって全員のデコードが停止し (行頭ブロック)、2 つをバッチ処理すると干渉が発生します。分散により、ある GPU プールにプリフィルが配置され、別の GPU プールにデコードが配置され、NVLink や InfiniBand などの高速インターコネクトを介してそれらの間で KV キャッシュが転送されます。各プールは個別に調整およびスケーリングされるため、グッドプットが向上し、テール レイテンシーが平滑化され、オペレーターは最初のトークンまでの時間と出力トークンごとの時間という厳しい目標を同時に達成できるようになります。
技術的な洞察
2 つのフェーズはボトルネックが異なります。 Prefill はすべてのプロンプト トークンを並行して処理するため、その FLOP はプロンプトの長さに応じて拡張され、テンソル コアが最大になります。デコードは自己回帰です。各新しいトークンには、HBM から完全な KV キャッシュを再読み取る 1 つのフォワード パスが必要です。そのため、スループットはコンピューティングではなくメモリ帯域幅によって制限されます。分解は、サイジング、バッチ処理、さらにはプールごとに異なる並列処理を選択することでこれを利用し、KV キャッシュをプレフィル ワーカーからデコード ワーカーに送信します。
戦略的影響
費用と予算
アーキテクチャの決定により、パフォーマンスと運用コストが何年にもわたって推進されます。
より明確な判決
技術教育は、チームが最新のスタックだけでなく、適切なスタックを選択するのに役立ちます。
品質管理
より良いエンジニアリングの選択により、本番環境での信頼性に関するインシデントが減少します。
細分化されたプレフィルおよびデコード サービスの将来
非集計が運用スタックのデフォルトになることが予想されます。 DistServe、Splitwise、Mooncake などのシステムによってこれが普及し、vLLM と NVIDIA Dynamo が分離モードを出荷するようになりました。研究では、KV キャッシュ転送の最適化、リクエスト全体でのキャッシュ プーリングと再利用、トラフィックの変化に伴うプレフィル/デコード率の動的な再バランス、プレフィックス キャッシュとチャンク プレフィルとの緊密な統合が推進されています。コンテキスト ウィンドウが数百万のトークンに成長するにつれて、コスト効率の高い低遅延のサービスを提供するには、これらのフェーズを分離することがますます重要になります。
現実世界の実装
チャット アシスタントは、長いドキュメント プロンプトを計算負荷の高いプレフィル クラスターにルーティングし、メモリ最適化されたデコード クラスターから返信をストリーミングして入力遅延をスムーズに保ちます。
NVIDIA Dynamo と vLLM を使用すると、オペレータは個別のプレフィル ワーカー グループとデコード ワーカー グループをデプロイできるため、長いプロンプトのバーストによって進行中の世代がフリーズすることはありません。
Mooncake (Moonshot AI の Kim によって使用) は、プリフィルとデコードを分離し、分散 KV キャッシュ プールを追加して、冗長なプロンプト再計算を大規模に削減します。
コード補完サービスは、ほとんどのコストが多数の出力トークンのストリーミングから発生するため、短いプロンプト用の小さなプレフィル プールと大きなデコード プールを専用にします。
リスクとガードレール
1 つのベンチマークを最適化すると、より広範なシステムの弱点が隠れる可能性があります。
インフラストラクチャとメンテナンスのコストは過小評価されがちです。
システムが複雑になるにつれて、セキュリティと可観測性のギャップが拡大する可能性があります。
実装ロードマップ
実装前にレイテンシ、品質、コストの目標を定義します。
現実的な負荷とデータ条件でのベンチマーク。
エラー、ドリフト、ユーザーへの影響を計測器で監視します。
スケーリングの前に、ロールバックとインシデント対応のパスを準備します。
探検を続けましょう
Free newsletter
Get the daily AI briefing
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Take the Disaggregated Prefill and Decode Serving quiz
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
次のガイド
Kubernetes での KServe とモデルの提供
よくある質問
細分化されたプレフィルおよびデコード サービングとは何ですか?
大規模な言語モデルの推論を 2 つの異なるフェーズ (プリフィルとデコード) に分割し、それらを GPU の異なるプールで実行するサービング アーキテクチャ。これら 2 つのフェーズではハードウェアの要求が相反するため、これらのフェーズを同じマシンに強制すると容量が無駄になり、遅延が発生するため、これが重要です。
プリフィルとデコードを異なる GPU プールに分離する主なハードウェアの理由は何ですか?
プリフィルはプロンプト全体を並列処理してコンピューティングを飽和させますが、デコードはステップごとに KV キャッシュを読み取り、メモリ帯域幅によって制限されます。これは、個別に個別に調整されたプールを正当化する反対の欲求です。
プレフィル ワーカーからデコード ワーカーに転送する必要があるデータ構造は何ですか?
Prefill はプロンプトの KV キャッシュを構築します。デコードでは生成を続けるためにそのキャッシュが必要であるため、キャッシュは高速インターコネクトを介してデコード プールに送信されます。
共有 GPU セットアップにおいて、分散によって具体的に軽減される問題はどれですか?
共有 GPU では、長いプリフィル バーストによって進行中のデコード ステップがブロックされる可能性があります。それらを分離すると、その干渉が防止され、テールのレイテンシーが安定します。
プリフィルは積極的にバッチ処理できるのに、異なるチューニングによるメリットをデコードできるのはなぜですか?
Prefill はすべてのプロンプト トークンをまとめて処理するため、より大きなバッチがテンソル コアに適切に供給されます。 decode は一度に 1 つのトークンを生成し、メモリによってゲートされるため、スケールが異なります。
非集約プール間で KV キャッシュを移動するために通常どのインターコネクトが使用されますか?
KV キャッシュ転送が新たなボトルネックにならないように、NVLink (ノード内) や InfiniBand (ノード間) などの高帯域幅で低遅延のリンクが必要です。