

 **このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# Amazon EKS の NVIDIA GPU でマルチインスタンス GPU (MIG) を使用する
<a name="device-management-nvidia-mig"></a>

 [マルチインスタンス GPU](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/index.html) (MIG) は、単一の物理 GPU を複数の分離されたインスタンスにパーティション化する NVIDIA GPU のハードウェア機能です。パーティション化されたインスタンスの最大数は GPU によって異なります。各インスタンスには専用メモリ、コンピューティングユニット、メモリ帯域幅があるため、あるインスタンスで実行されるワークロードが別のインスタンスのワークロードに影響を与えることはありません。分離なしでソフトウェアのタイムマルチプレクシングを通じて GPU を共有する[タイムスライシング](device-management-nvidia-time-slicing.md)とは異なり、MIG は Pod 間でハードウェアレベルのメモリと障害分離を提供します。

MIG は、予測可能なサービスの品質を必要とするマルチテナント推論やワークロードに最適です。NVIDIA Ampere (A100)、Hopper (H100 と H200)、および Blackwell GPU で使用できます。AWS では、これらは P ファミリーインスタンスタイプと、Blackwell ベースの `g7` および `g7e` インスタンスタイプです。利用できるタイムゾーンの一覧については、「[MIG 対応インスタンスタイプ](#eks-mig-capable-instance-types)」を参照してください。

MIG は、次の場合に適しています:
+ あるワークロードが別のワークロードに必要な GPU メモリを消費できないようにするために、メモリの分離が必要である。
+ テナントが GPU ハードウェアを共有するけれども、テナントごとのサービス品質が必要なマルチテナント推論を実行する。
+ A100、H100、H200、または Blackwell インスタンスでトレーニングを既に実行しており、トレーニングがアイドル状態のときに、これらの GPU を小規模な推論ワークロードに再利用したいと考えている。

次の場合は、別のアプローチを検討してください:
+ ノードが、`g5`、`g6`、`g6e` ファミリーなど、MIG をサポートしていない GPU インスタンスタイプを使用している。代わりに[タイムスライシング](device-management-nvidia-time-slicing.md)を使用します。
+ メモリを分離する必要はなく、最も簡単な設定を望んでいる。代わりに[タイムスライシング](device-management-nvidia-time-slicing.md)を使用します。
+ GPU パーティションを中断することなく頻繁に変更する必要がある。MIG モードまたはパーティションレイアウトを変更するには、GPU のリセットが必要です。GPU オペレータはノードを再起動してこれを実行します。
+ GPU 間の集合通信またはピアツーピア通信に依存するマルチ GPU トレーニングを実行している。MIG は NCCL またはクロス GPU P2P をサポートしていません。

## 考慮事項
<a name="eks-mig-considerations"></a>

本番環境で MIG を使用する前に、以下の考慮事項を確認してください。

### 一般的な考慮事項
<a name="_general_considerations"></a>
+  **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 ユーザーガイドの「[アプリケーションに関する考慮事項](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html#application-considerations)」を参照してください。

### NVIDIA デバイスプラグインに関する考慮事項
<a name="_nvidia_device_plugin_considerations"></a>
+  **ポッドリソースリクエストは、戦略と一致する必要があります。**単一戦略では、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 デバイスプラグインを管理し、その設定を公開しません ([加速ワークロードをデプロイする](auto-accelerated.md) を参照)。EKS Auto Mode ノードで MIG を有効にすることはできません。AMI とデバイスプラグインの設定を制御するセルフマネージド Karpenter ノードまたはマネージドノードグループで MIG を設定します。

### NVIDIA DRA ドライバーに関する考慮事項
<a name="_nvidia_dra_driver_considerations"></a>
+  **静的 MIG には、事前に作成されたインスタンスが必要です。**静的 MIG では、DRA ドライバーは既存の MIG インスタンスを割り当てますが、MIG モードを有効にしたり GPU をパーティション化したりしません。まず MIG モードを有効にし、インスタンスを作成する必要があります。例えば、NVIDIA GPU Operator の MIG Manager または `nvidia-smi` を使用します。詳細については、「[NVIDIA DRA ドライバーで MIG を使用する](#eks-mig-dra-driver)」を参照してください。
+  **動的 MIG はアルファ機能です。**動的 MIG を使用すると、ドライバーはワークロードリクエストに応じてオンデマンドで MIG パーティションを作成および破棄します。`DynamicMIG` 機能ゲートが必要です。これはデフォルトで無効になっています。詳細については、「[NVIDIA DRA ドライバーで MIG を使用する](#eks-mig-dra-driver)」を参照してください。
+  **Bottlerocket の組み込みデバイスプラグインを無効にします。**DRA ドライバーは、同じノード上の NVIDIA デバイスプラグインと一緒に実行することはできません。Bottlerocket で、組み込みデバイスプラグインを無効にします。これには Bottlerocket バージョン 1.63.0 以降が必要です。詳細については、「[NVIDIA DRA ドライバーをインストールする](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver)」を参照してください。
+  **コンピューティングのサポート。**NVIDIA DRA ドライバーは、Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードの静的キャパシティのプロビジョニングでサポートされており、EKS Auto Mode ではサポートされていません。詳細については、Karpenter ウェブサイトの「[Karpenter 静的 NodePool ドキュメント](https://karpenter.sh/docs/concepts/nodepools/#static-nodepool)」を参照してください。

## MIG 対応インスタンスタイプ
<a name="eks-mig-capable-instance-types"></a>

AWS では、次のインスタンスタイプが MIG 対応 GPU を提供します。


| インスタンスタイプ | GPU | GPU メモリ | 
| --- | --- | --- | 
|  `p4d.24xlarge`  | 8 x NVIDIA A100 40 GB | 320 GB | 
|  `p4de.24xlarge`  | 8 x NVIDIA A100 80 GB | 640 GB | 
|  `p5.48xlarge`  | 8 x NVIDIA H100 80 GB | 640 GB | 
|  `p5e.48xlarge`  | 8 x NVIDIA H200 | 1128 GB | 
|  `p5en.48xlarge`  | 8 x NVIDIA H200 | 1128 GB | 
|  `p6-b200.48xlarge`  | 8 x NVIDIA Blackwell B200 | 1432 GB | 
|  `p6-b300.48xlarge`  | 8 x NVIDIA Blackwell Ultra B300 | 2144 GB | 
|  `g7.48xlarge`  | 8 x NVIDIA RTX PRO 4500 Blackwell Server Edition | 256 GB | 
|  `g7e.48xlarge`  | 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 を使用する](ml-eks-nvidia-ultraserver.md) を参照してください。

**注記**  
`g7` インスタンスタイプには NVIDIA ドライバーバージョン 595 以降が必要です。EKS 最適化高速 AMI には、現在 NVIDIA ドライバーバージョン 580 が含まれているため、`g7` で MIG を使用するには、ドライバーバージョン 595 でカスタム AMI を構築する必要があります。詳細については、「[EKS に最適化されたカスタム Amazon Linux AMI の構築](eks-ami-build-scripts.md)」を参照してください。

MIG インスタンスは、命名パターン `<slices>g.<memory>gb` を使用するプロファイルによって記述されます。ここで、`<slices>` はコンピューティングスライスの数で、`<memory>` はギガバイト単位でのインスタンスのメモリです。例えば、`3g.40gb` プロファイルは 7 個のコンピューティングスライスのうち 3 個と 40 GB のメモリを提供します。各 GPU がサポートするプロファイルは、ハードウェアによって固定されます。完全なリストについては、NVIDIA ウェブサイトの「[NVIDIA マルチインスタンス GPU ユーザーガイド](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/)」を参照してください。

## インスタンスタイプあたりの MIG プロファイル
<a name="eks-mig-profiles-per-instance-type"></a>

ノードで使用できる MIG プロファイルは、インスタンスタイプの GPU によって異なります。以下のセクションでは、MIG 対応の各 Amazon EC2 インスタンスタイプのプロファイルを一覧表示します。各プロファイルの**最大インスタンス**は、単一の GPU で作成できるそのプロファイルの最大インスタンス数で、**インスタンスあたりのメモリ**は、それぞれに割り当てられた GPU メモリです。

### `p4d.24xlarge` – NVIDIA A100 40 GB
<a name="eks-mig-profiles-p4d"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.5gb`  | 1/7 | 5 GB | 7 | 
|  `1g.10gb`  | 1/7 | 10 GB | 4 | 
|  `2g.10gb`  | 2/7 | 10 GB | 3 | 
|  `3g.20gb`  | 3/7 | 20 GB | 2 | 
|  `4g.20gb`  | 4/7 | 20 GB | 1 | 
|  `7g.40gb`  | 7/7 | 40 GB | 1 | 

### `p4de.24xlarge` – NVIDIA A100 80 GB
<a name="eks-mig-profiles-p4de"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1/7 | 10 GB | 7 | 
|  `1g.20gb`  | 1/7 | 20 GB | 4 | 
|  `2g.20gb`  | 2/7 | 20 GB | 3 | 
|  `3g.40gb`  | 3/7 | 40 GB | 2 | 
|  `4g.40gb`  | 4/7 | 40 GB | 1 | 
|  `7g.80gb`  | 7/7 | 80 GB | 1 | 

### `p5.48xlarge` – NVIDIA H100 80 GB
<a name="eks-mig-profiles-p5"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1/7 | 10 GB | 7 | 
|  `1g.20gb`  | 1/7 | 20 GB | 4 | 
|  `2g.20gb`  | 2/7 | 20 GB | 3 | 
|  `3g.40gb`  | 3/7 | 40 GB | 2 | 
|  `4g.40gb`  | 4/7 | 40 GB | 1 | 
|  `7g.80gb`  | 7/7 | 80 GB | 1 | 

### `p5e.48xlarge` と `p5en.48xlarge` – NVIDIA H200 141 GB
<a name="eks-mig-profiles-p5e-p5en"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.18gb`  | 1/7 | 18 GB | 7 | 
|  `1g.35gb`  | 1/7 | 35 GB | 4 | 
|  `2g.35gb`  | 2/7 | 35 GB | 3 | 
|  `3g.71gb`  | 3/7 | 71 GB | 2 | 
|  `4g.71gb`  | 4/7 | 71 GB | 1 | 
|  `7g.141gb`  | 7/7 | 141 GB | 1 | 

### `p6-b200.48xlarge` – NVIDIA Blackwell B200 180 GB
<a name="eks-mig-profiles-p6-b200"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.23gb`  | 1/7 | 23 GB | 7 | 
|  `1g.45gb`  | 1/7 | 45 GB | 4 | 
|  `2g.45gb`  | 2/7 | 45 GB | 3 | 
|  `3g.90gb`  | 3/7 | 90 GB | 2 | 
|  `4g.90gb`  | 4/7 | 90 GB | 1 | 
|  `7g.180gb`  | 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 プロファイル](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html)」を参照してください。

### `g7.48xlarge` – NVIDIA RTX PRO 4500 Blackwell Server Edition 32 GB
<a name="eks-mig-profiles-g7"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.16gb`  | 1/2 | 16 GB | 2 | 
|  `2g.32gb`  | 2/2 | 32 GB | 1 | 

RTX PRO 4500 Blackwell は、グラフィックス対応 (`+gfx`) およびメディアエンジン (`+me.all`、`-me`) プロファイルバリアントもサポートしています。詳細なリストについては、NVIDIA ウェブサイトの「[NVIDIA がサポートする MIG プロファイル](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html)」を参照してください。

### `g7e.48xlarge` – NVIDIA RTX PRO 6000 Blackwell Server Edition 96 GB
<a name="eks-mig-profiles-g7e"></a>


| プロファイル | コンピューティングスライス | インスタンスあたりのメモリ | 最大インスタンス | 
| --- | --- | --- | --- | 
|  `1g.24gb`  | 1/4 | 24 GB | 4 | 
|  `2g.48gb`  | 2/4 | 48 GB | 2 | 
|  `4g.96gb`  | 4/4 | 96 GB | 1 | 

RTX PRO 6000 Blackwell Server Edition は、グラフィックス対応 (`+gfx`) およびメディアエンジン (`+me.all`、`-me`) プロファイルバリアントもサポートしています。詳細なリストについては、NVIDIA ウェブサイトの「[NVIDIA がサポートする MIG プロファイル](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html)」を参照してください。

## MIG 戦略
<a name="eks-mig-strategies"></a>

NVIDIA DRA ドライバーと NVIDIA デバイスプラグインは、さまざまな方法で MIG インスタンスを Kubernetes に公開します。デバイスプラグインはノード全体の **MIG 戦略**設定を使用しますが、DRA ドライバーは属性によってインスタンスを選択するため、同等の設定はありません。この違いを理解することは、2 つのモデルから選択する上で重要です。

### NVIDIA DRA ドライバー
<a name="_nvidia_dra_driver"></a>

NVIDIA DRA ドライバーは単一または混合戦略の概念を使用しないため、同等の設定を構成することはできません。MIG インスタンスをカウントされたリソースとしてアドバタイズする代わりに、ドライバーは各インスタンスを `mig.nvidia.com` `DeviceClass` のデバイスとして、その `profile` などの属性とともに発行します。Pod は、[NVIDIA DRA ドライバーで MIG を使用する](#eks-mig-dra-driver) に示すように、これらの属性を `ResourceClaim` または `ResourceClaimTemplate` の共通表現言語 (CEL) セレクターと照合してインスタンスを選択します。

選択はインスタンスごとに行われるため、混合プロファイルノードは戦略モードの切り替えなしで機能します。単一の GPU を複数の異なるプロファイルに分割でき、各クレームで必要なプロファイルが選択されます。DRA ドライバーにとって重要な選択は、単一戦略か混合戦略ではなく、静的 MIG か動的 MIG であり、MIG インスタンスを事前に作成するか、ドライバーがオンデマンドで作成するかを制御します。詳細については、「[NVIDIA DRA ドライバーで MIG を使用する](#eks-mig-dra-driver)」を参照してください。

### NVIDIA デバイスプラグイン
<a name="_nvidia_device_plugin"></a>

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](https://github.com/bottlerocket-os/bottlerocket/issues/4483)」を参照してください。

## NVIDIA DRA ドライバーで MIG を使用する
<a name="eks-mig-dra-driver"></a>

NVIDIA DRA ドライバーを使用して MIG インスタンスを割り当てると、Pod はデバイスプラグインの `nvidia.com/mig-<profile>` 拡張リソースではなく、`ResourceClaim` または `ResourceClaimTemplate` を介して MIG インスタンスをリクエストします。

DRA ドライバーは、カウントされたリソースとしてではなく属性でインスタンスを記述するため、デバイスプラグインが必要とする単一戦略または混合戦略を使用しません ([MIG 戦略](#eks-mig-strategies) を参照)。ドライバーは、各 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 を使用する](#eks-mig-device-plugin-al2023) で説明されているように、NVIDIA GPU Operator の MIG Manager を使用します。ドライバーは既存のインスタンスを検出して Pod に割り当てますが、ノードの MIG 設定は変更しません。ドライバーの起動後に追加されたインスタンスは、GPU kubelet プラグインが再起動するまで検出されません。静的 MIG はデフォルトであり、機能ゲートは必要ありません。
+  **動的 MIG** – ドライバーはワークロードリクエストに応じてオンデマンドで MIG パーティションを作成および破棄するため、GPU を事前にパーティション化する必要はありません。動的 MIG は、デフォルトで無効になっているアルファ機能です。次のセクションに示すのと同じ `ResourceClaimTemplate` セレクターを使用してプロファイルをリクエストすると、ドライバーはリクエストを満たすために GPU をパーティション化します。

### 考慮事項
<a name="_considerations"></a>
+ 動的 MIG は、ノードの静的検出を置き換えます。ドライバーはすべてのパーティションを管理し、GPU kubelet プラグインの起動時に作成されなかった MIG パーティションを破棄します。保持する事前に作成されたパーティションがあるノードで動的 MIG を有効にしないでください。また、プラグインの実行中に `mig-parted` または `nvidia-smi mig` を実行しないでください。それは、手動の変更がドライバーのパーティション状態と競合し、Pod の準備またはクリーンアップが失敗する可能性があるからです。
+ 動的 MIG はアルファ状態であり、NVIDIA DRA ドライバーのインストール時に機能ゲートを有効にする必要があります。手順については、[NVIDIA DRA ドライバーをインストールする](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver) を参照してください。
+ Hopper (H100 および H200) 以降のアーキテクチャは、オンデマンドで MIG モードを有効にします。以前の世代では、Ampere (A100) GPU など、オンデマンドで MIG モードを有効にできません。
+ 動的 MIG は、Kubernetes バージョン 1.36 以降でデフォルトで有効になっている、Kubernetes のパーティション化可能なデバイス機能 (GitHub の [KEP-4815](https://github.com/kubernetes/enhancements/issues/4815)) に依存しています。以前のバージョンでは、この機能はデフォルトで有効になっていないため、スケジューラは動的に作成された MIG デバイスを割り当てることができません。

### 前提条件
<a name="_prerequisites"></a>
+ Amazon EKS クラスターで Kubernetes バージョン 1.34 以降を実行していて、Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードグループによって静的キャパシティがプロビジョニングされていること。
+ MIG モードが有効で GPU が MIG インスタンスにパーティション化された MIG 対応 P ファミリーノード。静的 MIG については、NVIDIA ウェブサイトの「[NVIDIA GPU Operator の MIG Manager](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html)」を参照してください。
+ [NVIDIA DRA ドライバーをインストールする](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver) で説明されているようにインストールされた NVIDIA DRA ドライバー。静的 MIG パーティショニングを使用していない場合は、オプションで動的 MIG が有効にされている。

### 手順
<a name="_procedure"></a>

次の例は、静的または動的な MIG および NVIDIA DRA ドライバーで使用できます。

1. `mig.nvidia.com` `DeviceClass` から 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
   ```

1. 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 プロファイルをリクエストする
<a name="_request_a_specific_mig_profile"></a>

使用可能なインスタンスの代わりに特定のプロファイルをリクエストするには、`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 インスタンスをリクエストする
<a name="_request_multiple_mig_instances_from_the_same_gpu"></a>

単一のクレーム内の複数の 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 を使用する
<a name="eks-mig-device-plugin-bottlerocket"></a>

Bottlerocket では、EKS 最適化高速 AMI には NVIDIA デバイスプラグインが含まれています。`settings.kubelet-device-plugins.nvidia` 設定を通じて単一戦略で MIG を有効にします。Bottlerocket は、バージョン 1.34.0 以降で MIG をサポートしています。

### 前提条件
<a name="_prerequisites_2"></a>
+ Amazon EKS クラスター。次の手順では、EKS 最適化 Bottlerocket NVIDIA AMI バージョン 1.34.0 以降を使用して、MIG 対応 P ファミリーノードをプロビジョニングします。
+ Karpenter がクラスターにインストールおよび設定されていること。それは、次の手順で、Karpenter `EC2NodeClass` を使用して Bottlerocket ノードのユーザーデータに MIG 設定を指定するからです。詳細については、Karpenter ウェブサイトの「[Karpenter の開始方法](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/)」を参照してください。
+  クラスターと通信するように `kubectl` が設定されていること。詳細については、「[`kubectl` をインストールまたは更新する](install-kubectl.md#kubectl-install-update)」を参照してください。

### 手順
<a name="_procedure_2"></a>

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 を使用する
<a name="eks-mig-device-plugin-al2023"></a>

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 を自分でインストールおよび管理することもできます。

### 前提条件
<a name="_prerequisites_3"></a>
+ Amazon EKS クラスター。次の手順では、EKS 最適化 AL2023 NVIDIA AMI を使用して MIG 対応 P ファミリーノード (`p4d.24xlarge` など) をプロビジョニングします。
+ Karpenter がクラスターにインストールおよび設定されていること。それは、この手順で、Karpenter `EC2NodeClass` と `NodePool` を作成して GPU ノードをプロビジョニングするからです。詳細については、Karpenter ウェブサイトの「[Karpenter の開始方法](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/)」を参照してください。
+ コマンドライン環境に Helm がインストールされていること。詳細については、「[Setup Helm instructions](helm.md)」を参照してください。
+  クラスターと通信するように `kubectl` が設定されていること。詳細については、「[`kubectl` をインストールまたは更新する](install-kubectl.md#kubectl-install-update)」を参照してください。

### 手順
<a name="_procedure_3"></a>

1. 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
   ```

1. NVIDIA Helm リポジトリを追加します。

   ```
   helm repo add nvidia https://nvidia.github.io/gpu-operator
   helm repo update
   ```

1. ドライバー管理を無効にし、混合戦略を選択し、適用する 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
   ```

1. 値ファイルを使用して GPU Operator をインストールします。

   ```
   helm install gpu-operator nvidia/gpu-operator \
       --namespace gpu-operator \
       --create-namespace \
       --values gpu-operator-values.yaml
   ```

1. MIG 対応ノードに、適用するプロファイル設定をラベル付けします。MIG Manager コンポーネントはこのラベルを監視し、それに応じて GPU をパーティション化し、ノードを再起動して変更を適用します。

   ```
   kubectl label nodes -l node.kubernetes.io/instance-type=p4d.24xlarge \
       nvidia.com/mig.config=p4d-half-balanced --overwrite
   ```

1. 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 ベストプラクティスガイド](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html)」の「MIG」セクションを参照してください。

## MIG がアクティブであることを確認する
<a name="eks-mig-verify"></a>

MIG 対応ノードが `Ready` になったら、MIG モードが GPU でアクティブであり、ノードが予想される MIG リソースをアドバタイズしていることを確認します。

1. ノードが MIG リソースをアドバタイズしていることを確認します。単一戦略では、ノードはインスタンスを `nvidia.com/gpu` としてレポートします。混合戦略では、ノードは `nvidia.com/mig-1g.10gb` などのプロファイル固有のリソースをレポートします。

   ```
   kubectl describe node <node-name> | grep nvidia.com
   ```

1. 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-inference` Pod は 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)
   ```