AWS、HyperPodのモデルキャッシュとプレフィックスルーティングでSageMaker推論の遅延に対処
AWSは、SageMaker HyperPodにモデルキャッシュを、SageMaker Inferenceにプレフィックス対応ルーティングを追加し、より速いスケールアウトとLLMの低遅延を狙う。
AWSは、大規模言語モデルの配信における別々だが関連するボトルネックを狙った2つのインフラ機能を追加している。Amazon SageMaker HyperPod向けのモデルキャッシュと、SageMaker Inference向けのプレフィックス認識ルーティングだ。前者は新しい推論Podをオンラインにするまでの時間を短縮することを目的とし、後者は頻繁に再利用されるプロンプト計算を同じインスタンスに保持することで応答レイテンシを下げることを狙っている。
この変更が特に重要なのは、変動のあるトラフィック下で大規模モデルを運用するチームだ。キャッシュがなければ、スケールアウトイベントのたびに新しいノードが数ギガバイト規模のコンテナイメージとモデル重みをダウンロードし、リクエストを処理できるようになるまで待つ必要がある。プロンプト内容を考慮しないルーティングでは、同一プロンプト部分がフリート全体に分散されるため、サービングフレームワークのプレフィックスキャッシュが十分に活用されないままになる可能性がある。
どちらの発表もAWS Machine Learning Blogに基づいているため、性能数値や運用上の主張はAWSによる報告であり、独立検証されたものではない。両者を合わせると、推論のコールドスタートと定常状態での最初のトークンまでの時間の両方を減らす、より協調的なアプローチが示されている。
HyperPodキャッシュがスケールアウトのギャップを埋める
AWSによれば、SageMaker HyperPodでのモデル展開は2段階の連続したダウンロードによって遅れる可能性がある。KubernetesはまずAmazon Elastic Container Registryから推論サーバーイメージを取得し、その後サーバーがAmazon S3、Amazon FSx for Lustre、Hugging Face Hub、JumpStartなどのソースからモデル重みをダウンロードする。
小規模モデルなら、この処理には数分かかる場合がある。AWSは、145 GBのモデルの例として、ネットワーク条件にもよるがAmazon S3からの重みダウンロードに20分以上かかる可能性を挙げている。DeepSeek-R1のように、引用されたシナリオでAWSが600 GB超と説明するモデルでは、30分以上かかることもある。コンテナイメージのプルだけでも、典型的な数ギガバイト規模の推論イメージでは5〜7分とAWSは見積もっている。
この遅延は、オートスケーリングと実際のキャパシティの間にずれを生む。HorizontalPodAutoscalerは追加Podをすぐ要求できるが、それらのPodはイメージと重みが利用可能になるまでトラフィックを受け付けられない。したがって、急なリクエスト急増に対する運用上の対応が、数十分遅れて届くことになりうる。
新しいモデルキャッシュ機能は、対象ノードのローカルNVMeストレージに重みを事前配置する。AWSによると、HyperPod Inference Operatorは事前に重みをダウンロードし、ノードをキャッシュ準備済みとしてマークし、対象ノードがその処理を完了するのを待ってから推論デプロイメントを作成する。準備済みノード上でPodが起動すると、モデルをネットワーク経由でダウンロードする代わりに、約7 GB/秒でローカル読み取りができる。
AWSは独立したイメージキャッシュも提供している。DaemonSetが推論コンテナイメージをノードへ事前プルし、後続のPodがAmazon Elastic Container Registryからのダウンロードを省略できるようにする。同じイメージを使う複数のデプロイメントはこのキャッシュを共有でき、オペレーターが参照管理とクリーンアップを担当する。
2つのキャッシュシステムが本番でどう動くか
重みキャッシュとイメージキャッシュは、デプロイメントのセマンティクスが同一ではない。AWSは、重みキャッシュはすべての対象ノードが準備できるまで推論デプロイメントの作成を遅らせる一方、イメージキャッシュはデプロイメント作成をブロックしないと説明している。したがって、あるノードでイメージキャッシュが完了する前にPodが起動し、通常のイメージプルにフォールバックすることもある。
どちらの仕組みも、必須ではなく優先度付きのスケジューリングを使う。Podは可能であればウォームなデータを持つノードへ誘導されるが、他で動作することは妨げられない。急速なスケールアウトが準備済みノード数を超えた場合、Podは元のモデルソースを使い、通常どおりイメージを取得できる。トレードオフはデプロイ失敗ではなく、起動が遅くなることだ。
オペレーターは、モデル重み用のModelDataCacheConfigとコンテナイメージ用のModelImageCacheという2つの基盤となるカスタムリソースを管理する。ユーザーは、これらのライフサイクルオブジェクトを直接管理するのではなく、InferenceEndpointConfigまたはJumpStartModelリソース内のmodelCacheConfigでキャッシュを有効化する。
AWSは、モデルソースやイメージが変更された際のキャッシュ更新も処理されると述べている。オペレーターは新しいキャッシュを作成し、更新されたデプロイメントを展開してから古いキャッシュを削除する。これは、古い重みを防ぎつつゼロダウンタイム移行を支えることを意図しているが、実際の結果は依然としてノードの空きストレージや、代替キャッシュを埋めるのに必要な時間に左右される。
プレフィックス認識ルーティングがLLMプロンプトキャッシュを有効に保つ
2つ目のSageMaker変更は、サービングスタックの別の層を狙っている。多くのLLMリクエストは、システム指示、取得した文書、会話履歴、ソースコードなどの長く繰り返されるプレフィックスと、その後に続く短いユーザー固有のサフィックスを含む。vLLMやTensorRT-LLMのようなフレームワークは、その繰り返しプレフィックスに対して計算済みのキー・バリュー、すなわちKVキャッシュを再利用できる。
リクエストをランダムに分散すると、マルチインスタンスのエンドポイントではこの利点が弱まる。同じプレフィックスを持つ連続したリクエストが異なるマシンに届くと、各インスタンスが共有コンテキストを再計算しなければならない場合がある。SageMaker Inferenceの新しいプレフィックス認識ルーティング戦略は、リクエストの先頭を調べ、一致するプレフィックスを一貫して同じインスタンスへ送る。
AWSによると、この機能は過度に人気のあるプレフィックスからフリートを守ることもできる。優先インスタンスが設定済みの同時実行上限に達した場合、リクエストはより空いているインスタンスへ転送できる。1件のリクエストではキャッシュヒットを失うかもしれないが、トラフィックが1台に集中するのを避けられる。AWSはさらに、インスタンスの追加や削除によって移動するトラフィックは限定的であり、スケーリング時のキャッシュ局所性の維持に役立つと述べている。
この戦略は本番バリアントごとに設定でき、モデルを再デプロイせずにエンドポイント設定から変更可能だ。AWSは引き続きデフォルトとしてランダムルーティングを提供し、リクエスト時間が変動するワークロード向けに最小未処理リクエストルーティングも提供している。プレフィックス認識ルーティングは、共有された先頭コンテキストと有効化されたプレフィックスキャッシュを持つLLMワークロード向けに特化している。
エビデンス、ベンチマーク、制限
AWSは、vLLMとプレフィックスキャッシュを有効にした7台のml.p5.48xlargeインスタンス上で、Llama 3.1 70B Instructを使い、プレフィックス認識ルーティングとランダムルーティングを比較ベンチマークした。異なるエンドポイントとAPI構成をカバーする16のテスト設定全体で、AWSは中央値の最初のトークンまでの時間を最大77%短縮、スループットを最大16%向上、KVキャッシュヒット率を約25%から80%以上へ増加させたと報告している。
これらはベンダー報告のベンチマーク結果であり、独立評価ではない。AWSによれば、テスト中のトラフィックは均衡しており、各インスタンスが13.3%〜15.4%のリクエストを受け取った。また、テスト構成ではモデルの最初のトークンまでの時間が63〜280ミリ秒だったのに対し、ルーティングの追加コストは1リクエストあたり1.3〜1.9ミリ秒と報告している。
効果の大きさはワークロードの形状に大きく依存する。AWSは、共有プレフィックスが長いほど、より多くの計算を省けるため、より大きな利益が得られると述べている。AWSが挙げるユースケースには、同じ文書を繰り返し問い合わせるRAGシステム、複数ターン会話、テンプレート型アシスタント、コード補完が含まれる。短い、またはほぼ一意のプロンプトを持つワークロードでは価値が小さい。
HyperPodの主張も、ノードの可用性、キャッシュ投入時間、ストレージ容量、モデル形式、初期プリロード時のネットワーク性能など、ソースで完全には明示されていない条件に依存する。数十分から数秒への移行は、Podが関連データをすでにキャッシュしているノードに着地した場合に当てはまる。準備されていないノードでは通常のダウンロード経路をたどる。
AIインフラチームにとって何を意味するか
ビルダーやエンタープライズのプラットフォームチームにとって、今回の発表はしばしば1つのレイテンシ問題として扱われる2つの判断を分けている。モデルキャッシュはエラスティシティを改善し、トラフィック増加時に新しいキャパシティをより早く有用にできる。プレフィックス認識ルーティングはリクエスト効率を改善し、容量がすでにオンラインになった後の繰り返しprefill作業を減らせる。
この組み合わせは、バースト的なトラフィックと大きな繰り返しコンテキストの両方を持つRAGアプリケーションやアシスタントに役立つ可能性がある。チームはHyperPodキャッシュを使ってスケールアウト用のノードを準備しつつ、プレフィックス認識ルーティングで文書や会話のプレフィックスをアクティブなフリート全体で温かく保てる。とはいえ、ローカルNVMe容量の見積もり、同時実行上限の設定、実トラフィックでのキャッシュヒット率測定の必要性はなくならない。
購入者が検証すべきコストと信頼性の問題もある。各対象ノードに重みを保持するとローカルストレージを消費し、デプロイメントが準備完了になる前の準備時間が増える可能性がある。プレフィックスアフィニティはレイテンシを改善しうるが、内容依存のルーティング動作を導入するため、チームはキュー深度、インスタンス利用率、キャッシュ占有率、テールレイテンシとあわせて観測すべきだ。AWSが自動でルーティングを処理していても、ルーティング判断がリクエストペイロードの先頭を検査するため、プライバシーやデータガバナンスのレビューも重要になる可能性がある。
次に注目すべき点
これらの機能を評価するチームは、AWSのLlama 3.1 70Bテストを超えて、モデル、ハードウェア、プロンプト分布について独立に再現された結果を探すべきだ。特に有用な指標は、p95およびp99の最初のトークンまでの時間、スケールアウト中のキャッシュヒット率、そして準備されていないノードに着地するリクエストの割合だ。
ローカルNVMeのサイズ設計、キャッシュのウォームアップオーケストレーション、マルチモデルクラスターに関する運用ガイダンスも重要になる。購入者は、キャッシュ準備がデプロイメントのロールアウト、ノード交換、スポットまたは中断シナリオ、事前ロード済みフリートを超える急速なスケーリングにどう影響するかを確認すべきだ。
最後に、ホスト型のサービングプラットフォームがモデルへのアクセスそのものよりも予測可能なレイテンシで競争するにつれ、AWSのエンドポイントレベルのルーティング制御はより重要になるかもしれない。注目すべきシグナルは、これらの制御を大きなスケジューリング複雑性を追加したり、バランスの取れたGPU利用を犠牲にしたりせずに使えるかどうかだ。
Creati.aiの見解
AWSは、新しいモデル機能を導入するのではなく、LLM運用における2つの実用的な弱点に対処している。HyperPodのモデルキャッシュはキャパシティ追加のペナルティを減らし、プレフィックス認識ルーティングは既存のサービング最適化であるKVキャッシュ再利用を複数インスタンスにまたがってより確実にする。
最も強いユースケースは、大きなモデルの事前ロードを正当化できるだけのトラフィックがある、予測可能でコンテキストが繰り返されるワークロードだ。主に一意のプロンプトや頻繁でないデプロイメントを扱うチームでは、ストレージと準備のオーバーヘッドが利益を上回るかもしれない。AWSのベンチマーク数値は好意的だが、インフラ購入者は、キャッシュを保証された改善とみなす前に、自社のプロンプト重複、スケーリングパターン、レイテンシ目標に照らして検証すべきだ。
