Amazon SageMaker HyperPod Inference Gatewayの紹介：よりスマートなGPUルーティングが厳しい本番テストに直面

Amazonは、モデルサーバーやクライアントアプリケーションを変更せずに初回トークンのレイテンシを最大82%削減できるという印象的な主張とともに、Amazon SageMaker HyperPod Inference Gatewayを発表した。

この新しいAmazon EKSアドオンは、汎用的なリクエスト分散を、モデルサーバーとGPUのリアルタイムな状態に基づくルーティング判断へと置き換える。AWSによれば、あるベンチマークでは初回トークンまでの時間が4.4秒から800ミリ秒未満に短縮された。

この結果は、大規模言語モデルのサービングにおけるコストの大きい弱点を狙ったものだ。ラウンドロビンのロードバランサーは利用可能なネットワークエンドポイントを把握できても、飽和したキャッシュや長い生成キューは認識できない。別のGPUが待機しているにもかかわらず、過負荷のpodに新しい処理を送る可能性がある。

今回の発表により、推論リクエスト経路を誰が制御するかをめぐる競争にもAWSが加わった。Google CloudはGKE上で類似のモデル認識型ルーティングを提供しており、NVIDIA Dynamoは独自のサービングスタック内でキャッシュ認識型の配置判断を行える。

AWSは、Kubernetesネイティブのルーティングが共通の制御レイヤーになり得ると見込んでいる。より厳しい検証点は、運用面やセキュリティ面の問題を新たに生じさせずに、チームが実際のワークロード全体でこのレイテンシ改善を再現できるかどうかだ。

Amazon SageMaker HyperPod Inference Gatewayがリクエスト経路を変える

重要な変更は、また別のモデルサービングエンジンではない。AWSは既存エンジンの前段に、推論を認識する判断レイヤーを組み込んだ。

AWSは9月18日、gateway announcementを公開した。製品のリリースノートによれば、その基盤となるEKSアドオンのリリースは9月10日に行われた。

このgatewayはAmazon EKSを介してオーケストレーションされたSageMaker HyperPodクラスター上で動作する。1つのプライベートエンドポイントでリクエストを受け付け、各リクエストに対してモデルプールとサービングpodを選択する。

この選択は、2段階のローカルルーティング経路を通じて行われる。Body-Based RouterがOpenAI互換リクエストのmodelフィールドを読み取り、そのリクエストを適切なプールへ振り分ける。

Endpoint Picker、すなわちEPPは、そのプール内のpodを選択する。従来のKubernetesサービスルーティングでは理解できない情報を利用して候補を評価する。

このシグナルには、キュー深度、実行中のリクエスト、キー・バリューキャッシュの利用率、プレフィックスキャッシュの親和性、LoRAアダプターの常駐状況が含まれる。キー・バリューキャッシュは、以前に処理したトークンのアテンション状態を保存し、同じプロンプトの計算を繰り返す必要を減らす。

LoRAアダプターは、共有ベースモデルに適用するコンパクトなファインチューニング重みの集合だ。正しいアダプターをGPUメモリにロードするには時間がかかるため、常駐しているアダプターへルーティングすればスワップを回避できる。

AWSでは、オペレーターがこれらの評価要因に設定可能な重みを割り当てられる。そのため、レイテンシに敏感なチャットサービスは、バッチ指向の生成ワークロードとは異なる優先順位を利用できる。

このアーキテクチャは、トランスポートと配置インテリジェンスを分離する。EnvoyがHTTPSトラフィックと転送を処理し、Endpoint Pickerがモデル固有の選択を行う。

このgatewayは、Kubernetesネットワークを独自のリクエスト形式で置き換えるのではなく、Kubernetes Gateway API Inference Extensionを基盤としている。チームは引き続きルーティングリソースを宣言的に定義し、使い慣れたクラスター管理ツールで運用できる。

既存クライアントは、標準的なOpenAI互換リクエストを引き続き送信できる。サポートされるモデルサーバーには、vLLM、SGLang、および互換エンドポイントを公開するその他のサーバーが含まれる。

ただし、デプロイにはインフラ作業が必要だ。管理者はHyperPod Inference EKSアドオンをインストールし、権限を設定し、モデルpodにラベルを付け、InferenceGatewayConfigリソースを作成しなければならない。

AWSの最新のdeployment documentationには、サーバーの最低バージョンも記載されている。vLLMは0.9.2以降、SGLangは0.3.5.post1以降が必要となる。

AWSがgatewayにアプリケーション変更は不要だと述べる際、この区別は重要になる。クライアントおよびサーバーのコードは変更せずに済むが、クラスター設定は変更なしでは済まない。

AWSが削減したのは統合の境界であり、運用作業をなくしたわけではない。プラットフォームチームは引き続き、アイデンティティ、ネットワーク、メトリクス、アップグレード、互換性テスト、障害処理を担う。

それでも、この変化によって重要な最適化をどこで実行できるかが変わる。これまでチームは、ルーティングロジックをアプリケーション、サービスメッシュ、または専用のサービングフレームワークに組み込んでいた。

HyperPod Inference Gatewayは、その判断をマネージドEKSアドオンへ移す。これにより、各アプリケーションチームが独自のスケジューラーを構築しなくても、高度なルーティングを利用できる。

GPU認識型ルーティングがラウンドロビンより重要な理由

生成AIのリクエストは交換可能な処理単位ではないため、リクエスト数を均等に分散しても、計算負荷が均等に分散されることはほとんどない。

従来のラウンドロビンポリシーは、固定の順序でバックエンドへリクエストを送る。最小接続数ルーティングは、アクティブな接続数を考慮することで、やや改善された推定を行う。

しかし、いずれのポリシーもプロンプト長、キャッシュ状態、アダプターの可用性、または残りの生成処理量を理解できない。そのため、一見同じに見える2つの接続が、GPUに対して大きく異なる負荷を表す場合がある。

同じシステムプロンプトと製品ドキュメントを含む複数のリクエストを受け取るカスタマーサポートアシスタントを考えてみよう。その共有プレフィックスをキャッシュに保持するpodは、プロンプト処理フェーズの一部を省略できる。

別のpodでは、プレフィックス全体を再計算する必要がある。前者のpodがすでに過負荷でなければ、キャッシュ済みpodにリクエストを送ることで初回トークンまでの時間を改善できる。

ただし、キャッシュ親和性だけでは不十分だ。最も強いプレフィックス一致を常に優先するルーターは、ホットスポットを生み出し、他のアクセラレーターを十分に活用できない可能性がある。

そのためEndpoint Pickerは、キャッシュ情報とアクティブ負荷のシグナルを組み合わせる。意図する結果は、過去の処理を再利用することと、podの過負荷を避けることのバランスだ。

長大なコンテキストを含むリクエストでは、このバランスがさらに重要になる。しばしばprefillと呼ばれるプロンプト処理は、モデルが最初の可視トークンを生成する前に、かなりのアクセラレーター容量を占有することがある。

この遅延は、ユーザーには初回トークンまでの時間として現れる。チャット、検索拡張生成、コーディングアシスタント、文書分析システムでは特に目立つ。

AWSによれば、同社の例では単純なルーティングによりトラフィック急増時のレイテンシが4秒を超えた。最適化された経路では、示された4.4秒の待ち時間が800ミリ秒未満に短縮された。

これが「最大82%」という見出しの根拠だ。ただしこれはAWSが報告した結果であり、モデル、ハードウェア、トラフィックパターン、プロンプト分布を問わず得られる独立した性能保証ではない。

それでも、この仕組みには妥当性があり、業界全体で採用が広がっている。モデルサービングは、汎用ネットワークロードバランサーでは評価できない内部状態を生み出す。

潜在的な経済効果は、チャット応答の高速化にとどまらない。キューの偏りにより、オペレーターは既存容量を確実に活用できず、予備レプリカを追加しがちになる。

より適切な配置により、この安全余裕を減らせる可能性がある。また、実際に利用可能な容量へトラフィックを振り分けることで、オートスケーリングの発動を遅らせることもできる。

ただし、ルーティングとオートスケーリングは異なる問題を解決する。ルーティングは、利用可能なpodの中で次のリクエストをどこへ送るかを決める。オートスケーリングは、追加のpodやノードをいつ用意すべきかを決める。

HyperPodはすでに、CloudWatch、Amazon Managed Prometheus、Kubernetes Event-driven Autoscalingを通じた推論オートスケーリングをサポートしている。gatewayは、このより広い容量管理システムの内部で、より高速なリクエストレベルの判断を追加する。

この階層的なアプローチは、短時間の急増時に重要となる。GPU搭載の新しいレプリカを起動するよりも、すでにモデルを実行している比較的空いているpodを選ぶほうが速い場合がある。

gatewayは、オートスケーラーが持続的な需要に対応する間、即時の配置を改善できる。ただし、対象となるすべてのバックエンドが埋まっている場合に容量を生み出すことはできない。

AWSによれば、プールが枯渇した場合はRetry-Afterヘッダー付きのHTTP 429が返される。アプリケーションには依然として、リトライポリシー、受付制御、適切なタイムアウト動作が必要だ。

したがって、GPU認識型ルーティングが最も効果を発揮するのは、状態が不均一な複数レプリカのサービスだと考えられる。1つのエンドポイントに対象バックエンドが1つしかない場合、その説得力は弱まる。

AWSがKubernetesルーティング競争に参入

Amazonがモデル認識型ルーティングを何もない市場に導入するわけではない。HyperPodの運用を中心に、新たに台頭するKubernetesパターンをパッケージ化している。

Google CloudのGKE Inference Gatewayも、キュー深度、キャッシュ利用率、プレフィックス状態、LoRA親和性を活用している。これはオープンソースのllm-d routerを基盤としている。

AWSと同様に、GoogleはKubernetes gatewayの背後にEndpoint Pickerを配置する。このpickerは、モデルサーバーのシグナルを組み合わせ、受信リクエストごとに利用可能なpodを順位付けする。

NVIDIA Dynamoは別の経路を提供する。KV-aware routingは、Dynamo frontendを通じて動作することも、Gateway API Inference Extensionと統合することもできる。

違いは、リクエスト経路の所有権に関わる。プラットフォームチームは、一元化されたingress、認証、レート制限、テレメトリーのためにKubernetes Gateway APIを選ぶ場合がある。

一方、モデルサービングチームは、ルーティングを直接制御するフレームワーク固有のfrontendを好むかもしれない。NVIDIAが両方のパターンを文書化しているのは、どちらもすべての運用モデルに適合するわけではないためだ。

AWSはプラットフォーム管理型の経路を選んだ。HyperPod Inference Gatewayはクラスターに共通のエントリーポイントを与え、その背後ではモデルサーバーが引き続き推論を行う。

この設計は、1つのクラスターで複数のモデルを実行する組織に役立つ可能性がある。Body-Based Routerは要求されたモデルを読み取り、設定済みのスケジューラーおよびプールにマッピングする。

アプリケーションは、デプロイ済みモデルごとに別個のルーティングロジックを必要としなくなる。1つのgatewayで複数のプールを公開しつつ、各プール内ではpodレベルの配置判断を維持できる。

また、「ロックインなし」という主張には留保が必要なのもこの点だ。AWSは、gatewayがvLLM、SGLang、TGIを含む、あらゆるOpenAI互換モデルサーバーと動作するとしている。

データプレーンのインターフェースはポータブルであり、アーキテクチャはKubernetesリソースに依存している。しかし、マネージドアドオン、設定リソース、IAM統合、運用ライフサイクルは依然としてAWSサービスに結び付いている。

これはマネージドクラウドコンポーネントとしては珍しいことではない。完全な運用レイヤーよりも、サービングインターフェースにおいて可搬性が存在することを意味する。

GoogleもGKE上で同じ緊張関係に直面している。NVIDIAはよりフレームワークレベルの制御を提供するが、そのサービンググラフの採用は別種の依存関係をもたらす。

したがって、本当の競争はAWS対GoogleやNVIDIAという単純なものではない。プラットフォーム管理型ルーティングと、モデルサービングスタック内部で所有されるルーティングの競争である。

プラットフォーム管理型ルーティングは、複数のエンジンに対する1つの制御点を提供する。トラフィックポリシーを、クラスター運用チームの既存のKubernetesプラクティスに合わせられる。

フレームワーク所有型ルーティングは、より深いエンジン状態と専用サービング機能を、より迅速に公開できる可能性がある。また、リクエストとワーカーの間にあるコンポーネント数を減らすこともできる。

AWSによるオープンなKubernetesインターフェースの活用は、これらのアプローチ間のアーキテクチャ上の隔たりを縮める。ただし、運用上の選択をなくすものではない。

組織は、スコアリングの重みを誰が調整し、配置不良を誰が診断し、ルーティングシグナルが古くなった場合に誰が対応するのかを決めなければならない。こうした責任は、プラットフォームチームと機械学習チームをまたぐ可能性がある。

今回のリリースは、クラウドおよびサービングベンダーに対し、ルーティングインテリジェンスをより利用しやすくするよう促している。キュー認識型の配置は、カスタム最適化ではなく、期待されるレイヤーになりつつある。

競争優位はおそらく、統合の品質、可観測性、測定可能な性能へと移っていく。どのベンダーも似たようなルーティングシグナルを列挙できる。

しかし、そのシグナルが障害、急速なスケール、混在モデル、変化するプロンプト分布の中でも正確であり続けることを示せるベンダーは少ない。本番環境での証拠は、機能の同等性以上に重要になる。

82%のレイテンシー主張にはワークロード単位の検証が必要

AWSの結果は有用な上限を示しているが、自社トラフィックでどれほど改善するかを運用者に教えるものではない。

「最大82%」は、特定のテストにおいて報告された最も強い結果を表す。AWSはこれを、すべてのHyperPodデプロイメントに共通する削減率として提示してはいない。

この結果は、ベースラインのルーティングポリシーが、混雑したPodやキャッシュが冷えたPodを繰り返し選ぶかどうかに左右される。リクエストが均一なバランスの取れたサービスでは、改善の余地は小さい。

プロンプトの反復も重要である。プレフィックス認識型ルーティングは、多くのリクエストが長い先頭トークン列を共有する場合に、より大きな価値を生む。

検索拡張アプリケーションでは、似通ったプロンプトに異なる文書が挿入されることが多い。このパターンは部分的なプレフィックス重複をもたらし得るが、その価値はプロンプトの構成に依存する。

同様に、LoRA認識型ルーティングが役立つのは、チームが共有レプリカ間でアダプターを動的に提供する場合に限られる。固定モデルを1つだけ実行するサービスは、アダプター親和性から何も得られない。

トラフィック強度も結果を変える。低負荷では、配置にかかわらず複数のPodが素早く応答できる。深刻な過負荷では、どのルーティングアルゴリズムも不足したキャパシティを補えない。

そのためチームは、複数の同時実行レベルでベンチマークすべきである。最速または平均の応答だけでなく、中央値とテールレイテンシーを測定する必要がある。

最初のトークンが返るまでの時間も、ユーザー体験の一部にすぎない。トークン間レイテンシーは、最初のトークンが表示された後の生成ペースを測る。

キャッシュ済みのprefill作業を優先するルーティング判断は、最初のトークンを改善する一方、decode作業を混雑したPodに配置する可能性がある。運用者は両方のフェーズを監視しなければならない。

スループット、障害率、キュー時間、GPU使用率も、同じ評価に含めるべきである。ある指標を最適化すると、別の場所での劣化が隠れる可能性がある。

スコアリングシステムは別の変数を導入する。AWSは、キュー深度、キャッシュ状態、アクティブリクエスト、アダプター常駐性の相対的な重みをチームが変更できるようにしている。

この柔軟性は有用だが、調整の負担を生む。短いチャットプロンプト向けに設計された重みの組み合わせは、長文書リクエストでは適切に機能しない可能性がある。

メトリクスの品質も同様に重要である。Endpoint Pickerは、モデルサービングPodからの最新のPrometheusデータに依存する。

遅延、欠落、または不整合のあるメトリクスにより、インテリジェントなルーターが古い状況認識に基づいて動作する可能性がある。AWSによれば、メトリクスが古いPodは報告が再開されるまで除外される。

障害が発生したバックエンドに意図的にルーティングするより、除外する方が安全だが、利用可能なキャパシティは減少する。したがって、監視の障害がトラフィック管理の問題になり得る。

導入前には互換性のテストも必要である。現在のAWSドキュメントはvLLMとSGLangの最低バージョンを指定しており、ゲートウェイ導入に伴ってエンジンのアップグレードを強いられる場合がある。

バージョン変更は、メトリクス、キャッシュ動作、メモリー消費、モデル出力性能を変える可能性がある。チームは評価時に、ゲートウェイの効果とエンジンアップグレードの効果を切り分けるべきである。

最も安全なロールアウトは、ミラーリングされた測定または限定的なトラフィック割合から始める方法だ。運用者は、同じモデルとハードウェアで通常の負荷分散とEndpoint Pickerを比較できる。

キャッシュヒット率、キュー深度、選択判断、拒否されたリクエストを記録すべきである。これらの測定により、レイテンシーが変化したかだけでなく、なぜ変化したのかを示せる。

今回のリリースは、有望なベンダーベンチマークを伴うルーティング機構として理解するのが最適だ。あらゆるレイテンシープロファイルを自動的に82%削減するものではない。

この慎重な位置付けは、製品の価値を弱めるものではない。インフラチームに対して、検証可能な仮説と確認すべき変数の明確な組み合わせを与える。

Kubernetesネイティブはセキュリティ不要を意味しない

最も重大なデプロイメント上の詳細は、レイテンシーの見出しの外側にある。運用者が設定しない限り、ゲートウェイエンドポイントにはリクエスト単位の認可がない。

AWSのドキュメントでは、新規作成されたエンドポイントには、デフォルトでリクエスト単位の認証や認可がないとされている。ネットワークアクセスは引き続きVPCおよび関連する制御によって制限される。

AWSは、すべてのゲートウェイでJSON Web Token認証を有効にすることを強く推奨している。JWTは署名付きのIDクレームを含み、ゲートウェイはリクエストを転送する前にこれを検証できる。

ゲートウェイは高価なモデルキャパシティへの共有入口となるため、このデフォルトには注意が必要だ。認可されていない呼び出し元でも、管理APIにアクセスせずにGPU時間を消費できる。

プライベートネットワーキングは露出を減らすが、ワークロードIDの代替にはならない。内部的なミス、侵害されたサービス、過度に広いネットワークアクセスは依然としてリスクを生む。

組織は認証を、後から行う強化策ではなく初期デプロイメントの一部として扱うべきである。また、モデルとテナント間の認可境界も定義する必要がある。

共有エンドポイントは効率を生む一方、所有権を曖昧にする可能性がある。複数のアプリケーションが同じプールまたはクラスタリソースを取り合えば、あるアプリケーションの急増が別のアプリケーションに影響する可能性がある。

そのため、レート制限とクォータはインテリジェントな配置と並んで必要になる。ローカルゲートウェイは最も健全なPodを選べるが、誰が作業を送信してよいかを定めるルールも必要である。

Transport Layer Securityにも意図的な設定が求められる。AWSは、デプロイメント設定に統合された証明書を使い、ゲートウェイ経由でTLSを終端する方法を文書化している。

チームは証明書の発行、ローテーション、信頼を適切に管理しなければならない。Kubernetesネイティブな設定はこれらを宣言的にするが、自己検証可能にするわけではない。

可観測性にも同様の要件がある。運用者には、外部リクエストごとに、選択されたモデル、プール、Podを結び付けるトレースまたはログが必要である。

この記録がなければ、実際の原因がルーティングスコアや古いメトリクスであるにもかかわらず、レイテンシーの急上昇がエンジン障害に見えることがある。

共有ルーティングは、設定ミスの影響範囲も広げる。誤ったモデルマッピングは、1つのエンドポイントを通じて複数のクライアントに影響し得る。

宣言的リソースは、特にチームがGitOpsを利用する場合にロールバックを容易にする。一方で、誤った変更を環境全体へ一貫して伝播させることもある。

プラットフォームチームは、受け入れ前に設定を検証すべきである。ポリシーは認証設定、モデルセレクター、名前空間、許可されるゲートウェイ公開範囲を確認できる。

ゲートウェイの標準HTTPインターフェースは、クライアントにとって移行コストを下げる。この利便性によって、チームが新たなリクエスト経路の脅威モデリングを省略すべきではない。

AWSは、クラスタ間およびリージョン間の調整を担うGlobal Inference Routerも計画している。発表によれば、この第2層は後日提供される予定である。

計画中のレイヤーには、フェイルオーバー、グローバルなレート制限、コスト認識型のトラフィックシェーピングが含まれる。これらの機能は、より広範なポリシーおよびデータルーティング上の問題を導入することになる。

リージョン間ルーティングは可用性を改善できるが、プロンプトを法的管轄や組織の境界を越えて移動させる可能性もある。今後のデプロイメントには明示的なローカリティ制御が必要になる。

コスト認識型ルーティングには別のトレードオフもある。より安価なキャパシティへ作業を送ることで、ネットワーク距離やユーザーレイテンシーが増す可能性がある。

現行リリースは、Tier 1が各クラスタ内で動作するため、この複雑さの一部を回避している。ローカル環境であっても、チームは本番トラフィックの到来前にID、分離、テレメトリーを検証しなければならない。

ゲートウェイの効果を示す3つのシグナル

次の段階は、別の機能発表ではない。多様な本番条件下でもルーティングレイヤーが有用であり続けるという証拠である。

第1のシグナルは、独立したベンチマークデータだ。チームには、モデルサイズ、コンテキスト長、同時実行レベル、ハードウェアタイプ、キャッシュ再利用パターンを横断した結果が必要である。

有用な比較には、ラウンドロビン、最少接続数、GPU認識型ルーティングを含めるべきだ。エンジンバージョンとレプリカ数は一定に保つ必要がある。

ベンチマークでは、最初のトークンが返るまでの時間の中央値とテール値を報告すべきである。また、トークン間レイテンシー、スループット、エラー、アクセラレーター使用率も含める必要がある。

独立テストが現実的なバーストトラフィックでAWSの見出しの改善幅に近づけば、推論認識型ルーティングの根拠ははるかに強くなる。改善が小さい、または一貫しない場合は、その対象市場が狭まる。

第2のシグナルは、モデルサーバーをまたぐ運用導入である。AWSは現在、vLLMおよびSGLangの互換性要件を文書化する一方、より広範なOpenAI互換インターフェースを推進している。

本番レポートでは、エンジンをまたいでメトリクスが信頼できる状態を保つかを示すべきである。また、各ワークロードにどれほどのカスタム調整が必要かも明らかにすべきだ。

複数のサーバーにわたって低負荷で導入できれば、AWSの抽象化に関する主張を裏付ける。エンジン固有のトラブルシューティングが必要なら、共通ゲートウェイが依然としてバックエンドの複雑さを漏らしていることになる。

ここではリリースの成熟度も重要である。アドオンのリリースノートでは、バージョン2.0.0-eksbuild.2がゲートウェイの導入版として示されている。

チームは、その後のリリースで互換性修正、メトリクス修正、認証改善、設定変更を注視すべきである。初期のメンテナンス傾向は、実際の運用負担を明らかにすることが多い。

第3のシグナルは、計画されているGlobal Inference Routerの提供である。Tier 1はクラスタ内の配置を改善するが、大規模サービスはしばしば複数のクラスタとリージョンにまたがる。

グローバルレイヤーは、健全性、キャパシティ、コスト、ローカリティを用いてルーティング判断を行わなければならない。また、リージョンの問題をフリート全体の障害に変えずに実行する必要がある。

カナリアトラフィック分割と優先度ベースのフロー制御もAWSのロードマップに含まれている。これらの機能により、ゲートウェイはPod選択から、より広範な推論トラフィック管理へと進むことになる。

提供が成功すれば、AWSのプラットフォーム管理型アプローチは強化される。度重なる遅延があれば、顧客はグローバルルーティング、クォータ、ロールアウト制御を別の場所で組み立て続けることになる。

したがって、Amazon SageMaker HyperPod Inference Gatewayの導入は、単なる高速なロードバランサー以上の意味を持つ。これは、モデル認識型ルーティングをマネージドKubernetesインフラの一部にしようとするAWSの試みである。

この仕組みは、汎用的な負荷分散とステートフルな言語モデルサービングの間にある現実的な不一致に対応する。その価値は、測定可能な改善、信頼できるシグナル、規律あるセキュリティ設定に左右される。

ゲートウェイを評価するインフラチームは、代表的なモデル1つと再現可能なトラフィックプロファイルから始めるべきである。ルーティングポリシーを比較し、すべての選択シグナルを検査し、アクセスを拡大する前に認証をテストする。

そのうえで決定的な問いを投げかけるべきだ。最悪のバースト時にもテールレイテンシーを維持しながら、ゲートウェイは総キャパシティへの負荷を減らせるのか。この答えは、最も強いベンチマーク数値より重要である。