Prefill-Decodeの分離とは何か、そしてLLMサービングをどう変えるのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Is Prefill-Decode Disaggregation, and Why Does It Change LLM Serving?

Prefillとdecodeの分離により、プロンプト処理とトークン生成を分け、それぞれのLLMフェーズで異なるワーカー、スケジュール、容量計画を利用できるようになります。

長いRAGプロンプトでは、最初のトークンを生成する前に大量の計算処理が一気に必要になります。一方、decodeではその後、多数の小規模でメモリ帯域幅に依存する反復処理を実行します。両方のフェーズを1つのGPUで実行する方法はシンプルですが、長いprefillによって進行中の会話が中断される可能性があります。分離構成では、リクエストとそのKV状態をプール間で移動させます。これにより、追加の調整や転送コストと引き換えに、初回トークンおよびトークンごとのレイテンシーを個別に制御できます。

PrefillとDecodeではリソースの特性が異なる

Prefillでは、すべてのプロンプトトークンを並列処理してKVキャッシュを構築します。そのため、プロンプトが長くなるほど処理時間が増加する、計算負荷の高いバースト処理になります。Decodeでは、モデルの重みと蓄積されたKV状態を繰り返し読み取り、1回の反復で1つ、または少数の新しいトークンを生成します。

DistServeは、両方のフェーズが同じGPUを共有する際に発生するprefillとdecodeの干渉を特定し、prefillを初回トークン生成までの時間に、decodeを出力トークンごとの時間に関連付けています。これらを分離することで、スケジューラーは各目標を個別に保護できます。この違いは、後の家庭環境でのテストでも確認できます。

分離構成は、通常のモデル並列化とは異なります。同じモデルが両方のプールに存在する場合でも、リクエストは1回のフォワードパス内のレイヤー間ではなく、機能フェーズ間を移動します。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

KV転送が2つのワーカープールを接続する

Prefillの後、システムはリクエストのKVキャッシュをdecodeワーカーから利用できるようにする必要があります。テンソルをPCIeまたはネットワークファブリック経由で転送したり、共有メモリを使用したり、移動コストを最小限に抑えられるようにワーカーを配置したりできます。

Splitwiseは、フェーズごとのマシンとスケジューリングを用いたフェーズ特化型サービングを研究し、ハードウェア割り当てがプロンプト処理とトークン処理の異なる計算特性に適合する理由を示しています。キューイングと状態の移動は、サービング経路の一部になります。この境界は、現実的な運用条件下で個別に測定する必要があります。

Decodeプールは、一貫したKV状態とリクエストメタデータを受け取るまで開始できません。コンテキストが大きくなると転送データ量が増えるため、小規模なホームネットワークでは、名目上は高速なフェーズ分離構成でも、同一場所での実行に負ける可能性があります。

独立したスケーリングが容量計画を変える

プールを分離すれば、長文書のバーストに対応するprefill容量を、decode容量を同じ割合で拡張することなく増やせます。また、バックグラウンドの要約処理がプロンプトワーカーを使用している間も、音声のdecode処理を保護できます。アドミッション制御では、2つのキューと2つのレイテンシー予算を対象にできます。複数のソースが限られたコンテキストを奪い合う状況では、この実際の効果が現れます。

Mooncakeは、KVキャッシュの移動と保存をサービング上の第一級の関心事として扱うKVキャッシュ調整について説明しています。このアーキテクチャは、分離構成によってボトルネックがGPUスケジューリングだけの問題から、状態転送とキャッシュ調整の問題へ移ることを示しています。

障害の境界となるのは、スケールまたは帯域幅が不十分な場合です。家庭用GPUが1台または2台しかない場合、特化用の余剰デバイスがないことがあります。また、モデルの重みの複製とKV転送によって、解消したい干渉以上にメモリとレイテンシーを消費する可能性もあります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

同一配置と分離配置のフェーズ予算を比較する

短いプロンプト、長いプロンプト、混在したプロンプトについて、プロンプトの1秒あたり処理トークン数、初回トークン生成までの時間、出力トークンごとの時間、転送したKVデータ量、転送時間、キュー待ち時間、モデルメモリの重複、消費電力、障害復旧を測定します。この依存関係は、最終インターフェースでも明示したままにする必要があります。

同一配置の代替手段としてチャンク化Prefillを使用します。2つ目のプールを追加する前にチャンク化Prefillをテストし、両方のアーキテクチャで同一の到着トレースを比較します。したがって、結果は元の証拠と照合する必要があります。

フェーズ間の干渉が測定され、転送経路によって両方のレイテンシー目標が維持される場合にのみ、分離構成を採用します。小規模なサーバーでは、prefillチャンクに上限を設けた同一配置のスケジューリングにより、状態移動を減らしながら同じユーザー体験を実現できる可能性があります。