協助改進此頁面
本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
若要為本使用者指南貢獻內容,請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。
本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
在 Amazon EKS 上使用多執行個體 GPUs (MIG) 搭配 NVIDIA GPUs
多執行個體 GPU
MIG 最適合需要可預測服務品質的多租戶推論和工作負載。可在 NVIDIA Ampere (A100)、Hopper (H100 和 H200) 和 Blackwell GPUs 上使用。在 上 AWS,這些是 P 系列執行個體類型,以及 Blackwell 型g7和g7e執行個體類型。如需完整清單,請參閱支援 MIG 的執行個體類型。
在下列情況下,MIG 非常適合:
-
您需要記憶體隔離,以便一個工作負載無法使用另一個工作負載所需的 GPU 記憶體。
-
您可以執行多租戶推論,其中租戶共用 GPU 硬體,但需要每個租戶的服務品質。
-
您已在 A100、H100、H200 或 Blackwell 執行個體上執行訓練,並希望在訓練閒置時將這些 GPUs 重複使用於較小的推論工作負載。
在下列情況下,請考慮不同的方法:
考量事項
在生產環境中使用 MIG 之前,請檢閱下列考量事項。
一般考量事項
-
變更 MIG 組態需要重設 GPU。啟用或停用 MIG 模式或變更分割區配置需要 GPU 重設,因此無法變更。例如,NVIDIA GPU Operator 中的 MIG Manager 會套用組態變更,方法是停止節點上的 GPU Pod,並在需要重新啟動以變更 MIG 模式時重新啟動節點。
-
運算與執行個體大小不成正比。
1g執行個體不會為每個工作負載提供全 GPU 輸送量的比例分配,因為記憶體頻寬和快取行為因設定檔而異。在調整分割區大小之前,在您想要使用的設定檔上為工作負載建立基準。 -
時間分割對 MIG 執行個體沒有影響。MIG 執行個體已進行硬體隔離,無法透過時間分割進一步共用。在 MIG 裝置上請求
TimeSlicing共用策略並不會變更硬體行為。若要跨容器共用單一 MIG 執行個體,請改用 NVIDIA Multi-Process Service (MPS)。 -
有限的跨 GPU 通訊。啟用 MIG 時,不同 GPUs 上的 MIG 執行個體無法使用 GPU-to-GPU peer-to-peer(P2P) 通訊,且 NCCL 無法使用 MIG。依賴集體通訊或跨 GPUs 的 P2P 的多 GPU 工作負載,例如張量平行多 GPU 訓練,需要整個 GPUs。如需詳細資訊,請參閱 NVIDIA 網站上的 NVIDIA MIG 使用者指南中的應用程式考量事項
。
NVIDIA 裝置外掛程式考量事項
-
Pod 資源請求必須符合 策略。使用單一策略,Pods 請求
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 模式。EKS Auto Mode 會管理 NVIDIA 裝置外掛程式,而不會公開其組態 (請參閱 部署加速工作負載)。您無法在 EKS Auto Mode 節點上啟用 MIG。在自我管理的 Karpenter 節點或受管節點群組上設定 MIG,您可以在其中控制 AMI 和裝置外掛程式設定。
NVIDIA DRA 驅動程式考量事項
-
靜態 MIG 需要預先建立的執行個體。使用靜態 MIG 時,DRA 驅動程式會配置現有的 MIG 執行個體,但不啟用 MIG 模式或分割 GPUs。您必須啟用 MIG 模式,並先建立執行個體,例如在 NVIDIA GPU Operator 或 中使用 MIG Manager
nvidia-smi。如需詳細資訊,請參閱搭配 NVIDIA DRA 驅動程式使用 MIG。 -
動態 MIG 是一種 Alpha 功能。使用動態 MIG,驅動程式會隨需建立和銷毀 MIG 分割區,以回應工作負載請求。它需要
DynamicMIG功能閘道,預設為停用。如需詳細資訊,請參閱搭配 NVIDIA DRA 驅動程式使用 MIG。 -
在 Bottlerocket 上停用內建裝置外掛程式。DRA 驅動程式無法與相同節點上的 NVIDIA 裝置外掛程式一起執行。在 Bottlerocket 上,停用需要 Bottlerocket 1.63.0 版或更新版本的內建裝置外掛程式。如需詳細資訊,請參閱安裝 NVIDIA DRA 驅動程式。
-
運算支援。在 Karpenter、EKS 受管節點群組或自我管理節點中,靜態容量佈建支援 NVIDIA DRA 驅動程式,EKS Auto Mode 不支援。如需詳細資訊,請參閱 Karpenter 網站上的 Karpenter 靜態 NodePool 文件
。
支援 MIG 的執行個體類型
在 上 AWS,下列執行個體類型提供具備 MIG 功能的 GPUs。
| 執行個體類型 | GPU | 記憶體 |
|---|---|---|
|
|
8 個 NVIDIA A100 40 GB |
320 GB |
|
|
8 個 NVIDIA A100 80 GB |
640 GB |
|
|
8 個 NVIDIA H100 80 GB |
640 GB |
|
|
8 個 NVIDIA H200 |
1128 GB |
|
|
8 個 NVIDIA H200 |
1128 GB |
|
|
8 個 NVIDIA Blackwell B200 |
1432 GB |
|
|
8 個 NVIDIA Blackwell Ultra B300 |
2144 GB |
|
|
8 個 NVIDIA RTX PRO 4500 Blackwell 伺服器版本 |
256 GB |
|
|
8 個 NVIDIA RTX PRO 6000 Blackwell 伺服器版本 |
768 GB |
MIG 不適用於 g5、 g6或 g6e 系列。對於使用支援 MIG 的 NVIDIA GB200 GPU 的 p6e-gb200 UltraServers,請參閱 搭配 Amazon EKS 使用 P6e-GB200 UltraServers。
注意
g7 執行個體類型需要 NVIDIA 驅動程式 595 版或更新版本。EKS 最佳化加速 AMIs 目前包含 NVIDIA 驅動程式 580 版,因此若要在 上使用 MIGg7,您必須建置驅動程式 595 版的自訂 AMI。如需詳細資訊,請參閱建置自訂 EKS 最佳化 Amazon Linux AMI。
MIG 執行個體是由使用命名模式 的設定檔描述<slices>g.<memory>gb,其中 <slices>是運算配量的數量,而 <memory>是執行個體的記憶體,以 GB 為單位。例如,3g.40gb設定檔提供七個運算配量中的三個,以及 40 GB 的記憶體。每個 GPU 支援的設定檔由硬體修正。如需完整清單,請參閱 NVIDIA 網站上的 NVIDIA 多執行個體 GPU 使用者指南
每個執行個體類型的 MIG 設定檔
節點上可用的 MIG 設定檔取決於執行個體類型的 GPU。下列各節列出每個具備 MIG 功能的 Amazon EC2 執行個體類型的設定檔。對於每個設定檔,最大執行個體是您可以在單一 GPU 上建立的該設定檔執行個體數量上限,而每個執行個體的記憶體是分配給每個設定檔的 GPU 記憶體。
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 7 頁 |
5 GB |
7 |
|
|
第 1 頁,共 7 頁 |
10 GB |
4 |
|
|
第 2 頁,共 7 頁 |
10 GB |
3 |
|
|
第 3 頁,共 7 頁 |
20 GB |
2 |
|
|
第 4 頁,共 7 頁 |
20 GB |
1 |
|
|
第 7 頁,共 7 頁 |
40 GB |
1 |
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 7 頁 |
10 GB |
7 |
|
|
第 1 頁,共 7 頁 |
20 GB |
4 |
|
|
第 2 頁,共 7 頁 |
20 GB |
3 |
|
|
第 3 頁,共 7 頁 |
40 GB |
2 |
|
|
第 4 頁,共 7 頁 |
40 GB |
1 |
|
|
第 7 頁,共 7 頁 |
80 GB |
1 |
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 7 頁 |
10 GB |
7 |
|
|
第 1 頁,共 7 頁 |
20 GB |
4 |
|
|
第 2 頁,共 7 頁 |
20 GB |
3 |
|
|
第 3 頁,共 7 頁 |
40 GB |
2 |
|
|
第 4 頁,共 7 頁 |
40 GB |
1 |
|
|
第 7 頁,共 7 頁 |
80 GB |
1 |
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 7 頁 |
18 GB |
7 |
|
|
第 1 頁,共 7 頁 |
35 GB |
4 |
|
|
第 2 頁,共 7 頁 |
35 GB |
3 |
|
|
第 3 頁,共 7 頁 |
71 GB |
2 |
|
|
第 4 頁,共 7 頁 |
71 GB |
1 |
|
|
第 7 頁,共 7 頁 |
141 GB |
1 |
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 7 頁 |
23 GB |
7 |
|
|
第 1 頁,共 7 頁 |
45 GB |
4 |
|
|
第 2 頁,共 7 頁 |
45 GB |
3 |
|
|
第 3 頁,共 7 頁 |
90 GB |
2 |
|
|
第 4 頁,共 7 頁 |
90 GB |
1 |
|
|
第 7 頁,共 7 頁 |
180 GB |
1 |
p6-b300.48xlarge – NVIDIA Blackwell Ultra B300
p6-b300.48xlarge 使用 HGX B300,支援將每個 GPU 分割成 7 個 32 GB、4 個 67 GB、2 個 135 GB 或 1 個 270 GB 的執行個體。這些大小是初步的,可能會變更。如需設定檔詳細資訊,請參閱 NVIDIA 網站上的 NVIDIA 支援的 MIG 設定檔
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 2 頁 |
16 GB |
2 |
|
|
第 2 個,共 2 個 |
32 GB |
1 |
RTX PRO 4500 Blackwell 也支援圖形啟用 (+gfx) 和媒體引擎 (+me.all、-me) 設定檔變體。如需完整清單,請參閱 NVIDIA 網站上的 NVIDIA 支援的 MIG 設定檔
| 設定檔 | 運算配量 | 每個執行個體的記憶體數量 | 執行個體上限 |
|---|---|---|---|
|
|
第 1 頁,共 4 頁 |
24 GB |
4 |
|
|
第 2 頁,共 4 頁 |
48 GB |
2 |
|
|
第 4 個,共 4 個 |
96 GB |
1 |
RTX PRO 6000 Blackwell Server Edition 也支援圖形啟用 (+gfx) 和媒體引擎 (+me.all、-me) 設定檔變體。如需完整清單,請參閱 NVIDIA 網站上的 NVIDIA 支援的 MIG 設定檔
MIG 策略
NVIDIA DRA 驅動程式和 NVIDIA 裝置外掛程式會以不同的方式向 Kubernetes 公開 MIG 執行個體。裝置外掛程式使用全節點的 MIG 策略設定,而 DRA 驅動程式沒有同等設定,因為它會依其屬性選取執行個體。了解此差異是兩種模型之間選擇的關鍵。
NVIDIA DRA 驅動程式
NVIDIA DRA 驅動程式不會使用單一或混合策略概念,也沒有要設定的同等設定。驅動程式不會將 MIG 執行個體公告為計數的資源,而是將每個執行個體發佈為 中的裝置,mig.nvidia.comDeviceClass並具有其 等屬性profile。Pod 會將這些屬性與 ResourceClaim或 中的通用表達式語言 (CEL) 選擇器相符,以選取執行個體ResourceClaimTemplate,如 所示搭配 NVIDIA DRA 驅動程式使用 MIG。
由於選取是每個執行個體,因此混合設定檔節點可在沒有策略模式切換的情況下運作。單一 GPU 可以分割成數個不同的設定檔,每個宣告都會選取所需的設定檔。對於 DRA 驅動程式而言重要的選擇不是單一或混合策略,而是靜態或動態 MIG,這會控制您是否預先建立 MIG 執行個體或驅動程式隨需建立它們。如需詳細資訊,請參閱搭配 NVIDIA DRA 驅動程式使用 MIG。
NVIDIA 裝置外掛程式
NVIDIA 裝置外掛程式會使用兩種策略之一,向 Kubernetes 公告 MIG 執行個體。由於裝置外掛程式會將 MIG 執行個體公開為節點層級的延伸資源,只包含整數計數,而且沒有每個執行個體的屬性,因此策略會決定這些資源的命名方式。
-
單一策略 – 節點上的每個 GPU 都使用相同的 MIG 設定檔。裝置外掛程式會將每個執行個體公告為
nvidia.com/gpu資源,Pod 請求與專用 GPU 的請求nvidia.com/gpu: 1相同。現有的資訊清單不會變更。Bottlerocket 和 AL2023 都支援單一策略。 -
混合策略 – 相同節點上的 GPUs 可以使用不同的 MIG 設定檔。裝置外掛程式會將每個設定檔公告為不同的資源,例如
nvidia.com/mig-1g.10gb或nvidia.com/mig-3g.40gb,Pod 會請求所需的特定設定檔。您無法將混合策略與 Bottlerocket 的內建 NVIDIA 裝置外掛程式搭配使用。如需詳細資訊,請參閱 GitHub 上的 Bottlerocket GitHub 問題 #4483。 GitHub
搭配 NVIDIA DRA 驅動程式使用 MIG
使用 NVIDIA DRA 驅動程式配置 MIG 執行個體時,Pods 會透過 ResourceClaim或 ResourceClaimTemplate而非裝置外掛程式的nvidia.com/mig-<profile>延伸資源請求 MIG 執行個體。
由於 DRA 驅動程式會依執行個體的屬性而非計數的資源來描述執行個體,因此不會使用裝置外掛程式所需的單一或混合策略 (請參閱 MIG 策略)。驅動程式會將每個 MIG 執行個體公開為 gpu.nvidia.com/type 中的裝置mig,mig.nvidia.comDeviceClass並公告每個執行個體的屬性,例如實體 GPU parentUUID的 profile(例如 1g.5gb) 和 。您可以使用通用表達式語言 (CEL) 選擇器比對這些屬性,以請求特定設定檔或將多個執行個體保留在相同的 GPU 上。
DRA 驅動程式會以兩種模式之一配置 MIG 執行個體:
-
靜態 MIG – 您可以在驅動程式啟動之前啟用 MIG 模式並在節點上建立 MIG 執行個體,例如在 NVIDIA GPU Operator 中使用 MIG Manager,如中所述在 AL2023 節點上使用 MIG 搭配 NVIDIA 裝置外掛程式。驅動程式會探索現有的執行個體並將其配置給 Pod,但不會修改節點的 MIG 組態。在 GPU kubelet 外掛程式重新啟動之前,不會發現驅動程式啟動後新增的執行個體。靜態 MIG 是預設值,不需要任何功能閘道。
-
動態 MIG – 驅動程式會隨需建立和銷毀 MIG 分割區以回應工作負載請求,因此您不會預先分割 GPUs。動態 MIG 是一種依預設停用的 Alpha 功能。您可以使用下列各節中顯示的相同
ResourceClaimTemplate選取器來請求設定檔,而且驅動程式會分割 GPU 以滿足請求。
考量事項
-
動態 MIG 取代節點上的靜態探索。驅動程式會管理所有分割區,並銷毀 GPU kubelet 外掛程式啟動時未建立的任何 MIG 分割區。請勿在具有您要保留之預先建立分割區的節點上啟用動態 MIG,並且不要執行
mig-parted或在外掛程式執行nvidia-smi mig時啟用動態 MIG,因為手動變更可能會與驅動程式的分割區狀態衝突,並導致 Pod 準備或清除失敗。 -
動態 MIG 處於 Alpha 狀態,且在安裝 NVIDIA DRA 驅動程式時需要啟用功能閘道,請參閱 安裝 NVIDIA DRA 驅動程式 以取得說明。
-
Hopper (H100 和 H200) 和更新架構會隨需啟用 MIG 模式。上一代無法隨需啟用 MIG 模式,包括 Ampere (A100) GPUs。
-
動態 MIG 取決於 Kubernetes 可分割裝置功能 (GitHub 上的 KEP-4815
),此功能預設為在 Kubernetes 1.36 版和更新版本中啟用。在舊版上,此功能預設不會啟用,因此排程器無法配置動態建立的 MIG 裝置。
先決條件
-
執行 Kubernetes 1.34 版或更新版本的 Amazon EKS 叢集,具有由 Karpenter、EKS 受管節點群組或自我管理節點群組佈建的靜態容量。
-
具備 MIG 功能的 P 系列節點,已啟用 MIG 模式,並將 GPUs 分割為 MIG 執行個體。如需靜態 MIG,請參閱 NVIDIA 網站上的 NVIDIA GPU Operator 中的 MIG Manager
。 -
如中所述安裝的 NVIDIA DRA 驅動程式安裝 NVIDIA DRA 驅動程式,如果您未使用靜態 MIG 分割,可選擇是否啟用動態 MIG。
程序
下列範例可與靜態或動態 MIG 和 NVIDIA DRA 驅動程式搭配使用。
-
建立從
ResourceClaimTemplate請求 MIGmig.nvidia.com執行個體的DeviceClass,以及參考它的 Pod。此範例會請求任何可用的 MIG 執行個體,而不限制設定檔。cat <<EOF | kubectl apply -f - apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: mig-profile-any spec: spec: devices: requests: - name: mig exactly: deviceClassName: mig.nvidia.com count: 1 --- apiVersion: v1 kind: Pod metadata: name: mig-dra-pod spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: claims: - name: mig resourceClaims: - name: mig resourceClaimTemplateName: mig-profile-any restartPolicy: OnFailure EOF -
確認 Pod 已配置單一 MIG 執行個體。
kubectl logs mig-dra-pod範例輸出如下。Pod 會從分割的 GPU 看到一個 MIG 執行個體。
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-edd63844-8488-f76a-f6e0-1027a7319a88) MIG 2g.10gb Device 0: (UUID: MIG-a5ad493e-e7e8-5675-9381-1d0f5311a456)
請求特定的 MIG 設定檔
若要請求特定設定檔,而非任何可用的執行個體,請新增符合 profile 屬性的 CEL 選擇器。下列 ResourceClaimTemplate會請求執行個體,而 Pod 會參考該1g.5gb執行個體。
cat <<EOF | kubectl apply -f - apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: mig-profile-1g.5gb spec: spec: devices: requests: - name: mig exactly: deviceClassName: mig.nvidia.com selectors: - cel: expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'" --- apiVersion: v1 kind: Pod metadata: name: mig-profile-pod spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: claims: - name: mig resourceClaims: - name: mig resourceClaimTemplateName: mig-profile-1g.5gb restartPolicy: OnFailure EOF
從相同的 GPU 請求多個 MIG 執行個體
若要確保單一宣告中的多個 MIG 執行個體來自相同的實體 GPU,請使用 新增constraints區塊matchAttribute: "gpu.nvidia.com/parentUUID"。下列會從相同的 GPU ResourceClaimTemplate請求1g.5gb執行個體和2g.10gb執行個體,而 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
在 Bottlerocket 節點上使用 MIG 搭配 NVIDIA 裝置外掛程式
在 Bottlerocket 上,EKS 最佳化的加速 AMI 包含 NVIDIA 裝置外掛程式。您可以透過settings.kubelet-device-plugins.nvidia設定以單一策略啟用 MIG。Bottlerocket 在 1.34.0 版和更新版本中支援 MIG。
先決條件
-
Amazon EKS 叢集。下列程序使用 EKS 最佳化 Bottlerocket NVIDIA AMI 1.34.0 版或更新版本佈建具備 MIG 功能的 P 系列節點。
-
叢集中已安裝並設定 Karpenter,因為下列程序使用 Karpenter
EC2NodeClass在 Bottlerocket 節點使用者資料中提供 MIG 設定。如需詳細資訊,請參閱 Karpenter 網站上的 Karpenter 入門。 -
kubectl設定為與您的叢集通訊,安裝或更新 kubectl如需詳細資訊,請參閱 。
程序
將 MIG 分割設定新增至 GPU 節點的 Bottlerocket 使用者資料。您提供使用者資料的方式取決於您佈建節點的方式。下列範例顯示p4d.24xlarge節點EC2NodeClass的 Karpenter。
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
當使用這些設定佈建的節點加入叢集時,會在 GPUs 上啟用 MIG 模式、將每個 GPU 分割為2g.10gb執行個體,且裝置外掛程式會將產生的執行個體公告為nvidia.com/gpu資源。由於 p4d.24xlarge有八個 A100 GPUs,且每個都支援三個2g.10gb執行個體,因此節點會公告 nvidia.com/gpu: 24。
注意
此mig.profile設定由 GPU 模型輸入,例如 a100.40gb或 h100.80gb。如果沒有mig.profile設定,GPU 會啟用 MIG 模式並使用其最大的設定檔。由於 Bottlerocket 使用單一策略,節點上的每個 GPU 都使用相同的設定檔。若要在相同的節點 (混合策略) 上使用不同的設定檔,請使用 AL2023 路徑搭配 NVIDIA GPU Operator。
在 AL2023 節點上使用 MIG 搭配 NVIDIA 裝置外掛程式
在 AL2023 上,下列步驟使用 NVIDIA GPU Operator 安裝 NVIDIA 裝置外掛程式和 MIG Manager。MIG Manager 會啟用 MIG 模式,並根據您提供的組態分割 GPUs。然後,NVIDIA 裝置外掛程式會將產生的執行個體公告給 Kubernetes。GPU Operator 同時支援單一和混合策略。
由於 EKS 最佳化 AL2023 NVIDIA AMI 已包含 NVIDIA 驅動程式和工具組,請在 GPU Operator 中停用驅動程式管理,以避免與預先安裝的驅動程式發生衝突。或者,您可以自行安裝和管理 NVIDIA 裝置外掛程式和 MIG Manager,而無需使用 GPU Operator。
先決條件
-
Amazon EKS 叢集。下列程序使用 EKS 最佳化 AL2023 NVIDIA AMI 佈建具備 MIG 功能的 P 系列節點 (例如
p4d.24xlarge)。 -
您的叢集中已安裝並設定 Karpenter,因為程序會建立 Karpenter
EC2NodeClass和NodePool來佈建 GPU 節點。如需詳細資訊,請參閱 Karpenter 網站上的 Karpenter 入門。 -
已在命令列環境中安裝 Helm,如需詳細資訊,請參閱安裝 Helm 說明。
-
kubectl設定為與您的叢集通訊,安裝或更新 kubectl如需詳細資訊,請參閱 。
程序
-
NodePool為 AL2023 P 系列 GPU 節點建立EC2NodeClass和 。在 AL2023 上,GPU Operator 會在後續步驟中套用 MIG 分割,因此這是標準 AL2023 GPU 節點類別。下列範例使用 EKS 最佳化 AL2023 NVIDIA AMI 佈建p4d.24xlarge節點。cat <<EOF | kubectl apply -f - apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: gpu-mig-al2023 spec: amiFamily: AL2023 amiSelectorTerms: - alias: al2023@latest role: eksctl-KarpenterNodeRole-<cluster-name> subnetSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> securityGroupSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> tags: karpenter.sh/discovery: <cluster-name> --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-mig-al2023 spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: gpu-mig-al2023 taints: - key: nvidia.com/gpu effect: NoSchedule requirements: - key: karpenter.sh/capacity-type operator: In values: ["spot", "on-demand"] - key: node.kubernetes.io/instance-type operator: In values: ["p4d.24xlarge"] - key: kubernetes.io/arch operator: In values: ["amd64"] limits: cpu: 1000 memory: 5000Gi EOF -
新增 NVIDIA Helm 儲存庫。
helm repo add nvidia https://nvidia.github.io/gpu-operator helm repo update -
建立
gpu-operator-values.yaml檔案以停用驅動程式管理、選取混合策略,並定義要套用的 MIG 設定檔。下列範例定義的p4d-half-balanced組態會將p4d.24xlarge節點上八個 GPUs 中的四個 GPU 分割,並保留整個 GPU。cat <<EOF > gpu-operator-values.yaml driver: enabled: false toolkit: enabled: false devicePlugin: enabled: true nfd: enabled: true gfd: enabled: true mig: strategy: mixed migManager: enabled: true env: - name: WITH_REBOOT value: "true" config: create: true name: custom-mig-parted-configs default: all-disabled data: config.yaml: |- version: v1 mig-configs: all-disabled: - devices: all mig-enabled: false p4d-half-balanced: - devices: [0, 1, 2, 3] mig-enabled: true mig-devices: "1g.5gb": 2 "2g.10gb": 1 "3g.20gb": 1 - devices: [4, 5, 6, 7] mig-enabled: false EOF -
使用值檔案安裝 GPU Operator。
helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --values gpu-operator-values.yaml -
使用要套用的設定檔組態來標記具備 MIG 功能的節點。MIG Manager 元件會監看此標籤,並相應地分割 GPUs,重新啟動節點以套用變更。
kubectl label nodes -l node.kubernetes.io/instance-type=p4d.24xlarge \ nvidia.com/mig.config=p4d-half-balanced --overwrite -
GPU Operator 分割 GPUs 之後,Pods 會依其資源名稱而非 請求特定的 MIG 設定檔
nvidia.com/gpu。下列範例會執行請求一個1g.5gb執行個體的 Pod。cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: mig-inference spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: limits: nvidia.com/mig-1g.5gb: 1 EOF
如需 P 系列執行個體的完整混合策略組態範例,包括具有容量保留和每個設定檔工作負載的受管節點群組,請參閱《Amazon EKS 最佳實務指南》中的 MIG 一節。
確認 MIG 處於作用中狀態
啟用 MIG 的節點為 之後Ready,請確認 GPUs 上的 MIG 模式處於作用中狀態,且節點會公告預期的 MIG 資源。
-
確認節點公告 MIG 資源。使用單一策略時,節點會將執行個體報告為
nvidia.com/gpu。使用混合策略時,節點會報告設定檔特定的資源,例如nvidia.com/mig-1g.10gb。kubectl describe node <node-name> | grep nvidia.com -
nvidia-smi從已啟用 MIG 的節點上的 Pod 執行,以確認 MIG 模式處於作用中狀態。nvidia-smiMIG M.: Enabled報告已開啟 MIG 模式的 GPUs,並列出每個 GPU 上設定的 MIG 執行個體。以下是啟用 MIG 並分割為3g.20gb、2g.10gb和1g.5gb執行個體之 A100 40 GB GPU 的輸出範例。+-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.159.03 Driver Version: 580.159.03 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA A100-SXM4-40GB On | 00000000:10:1C.0 Off | On | | N/A 35C P0 65W / 400W | 213MiB / 40960MiB | N/A Default | | | | Enabled | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | MIG devices: | +------------------+----------------------------------+-----------+-----------------------+ | GPU GI CI MIG | Shared Memory-Usage | Vol| Shared | | ID ID Dev | Shared BAR1-Usage | SM Unc| CE ENC DEC OFA JPG | | | | ECC| | |==================+==================================+===========+=======================| | 0 1 0 0 | 107MiB / 20096MiB | 42 0 | 3 0 2 0 0 | | | 0MiB / 12211MiB | | | +------------------+----------------------------------+-----------+-----------------------+ | 0 5 0 1 | 71MiB / 9984MiB | 28 0 | 2 0 1 0 0 | | | 0MiB / 6105MiB | | | +------------------+----------------------------------+-----------+-----------------------+ | 0 13 0 2 | 36MiB / 4864MiB | 14 0 | 1 0 0 0 0 | | | 0MiB / 3052MiB | | | +------------------+----------------------------------+-----------+-----------------------+使用混合策略時,Pod 只會看到其請求的 MIG 執行個體,而不是節點的完整 GPU 配置。上一個步驟的
mig-inferencePod 請求一個nvidia.com/mig-1g.5gb執行個體,因此 Podnvidia-smi -L會列出單一 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 的完整分割區配置,請在主機
nvidia-smi -L上執行,而不是在工作負載 Pod 內執行。下列命令會在節點上啟動特權偵錯 Pod,並執行主機的nvidia-smi。以已啟用 MIG 的節點名稱取代node-name。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組態的範例輸出。前四個 GPUs 會分割為 MIG 執行個體,其餘四個 GPU 是整個 GPUs。每一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)