マルチノード Disaggregated 推論：AMD Instinct MI300X GPU 上の DeepSeek R1 671B

はじめに

自己回帰型 LLM 推論は、2つの異なるフェーズで構成されます。prefill フェーズでは入力プロンプト全体を 並列処理して KV cache を構築し、decode フェーズではキャッシュされた key と value を使用して 出力 token を1つずつ生成します。 これら2つのフェーズは大きく異なる実行特性を持ちます — prefill は単一の長時間実行ステップで 多数の token を一度に処理する一方、decode は高頻度で多数の短いイテレーションを実行します — しかし従来のサービングシステムでは同じ GPU リソースを共有するため、 相互干渉が発生し、スループットとレイテンシの両方が低下します。

Prefill-decode disaggregation（disaggregated serving とも呼ばれる）は、 各フェーズを専用の GPU ノードプールに割り当てることでこの問題に対処し、 prefill と decode が同じ GPU 上でリソースを奪い合うことがなくなります。 この概念は DistServe（Zhong ら、OSDI 2024）で初めて体系化され、 その後広く採用されていますが、本番環境でその潜在能力を最大限に引き出すには、 カーネルレベルの計算効率からクラスタ全体のスケジューリングや KV cache 転送に至るまで、 高度に最適化されたフルスタックソフトウェアソリューションが必要です。

本レポートでは、MoAI Inference Framework — AMD GPU 上での高性能 disaggregated serving に最適化された Moreh のプロダクショングレード推論フレームワーク — を使用して、DeepSeek R1 671B を実行する5ノード AMD Instinct MI300X クラスタで prefill-decode disaggregation の効果を測定します。まず、disaggregated serving が colocated ベースラインに対して持つ優位性を示し、次に2つの構成を比較することで、 最適な prefill 対 decode ノード比率がリクエストパターンによってどのように変化するかを検証します： 2P3D（2 Prefill + 3 Decode ノード）と 1P4D（1 Prefill + 4 Decode ノード）。

背景：なぜ Prefill と Decode を分離するのか？

干渉問題

Prefill と decode が同じ GPU 上に colocated されている場合、 いくつかの方法で互いに干渉します：

• レイテンシスパイク。 Prefill は単一の、場合によっては長時間実行される GPU ステップで多数の token を一度に処理します。長いコンテキストの prefill が到着すると、 GPU を長時間占有し、同じデバイスを共有するすべての実行中の decode イテレーションを停止させます。 これにより P99 inter-token latency (ITL) が大幅に増大し — 時には桁違いに — ユーザーが期待するスムーズなストリーミング体験が損なわれます。
• スケジューリングの競合。 Prefill と decode は対立するスケジューリング 要件を持ちます。prefill は time-to-first-token (TTFT) を最小化するために新しいリクエストを 素早く処理したい一方、decode は低い inter-token latency を維持するために頻繁で 中断のないイテレーションが必要です。単一のサービングインスタンスは常に両者の間で 調停しなければならず、どのような妥協も少なくとも1つの指標を低下させます。
• 結合されたスケーリング。 オペレーターは prefill または decode の容量を 個別に追加できません。すべての新しいノードが両方のフェーズを処理する必要があり、 ボトルネックが少ない方のフェーズが過剰にプロビジョニングされます。

Disaggregated Serving の仕組み

Disaggregated serving はクラスタを個別の prefill ノードと decode ノードに分割します。 各プールは完全なモデルウェイトを保持し（プール間でのモデルシャーディングはありません）、 指定されたフェーズのみを処理します。Prefill ノードが入力処理を完了すると、 生成された KV cache を高帯域幅インターコネクト（例：RDMA）を介して decode ノードに転送し、 decode ノードは干渉なしに token 生成を継続します。

この分離はいくつかの重要な利点をもたらします。すべてのノードが同じ GPU を持つ 同質クラスタ上であっても、disaggregation は以下を提供します：

• Prefill-decode 干渉の排除。 Decode ノードは受信する prefill 作業に 中断されることなく、安定したレートで token を生成し、 大幅に低く予測可能な inter-token latency を実現します。
• 独立したスケーリング。 オペレーターはワークロードの入出力長分布に合わせて prefill 対 decode のノード比率を調整でき、過剰プロビジョニングを回避できます。
• フェーズごとの最適化。 各プールは異なる並列化戦略、スケジューリングポリシー、 バッチ構成を独立して適用でき、各フェーズに合わせて調整しつつ、 他方に影響を与えることがありません。

異種クラスタでは、disaggregation は追加の最適化次元を解放します。prefill が計算バウンドである一方 decode がメモリ帯域幅バウンドであるため、オペレーターは計算密度の高い GPU を prefill プールに、 帯域幅に最適化された GPU を decode プールに割り当て、ハードウェア特性を各フェーズの ボトルネックに合わせることができます。本レポートでは同質 AMD MI300X クラスタに焦点を当て、 干渉排除、スケーリング、フェーズごとの最適化の利点をハードウェアミックスの効果から分離します。

実験セットアップ

テスト環境

すべての実験は5ノード GPU クラスタ上で実施しました。各ノードは Gigabyte G593-ZX1-AAX1 サーバーで、デュアル AMD EPYC 9474F CPU（48コア、3.6 GHz）、2,304 GB のメインメモリ、 および8基の AMD Instinct MI300X GPU（各 192 GB HBM3e）を搭載しています。 ノード間は InfiniBand HDR で接続されています。

構成

同じ5ノードクラスタを使用して3つの構成を評価しました：

• Colocated（ベースライン）： 5つのノードすべてが prefill と decode の両方を処理。 ロードバランシングがリクエストをノード間で分散します。
• Disaggregated 2P3D： 2ノードを prefill に、3ノードを decode に専用化。 1P4D と比較して prefill により多くの容量を割り当てます。
• Disaggregated 1P4D： 1ノードを prefill に、4ノードを decode に専用化。 2P3D と比較して decode により多くの容量を割り当てます。

ベンチマークシナリオ

すべてのベンチマークは vllm bench serve を使用して実行しました。 様々な同時接続数で4つの ISL/OSL（Input Sequence Length / Output Sequence Length）の 組み合わせをテストしました。これらの組み合わせは特定のアプリケーションをモデル化するのではなく、 サービングパイプラインの異なる部分にストレスをかけるように設計されています：

• 1K/1K： バランスの取れた入出力長
• 1K/8K： 短い入力、長い出力（decode ヘビー）
• 8K/1K： 長い入力、短い出力（prefill ヘビー）
• 8K/8K： 長い入力と長い出力

各シナリオのトラフィック負荷は2つのパラメータで制御しました：N_REQs（リクエスト総数）と REQ_RATE（リクエスト到着レート、req/s）。 N_REQs はすべてのシナリオで同時接続数の2倍に設定しました。REQ_RATE は短い出力のシナリオでは より高く（1K/1K は 3–6 req/s、8K/1K は 2–4 req/s）、 長い出力のシナリオではより低く（1K/8K と 8K/8K は 2 req/s）設定しました。 これは長い生成リクエストが GPU リソースをより長時間占有する事実を反映しています。 REQ_RATE を指定すると、それが — N_REQs と共に — 名目上の同時接続数だけよりも 実際のトラフィックパターンをより正確に決定します。

結果：Disaggregated vs. Colocated Serving

まず、disaggregated 2P3D 構成（2 prefill + 3 decode ノード）を、5つのノードすべてが 両方のフェーズを処理する colocated ベースラインと比較します。クラスタの計算リソースの 40% を prefill に確保した 2P3D は、4つの ISL/OSL シナリオすべてにおける 主要な disaggregation 構成として機能します。

エンドツーエンドレイテンシ

Disaggregated 2P3D は、テストしたすべての構成において、中央値エンドツーエンドレイテンシで 1.35倍の幾何平均改善を達成しました。

最大の改善は 8K/1K（prefill ヘビー）シナリオで見られ、CON=160 で最大 1.84倍に達しました。 これは予想通りです。専用の prefill ノードがあれば、長い入力シーケンスが decode 操作をブロックする ことがなくなり、prefill ノードはそれらをより効率的にバッチ処理して処理できます。

総スループット

Disaggregated 2P3D は、総スループット（tokens per second）で 1.20倍の幾何平均改善を達成しました。

レイテンシ vs. スループット

以下の散布図は、各 ISL/OSL シナリオにおけるレイテンシとスループットのトレードオフを 可視化しています。左上（低レイテンシ、高スループット）に近いほど良好です。 各点は異なる同時接続数を表しています。

コスト効率（Token/Dollar）

Disaggregated serving は colocated ベースラインと同じ GPU 総数を使用するため、 スループットの改善はそのまま token あたりのコスト削減につながります。 2P3D 構成は colocated ベースラインに対して幾何平均 107.57% の token/dollar 効率を達成し、 オペレーターは同じインフラコストで 7.57% 多くの token を提供できることを意味します。

結果：Prefill 対 Decode 比率の影響

Disaggregated serving が colocated serving を上回ることを確認した上で、 次の問いを検討します：クラスタのノードを prefill と decode の間でどのように分割すべきか？ これに答えるため、decode ヘビーの 1K/8K シナリオで 2P3D 構成（2 prefill + 3 decode）と 1P4D（1 prefill + 4 decode）を比較します。このシナリオでは、ノードを prefill から decode に 1つ移すことの影響が最も顕著に表れます。

エンドツーエンドレイテンシ：2P3D vs. 1P4D (1K/8K)

総スループット：2P3D vs. 1P4D (1K/8K)

この decode ヘビーのワークロードでは、1P4D が一貫して 2P3D を上回ります。 追加の decode ノードがより多くの集約 decode 容量を提供し、より低いエンドツーエンドレイテンシと より高いスループットをもたらします — 特に decode がボトルネックとなる高同時接続数において。 CON=480 では、1P4D は 6,082.84 TPS を達成し、2P3D の 5,668.40 TPS を上回りました。

コスト効率の比較

Token/dollar 効率（幾何平均）では、1P4D は 111.07% に達し、2P3D は colocated ベースライン に対して 107.57% を達成しました。Decode ヘビーのワークロードでは、追加の decode ノードが 直接的により良いコスト効率につながります。

まとめ：どの比率を選ぶべきか？

2P3D は prefill ヘビーの 8K/1K ワークロードで 1.80倍の幾何平均レイテンシ改善を達成しますが、 decode ヘビーの 1K/8K ワークロードではその優位性は 1.08倍に縮小します。その場合、 1P4D が 1.13倍の E2EL 改善と 111% の token/dollar 効率で優位に立ちます。 これは追加の decode ノードのおかげです。 本番環境では、実際のワークロードは均一であることは稀で — 短いクエリ、 長いコンテキストの RAG、推論リクエストが同時に到着し、最適な比率は 一日を通じてトラフィックパターンが変化するにつれて変動する可能性があります。

これにより、prefill/decode 比率の手動設定は本質的に脆弱になります。 ピーク時のトラフィックに合わせて調整された比率はオフピーク時には最適でない場合があり、 その逆も同様です。課題は正しい比率を一度選ぶことだけではなく、継続的に適応させることです。

レイテンシの安定性：P99 Inter-Token Latency

Disaggregated serving の最も影響力のある利点の1つは、テールレイテンシの劇的な改善です。 Colocated セットアップでは、長い prefill リクエストが断続的に decode ステップをブロックし、 P99 inter-token latency (ITL) が数秒にスパイクします。 これはストリーミングアプリケーションのユーザー体験を直接低下させます。

Disaggregated serving では、prefill と decode が同じ GPU リソースを奪い合うことがありません。 その結果、P99 ITL は劇的に低下します：

これは、disaggregated serving により、混合ワークロード条件下でも一貫したスムーズな token ストリーミングをユーザーが体験できることを意味します — プロダクションチャットおよび推論アプリケーションにとって不可欠な要件です。

結論

Prefill-decode disaggregation は、大規模 MoE モデル推論において colocated serving に対する 明確で測定可能な改善をもたらします。DeepSeek R1 671B を実行する5ノード AMD MI300X クラスタでは：

• 両方の disaggregated 構成がすべてのテストシナリオで colocated ベースラインを上回り、 エンドツーエンドレイテンシの改善は最大 1.84倍、P99 inter-token latency の削減は 12–51倍に達しました。
• 2P3D（より多くの prefill ノード）は prefill ヘビーのワークロードで優れ、 8K/1K で 1.80倍の幾何平均 E2EL 改善を達成。
• 1P4D（より多くの decode ノード）は decode ヘビーのワークロードで より良いコスト効率を実現し、1K/8K で 111% の token/dollar を達成。

しかし、最適な prefill 対 decode 比率は静的ではありません — ワークロードの 入出力長分布と同時接続数に依存し、これらは本番環境で時間と共に変化します。 誤った比率を選択すると、prefill または decode のいずれかの容量が未活用となり、 disaggregation がもたらすまさにその利点が損なわれます。

MoAI Inference Framework は、disaggregated serving の構成を自動化することでこの問題に 対処します。オペレーターが固定の prefill/decode 比率を手動で選択・維持する必要はなく、 MoAI は観測されたワークロード特性に基づいて割り当てを動的に調整します — expert parallelism、ルーティング、その他の分散推論最適化と合わせて — これにより、オペレーターは手動チューニングなしで AMD Instinct GPU クラスタ上での disaggregation の完全な利点を実現できます。