AWS、GPU内部状態に応じてLLMリクエストを最適分散する「SageMaker HyperPod Inference Gateway」を発表

要点

• 米Amazon Web Services（AWS）は、GPUの稼働状況に応じてLLM推論リクエストを最適に振り分ける「Amazon SageMaker HyperPod Inference Gateway」を発表した。

• モデルサーバーやクライアント側のコード変更を伴わず、単一のKubernetes（EKS）マネージド・アドオンとして既存インフラに導入できる。

• KVキャッシュ使用率やキュー深度などのリアルタイム指標をもとにルーティングを行い、ファーストトークンレイテンシを最大82%削減する。

• 今後の計画として、複数クラスタや複数リージョンにまたがるトラフィック調整を行う「Global Inference Router」の提供も予定されている。

• 米Amazon Web Services（AWS）は現地時間2026年9月18日、GPUクラスタ上での大規模言語モデル（LLM）推論を効率化するルーティングシステム「Amazon SageMaker HyperPod Inference Gateway」を発表した。本機能は、GPU内部のリアルタイムな負荷状態を把握して最適なポッド（コンテナの実行単位）へ推論リクエストを振り分けることで、GPUリソースの浪費を防ぎ、応答開始までの遅延を大幅に削減するKubernetesネイティブのアドオンとなっている。

従来の負荷分散が抱えるGPUの非効率性と応答遅延

大規模言語モデルをGPUクラスタ上で大規模に運用する際、従来のKubernetes標準ロードバランサーが採用するラウンドロビン（順番通りの均等割り振りの仕組み）や最小接続数といったアルゴリズムでは、GPU内部の詳細な処理状況を把握できないという課題があった。

具体的には、どのポッドのKVキャッシュ（生成AIが推論時に過去の計算結果を保持するメモリ領域）が満杯に近い状態にあるか、長文の生成処理を実行中であるか、あるいはリクエストが必要とするLoRAアダプタ（特定用途向けに追加学習された軽量モデル）がメモリ上に読み込まれているかといった情報をロードバランサーが認識できなかった。

その結果、処理負荷の高いポッドにリクエストが集中して待ち行列が生じる一方で、余力のあるポッドが活用されない事態が発生していたという。トラフィックが急増した際には、最初の出力文字が返るまでの時間（ファーストトークンレイテンシ）が4秒以上に跳ね上がり、GPUの稼働率が不安定になることで、需要を満たすために過剰なGPUを用意せざるを得ず、コスト増加につながっていたとAWSは説明している。

GPUシグナルに基づくインテリジェントルーティングと遅延削減

今回発表されたSageMaker HyperPod Inference Gatewayは、こうした課題を解決するために開発された。既存のHyperPodインフラ環境に対し、単一のEKSマネージド・アドオン（amazon-sagemaker-hyperpod-inference）として導入できる。

モデルサーバーやクライアントアプリケーションに変更を加えることなく利用できる点が特徴で、GPUから得られるリアルタイムなシグナルを活用して各リクエストに最も適したポッドを選択する。

これによりGPUの無駄を排除し、ファーストトークンレイテンシを最大82%削減できるとしている。元記事では具体例として、「チャットボットの利用者が最初のトークンを受信するまでに4.4秒待たされていたケースにおいて、800ミリ秒未満で表示されるようになる」という改善効果が示されている。

クラスタ内処理を担う第1層の3要素と評価アルゴリズム

本システムのアーキテクチャは、Kubernetesの標準機能を基盤とした2層構造を採用している。第1層（Tier 1）は個々のHyperPod／EKSクラスタに直接導入されるクラスタ単位のゲートウェイであり、オープンソースの「Gateway API Inference Extension」をベースとする3つのコア要素で構成される。

1つ目は「Envoy Gateway」で、クラスタごとに単一のプライベートエンドポイントを提供し、送られてくるHTTPSトラフィックを終端する高性能なL7プロキシとして機能する。

2つ目は「Body-Based Router（BBR）」で、OpenAI互換のリクエスト本文を検査し、指定されたモデル情報を抽出して適切なモデルプールへ振り分ける。これにより、1つのゲートウェイで複数モデルを運用するマルチモデルルーティングが可能になる。

3つ目は知能レイヤーにあたる「Endpoint Picker（EPP）」である。EPPは各ポッドから監視ツールPrometheusのメトリクスをリアルタイムに収集し、重み付けスコアリングアルゴリズムを用いて最適なバックエンドを選定する。評価指標には以下の5項目が用いられる。

• KVキャッシュ使用率：キーバリューメモリが満杯に近いポッドへの割り振りを回避する。
• キューの深さ：未処理リクエストのバックログが溜まっているポッドを避ける。
• LoRAアダプタの常駐状況：リクエストされたアダプタがすでにメモリ上に読み込まれているポッドを優先する。
• プレフィックスキャッシュのヒット率：プロンプトの共通部分がキャッシュされており、高速に処理できるポッドを優先する。
• 実行中リクエスト数：稼働中の処理負荷をフリート全体で均等に保つ。

各スコアラーの重みは利用者が柔軟に設定可能となっており、低遅延が重視されるチャット用途から、スループットの最大化を目指すバッチ処理用途まで、ワークロードの特性に応じたチューニングに対応する。

フリート全体を統合制御する第2層の計画

さらにAWSは、アーキテクチャの第2層（Tier 2）として「Global Inference Router（GIR）」の提供を近日中に予定していることを明らかにした。

GIRは第1層の基盤の上に構築され、複数クラスタや複数リージョンにまたがるフリート全体のトラフィック調整を行う機能である。クラスタ間での自動フェイルオーバーやグローバルなレート制限、コストを考慮したトラフィック制御などが追加される予定だという。この第2層が導入された後も、各クラスタに配置された第1層のゲートウェイがローカル環境におけるインテリジェントなルーティング処理を引き続き担う設計となっている。