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

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

## なにが発表されたの？

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 のドキュメント](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-dpd.html) をチェックしてみてね。

## まとめ

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

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