ライフスタイル

AWS、マルチノード対応のRay LLMコンテナを公開：大規模言語モデルの「プロンプト読み込み」と「回答生成」を2台のGPUノードに分担

AWSはマルチノードデプロイ向けのRay LLM Deep Learning Containerを公開し、Amazon EKS上で2台のGPUノードにプロンプトの読み込み（prefill）と回答の生成（decode）を分担させる例を示しました。AWSは、自前で大規模モデルを運用するチームが、AWSの保守・テスト済みコンテナをそのまま使え、ソフトウェアスタックを自分で組み合わせる必要がないと説明しています。

読了目安 8 分

AWS、マルチノード対応のRay LLMコンテナを公開：大規模言語モデルの「プロンプト読み込み」と「回答生成」を2台のGPUノードに分担
画像：Mokaair (Original editorial artwork)

何が起きたのか

AWSはブログ記事で、マルチノードデプロイ向けRay LLM Deep Learning Container（DLC）の登場により、DLCの構築済み手法がマルチノード推論にも広がったと述べています。AWSの説明では、DLCはフレームワーク、依存パッケージ、GPUソフトウェアスタックを、テスト・パッチ適用済みの組み合わせとしてまとめた構築済みDockerイメージで、取得してすぐ使えます。記事では、Amazon EKS（Amazon Elastic Kubernetes Service）上で、単一の大規模言語モデルを2台のGPUノードにデプロイし、独立したprefillノードとdecodeノードをOpenAI互換の単一エンドポイントの背後に置く方法を示しています。つまり、利用者は標準的なチャットリクエスト形式でこのサービスの入口を呼び出せます。

AWSによると、Ray LLM DLCには、推論エンジンとしてvLLM、サービング層としてRay ServeのHTTP、ノード間のKVキャッシュ転送用のNIXL（NVIDIA Inference Transfer Library）、高帯域のノード間通信を担うEFA（Elastic Fabric Adapter）スタック（libfabricとaws-ofi-nccl）が含まれます。AWSはまた、DLCの全コンポーネントがリリースごとにまとめて検証されるため、CUDAランタイム、フレームワーク、サービング層の間でバージョンのずれが生じず、セキュリティパッチもビルド時に適用されると述べています。

AWSは、サービングアプリ全体が1つのYAML設定だけで済み、ハンドラークラス、モデルアーカイブ用ツール、カスタムイメージは不要だと説明しています。ヘルパー関数build_pd_openai_appがprefillとdecodeの設定を受け取り、OpenAI互換の単一エンドポイントの背後でKVキャッシュ転送を接続します。

なぜprefillとdecodeを分けるのか

AWSによれば、大規模言語モデルの推論には2つの段階があります。Prefillは入力プロンプト全体を並列に処理してkey-value（KV）キャッシュを作り、Decodeはトークン（モデルが出力する文章の単位）を1つずつ生成しながらそのキャッシュを読み込み、拡張します。AWSは、2段階を分けることで、計算量の大きい長いプロンプトが進行中リクエストのトークン生成を妨げるのを避けられ、両段階を独立にスケールできると指摘しています。

AWS記事による推論2段階の説明
項目PrefillDecode
作業内容入力プロンプト全体を並列処理してKVキャッシュを作成トークンを1つずつ生成し、そのキャッシュを読み込み・拡張
AWSが述べるボトルネック演算能力に制約されるメモリ帯域に制約される
例でのノードg6.8xlargeのGPUノード1台別のg6.8xlargeのGPUノード1台

AWSは、トレードオフとして、prefillが作ったKVキャッシュをdecodeノードへ渡す必要があり、この転送が十分高速でなければ利点が相殺されるため、ノード間の相互接続が重要だと述べています。AWSは、この構成がRAG（検索拡張生成）、文書要約、エージェント型アプリなどのワークロードに向くとしています。

サンプル構成と注意点

AWSのサンプル構成では、システムワークロード、KubeRay operator、Ray head podを載せるCPUシステムノード（m7i.xlarge）1台と、prefill用・decode用の2台のGPUワーカーノード（g6.8xlarge）を使います。AWSは、EFAがアベイラビリティゾーン（AZ）をまたげないため、GPUノードグループを単一AZに固定していると述べています。

AWSの例ではQwen3.5-9Bモデルを使い、max_model_lenを4096に設定しています。AWSによれば、g6.8xlargeで記事のキャッシュ設定を使うと、再起動時のモデル重みの読み込み時間が約145秒から約2秒に短縮されたとのことです。

AWSはさらに、計算を担当するワーカーpodはprivileged: trueの設定で動かすと説明しています。NIXLがCUDA VRAM（GPUメモリ）をEFAネットワークカードに登録するため、IPC_LOCKケーパビリティだけでは足りないからです。

一般の読者にとっての意味

一般の読者にとっては、自前で大規模モデルのサービスを運用したいチームが、AWSが保守・テストしたコンテナを使え、GPUやネットワーク関連のソフトウェアスタックを自分で組み合わせなくて済む、ということです。AWSは、一般的なマルチノード推論のパターンとして、テンソル並列・パイプライン並列（1つのインスタンスに収まらないモデルを分割）、データ並列（モデルを複製してスループットを高める）、prefill/decodeの分離（推論の2段階を別ノードに置く）を挙げています。

AWSが挙げる前提条件は、課金が有効なAWSアカウント、g6.8xlargeインスタンス2台を動かせるクォータ（64 vCPU以上）、AWS CLI、kubectl、eksctl、helm、envsubstなどのツールです。デプロイ手順は4ステップで、EKSクラスターの作成（新規で約15〜20分）、GPUワーカーノードの追加、KubeRay operatorのインストール、RayServiceのデプロイです。継続的な課金を避けるため、AWSはリソースを逆の順序で削除することを勧めています。

以上はすべてAWS自身の説明です。性能やコストの結果は、ご自身の環境で確認してください。

よくある質問

prefill/decodeの分離とは何ですか？

AWSによれば、入力プロンプトを処理するprefill段階と、トークンを1つずつ生成するdecode段階を別ノードに置き、互いに干渉させず、独立してスケールできるようにする手法です。

このコンテナは何に使うものですか？

AWSによると、Ray LLM DLCにはvLLM、Ray ServeのHTTPサービング層、NIXL、EFAスタックが含まれ、OpenAI互換のエンドポイントでマルチノードのモデル推論を提供するために使います。

デプロイにプログラミングは必要ですか？

AWSは、サービングアプリ全体が1つのYAMLで済み、ハンドラークラス、モデルアーカイブ用ツール、カスタムイメージは不要だと説明しています。ただしEKSクラスターと関連ツールの設定は必要です。

これらの性能数値は他の情報源でも裏付けられていますか？

本記事の内容はすべてAWS自身のブログ記事に基づく単一の情報源であり、AWSの主張として受け取ってください。

このトピックの最新ニュースを見る

同じテーマの記事

出典

ライフスタイル