SageMaker HyperPod、LLM 推論の prefill と decode をついに分離！

こんにちは、しぃちゃんだよ！ 今日は LLM の推論をもっと安定させる、ちょっと通なアップデートを見つけちゃった。

AWS What's New aws.amazon.com

なにが発表されたの？

AWS の What's New から。Amazon SageMaker HyperPod が Disaggregated Prefill and Decode（DPD） に対応したよ。これは大規模言語モデル（LLM）の推論を、prefill（プロンプトを読み込む段階） と decode（トークンを 1 個ずつ生成する段階） の 2 つに分けて、それぞれ専用の GPU プールで動かす最適化なの。2 つのプールの間では KV（キーバリュー）キャッシュを、Elastic Fabric Adapter（EFA）上の GPU-Direct RDMA で受け渡しするんだって。

今まではどうだったの？

これまでは prefill と decode が 同じ GPU を共有していたの。すると、長いコンテキストのリクエストが 1 本入っただけで、同時に走っている他の全リクエストのトークン生成が止まっちゃう。しかも片方の段階を守るために、もう片方を過剰にプロビジョニングする…という無駄も起きやすかったんだ。チャットアシスタントやエージェント、RAG、長文解析みたいに「1 トークンあたりのレイテンシを一定に保ちたい」ワークロードには悩ましいところだったの。

これで何が変わるの？

DPD を使うと、計算律速な prefill と、メモリ帯域律速な decode がリソースを取り合わなくなるよ。だから

• 高い同時実行でも 1 トークンあたりのレイテンシが安定する
• 厳しいレイテンシ SLO のもとでも goodput が上がる
• prefill と decode の容量を 別々にスケール できる

しかも賢いルーターが付いていて、長いコンテキストのリクエストだけを分離パスに流して、短いプロンプトはそのまま decoder に送るの。だから短いプロンプトに転送のオーバーヘッドを払わずに済むんだって。

深く潜ってみよう

有効化はとってもシンプル。いつも推論エンドポイントで使っている InferenceEndpointConfig カスタムリソースに pdSpec セクションを足すだけで、HyperPod Inference Operator 上で DPD が動くよ。既存の KV キャッシュオフロードやインテリジェントルーティングとも組み合わせられるの。

対象は EKS オーケストレーターを使う SageMaker HyperPod クラスターで、EFA 対応のインスタンスタイプが必要。提供リージョンは HyperPod が使える全 AWS リージョンだよ。もっと詳しく知りたい人は HyperPod 推論向けの Disaggregated Prefill and Decode のドキュメント をチェックしてみてね。

まとめ

• SageMaker HyperPod が LLM 推論の prefill と decode を分離する DPD に対応
• 2 段階が GPU を取り合わなくなり、レイテンシが安定して容量も別々にスケールできる
• KV キャッシュは EFA 上の GPU-Direct RDMA で転送、賢いルーターが長文だけを分離パスへ
• 有効化は InferenceEndpointConfig に pdSpec を足すだけ

本番で LLM を大規模にサービングしていて、レイテンシのばらつきや GPU の過剰プロビジョニングに悩んでいる人にこそ刺さるアップデートだよ！