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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html). 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](https://slurm.schedmd.com/topology.html) 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 os 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 lêem dados das to/from GPUs 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. 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: + **topologia.kubernetes. io/region**- a em Região da AWS que o nodo reside. + **topologia.kubernetes. io/zone**- a zona de disponibilidade em que 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, consulte[Usando UltraServers na Amazon SageMaker HyperPod](sagemaker-hyperpod-ultraserver.md). 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](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks-scheduling.md). ## 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](#sagemaker-hyperpod-topology-dynamic-updates). ### 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 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology-prerequisites.html#inst-net-topology-prereqs-instance-types) 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ância`ml.p5.48xlarge`, como`ml.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. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html) No Slurm 25.11 e versões posteriores, HyperPod define a topologia em`topology.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: + 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 a arquitetura em SageMaker HyperPod suporta o plugin de blocos. A topologia de blocos é usada para tipos de UltraServer instância, como`ml.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 em`topology.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`: + `--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 ``` ### 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: + Se cada grupo de instâncias de computação na partição for do tipo UltraServer instância, a partição usará `block` topologia. + Se cada grupo de instâncias de computação na partição oferecer suporte à topologia de rede (e a partição não for toda UltraServer), a partição usará `tree` topologia. + Se uma partição contiver ambos UltraServer e outros tipos de instância com capacidade de topologia, a partição usará topologia. `tree` + Se algum grupo de instâncias de computação na partição usar um tipo de instância que não ofereça suporte à topologia de rede, a partição não terá atribuição de topologia e herdará o padrão para todo o cluster. `flat` 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. | Grupo de instâncias | Tipo de instância | Topologia aplicada | | --- | --- | --- | | IG-1 | ml.p5.48xlarge | Árvore | | IG-2 | ml.p6e-gb200.36xlarge | Bloquear | 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. **nota** Em clusters executando o Slurm 24.x, somente uma única configuração de topologia em todo o cluster é suportada. Per-partition a topologia requer o Slurm 25.11 ou posterior. ### 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: + **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**: nós com falha ou não íntegros são substituídos ou os nós são substituídos manualmente usando a [ BatchReplaceClusterNodes ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchReplaceClusterNodes.html) API. 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ó controlador do Slurm e modificando manualmente o arquivo de topologia aplicável (`topology.yaml`no Slurm 25.11 `slurm.conf` e posterior ou no Slurm 24.x). `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ó for 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**: + Se`BlockSizes=18`, trabalhos com até 18 instâncias sempre serão executados em uma única UltraServer. + Se`BlockSizes=16`, trabalhos com menos de 16 instâncias sempre serão executados em uma única instância 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 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](#sagemaker-hyperpod-topology-partition-level). Em clusters que executam 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: + Somente os nós listados em blocos podem ser programados pelo Slurm. + Cada bloco deve ter pelo menos `BlockSizes[0]` nós. Para clusters heterogêneos no Slurm 24.x, 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.