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

# モデルの重みキャッシュとイメージキャッシュ
<a name="sagemaker-hyperpod-model-deployment-model-caching"></a>

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

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

モデルの重みキャッシュ (`weightsCache`)  
対象となる各ノードのホストローカル NVMe ストレージにモデル重みファイルを事前に入力します。同じノード上の推論ポッドは、リモートモデルソースからダウンロードするのではなく、ローカルストレージから重みをロードするため、ポッド間で冗長なダウンロードがなくなります。

イメージキャッシュ (`imageCache`)  
推論サーバーのコンテナイメージをターゲットノードにプリプルし、コールドイメージのプルを待たずに新しいポッドを起動できるようにします。

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

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

## 前提条件
<a name="sagemaker-hyperpod-model-deployment-model-caching-prereqs"></a>

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

ローカル NVMe ストレージを使用するインスタンスタイプ  
モデル重みキャッシュは、ホストローカル NVMe ストレージ (`/opt/dlami/nvme`デフォルトでは ) に重みを保存します。インスタンスタイプは、設定された でローカル NVMe ストレージを提供する必要があります`hostPath`。

十分な NVMe 容量  
ノードにモデル用の十分なローカルストレージがあることを確認します。各デプロイは独自の分離されたキャッシュディレクトリを使用するため、同じノード上の複数のキャッシュされたデプロイはそれぞれ独自のストレージを消費します。

推論演算子  
クラスターには、モデルキャッシュをサポートするバージョンの HyperPod Inference 演算子が必要です。`modelCacheConfig` フィールドが認識されない場合は、推論演算子アドオンを最新バージョンに更新します。

**重要**  
インスタンスタイプに設定された にローカル NVMe ストレージがない場合`hostPath`、モデルの重みキャッシュはキャッシュをウォームアップせず、推論ポッドはリモートモデルソースからの重みのダウンロードにフォールバックします。この機能を有効にする前に、インスタンスタイプがローカル NVMe ストレージを提供していることを確認します。

## モデルの重みキャッシュとイメージキャッシュを設定する
<a name="sagemaker-hyperpod-model-deployment-model-caching-configure"></a>

`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 | false | ホストローカルモデルの重みキャッシュを有効にするかどうか。の場合true、オペレーターはホストローカルストレージにモデル重みを事前に入力し、推論ポッドにマウントします。 | 
| weightsCache.hostPath | /opt/dlami/nvme | キャッシュされたモデルの重みが保存されるホストパス。空でない絶対パスは最大 255 文字にする必要があります。 | 
| imageCache.enabled | false | コンテナイメージキャッシュが有効になっているかどうか。の場合true、オペレーターは推論サーバーのコンテナイメージをターゲットノードに事前にプルします。 | 

## モデルの重みキャッシュの仕組み
<a name="sagemaker-hyperpod-model-deployment-model-caching-weights"></a>

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

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

分離  
各デプロイでは、設定された の下に独立したデプロイごとのキャッシュディレクトリを使用するため`hostPath`、同じノード上の複数のモデルデプロイが相互に干渉することはありません。

キャッシュミスフォールバック  
キャッシュがまだ利用できないノードでポッドがスケジュールされている場合、デプロイはリモートモデルソースから直接モデルの重みをロードすることにフォールバックするため、ウォームキャッシュがない場合でもデプロイは機能し続けます。

ノード置換  
ノードが置き換えられた場合 (障害後など）、オペレータはポッドを優先的にスケジュールする前に、新しいノードのキャッシュを再度ウォームする必要があります。既存のウォームノードは、その間もトラフィックを処理し続けます。

削除時のクリーンアップ  
デプロイを削除すると、オペレータは入力したノードからキャッシュされた重みファイルを削除します。

## イメージキャッシュの仕組み
<a name="sagemaker-hyperpod-model-deployment-model-caching-image"></a>

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

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

## キャッシュが機能していることを確認する
<a name="sagemaker-hyperpod-model-deployment-model-caching-verify"></a>

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

### ウォームキャッシュのノードラベルを確認する
<a name="sagemaker-hyperpod-model-deployment-model-caching-verify-labels"></a>

ノードのキャッシュがウォームになると、オペレータはキャッシュ対応ラベルを適用します。モデルの重みキャッシュでは、プレフィックス のラベルを使用し`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"
```

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

### キャッシュマウントのポッドイベントを確認する
<a name="sagemaker-hyperpod-model-deployment-model-caching-verify-pod"></a>

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

```
kubectl describe pod {{inference-pod-name}} -n {{namespace}}
```

### オペレーターログを確認する
<a name="sagemaker-hyperpod-model-deployment-model-caching-verify-logs"></a>

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

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

## トラブルシューティング
<a name="sagemaker-hyperpod-model-deployment-model-caching-troubleshooting"></a>


| 症状 | 考えられる原因 | 解決策 | 
| --- | --- | --- | 
| キャッシュが有効になっている場合でも、ポッドはゆっくりと起動します。 | NVMe パスがインスタンスタイプに存在しません。 | インスタンスタイプにローカル NVMe ストレージがあり、実際のマウントポイントhostPathと一致することを確認します。 | 
| キャッシュがウォームアップされることはありません。 | ホストパスのディスク容量が不十分です。 | で使用可能な容量を確認しますhostPath。大規模なモデルでは、大量のローカルストレージが必要になる場合があります。 | 
| キャッシュ対応としてラベル付けされたノードはありません。 | キャッシュのダウンロードが失敗したか、リモートソースにアクセスできません。 | ダウンロードエラーがないかオペレータログをチェックし、Amazon S3 または Amazon FSx へのネットワークアクセスを確認します。 | 
| 複数のデプロイにより、ノードにディスク負荷が発生します。 | キャッシュされたデプロイは、同じノードの NVMe ストレージを共有します。 | 個別のインスタンスグループを使用するか、ノードあたりの同時キャッシュデプロイの数を減らします。 | 

## 考慮事項
<a name="sagemaker-hyperpod-model-deployment-model-caching-considerations"></a>
+ モデルの重みキャッシュには、ローカル NVMe ストレージを持つインスタンスタイプが必要です。EBS 専用インスタンスはサポートされていません。
+ キャッシュ可能なモデルの最大サイズは、インスタンスタイプの使用可能な NVMe 容量によって制限されます。
+ キャッシュのウォームアップ時間は、モデルサイズとリモートモデルソースへのネットワークスループットによって異なります。