Ajudar a melhorar esta página
Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.
Usar GPUs de várias instâncias (MIG) com GPUs da NVIDIA no Amazon EKS
A GPU de várias instâncias
O MIG é mais adequado para inferência multilocatária e workloads que exigem qualidade de serviço previsível. Ele está disponível nas GPUs NVIDIA Ampere (A100), Hopper (H100 e H200) e Blackwell. Na AWS, esses são os tipos de instância da família P e os tipos de instância g7 e g7e baseados em Blackwell. Para ver a lista completa, consulte Tipos de instância compatíveis com o MIG.
O MIG é uma boa opção quando:
-
Você precisa de isolamento de memória para que uma workload não possa consumir a memória da GPU que outra workload exige.
-
Você executa a inferência multilocatária em que os locatários compartilham o hardware da GPU, mas exigem qualidade de serviço por locatário.
-
Você já executa treinamento em instâncias A100, H100, H200 ou Blackwell e deseja reutilizar essas GPUs para workloads de inferência menores quando o treinamento está ocioso.
Considere uma abordagem diferente quando:
-
Seus nós usam um tipo de instância de GPU que não é compatível com o MIG, como as famílias
g5,g6oug6e. Use então fatiamento de tempo. -
Você não precisa de isolamento de memória e quer a configuração mais simples. Use então fatiamento de tempo.
-
Você precisa alterar as partições da GPU com frequência sem interrupções. Alterar o modo MIG ou o layout da partição requer uma redefinição da GPU, que o GPU Operator executa ao reinicializar o nó.
-
Você executa um treinamento com várias GPUs que depende da comunicação coletiva ou ponto a ponto entre as GPUs. O MIG não oferece suporte a NCCL ou P2P entre GPUs.
Considerações
Analise as considerações a seguir antes de utilizar o MIG na produção.
Considerações gerais
-
Alterar a configuração do MIG requer uma redefinição da GPU. Habilitar ou desabilitar o modo MIG, ou alterar o layout da partição, requer uma redefinição da GPU, portanto, ela não pode ser alterada no local. Por exemplo, o MIG Manager no NVIDIA GPU Operator aplica uma alteração na configuração interrompendo os pods de GPU no nó e reinicializando o nó quando uma reinicialização é necessária para alterar o modo MIG.
-
A computação não é estritamente proporcional ao tamanho da instância. Uma instância
1gnão fornece uma parcela proporcional do throughput de toda a GPU para cada workload, porque a largura de banda da memória e o comportamento do cache diferem entre os perfis. Faça uma avaliação comparativa da sua workload no perfil que você pretende usar antes de dimensionar as partições. -
O fatiamento de tempo não tem efeito nas instâncias MIG. Uma instância MIG já está isolada por hardware e não pode ser compartilhada posteriormente por meio do fatiamento de tempo. Solicitar a estratégia de compartilhamento de
TimeSlicingem um dispositivo MIG não altera o comportamento do hardware. Para compartilhar uma única instância MIG entre contêineres, use o NVIDIA Multi-Process Service (MPS). -
Comunicação limitada entre GPUs. Quando o MIG está habilitado, as instâncias MIG em GPUs diferentes não podem usar a comunicação ponto a ponto (P2P) de GPU a GPU, e o NCCL não funciona com o MIG. Em vez disso, workloads com várias GPUs que dependem de comunicação coletiva ou P2P entre GPUs, como treinamento de várias GPUs com tensor paralelo, exigem GPUs inteiras. Para obter detalhes, consulte as considerações sobre a aplicação
no Guia do usuário do NVIDIA MIG no site da NVIDIA.
Considerações sobre o plug-in de dispositivo da NVIDIA
-
As requisições de recursos de pods devem corresponder à estratégia. Com a estratégia única, os pods solicitam
nvidia.com/gpu. Com a estratégia mista, os pods solicitam o recurso específico do perfil, comonvidia.com/mig-1g.10gb. Um pod que solicita um perfil que o nó não anuncia permanece no estadoPending. Confirme os recursos anunciados comkubectl describe node <node-name>. -
Plug-in de dispositivo autônomo no AL2023. Se você instalar o plug-in de dispositivo da NVIDIA separadamente, por exemplo, como parte da configuração do cluster, exclua-o dos nós do MIG para que ele não entre em conflito com o plug-in de dispositivo gerenciado pelo GPU Operator. Adicione uma regra de afinidade de nós ao plug-in de dispositivo autônomo que exclua os nós que têm o rótulo
nvidia.com/mig.config. -
Sem compatibilidade com o Modo Automático do EKS. O Modo Automático do EKS gerencia o plug-in de dispositivo da NVIDIA e não expõe sua configuração (consulte Implementar uma workload acelerada). Você não pode habilitar o MIG nos nós do Modo Automático do EKS. Configure o MIG em nós autogerenciados do Karpenter ou em um grupo de nós gerenciados em que você controla as configurações da AMI e do plug-in de dispositivo.
Considerações sobre o driver NVIDIA DRA
-
O MIG estático requer instâncias pré-criadas. Com o MIG estático, o driver DRA aloca instâncias MIG existentes, mas não habilita o modo MIG nem particiona as GPUs. Você deve habilitar o modo MIG e criar as instâncias primeiro, por exemplo, com o MIG Manager no NVIDIA GPU Operator ou
nvidia-smi. Para obter mais informações, consulte Usar o MIG com o driver NVIDIA DRA. -
O MIG dinâmico é um recurso alfa. Com o MIG dinâmico, o driver cria e destrói partições MIG sob demanda em resposta às requisições das workloads. Requer o feature gate
DynamicMIG, que é desabilitado por padrão. Para obter mais informações, consulte Usar o MIG com o driver NVIDIA DRA. -
Desabilite o plug-in de dispositivo integrado no Bottlerocket. O driver DRA não pode ser executado junto com o plug-in de dispositivo da NVIDIA no mesmo nó. No Bottlerocket, desabilite o plug-in de dispositivo integrado, que requer a versão 1.63.0 ou posterior do Bottlerocket. Para obter mais informações, consulte Instale o driver NVIDIA DRA.
-
Suporte computacional. O driver NVIDIA DRA é compatível com o provisionamento de capacidade estática no Karpenter, grupos de nós gerenciados pelo EKS ou nós autogerenciados, e não é compatível com o Modo Automático do EKS. Para obter mais informações, consulte a documentação do NodePool estático do Karpenter
no site do Karpenter.
Tipos de instância compatíveis com o MIG
Na AWS, os tipos de instância a seguir fornecem GPUs compatíveis com o MIG.
| Tipo de instância | GPUs | Memória da GPU |
|---|---|---|
|
|
8 x NVIDIA A100 de 40 GB |
320 GB |
|
|
8 x NVIDIA A100 de 80 GB |
640 GB |
|
|
8 x NVIDIA H100 de 80 GB |
640 GB |
|
|
8 x NVIDIA H200 |
1128 GB |
|
|
8 x NVIDIA H200 |
1128 GB |
|
|
8 x NVIDIA Blackwell B200 |
1432 GB |
|
|
8 x NVIDIA Blackwell Ultra B300 |
2144 GB |
|
|
8 x NVIDIA RTX PRO 4500 Blackwell Server Edition |
256 GB |
|
|
8 x NVIDIA RTX PRO 6000 Blackwell Server Edition |
768 GB |
O MIG não está disponível nas famílias g5, g6 ou g6e. Para UltraServers p6e-gb200, que usam a GPU NVIDIA GB200 compatível com o MIG, consulte Uso do P6e-GB200 UltraServers com o Amazon EKS.
nota
O tipo de instância g7 exige a versão 595 ou posterior do driver NVIDIA. Atualmente, as AMIs aceleradas otimizadas para EKS incluem a versão 580 do driver NVIDIA. Portanto, para usar o MIG na g7, você deve criar uma AMI personalizada com a versão 595 do driver. Para obter mais informações, consulte Desenvolvimento de uma AMI do Amazon Linux personalizada e otimizada para o EKS.
As instâncias MIG são descritas por perfis que usam o padrão de nomenclatura <slices>g.<memory>gb, em que <slices> é o número de fatias de computação e <memory> é a memória da instância em gigabytes. Por exemplo, o perfil 3g.40gb fornece três das sete fatias de computação e 40 GB de memória. Os perfis compatíveis com cada GPU são definidos pelo hardware. Para ver a lista completa, consulte NVIDIA Multi-Instance GPU User Guide
Perfis do MIG por tipo de instância
Os perfis disponíveis do MIG em um nó dependem da GPU do tipo de instância. As seções a seguir listam os perfis de cada tipo de instância do Amazon EC2 compatível com o MIG. Para cada perfil, Máximo de instâncias é o número máximo de instâncias desse perfil que você pode criar em uma única GPU, e Memória por instância é a memória da GPU alocada para cada uma.
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 7 |
5 GB |
7 |
|
|
1 de 7 |
10 GB |
4 |
|
|
2 de 7 |
10 GB |
3 |
|
|
3 de 7 |
20 GB |
2 |
|
|
4 de 7 |
20 GB |
1 |
|
|
7 de 7 |
40 GB |
1 |
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 7 |
10 GB |
7 |
|
|
1 de 7 |
20 GB |
4 |
|
|
2 de 7 |
20 GB |
3 |
|
|
3 de 7 |
40 GB |
2 |
|
|
4 de 7 |
40 GB |
1 |
|
|
7 de 7 |
80 GB |
1 |
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 7 |
10 GB |
7 |
|
|
1 de 7 |
20 GB |
4 |
|
|
2 de 7 |
20 GB |
3 |
|
|
3 de 7 |
40 GB |
2 |
|
|
4 de 7 |
40 GB |
1 |
|
|
7 de 7 |
80 GB |
1 |
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 7 |
18 GB |
7 |
|
|
1 de 7 |
35 GB |
4 |
|
|
2 de 7 |
35 GB |
3 |
|
|
3 de 7 |
71 GB |
2 |
|
|
4 de 7 |
71 GB |
1 |
|
|
7 de 7 |
141 GB |
1 |
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 7 |
23 GB |
7 |
|
|
1 de 7 |
45 GB |
4 |
|
|
2 de 7 |
45 GB |
3 |
|
|
3 de 7 |
90 GB |
2 |
|
|
4 de 7 |
90 GB |
1 |
|
|
7 de 7 |
180 GB |
1 |
p6-b300.48xlarge: NVIDIA Blackwell Ultra B300
O p6-b300.48xlarge usa o HGX B300, que é compatível com particionamento de cada GPU em 7 instâncias de 32 GB, 4 de 67 GB, 2 de 135 GB ou 1 de 270 GB. Esses tamanhos são preliminares e podem mudar. Para obter detalhes do perfil, consulte NVIDIA Supported MIG Profiles
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 2 |
16 GB |
2 |
|
|
2 de 2 |
32 GB |
1 |
O RTX PRO 4500 Blackwell também é compatível com as variantes de perfil habilitado para gráficos (+gfx) e de mecanismo de mídia (+me.all, -me). Para ver a lista completa, consulte NVIDIA Supported MIG Profiles
| Perfil | Fatias de computação | Memória por instância | Máximo de instâncias |
|---|---|---|---|
|
|
1 de 4 |
24 GB |
4 |
|
|
2 de 4 |
48 GB |
2 |
|
|
4 de 4 |
96 GB |
1 |
O RTX PRO 6000 Blackwell Server Edition também é compatível com as variantes de perfil habilitado para gráficos (+gfx) e de mecanismo de mídia (+me.all, -me). Para ver a lista completa, consulte NVIDIA Supported MIG Profiles
Estratégias do MIG
O driver NVIDIA DRA e o plug-in de dispositivo da NVIDIA expõem instâncias MIG ao Kubernetes de maneiras diferentes. O plug-in de dispositivo usa uma configuração de estratégia do MIG em todo o nó, enquanto o driver DRA não tem configuração equivalente porque seleciona instâncias por seus atributos. Entender essa diferença é fundamental para escolher entre os dois modelos.
Driver de DRA da NVIDIA
O driver NVIDIA DRA não usa o conceito de estratégia única ou mista, e não há configuração equivalente a ser configurada. Em vez de anunciar instâncias MIG como recursos contados, o driver publica cada instância como um dispositivo no DeviceClass mig.nvidia.com com atributos como seu profile. Os pods selecionam uma instância combinando esses atributos com os seletores em Common Expression Language (CEL) em um ResourceClaim ou ResourceClaimTemplate, conforme mostrado em Usar o MIG com o driver NVIDIA DRA.
Como a seleção é por instância, os nós com perfis mistos funcionam sem a necessidade de alternar o modo de estratégia. Uma única GPU pode ser particionada em vários perfis diferentes, e cada declaração seleciona o perfil de que precisa. A escolha que importa para o driver DRA não é a estratégia única versus a estratégia mista, mas sim o MIG estático versus dinâmico, que controla se você pré-cria as instâncias MIG ou se o driver as cria sob demanda. Para obter mais informações, consulte Usar o MIG com o driver NVIDIA DRA.
Plug-in de dispositivo NVIDIA
O plug-in de dispositivo da NVIDIA anuncia instâncias MIG para o Kubernetes usando uma das duas estratégias. Como o plug-in de dispositivo expõe as instâncias MIG como recursos estendidos no nível do nó, que contêm apenas uma contagem de números inteiros e nenhum atributo por instância, a estratégia determina como esses recursos são nomeados.
-
Estratégia única: cada GPU em um nó usa o mesmo perfil do MIG. O plug-in de dispositivo anuncia cada instância como o recurso
nvidia.com/gpu, e os pods solicitamnvidia.com/gpu: 1como fariam com uma GPU dedicada. Os manifestos existentes não mudam. Tanto o Bottlerocket quanto o AL2023 são compatíveis com a estratégia única. -
Estratégia mista: as GPUs no mesmo nó podem usar perfis diferentes do MIG. O plug-in de dispositivo anuncia cada perfil como um recurso distinto, como
nvidia.com/mig-1g.10gbounvidia.com/mig-3g.40gb, e os pods solicitam o perfil específico de que precisam. Você não pode usar uma estratégia mista com o plug-in de dispositivo da NVIDIA integrado do Bottlerocket. Para obter mais informações, consulte Bottlerocket GitHub issue #4483no GitHub.
Usar o MIG com o driver NVIDIA DRA
Ao alocar instâncias MIG com o driver NVIDIA DRA, os pods solicitam uma instância MIG por meio de um ResourceClaim ou ResourceClaimTemplate, e não do recurso estendido nvidia.com/mig-<profile> do plug-in de dispositivo.
Como o driver DRA descreve as instâncias por seus atributos e não como recursos contados, ele não usa a estratégia única ou mista exigida pelo plug-in de dispositivo (consulte Estratégias do MIG). O driver expõe cada instância MIG como um dispositivo no DeviceClass mig.nvidia.com com um atributo gpu.nvidia.com/type de mig, e anuncia atributos por instância, como o profile (por exemplo, 1g.5gb) e o parentUUID da GPU física. Você combina esses atributos com os seletores em Common Expression Language (CEL) para solicitar um perfil específico ou manter várias instâncias na mesma GPU.
O driver DRA aloca as instâncias MIG em um dos dois modos:
-
MIG estático: você habilita o modo MIG e cria as instâncias MIG no nó antes que o driver inicie, por exemplo, com o MIG Manager no NVIDIA GPU Operator, conforme descrito em Usar o MIG nos nós do AL2023 com o plug-in de dispositivo da NVIDIA. O driver descobre as instâncias existentes e as aloca aos pods, mas não modifica a configuração do MIG do nó. As instâncias adicionadas após a inicialização do driver não são descobertas até que o plug-in do kubelet da GPU seja reiniciado. O MIG estático é o padrão e não requer nenhum feature gate.
-
MIG dinâmico: o driver cria e destrói partições MIG sob demanda em resposta às requisições das workloads, portanto, você não precisa particionar as GPUs com antecedência. O MIG dinâmico é um recurso alfa desabilitado por padrão. Você solicita um perfil com os mesmos seletores
ResourceClaimTemplatemostrados nas seções a seguir, e o driver particiona uma GPU para atender à requisição.
Considerações
-
O MIG dinâmico substitui a descoberta estática em um nó. O driver gerencia todas as partições e destrói todas as partições MIG que não foram criadas quando o plug-in do kubelet da GPU foi iniciado. Não habilite o MIG dinâmico em nós com partições pré-criadas que você deseja manter e não execute
mig-partedounvidia-smi migenquanto o plug-in estiver em execução, pois as alterações manuais podem entrar em conflito com o estado da partição do driver e causar falhas na preparação ou limpeza dos pods. -
O MIG dinâmico está em estado alfa e requer que um feature gate seja habilitado ao instalar o driver NVIDIA DRA. Consulte Instale o driver NVIDIA DRA para obter instruções.
-
As arquiteturas Hopper (H100 e H200) e posteriores habilitam o modo MIG sob demanda. As gerações anteriores não podem habilitar o modo MIG sob demanda, incluindo as GPUs Ampere (A100).
-
O MIG dinâmico depende do recurso de dispositivos particionáveis do Kubernetes (KEP-4815
no GitHub), que é habilitado por padrão na versão 1.36 e posterior do Kubernetes. Em versões anteriores, esse recurso não é habilitado por padrão, portanto, o agendador não pode alocar dispositivos MIG criados dinamicamente.
Pré-requisitos
-
Um cluster do Amazon EKS que executa a versão 1.34 ou posterior do Kubernetes com capacidade estática provisionada pelo Karpenter, grupos de nós gerenciados pelo EKS ou grupos de nós autogerenciados.
-
Nós da família P compatíveis com o MIG com o modo MIG habilitado e GPUs particionadas em instâncias MIG. Para MIG estático, consulte o MIG Manager in the NVIDIA GPU Operator
no site da NVIDIA. -
O driver NVIDIA DRA instalado conforme descrito em Instale o driver NVIDIA DRA, opcionalmente com o Dynamic MIG habilitado se você não estiver usando o particionamento MIG estático.
Procedimento
Os exemplos a seguir podem ser usados com o MIG estático ou dinâmico e com o driver NVIDIA DRA.
-
Crie um
ResourceClaimTemplateque solicite uma instância MIG doDeviceClassmig.nvidia.come um pod que faça referência a ela. Este exemplo solicita qualquer instância MIG disponível sem restringir o perfil.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 -
Verifique se o pod foi alocado em uma única instância MIG.
kubectl logs mig-dra-podVeja abaixo um exemplo de saída. O pod vê uma instância MIG da GPU particionada.
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)
Solicitar um perfil específico do MIG
Para solicitar um perfil específico em vez de qualquer instância disponível, adicione um seletor CEL que corresponda ao atributo profile. O ResourceClaimTemplate a seguir solicita uma instância 1g.5gb e o pod faz referência a ela.
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
Solicitar várias instâncias MIG da mesma GPU
Para garantir que várias instâncias MIG em uma única declaração venham da mesma GPU física, adicione um bloco constraints com matchAttribute: "gpu.nvidia.com/parentUUID". O ResourceClaimTemplate a seguir solicita uma instância 1g.5gb e uma instância 2g.10gb da mesma GPU, e o pod faz referência à declaração. Como o contêiner faz referência à declaração sem nomear uma requisição específica, ele recebe as duas instâncias 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
Usar o MIG em nós do Bottlerocket com o plug-in de dispositivo da NVIDIA
No Bottlerocket, a AMI acelerada otimizada para EKS inclui o plug-in de dispositivo da NVIDIA. Você habilita o MIG com a estratégia única por meio das configurações de settings.kubelet-device-plugins.nvidia. O Bottlerocket é compatível com o MIG na versão 1.34.0 e posterior.
Pré-requisitos
-
Um cluster do Amazon EKS. O procedimento a seguir provisiona nós da família P compatíveis com o MIG com a AMI Bottlerocket NVIDIA otimizada para EKS, versão 1.34.0 ou posterior.
-
O Karpenter instalado e configurado em seu cluster, porque o procedimento a seguir usa um
EC2NodeClassdo Karpenter para fornecer as configurações do MIG nos dados do usuário do nó do Bottlerocket. Para obter mais informações, consulte Getting Started with Karpenterno site do Karpenter. -
kubectlconfigurado para se comunicar com o seu cluster; consulte Instalar ou atualizar o kubectl para obter mais informações.
Procedimento
Adicione a configuração de particionamento MIG aos dados do usuário do Bottlerocket para seus nós de GPU. A forma como você fornece dados do usuário depende de como você provisiona os nós. O exemplo a seguir mostra um EC2NodeClass do Karpenter para nós p4d.24xlarge.
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
Quando os nós provisionados com essas configurações se juntam ao cluster, o modo MIG é habilitado nas GPUs, cada GPU é particionada em instâncias 2g.10gb e o plug-in de dispositivo anuncia as instâncias resultantes como o recurso nvidia.com/gpu. Como um p4d.24xlarge tem oito GPUs A100 e cada uma oferece suporte a três instâncias 2g.10gb, o nó anuncia nvidia.com/gpu: 24.
nota
A configuração mig.profile é definida pelo modelo de GPU, como a100.40gb ou h100.80gb. Sem uma configuração de mig.profile, a GPU habilita o modo MIG e usa seu maior perfil. Como o Bottlerocket usa a estratégia única, cada GPU no nó usa o mesmo perfil. Para usar perfis diferentes no mesmo nó (a estratégia mista), use o caminho do AL2023 com o NVIDIA GPU Operator.
Usar o MIG nos nós do AL2023 com o plug-in de dispositivo da NVIDIA
No AL2023, as etapas a seguir usam o NVIDIA GPU Operator para instalar o plug-in de dispositivo da NVIDIA e o MIG Manager. O MIG Manager habilita o modo MIG e particiona as GPUs de acordo com a configuração fornecida por você. O plug-in de dispositivo da NVIDIA então anuncia as instâncias resultantes para o Kubernetes. O GPU Operator é compatível com as estratégias simples e mistas.
Como a AMI NVIDIA AL2023 otimizada para EKS já inclui o driver e o kit de ferramentas da NVIDIA, desabilite o gerenciamento de drivers no GPU Operator para evitar conflitos com o driver pré-instalado. Como alternativa, você pode instalar e gerenciar o plug-in de dispositivo da NVIDIA e o MIG Manager por conta própria sem usar o GPU Operator.
Pré-requisitos
-
Um cluster do Amazon EKS. O procedimento a seguir fornece nós da família P compatíveis com o MIG (como
p4d.24xlarge) com a AMI NVIDIA AL2023 otimizada para EKS. -
O Karpenter instalado e configurado em seu cluster, porque o procedimento cria um
EC2NodeClasseNodePooldo Karpenter para provisionar os nós da GPU. Para obter mais informações, consulte Getting Started with Karpenterno site do Karpenter. -
O Helm instalado em seu ambiente de linha de comando. Consulte as Instruções de configuração do Helm para obter mais informações.
-
kubectlconfigurado para se comunicar com o seu cluster; consulte Instalar ou atualizar o kubectl para obter mais informações.
Procedimento
-
Crie um
EC2NodeClasseNodePoolpara nós de GPU da família P do AL2023. No AL2023, o particionamento MIG é aplicado pelo GPU Operador em etapas posteriores, portanto, esta é uma classe de nó de GPU padrão do AL2023. O exemplo a seguir provisiona nósp4d.24xlargecom a AMI NVIDIA AL2023 otimizada para EKS.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 -
Adicione o repositório NVIDIA Helm.
helm repo add nvidia https://nvidia.github.io/gpu-operator helm repo update -
Crie um arquivo
gpu-operator-values.yamlque desabilite o gerenciamento de drivers, selecione a estratégia mista e defina os perfis MIG a serem aplicados. O exemplo a seguir define uma configuraçãop4d-half-balancedque particiona quatro das oito GPUs em um nóp4d.24xlargee deixa o restante inteiro.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 -
Instale o GPU Operator com o arquivo de valores.
helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --values gpu-operator-values.yaml -
Rotule seus nós compatíveis com o MIG com a configuração de perfil a ser aplicada. O componente MIG Manager monitora esse rótulo e particiona as GPUs adequadamente, reinicializando o nó para aplicar a alteração.
kubectl label nodes -l node.kubernetes.io/instance-type=p4d.24xlarge \ nvidia.com/mig.config=p4d-half-balanced --overwrite -
Depois que o GPU Operator particiona as GPUs, os pods solicitam um perfil MIG específico pelo nome do recurso, em vez de
nvidia.com/gpu. O exemplo a seguir executa um pod que solicita uma instância1g.5gb.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
Para obter exemplos completos de configuração de estratégia mista para instâncias da família P, incluindo grupos de nós gerenciados com reservas de capacidade e workloads por perfil, consulte a seção MIG do Guia de práticas recomendadas do Amazon EKS.
Verificar se o MIG está ativo
Depois que seus nós habilitados para MIG estiverem Ready, confirme se o modo MIG está ativo nas GPUs e se o nó anuncia os recursos MIG esperados.
-
Confirme se o nó anuncia os recursos do MIG. Com a estratégia única, o nó indica as instâncias como
nvidia.com/gpu. Com a estratégia mista, o nó indica recursos específicos do perfil, comonvidia.com/mig-1g.10gb.kubectl describe node <node-name> | grep nvidia.com -
Execute
nvidia-smide um pod em um nó habilitado para MIG para confirmar se o modo MIG está ativo.nvidia-smiindicaMIG M.: Enabledpara as GPUs que têm o modo MIG ativado e lista as instâncias MIG configuradas em cada uma. Confira a seguir um exemplo de saída de uma GPU A100 de 40 GB com o MIG habilitado e particionado em instâncias3g.20gb,2g.10gbe1g.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 | | | +------------------+----------------------------------+-----------+-----------------------+Com a estratégia mista, um pod vê somente a instância MIG solicitada, não o layout completo da GPU do nó. O pod
mig-inferenceda etapa anterior solicitou uma instâncianvidia.com/mig-1g.5gb, entãonvidia-smi -Ldentro desse pod lista um único dispositivo MIG.kubectl logs mig-inferenceVeja abaixo um exemplo de saída.
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)Para ver o layout completo da partição de cada GPU em um nó, execute
nvidia-smi -Lno host em vez de dentro de um pod da workload. O comando a seguir inicia um pod de depuração privilegiado no nó e executa onvidia-smido host. Substituanode-namepelo nome do seu nó habilitado para MIG.kubectl debug node/<node-name> -it --profile=sysadmin --image=nvidia/cuda:12.6.0-base-ubuntu22.04 -- chroot /host nvidia-smi -LConfira a seguir um exemplo de saída para a configuração
p4d-half-balanced. As quatro primeiras GPUs são particionadas em instâncias MIG e as quatro restantes são GPUs inteiras. Cada linhaMIGé uma instância isolada de hardware com seu próprio UUID, memória e fatias de computação.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)
