Amazon SageMaker エンドポイントでのメモリ不足の問題を防止またはトラブルシューティングする方法を教えてください。

解決策

SageMaker エンドポイントでのメモリ不足の問題を防止またはトラブルシューティングするには、次の手順を実行します。

CPU ベースのモデル

CPU 上で動作し、エンドポイントのメモリに問題があるモデルをデプロイする場合は、次のベストプラクティスを使用します。

SageMaker 組み込みアルゴリズムコンテナを使用する場合は、model_server_workers パラメータを使用してワーカーの数を制限します。詳細については、SageMaker のウェブサイトで model_server_workers を参照してください。値は 1 から開始し、徐々に値を増やして、エンドポイントに設定できるワーカーの最大数を求めます。
注: model_server_workers の値を増やすと、作成されるモデルコピーの数も増えます。その結果、必要なメモリが増加します。

SageMaker のメモリ使用量を監視するには、Amazon CloudWatch を使用します。

エンドポイントのインスタンスタイプが 1 つのモデルコピーしか対応できない場合は、インスタンスタイプをメモリの多いタイプに増やします。詳細については、Amazon SageMaker 料金表を参照してください。

エンドポイントをテストし、呼び出しがローカルで実行されている間のメモリ使用量を監視するには、SageMaker ローカルモードを使用します。詳細については、SageMaker のウェブサイトで「ローカルモード」を参照してください。一貫した結果を得るには、ローカルテストに同じインスタンスタイプを使用する必要があります。

エンドポイント用の単一インスタンスのメモリを増やすことができない場合は、Auto Scaling を使用します。Auto Scaling では、ワークロードの需要に基づいてインスタンス数を自動的に調整するため、パフォーマンスとリソースの使用を最適化できます。詳細については、「Amazon SageMaker で自動スケーリングを使用して機械学習のデプロイを最適化する」を参照してください。

エンドポイントに必要なインスタンスタイプと設定を特定するには、推論レコメンダーを使用します。

GPU ベースのモデル

GPU 上で動作し、エンドポイントのメモリに問題があるモデルをデプロイする場合は、次のベストプラクティスを使用します。

モデルの重みの読み込みに必要な GPU メモリを計算するには、次の式を使用します。
Llama 2 13Bを実行する場合の例:

Model Size Calculation:
Parameters (13B) × 4 bytes (FP32) = 52 GB

Total Memory Required = Initial weights(52 GB) + Attention cache and Token Generation memory(4-10 GB)** + Additional overhead(2-3 GB)

** depends on sequence length, batch strategy, model architecture)

Memory Precision Comparisons:
• FP32 (Full Precision):           Base reference ( 4 bytes for 1 parameter)
• FP16 (Half Precision):           1/2 of FP32
• BF16 (Brain Float 16):           1/2 of FP32
• INT8 (8-bit Integer):            1/4 of FP32

モデルが GPU のメモリよりも多くのメモリを必要とする場合は、量子化、テンソル並列処理、連続バッチ処理を使用してパフォーマンスを最適化します。詳細については、「Amazon SageMaker を使用した LLM のデプロイ」および「エンドポイントデプロイ設定を選択する」を参照してください。Hugging Face で利用可能な LLM をデプロイする場合は、モデルメモリ推定ツールを使用して推定モデルメモリ要件を特定します。詳細については、Hugging Face のウェブサイトで「モデルメモリ推定ツール」を参照してください。

モデルに最適なバッチサイズと使用可能な GPU メモリを特定するには、「Amazon SageMaker を使用して Llama 2 モデルのスループットパフォーマンスを改善する」を参照してください。

モデルが長距離依存関係を処理する場合は、シーケンスの長さを調整します。詳細については、「新しい Amazon SageMaker コンテナを使用して LLM の推論パフォーマンスを改善する」を参照してください。

モデルの GPU メモリ割り当てが正しく設定されていることを確認します。GPU のメモリ消費量を追跡するには、nvidia-smi などの監視ツールを使用します。詳細については、NVIDIA のウェブサイトで「システム管理インターフェイス (SMI)」を参照してください。さらに、GPU メモリの問題の特定と解決をしやすくするために、追加のログステートメントを使用して推論スクリプトを拡張します。

一般的なメモリ関連エラーのトラブルシューティング

"botocore.errorfactory.ModelError: InvokeEndpoint 操作の呼び出し時にエラーが発生しました (ModelError): プライマリで、次のメッセージを含むサーバーエラー (503) が発生しました" {"code": 503, "type": "ServiceUnavailableException", "message": "No worker is available to serve request: model"}"

上記のエラーが表示された場合は、次の手順を実行してください。

• メモリ関連の問題を特定するには、エンドポイントの CloudWatch ログを確認します。
• コンテナの設定を調査し、エンドポイントインスタンスが同時リクエストを管理できることを確認します。受信したリクエストを効率的に処理できるよう、複数のワーカーが対応できるようにします。
• 複数のワーカーをサポートするには、model_server_workers パラメータを調整します。詳細については、SageMaker のウェブサイトで model_server_workers を参照してください。TorchServe などのフレームワークを使用してモデルをデプロイする場合は、ユースケースに基づいて最小ワーカーと最大ワーカー数を設定します。
• エンドポイントの最適な構成を特定するには、エンドポイントの負荷テストを行います。コンテナに複数のワーカーを処理するのに十分なリソースがない場合は、複数のインスタンスに負荷を分散するように自動スケーリングを設定します。

"torch.cuda.OutOfMemoryError: CUDA のメモリが不足しています。"

エンドポイントのデプロイ段階で上記のエラーが発生した場合は、次の手順を実行します。

• モデルのメモリ要件および構成を確認します。
• p4d.*、p5.* ファミリーなど、GPU あたりのメモリが大きいインスタンスタイプを使用します。または、g5.12xlarge や g5.48xlarge など、複数の GPU を搭載したインスタンスを使用します。
• モデルが 1 つの GPU に収まらない場合は、モデルの重みを複数の GPU に分散させます。

推論中に上記のエラーが発生した場合、GPU には入力要求を処理するための十分なメモリがありません。この問題をトラブルシューティングするには、バッチサイズを 1 に減らし、生成長を単一トークンに減らします。次に、GPU のメモリ使用量を監視し、バッチサイズと生成長を徐々に増やして、GPU の最大容量を判断します。

注: Hugging Faceの Accelerate ライブラリを使用している場合は、DeepSpeed を有効にして GPU メモリの使用率を減らします。この方法はダウンストリームのパフォーマンスには影響しません。詳細については、Hugging Face のウェブサイトで Accelerate を参照してください。