このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Amazon EKS の NVIDIA GPU でマルチインスタンス GPU (MIG) を使用する
マルチインスタンス GPU
MIG は、予測可能なサービスの品質を必要とするマルチテナント推論やワークロードに最適です。NVIDIA Ampere (A100)、Hopper (H100 と H200)、および Blackwell GPU で使用できます。AWS では、これらは P ファミリーインスタンスタイプと、Blackwell ベースの g7 および g7e インスタンスタイプです。利用できるタイムゾーンの一覧については、「MIG 対応インスタンスタイプ」を参照してください。
MIG は、次の場合に適しています:
-
あるワークロードが別のワークロードに必要な GPU メモリを消費できないようにするために、メモリの分離が必要である。
-
テナントが GPU ハードウェアを共有するけれども、テナントごとのサービス品質が必要なマルチテナント推論を実行する。
-
A100、H100、H200、または Blackwell インスタンスでトレーニングを既に実行しており、トレーニングがアイドル状態のときに、これらの GPU を小規模な推論ワークロードに再利用したいと考えている。
次の場合は、別のアプローチを検討してください:
-
ノードが、
g5、g6、g6eファミリーなど、MIG をサポートしていない GPU インスタンスタイプを使用している。代わりにタイムスライシングを使用します。 -
メモリを分離する必要はなく、最も簡単な設定を望んでいる。代わりにタイムスライシングを使用します。
-
GPU パーティションを中断することなく頻繁に変更する必要がある。MIG モードまたはパーティションレイアウトを変更するには、GPU のリセットが必要です。GPU オペレータはノードを再起動してこれを実行します。
-
GPU 間の集合通信またはピアツーピア通信に依存するマルチ GPU トレーニングを実行している。MIG は NCCL またはクロス GPU P2P をサポートしていません。
考慮事項
本番環境で MIG を使用する前に、以下の考慮事項を確認してください。
一般的な考慮事項
-
MIG 設定を変更するには、GPU のリセットが必要です。MIG モードの有効化または無効化、またはパーティションレイアウトの変更には GPU のリセットが必要なため、インプレースで変更することはできません。例えば、NVIDIA GPU Operator の MIG Manager は、ノード上の GPU Pod を停止し、MIG モードを変更するために再起動が必要な場合にノードを再起動することで、設定変更を適用します。
-
コンピューティングはインスタンスサイズに厳密には比例しません。メモリ帯域幅とキャッシュ動作はプロファイルによって異なるため、
1gインスタンスはすべてのワークロードで GPU 全体のスループットを比例配分するわけではありません。パーティションのサイズを設定する前に、使用するプロファイルでワークロードをベンチマークします。 -
タイムスライシングは MIG インスタンスには影響しません。MIG インスタンスはすでにハードウェア分離されており、タイムスライスを通じてそれ以上共有することはできません。MIG デバイスで
TimeSlicing共有戦略をリクエストしても、ハードウェアの動作は変更されません。コンテナ間で単一の MIG インスタンスを共有するには、代わりに NVIDIA Multi-Process Service (MPS) を使用します。 -
クロス GPU 通信の制限。MIG が有効になっている場合、異なる GPU 上の MIG インスタンスは GPU 間のピアツーピア (P2P) 通信を使用できません。また、NCCL は MIG と連携しません。テンソル並列マルチ GPU トレーニングなど、GPU 間の集合通信または P2P に依存するマルチ GPU ワークロードには、代わりに GPU 全体が必要です。詳細については、NVIDIA ウェブサイトの NVIDIA MIG ユーザーガイドの「アプリケーションに関する考慮事項
」を参照してください。
NVIDIA デバイスプラグインに関する考慮事項
-
ポッドリソースリクエストは、戦略と一致する必要があります。単一戦略では、Pod は
nvidia.com/gpuをリクエストします。混合戦略では、Pod はnvidia.com/mig-1g.10gbなどのプロファイル固有のリソースをリクエストします。ノードがアドバタイズしないプロファイルをリクエストする Pod はPending状態のままになります。kubectl describe node <node-name>でアドバタイズされたリソースを確認します。 -
AL2023 のスタンドアロンデバイスプラグイン。例えば、クラスターのセットアップの一部として NVIDIA デバイスプラグインを個別にインストールする場合は、MIG ノードからそれを除外して、GPU Operator が管理するデバイスプラグインと競合しないようにします。
nvidia.com/mig.configラベルを持つノードを除外するノードアフィニティルールをスタンドアロンデバイスプラグインに追加します。 -
EKS Auto Mode ではサポートされていません。EKS Auto Mode は NVIDIA デバイスプラグインを管理し、その設定を公開しません (加速ワークロードをデプロイする を参照)。EKS Auto Mode ノードで MIG を有効にすることはできません。AMI とデバイスプラグインの設定を制御するセルフマネージド Karpenter ノードまたはマネージドノードグループで MIG を設定します。
NVIDIA DRA ドライバーに関する考慮事項
-
静的 MIG には、事前に作成されたインスタンスが必要です。静的 MIG では、DRA ドライバーは既存の MIG インスタンスを割り当てますが、MIG モードを有効にしたり GPU をパーティション化したりしません。まず MIG モードを有効にし、インスタンスを作成する必要があります。例えば、NVIDIA GPU Operator の MIG Manager または
nvidia-smiを使用します。詳細については、「NVIDIA DRA ドライバーで MIG を使用する」を参照してください。 -
動的 MIG はアルファ機能です。動的 MIG を使用すると、ドライバーはワークロードリクエストに応じてオンデマンドで MIG パーティションを作成および破棄します。
DynamicMIG機能ゲートが必要です。これはデフォルトで無効になっています。詳細については、「NVIDIA DRA ドライバーで MIG を使用する」を参照してください。 -
Bottlerocket の組み込みデバイスプラグインを無効にします。DRA ドライバーは、同じノード上の NVIDIA デバイスプラグインと一緒に実行することはできません。Bottlerocket で、組み込みデバイスプラグインを無効にします。これには Bottlerocket バージョン 1.63.0 以降が必要です。詳細については、「NVIDIA DRA ドライバーをインストールする」を参照してください。
-
コンピューティングのサポート。NVIDIA DRA ドライバーは、Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードの静的キャパシティのプロビジョニングでサポートされており、EKS Auto Mode ではサポートされていません。詳細については、Karpenter ウェブサイトの「Karpenter 静的 NodePool ドキュメント
」を参照してください。
MIG 対応インスタンスタイプ
AWS では、次のインスタンスタイプが MIG 対応 GPU を提供します。
| インスタンスタイプ | GPU | GPU メモリ |
|---|---|---|
|
|
8 x NVIDIA A100 40 GB |
320 GB |
|
|
8 x NVIDIA A100 80 GB |
640 GB |
|
|
8 x NVIDIA H100 80 GB |
640 GB |
|
|
8 x NVIDIA H200 |
1128 GB |
|
|
8 x NVIDIA H200 |
1128 GB |
|
|
8 x NVIDIA Blackwell B200 |
1432 GB |
|
|
8 x NVIDIA Blackwell Ultra B300 |
2144 GB |
|
|
8 x NVIDIA RTX PRO 4500 Blackwell Server Edition |
256 GB |
|
|
8 x NVIDIA RTX PRO 6000 Blackwell Server Edition |
768 GB |
MIG は、g5、g6、または g6e ファミリーでは使用できません。MIG 対応 NVIDIA GB200 GPU を使用する p6e-gb200 UltraServers については、Amazon EKS で P6e-GB200 UltraServer を使用する を参照してください。
注記
g7 インスタンスタイプには NVIDIA ドライバーバージョン 595 以降が必要です。EKS 最適化高速 AMI には、現在 NVIDIA ドライバーバージョン 580 が含まれているため、g7 で MIG を使用するには、ドライバーバージョン 595 でカスタム AMI を構築する必要があります。詳細については、「EKS に最適化されたカスタム Amazon Linux AMI の構築」を参照してください。
MIG インスタンスは、命名パターン <slices>g.<memory>gb を使用するプロファイルによって記述されます。ここで、<slices> はコンピューティングスライスの数で、<memory> はギガバイト単位でのインスタンスのメモリです。例えば、3g.40gb プロファイルは 7 個のコンピューティングスライスのうち 3 個と 40 GB のメモリを提供します。各 GPU がサポートするプロファイルは、ハードウェアによって固定されます。完全なリストについては、NVIDIA ウェブサイトの「NVIDIA マルチインスタンス GPU ユーザーガイド
インスタンスタイプあたりの MIG プロファイル
ノードで使用できる MIG プロファイルは、インスタンスタイプの GPU によって異なります。以下のセクションでは、MIG 対応の各 Amazon EC2 インスタンスタイプのプロファイルを一覧表示します。各プロファイルの最大インスタンスは、単一の GPU で作成できるそのプロファイルの最大インスタンス数で、インスタンスあたりのメモリは、それぞれに割り当てられた GPU メモリです。
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/7 |
5 GB |
7 |
|
|
1/7 |
10 GB |
4 |
|
|
2/7 |
10 GB |
3 |
|
|
3/7 |
20 GB |
2 |
|
|
4/7 |
20 GB |
1 |
|
|
7/7 |
40 GB |
1 |
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/7 |
10 GB |
7 |
|
|
1/7 |
20 GB |
4 |
|
|
2/7 |
20 GB |
3 |
|
|
3/7 |
40 GB |
2 |
|
|
4/7 |
40 GB |
1 |
|
|
7/7 |
80 GB |
1 |
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/7 |
10 GB |
7 |
|
|
1/7 |
20 GB |
4 |
|
|
2/7 |
20 GB |
3 |
|
|
3/7 |
40 GB |
2 |
|
|
4/7 |
40 GB |
1 |
|
|
7/7 |
80 GB |
1 |
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/7 |
18 GB |
7 |
|
|
1/7 |
35 GB |
4 |
|
|
2/7 |
35 GB |
3 |
|
|
3/7 |
71 GB |
2 |
|
|
4/7 |
71 GB |
1 |
|
|
7/7 |
141 GB |
1 |
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/7 |
23 GB |
7 |
|
|
1/7 |
45 GB |
4 |
|
|
2/7 |
45 GB |
3 |
|
|
3/7 |
90 GB |
2 |
|
|
4/7 |
90 GB |
1 |
|
|
7/7 |
180 GB |
1 |
p6-b300.48xlarge – NVIDIA Blackwell Ultra B300
p6-b300.48xlarge は、各 GPU を 7 個の 32 GB のインスタンス、4 個の 67 GB、2 個の 135 GB、または 1 個の 270 GB のインスタンスへのパーティション化をサポートする HGX B300 を使用します。これらのサイズは暫定的なものであり、変更される可能性があります。プロファイルの詳細については、NVIDIA ウェブサイトの「NVIDIA がサポートする MIG プロファイル
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/2 |
16 GB |
2 |
|
|
2/2 |
32 GB |
1 |
RTX PRO 4500 Blackwell は、グラフィックス対応 (+gfx) およびメディアエンジン (+me.all、-me) プロファイルバリアントもサポートしています。詳細なリストについては、NVIDIA ウェブサイトの「NVIDIA がサポートする MIG プロファイル
| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス |
|---|---|---|---|
|
|
1/4 |
24 GB |
4 |
|
|
2/4 |
48 GB |
2 |
|
|
4/4 |
96 GB |
1 |
RTX PRO 6000 Blackwell Server Edition は、グラフィックス対応 (+gfx) およびメディアエンジン (+me.all、-me) プロファイルバリアントもサポートしています。詳細なリストについては、NVIDIA ウェブサイトの「NVIDIA がサポートする MIG プロファイル
MIG 戦略
NVIDIA DRA ドライバーと NVIDIA デバイスプラグインは、さまざまな方法で MIG インスタンスを Kubernetes に公開します。デバイスプラグインはノード全体の MIG 戦略設定を使用しますが、DRA ドライバーは属性によってインスタンスを選択するため、同等の設定はありません。この違いを理解することは、2 つのモデルから選択する上で重要です。
NVIDIA DRA ドライバー
NVIDIA DRA ドライバーは単一または混合戦略の概念を使用しないため、同等の設定を構成することはできません。MIG インスタンスをカウントされたリソースとしてアドバタイズする代わりに、ドライバーは各インスタンスを mig.nvidia.com DeviceClass のデバイスとして、その profile などの属性とともに発行します。Pod は、NVIDIA DRA ドライバーで MIG を使用する に示すように、これらの属性を ResourceClaim または ResourceClaimTemplate の共通表現言語 (CEL) セレクターと照合してインスタンスを選択します。
選択はインスタンスごとに行われるため、混合プロファイルノードは戦略モードの切り替えなしで機能します。単一の GPU を複数の異なるプロファイルに分割でき、各クレームで必要なプロファイルが選択されます。DRA ドライバーにとって重要な選択は、単一戦略か混合戦略ではなく、静的 MIG か動的 MIG であり、MIG インスタンスを事前に作成するか、ドライバーがオンデマンドで作成するかを制御します。詳細については、「NVIDIA DRA ドライバーで MIG を使用する」を参照してください。
NVIDIA デバイスプラグイン
NVIDIA デバイスプラグインは、2 つの戦略のいずれかを使用して MIG インスタンスを Kubernetes にアドバタイズします。デバイスプラグインは MIG インスタンスをノードレベルの拡張リソースとして公開しており、整数カウントのみを持ちインスタンスごとの属性を持たないため、戦略によってそれらのリソースに名前を付ける方法が決まります。
-
単一戦略 – ノード上のすべての GPU は、同じ MIG プロファイルを使用します。デバイスプラグインは各インスタンスを
nvidia.com/gpuリソースとしてアドバタイズし、Pod は専用 GPU の場合と同様にnvidia.com/gpu: 1をリクエストします。既存のマニフェストは変更されません。Bottlerocket と AL2023 はどちらも単一戦略をサポートしています。 -
混合戦略 – 同じノード上の GPU は、異なる MIG プロファイルを使用できます。デバイスプラグインは、各プロファイルを
nvidia.com/mig-1g.10gbやnvidia.com/mig-3g.40gbなどの個別のリソースとしてアドバタイズし、Pod は必要な特定のプロファイルをリクエストします。Bottlerocket の組み込み NVIDIA デバイスプラグインでは、混合戦略を使用できません。詳細については、GitHub の「Bottlerocket GitHub の問題 #4483」を参照してください。
NVIDIA DRA ドライバーで MIG を使用する
NVIDIA DRA ドライバーを使用して MIG インスタンスを割り当てると、Pod はデバイスプラグインの nvidia.com/mig-<profile> 拡張リソースではなく、ResourceClaim または ResourceClaimTemplate を介して MIG インスタンスをリクエストします。
DRA ドライバーは、カウントされたリソースとしてではなく属性でインスタンスを記述するため、デバイスプラグインが必要とする単一戦略または混合戦略を使用しません (MIG 戦略 を参照)。ドライバーは、各 MIG インスタンスを mig.nvidia.com DeviceClass 内の gpu.nvidia.com/type 属性が mig のデバイスとして公開し、profile (1g.5gb など) や物理 GPU の parentUUID などのインスタンスごとの属性をアドバタイズします。これらの属性を共通表現言語 (CEL) セレクターと照合して、特定のプロファイルをリクエストしたり、複数のインスタンスを同じ GPU に保持したりできます。
DRA ドライバーは、次の 2 つのモードのいずれかで MIG インスタンスを割り当てます。
-
静的 MIG – MIG モードを有効にし、ドライバーの起動前にノードに MIG インスタンスを作成します。例えば、NVIDIA デバイスプラグインで AL2023 ノードの MIG を使用する で説明されているように、NVIDIA GPU Operator の MIG Manager を使用します。ドライバーは既存のインスタンスを検出して Pod に割り当てますが、ノードの MIG 設定は変更しません。ドライバーの起動後に追加されたインスタンスは、GPU kubelet プラグインが再起動するまで検出されません。静的 MIG はデフォルトであり、機能ゲートは必要ありません。
-
動的 MIG – ドライバーはワークロードリクエストに応じてオンデマンドで MIG パーティションを作成および破棄するため、GPU を事前にパーティション化する必要はありません。動的 MIG は、デフォルトで無効になっているアルファ機能です。次のセクションに示すのと同じ
ResourceClaimTemplateセレクターを使用してプロファイルをリクエストすると、ドライバーはリクエストを満たすために GPU をパーティション化します。
考慮事項
-
動的 MIG は、ノードの静的検出を置き換えます。ドライバーはすべてのパーティションを管理し、GPU kubelet プラグインの起動時に作成されなかった MIG パーティションを破棄します。保持する事前に作成されたパーティションがあるノードで動的 MIG を有効にしないでください。また、プラグインの実行中に
mig-partedまたはnvidia-smi migを実行しないでください。それは、手動の変更がドライバーのパーティション状態と競合し、Pod の準備またはクリーンアップが失敗する可能性があるからです。 -
動的 MIG はアルファ状態であり、NVIDIA DRA ドライバーのインストール時に機能ゲートを有効にする必要があります。手順については、NVIDIA DRA ドライバーをインストールする を参照してください。
-
Hopper (H100 および H200) 以降のアーキテクチャは、オンデマンドで MIG モードを有効にします。以前の世代では、Ampere (A100) GPU など、オンデマンドで MIG モードを有効にできません。
-
動的 MIG は、Kubernetes バージョン 1.36 以降でデフォルトで有効になっている、Kubernetes のパーティション化可能なデバイス機能 (GitHub の KEP-4815
) に依存しています。以前のバージョンでは、この機能はデフォルトで有効になっていないため、スケジューラは動的に作成された MIG デバイスを割り当てることができません。
前提条件
-
Amazon EKS クラスターで Kubernetes バージョン 1.34 以降を実行していて、Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードグループによって静的キャパシティがプロビジョニングされていること。
-
MIG モードが有効で GPU が MIG インスタンスにパーティション化された MIG 対応 P ファミリーノード。静的 MIG については、NVIDIA ウェブサイトの「NVIDIA GPU Operator の MIG Manager
」を参照してください。 -
NVIDIA DRA ドライバーをインストールする で説明されているようにインストールされた NVIDIA DRA ドライバー。静的 MIG パーティショニングを使用していない場合は、オプションで動的 MIG が有効にされている。
手順
次の例は、静的または動的な MIG および NVIDIA DRA ドライバーで使用できます。
-
mig.nvidia.comDeviceClassから MIG インスタンスをリクエストするResourceClaimTemplateと、それを参照する Pod を作成します。この例では、プロファイルを制限せずに、使用可能な MIG インスタンスをリクエストします。cat <<EOF | kubectl apply -f - apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: mig-profile-any spec: spec: devices: requests: - name: mig exactly: deviceClassName: mig.nvidia.com count: 1 --- apiVersion: v1 kind: Pod metadata: name: mig-dra-pod spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: claims: - name: mig resourceClaims: - name: mig resourceClaimTemplateName: mig-profile-any restartPolicy: OnFailure EOF -
Pod に単一の MIG インスタンスが割り当てられていることを確認します。
kubectl logs mig-dra-pod出力例は次のとおりです。Pod は、パーティション化された GPU から 1 つの MIG インスタンスを確認します。
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-edd63844-8488-f76a-f6e0-1027a7319a88) MIG 2g.10gb Device 0: (UUID: MIG-a5ad493e-e7e8-5675-9381-1d0f5311a456)
特定の MIG プロファイルをリクエストする
使用可能なインスタンスの代わりに特定のプロファイルをリクエストするには、profile 属性に一致する CEL セレクターを追加します。次の ResourceClaimTemplate は 1g.5gb インスタンスをリクエストし、Pod はそれを参照します。
cat <<EOF | kubectl apply -f - apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: mig-profile-1g.5gb spec: spec: devices: requests: - name: mig exactly: deviceClassName: mig.nvidia.com selectors: - cel: expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'" --- apiVersion: v1 kind: Pod metadata: name: mig-profile-pod spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: claims: - name: mig resourceClaims: - name: mig resourceClaimTemplateName: mig-profile-1g.5gb restartPolicy: OnFailure EOF
同じ GPU から複数の MIG インスタンスをリクエストする
単一のクレーム内の複数の MIG インスタンスが同じ物理 GPU から取得されるようにするには、matchAttribute: "gpu.nvidia.com/parentUUID" で constraints ブロックを追加します。次の ResourceClaimTemplate は、1g.5gb インスタンスと 2g.10gb インスタンスを同じ GPU からリクエストし、Pod はクレームを参照します。コンテナは特定のリクエストに名前を付けることなくクレームを参照するため、両方の MIG インスタンスを受け取ります。
cat <<EOF | kubectl apply -f - apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: multi-mig spec: spec: devices: requests: - name: mig-small exactly: deviceClassName: mig.nvidia.com selectors: - cel: expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'" - name: mig-medium exactly: deviceClassName: mig.nvidia.com selectors: - cel: expression: "device.attributes['gpu.nvidia.com'].profile == '2g.10gb'" constraints: - requests: [] matchAttribute: "gpu.nvidia.com/parentUUID" --- apiVersion: v1 kind: Pod metadata: name: multi-mig-pod spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: claims: - name: mig resourceClaims: - name: mig resourceClaimTemplateName: multi-mig restartPolicy: OnFailure EOF
NVIDIA デバイスプラグインで Bottlerocket ノードの MIG を使用する
Bottlerocket では、EKS 最適化高速 AMI には NVIDIA デバイスプラグインが含まれています。settings.kubelet-device-plugins.nvidia 設定を通じて単一戦略で MIG を有効にします。Bottlerocket は、バージョン 1.34.0 以降で MIG をサポートしています。
前提条件
-
Amazon EKS クラスター。次の手順では、EKS 最適化 Bottlerocket NVIDIA AMI バージョン 1.34.0 以降を使用して、MIG 対応 P ファミリーノードをプロビジョニングします。
-
Karpenter がクラスターにインストールおよび設定されていること。それは、次の手順で、Karpenter
EC2NodeClassを使用して Bottlerocket ノードのユーザーデータに MIG 設定を指定するからです。詳細については、Karpenter ウェブサイトの「Karpenter の開始方法」を参照してください。 -
クラスターと通信するように
kubectlが設定されていること。詳細については、「kubectl をインストールまたは更新する」を参照してください。
手順
GPU ノードの Bottlerocket ユーザーデータに MIG パーティショニング設定を追加します。ユーザーデータの提供方法は、ノードのプロビジョニング方法によって異なります。次の例は、p4d.24xlarge ノード用の Karpenter EC2NodeClass を示しています。
cat <<EOF | kubectl apply -f - apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: gpu-bottlerocket-mig spec: amiFamily: Bottlerocket amiSelectorTerms: - alias: bottlerocket@latest role: eksctl-KarpenterNodeRole-<cluster-name> subnetSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> securityGroupSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> userData: | [settings.kubelet-device-plugins.nvidia] device-partitioning-strategy = "mig" [settings.kubelet-device-plugins.nvidia.mig.profile] "a100.40gb" = "2g.10gb" EOF
これらの設定でプロビジョニングされたノードがクラスターを結合すると、GPU で MIG モードが有効になり、各 GPU が 2g.10gb インスタンスにパーティション化され、デバイスプラグインは結果のインスタンスを nvidia.com/gpu リソースとしてアドバタイズします。p4d.24xlarge には 8 個の A100 GPU があり、それぞれが 3 個の 2g.10gb インスタンスをサポートしているため、ノードは nvidia.com/gpu: 24 をアドバタイズします。
注記
mig.profile 設定は、a100.40gb や h100.80gb などの GPU モデルによってキー指定されます。mig.profile 設定がない場合、GPU は MIG モードを有効にし、最大のプロファイルを使用します。Bottlerocket は単一戦略を使用するため、ノード上のすべての GPU は同じプロファイルを使用します。同じノードで異なるプロファイルを使用するには (混合戦略)、NVIDIA GPU Operator で AL2023 パスを使用します。
NVIDIA デバイスプラグインで AL2023 ノードの MIG を使用する
AL2023 では、次の手順で NVIDIA GPU Operator を使用して NVIDIA デバイスプラグインと MIG Manager をインストールします。MIG Manager は MIG モードを有効にし、指定した設定に従って GPU をパーティション化します。次に NVIDIA デバイスプラグインは、結果のインスタンスを Kubernetes にアドバタイズします。GPU Operator は、単一戦略と混合戦略の両方をサポートしています。
EKS 最適化 AL2023 NVIDIA AMI には NVIDIA ドライバーとツールキットが既に含まれているため、GPU Operator でドライバー管理を無効にして、プリインストールされているドライバーとの競合を回避します。または、GPU Operator を使用せずに NVIDIA デバイスプラグインと MIG Manager を自分でインストールおよび管理することもできます。
前提条件
-
Amazon EKS クラスター。次の手順では、EKS 最適化 AL2023 NVIDIA AMI を使用して MIG 対応 P ファミリーノード (
p4d.24xlargeなど) をプロビジョニングします。 -
Karpenter がクラスターにインストールおよび設定されていること。それは、この手順で、Karpenter
EC2NodeClassとNodePoolを作成して GPU ノードをプロビジョニングするからです。詳細については、Karpenter ウェブサイトの「Karpenter の開始方法」を参照してください。 -
コマンドライン環境に Helm がインストールされていること。詳細については、「Setup Helm instructions」を参照してください。
-
クラスターと通信するように
kubectlが設定されていること。詳細については、「kubectl をインストールまたは更新する」を参照してください。
手順
-
AL2023 P ファミリー GPU ノード用の
EC2NodeClassとNodePoolを作成します。AL2023 では、後のステップで GPU Operator によって MIG パーティショニングが適用されるため、これは標準の AL2023 GPU ノードクラスです。次の例では、EKS 最適化 AL2023 NVIDIA AMI を使用してp4d.24xlargeノードをプロビジョニングします。cat <<EOF | kubectl apply -f - apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: gpu-mig-al2023 spec: amiFamily: AL2023 amiSelectorTerms: - alias: al2023@latest role: eksctl-KarpenterNodeRole-<cluster-name> subnetSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> securityGroupSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> tags: karpenter.sh/discovery: <cluster-name> --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-mig-al2023 spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: gpu-mig-al2023 taints: - key: nvidia.com/gpu effect: NoSchedule requirements: - key: karpenter.sh/capacity-type operator: In values: ["spot", "on-demand"] - key: node.kubernetes.io/instance-type operator: In values: ["p4d.24xlarge"] - key: kubernetes.io/arch operator: In values: ["amd64"] limits: cpu: 1000 memory: 5000Gi EOF -
NVIDIA Helm リポジトリを追加します。
helm repo add nvidia https://nvidia.github.io/gpu-operator helm repo update -
ドライバー管理を無効にし、混合戦略を選択し、適用する MIG プロファイルを定義する
gpu-operator-values.yamlファイルを作成します。次の例では、p4d.24xlargeノード上の 8 個の GPU のうち 4 個をパーティション化し、残りのすべてをそのままにするp4d-half-balanced設定を定義します。cat <<EOF > gpu-operator-values.yaml driver: enabled: false toolkit: enabled: false devicePlugin: enabled: true nfd: enabled: true gfd: enabled: true mig: strategy: mixed migManager: enabled: true env: - name: WITH_REBOOT value: "true" config: create: true name: custom-mig-parted-configs default: all-disabled data: config.yaml: |- version: v1 mig-configs: all-disabled: - devices: all mig-enabled: false p4d-half-balanced: - devices: [0, 1, 2, 3] mig-enabled: true mig-devices: "1g.5gb": 2 "2g.10gb": 1 "3g.20gb": 1 - devices: [4, 5, 6, 7] mig-enabled: false EOF -
値ファイルを使用して GPU Operator をインストールします。
helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --values gpu-operator-values.yaml -
MIG 対応ノードに、適用するプロファイル設定をラベル付けします。MIG Manager コンポーネントはこのラベルを監視し、それに応じて GPU をパーティション化し、ノードを再起動して変更を適用します。
kubectl label nodes -l node.kubernetes.io/instance-type=p4d.24xlarge \ nvidia.com/mig.config=p4d-half-balanced --overwrite -
GPU Operator が GPU をパーティション化した後、Pod は
nvidia.com/gpuではなくそのリソース名で特定の MIG プロファイルをリクエストします。次の例では、1 つの1g.5gbインスタンスをリクエストする Pod を実行します。cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: mig-inference spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: limits: nvidia.com/mig-1g.5gb: 1 EOF
キャパシティ予約とプロファイルごとのワークロードを持つマネージドノードグループなど、P ファミリーインスタンスの完全な混合戦略の設定例については、「Amazon EKS ベストプラクティスガイド」の「MIG」セクションを参照してください。
MIG がアクティブであることを確認する
MIG 対応ノードが Ready になったら、MIG モードが GPU でアクティブであり、ノードが予想される MIG リソースをアドバタイズしていることを確認します。
-
ノードが MIG リソースをアドバタイズしていることを確認します。単一戦略では、ノードはインスタンスを
nvidia.com/gpuとしてレポートします。混合戦略では、ノードはnvidia.com/mig-1g.10gbなどのプロファイル固有のリソースをレポートします。kubectl describe node <node-name> | grep nvidia.com -
MIG 対応ノードの Pod から
nvidia-smiを実行して、MIG モードがアクティブであることを確認します。nvidia-smiは、MIG モードがオンになっている GPU のMIG M.: Enabledをレポートし、それぞれに設定されている MIG インスタンスを一覧表示します。以下は、MIG が有効で、3g.20gb、2g.10gb、および1g.5gbインスタンスにパーティション化された A100 40 GB GPU からの出力例です。+-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.159.03 Driver Version: 580.159.03 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA A100-SXM4-40GB On | 00000000:10:1C.0 Off | On | | N/A 35C P0 65W / 400W | 213MiB / 40960MiB | N/A Default | | | | Enabled | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | MIG devices: | +------------------+----------------------------------+-----------+-----------------------+ | GPU GI CI MIG | Shared Memory-Usage | Vol| Shared | | ID ID Dev | Shared BAR1-Usage | SM Unc| CE ENC DEC OFA JPG | | | | ECC| | |==================+==================================+===========+=======================| | 0 1 0 0 | 107MiB / 20096MiB | 42 0 | 3 0 2 0 0 | | | 0MiB / 12211MiB | | | +------------------+----------------------------------+-----------+-----------------------+ | 0 5 0 1 | 71MiB / 9984MiB | 28 0 | 2 0 1 0 0 | | | 0MiB / 6105MiB | | | +------------------+----------------------------------+-----------+-----------------------+ | 0 13 0 2 | 36MiB / 4864MiB | 14 0 | 1 0 0 0 0 | | | 0MiB / 3052MiB | | | +------------------+----------------------------------+-----------+-----------------------+混合戦略では、Pod はリクエストした MIG インスタンスのみを確認し、ノードの完全な GPU レイアウトは確認しません。前のステップの
mig-inferencePod は 1 つのnvidia.com/mig-1g.5gbインスタンスをリクエストしたため、その Pod 内のnvidia-smi -Lでは 1 つの MIG デバイスが一覧表示されます。kubectl logs mig-inference出力例は次のとおりです。
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-5b7ce860-1951-004c-4881-6ac6997df770) MIG 1g.5gb Device 0: (UUID: MIG-9b065868-21b6-5b8d-8ab9-e99089ed472c)ノード上のすべての GPU の完全なパーティションレイアウトを表示するには、ワークロード Pod 内の代わりにホストで
nvidia-smi -Lを実行します。次のコマンドは、ノードで特権デバッグ Pod を起動し、ホストのnvidia-smiを実行します。node-nameを MIG 対応ノードの名前に置き換えます。kubectl debug node/<node-name> -it --profile=sysadmin --image=nvidia/cuda:12.6.0-base-ubuntu22.04 -- chroot /host nvidia-smi -L以下は、
p4d-half-balanced設定の出力例です。最初の 4 個の GPU は MIG インスタンスにパーティション化され、残りの 4 個が全 GPU です。各MIG行は、独自の UUID、メモリ、コンピューティングスライスを持つハードウェア分離インスタンスです。GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-5b7ce860-1951-004c-4881-6ac6997df770) MIG 3g.20gb Device 0: (UUID: MIG-7dc16162-7ba2-5894-abde-d753dc8ecf56) MIG 2g.10gb Device 1: (UUID: MIG-56cfe1f0-0662-50e4-a5f7-111107e4d5e6) MIG 1g.5gb Device 2: (UUID: MIG-1409727e-2ffa-5fd4-9586-204c9e2b36d5) MIG 1g.5gb Device 3: (UUID: MIG-9b065868-21b6-5b8d-8ab9-e99089ed472c) GPU 1: NVIDIA A100-SXM4-40GB (UUID: GPU-73692a43-dd2d-f1a1-b0df-2f4734e2a87d) MIG 3g.20gb Device 0: (UUID: MIG-745fd93a-9582-57a6-8b3b-9782d289ca1b) MIG 2g.10gb Device 1: (UUID: MIG-8440294e-c4a0-5687-add5-2cc506babb2f) MIG 1g.5gb Device 2: (UUID: MIG-559810c0-f2bb-5ca2-b529-47228d99437f) MIG 1g.5gb Device 3: (UUID: MIG-a91cf3f9-6459-59e9-97a8-dc69b9958eef) GPU 2: NVIDIA A100-SXM4-40GB (UUID: GPU-4e56019e-84de-eef5-5ac3-85e468e93639) MIG 3g.20gb Device 0: (UUID: MIG-c130392b-fd7c-59f8-9f4b-ecab27a2984b) MIG 2g.10gb Device 1: (UUID: MIG-7d61cf16-ad08-57be-b2c2-ac6e515b28c3) MIG 1g.5gb Device 2: (UUID: MIG-f5388dec-d841-506c-bb7a-6ac136ceee53) MIG 1g.5gb Device 3: (UUID: MIG-02d54020-c6cb-5997-894b-e95af0f49388) GPU 3: NVIDIA A100-SXM4-40GB (UUID: GPU-4fd894a0-b471-9e77-eb67-0ad15002ed5b) MIG 3g.20gb Device 0: (UUID: MIG-10399b59-2625-5106-b3f8-76ae19da46e1) MIG 2g.10gb Device 1: (UUID: MIG-ef81ee7d-fc48-56ed-8479-8ffa76eb4154) MIG 1g.5gb Device 2: (UUID: MIG-ed9bf59d-6bf2-5e07-80fb-dd0d7ca41f9d) MIG 1g.5gb Device 3: (UUID: MIG-a15d6f7d-661b-514e-8838-06fe4ffe7f75) GPU 4: NVIDIA A100-SXM4-40GB (UUID: GPU-05b6b91b-da6e-3078-1f4f-a7bbf1ff7ed2) GPU 5: NVIDIA A100-SXM4-40GB (UUID: GPU-078a8df1-f387-0315-6b0b-af12e082f6d5) GPU 6: NVIDIA A100-SXM4-40GB (UUID: GPU-6cdeffe7-45f1-7e8e-bcc1-4634399ad877) GPU 7: NVIDIA A100-SXM4-40GB (UUID: GPU-5f68814a-4e4a-5dec-79b4-8d70a61c7714)
