LLM推論のGPU取り合いを解消｜AWS新機能DPD

ツール米国メガテック SageMaker HyperPod 07/07 13:05

AI TREND

AWS：DPD機能を提供開始

AWSがSageMaker HyperPodで、LLM推論の前処理（プロンプト読み込み）と生成（トークン出力）を別々の専用GPU群に分けて処理する新機能「前処理・生成の分離（DPD）」を提供開始した。

3 の要点を3分で

AWSはSageMaker HyperPodで、LLM推論の2段階を別々のGPU群に分ける新機能「前処理・生成の分離（Disaggregated Prefill and Decode、DPD）」を提供開始した。LLM推論は、入力プロンプトをまとめて処理する前処理と、応答を1トークンずつ生成する生成に分かれる。従来は両段階を同じGPUで実行していたため、長い文脈を持つ1件のリクエストが同時処理中の全リクエストのトークン生成を止め、片方を守るために過剰にGPUを確保せざるを得なかった。

DPDは計算量が多い前処理と、メモリ帯域を多く使う生成を別々のGPU群で走らせ、中間データ（キー・バリューキャッシュ）をEFA上のGPU-Direct RDMAで転送する。自動振り分け機能が長文リクエストのみを分離経路へ送り、短文は直接生成側へ回すため無駄な転送負荷が生じない。

有効化は既存の推論エンドポイント設定に「pdSpec」設定を足すだけで、既存のキャッシュ退避機能や振り分け機能と組み合わせられる。EKS基盤のHyperPodクラスターでEFA対応インスタンスがあれば、HyperPod提供の全AWSリージョンで利用できる。

LLM推論のGPU取り合いを解消｜AWS新機能DPDの本文内説明図 — 図解: AIエージェント - AWSがSageMakerHyperPodでLLM推論の前処理

押さえるポイント

この変化で何が要点か。図解と出典つきで一目で。

前処理と生成を別GPUに分離し、同居時の資源競合をなくす
長文1件が全リクエストのトークン生成を止める問題を解消
既存設定にpdSpec設定を足すだけで有効化できる手軽さ

5W1Hでサクッと理解

構造化された事実を最初に。誰が何をいつどこでなぜどのように。

誰が: AWS
何を: DPD機能を提供開始
いつ: 2026年7月7日
どこで: SageMaker HyperPod
なぜ: 推論の資源競合解消
どのように: 前処理と生成を分離

背景

LLM推論は、入力プロンプトをまとめて処理する「前処理」と、応答を1トークンずつ生成する「生成」の2段階に分かれる。従来は両段階を同じGPUで実行していたため、長い文脈を持つ1件のリクエストが、同時に処理している全リクエストのトークン生成を止めてしまう問題があった。その結果、片方の段階を守るために過剰にGPUを確保せざるを得なかった。前処理は計算量が多く、生成はメモリ帯域を多く使うという性質の違いがあり、同居させると互いに資源を奪い合っていた。

なぜ今注目なのか

チャットアシスタント、複数手順を自動で進めるAIパイプライン（エージェント処理）、外部知識を参照して回答する仕組み（検索連携生成、RAG）、長文分析などを本番運用する企業は、混在するトラフィックの下でも安定した応答速度と予測可能なスループットを求めている。DPDは前処理と生成の資源競合をなくし、厳しい応答速度目標の下でも実効処理量を高められる。前処理と生成の容量を別々に増減できるため、ワークロードの入出力特性に合わせた運用が可能になる。

前処理と生成を別GPUに分離する仕組み

AWSはSageMaker HyperPodで、LLM推論の2段階を別々のGPU群に分ける新機能「前処理・生成の分離（Disaggregated Prefill and Decode、DPD）」を提供開始した。LLM推論は、入力プロンプトをまとめて処理する前処理（プレフィル）と、応答を1トークンずつ生成する生成（デコード）の2段階に分かれる。DPDは前処理を計算量が多いGPU群、生成をメモリ帯域を多く使うGPU群に分け、両者の中間データであるキー・バリューキャッシュを、高速ネットワーク（EFA上のGPU-Direct RDMA、GPU間を直結して高速転送する仕組み）で受け渡す。

Amazon SageMaker HyperPod now supports Disaggregated Prefill and Decode (DPD), an inference optimization that separates the two phases of large language model (LLM) inference — prefill and decode — onto dedicated GPU pools and transfers the key-value (KV) cache between them over Elastic Fabric Adapter (EFA) using GPU-Direct RDMA.
出典: AWS What's New

従来は前処理と生成を同じGPUで実行していたため、長い文脈を持つ1件のリクエストが、同時に処理している全リクエストのトークン生成を止めてしまう問題があった。DPDはこの資源競合を切り離す設計だ。

なぜ同居させると資源を奪い合うのか

前処理と生成には性質の違いがある。前処理は入力プロンプト全体を一度に処理するため計算量が多く、生成は1トークンずつ出力するためメモリ帯域を多く使う。この2つを同じGPUに同居させると、互いに資源を奪い合う。

結果として、片方の段階の性能を守るために、もう片方に過剰にGPUを確保せざるを得なかった。DPDでは計算重視の前処理を一方のGPU群、メモリ帯域重視の生成をもう一方のGPU群で走らせるため、両者はもう同じ資源で競合しない。

With DPD, customers run compute-bound prefill on one set of GPUs and memory-bandwidth-bound decode on another, so the two phases no longer contend for the same resources.
出典: AWS What's New

これにより持続的な同時実行下でトークンあたりの応答速度が安定し、厳しい応答速度目標（レイテンシSLO）の下でも実効処理量（goodput）が高まる。さらに前処理と生成の容量を別々に増減できるため、入力と出力の分布に合わせた運用ができる。

短文に無駄な転送をかけない自動振り分け

分離には中間データの転送コストが伴う。すべてのリクエストを分離経路に通すと、短いプロンプトにまで転送負荷がかかってしまう。DPDはこれを自動振り分け機能（インテリジェントルーター）で回避する。

An intelligent router automatically directs long-context requests through the disaggregated path and sends shorter prompts directly to the decoder, so customers get the benefit on the traffic that needs it without paying transfer overhead on short prompts.
出典: AWS What's New

長い文脈のリクエストだけを分離経路へ送り、短いプロンプトは直接生成側（デコーダー）へ回す。これにより、分離の恩恵が効く長文トラフィックだけに効果を集中させ、短文で無駄な転送負荷を払わずに済む。チャットアシスタント、エージェント処理、RAG、長文分析といった入力長がばらつくワークロードで、この振り分けが効く。

DPDの有効化のやり方と利用条件

有効化は既存構成への追加だけで済む。すでに推論エンドポイントで使っているリソースに設定を足す形だ。

HyperPod推論オペレーターで使っている既存の推論エンドポイント設定（InferenceEndpointConfigというカスタムリソース）に、`pdSpec`という設定セクションを追加する。
既存のキャッシュ退避機能（KVキャッシュのオフロード）や自動振り分け機能と組み合わせて構成する。

Customers enable DPD by adding a `pdSpec` section to the same `InferenceEndpointConfig` custom resource they already use for inference endpoints on the HyperPod Inference Operator, and DPD is composable with the existing KV cache offloading and intelligent routing features on HyperPod.
出典: AWS What's New

利用条件は、EKS（Kubernetesのマネージド基盤）をオーケストレーターに使うHyperPodクラスターで、EFA対応インスタンスタイプを使っていること。この条件を満たせば、SageMaker HyperPodが提供される全AWSリージョンで利用できる。