# さくらの高火力 PHYを利用した分散推論基盤の性能検証 〜高火力 PHYで作る分散推論基盤 vol.3〜 [[道下幹也]]（[[SAKURA Internet]]）著の連載「高火力 PHYで作る分散推論基盤」第 3 回。Prefill-Decode Disaggregation（PD Disaggregation）の効力を、[[高火力 PHY]] 環境（H100 HGX）の実測データで詳細に検証した報告である。 --- ## 課題設定 第 1 回（[[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]）で「PD Disaggregation は状況によってはコストがかかるソリューションであり、SLO/SLA の厳密定義がない環境や小規模環境ではメリットが限定的である可能性がある」と指摘されていた。本回ではその問いを具体的な 2 軸で検証する。 1. **小規模環境での効果** — 限定的な GPU リソース（4 枚程度）を持つ環境でもメリットが得られるか。 2. **ワークロード依存性** — Prefill 処理が重い環境と軽い環境で、効果はどの程度変わるか。 --- ## ソフトウェアスタック 検証に用いたソフトウェアスタックは以下の 4 層で構成される。 - **[[UCX]]** — 高性能通信基盤。GPU 間の低レイテンシ転送を担う。 - **[[NIXL]]** — P2P データ転送レイヤー。UCX の上位に位置し GPU 間ダイレクト転送を抽象化する。 - **[[vLLM]]** — LLM サービングエンジン。Prefill/Decode の推論処理を実行する。 - **[[LMCache]]** — KV キャッシュ管理・転送ソフトウェア。NIXL を利用した P2P データ転送機能で PD Disaggregation を実現する。 --- ## LMCache のプロキシサーバー処理フロー [[LMCache]] は [[NIXL]] 経由で Prefill インスタンスと Decode インスタンス間にデータ転送チャネルを確立し、メタデータ交換に ZMQ を利用する。プロキシサーバー `disagg_proxy_server.py` がユーザーリクエストのルーティングを担い、9 段階のフローで処理が進む。 1. プロキシサーバーがユーザーから推論リクエストを受け取る。 2. リクエスト内容を一部書き換え（`max_tokens = 1` に上書き、Decoder 接続情報を埋め込む）て Prefiller に転送する。 3. Prefiller は「1 トークン生成」の推論リクエストとして受け取り処理を開始する。 4. Prefiller が推論処理で KV キャッシュを作成し、1 トークンを生成してプロキシサーバーへ返却する。 5. Prefiller は NIXL 経由で KV キャッシュを Decoder に転送する。 6. プロキシサーバーは KV キャッシュ転送完了を待機する。 7. 転送完了後、プロキシサーバーは Decoder 向けリクエストを実行する。 8. Decoder がトークン生成を継続し、プロキシサーバーへ返却する。 9. プロキシサーバーは Decoder からの返却内容をそのままユーザーへ返却する。 この設計により、Prefill の計算バウンド処理と Decode のメモリバウンド処理を物理的に分離できる。 --- ## ベンチマークツールの選定 3 種類のツールを評価し、採用を判断した。 | ツール | 評価 | |--------|------| | GenAI-perf | 現在は新機能開発停止、後継として AIPerfが開発中 | | vllm bench serve | 直感的かつ簡便。調整可能パラメータと取得可能データで十分カバー。[[vLLM]] 同梱で広く利用される | | inference-benchmarker | 候補の一つだが最終的に非採用 | **採用**: vllm bench serve。[[vLLM]] エコシステムとの統一性と操作の簡便さが決め手となった。 --- ## ベンチマークパラメータ設計 | パラメータ | 値 | 説明 | |-----------|-----|------| | `--dataset-name` | random | リクエスト入力内容データセット | | `--random-input-len` | 1k / 8k | ワークロード毎の入力長 | | `--random-output-len` | 1k | ワークロード毎の出力長 | | `--request-rate` | inf | リクエスト送信レート（制限なし） | | `--max-concurrency` | 1, 2, 4, 8, 16, 32 | 最大同時接続数 | | `--num-prompts` | max-concurrency × 10 | 処理プロンプト数 | > [!note] 本ベンチマーク設計は現実のユーザーワークロードの模擬よりも**負荷試験的性格が強い**。入力長を固定し最大スループットに近い条件で測定しているため、散発的リクエストが中心の実際の運用環境とは乖離がある点に留意が必要。 --- ## 検証環境 - **採用モデル**: gpt-oss-120b（量子化なし） - **ハードウェア**: [[高火力 PHY]] が提供する HGX H100 サーバー（H100 GPU × 8） - **Aggregated 構成**: GPU 4 枚（Tensor Parallelism 4 または TP8） - **PD Disaggregation 構成**: Prefill 用 GPU 2 枚 + Decode 用 GPU 2 枚（合計 4 枚） Aggregated 構成と PD Disaggregation 構成を GPU 合計枚数を揃えた条件で比較することで、同一リソース量における性能特性の差異を測定している。 --- ## 検証結果と考察 ### 入力長 8k・出力長 1k の場合 **Aggregated 構成**では、同時接続数の増加に伴い ITL（Inter-Token Latency）の Tail Latency が急激に悪化する。16 並列以上では P99 を 100ms 以内に抑えることが困難となり、HoL（Head-of-Line）ブロッキング状態が発生する。高負荷下で Prefill と Decode が同一 GPU を共有するため、長い入力を処理する Prefill がブロックとなりトークン生成間隔を阻害する。 **PD Disaggregation 構成**では、影響はあるものの抑制傾向が明確に見られる。32 並列でも P99 を 30ms 以内に抑止できる。Prefill と Decode を独立したインスタンスに分離することで HoL ブロッキングを根本的に回避するためである。 **GPU 枚数増加の効果**： - TTFT（Time To First Token）: GPU リソース追加が性能を大きく改善する。Prefill は計算バウンドであり、GPU 数増加がそのままスループット向上に繋がる。 - ITL: GPU 間の計算結果同期に伴う通信コストにより性能が悪化傾向を示す。Decode はメモリバウンドであるため、GPU を追加するほど通信オーバーヘッドが相対的に増大する。 ### 入力長 1k・出力長 1k の場合 多くのケースで Aggregated 構成の方が同等以上の性能を示す。32 並列でスループットが伸びると P99.5 付近で性能が逆転し始めるが効果は限定的である。 入力長が短い場合は Prefill の計算量が少なく HoL ブロッキングが発生しにくいため、PD Disaggregation の分離コスト（NIXL 経由の KV キャッシュ転送）が相対的に不利に働く局面が生じる。散発的リクエストが想定される現実的なワークロードでは、PD Disaggregation のメリットはさらに限定的と考えられる。 --- ## 結論 本検証から得られた主要な知見を 3 点にまとめる。 1. **Tail Latency は SLO/SLA の要**：[[サービスレベル目標]]（SLO）・SLA の指標として利用されやすい ITL Tail Latency は、Aggregated 構成では強い負荷下でリソースを単純に追加しても改善が困難になる。GPU 数を増やすことで TTFT は改善できるが ITL の Tail は通信コスト増で悪化する可能性すらある。 2. **PD Disaggregation はリソースの独立スケーリングを可能にする**：TTFT と ITL という相反する最適化要求を持つ指標を個別に改善するには、Prefill と Decode を分離して独立したリソーススケーリングを行うことが望ましい。PD Disaggregation はその設計的根拠となる。 3. **メリット享受はワークロード依存**：入力長が比較的長く、リクエストが常時飛んでくる環境（バースト的な高並行接続）ではメリットが得られる。そうでない場合は PD Disaggregation なしでも SLO/SLA を満たせる可能性が高い。 さらに、特定の構成・リソース量が最適とは限らず、**継続的に観測・改善する最適化ループが重要**であるとまとめられている。ユーザーリクエストの傾向やシステム負荷を常時観測し、基盤が満たすべき SLO/SLA を実現するための情報を収集しながら改善を繰り返すアプローチが必要である。 --- ## 備考 - 本記事の内容は第 3 回 vLLM roundup Community Meetup Tokyo での発表内容と一部重複する。 - GenAI-perf は現在新機能開発を停止しており、後継として AIPerfが開発中である。 - LLM の利用形態（ChatBot / RAG / Agentic AI 等）によってもユーザー負荷の傾向は変化するため、ベンチマーク設計には十分な考慮が必要である。 - 今後の連載では KV キャッシュの最適化・再利用に関する話題を中心に扱う予定とのことである。 --- ## 関連 - ソース: `.raw/articles/sakura-distributed-inference-vol3-2026-03-25.md` - 著者: [[道下幹也]] - 組織: [[SAKURA Internet]] - ハードウェア: [[高火力 PHY]] - ソフトウェアスタック: [[vLLM]] / [[LMCache]] / [[NIXL]] / [[UCX]] - 関連概念: [[LLM推論]] / [[サービスレベル目標]] - 連載前回: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]