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

HyperPod でのモデルデプロイのタスクガバナンス

このセクションでは、リアルタイム推論ワークロード用に共有 Amazon SageMaker HyperPod EKS クラスターを最適化する方法について説明します。クォータ管理、優先度スケジューリング、リソース共有ポリシーなど、Kueue のタスクガバナンス機能を設定して、チームのトレーニング、評価、テストアクティビティ全体で公平な配分を維持しながら、トラフィックの急増時に推論ワークロードに必要な GPU リソースを確実に取得する方法について説明します。タスクガバナンスの概念の詳細については、「Amazon SageMaker HyperPod タスクのガバナンス」を参照してください。

推論ワークロード管理の仕組み

共有 HyperPod EKS クラスターのリアルタイムの推論トラフィックのスパイクを効果的に管理するには、Kueue の既存の機能を使用して次のタスクガバナンス戦略を実装します。

優先クラス設定

高い加重で推論ワークロード (100 など) 専用の優先クラスを定義して、推論ポッドが他のタスクタイプより先に許可され、スケジュールされるようにします。この設定により、推論ワークロードはクラスターのロード中に優先度の低いジョブより優先されます。これは、トラフィックのスパイク時に低レイテンシー要件を維持する上で重要です。

クォータのサイジングと割り当て

予想される推論スパイクを処理するのに十分な GPU リソースをチームの ClusterQueue で予約します。推論トラフィックが少ない期間中は、未使用のクォータリソースを他のチームのタスクに一時的に割り当てることができます。推論の需要が増加すると、これらの借用リソースを再利用して、保留中の推論ポッドに優先順位を付けることができます。詳細については、「クラスターのキュー」を参照してください。

リソース共有戦略

要件に基づいて、以下の 2 つのクォータ共有アプローチから選択します。

チーム内プリエンプション

同じクォータで混合ワークロード (評価、トレーニング、推論) を実行する場合、チーム内プリエンプションを有効にします。これにより、Kueue はチーム内の優先度の低いジョブよりも優先して優先度の高い推論ポッドに対応できるため、外部クォータからの借用に依存せずにリアルタイム推論を実行できます。詳細については、「プリエンプション」を参照してください。

サンプル推論ワークロードの設定

次の例は、Kueue が共有 Amazon SageMaker HyperPod クラスター内の GPU リソースを管理する方法を説明しています。

クラスターの設定とポリシーの設定

このクラスターの設定は、以下のとおりです。

共有 GPU プールは、次の優先度ポリシーを使用します。

Kueue は、チームのクォータと優先クラスを適用し、プリエンプションとクォータの借用を有効にします。

初期状態: 通常のクラスター使用率

通常運用:

推論スパイク: チーム B に追加の GPUが必要です

チーム B でトラフィックのスパイクが発生した場合、追加の推論ポッドにはさらに 5 つの P4 GPU が必要です。Kueue は、新しいポッドが以下であることを検出します。

Kueue のレスポンスプロセスは、次の 2 つのオプションから選択します。

オプション 1: クォータの借用 - チーム A が 10 の P4 のうち 6 しか使用していない場合、Kueue はアイドル状態の 4 の P4 の使用をチーム B に認めることができます。ただし、これらの借用リソースはプリエンプティブルです。チーム A がジョブを送信してクォータ上限に達すると、Kueue はチーム B が借りた推論ポッドをエビクションします。

オプション 2: セルフプリエンプション (推奨) - チーム B は優先度の低い評価ジョブ (優先度 50) を実行しています。優先度の高い推論ポッドが待機している場合、Kueue はチーム B のクォータ内の評価ジョブよりも優先し、推論ポッドを承認します。このアプローチは、外部エビクションのリスクがなく、安全なリソース割り当てを提供します。

Kueue は 3 ステップのプロセスに従ってリソースを割り当てます。