PD Disaggregation
何を分けるのか
PD disaggregationは、LLM推論のprefillとdecodeを別々のworker poolに分ける構成です。
SGLangの説明では、従来の統合engineではprefill batchとdecode batchが同じengineで処理され、decode遅延やDP attentionの不均衡が起きると説明されています。
Dynamoのdesign docでは、disaggregated executionを次の3段階として説明しています。
- prefill engineがprefillを計算し、KV cacheを生成する。
- prefill engineがKV cacheをdecode engineへ転送する。
- decode engineがdecodeを実行する。
なぜ速くなる可能性があるのか
prefillとdecodeは得意なGPU配置・並列化が違います。
| 段階 | 重いもの | 向きやすい最適化 |
|---|---|---|
| prefill | 長い入力列の一括計算 | 大きめbatch、計算資源、chunked prefill |
| decode | KV cache読み書き、1 tokenずつの生成 | 高concurrency、KV cache効率、メモリ帯域 |
この2つを同じworkerで雑に混ぜると、長いprefillがdecodeを邪魔し、ユーザーから見たtoken生成が遅くなることがあります。
RDMAとKV転送
Dynamoのdisaggregated servingドキュメントでは、KV cacheをprefill側GPU memoryからdecode側GPU memoryへ転送するため、RDMAが重要だと説明されています。Dynamo docsでは、RDMAなしではKV cache transferが大きなボトルネックになり得るとも説明されています。
大会環境でInfiniBand、RoCE、UCX、NIXL、Mooncakeなどが使えるかは、必ず確認します。
SGLangとDynamoの関係
DynamoのSGLang backend docsでは、SGLang単体のdisaggregationとDynamo統合時の流れが少し違うと説明されています。
大まかには次の理解でよいです。
| 構成 | 役割 |
|---|---|
| SGLang単体 | SGLang router/load balancerがprefill/decodeを扱う |
| Dynamo + SGLang | Dynamoのdiscoveryやrouterがworker選択やrequest flowを管理し、SGLang側のbootstrapを使ってKV転送する |
最初に見るメトリクス
PD disaggregationの評価では、総throughputだけでは不十分です。
| メトリクス | 意味 |
|---|---|
| TTFT | requestを送ってから最初のtokenが出るまでの時間 |
| TPOT / ITL | 出力token間の平均時間 |
| Output tokens/s | 全体で何token/s出るか |
| Requests/s | requestを何件/s処理できるか |
| p95 latency | 遅いrequestを含めた体感の悪さ |
| GPU memory usage | KV cacheや重みでどれだけVRAMを使うか |
| KV transfer time | prefillからdecodeへのKV cache転送時間 |
注意点
- PD disaggregationは常に速いとは限らない。短いprompt中心なら転送コストが勝つ可能性がある。
- RDMAが弱い環境では、KV transferがボトルネックになる。
- prefill/decode worker数の比率を間違えると、片方が詰まる。
- 競技評価が総throughputだけの場合、実サービスらしいlatency最適化と衝突する可能性がある。