AWS、Ray LLM DLCでEKS上のマルチノードLLM推論を解説

何が示されたか

AWSがRay LLM DLCを使い、Amazon EKS上の2つのGPUノードに1つのLLMをまたがって配置する手順を示した。prefillとdecodeを別ノードに分離し、1つのOpenAI互換エンドポイントの背後で協調させる。想定用途としてRAG、文書要約、エージェント型アプリケーションが挙げられている。

単一GPUノードの構成では、1つのGPUに収まらないモデルや、1レプリカでは足りないスループットへの対応が難しい。マルチノード構成はテンソル並列・パイプライン並列・データ並列、そしてprefill/decode分離で一般的だが、GPUスタックのライブラリ互換を利用者自身が組み合わせて検証する必要があった。DLCはその依存関係をテスト済みの組み合わせとしてまとめたものになる。

PD分離の狙いと仕組み

LLM推論には2つのフェーズがある。prefillは入力プロンプト全体を並列に処理してKVキャッシュを作り、decodeはそのキャッシュを読みながらトークンを1つずつ生成する。prefillは計算律速、decodeはメモリ帯域律速で、同じGPUを共有すると互いに干渉する。

分離すると各フェーズに別々のハードウェアとサービング設定を選べ、独立してスケールできる。一方で、prefillが作ったKVキャッシュをdecodeノードに渡す必要があり、その転送が速くなければ効果が相殺される。記事はだからこそノード間の相互接続が重要になると説明している。

DLCに含まれるもの

Ray LLM DLCには、推論エンジンのvLLM、Ray ServeのHTTPレイヤー、ノード間KVキャッシュ転送のNIXL、高帯域ノード間通信用のEFAスタック（libfabricとaws-ofi-nccl）が含まれる。CUDAランタイムやフレームワーク、サービング層の間にバージョンのずれが起きないよう、全コンポーネントがまとめて検証され、セキュリティパッチはビルド時に適用される。

アプリケーションはYAMLのserveConfigV2ブロックで定義する。build_pd_openai_appというヘルパーがprefill_configとdecode_configを受け取り、両者の間のKVキャッシュ転送を配線する。ハンドラクラスやモデルアーカイバ、カスタムイメージのビルドは不要とされている。

記事が特に重視するのがkv_connector_extra_configでbackendsにLIBFABRICを指定する行である。指定しない場合、NIXLはUCXを既定として使い、EFA上でもTCP相当の速度になると説明されている。

EKS上の構成

構成はVPC内のEKSクラスタで、ノードはプライベートサブネットに置かれ、NAT Gateway経由で外向き通信を行う。CPUのシステムノード（m7i.xlarge）がKubeRayオペレーターとRayヘッドを動かし、2台のGPUワーカーノード（g6.8xlarge）がprefillとdecodeをそれぞれ担当する。両ノードはAmazon ECRからDLCを取得する。

GPUノードグループは単一のAvailability Zoneに固定される。EFAはAZをまたげないためである。ワーカーのPodはGPU 1基とEFAインターフェース1つを要求し、NIXLがCUDA VRAMをEFA NICに登録する関係でprivileged: trueで動かす必要がある。IPC_LOCKだけでは足りないと説明されている。

現時点の注意点

検証はQwen3.5-9Bをg6.8xlargeで動かす構成を前提としている。記事の設定値（max_model_len 4096、bfloat16、gpu_memory_utilization 0.90、enforce_eager true）はこの構成に合わせたものとみられる。より大きなモデルや別のインスタンスで同じ設定が通用するかは示されていない。

モデル重みのロードは、このキャッシュ構成で再起動時に約145秒から約2秒に短縮されたと報告されている。ただしモデルや入力に依存する部分がある。デプロイ手順は4つのスクリプトに分かれ、クラスタ作成だけで15〜20分、GPUノード追加に5〜20分かかるとされる。