【LLM推論のゲームチェンジャー】SageMaker HyperPodが「PrefillとDecodeの分離」を実現！遅延とスループットのジレンマを突破せよ

Amazon SageMaker HyperPodが、LLM推論の2つのフェーズ（PrefillとDecode）を物理的に異なるGPUプールに分離して実行する「Disaggregated Prefill and Decode (DPD)」をサポートしました。EFAとGPU-Direct RDMAを利用してKVキャッシュを高速転送することで、長いコンテキストのリクエストが他の生成処理をストップさせてしまうリソース競合を解消。ワークロードに合わせてPrefill用とDecode用の計算リソースを独立してスケーリング可能になります。

🚀 LLM運用エンジニアの悲鳴、ついに解消か？

「長いプロンプトが来た瞬間に、他のリクエストのトークン生成が止まる…」 LLMの本番運用で誰もが直面するこの**「PrefillとDecodeの競合」**問題、ついにSageMaker HyperPodが正面突破してきましたね。

🛠 技術的なブレイクスルー

従来の構成では、計算負荷の高いPrefillと、メモリ帯域が重要なDecodeが同じGPUでリソースを奪い合っていました。DPDなら、計算リソースに特化したPrefill Podsと、メモリ帯域に特化したDecode Podsを分けることで、一貫したトークン生成遅延を実現できます。

🇯🇵 日本国内の利用環境について

リサーチの結果、東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) の両方で SageMaker HyperPod の利用が可能であることが確認できました！ ただし、DPDの性能をフルに引き出すには EFA対応のインスタンス（p4d/p5等） が必須です。利用するAZでこれらが確保できるか、事前にAWS公式の裏取りをしておくことを強く推奨します。

💡 実践的なアドバイス

• ターゲット: 70B以上の巨大モデルや、RAGなどで長いコンテキストを扱うワークロードに最適です。
• 運用戦略: DPDを有効ににするには、InferenceEndpointConfig に pdSpec セクションを追加するだけ。構成コストは上がりますが、厳格なSLOを守りつつ、スループット（Goodput）を最大化できるため、トータルでのリソース効率は向上するはずです。
• 構成のコツ: ノード間の低遅延通信が生命線なので、同一AZへの配置を基本戦略にしましょう。

✅ 次のアクション

まずは、既存の HyperPod クラスターが EFA対応インスタンス で構成されているか、そして pdSpec の設定変更だけでどの程度レイテンシが安定するか、検証環境でテストしてみるのが良いでしょう。

参照元: Amazon SageMaker AI Developer Guide - Disaggregated Prefill and Decode for HyperPod inference