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á.
Melhorias na inicialização da comunicação coletiva
A NCCL e a Gloo são bibliotecas de comunicação fundamentais que permitem operações coletivas (como redução total e transmissão) em processos de treinamento distribuídos. No entanto, a inicialização tradicional do NCCL e do Gloo pode criar gargalos durante a recuperação de falhas.
O processo de recuperação padrão exige que todos os processos se conectem a um processo centralizado TCPStore e coordenado por meio de um processo raiz, introduzindo uma sobrecarga cara que se torna particularmente problemática durante as reinicializações. Esse design centralizado cria três problemas críticos: sobrecarga de coordenação decorrente de TCPStore conexões obrigatórias, atrasos na recuperação, pois cada reinicialização deve repetir a sequência de inicialização completa e um único ponto de falha no próprio processo raiz. Isso impõe etapas de coordenação caras e centralizadas toda vez que o treinamento é inicializado ou reiniciado.
HyperPod o treinamento sem ponto de verificação elimina esses gargalos de coordenação, permitindo uma recuperação mais rápida de falhas, tornando a inicialização “sem raiz” e “.” TCPStoreless
Configurações sem raiz
Para habilitar o Rootless, basta expor as seguintes variáveis de ambiente.
export HPCT_USE_ROOTLESS=1 && \ sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
HPCT_USE_ROOTLESS: 0 ou 1. Use para ligar e desligar sem raiz
sysctl -w net.ipv4.ip_local_port_range="20000 65535": Defina o intervalo de portas do sistema
Veja o exemplo
Sem raízes
HyperPod O treinamento checkpointless oferece novos métodos de inicialização, Rootless e, para grupos de processos NCCL e TCPStoreless Gloo.
A implementação dessas otimizações envolve a modificação de NCCL, Gloo e: PyTorch
Estendendo APIs a biblioteca de terceiros para permitir otimizações NCCL e Gloo sem raiz e sem armazenamento, mantendo a compatibilidade com versões anteriores
Atualização de back-ends de grupos de processos para usar condicionalmente caminhos otimizados e lidar com problemas de recuperação em processo
Ignorando a TCPStore criação cara na camada PyTorch distribuída e mantendo padrões de endereço simétricos por meio de contadores de grupos globais
O gráfico a seguir mostra a arquitetura das bibliotecas de treinamento distribuídas e as mudanças feitas no treinamento sem pontos de verificação.
NCCL e Gloo
Esses são pacotes independentes que executam a funcionalidade principal das comunicações coletivas. Eles fornecem a chave APIs, como ncclCommInit Rank, para inicializar redes de comunicação, gerenciar os recursos subjacentes e realizar comunicações coletivas. Depois de fazer alterações personalizadas no NCCL e no Gloo, o Rootless e o Storeless otimizam (por exemplo, pulam a conexão com a) inicialização da rede de comunicação. TCPStore Você pode alternar entre usar os caminhos de código originais ou os caminhos de código otimizados de forma flexível.
PyTorch backend do grupo de processos
Os back-ends do grupo de processos, especificamente ProcessGroup NCCL e ProcessGroupGloo, implementam o ProcessGroup APIs invocando suas bibliotecas subjacentes APIs correspondentes. Como ampliamos as bibliotecas de terceiros APIs, precisamos invocá-las adequadamente e fazer trocas de caminho de código com base nas configurações dos clientes.
Além dos caminhos do código de otimização, também alteramos o back-end do grupo de processos para oferecer suporte à recuperação em processo.
