翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

モデルの重みキャッシュとイメージキャッシュ

推論デプロイをスケールアウトする場合、各新しいポッドはレジストリから推論サーバーコンテナイメージをプルする必要があります。また、トラフィックを処理する前に、リモートストレージ (Amazon S3 または Amazon FSx) からモデルの重みをダウンロードする必要があります。大規模言語モデルの場合、モデルの重みのダウンロードとコンテナイメージのプルは、コールドスタートレイテンシーに最も影響します。

スケールアウト中にこれらのボトルネックを排除するには、Amazon SageMaker HyperPod Inference で次のホストローカルキャッシュメカニズムの 1 つまたは両方を設定します。

両方のキャッシュメカニズムは、 InferenceEndpointConfigまたは JumpStartModelデプロイの modelCacheConfigフィールドを使用して設定します。

重みキャッシュとイメージキャッシュを個別に有効にすることも、一緒に有効にすることもできます。どちらの機能も、Amazon SageMaker JumpStart デプロイ (オープンウェイトモデルとゲートモデルの両方) や Amazon S3 または Amazon FSx のカスタムモデルなど、すべての Amazon SageMaker HyperPod Inference モデルソースで動作します。 Amazon S3 FSx

前提条件

キャッシュを有効にする前に、以下を確認してください。

モデルの重みキャッシュとイメージキャッシュを設定する

InferenceEndpointConfig または JumpStartModelリソースspecの にmodelCacheConfigブロックを追加します。次の例では、モデルの重みキャッシュとイメージキャッシュの両方を有効にします。

spec:
  # ... model source, worker, and TLS configuration ...
  modelCacheConfig:
    weightsCache:
      enabled: true
      hostPath: /opt/dlami/nvme
    imageCache:
      enabled: true

modelCacheConfig フィールドは、次のサブフィールドをサポートしています。

モデルの重みキャッシュの仕組み

weightsCache.enabled が の場合true、オペレータは推論ポッドがトラフィックの処理を開始する前に、リモートモデルソース (Amazon S3 または Amazon FSx) から各対象ノードのホストローカル NVMe ストレージにモデル重みをダウンロードします。推論ポッドは、キャッシュされた重みを読み取り専用でマウントし、リモートソースから繰り返しダウンロードするのではなく、ローカルストレージからモデルをロードします。

演算子は、推論デプロイのスケジュール制約に一致するノードにキャッシュを入力し、キャッシュがウォームになったときに各ノードにラベルを付けます。推論デプロイはこのラベルで優先ノードアフィニティを使用するため、ポッドは利用可能な場合はウォームノードにスケジュールされますが、他の場所でもスケジュールできます。

イメージキャッシュの仕組み

imageCache.enabled が の場合true、オペレータは推論サーバーコンテナイメージをターゲットノードに事前にプルします。イメージはノードに既に存在するため、新しい推論ポッドは、ポッドの起動を遅らせるコールドイメージのプルを回避します。これは、大規模な推論サーバーイメージや、頻繁にスケールアウトするデプロイに特に役立ちます。

イメージキャッシュは、モデルの重みキャッシュとは無関係です。単独で有効にすることも、重みキャッシュと組み合わせて、スケールアウト中のイメージプルと重みダウンロードの両方の時間を短縮することもできます。

キャッシュが機能していることを確認する

次のチェックを使用して、デプロイでキャッシュがアクティブであることを確認します。

ウォームキャッシュのノードラベルを確認する

ノードのキャッシュがウォームになると、オペレータはキャッシュ対応ラベルを適用します。モデルの重みキャッシュでは、プレフィックス のラベルを使用しinference.sagemaker.aws.amazon.com/weights-cache-ready.、イメージキャッシュではプレフィックス を使用します。各プレフィックスにはinference.sagemaker.aws.amazon.com/image-cache-ready.、キャッシュ設定の UID のサフィックスが付きます。

kubectl get nodes --show-labels | grep "cache-ready"

出力がないということは、まだノードがキャッシュをウォームアップしていないことを意味します。

キャッシュマウントのポッドイベントを確認する

推論ポッドを検査し、ホストローカルキャッシュパスが読み取り専用でマウントされていることを確認します。hostPath ボリュームがない場合、ポッドはリモートストレージから重みをロードしています。

kubectl describe pod inference-pod-name -n namespace

オペレーターログを確認する

推論演算子ログでキャッシュウォームアップアクティビティまたはエラーを確認します。

kubectl logs -n hyperpod-inference-system deployment/hyperpod-inference-controller-manager | grep -i "cache"

トラブルシューティング

考慮事項