このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Amazon EKS で AI/ML ワークロードの高速コンピューティングを管理する
ヒント
今後開催予定の Amazon EKS AI/ML ワークショップに登録
このセクションでは、Amazon EKS を使用して AI/ML トレーニングおよび推論ワークロード用の EC2 高速コンピューティングインスタンスを購入およびプロビジョニングする方法について説明します。大規模なモデルをトレーニングする場合でも、リアルタイム推論を実行する場合でも、生成 AI アプリケーションをデプロイする場合でも、適切な NVIDIA GPU または AWS Trainium キャパシティを使用することは、ワークロードのパフォーマンスの基盤となります。
EC2 インスタンスタイプから選択
利用可能な Amazon EC2 高速コンピューティングインスタンスの詳細については、「Amazon EC2 高速コンピューティングインスタンスの仕様」を参照してください。これには、P ファミリーと G ファミリーの NVIDIA GPU インスタンス、および AWS 設計のアクセラレーター Trainium と Inferentia が含まれます。
EC2 購入オプションを理解する
ワークロードに必要な高速インスタンスがわかったならば、次のステップは、これらの高速インスタンスタイプを取得するために利用できる購入オプションを理解することです。AWS には、オンデマンドインスタンス、スポットインスタンス、ML のキャパシティブロック、オンデマンドキャパシティ予約 (ODCR) の 4 つのコンピューティングキャパシティ購入オプションがあります。各オプションは、さまざまなワークロードパターン、コストプロファイル、可用性要件に対応します。Amazon EC2 インスタンス購入オプションドキュメントでは、各オプションの仕組み、その料金モデル、および使用時期について説明します。
-
オンデマンドインスタンス: キャパシティが存在する場合は、コミットメントなしで秒単位で支払います。開発、プロトタイプ作成、予測不可能な推論スケーリング、および中断リスクなしで即時のコンピューティングを必要とするワークロードに最適です。
-
スポットインスタンス: 予備の EC2 キャパシティを使用することで、2 分間の中断通知で、オンデマンドと比較して最大 90% の節約を実現します。耐久性のあるストレージにチェックポイントを提供する耐障害性のあるワークロードに最適です: ハイパーパラメータの調整、定期的なチェックポイントによる分散トレーニング、バッチ推論とオフライン推論、データ前処理パイプライン。
-
ML のキャパシティブロック: P ファミリーインスタンスと Trainium インスタンスを固定ウィンドウ (24 時間、最大 6 か月) に予約し、最大 8 週間前に予約します。キャパシティブロックは、GPU クラスターへの予測可能なアクセスを必要とする既知のタイムラインを持つ、計画された大規模なトレーニング実行、時間制限のあるファインチューニング実験、研究プロジェクトに使用します。
-
オンデマンドキャパシティ予約 (ODCR): 長期契約なしで特定のアベイラビリティーゾーンに高速キャパシティを予約します。キャパシティが使用されているかどうかにかかわらず、標準のオンデマンド料金で請求されます。本番推論、SLA バウンドサービス、ビジネスクリティカルなアプリケーションに最適です。スケジュールの遅延やキャパシティの利用不可は許容されません。キャパシティブロックとは異なり、ODCR は P ファミリーインスタンスと G ファミリーインスタンスの両方をサポートします。
購入オプションをワークロード要件に一致させる
高速インスタンスタイプと購入オプションを理解したので、次のステップは適切な購入オプションをワークロード固有の要件に一致させることです。インスタンスタイプ、リージョン、タイミングの柔軟性が高いワークロードは、より多くの購入オプションとより低い料金の対象となります。
次のような要因に基づいて決定します:
-
戦略的重要性と SLA コミットメント
-
需要の予測可能性とスケジューリングの柔軟性
-
リザーブドキャパシティに事前にコミットする意思
-
インスタンスタイプ、リージョン、タイミングの柔軟性
-
中断とコスト削減の許容度
実際には、チームは複数の購入オプションを組み合わせて、ワークロードポートフォリオ全体でコスト、可用性、信頼性のバランスを取るハイブリッドアプローチを採用しています。記事「AWS でGPU キャパシティを取得する方法
EC2 サービスクォータを確認する
EKS クラスターにキャパシティ購入オプションを実装する前に、使用する計画がある GPU インスタンスファミリーに十分な vCPU クォータが AWS アカウントにあることを確認してください。適切なクォータがない場合、Karpenter NodePools、EKS Auto Mode プロビジョニング、および EKS ノードグループは、選択した購入オプションに関係なく、高速コンピューティングノードを起動できません。
AWS は、インスタンスファミリーと購入モデルごとに個別の vCPU クォータを適用します。Amazon EC2 インスタンスタイプのクォータを確認して、高速コンピューティングインスタンスのデフォルトのクォータを理解します。
これらのクォータは、インスタンス数ではなく vCPU 数に基づいています。例えば、10 個の p6-b300.48xlarge インスタンスを起動するには、1,920 個の vCPU (10 × 192) が必要です。多くの場合、新しいアカウントではデフォルトの GPU クォータが 0 に設定されているため、インスタンスをデプロイしようとする前にクォータの引き上げをリクエストしてください。
キャパシティブロック予約の作成、オンデマンドインスタンスの起動、またはスポットリクエストの送信時にクォータの制限が発生した場合は、AWS サポートまたは AWS アカウントチームに連絡して要件について話し合い、ニーズに最適な高速コンピューティングキャパシティを確保するためのオプションを検討してください。
Amazon EKS で EC2 購入オプションを使用する
EC2 高速コンピューティング購入オプションを選択したら、キャパシティを使用するように Amazon EKS クラスターを設定します。Amazon EKS には 3 つのプロビジョニング方法があり、それぞれで制御と自動化のバランスが異なります。
-
Amazon EKS Auto Mode: ノードを自動的にプロビジョニング、スケーリング、パッチ適用する AWS マネージドコンピューティング。プロビジョニングに組み込み Karpenter、および NVIDIA ドライバーとデバイスプラグインを含む Bottlerocket オペレーティングシステムを使用します。運用上のオーバーヘッドを最小限に抑えたマネージドインフラストラクチャが必要な場合に最適です。静的キャパシティのプロビジョニングと動的キャパシティのプロビジョニングの両方をサポートします。
-
Karpenter (セルフマネージド): Amazon EKS クラスターにインストールして運用するオープンソースのアップストリームプロジェクト。EKS Auto Mode と同じプロビジョニングモデルを提供し、オペレーティングシステム、AMI、カーネルチューニング、およびノードライフサイクルを完全に制御できます。EKS Auto Mode がすぐに提供しない要件を持つプラットフォームチームに最適です。
-
ノードグループ (マネージドおよびセルフマネージド): EC2 Auto Scaling Groups (ASG) によってバックアップされ、キャパシティは EC2 起動テンプレートを通じて事前に定義されます。既存の EKS マネージドノードグループまたはセルフマネージドノードグループを持つプラットフォームチーム、および既知の静的な高速コンピューティングフットプリントで予測可能なサイズ設定を持つトレーニングワークロードに最適です。
以下のページでは、各プロビジョニングオプションについて詳しく説明します。
混合戦略：購入オプションを組み合わせる
単一の Amazon EKS クラスター内で複数のキャパシティ購入オプションを組み合わせるのが一般的です。このアプローチは、さまざまなワークロードを最適なキャパシティソースにルーティングすることで、コスト、可用性、信頼性を同時に最適化します。顧客は、3 つの EKS コンピューティング管理アプローチ (EKS Auto Mode、Karpenter、または Node Groups) のいずれかを使用してこのハイブリッド戦略を実装するか、同じクラスター内でそれらを組み合わせます。
EKS Auto Mode と Karpenter は常にリザーブドキャパシティ (ODCR とキャパシティブロック) を最初にプロビジョニングし、続いてスポットまたはオンデマンドをプロビジョニングします。このインスタンスプロビジョニングの優先度を組み合わせるには、重要なワークロードをリザーブドキャパシティにスケジューリングし、柔軟なワークロードをスポットインスタンスまたはオンデマンドインスタンスにスケジューリングします。Kubernetes ネイティブスケジューリングプリミティブを使用してワークロードのルーティングを制御します。nodeSelector は特定のキャパシティタイプをターゲットにし、テイントと許容値によって NVIDIA GPU ノードまたは AWS Trainium ノードを分離し、topologySpreadConstraints は高可用性のためにアベイラビリティーゾーン全体でワークロードを分散します。
適切に設計された Amazon EKS クラスターは、高速コンピューティング NodePools またはノードグループをリザーブドとバーストの 2 つのカテゴリに整理し、それぞれをキャパシティ戦略に最適なワークロードパターンに合わせます。以下に例を示します。
-
リザーブドキャパシティ:
gpu-reservedNodePool またはノードグループは、SLA バインドサービスおよび計画されたコンピューティング負荷の高いジョブ用に、リザーブドキャパシティ (ODCR とキャパシティブロック) で本番推論とスケジュールされた大規模トレーニングを実行します。この NodePool またはノードグループは、リアルタイム推論エンドポイント、本番モデルサービング、および予測可能なパフォーマンスで常時オンの GPU 可用性を必要とするビジネスクリティカルなアプリケーションなど、推論ワークロードと本番ワークロードを処理します。また、計画された分散トレーニング、大規模なファインチューニング実験、期間限定の研究プロジェクト、および開始時間と期間を事前に把握しているワークロードなど、スケジュールされたコンピューティング負荷の高いジョブもサポートします。 -
バーストキャパシティ:
gpu-burstNodePool またはノードグループは、実験、アドホックワークロード、バッチ処理を処理します。オンデマンドフォールバックを備え、スポットインスタンスをプライマリキャパシティタイプとして使用します。この組み合わせにより、耐障害性のあるワークロードのコスト削減を最大化し、スポットが利用できない場合のキャパシティを確保できます。この NodePool またはノードグループは、バッチオフライン推論、データ前処理パイプライン、モデル評価ジョブ、開発とプロトタイピング、予測不可能な推論スケーリング、短期間のデバッグセッション、チェックポイントを実装してスポットの中断を処理できるワークロード、または予約を正当化しないがリザーブドウィンドウを待つことができないワークロードを処理します。この NodePool またはノードグループ上のワークロードは、チェックポイントとグレースフルシャットダウンを実装して、2 分間のスポット中断ウィンドウ内のノード損失を処理します。
nodeSelector を使用してワークロードに必要なキャパシティタイプを指定します。karpenter.sh/capacity-type: [spot, on-demand, reserved]重みベースのプロビジョニングは、すべてのキャパシティプール全体でクラスターを効率的にスケーリングします。このアーキテクチャでは、コストを最適化しながら、実験的なノートブックから本番推論まで、多様な AI/ML ワークロードを単一の Amazon EKS クラスター内で実行できます。
