Pytorch Fsdp

Pytorch-Fsdp Skill

Assistência abrangente para desenvolvimento com pytorch-fsdp, gerada a partir da documentação oficial.

Quando Usar Esta Skill

Esta skill deve ser acionada quando:

• Trabalhando com pytorch-fsdp
• Perguntando sobre features ou APIs do pytorch-fsdp
• Implementando soluções pytorch-fsdp
• Debugando código pytorch-fsdp
• Aprendendo best practices do pytorch-fsdp

Referência Rápida

Padrões Comuns

Padrão 1: Gerenciador de Contexto Join Genérico# Criado em: 06 de junho de 2025 | Última atualização: 06 de junho de 2025 O gerenciador de contexto join genérico facilita o treinamento distribuído em inputs desiguais. Esta página descreve a API das classes relevantes: Join, Joinable e JoinHook. Para um tutorial, consulte Distributed Training with Uneven Inputs Using the Join Context Manager. class torch.distributed.algorithms.Join(joinables, enable=True, throw_on_early_termination=False, **kwargs)[source]# Esta classe define o gerenciador de contexto join genérico, que permite que hooks customizados sejam chamados depois que um processo se junta. Esses hooks devem sombrear as comunicações coletivas de processos não unidos para evitar travamentos, erros e garantir correção algorítmica. Consulte JoinHook para detalhes sobre a definição do hook. Aviso O gerenciador de contexto requer que cada Joinable participante chame o método notify_join_context() antes de suas próprias comunicações coletivas por iteração para garantir correção. Aviso O gerenciador de contexto requer que todos os atributos process_group nos objetos JoinHook sejam os mesmos. Se houver múltiplos objetos JoinHook, o dispositivo do primeiro é usado. As informações do grupo de processos e do dispositivo são usadas para verificar processos não unidos e para notificar processos a lançar uma exceção se throw_on_early_termination estiver habilitado, ambos usando um all-reduce. Parâmetros joinables (List[Joinable]) – uma lista dos Joinables participantes; seus hooks são iterados na ordem fornecida. enable (bool) – um flag habilitando detecção de inputs desiguais; definir como False desabilita a funcionalidade do gerenciador de contexto e deve ser definido apenas quando o usuário souber que os inputs não serão desiguais (padrão: True). throw_on_early_termination (bool) – um flag controlando se uma exceção deve ser lançada ao detectar inputs desiguais (padrão: False). Exemplo: >>> import os >>> import torch >>> import torch.distributed as dist >>> import torch.multiprocessing as mp >>> import torch.nn.parallel.DistributedDataParallel as DDP >>> import torch.distributed.optim.ZeroRedundancyOptimizer as ZeRO >>> from torch.distributed.algorithms.join import Join >>> >>> # Em cada worker spawn >>> def worker(rank): >>> dist.init_process_group("nccl", rank=rank, world_size=2) >>> model = DDP(torch.nn.Linear(1, 1).to(rank), device_ids=[rank]) >>> optim = ZeRO(model.parameters(), torch.optim.Adam, lr=0.01) >>> # Rank 1 recebe um input a mais que rank 0 >>> inputs = [torch.tensor([1.]).to(rank) for _ in range(10 + rank)] >>> with Join([model, optim]): >>> for input in inputs: >>> loss = model(input).sum() >>> loss.backward() >>> optim.step() >>> # Todos os ranks chegam aqui sem travamentos/erros static notify_join_context(joinable)[source]# Notifica o gerenciador de contexto join que o processo chamador ainda não se juntou. Depois, se throw_on_early_termination=True, verifica se inputs desiguais foram detectados (ou seja, se um processo já se juntou) e lança uma exceção se assim for. Este método deve ser chamado de um objeto Joinable antes de suas comunicações coletivas por iteração. Por exemplo, isto deve ser chamado no início do forward pass em DistributedDataParallel. Apenas o primeiro objeto Joinable passado ao gerenciador de contexto realiza as comunicações coletivas neste método, e para os outros, este método é vácuo. Parâmetros joinable (Joinable) – o objeto Joinable chamando este método. Retorna Um handle de work async para o all-reduce destinado a notificar o gerenciador de contexto que o processo ainda não se juntou se joinable for o primeiro passado ao gerenciador de contexto; None caso contrário. class torch.distributed.algorithms.Joinable[source]# Isto define uma classe base abstrata para classes joinable. Uma classe joinable (herdando de Joinable) deve implementar join_hook(), que retorna uma instância JoinHook, além de join_device() e join_process_group() que retornam informações de dispositivo e grupo de processos, respectivamente. abstract property join_device: device# Retorna o dispositivo do qual realizar comunicações coletivas necessárias pelo gerenciador de contexto join. abstract join_hook(**kwargs)[source]# Retorna uma instância JoinHook para o Joinable dado. Parâmetros kwargs (dict) – um dicionário contendo quaisquer argumentos nomeados para modificar o comportamento do join hook em tempo de execução; todas as instâncias Joinable compartilhando o mesmo gerenciador de contexto join são encaminhadas com o mesmo valor para kwargs. Tipo de retorno JoinHook abstract property join_process_group: Any# Retorna o grupo de processos para as comunicações coletivas necessárias pelo próprio gerenciador de contexto join. class torch.distributed.algorithms.JoinHook[source]# Isto define um join hook, que fornece dois pontos de entrada no gerenciador de contexto join. Pontos de entrada: um hook principal, que é chamado repetidamente enquanto existe um processo não unido, e um pos-hook, que é chamado uma vez que todos os processos se juntaram. Para implementar um join hook para o gerenciador de contexto join genérico, defina uma classe que herda de JoinHook e sobrescreva main_hook() e post_hook() conforme apropriado. main_hook()[source]# Chame este hook enquanto existe um processo não unido para sombrear comunicações coletivas em uma iteração de treinamento. Iteração de treinamento, ou seja, em um forward pass, backward pass e otimizador step. post_hook(is_last_joiner)[source]# Chame hook depois que todos os processos se juntaram. É passado um argumento bool adicional is_last_joiner, que indica se o rank é um dos últimos a se juntar. Parâmetros is_last_joiner (bool) – True se o rank é um dos últimos a se juntar; False caso contrário.

Join

Padrão 2: Pacote de comunicação distribuída - torch.distributed# Criado em: 12 de julho de 2017 | Última atualização: 04 de setembro de 2025 Nota Por favor, consulte PyTorch Distributed Overview para uma breve introdução a todos os recursos relacionados ao treinamento distribuído. Backends# torch.distributed suporta quatro backends built-in, cada um com diferentes capacidades. A tabela abaixo mostra quais funções estão disponíveis para uso com CPU ou GPU para cada backend. Para NCCL, GPU refere-se a CUDA GPU enquanto para XCCL refere-se a XPU GPU. MPI suporta CUDA apenas se a implementação usada para compilar PyTorch suporta. Backend gloo mpi nccl xccl Device CPU GPU CPU GPU CPU GPU CPU GPU send ✓ ✘ ✓ ? ✘ ✓ ✘ ✓ recv ✓ ✘ ✓ ? ✘ ✓ ✘ ✓ broadcast ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ all_reduce ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ reduce ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ all_gather ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ gather ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ scatter ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ reduce_scatter ✓ ✓ ✘ ✘ ✘ ✓ ✘ ✓ all_to_all ✓ ✓ ✓ ? ✘ ✓ ✘ ✓ barrier ✓ ✘ ✓ ? ✘ ✓ ✘ ✓ Backends que vêm com PyTorch# O pacote torch.distributed suporta Linux (estável), MacOS (estável) e Windows (protótipo). Por padrão, para Linux, os backends Gloo e NCCL são construídos e incluídos no torch.distributed (NCCL apenas ao compilar com CUDA). MPI é um backend opcional que pode ser incluído apenas se você construir PyTorch a partir do código-fonte. (por exemplo, construindo PyTorch em um host que tem MPI instalado.) Nota A partir do PyTorch v1.8, Windows suporta todas as comunicações coletivas backend exceto NCCL. Se o argumento init_method de init_process_group() aponta para um arquivo, ele deve estar de acordo com o seguinte schema: Sistema de arquivos local, init_method="file:///d:/tmp/some_file" Sistema de arquivos compartilhado, init_method="file://////{machine_name}/{share_folder_name}/some_file" Igual a na plataforma Linux, você pode ativar TcpStore configurando variáveis de ambiente MASTER_ADDR e MASTER_PORT. Qual backend usar?# No passado, frequentemente nos perguntavam: "qual backend devo usar?". Regra de bolso Use o backend NCCL para treinamento distribuído com CUDA GPU. Use o backend XCCL para treinamento distribuído com XPU GPU. Use o backend Gloo para treinamento distribuído com CPU. Hosts GPU com interconexão InfiniBand Use NCCL, pois é o único backend que atualmente suporta InfiniBand e GPUDirect. Hosts GPU com interconexão Ethernet Use NCCL, pois atualmente fornece o melhor desempenho de treinamento distribuído em GPU, especialmente para treinamento multi-processo single-node ou multi-node. Se encontrar qualquer problema com NCCL, use Gloo como opção de fallback. (Nota que Gloo atualmente roda mais lentamente que NCCL para GPUs.) Hosts CPU com interconexão InfiniBand Se seu InfiniBand tiver ativado IP over IB, use Gloo, caso contrário, use MPI. Estamos planejando adicionar suporte a InfiniBand para Gloo nos próximos lançamentos. Hosts CPU com interconexão Ethernet Use Gloo, a menos que você tenha razões específicas para usar MPI. Variáveis de ambiente comuns# Escolhendo a interface de rede a usar# Por padrão, tanto os backends NCCL quanto Gloo tentarão encontrar a interface de rede correta a usar. Se a interface detectada automaticamente não estiver correta, você pode sobrescrevê-la usando as seguintes variáveis de ambiente (aplicáveis ao backend respectivo): NCCL_SOCKET_IFNAME, por exemplo export NCCL_SOCKET_IFNAME=eth0 GLOO_SOCKET_IFNAME, por exemplo export GLOO_SOCKET_IFNAME=eth0 Se estiver usando o backend Gloo, você pode especificar múltiplas interfaces separando-as por vírgula, assim: export GLOO_SOCKET_IFNAME=eth0,eth1,eth2,eth3. O backend enviará operações em modo round-robin através dessas interfaces. É imperativo que todos os processos especifiquem o mesmo número de interfaces nesta variável. Outras variáveis de ambiente NCCL# Debug - em caso de falha NCCL, você pode definir NCCL_DEBUG=INFO para imprimir um aviso explícito bem como informações básicas de inicialização NCCL. Você também pode usar NCCL_DEBUG_SUBSYS para obter mais detalhes sobre um aspecto específico de NCCL. Por exemplo, NCCL_DEBUG_SUBSYS=COLL imprimiria logs de chamadas coletivas, o que pode ser útil ao debugar travamentos, especialmente aqueles causados por tipo de coletiva ou desajuste de tamanho de mensagem. Em caso de falha na detecção de topologia, seria útil definir NCCL_DEBUG_SUBSYS=GRAPH para inspecionar o resultado detalhado da detecção e salvar como referência se ajuda adicional da equipe NCCL for necessária. Ajuste de desempenho - NCCL realiza ajuste automático baseado em sua detecção de topologia para economizar esforço de ajuste dos usuários. Em alguns sistemas baseados em socket, você ainda pode tentar afinar NCCL_SOCKET_NTHREADS e NCCL_NSOCKS_PERTHREAD para aumentar a largura de banda da rede de socket. Essas duas variáveis de ambiente foram pré-ajustadas por NCCL para alguns provedores de cloud, como AWS ou GCP. Para uma lista completa de variáveis de ambiente NCCL, consulte a documentação oficial do NVIDIA NCCL Você pode afinar ainda mais comunicadores NCCL usando torch.distributed.ProcessGroupNCCL.NCCLConfig e torch.distributed.ProcessGroupNCCL.Options. Aprenda mais sobre eles usando help (ex: help(torch.distributed.ProcessGroupNCCL.NCCLConfig)) no interpretador. Básico# O pacote torch.distributed fornece suporte PyTorch e primitivas de comunicação para paralelismo multiprocesso em vários nós de computação executando em uma ou mais máquinas. A classe torch.nn.parallel.DistributedDataParallel() constrói sobre esta funcionalidade para fornecer treinamento distribuído síncrono como um wrapper em torno de qualquer modelo PyTorch. Isto difere dos tipos de paralelismo fornecidos pelo pacote Multiprocessing - torch.multiprocessing e torch.nn.DataParallel() em que suporta múltiplas máquinas conectadas por rede e em que o usuário deve explicitamente lançar uma cópia separada do script de treinamento principal para cada processo. No caso síncrono single-machine, torch.distributed ou o wrapper torch.nn.parallel.DistributedDataParallel() ainda pode ter vantagens sobre outras abordagens para data-paralelismo, incluindo torch.nn.DataParallel(): Cada processo mantém seu próprio otimizador e realiza um passo de otimização completo a cada iteração. Embora isto possa parecer redundante, visto que os gradientes já foram reunidos e promediados entre processos e assim são idênticos para cada processo, isto significa que nenhum passo de broadcast de parâmetro é necessário, reduzindo o tempo gasto transferindo tensores entre nós. Cada processo contém um interpretador Python independente, eliminando a sobrecarga extra do interpretador e "GIL-thrashing" que vem de dirigir vários threads de execução, réplicas de modelo ou GPUs de um único processo Python. Isto é especialmente importante para modelos que fazem uso pesado do runtime Python, incluindo modelos com camadas recorrentes ou muitos componentes pequenos. Inicialização# O pacote precisa ser inicializado usando a função torch.distributed.init_process_group() ou torch.distributed.device_mesh.init_device_mesh() antes de chamar qualquer outro método. Ambas bloqueiam até que todos os processos se juntarem. Aviso Inicialização não é thread-safe. Criação de grupo de processos deve ser realizada em uma única thread para prevenir atribuição inconsistente de 'UUID' entre ranks, e para prevenir race conditions durante a inicialização que podem levar a travamentos. torch.distributed.is_available()[source]# Retorna True se o pacote distribuído está disponível. Caso contrário, torch.distributed não expõe nenhuma outra API. Atualmente, torch.distributed está disponível em Linux, MacOS e Windows. Defina USE_DISTRIBUTED=1 ao compilar PyTorch a partir do código-fonte. Atualmente, o valor padrão é USE_DISTRIBUTED=1 para Linux e Windows, USE_DISTRIBUTED=0 para MacOS. Tipo de retorno bool torch.distributed.init_process_group(backend=None, init_method=None, timeout=None, world_size=-1, rank=-1, store=None, group_name='', pg_options=None, device_id=None)[source]# Inicializa o grupo de processos distribuído padrão. Isto também inicializará o pacote distribuído. Existem 2 formas principais de inicializar um grupo de processos: Especificar store, rank e world_size explicitamente. Especificar init_method (uma string de URL) que indica onde/como descobrir peers. Opcionalmente especificar rank e world_size, ou codificar todos os parâmetros necessários na URL e omiti-los. Se nenhum for especificado, init_method é considerado "env://". Parâmetros backend (str ou Backend, opcional) – O backend a usar. Dependendo das configurações de tempo de compilação, valores válidos incluem mpi, gloo, nccl, ucc, xccl ou um registrado por um plugin de terceiros. Desde 2.6, se backend não for fornecido, c10d usará um backend registrado para o tipo de dispositivo indicado pelo argumento device_id (se fornecido). As registrações padrão conhecidas hoje são: nccl para cuda, gloo para cpu, xccl para xpu. Se nem backend nem device_id forem fornecidos, c10d detectará o acelerador na máquina em tempo de execução e usará um backend registrado para esse acelerador detectado (ou cpu). Este campo pode ser dado como uma string minúscula (ex, "gloo"), que também pode ser acessado via atributos Backend (ex, Backend.GLOO). Se usar múltiplos processos por máquina com backend nccl, cada processo deve ter acesso exclusivo a cada GPU que usa, pois compartilhar GPUs entre processos pode resultar em deadlock ou uso inválido de NCCL. Backend ucc é experimental. Backend padrão para o dispositivo pode ser consultado com get_default_backend_for_device(). init_method (str, opcional) – URL especificando como inicializar o grupo de processos. O padrão é "env://" se nenhum init_method ou store for especificado. Mutuamente exclusivo com store. world_size (int, opcional) – Número de processos participando do job. Necessário se store for especificado. rank (int, opcional) – Rank do processo atual (deve ser um número entre 0 e world_size-1). Necessário se store for especificado. store (Store, opcional) – Armazenamento chave/valor acessível a todos os workers, usado para trocar informações de conexão/endereço. Mutuamente exclusivo com init_method. timeout (timedelta, opcional) – Timeout para operações executadas contra o grupo de processos. Valor padrão é 10 minutos para NCCL e 30 minutos para outros backends. Esta é a duração após a qual coletivas serão abortadas assincronamente e o processo falhará. Isto é feito porque execução CUDA é assíncrona e já não é seguro continuar executando código de usuário visto que operações NCCL assíncronas falhadas podem resultar em operações CUDA subsequentes rodando em dados corrompidos. Quando TORCH_NCCL_BLOCKING_WAIT é configurado, o processo bloqueará e aguardará este timeout. group_name (str, opcional, descontinuado) – Nome do grupo. Este argumento é ignorado pg_options (ProcessGroupOptions, opcional) – opções de grupo de processos especificando quais opções adicionais precisam ser passadas durante a construção de grupos de processos específicos. Até agora, a única opção que suportamos é ProcessGroupNCCL.Options para o backend nccl, is_high_priority_stream pode ser especificado para que o backend nccl possa capturar streams cuda de alta prioridade quando há kernels de computação aguardando. Para outras opções disponíveis para configurar nccl, veja https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/api/types.html#ncclconfig-t device_id (torch.device | int, opcional) – um dispositivo único e específico no qual este processo trabalhará, permitindo otimizações específicas do backend. Atualmente isto tem dois efeitos, apenas sob NCCL: o comunicador é formado imediatamente (chamando ncclCommInit* imediatamente ao invés da chamada lazy normal) e sub-grupos usarão ncclCommSplit quando possível para evitar overhead desnecessário de criação de grupo. Se deseja conhecer o erro de inicialização NCCL logo, você também pode usar este campo. Se um int for fornecido, a API assume que o tipo de acelerador em tempo de compilação será usado. Nota Para habilitar backend == Backend.MPI, PyTorch precisa ser construído a partir do código-fonte em um sistema que suporta MPI. Nota Suporte para múltiplos backends é experimental. Atualmente quando nenhum backend é especificado, ambos os backends gloo e nccl serão criados. O backend gloo será usado para coletivas com tensores CPU e o backend nccl será usado para coletivas com tensores CUDA. Um backend customizado pode ser especificado passando uma string com formato ":,:", ex "cpu:gloo,cuda:custom_backend". torch.distributed.device_mesh.init_device_mesh(device_type, mesh_shape, *, mesh_dim_names=None, backend_override=None)[source]# Inicializa um DeviceMesh baseado em parâmetros device_type, mesh_shape e mesh_dim_names. Isto cria um DeviceMesh com layout de array n-dimensional, onde n é o comprimento de mesh_shape. Se mesh_dim_names for fornecido, cada dimensão é rotulada como mesh_dim_names[i]. Nota init_device_mesh segue modelo de programação SPMD, significando que o mesmo programa Python PyTorch roda em todos os processos/ranks no cluster. Garanta que mesh_shape (as dimensões do array nD descrevendo layout de dispositivo) seja idêntico entre todos os ranks. mesh_shape inconsistente pode levar a travamento. Nota Se nenhum grupo de processos for encontrado, init_device_mesh inicializará grupo(s) de processos distribuído necessário(s) para comunicações distribuídas nos bastidores. Parâmetros device_type (str) – O tipo de dispositivo do mesh. Atualmente suporta: "cpu", "cuda/cuda-like", "xpu". Passar em um tipo de dispositivo com índice de GPU, como "cuda:0", não é permitido. mesh_shape (Tuple[int]) – Uma tupla definindo as dimensões do array multi-dimensional descrevendo o layout de dispositivos. mesh_dim_names (Tuple[str], opcional) – Uma tupla de nomes de dimensão de mesh a atribuir a cada dimensão do array multi-dimensional descrevendo o layout de dispositivos. Seu comprimento deve corresponder ao comprimento de mesh_shape. Cada string em mesh_dim_names deve ser única. backend_override (Dict[int | str, tuple[str, Options] | str | Options], opcional) – Sobrescritas para alguns ou todos os ProcessGroups que serão criados para cada dimensão de mesh. Cada chave pode ser tanto o índice de uma dimensão quanto seu nome (se mesh_dim_names for fornecido). Cada valor pode ser uma tupla contendo o nome do backend e suas opções, ou apenas um destes dois componentes (nesse caso o outro será definido para seu valor padrão). Retorna Um objeto DeviceMesh representando o layout de dispositivo. Tipo de retorno DeviceMesh Exemplo: >>> from torch.distributed.device_mesh import init_device_mesh >>> >>> mesh_1d = init_device_mesh("cuda", mesh_shape=(8,)) >>> mesh_2d = init_device_mesh("cuda", mesh_shape=(2, 8), mesh_dim_names=("dp", "tp")) torch.distributed.is_initialized()[source]# Verifica se o grupo de processos distribuído padrão foi inicializado. Tipo de retorno bool torch.distributed.is_mpi_available()[source]# Verifica se o backend MPI está disponível. Tipo de retorno bool torch.distributed.is_nccl_available()[source]# Verifica se o backend NCCL está disponível. Tipo de retorno bool torch.distributed.is_gloo_available()[source]# Verifica se o backend Gloo está disponível. Tipo de retorno bool torch.distributed.distributed_c10d.is_xccl_available()[source]# Verifica se o backend XCCL está disponível. Tipo de retorno bool torch.distributed.is_torchelastic_launched()[source]# Verifica se este processo foi lançado com torch.distributed.elastic (conhecido como torchelastic). A existência da variável de ambiente TORCHELASTIC_RUN_ID é usada como proxy para determinar se o processo atual foi lançado com torchelastic. Isto é um proxy razoável visto que TORCHELASTIC_RUN_ID mapeia para a id de rendezvous que é sempre um valor não-nulo indicando a id do job para fins de descoberta de peers. Tipo de retorno bool torch.distributed.get_default_backend_for_device(device)[source]# Retorna o backend padrão para o dispositivo dado. Parâmetros device (Union[str, torch.device]) – O dispositivo para obter o backend padrão. Retorna O backend padrão para o dispositivo dado como uma string minúscula. Tipo de retorno str Atualmente três métodos de inicialização são suportados: Inicialização TCP# Existem duas formas de inicializar usando TCP, ambas necessitando de um endereço de rede alcançável de todos os processos e um world_size desejado. A primeira forma requer especificar um endereço que pertence ao processo com rank 0. Este método de inicialização requer que todos os processos tenham ranks manualmente especificados. Nota que endereço multicast não é mais suportado no pacote distribuído mais recente. group_name também é descontinuado. import torch.distributed as dist # Use endereço de uma das máquinas dist.init_process_group(backend, init_method='tcp://10.1.1.20:23456', rank=args.rank, world_size=4) Inicialização com sistema de arquivos compartilhado# Outro método de inicialização faz uso de um sistema de arquivos que é compartilhado e visível de todas as máquinas em um grupo, juntamente com um world_size desejado. A URL deve começar com file:// e conter um caminho para um arquivo inexistente (em um diretório existente) em um sistema de arquivos compartilhado. Inicialização com sistema de arquivos criará automaticamente esse arquivo se não existir, mas não o deletará. Portanto, é sua responsabilidade garantir que o arquivo seja limpo antes da próxima chamada de init_process_group() no mesmo caminho/nome de arquivo. Nota que atribuição automática de rank não é mais suportada no pacote distribuído mais recente e group_name também é descontinuado. Aviso Este método assume que o sistema de arquivos suporta locking usando fcntl - a maioria dos sistemas locais e NFS suportam. Aviso Este método sempre criará o arquivo e fará o seu melhor para limpar e remover o arquivo no final do programa. Em outras palavras, cada inicialização com o método init de arquivo precisará de um arquivo vazio novo e completo para que a inicialização tenha sucesso. Se o mesmo arquivo usado pela inicialização anterior (que acontece de não ter sido limpo) for usado novamente, isto é comportamento inesperado e frequentemente pode causar deadlocks e falhas. Portanto, embora este método faça o seu melhor para limpar o arquivo, se a auto-deleção acontecer de ser malsucedida, é sua responsabilidade garantir que o arquivo seja removido no final do treinamento para prevenir que o mesmo arquivo seja reutilizado novamente na próxima vez. Isto é especialmente importante se você planeja chamar init_process_group() múltiplas vezes no mesmo nome de arquivo. Em outras palavras, se o arquivo não for removido/limpo e você chamar init_process_group() novamente naquele arquivo, falhas são esperadas. A regra de bolso é: garanta que o arquivo seja inexistente ou vazio toda vez que init_process_group() for chamado. import torch.distributed as dist # rank deve sempre ser especificado dist.init_process_group(backend, init_method='file:///mnt/nfs/sharedfile', world_size=4, rank=args.rank) Inicialização por variável de ambiente# Este método lerá a configuração de variáveis de ambiente, permitindo que você customize completamente como a informação é obtida. As variáveis a serem definidas são: MASTER_PORT - obrigatório; deve ser uma porta livre na máquina com rank 0 MASTER_ADDR - obrigatório (exceto para rank 0); endereço do nó rank 0 WORLD_SIZE - obrigatório; pode ser definido aqui ou em uma chamada à função de inicialização RANK - obrigatório; pode ser definido aqui ou em uma chamada à função de inicialização A máquina com rank 0 será usada para configurar todas as conexões. Este é o método padrão, significando que init_method não precisa ser especificado (ou pode ser env://). Melhorando tempo de inicialização# TORCH_GLOO_LAZY_INIT - estabelece conexões sob demanda ao invés de usar uma malha completa o que pode grandemente melhorar tempo de inicialização para operações não all2all. Pós-Inicialização# Uma vez que torch.distributed.init_process_group() foi executado, as seguintes funções podem ser usadas. Para verificar se o grupo de processos já foi inicializado use torch.distributed.is