View a markdown version of this page

Verwenden Sie Mehrinstanz-GPUs (MIG) mit NVIDIA-GPUs auf Amazon EKS - Amazon EKS

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

Multi-Instance GPU (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, 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.

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 g5g6, oder. Verwenden Sie stattdessen Time-Slicing.

  • Sie benötigen keine Speicherisolierung und möchten die einfachste Konfiguration. Verwenden Sie stattdessen Time-Slicing.

  • 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

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

Allgemeine Überlegungen

  • 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 im NVIDIA MIG-Benutzerhandbuch auf der NVIDIA-Website.

Überlegungen zum NVIDIA-Geräte-Plugin

  • Pod-Ressourcenanforderungen müssen der Strategie entsprechen. Bei der Einzelstrategie fordern Pods annvidia.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 mitkubectl 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 (sieheEinen beschleunigten Workload bereitstellen). 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

  • 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.

  • 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.

  • 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.

  • 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.

MIG-capable Instanztypen

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 Familieng5,g6, oder nicht verfügbar. Informationen dazu p6e-gb200 UltraServers, welche die MIG-capable NVIDIA GB200-GPU verwenden, finden Sie unterP6e-GB200 UltraServers Mit Amazon EKS verwenden.

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.

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 auf der NVIDIA-Website.

MIG-Profile pro Instanztyp

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.

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

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

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

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

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 auf der NVIDIA-Website.

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 auf der NVIDIA-Website.

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 auf der NVIDIA-Website.

MIG-Strategien

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

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 zuordnenResourceClaimTemplate, wie unter gezeigt. Verwenden Sie MIG mit dem NVIDIA DRA-Treiber

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.

NVIDIA-Geräte-Plug-In

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 odernvidia.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. GitHub

Verwenden Sie MIG mit dem NVIDIA DRA-Treiber

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 (sieheMIG-Strategien). 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 anmig, wie z. B. die profile (zum Beispiel1g.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 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

  • 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 unterInstallieren Sie den NVIDIA DRA-Treiber.

  • 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-4815on 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

  • 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 auf der NVIDIA-Website.

  • Der NVIDIA DRA-Treiber wurde wie unter beschrieben installiertInstallieren Sie den NVIDIA DRA-Treiber, optional mit aktivierter dynamischer MIG, wenn Sie keine statische MIG-Partitionierung verwenden.

Verfahren

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

  1. Erstellen Sie eineResourceClaimTemplate, die eine MIG-Instanz von der anfordert mig.nvidia.comDeviceClass, 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
  2. 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

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

Um sicherzustellen, dass mehrere MIG-Instanzen in einem einzigen Anspruch von derselben physischen GPU stammen, fügen Sie einen constraints Block mit hinzumatchAttribute: "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

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

  • 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.

  • kubectlkonfiguriert für die Kommunikation mit Ihrem Cluster, weitere Informationen finden Sie unterInstallieren oder aktualisieren Sie kubectl.

Verfahren

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

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

Verfahren

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

    helm repo add nvidia https://nvidia.github.io/gpu-operator helm repo update
  3. 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
  4. 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
  5. 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
  6. 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.

Stellen Sie sicher, dass MIG aktiv ist

Nachdem Ihre MIG-enabled Knoten aktiviert sindReady, 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 alsnvidia.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
  2. 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-smimeldet 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-nameErsetzen 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)