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 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 a topologia da instância (como os recursos são conectados em uma instância) e 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 ambos os 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:

UltraServer arquitetura

SageMaker HyperPod oferece suporte à UltraServer arquitetura com instâncias p6e-gb200.36xlarge. Um 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:

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 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 arquivos de configuração gerados dinamicamente. No Slurm 25.11 e versões posteriores, a topologia é definida em um topology.yaml arquivo, que é a fonte da verdade e suporta várias definições de topologia e atribuição por partição. No Slurm 24.x, a topologia é definida em um topology.conf arquivo com uma única topologia em todo o cluster. À medida que o cluster evolui por meio de operações de escalabilidade ou substituição 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 dinâmicas de topologia.

Tipos de instância que oferecem suporte à topologia de rede

HyperPod configura a topologia de árvore ou bloco para tipos de instância que suportam a topologia de instância do Amazon EC2. Para ver a lista confiável e atualizada dos tipos de instâncias compatíveis, consulte Pré-requisitos para a topologia do Amazon EC2 no Guia do usuário do Amazon EC2.

Os tipos de instância compatíveis incluem famílias de computação acelerada, como G6e, G7e, P4d, P4de, P5, P5e, P5en e, além das famílias AWS Trainium, como Trn1, Trn1n e P6e-GB200 Trn2. UltraServertipos de instância (por exemplo,ml.p6e-gb200.36xlarge) usam topologia de blocos, e outros tipos de instância com capacidade de topologia usam topologia em árvore.

Usando o topology/tree plugin

O topology/tree plug-in modela estruturas de comunicação hierárquicas com vários níveis de largura de banda. A topologia em árvore permite que o Slurm coloque 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, em que cargas de trabalho de treinamento distribuídas se beneficiam do posicionamento com reconhecimento de localidade. Isso inclui tipos de instânciaml.p5.48xlarge, comoml.p5e.48xlarge, ml.p5en.48xlarge e.

SageMaker HyperPod configura automaticamente o topology/tree plug-in quando seu cluster usa esses tipos de instância. A configuração de topologia gerada mapeia os nós em uma hierarquia de switch que reflete as camadas de comunicação do seu hardware.

Garanta que slurm.conf inclua:

TopologyPlugin=topology/tree

Configuração

SageMaker HyperPod configura automaticamente a topologia da árvore com base nas informações fornecidas pelo Amazon EC2. Para obter mais detalhes sobre a topologia do Amazon EC2, consulte Topologia de instância do Amazon EC2.

No Slurm 25.11 e versões posteriores, HyperPod define a topologia emtopology.yaml, que é a fonte da verdade. Uma entrada de topologia em árvore mapeia os nós em uma hierarquia de switch que reflete os níveis de comunicação do seu hardware:

- topology: tree
  cluster_default: true
  tree:
    switches:
      - switch: root
        children: leaf-0,leaf-1
      - switch: leaf-0
        nodes: compute-1,compute-2
      - switch: leaf-1
        nodes: compute-3,compute-4

No Slurm 24.x, a topologia em árvore é definida em topology.conf vez disso, que usa o seguinte formato:

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:

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 a arquitetura em SageMaker HyperPod suporta o plugin de blocos.

A topologia de blocos é usada para tipos de UltraServer instância, comoml.p6e-gb200.36xlarge.

Garanta que slurm.conf inclua:

TopologyPlugin=topology/block

Configuração

SageMaker HyperPod configura automaticamente a topologia de blocos. No Slurm 25.11 e versões posteriores, a topologia de blocos é definida emtopology.yaml, que é a fonte da verdade. As topologias de blocos e árvores de um cluster são definidas juntas no mesmo arquivo. O exemplo a seguir mostra um cluster com uma partição P5 (árvore) e uma UltraServer partição (bloco):

- topology: tree
  cluster_default: true
  tree:
    switches:
      - switch: root
        children: leaf-0,leaf-1
      - switch: leaf-0
        nodes: compute-p5-1,compute-p5-2
      - switch: leaf-1
        nodes: compute-p5-3,compute-p5-4
- topology: block
  cluster_default: false
  block:
    block_sizes:
      - 18
    blocks:
      - block: cb-001
        nodes: ultraserver-1-[1-18]

No Slurm 24.x, a topologia de blocos é definida em topology.conf vez disso, que usa o seguinte formato:

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

Usage

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

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

Partition-level seleção de topologia

A partir do Slurm 25.11, HyperPod oferece suporte à configuração de topologia no nível da partição. Cada partição recebe uma topologia com base nos tipos de instância de seus grupos de instâncias de computação, para que um único cluster possa executar a topologia em árvore em uma partição e a topologia de blocos em outra. As partições que contêm tipos de instância sem suporte à topologia de rede herdam um flat padrão para todo o cluster, que mantém seus nós programáveis.

HyperPod resolve a topologia de cada partição da seguinte forma:

A topologia padrão para todo o cluster é selecionada com base nas topologias presentes no cluster: se apenas um tipo de topologia estiver presente, esse tipo será o padrão; se o bloco e a árvore estiverem presentes sem grupos não topológicos, a árvore será o padrão; e se algum grupo de computação não topológico estiver presente, será o padrão para que esses nós permaneçam programáveis. flat

A tabela a seguir mostra um exemplo de como HyperPod resolve a topologia de um cluster com tipos mistos de instâncias.

Neste exemplo, a partição P5 usa topologia em árvore e a UltraServer partição usa topologia em bloco. Com a topologia em nível de partição, cada partição usa sua topologia ideal dentro do mesmo cluster, então você não precisa mais criar clusters separados para dar a cada tipo de instância seu modelo de topologia ideal.

Topologia plana padrão

Quando um cluster contém uma combinação de tipos de instância com e sem topologia, HyperPod aplica-se topology/flat como padrão do cluster. Topology-aware as partições são apontadas para sua topologia de árvore ou bloco por meio de Topology= diretivas por partição no slurm.conf (Slurm 25.11 e versões posteriores), enquanto as partições com nós que não são de topologia não têm diretiva e herdam o padrão plano. Topology= Isso garante que cada nó permaneça programável.

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.

Para desativar o posicionamento com reconhecimento de topologia, defina o plug-in como topology/flat (ou): topology/default

# Set this value to disable topology-aware placement
TopologyPlugin=topology/flat

Atualizações dinâmicas de topologia

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

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.

Práticas recomendadas para UltraServer topologia

Para um desempenho ideal com UltraServer arquitetura em SageMaker HyperPod:

Ao pensar em segmentar, considere o seguinte:

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

Com o Slurm 25.11 e versões posteriores, clusters heterogêneos (clusters com diferentes tipos de instância) são suportados por meio da topologia em nível de partição e do cluster padrão. flat Cada partição recebe a topologia mais adequada aos seus tipos de instância, e a não topologia e UltraServer os nós permanecem programáveis no mesmo cluster. Para obter mais informações, consulte Partition-level seleção de topologia.

Em clusters executando o Slurm 24.x, uma única topologia em todo o cluster se aplica, e o topology/block plug-in tem as seguintes limitações com clusters heterogêneos:

Para clusters heterogêneos no Slurm 24.x, considere estas alternativas: