View a markdown version of this page

HyperPod でのモデルデプロイのタスクガバナンス - Amazon SageMaker AI
推論ワークロード管理の仕組みサンプル推論ワークロードの設定推論ワークロードのタスクガバナンスの設定

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

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

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

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

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

優先クラス設定

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

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

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

リソース共有戦略

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

  1. 厳格なリソースコントロール: クォータの貸借を無効にして、GPU のリザーブドキャパシティがワークロードで常に使用可能であるようにします。このアプローチでは、ピーク需要を個別に処理するのに十分なサイズのクォータが必要であり、トラフィックが少ない時間帯にアイドル状態のノードが発生する可能性があります。

  2. Flexible Resource Sharing: クォータの借用を有効にして、必要に応じて他のチームのアイドルリソースを使用します。借用したポッドはプリエンプティブルとマークされ、貸す方のチームがキャパシティを取り戻すとエビクションされる可能性があります。

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

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

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

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

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

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

  • チーム A: 10 の P4 GPU クォータ

  • チーム B: 20 の P4 GPU クォータ

  • 静的プロビジョニング: オートスケーリングなし

  • キャパシティ合計: 30 の P4 GPU

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

  1. リアルタイム推論: 優先度 100

  2. トレーニング: 優先度 75

  3. 評価: 優先度 50

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

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

通常運用:

  • チーム A は 10 の P4 GPU すべてでトレーニングジョブと評価ジョブを実行します。

  • チーム B は、20 の GPU クォータ内でリアルタイム推論 (10 の P4) と評価 (10 の P4) を実行します。

  • クラスターは、許可されたすべてのジョブと実行中のすべてのジョブで完全に活用されています。

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

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

  • チーム B の名前空間内

  • 優先度 100 (リアルタイム推論)

  • クォータの制約によりアドミッション保留中

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

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

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

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

  1. クォータチェック

    質問: チーム B には未使用のクォータがありますか。

    • はい → ポッドを承認します

    • いいえ → ステップ 2 に進む

  2. チーム B 内のセルフプリエンプション

    質問: 優先度の低いチーム B ジョブよりも優先できますか。

    • はい → 評価ジョブ (優先度 50) よりも優先し、P4 を 5 つリリースして、推論ポッドを承認します

    • いいえ → ステップ 3 に進む

    このアプローチの場合、ワークロードをチーム B の保証クォータ内に維持し、外部エビクションのリスクを回避できます。

  3. 他のチームからの借用

    質問: 他のチームにアイドル状態で借用可能なクォータはありますか。

    • はい → 借用クォータ (プリエンプティブルとしてマーク) を使用して承認する

    • いいえ → ポッドは NotAdmitted 状態のまま

推論ワークロードのタスクガバナンスの設定

推論ワークロードを Kueue と統合するには、タスクガバナンスラベルを InferenceEndpointConfigまたは JumpStartModel CRD に追加します。これらのラベルは、クォータ管理のためにワークロードを受け取る LocalQueue を決定し、プリエンプションの決定に使用されるスケジューリング優先度を定義します。以下のセクションでは、前提条件、リソーススコープ、ラベル設定、検証手順について説明します。

前提条件

推論ワークロードのタスクガバナンスを設定する前に、HyperPod クラスターに次のリソースが存在することを確認してください。

  • Kueue がクラスターにインストールされ、実行されている

  • チームに割り当てられた GPU クォータを持つ ClusterQueue が存在する

  • LocalQueue は、推論エンドポイントをデプロイする予定の 名前空間に存在します。

  • ワークロードタイプ (推論、トレーニング、評価など) に対して 1 つ以上の PriorityClass リソースが定義されている

これらのリソースが使用可能であることを確認するには、次のコマンドを実行します。

# Verify Kueue is installed
kubectl get crd | grep kueue

# List available PriorityClasses
kubectl get priorityclass

# List ClusterQueues
kubectl get clusterqueue

# List LocalQueues in your namespace
kubectl get localqueue -n <your-namespace>

リソーススコープについて

タスクガバナンスリソースには、推論デプロイラベルの設定方法に影響するさまざまなスコープがあります。

kueue.x-k8s.io/queue-name ラベルは、 InferenceEndpointConfigまたは と同じ名前空間に存在する LocalQueue を参照する必要がありますJumpStartModel。その名前空間に一致する LocalQueue が見つからない場合、ワークロードは Kueue によって許可されません。

ClusterQueue、ResourceFlavor、および PriorityClass はクラスタースコープであり、任意の名前空間からアクセスできます。

クラスターのリソーススコープを確認するには:

kubectl api-resources | grep kueue

タスクガバナンスラベルの追加

推論デプロイのタスクガバナンスを有効にするには、 InferenceEndpointConfigまたは JumpStartModel CRD の metadataセクションに次のラベルを追加します。

metadata:
  name: <your-deployment-name>
  namespace: <your-namespace>
  labels:
    kueue.x-k8s.io/queue-name: <your-localqueue-name>
    kueue.x-k8s.io/priority-class: <your-priority-class>

ラベルの説明:

  • kueue.x-k8s.io/queue-name — クォータ追跡のためにワークロードをチームの LocalQueue にルーティングします。ワークロードと同じ名前空間の LocalQueue 名と一致する必要があります。

  • kueue.x-k8s.io/priority-class — プリエンプション決定のスケジュール優先度を設定します。クラスタースコープの PriorityClass を名前で参照します。

タスクガバナンス設定の検証

タスクガバナンスラベルJumpStartModelを使用して InferenceEndpointConfigまたは を適用したら、Kueue がワークロードとポッドが正しくスケジュールされていることを確認します。

タスクガバナンスが機能していることを確認するには

  1. ワークロードのアドミッションステータスを確認します。

    kubectl get workloads -n <namespace>

    正常に許可されたワークロードが ADMITTED 列Trueに表示され、リソースを予約した ClusterQueue が RESERVED IN 列に一覧表示されます。

  2. ポッドのステータスを確認します。

    kubectl get pods -n <namespace>

    アドミッション後、ポッドは初期化段階を経て段階的に移行し、 Running状態になります。

  3. クォータの消費量を確認します。

    kubectl get clusterqueue <clusterqueue-name> -o yaml

    status セクションを確認して、リソースの消費量が追跡されていることを確認します。

  4. LocalQueue の保留中のワークロードを確認します。

    kubectl get localqueue -n <namespace>

    PENDING WORKLOADS 列には、アドミッションを待っているワークロードの数が表示されます。

  5. Kueue アドミッションイベントを表示する:

    kubectl describe workload <workload-name> -n <namespace>

    承認の決定とエラーについては、「イベント」セクションを確認してください。

ポッドが Pending状態のままの場合は、問題が Kueue アドミッションレベル (ワークロードに と表示Admitted: False) か、Kubernetes スケジューラレベル (ワークロードは許可されていますが、ポッドはスケジュール不可能) かを判断します。