Amazon SageMaker HyperPodで「モデルキャッシング」が提供開始、大規模モデルの推論起動時間を数十分から数秒へ短縮

要点

• 米AWSは、機械学習クラスタ環境「Amazon SageMaker HyperPod」の推論向け新機能「モデルキャッシング」の提供を開始した。

• コンテナイメージとモデル重みをクラスタノードの高速なローカルNVMeストレージへ事前配置し、ネットワーク経由のダウンロード遅延を排除する。

• 起動に30分以上を要していた600GB超の大規模言語モデルでも、Pod起動からリクエスト受付開始までの時間を数秒へと大幅に短縮できる。

• 急な負荷増加に伴うオートスケーリング時にも、ノードごとに発生していたダウンロード待ち時間をなくし、迅速なトラフィック処理を可能にする。

• 米Amazon Web Services（AWS）は2026年9月10日（現地時間）、機械学習専用クラスタサービス「Amazon SageMaker HyperPod」の推論向け新機能として「モデルキャッシング（model caching）」の提供を開始したと公式ブログで公表した。大規模言語モデル（LLM）の推論用Podを起動する際、あらかじめコンテナイメージやモデル重みデータをクラスタノード上に事前ロードしておくことで、初期起動にかかる待機時間を従来の数十分からわずか数秒へと劇的に短縮できるとしている。

大規模モデルのデプロイを阻む「コールドスタート」の要因

近年の大規模言語モデルの肥大化に伴い、推論環境の立ち上げ時に発生する「コールドスタート（停止状態や新規リソースから処理可能な状態へ立ち上げる初期化遅延）」は、運用上の大きな課題となっている。AWSの説明によると、Amazon SageMaker HyperPod（大規模な機械学習ワークロード向けに最適化された専用クラスタ環境）において推論用Pod（Kubernetesでコンテナを実行・管理する最小単位）を要求してから実際にリクエストを処理できるようになるまでには、常に大きな時間差が生じていたという。

この待機時間の大半は、直列で実行される2つの大容量ダウンロード処理によって占められている。1つ目は、コンテナイメージをAmazon ECR（Amazon Elastic Container Registry：AWSが提供するフルマネージド型のコンテナレジストリ）から取得する処理である。vLLMやLMI（LLMの高速な推論実行に特化したサービングフレームワーク）といった推論サーバー用のコンテナイメージには、GPUドライバやCUDAライブラリ、各種フレームワークがバンドルされており、イメージサイズは数ギガバイトに達する。そのため、Kubernetesのkubeletがイメージを取得するだけでも5分から7分程度の時間を要していた。

2つ目は、コンテナ起動後に実行されるモデル重みデータのダウンロード処理である。モデルの保存先としてはAmazon S3（Simple Storage Service）をはじめ、Amazon FSx for LustreやHuggingFace Hubなどが利用される。容量が145GB程度のモデルであっても、Amazon S3からのダウンロードにはネットワーク環境や利用可能帯域によって20分以上かかる場合がある。さらに、パラメータ規模が大きい「DeepSeek-R1」のような600GBを超えるモデルになると、1つのPodが最初のリクエストを受け付けられる状態になるまでに30分以上の時間を要していたという。

オートスケーリング時のボトルネックとトラフィック急増への影響

このダウンロード処理に伴う遅延は、初回デプロイ時だけでなく、クラスタの負荷変動に応じて自動でリソースを増減させるスケールアウト時にも深刻な影響を及ぼす。

例えば、急激なトラフィック増加が発生し、HorizontalPodAutoscaler（負荷に応じてKubernetesのPod数を自動で増減させる機能）が新規に5つのPodを要求した場合、追加された5つのPodのすべてが独立してコンテナイメージの取得とモデル重みデータのダウンロードを最初から実行する。

オートスケーリングのポリシー自体は負荷を検知して数秒でスケールアウトの判定を下すことができるものの、実際に新しいPodが追加トラフィックの処理を開始できるようになるまでには25分から30分以上の待機時間が発生してしまう。このように、急増するアクセスに対する自動拡張の応答速度が、ストレージバックエンドへのネットワークスループットによって厳しく制限される構造になっていたとAWSは指摘している。

ローカルNVMeストレージを活用した「モデルキャッシング」の構造

今回発表された「モデルキャッシング」は、PodがKubernetesスケジューラによってノードに割り当てられる前に、必要なコンテナイメージとモデル重みデータを各クラスタノードへ事前に配置（プレロード）しておくことで、これらのネットワーク遅延を根本から解消する仕組みである。

モデルキャッシングを有効化すると、Podの起動時にネットワーク越しの大容量ダウンロードを行う必要がなくなる。代わりに、各ノードに搭載された高速なローカルNVMe（高速なデータ転送を実現するSSD向け接続規格）ストレージから、毎秒約7GB（7 GB/s）の高速なスループットでデータを直接読み出せるようになる。

これにより、これまで数十分を要していたPodの初期化処理が劇的に高速化され、設定完了後はわずか数秒で推論トラフィックの処理を開始できるようになるとしている。

キャッシュ機能の構成と有効化の手順

モデルキャッシングには独立した2つの機能が用意されており、用途に応じて両方を組み合わせて利用することも、個別に有効化することも可能となっている。

そのうちの1つである「重みキャッシュ（Weights cache）」は、モデルの重みデータを各ノードのローカルNVMeストレージにあらかじめダウンロードしておく機能である。利用者は、推論エンドポイントの設定（InferenceEndpointConfig）において modelCacheConfig を追加し、weightsCache を有効に設定することで本機能を利用できるとしている。

これにより、Amazon S3、Amazon FSx for Lustre、HuggingFace Hubなどの外部ストレージに配置されたモデルデータをクラスタノード上で効率的にキャッシュし、推論インフラの即応性を高めることが可能となる。