AWSは2026年9月10日、Amazon SageMaker Inference on HyperPod向けにモデルキャッシュを開始した。大規模言語モデルを推論用に展開する際のコールドスタートを減らす機能で、モデル重みと推論サーバーのコンテナイメージを、ポッドがトラフィックを処理する前にクラスターノードへ事前配置する。繰り返しのネットワークダウンロードは、約7 GB/sのローカルNVMeストレージ読み込みに置き換わり、AWSによればキャッシュ有効化後のポッドは通常、数十分ではなく数秒でトラフィック処理を始められる。

キャッシュがない場合、HyperPodの推論ポッドはリクエスト処理前に2つのダウンロードを順番に待つ。まずKubeletがvLLMやLMIなど数GB規模の推論サーバーイメージをAmazon ECRから取得し、AWSによればこの工程に5〜7分かかる。次に推論サーバーがAmazon S3、Amazon FSx for Lustre、HuggingFace Hubからモデル重みをダウンロードする。Amazon S3上の145 GBモデルではさらに20+分、DeepSeek-R1のような600+ GBモデルでは30分超かかる場合がある。

同じ遅延はスケールアウト時にも繰り返される。トラフィック急増後にHorizontalPodAutoscalerが5つの新規ポッドを要求すると、5つのポッドすべてがリクエスト処理前にそれぞれイメージと重みを取得する。AWSは、オートスケーリングポリシー自体は数秒で反応しても、各新規ポッドがダウンロードを待つため、実際に追加の処理能力が届くのは25〜30+分後になり得るとしている。

モデルキャッシュには、weights cacheとimage cacheという2つの独立した選択肢がある。weights cacheは、ユーザーがInferenceEndpointConfigまたはJumpStartModelリソースにweightsCacheを有効化したmodelCacheConfigを追加すると、対象ノードごとのローカルNVMeストレージへモデル重みをダウンロードする。HyperPod Inference OperatorはModelDataCacheConfigリソースを作成し、Amazon S3、Amazon FSx for Lustre、HuggingFace Hub、JumpStartから重みを取得し、ノードにcache-readyラベルを付け、全対象ノードを待ってから推論デプロイメントを作成する。

image cacheは、ユーザーがmodelCacheConfigでimageCacheを有効化した後、推論サーバーのコンテナイメージをノードへ事前取得する。オペレーターはイメージ取得のためDaemonSet（選択ノードごとに1つのポッド）を作成するが、weights cacheと異なり推論デプロイメントはただちに作成する。キャッシュ済みイメージを持つポッドはAmazon ECRからの取得を省き、5〜7分を節約する。キャッシュ完了前に起動したポッドは通常どおりECRから取得する。

AWSによれば、2つのキャッシュ方式はいずれも必須スケジューリングではなく優先スケジューリングを使う。ポッドはキャッシュ済みデータを持つノードを優先するが、急速なスケールアウト時にスケジューラーがウォームキャッシュのないノードへ配置してもブロックされない。その場合、ポッドは元のAmazon S3またはAmazon FSxソースから重みを読み込み、Amazon ECRからイメージを取得し、通常の非キャッシュ動作と同じになる。

オペレーターは2つのCustom Resource Definition、すなわちCRD（Kubernetes拡張オブジェクト）でキャッシュを管理する。ModelDataCacheConfigはモデル重みのダウンロード、cache-readyラベル、キャッシュの健全性、親リソース削除時のクリーンアップを管理する。ModelImageCacheはイメージの事前取得、image-readyラベル、ノードごとの取得状態、デプロイメント間で共有されるイメージキャッシュ参照、どのデプロイメントからも参照されなくなった場合のクリーンアップを扱う。

AWSは57〜145 GBのモデルでベンチマークを実施し、weights caching有効時にスケールアウトが約60 percent高速化したと報告した。image cacheは2分超のコールドイメージ取得時間を取り除き、各ポッド起動時にECRから新規取得する場合と比べて通常は最大97 percentの削減を達成した。DeepSeek-R1のような600 GB超のモデルでは、キャッシュによって30分超のダウンロードを不要にするとAWSは述べている。

モデルキャッシュはAmazon S3、Amazon FSx for Lustre、HuggingFace Hub、Amazon SageMaker JumpStartの非ゲート付きモデル、Amazon SageMaker JumpStartのゲート付きモデルで動作する。AWSはNVMeストレージ例として、ml.g5.xlargeは250 GB、ml.g5.12xlargeは3,800 GB、ml.g5.48xlargeは7,600 GB、ml.p4d.24xlargeは8,000 GB、ml.p5.48xlargeは30,000 GBを挙げた。

AWSはローカルストレージとキャッシュ鮮度に関する制限も示した。weights cacheはノード単位のため、NVMe使用量はノード数に応じて増える。初回のキャッシュ作成には依然として1回のリモートダウンロードが必要で、300 GBモデルは250 GBのNVMeしかないインスタンスにはキャッシュできない。同じAmazon S3パスでファイルが変更されても、InferenceEndpointConfigのspec更新がなければソース更新は自動検出されない。モデルキャッシュは、Amazon SageMaker HyperPodを利用できるすべてのリージョンで一般提供されている。

AWSは2026年9月10日、Amazon SageMaker Inference on HyperPod向けにモデルキャッシュを開始した。大規模言語モデルを推論用に展開する際のコールドスタートを減らす機能で、モデル重みと推論サーバーのコンテナイメージを、ポッドがトラフィックを処理する前にクラスターノードへ事前配置する。繰り返しのネットワークダウンロードは、約7 GB/sのローカルNVMeストレージ読み込みに置き換わり、AWSによればキャッシュ有効化後のポッドは通常、数十分ではなく数秒でトラフィック処理を始められる。

キャッシュがない場合、HyperPodの推論ポッドはリクエスト処理前に2つのダウンロードを順番に待つ。まずKubeletがvLLMやLMIなど数GB規模の推論サーバーイメージをAmazon ECRから取得し、AWSによればこの工程に5〜7分かかる。次に推論サーバーがAmazon S3、Amazon FSx for Lustre、HuggingFace Hubからモデル重みをダウンロードする。Amazon S3上の145 GBモデルではさらに20+分、DeepSeek-R1のような600+ GBモデルでは30分超かかる場合がある。

同じ遅延はスケールアウト時にも繰り返される。トラフィック急増後にHorizontalPodAutoscalerが5つの新規ポッドを要求すると、5つのポッドすべてがリクエスト処理前にそれぞれイメージと重みを取得する。AWSは、オートスケーリングポリシー自体は数秒で反応しても、各新規ポッドがダウンロードを待つため、実際に追加の処理能力が届くのは25〜30+分後になり得るとしている。

モデルキャッシュには、weights cacheとimage cacheという2つの独立した選択肢がある。weights cacheは、ユーザーがInferenceEndpointConfigまたはJumpStartModelリソースにweightsCacheを有効化したmodelCacheConfigを追加すると、対象ノードごとのローカルNVMeストレージへモデル重みをダウンロードする。HyperPod Inference OperatorはModelDataCacheConfigリソースを作成し、Amazon S3、Amazon FSx for Lustre、HuggingFace Hub、JumpStartから重みを取得し、ノードにcache-readyラベルを付け、全対象ノードを待ってから推論デプロイメントを作成する。

image cacheは、ユーザーがmodelCacheConfigでimageCacheを有効化した後、推論サーバーのコンテナイメージをノードへ事前取得する。オペレーターはイメージ取得のためDaemonSet（選択ノードごとに1つのポッド）を作成するが、weights cacheと異なり推論デプロイメントはただちに作成する。キャッシュ済みイメージを持つポッドはAmazon ECRからの取得を省き、5〜7分を節約する。キャッシュ完了前に起動したポッドは通常どおりECRから取得する。

AWSによれば、2つのキャッシュ方式はいずれも必須スケジューリングではなく優先スケジューリングを使う。ポッドはキャッシュ済みデータを持つノードを優先するが、急速なスケールアウト時にスケジューラーがウォームキャッシュのないノードへ配置してもブロックされない。その場合、ポッドは元のAmazon S3またはAmazon FSxソースから重みを読み込み、Amazon ECRからイメージを取得し、通常の非キャッシュ動作と同じになる。

オペレーターは2つのCustom Resource Definition、すなわちCRD（Kubernetes拡張オブジェクト）でキャッシュを管理する。ModelDataCacheConfigはモデル重みのダウンロード、cache-readyラベル、キャッシュの健全性、親リソース削除時のクリーンアップを管理する。ModelImageCacheはイメージの事前取得、image-readyラベル、ノードごとの取得状態、デプロイメント間で共有されるイメージキャッシュ参照、どのデプロイメントからも参照されなくなった場合のクリーンアップを扱う。

AWSは57〜145 GBのモデルでベンチマークを実施し、weights caching有効時にスケールアウトが約60 percent高速化したと報告した。image cacheは2分超のコールドイメージ取得時間を取り除き、各ポッド起動時にECRから新規取得する場合と比べて通常は最大97 percentの削減を達成した。DeepSeek-R1のような600 GB超のモデルでは、キャッシュによって30分超のダウンロードを不要にするとAWSは述べている。

モデルキャッシュはAmazon S3、Amazon FSx for Lustre、HuggingFace Hub、Amazon SageMaker JumpStartの非ゲート付きモデル、Amazon SageMaker JumpStartのゲート付きモデルで動作する。AWSはNVMeストレージ例として、ml.g5.xlargeは250 GB、ml.g5.12xlargeは3,800 GB、ml.g5.48xlargeは7,600 GB、ml.p4d.24xlargeは8,000 GB、ml.p5.48xlargeは30,000 GBを挙げた。

AWSはローカルストレージとキャッシュ鮮度に関する制限も示した。weights cacheはノード単位のため、NVMe使用量はノード数に応じて増える。初回のキャッシュ作成には依然として1回のリモートダウンロードが必要で、300 GBモデルは250 GBのNVMeしかないインスタンスにはキャッシュできない。同じAmazon S3パスでファイルが変更されても、InferenceEndpointConfigのspec更新がなければソース更新は自動検出されない。モデルキャッシュは、Amazon SageMaker HyperPodを利用できるすべてのリージョンで一般提供されている。