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á.
Redes
dica
Inscreva-se nos
Considere maior largura de banda de rede ou adaptador de malha elástica para aplicações com alta comunicação Inter-Node
Para cargas de trabalho de treinamento distribuídas no Amazon EKS com altas demandas de comunicação entre nós, considere selecionar instâncias com maior largura de banda de rede ou Elastic Fabric Adapter (EFA). O desempenho insuficiente da rede pode prejudicar a transferência de dados, retardando as tarefas de aprendizado de máquina, como o treinamento distribuído de várias GPUs. Observe que as cargas de trabalho de inferência normalmente não têm alta comunicação entre nós.
Certifique-se de que sua imagem de contêiner inclua NCCL e o plug-in aws-ofi-nccl (que permite que a NCCL use o EFA via
Considerações sobre provisionamento de nós para cargas de trabalho do EFA
Ao provisionar EFA-capable nós, as instâncias que precisam se comunicar devem estar na mesma zona de disponibilidade (requisito rígido). Além disso, a AWS recomenda o lançamento de todas as EFA-enabled instâncias em um grupo de posicionamento de cluster para minimizar a distância física entre elas dentro de uma única AZ, o que oferece a menor latência possível. Não é necessário um grupo de posicionamento para que o EFA funcione, mas é altamente recomendado para um desempenho ideal.
As considerações a seguir se aplicam a qualquer implantação de treinamento EFA-based distribuído no EKS. Abaixo, nos referimos às anotações do Karpenter como exemplo, mas as mesmas considerações também podem ser aplicadas às implementações de grupos gerenciados e de Self-managed nós.
-
Fixar em um AZ. O EFA exige que todos os nós comunicantes estejam no mesmo AZ, portanto, por exemplo, os nós que participam do mesmo trabalho de treinamento distribuído não devem estar espalhados entre as zonas. Você pode aplicar isso fixando o pod em uma AZ usando uma afinidade
nodeSelectorou pod ativada.topology.kubernetes.io/zoneSelecione a AZ em que seu tipo de instância de destino tem a melhor disponibilidade ou onde seu bloco de capacidade está reservado. Esteja ciente de que, embora a co-localização Same-AZ melhore a latência entre nós, ela também aumenta o raio de explosão de uma falha. AZ-level Para cargas de trabalho de treinamento de longa duração, um único evento de interrupção ou capacidade do AZ pode acabar com horas de progresso acumulado no treinamento — uma perda cara. Inclua isso em sua estratégia de checkpoint e no planejamento da duração do trabalho. -
Configure o grupo de posicionamento do cluster (recomendado). Especifique o grupo de posicionamento no EC2NodeClass. Karpenter o provisiona automaticamente. Isso é recomendado para uma latência ideal, mas não é estritamente necessário para que o EFA funcione. Para blocos de capacidade para ML, o posicionamento é feito automaticamente via UltraClusters — nenhum grupo de posicionamento manual é necessário. Observe que, nesse caso, o AZ já está bloqueado e, portanto, restrições adicionais Pod-level ou de NodePool-level AZ não são necessárias.
-
Evite a interrupção dos trabalhos de treinamento em vários nós. Use PDBs ou
karpenter.sh/do-not-disrupt: "true"anotações em módulos de treinamento. Sem isso, a consolidação da Karpenter pode tentar substituir ou mover as cargas de trabalho da EFA no meio do trabalho, interrompendo toda a execução do treinamento distribuído. DefinaconsolidationPolicy: WhenEmptyno NodePool para evitar a consolidação dos nós ocupados. Analise a interação entre esses rótulos eterminationGracePeriodeexpireAfteraqui. -
Defina a expiração apropriada. Configure
expireAfterno NodePool para um valor maior do que seu trabalho de treinamento mais longo ou desative-o NodePools totalmente para treinamento. Um nó que expira no meio do treinamento encerra o trabalho. -
Use a versão correta do plug-in do dispositivo EFA. O plug-in do dispositivo EFA é
exibido vpc.amazonaws.com/efacomo um recurso programável. -
Configure grupos de segurança. Todas as instâncias do EFA devem estar no mesmo grupo de segurança com uma regra de autorreferência que permita todo o tráfego em si. to/from Sem isso, o tráfego do EFA falha silenciosamente.
Entenda os riscos da instância Spot com a co-localização do EFA
As instâncias spot do Amazon EC2 oferecem uma economia significativa para cargas de trabalho de treinamento (consulte esta seção para ver as melhores práticas gerais do Spot com GPUs). No entanto, o EFA exige que todos os nós comunicantes residam na mesma zona de disponibilidade, e a AWS recomenda colocá-los em um grupo de posicionamento de cluster para otimizar a latência. Essa co-localização apresenta risco de interrupção correlacionado: as instâncias compartilham a infraestrutura física subjacente dentro da mesma AZ (e ainda mais dentro de um grupo de posicionamento), portanto, um único evento de recuperação de capacidade pode afetar várias instâncias simultaneamente, potencialmente interrompendo todo o trabalho de treinamento em vários nós de uma só vez, em vez de um único nó.
Isso é fundamentalmente diferente do uso do Spot sem restrições de EFA, em que os nós podem ser espalhados por AZs e as interrupções são estatisticamente independentes. Com o requisito Same-AZ da EFA, um evento de capacidade única pode se espalhar em cascata pelo seu cluster de treinamento.
Se você está buscando economia de custos para cargas de trabalho de treinamento de GPU, certifique-se de ter avaliado todas as opções de compra disponíveis antes de se comprometer com o Spot. Instâncias reservadas, reservas de On-Demand capacidade (ODCRs), planos de economia e blocos de capacidade para ML podem oferecer descontos significativos e, ao mesmo tempo, garantir a disponibilidade da capacidade, evitando o risco de interrupção correlacionado inerente ao Spot com as restrições de colocalização da EFA.
Planejando o consumo de endereços IP em grandes instâncias de GPU
Por padrão, o plug-in CNI do Amazon VPC pré-aloca endereços IP para garantir que os pods possam ser programados rapidamente, mantendo uma ENI sobressalente completa anexada e preenchida com IPs. Em instâncias grandes, isso pode resultar na reserva de dezenas de IPs por nó, mesmo quando apenas alguns pods estão em execução.
Essa incompatibilidade é comum em cargas de trabalho de treinamento e inferência em que a densidade de pods por nó é baixa. Em escala de cluster, especialmente durante eventos de escalonamento automático que acionam muitos nós de GPU com poucos pods cada, isso pode levar à exaustão do IP da sub-rede, mesmo que a utilização real do IP seja baixa.
Para atenuar isso, ajuste as WARM_ENI_TARGET variáveis WARM_IP_TARGETMINIMUM_IP_TARGET, e para corresponder à densidade real do seu pod. Mais informações nas configurações de ENI e IP Target da VPC CNI.
Para obter um guia completo sobre como otimizar o consumo de IP, consulte Otimizando a utilização de endereços IP.
