**Unterstützung für die Verbesserung dieser Seite beitragen** 

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub ** Link Diese Seite ** bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Verwenden Sie Mehrinstanz-GPUs (MIG) mit NVIDIA-GPUs auf Amazon EKS
<a name="device-management-nvidia-mig"></a>

 [Multi-Instance GPU ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/index.html) (MIG) ist eine Hardwarefunktion auf NVIDIA-GPUs, die eine einzelne physische GPU in mehrere isolierte Instanzen partitioniert. Die maximale Anzahl partitionierter Instanzen hängt von der GPU ab. Jede Instanz hat dedizierten Speicher, Recheneinheiten und Speicherbandbreite, sodass ein Workload, der auf einer Instance ausgeführt wird, keinen Workload auf einer anderen beeinflussen kann. Im Gegensatz zum [ Time-Slicing](device-management-nvidia-time-slicing.md), bei dem eine GPU durch Software-Zeitmultiplexing ohne Isolierung gemeinsam genutzt wird, bietet MIG Speicher auf Hardwareebene und Fehlerisolierung zwischen Pods.

MIG eignet sich am besten für Multi-Tenant-Inferenzen und Workloads, die eine vorhersehbare Servicequalität erfordern. Es ist auf NVIDIA Ampere (A100), Hopper (H100 und H200) und Blackwell-GPUs verfügbar. On AWS, dies sind die Instance-Typen und die P-family Instance-Typen. Blackwell-based `g7` `g7e` Eine vollständige Liste finden Sie unter [MIG-capable Instanztypen](#eks-mig-capable-instance-types).

MIG ist eine gute Wahl, wenn:
+ Sie benötigen eine Speicherisolierung, damit ein Workload nicht den GPU-Speicher beanspruchen kann, den ein anderer Workload benötigt.
+ Sie führen Multi-Tenant-Inferenz durch, bei der sich die Mandanten die GPU-Hardware teilen, aber eine Servicequalität pro Mandant benötigen.
+ Sie führen bereits Schulungen auf A100-, H100-, H200- oder Blackwell-Instances durch und möchten diese GPUs für kleinere Inferenz-Workloads wiederverwenden, wenn das Training inaktiv ist.

Erwägen Sie einen anderen Ansatz, wenn:
+ Ihre Knoten verwenden einen GPU-Instance-Typ, der MIG nicht unterstützt, wie z. B. die `g6e` Familien `g5``g6`, oder. Verwenden Sie stattdessen [ Time-Slicing. ](device-management-nvidia-time-slicing.md)
+ Sie benötigen keine Speicherisolierung und möchten die einfachste Konfiguration. Verwenden Sie stattdessen [ Time-Slicing. ](device-management-nvidia-time-slicing.md)
+ Sie müssen die GPU-Partitionen häufig und ohne Unterbrechung ändern. Das Ändern des MIG-Modus oder des Partitionslayouts erfordert einen GPU-Reset, den der GPU-Operator durch einen Neustart des Knotens durchführt.
+ Sie führen ein Training mit mehreren GPUs durch, das von der kollektiven oder Peer-to-Peer-Kommunikation zwischen GPUs abhängt. MIG unterstützt weder NCCL noch Cross-GPU-P2P.

## Überlegungen
<a name="eks-mig-considerations"></a>

Lesen Sie die folgenden Überlegungen, bevor Sie MIG in der Produktion verwenden.

### Allgemeine Überlegungen
<a name="_general_considerations"></a>
+  **Das Ändern der MIG-Konfiguration erfordert einen GPU-Reset. ** Das Aktivieren oder Deaktivieren des MIG-Modus oder das Ändern des Partitionslayouts erfordert einen GPU-Reset, sodass er nicht an Ort und Stelle geändert werden kann. Beispielsweise wendet der MIG Manager im NVIDIA GPU Operator eine Konfigurationsänderung an, indem er die GPU-Pods auf dem Knoten stoppt und den Knoten neu startet, wenn ein Neustart erforderlich ist, um den MIG-Modus zu ändern.
+  **Die Rechenleistung ist nicht strikt proportional zur Instanzgröße. ** Eine `1g` Instance liefert nicht für jeden Workload einen proportionalen Anteil des gesamten GPU-Durchsatzes, da sich Speicherbandbreite und Cacheverhalten von Profil zu Profil unterscheiden. Vergleichen Sie Ihre Arbeitslast anhand des Profils, das Sie verwenden möchten, bevor Sie die Größe der Partitionen festlegen.
+  **Time-slicing hat keine Auswirkungen auf MIG-Instances. ** Eine MIG-Instance ist bereits hardwareseitig isoliert und kann nicht durch Time-Slicing weiter geteilt werden. Das Anfordern der `TimeSlicing` Sharing-Strategie auf einem MIG-Gerät ändert nichts an dem Hardwareverhalten. Verwenden Sie stattdessen NVIDIA Multi-Process Service (MPS), um eine einzelne MIG-Instanz containerübergreifend gemeinsam zu nutzen.
+  **Eingeschränkte GPU-übergreifende Kommunikation. ** Wenn MIG aktiviert ist, können MIG-Instances auf verschiedenen GPUs keine GPU-to-GPU Peer-to-Peer-Kommunikation (P2P) verwenden, und NCCL funktioniert nicht mit MIG. Multi-GPU Workloads, die von kollektiver Kommunikation oder P2P zwischen GPUs abhängen, wie z. B. tensorparalleles Training mit mehreren GPUs, erfordern stattdessen ganze GPUs. Einzelheiten finden Sie in den [ Anwendungsüberlegungen ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html#application-considerations) im NVIDIA MIG-Benutzerhandbuch auf der NVIDIA-Website.

### Überlegungen zum NVIDIA-Geräte-Plugin
<a name="_nvidia_device_plugin_considerations"></a>
+  **Pod-Ressourcenanforderungen müssen der Strategie entsprechen. ** Bei der Einzelstrategie fordern Pods an`nvidia.com/gpu`. Bei der gemischten Strategie fordern Pods die profilspezifische Ressource an, z. B. `nvidia.com/mig-1g.10gb` Ein Pod, der ein Profil anfordert, das der Knoten nicht ankündigt, bleibt im `Pending` Status. Bestätigen Sie die angekündigten Ressourcen mit`kubectl describe node <node-name>`.
+  **Standalone-Geräte-Plugin auf AL2023. ** Wenn Sie das NVIDIA-Geräte-Plugin separat installieren, z. B. als Teil des Cluster-Setups, schließen Sie es von Ihren MIG-Knoten aus, damit es nicht zu Konflikten mit dem Geräte-Plugin kommt, das der GPU-Operator verwaltet. Fügen Sie dem Standalone-Geräte-Plugin eine Knotenaffinitätsregel hinzu, die Knoten ausschließt, die das `nvidia.com/mig.config` Label tragen.
+  **Keine Unterstützung für den EKS-Automatikmodus. ** EKS Auto Mode verwaltet das NVIDIA-Geräte-Plugin und macht seine Konfiguration nicht verfügbar (siehe[Einen beschleunigten Workload bereitstellen](auto-accelerated.md)). Sie können MIG nicht auf EKS-Auto-Mode-Knoten aktivieren. Konfigurieren Sie MIG auf selbstverwalteten Karpenter-Knoten oder einer verwalteten Knotengruppe, in der Sie die AMI- und Geräte-Plug-in-Einstellungen steuern.

### Überlegungen zum NVIDIA DRA-Treiber
<a name="_nvidia_dra_driver_considerations"></a>
+  **Statische MIG erfordert vorab erstellte Instanzen. ** Bei statischer MIG weist der DRA-Treiber vorhandene MIG-Instances zu, aktiviert jedoch nicht den MIG-Modus und partitioniert die GPUs nicht. Sie müssen den MIG-Modus aktivieren und die Instanzen zuerst erstellen, z. B. mit dem MIG Manager im NVIDIA GPU Operator oder. `nvidia-smi` Weitere Informationen finden Sie unter [Verwenden Sie MIG mit dem NVIDIA DRA-Treiber](#eks-mig-dra-driver).
+  **Dynamic MIG ist eine Alpha-Funktion. ** Bei dynamischer MIG erstellt und zerstört der Treiber MIG-Partitionen bei Bedarf als Reaktion auf Workload-Anforderungen. Dazu ist das `DynamicMIG` Feature Gate erforderlich, das standardmäßig deaktiviert ist. Weitere Informationen finden Sie unter [Verwenden Sie MIG mit dem NVIDIA DRA-Treiber](#eks-mig-dra-driver).
+  **Deaktivieren Sie das integrierte Geräte-Plugin auf Bottlerocket. ** Der DRA-Treiber kann nicht zusammen mit dem NVIDIA-Geräte-Plugin auf demselben Knoten ausgeführt werden. Deaktivieren Sie auf Bottlerocket das integrierte Geräte-Plug-In, für das Bottlerocket Version 1.63.0 oder höher erforderlich ist. Weitere Informationen finden Sie unter [Installieren Sie den NVIDIA DRA-Treiber](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver).
+  **Compute-Unterstützung. ** Der NVIDIA DRA-Treiber wird bei der statischen Kapazitätsbereitstellung in Karpenter, EKS-verwalteten Knotengruppen oder selbstverwalteten Knoten unterstützt und im EKS-Automatikmodus nicht unterstützt. Weitere Informationen finden Sie in der statischen NodePool Karpenter-Dokumentation auf der [ Karpenter-Website. ](https://karpenter.sh/docs/concepts/nodepools/#static-nodepool)

## MIG-capable Instanztypen
<a name="eks-mig-capable-instance-types"></a>

Nein AWS, die folgenden Instanztypen stellen MIG-capable GPUs bereit.


| Instance-Typ | GPUs | GPU-Arbeitsspeicher | 
| --- | --- | --- | 
|  `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 | 128 GB | 
|  `p5en.48xlarge`  | 8 x NVIDIA H200 | 128 GB | 
|  `p6-b200.48xlarge`  | 8 x NVIDIA Blackwell B200 | 1432 GB | 
|  `p6-b300.48xlarge`  | 8 x NVIDIA Blackwell Ultra B300 | 214 GB | 
|  `g7.48xlarge`  | 8 x NVIDIA RTX PRO 4500 Blackwell Serverausgabe | 256 GB | 
|  `g7e.48xlarge`  | 8 x NVIDIA RTX PRO 6000 Blackwell Serverausgabe | 768 GB | 

MIG ist für die `g6e` Familien`g5`,`g6`, oder nicht verfügbar. Informationen dazu `p6e-gb200` UltraServers, welche die MIG-capable NVIDIA GB200-GPU verwenden, finden Sie unter[P6e-GB200 UltraServers Mit Amazon EKS verwenden](ml-eks-nvidia-ultraserver.md).

**Anmerkung**  
Für den `g7` Instanztyp ist die NVIDIA-Treiberversion 595 oder höher erforderlich. Die EKS-optimized beschleunigten AMIs enthalten derzeit die NVIDIA-Treiberversion 580. Um MIG verwenden zu können, müssen `g7` Sie also ein benutzerdefiniertes AMI mit der Treiberversion 595 erstellen. Weitere Informationen finden Sie unter [Erstellen Sie ein benutzerdefiniertes EKS-optimized Amazon Linux AMI](eks-ami-build-scripts.md).

MIG-Instances werden durch Profile beschrieben, die das Benennungsmuster `<slices>g.<memory>gb` verwenden. Dabei `<slices>` handelt es sich um die Anzahl der `<memory>` Compute-Slices und um den Arbeitsspeicher der Instance in Gigabyte. Das `3g.40gb` Profil bietet beispielsweise drei der sieben Rechenbereiche und 40 GB Arbeitsspeicher. Die Profile, die jede GPU unterstützt, werden von der Hardware festgelegt. Die vollständige Liste finden Sie im [ Multi-Instance NVIDIA-GPU-Benutzerhandbuch ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) auf der NVIDIA-Website.

## MIG-Profile pro Instanztyp
<a name="eks-mig-profiles-per-instance-type"></a>

Die auf einem Knoten verfügbaren MIG-Profile hängen von der GPU für den Instanztyp ab. In den folgenden Abschnitten sind die Profile für jeden MIG-capable Amazon EC2-Instance-Typ aufgeführt. Für jedes Profil ** ist ** Max Instances die maximale Anzahl von Instances dieses Profils, die Sie auf einer einzelnen GPU erstellen können, und ** Memory per Instance ** ist der GPU-Speicher, der jedem Profil zugewiesen ist.

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


| Profil | Segmente berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.5gb`  | 1 von 7 | 5 GB | 7 | 
|  `1g.10gb`  | 1 von 7 | 10 GB | 4 | 
|  `2g.10gb`  | 2 von 7 | 10 GB | 3 | 
|  `3g.20gb`  | 3 von 7 | 20 GB | 2 | 
|  `4g.20gb`  | 4 von 7 | 20 GB | 1 | 
|  `7g.40gb`  | 7 von 7 | 40 GB | 1 | 

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


| Profil | Segmente berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1 von 7 | 10 GB | 7 | 
|  `1g.20gb`  | 1 von 7 | 20 GB | 4 | 
|  `2g.20gb`  | 2 von 7 | 20 GB | 3 | 
|  `3g.40gb`  | 3 von 7 | 40 GB | 2 | 
|  `4g.40gb`  | 4 von 7 | 40 GB | 1 | 
|  `7g.80gb`  | 7 von 7 | 80 GB | 1 | 

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


| Profil | Segmente berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1 von 7 | 10 GB | 7 | 
|  `1g.20gb`  | 1 von 7 | 20 GB | 4 | 
|  `2g.20gb`  | 2 von 7 | 20 GB | 3 | 
|  `3g.40gb`  | 3 von 7 | 40 GB | 2 | 
|  `4g.40gb`  | 4 von 7 | 40 GB | 1 | 
|  `7g.80gb`  | 7 von 7 | 80 GB | 1 | 

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


| Profil | Segmente berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.18gb`  | 1 von 7 | 18 GB | 7 | 
|  `1g.35gb`  | 1 von 7 | 35 GB | 4 | 
|  `2g.35gb`  | 2 von 7 | 35 GB | 3 | 
|  `3g.71gb`  | 3 von 7 | 71 GB | 2 | 
|  `4g.71gb`  | 4 von 7 | 71 GB | 1 | 
|  `7g.141gb`  | 7 von 7 | 141 GB | 1 | 

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


| Profil | Scheiben berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.23gb`  | 1 von 7 | 23 GB | 7 | 
|  `1g.45gb`  | 1 von 7 | 45 GB | 4 | 
|  `2g.45gb`  | 2 von 7 | 45 GB | 3 | 
|  `3g.90gb`  | 3 von 7 | 90 GB | 2 | 
|  `4g.90gb`  | 4 von 7 | 90 GB | 1 | 
|  `7g.180gb`  | 7 von 7 | 180 GB | 1 | 

**``p6-b300.48xlarge — NVIDIA Blackwell Ultra B300**  
Der `p6-b300.48xlarge` verwendet den HGX B300, der die Partitionierung jeder GPU in 7 Instanzen mit 32 GB, 4 mit 67 GB, 2 mit 135 GB oder eine mit 270 GB unterstützt. Diese Größen sind vorläufig und können sich ändern. Die Profildetails finden Sie in den von [ NVIDIA unterstützten MIG-Profilen ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) auf der NVIDIA-Website.

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


| Profil | Teile berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.16gb`  | 1 von 2 | 16 GB | 2 | 
|  `2g.32gb`  | 2 von 2 | 32 GB | 1 | 

Die RTX PRO 4500 Blackwell unterstützt auch grafikfähige (`+gfx`) und Media-Engine-Profilvarianten (`+me.all`,). `-me` Die vollständige Liste finden Sie unter den von [ NVIDIA unterstützten MIG-Profilen ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) auf der NVIDIA-Website.

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


| Profil | Teile berechnen | Arbeitsspeicher pro Instanz | Max. Anzahl Instanzen | 
| --- | --- | --- | --- | 
|  `1g.24gb`  | 1 von 4 | 24 GB | 4 | 
|  `2g.48gb`  | 2 von 4 | 48 GB | 2 | 
|  `4g.96gb`  | 4 von 4 | 96 GB | 1 | 

Die RTX PRO 6000 Blackwell Server Edition unterstützt auch grafikfähige (`+gfx`) und Media-Engine (`+me.all`,) Profilvarianten. `-me` Die vollständige Liste finden Sie unter den von [ NVIDIA unterstützten MIG-Profilen ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) auf der NVIDIA-Website.

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

Der NVIDIA DRA-Treiber und das NVIDIA-Geräte-Plugin stellen MIG-Instanzen auf unterschiedliche Weise für Kubernetes bereit. Das Geräte-Plug-In verwendet eine knotenweite ** ** MIG-Strategieeinstellung, während der DRA-Treiber keine entsprechende Einstellung hat, da er Instanzen anhand ihrer Attribute auswählt. Das Verständnis dieses Unterschieds ist entscheidend für die Wahl zwischen den beiden Modellen.

### NVIDIA DRA-Treiber
<a name="_nvidia_dra_driver"></a>

Der NVIDIA DRA-Treiber verwendet nicht das Konzept einer einzelnen oder einer gemischten Strategie, und es gibt keine entsprechende Einstellung, die konfiguriert werden muss. Anstatt MIG-Instanzen als gezählte Ressourcen zu bewerben, veröffentlicht der Treiber jede Instanz als Gerät im Verzeichnis `mig.nvidia.com` `DeviceClass` mit Attributen `profile` wie z. B. Pods wählen eine Instanz aus, indem sie diese Attribute den CEL-Selektoren (Common Expression Language) in einem `ResourceClaim` oder zuordnen`ResourceClaimTemplate`, wie unter gezeigt. [Verwenden Sie MIG mit dem NVIDIA DRA-Treiber](#eks-mig-dra-driver)

Da die Auswahl pro Instanz erfolgt, funktionieren Knoten mit gemischten Profilen ohne einen Wechsel des Strategiemodus. Eine einzelne GPU kann in mehrere verschiedene Profile partitioniert werden, und jeder Anspruch wählt das Profil aus, das er benötigt. Bei der Wahl des DRA-Treibers kommt es nicht auf eine einzelne oder eine gemischte Strategie an, sondern auf statische oder dynamische MIG. Dabei wird gesteuert, ob Sie die MIG-Instances vorab erstellen oder ob der Treiber sie bei Bedarf erstellt. Weitere Informationen finden Sie unter [Verwenden Sie MIG mit dem NVIDIA DRA-Treiber](#eks-mig-dra-driver).

### NVIDIA-Geräte-Plug-In
<a name="_nvidia_device_plugin"></a>

Das NVIDIA-Geräte-Plugin bewirbt MIG-Instanzen bei Kubernetes mithilfe einer von zwei Strategien. Da das Geräte-Plug-In MIG-Instanzen als erweiterte Ressourcen auf Knotenebene bereitstellt, die nur eine Ganzzahl und keine Attribute pro Instanz enthalten, bestimmt die Strategie, wie diese Ressourcen benannt werden.
+  **Einzelstrategie ** — Jede GPU auf einem Knoten verwendet dasselbe MIG-Profil. Das Geräte-Plugin kündigt jede Instanz als `nvidia.com/gpu` Ressource an, und Pods fordern dies `nvidia.com/gpu: 1` wie bei einer dedizierten GPU an. Bestehende Manifeste ändern sich nicht. Sowohl Bottlerocket als auch AL2023 unterstützen die einheitliche Strategie.
+  **Gemischte Strategie ** — GPUs auf demselben Knoten können unterschiedliche MIG-Profile verwenden. Das Geräte-Plugin kündigt jedes Profil als eigene Ressource an, z. B. `nvidia.com/mig-1g.10gb` oder`nvidia.com/mig-3g.40gb`, und Pods fordern das spezifische Profil an, das sie benötigen. Mit dem integrierten NVIDIA-Geräte-Plugin von Bottlerocket können Sie keine gemischte Strategie verwenden. Weitere Informationen finden Sie in der [ GitHub Bottlerocket-Ausgabe \#4483 unter. ](https://github.com/bottlerocket-os/bottlerocket/issues/4483) GitHub

## Verwenden Sie MIG mit dem NVIDIA DRA-Treiber
<a name="eks-mig-dra-driver"></a>

Bei der Zuweisung von MIG-Instanzen mit dem NVIDIA DRA-Treiber fordern Pods eine MIG-Instanz über ein `ResourceClaim` oder an und `ResourceClaimTemplate` nicht über die `nvidia.com/mig-<profile>` erweiterte Ressource des Geräte-Plug-ins an.

Da der DRA-Treiber Instanzen anhand ihrer Attribute und nicht als gezählte Ressourcen beschreibt, verwendet er nicht die Einzel- oder Mischstrategie, die für das Geräte-Plug-In erforderlich ist (siehe[MIG-Strategien](#eks-mig-strategies)). Der Treiber macht jede MIG-Instanz als Gerät `mig.nvidia.com` `DeviceClass` mit dem `gpu.nvidia.com/type` Attribut verfügbar und kündigt instanzspezifische Attribute an`mig`, wie z. B. die `profile` (zum Beispiel`1g.5gb`) und die `parentUUID` der physischen GPU. Sie ordnen diese Attribute den CEL-Selektoren (Common Expression Language) zu, um ein bestimmtes Profil anzufordern oder mehrere Instanzen auf derselben GPU zu speichern.

Der DRA-Treiber weist MIG-Instanzen in einem von zwei Modi zu:
+  **Statische MIG ** — Sie aktivieren den MIG-Modus und erstellen die MIG-Instanzen auf dem Knoten, bevor der Treiber gestartet wird, z. B. mit dem MIG Manager im NVIDIA GPU Operator, wie unter beschrieben. [Verwenden Sie MIG auf AL2023-Knoten mit dem NVIDIA-Geräte-Plugin](#eks-mig-device-plugin-al2023) Der Treiber erkennt die vorhandenen Instanzen und weist sie Pods zu, ändert jedoch nicht die MIG-Konfiguration des Knotens. Instanzen, die nach dem Start des Treibers hinzugefügt wurden, werden erst erkannt, wenn das GPU-Kubelet-Plugin neu gestartet wird. Statisches MIG ist die Standardeinstellung und erfordert kein Feature-Gate.
+  **Dynamische MIG ** — Der Treiber erstellt und zerstört MIG-Partitionen bei Bedarf als Reaktion auf Workload-Anforderungen, sodass Sie die GPUs nicht im Voraus partitionieren müssen. Dynamic MIG ist eine Alpha-Funktion, die standardmäßig deaktiviert ist. Sie fordern ein Profil mit denselben `ResourceClaimTemplate` Selektoren an, die in den folgenden Abschnitten gezeigt werden, und der Treiber partitioniert eine GPU, um die Anforderung zu erfüllen.

### Überlegungen
<a name="_considerations"></a>
+ Dynamische MIG ersetzt die statische Erkennung auf einem Knoten. Der Treiber verwaltet alle Partitionen und zerstört alle MIG-Partitionen, die er beim Start des GPU-Kubelet-Plug-ins nicht erstellt hat. Aktiviere dynamische MIG nicht auf Knoten mit vorab erstellten Partitionen, die du behalten möchtest, und führe es nicht aus `mig-parted` oder `nvidia-smi mig` während das Plugin läuft, da manuelle Änderungen mit dem Partitionsstatus des Treibers in Konflikt geraten und dazu führen können, dass die Pod-Vorbereitung oder -Bereinigung fehlschlägt.
+ Dynamic MIG befindet sich im Alpha-Status und erfordert, dass bei der Installation des NVIDIA DRA-Treibers ein Feature Gate aktiviert wird. Eine Anleitung finden Sie unter[Installieren Sie den NVIDIA DRA-Treiber](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver).
+ Hopper-Architekturen (H100 und H200) und neuere Architekturen ermöglichen den MIG-Modus bei Bedarf. Frühere Generationen können den MIG-Modus nicht bei Bedarf aktivieren, einschließlich der Ampere-GPUs (A100).
+ Die dynamische MIG hängt von der Funktion ([KEP-4815](https://github.com/kubernetes/enhancements/issues/4815)on GitHub) für partitionierbare Kubernetes-Geräte ab, die in Kubernetes-Version 1.36 und höher standardmäßig aktiviert ist. In früheren Versionen ist diese Funktion standardmäßig nicht aktiviert, sodass der Scheduler keine dynamisch erstellten MIG-Geräte zuweisen kann.

### Voraussetzungen
<a name="_prerequisites"></a>
+ Ein Amazon EKS-Cluster mit Kubernetes-Version 1.34 oder höher mit statischer Kapazität, die von Karpenter bereitgestellt wird, von EKS verwalteten Knotengruppen oder selbstverwalteten Knotengruppen.
+ MIG-capable P-family Knoten mit aktiviertem MIG-Modus und GPUs, die in MIG-Instances partitioniert sind. Informationen zu statischer MIG finden Sie im [ MIG-Manager im NVIDIA GPU Operator ](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html) auf der NVIDIA-Website.
+ Der NVIDIA DRA-Treiber wurde wie unter beschrieben installiert[Installieren Sie den NVIDIA DRA-Treiber](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver), optional mit aktivierter dynamischer MIG, wenn Sie keine statische MIG-Partitionierung verwenden.

### Verfahren
<a name="_procedure"></a>

Die folgenden Beispiele können entweder mit statischer oder dynamischer MIG und dem NVIDIA DRA-Treiber verwendet werden.

1. Erstellen Sie eine`ResourceClaimTemplate`, die eine MIG-Instanz von der anfordert `mig.nvidia.com``DeviceClass`, und einen Pod, der darauf verweist. In diesem Beispiel wird jede verfügbare MIG-Instanz angefordert, ohne das Profil einzuschränken.

   ```
   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. Stellen Sie sicher, dass dem Pod eine einzelne MIG-Instance zugewiesen wurde.

   ```
   kubectl logs mig-dra-pod
   ```

   Eine Beispielausgabe sieht wie folgt aus. Der Pod sieht eine MIG-Instanz von der partitionierten GPU.

   ```
   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)
   ```

### Fordern Sie ein bestimmtes MIG-Profil an
<a name="_request_a_specific_mig_profile"></a>

Um ein bestimmtes Profil anstelle einer verfügbaren Instanz anzufordern, fügen Sie einen CEL-Selektor hinzu, der dem `profile` Attribut entspricht. Im Folgenden wird `ResourceClaimTemplate` eine `1g.5gb` Instanz angefordert, und der Pod verweist darauf.

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

### Fordern Sie mehrere MIG-Instanzen von derselben GPU an
<a name="_request_multiple_mig_instances_from_the_same_gpu"></a>

Um sicherzustellen, dass mehrere MIG-Instanzen in einem einzigen Anspruch von derselben physischen GPU stammen, fügen Sie einen `constraints` Block mit hinzu`matchAttribute: "gpu.nvidia.com/parentUUID"`. Im Folgenden werden `ResourceClaimTemplate` eine `1g.5gb` Instance und eine `2g.10gb` Instance von derselben GPU angefordert, und der Pod verweist auf den Anspruch. Da der Container auf den Anspruch verweist, ohne eine bestimmte Anfrage zu benennen, empfängt er beide MIG-Instanzen.

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

## Verwenden Sie MIG auf Bottlerocket-Knoten mit dem NVIDIA-Geräte-Plugin
<a name="eks-mig-device-plugin-bottlerocket"></a>

Auf Bottlerocket enthält das EKS-optimized beschleunigte AMI das NVIDIA-Geräte-Plugin. Sie aktivieren MIG mit der einzigen Strategie über die Einstellungen. `settings.kubelet-device-plugins.nvidia` Bottlerocket unterstützt MIG in Version 1.34.0 und höher.

### Voraussetzungen
<a name="_prerequisites_2"></a>
+ Ein Amazon EKS-Cluster. Das folgende Verfahren stellt MIG-capable P-family Knoten mit dem EKS-optimized Bottlerocket NVIDIA AMI, Version 1.34.0 oder höher, bereit.
+ Karpenter wurde in Ihrem Cluster installiert und konfiguriert, da das folgende Verfahren einen Karpenter verwendet, `EC2NodeClass` um die MIG-Einstellungen in den Benutzerdaten des Bottlerocket-Knotens bereitzustellen. Weitere Informationen finden Sie unter [ Erste Schritte mit Karpenter auf der Karpenter-Website. ](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/)
+  `kubectl`konfiguriert für die Kommunikation mit Ihrem Cluster, weitere Informationen finden Sie unter[Installieren oder aktualisieren `Sie kubectl`](install-kubectl.md#kubectl-install-update).

### Verfahren
<a name="_procedure_2"></a>

Fügen Sie die MIG-Partitionierungseinstellung zu den Bottlerocket-Benutzerdaten für Ihre GPU-Knoten hinzu. Die Art und Weise, wie Sie Benutzerdaten bereitstellen, hängt davon ab, wie Sie Knoten bereitstellen. Das folgende Beispiel zeigt einen Karpenter `EC2NodeClass` für `p4d.24xlarge` Knoten.

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

Wenn Knoten, die mit diesen Einstellungen ausgestattet sind, dem Cluster beitreten, wird der MIG-Modus auf den GPUs aktiviert, jede GPU wird in `2g.10gb` Instanzen partitioniert, und das Geräte-Plug-In kündigt die resultierenden Instanzen als Ressource an. `nvidia.com/gpu` Da a `p4d.24xlarge` über acht A100-GPUs verfügt und jede drei `2g.10gb` Instanzen unterstützt, kündigt der Knoten dies an. `nvidia.com/gpu: 24`

**Anmerkung**  
Die `mig.profile` Einstellung wird je nach GPU-Modell eingegeben, z. B. oder. `a100.40gb` `h100.80gb` Ohne eine `mig.profile` Einstellung aktiviert die GPU den MIG-Modus und verwendet ihr größtes Profil. Da Bottlerocket die Einzelstrategie verwendet, verwendet jede GPU auf dem Knoten dasselbe Profil. Um verschiedene Profile auf demselben Knoten zu verwenden (die gemischte Strategie), verwenden Sie den AL2023-Pfad mit dem NVIDIA GPU Operator.

## Verwenden Sie MIG auf AL2023-Knoten mit dem NVIDIA-Geräte-Plugin
<a name="eks-mig-device-plugin-al2023"></a>

Auf AL2023 verwenden die folgenden Schritte den NVIDIA GPU Operator, um das NVIDIA-Geräte-Plugin und den MIG Manager zu installieren. Der MIG Manager aktiviert den MIG-Modus und partitioniert die GPUs gemäß einer von Ihnen angegebenen Konfiguration. Das NVIDIA-Geräte-Plugin kündigt dann die resultierenden Instanzen an Kubernetes an. Der GPU Operator unterstützt sowohl Einzelstrategien als auch gemischte Strategien.

Da das EKS-optimized AL2023 NVIDIA AMI bereits den NVIDIA-Treiber und das Toolkit enthält, deaktivieren Sie die Treiberverwaltung im GPU Operator, um Konflikte mit dem vorinstallierten Treiber zu vermeiden. Alternativ können Sie das NVIDIA-Geräte-Plugin und den MIG Manager selbst installieren und verwalten, ohne den GPU Operator zu verwenden.

### Voraussetzungen
<a name="_prerequisites_3"></a>
+ Ein Amazon EKS-Cluster. Das folgende Verfahren stellt MIG-capable P-family Knoten (z. B.`p4d.24xlarge`) mit dem EKS-optimized AL2023 NVIDIA AMI bereit.
+ Karpenter wurde in Ihrem Cluster installiert und konfiguriert, da das Verfahren einen Karpenter erstellt `EC2NodeClass` und `NodePool` die GPU-Knoten bereitstellt. Weitere Informationen finden Sie unter [ Erste Schritte mit Karpenter auf der Karpenter-Website](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/).
+ Weitere Informationen finden Sie in den [Anweisungen zur Einrichtung von Helm](helm.md).
+  `kubectl`konfiguriert für die Kommunikation mit Ihrem Cluster, weitere Informationen finden Sie unter[Installieren oder aktualisieren `Sie kubectl`](install-kubectl.md#kubectl-install-update).

### Verfahren
<a name="_procedure_3"></a>

1. Erstellen Sie ein `EC2NodeClass` und `NodePool` für AL2023 P-family GPU-Knoten. Bei AL2023 wird die MIG-Partitionierung in späteren Schritten vom GPU-Operator angewendet, es handelt sich also um eine standardmäßige AL2023 GPU-Knotenklasse. Das folgende Beispiel stellt `p4d.24xlarge` Knoten mit dem EKS-optimized AL2023 NVIDIA-AMI bereit.

   ```
   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. Fügen Sie das NVIDIA Helm-Repository hinzu.

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

1. Erstellen Sie eine `gpu-operator-values.yaml` Datei, die die Treiberverwaltung deaktiviert, die gemischte Strategie auswählt und die anzuwendenden MIG-Profile definiert. Das folgende Beispiel definiert eine `p4d-half-balanced` Konfiguration, bei der vier der acht GPUs auf einem `p4d.24xlarge` Knoten partitioniert werden und der Rest vollständig bleibt.

   ```
   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. Installieren Sie den GPU-Operator mit der Wertedatei.

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

1. Benennen Sie Ihre MIG-capable Knoten mit der anzuwendenden Profilkonfiguration. Die MIG Manager-Komponente achtet auf dieses Label und partitioniert die GPUs entsprechend. Sie startet den Knoten neu, um die Änderung zu übernehmen.

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

1. Nachdem der GPU-Operator die GPUs partitioniert hat, fordern Pods ein bestimmtes MIG-Profil nicht anhand des Ressourcennamens an. `nvidia.com/gpu` Im folgenden Beispiel wird ein Pod ausgeführt, der eine `1g.5gb` Instanz anfordert.

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

Vollständige Konfigurationsbeispiele für P-family Instances mit gemischter Strategie, einschließlich verwalteter Knotengruppen mit Kapazitätsreservierungen und Workloads pro Profil, finden Sie im Abschnitt MIG des [ Amazon EKS-Best-Practices-Leitfadens. ](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html)

## Stellen Sie sicher, dass MIG aktiv ist
<a name="eks-mig-verify"></a>

Nachdem Ihre MIG-enabled Knoten aktiviert sind`Ready`, stellen Sie sicher, dass der MIG-Modus auf den GPUs aktiv ist und dass der Knoten die erwarteten MIG-Ressourcen ankündigt.

1. Vergewissern Sie sich, dass der Knoten MIG-Ressourcen ankündigt. Bei der Einzelstrategie meldet der Knoten die Instanzen als`nvidia.com/gpu`. Bei der gemischten Strategie meldet der Knoten profilspezifische Ressourcen, z. B. `nvidia.com/mig-1g.10gb`

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

1. Führen Sie die Ausführung `nvidia-smi` von einem Pod auf einem MIG-enabled Knoten aus, um zu bestätigen, dass der MIG-Modus aktiv ist.

    `nvidia-smi`meldet GPUs, `MIG M.: Enabled` bei denen der MIG-Modus aktiviert ist, und listet die jeweils konfigurierten MIG-Instanzen auf. Im Folgenden finden Sie ein Beispiel für die Ausgabe einer A100-GPU mit 40 GB, bei der MIG aktiviert und in `3g.20gb` `2g.10gb` ,- und partitioniert ist. `1g.5gb`

   ```
   +-----------------------------------------------------------------------------------------+
   | 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    |           |                       |
   +------------------+----------------------------------+-----------+-----------------------+
   ```

   Bei der gemischten Strategie sieht ein Pod nur die MIG-Instance, die er angefordert hat, nicht das vollständige GPU-Layout des Knotens. Der `mig-inference` Pod aus dem vorherigen Schritt hat eine `nvidia.com/mig-1g.5gb` Instanz angefordert, sodass `nvidia-smi -L` in diesem Pod ein einzelnes MIG-Gerät aufgeführt ist.

   ```
   kubectl logs mig-inference
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   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)
   ```

   Um das vollständige Partitionslayout jeder GPU auf einem Knoten zu sehen, führen Sie den Vorgang `nvidia-smi -L` auf dem Host aus und nicht in einem Workload-Pod. Der folgende Befehl startet einen privilegierten Debugging-Pod auf dem Knoten und führt den Pod des `nvidia-smi` Hosts aus. {{node-name}}Ersetzen Sie ihn durch den Namen Ihres MIG-enabled Knotens.

   ```
   kubectl debug node/<node-name> -it --profile=sysadmin --image=nvidia/cuda:12.6.0-base-ubuntu22.04 -- chroot /host nvidia-smi -L
   ```

   Das Folgende ist eine Beispielausgabe für die `p4d-half-balanced` Konfiguration. Die ersten vier GPUs sind in MIG-Instances partitioniert, und die verbleibenden vier sind ganze GPUs. Jede `MIG` Zeile ist eine hardwaresolierte Instanz mit eigener UUID, eigenem Speicher und eigenen Rechenbereichen.

   ```
   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)
   ```