View a markdown version of this page

Usando o agendamento com reconhecimento de topologia na Amazon SageMaker HyperPod - SageMaker Inteligência Artificial da Amazon
UltraServer arquiteturaRótulos de topologiaPlug-ins de topologia do SlurmPráticas recomendadasLimitações

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Usando o agendamento com reconhecimento de topologia na Amazon SageMaker HyperPod

A eficiência da transferência de dados é um fator crítico nas workloads de machine learning e de computação de alta performance (HPC). Ao usar UltraServers com a Amazon SageMaker HyperPod, aplica SageMaker HyperPod automaticamente rótulos de topologia aos seus recursos. Topology-aware o agendamento ajuda a alocar recursos para minimizar as despesas gerais de transferência de dados, considerando tanto a topologia da instância (como os recursos são conectados dentro de uma instância) quanto a topologia da rede (como as instâncias estão conectadas umas às outras). Para ter mais informações sobre os tipos de instância, veja Topologia da instância do Amazon EC2.

Topology-aware o agendamento funciona com os dois clusters no Slurm e no Amazon EKS. Para ter informações gerais sobre como a topologia funciona com o Slurm, consulte Topology Guide na documentação do Slurm.

Na Amazon SageMaker HyperPod, as despesas gerais de transferência de dados geralmente vêm de três fontes principais:

  • GPU-to-GPU transferência de dados: tecnologias modernas, como switches NVLink e NVLink, permitem a transferência de dados de alto rendimento entre GPUs sem envolver outros recursos computacionais. Isso é extremamente eficiente, mas geralmente limita-se a uma única instância.

  • GPU-to-CPU transferência de dados: os sistemas de acesso à Non-uniform memória (NUMA) têm vários barramentos de sistema em uma única placa-mãe. Em uma arquitetura típica de instância do EC2, como p5.48xlarge, há dois barramentos de sistema diferentes, cada um com uma CPU e quatro GPUs. Para um desempenho ideal, os processos que carregam ou leem to/from GPUs de dados devem ser executados em uma CPU conectada ao mesmo barramento de sistema da GPU.

  • Comunicações de rede entre instâncias: as instâncias transferem dados por meio de uma cadeia de comutadores de rede. O caminho mais curto normalmente corresponde à menor latência.

UltraServer arquitetura

SageMaker HyperPod oferece suporte à UltraServer arquitetura com instâncias p6e-gb200.36xlarge. E UltraServer contém até 18 instâncias p6e-gb200.36xlarge, com 4 GPUs em cada instância. Todas as GPUs em todos os nós são interconectadas por meio de switches NVLink, permitindo a transferência de dados entre quaisquer duas GPUs sem usar interfaces de rede.

Essa arquitetura oferece um aumento significativo de desempenho em comparação com instâncias individuais. Para aproveitar essa arquitetura de forma eficaz, os trabalhos devem ser enviados aos nós de computação a partir de um único UltraServer.

Rótulo de topologia do EKS

De acordo com a topologia da instância do EC2, rotula HyperPod automaticamente seus nós com os seguintes rótulos:

  • topologia. kubernetes. io/region- aquele em Região da AWS que o nodo reside.

  • topologia. kubernetes. io/zone- a zona de disponibilidade na qual o nó reside.

  • topologia.k8s. aws/network-node-layer - NetworkNodes descreve o conjunto de nós de rede de uma instância. Em cada conjunto de nós de rede, os respectivos nós são listados em ordem hierárquica decrescente. O nó de rede conectado à instância é o último nó de rede na lista. Há até quatro camadas de nós de rede, e cada um é marcado com um rótulo. As camadas disponíveis são topology.k8s.aws/network-node-layer-1, topology.k8s.aws/network-node-layer-2 e topology.k8s.aws/network-node-layer-3.

  • topologia.k8s. aws/ultraserver-id - Um identificador usado para rotular cada uma das instâncias pertencentes ao mesmo domínio NVLink em um Ultraserver. Para saber mais sobre como usar UltraServers com SageMaker HyperPod, consulteUsando UltraServers na Amazon SageMaker HyperPod.

Usando esses rótulos, você pode usar o agendamento com reconhecimento de topologia na governança de HyperPod tarefas para aplicar rótulos e anotações de topologia para otimizar a eficiência do treinamento de suas cargas de trabalho. Para obter mais informações, consulte Usando o agendamento com reconhecimento de topologia na governança de tarefas da Amazon SageMaker HyperPod.

Plug-ins de topologia de rede do Slurm

O Slurm fornece plug-ins integrados para reconhecimento da topologia de rede. SageMaker HyperPod seleciona e configura automaticamente o plug-in de topologia apropriado com base nos tipos de instância em seu cluster.

Seleção automática de topologia

Quando você cria um cluster do HyperPod Slurm, o sistema inspeciona todos os grupos de instâncias e seus tipos de instância associados, identifica as características de comunicação da GPU de cada tipo de instância e configura o Slurm com o plug-in de topologia apropriado. Esse processo é executado automaticamente e não requer nenhuma configuração.

HyperPod gerencia a topologia por meio de um arquivo gerado topology.conf dinamicamente. À medida que o cluster evolui por meio de operações de escalabilidade ou substituições de nós, reconcilia HyperPod continuamente a configuração da topologia para refletir o estado atual do cluster. Para obter mais informações, consulte Atualizações de topologia dinâmica.

Usando o topology/tree plugin

O topology/tree plug-in modela estruturas hierárquicas de comunicação com vários níveis de largura de banda. A topologia em árvore permite que o Slurm realize trabalhos de uma forma que minimize a comunicação entre camadas e maximize a localidade.

A topologia em árvore é usada para tipos de instância com interconexões hierárquicas, nas quais cargas de trabalho de treinamento distribuídas se beneficiam do posicionamento com reconhecimento de localidade. Isso inclui tipos de instância como ml.p5.48xlargeml.p5e.48xlarge, ml.p5en.48xlarge e.

SageMaker HyperPod configura automaticamente o topology/tree plug-in quando seu cluster usa esses tipos de instância. O gerado topology.conf mapeia os nós em uma hierarquia de switches que reflete os níveis de comunicação do seu hardware.

Garanta que slurm.conf inclua:

TopologyPlugin=topology/tree

Configuração

SageMaker HyperPod configura automaticamente o topology/tree plug-in com base nas informações fornecidas pelo Amazon EC2. Para obter mais detalhes sobre a topologia do Amazon EC2, consulte Topologia de instâncias do Amazon EC2.

Quando o topology/tree plug-in é usado, o Slurm topology.conf tem a seguinte aparência:

SwitchName=nn-6fe9d8a965d34d181 Switches=nn-0b53107754517bf0e

SwitchName=nn-0b53107754517bf0e Switches=nn-424c855d4ad825aa4,nn-95acd7c656329fc30

SwitchName=nn-424c855d4ad825aa4 Nodes=ip-10-1-111-198
SwitchName=nn-95acd7c656329fc30 Nodes=ip-10-1-53-231

Usage

Quando o topology/tree plug-in é configurado, o Slurm tenta alocar máquinas próximas umas das outras. Você pode forçar o Slurm a alocar máquinas em um único switch passando o parâmetro da linha de --switch comando para ou: sbatch srun

sbatch --switch=1 ....

Usando o topology/block plugin

A NVIDIA desenvolveu um topology/block plug-in que fornece agendamento hierárquico em blocos de nós com as seguintes características:

  • Um bloco é um intervalo consecutivo de nós.

  • Os blocos não podem se sobrepor uns aos outros.

  • Todos os nós em um bloco são alocados a uma tarefa antes que o próximo bloco seja usado.

  • O tamanho do bloco de planejamento é o menor tamanho de bloco configurado.

  • Cada tamanho de nível de bloco maior é uma potência de dois em relação ao anterior.

Esse plug-in aloca nós com base na topologia de rede definida.

A topologia de blocos modela domínios de comunicação uniformes e de alta largura de banda, nos quais todas as GPUs participam de um único domínio de alta velocidade com latência quase uniforme. A topologia de blocos trata todos os nós como parte de uma única unidade de comunicação coesa. UltraServer arquitetura em SageMaker HyperPod suporta o plugin de bloco.

A topologia de blocos é usada para tipos de instância, como ml.p6e-gb200.NVL72 e. ml.p6e-gb300.NVL72

Configuração

SageMaker HyperPod configura automaticamente o topology/block plugin. Se você quiser configurar o plug-in manualmente, especifique o seguinte no topology.conf arquivo no diretório de configuração do Slurm:

BlockName=us1 Nodes=ultraserver1-[0-17]
BlockName=us2 Nodes=ultraserver2-[0-17]
BlockSizes=18

Garanta que slurm.conf inclua:

TopologyPlugin=topology/block

Usage

Ao enviar trabalhos, você pode usar os seguintes argumentos adicionais com os comandos sbatch e srun:

  • --segment=N: especifique o número de nós a serem agrupados. O tamanho do segmento deve ser menor que ou igual ao tamanho do bloco de planejamento.

  • --exclusive=topo: solicite que nenhum outro trabalho seja colocado no mesmo bloco. Isso é útil para aplicações de avaliação comparativa e sensíveis ao desempenho.

Veja a seguir cenários de exemplo que você pode considerar ao pensar em alocar blocos.

Alocar um bloco inteiro de nós em um sistema vazio

sbatch -N18

Alocar dois blocos inteiro de nós em um sistema vazio

sbatch -N36

Alocar 18 nós em um bloco e mais 6 nós em outro bloco

sbatch -N24

Alocar 12 nós em um bloco e mais 12 nós em outro bloco

sbatch -N24 --segment=12

Com --exclusive=topo, o trabalho deve ser colocado em um bloco sem outros trabalhos

sbatch -N12 --exclusive=topo

Seleção de topologia para clusters com tipos de instância mistos

HyperPod atualmente usa o Slurm 24.11, que suporta somente uma única configuração de topologia por cluster. Isso significa que a seleção de topologia por partição não é suportada, vários modelos de topologia não podem coexistir em um único cluster e todos os nós devem estar em conformidade com uma única definição de topologia.

Quando seu cluster contém vários tipos de instância, HyperPod seleciona uma topologia compatível com todos eles. A tabela a seguir mostra um exemplo de como HyperPod resolve a topologia de um cluster com tipos de instância mistos.

Grupo de instâncias Tipo de instância Topologia preferida

IG-1

ml.p5.48xlarge

Árvore

IG-2

ml.P6e-GB300.Nvl72

Bloquear

Neste exemplo, a topologia de blocos é ideal para ml.p6e-GB300.Nvl72, mas a topologia em árvore é compatível com ml.p5.48xlarge e ml.p6e-GB300.Nvl72. HyperPod seleciona a topologia em árvore como a topologia de todo o cluster para garantir que todos os nós possam participar do agendamento corretamente e que nenhum tipo de instância seja excluído ou deturpado.

Importante

Para cargas de trabalho em que o agendamento com reconhecimento de topologia é fundamental para o desempenho, recomendamos criar clusters separados para cada tipo de instância, em vez de combinar diferentes tipos de instância em um único cluster. Isso garante que cada cluster use a topologia ideal para seu hardware, oferecendo o melhor desempenho possível da carga de trabalho. Por exemplo, em vez de combinar instâncias ml.p5.48xlarge e ml.p6e-GB300.nvl72 em um único cluster em que a topologia em árvore é selecionada como um compromisso compatível, crie um cluster dedicado para cada tipo de instância para que cada um use seu modelo de topologia ideal.

Desativar ou alterar o plug-in de topologia

Quando um cluster Slurm é criado, seleciona HyperPod automaticamente o plug-in de topologia ideal. Para alterar manualmente o plug-in de topologia, atualize o TopologyPlugin valor slurm.conf no nó do controlador.

Exemplo:

# Set this value to disable topology plugin
TopologyPlugin=topology/flat

Atualizações de topologia dinâmica

Topology-aware o agendamento mantém continuamente a correção da topologia à medida que seu cluster muda. A topologia é recalculada automaticamente e o topology.conf arquivo é regenerado quando ocorre qualquer um dos seguintes eventos:

  • Scale-up: novos nós são adicionados ao cluster.

  • Scale-down: os nós são removidos do cluster.

  • Substituição de nós: os nós com falha ou não íntegros são substituídos, ou os nós são substituídos manualmente usando a BatchReplaceClusterNodesAPI.

Quando a topologia é atualizada, novos nós são incorporados à estrutura de topologia correta, os nós removidos são removidos e a configuração do Slurm é atualizada sem a necessidade de intervenção manual. Isso garante que a topologia sempre reflita o estado real do cluster.

nota

Usuários avançados podem substituir o comportamento da topologia fazendo login no nó do controlador Slurm e modificando manualmente e. slurm.conf topology.conf No entanto, as alterações manuais podem ser substituídas HyperPod durante as atualizações subsequentes do cluster, incluindo operações de escalabilidade, substituições de nós e outros eventos do ciclo de vida do cluster. Se você modificar esses arquivos manualmente, verifique suas alterações após qualquer atualização do cluster.

Práticas recomendadas para UltraServer topologia

Para um desempenho ideal com UltraServer arquitetura em SageMaker HyperPod:

  • Defina os tamanhos de bloco apropriados: configure BlockSizes=18 (ou 17 se um nó estiver sobressalente) para corresponder à UltraServer arquitetura.

  • Use segmentos para melhorar a disponibilidade: use --segment=16, --segment=8 ou --segment=9 com os comando srun e sbatch para melhorar a flexibilidade do agendamento de trabalhos.

  • Considere o tamanho do trabalho e o tamanho do segmento:

    • SeBlockSizes=18, trabalhos com até 18 instâncias sempre serão executados em uma única UltraServer.

    • SeBlockSizes=16, trabalhos com menos de 16 instâncias sempre serão executados em uma única UltraServer, enquanto trabalhos com 18 instâncias poderão ser executados em uma ou duas UltraServers.

Ao pensar em segmentar, considere o seguinte:

  • Com--segment=1, cada instância pode ser executada separadamente UltraServer.

  • Com-N 18 --segment 9, 9 nós serão colocados em um UltraServer e outros 9 nós poderão ser colocados no mesmo ou em outro UltraServer.

  • Com-N 24 --segment 8, o trabalho pode ser executado em 2 ou 3 UltraServers, com cada 8 nós colocados juntos no mesmo servidor.

Limitações na programação com reconhecimento de SageMaker HyperPod topologia

O plug-in topology/block tem limitações com clusters heterogêneos (clusters com diferentes tipos de instância):

  • Somente os nós listados em blocos são programáveis pelo Slurm.

  • Cada bloco deve ter pelo menos BlockSizes[0] nó.

Para clusters heterogêneos, considere estas alternativas:

  • Não use o plug-in de bloco com clusters heterogêneos. Em vez disso, isole UltraServer os nós em uma partição diferente.

  • Crie um cluster separado UltraServers somente na mesma VPC e use a configuração multicluster do Slurm.