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 TCPStore centralizado e se coordenem 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 das conexões TCPStore 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 a recuperação mais rápida de falhas, tornando a inicialização “sem raiz” e “sem TCPStore”.
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 TCPstoreless, para grupos de processos NCCL e Gloo.
A implementação dessas otimizações envolve a modificação de NCCL, Gloo e: PyTorch
Estendendo as APIs de bibliotecas 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 criação cara de TCPStore 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 APIs essenciais, como ncclCommInitRank, 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 and Storeless otimiza (por exemplo, ignora a conexão com o TCPStore) a inicialização da rede de comunicação. 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 as ProcessGroup APIs invocando as APIs de suas bibliotecas subjacentes correspondentes. Como estendemos as APIs das bibliotecas de terceiros, 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.
