7月11日、AWSが「Disaggregated prefill and decode for LLM inference on SageMaker HyperPod」と題した記事を公開した。SageMaker HyperPod上でvLLMを使ったPrefill/Decode分離推論（DPD）を実装する手順について詳しく紹介されており、長文プロンプトによってストリーミング中のトークン生成が乱れるレイテンシスパイクを構造的に解消するアプローチとして注目される。

なぜPrefillとDecodeを分離するのか

LLM推論には性質の異なる2つのフェーズがある。

• Prefill：入力プロンプト全体を並列処理してKVキャッシュを生成する。演算律速（compute-bound）。
• Decode：1トークンずつ生成する。メモリ帯域律速（memory-bound）で、モデルの重みと肥大化するKVキャッシュへの高速アクセスが必要。

この2つを同じGPUで動かすと、長いプロンプトのPrefill処理が実行中の全Decodeリクエストをブロックする。4,096トークンを超えるような長文プロンプトが複数同時に来ると、per-tokenレイテンシのスパイクが発生するのはこの構造的な問題による。

Disaggregated Prefill and Decode（DPD）はこの干渉をなくすため、PrefillとDecodeをそれぞれ専用のGPUプールに分離し、Elastic Fabric Adapter（EFA）のRDMA（Remote Direct Memory Access）経由でKVキャッシュを転送する構成だ。

アーキテクチャの全体像

HyperPodのDPD実装は、vLLM Production StackのルーターとLMCache（KVキャッシュ転送レイヤー）を組み合わせた3コンポーネント構成だ。

インテリジェントルーター

制御プレーンとして機能する。各プロンプトをトークナイズし、設定可能なトークン数閾値（routingThreshold）に基づいてリクエストの振り分けを決定する。

• 閾値を超える長文プロンプト → Prefiller → Decoder の分離パス
• 閾値以下の短いプロンプト → Decoderへ直接転送（EFA越しのKV転送コストが割に合わないため）

ルーティング戦略として prefixaware、kvaware、session、roundrobin を選択でき、レプリカ間のキャッシュ局所性を最大化できる。

Prefillerポッド

vLLMワーカーにLMCacheをKVコネクターとして組み込んだ構成。長文プロンプトのKVキャッシュを計算し、LMCacheのPD送信バックエンドを通じてレイヤーごとにDecoderへ転送する。演算と転送をオーバーラップさせることでGPUの稼働率を維持する。

また、CPUメモリ上のローカルキャッシュも持つ。システムプロンプトやマルチターン履歴など同じプレフィックスが再登場した場合、GPUで再計算せずCPUメモリから提供できるため、TTFT（Time to First Token）の改善につながる。

Decoderポッド

KV転送を受信するvLLMワーカー。PD_BUFFER_SIZEで設定されたGPUメモリを受信バッファとして確保し、転送完了後すぐに生成を開始する。Prefill処理を一切行わないため、長文リクエストが追加されても、すでにストリーミング中のレスポンスのトークン生成速度が乱れない。

KV転送スタック

LMCache PD → NIXL → libfabric → EFA

NIXLがGPU・CPU・リモートピア間のメモリ抽象化を担い、libfabricプロバイダーがEFAをカーネルバイパス・GPU-Direct RDMAとして公開する。ホストCPUはデータパスから外れる。

ml.p5.48xlarge（EFA帯域3,200 Gbps）上での実測値として、Llama 3.3 70Bの8,000トークン分のKV転送はシングルデジット・ミリ秒（一桁ミリ秒台）とされており、Prefill計算コストに対して転送コストは無視できるレベルだ。

実際のデプロイ手順

前提条件

• HyperPod Inference Operator v3.2以上（新規EKSクラスターにはデフォルトでインストール済み）
• RDMAおよびEFAに対応したインスタンス（P5ファミリーなど）
• 同一AZ内にインスタンスを配置すること（EFA高帯域通信の要件）

バージョン確認コマンド：

kubectl get deployment hyperpod-inference-operator-controller-manager \
  -n hyperpod-inference-system \
  -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].image}{"\n"}'

ワーカーイメージ

DPD対応イメージとして現時点で2択が提供されている。

• オープンソース版LMCache：lmcache/vllm-openai:v0.4.3
• SageMaker DLC：vllm:server-hyperpod-cuda-v1.1

モデルのS3配置とマニフェスト適用

モデルはHugging Faceからダウンロードしてs3へ同期しておく（hf download → aws s3 sync の手順）。マニフェストで重要なのがspec.pdSpecフィールドだ。このフィールドの存在がエンドポイントを分離構成にするトリガーとなる。

• replicas：PrefillとDecodeを独立してスケール
• routingThreshold：分離パスに振り分けるトークン数の閾値
• args：ロールごとのvLLMフラグ（prefillSpec・decodingSpecに個別設定可能）

マニフェストをapplyすると、Operatorがnamespace内にPrefill/Decode用の2つのDeploymentと、hyperpod-inference-systemにルーターDeploymentを作成する。

kubectl apply -f inference_endpoint_dpd_config.yaml

正常起動後は以下で状態を確認できる。

kubectl get inferenceendpointconfig ${DEPLOYMENT_NAME} -n ${NAMESPACE} \
  -o jsonpath='{.status.conditions[0].message}{"\n"}'
# → DPD prefill and decode deployments are ready

どういうワークロードに向くか

DPDが効果を発揮するのは以下の条件が揃うケースだ。

• 入力プロンプトが定常的に4,096トークンを超える
• 複数ユーザーが同時リクエストを送る
• ストリーミングレスポンスでの安定したトークン配信が求められる
• 長文・短文が混在するトラフィック

逆に、バッチ・オフライン処理や低並列・短文専用のワークロードでは、KVキャッシュ転送の固定コストがメリットを上回るため、シンプルなコロケーション構成の方が合理的だとされている。

詳細はDisaggregated prefill and decode for LLM inference on SageMaker HyperPodを参照していただきたい。