Criação de perfis de ambientes com várias frações

As frações nos ambientes de várias frações do Cloud TPU se comunicam pela rede do data center (DCN). Use a ferramenta Megascale Stats no XProf para conferir informações sobre a eficiência de uso da rede DCN pelo ambiente de várias frações. Especificamente, a ferramenta Megascale Stats permite o seguinte:

  • Conferir e entender o desempenho da rede entre frações com base nos dados coletados.
  • Identificar gargalos de desempenho.
  • Otimizar o desempenho do modelo.

Todas as métricas na ferramenta Megascale Stats são geradas por TPU. Para ativar essa ferramenta, siga as mesmas etapas aplicáveis para capturar o perfil no framework e use a biblioteca XProfiler para configurar uma instância do XProf no TensorBoard a fim de conferir seus perfis. Se a carga de trabalho tiver sido executada como sendo de várias frações, o TensorBoard vai mostrar a ferramenta Megascale Stats para ela.

Para mais detalhes sobre a ferramenta Megascale Stats no XProf, consulte o guia Ferramenta Megascale Stats.

Terminologia

A ferramenta de estatísticas coletivas da DCN mostra métricas que descrevem a comunicação entre frações de TPU em um ambiente de várias frações. Quando o ambiente de execução da TPU inicia a comunicação entre frações, diversas operações são usadas:

  • send: interrompe o host para iniciar o acesso direto à memória (DMA) e fornece um buffer preenchido ao host para iniciar a transferência de dados.
  • send-done: sinaliza ao host que a transferência de dados foi concluída.
  • recv: fornece um buffer vazio para o host preencher com os dados transferidos.
  • recv-done: sinaliza ao host que os dados foram recebidos.

Uma operação de comunicação coletiva é iniciada quando uma operação send ocorre e é concluída após a operação recv-done correspondente.

Período de tolerância

Uma medida do tempo em que operação de comunicação coletiva consegue enviar e receber dados. Isso não inclui as operações send, send-done, recv ou recv-done. Por exemplo, considere a seguinte linha do tempo:

Chip do pod da v5e

Neste exemplo, o período de tolerância é calculado da seguinte forma:

Período de tolerância = t1 + t2 + t3

Aumentar o período de tolerância reduz as chances de paralisação da TPU em uma operação de comunicação coletiva. É possível aumentar o período de tolerância escolhendo outro método de fragmentação.

Duração da paralisação

A duração média do tempo que a operação de comunicação coletiva gasta nestas operações: send, send-done, recv e recv-done. Isso não inclui o tempo gasto na transmissão de dados. Por exemplo, considere a seguinte linha do tempo:

Chip do pod da v5e

Neste exemplo, a duração da paralisação é calculada como:

Duração da paralisação = tsend + tsend-done + trecv + trecv-done

Duração observada

A quantidade de tempo entre as operações send e recv-done, incluindo o tempo de envio e recebimento de dados. Por exemplo, considere a seguinte linha do tempo:

Chip do pod da v5e

A duração observada é calculada da seguinte forma:

Duração observada = tsend + t1 + tsend-done + t2 + trecv + t3 + trecv-done

Ocorrências

O número de vezes que uma operação de comunicação coletiva é iniciada e concluída durante a duração de um perfil. Uma operação de comunicação coletiva é iniciada quando uma operação send ocorre e é concluída após a operação recv-end correspondente. A operação send e a operação recv-done correspondente precisam ocorrer dentro da duração de um perfil para serem incluídas nessa métrica.

Tempo total agregado de paralisação

O tempo total de paralisação de uma TPU pela operação de comunicação coletiva durante a duração de um perfil. O total agregado de paralisação é calculado da seguinte forma:

Total agregado de paralisação = duração da paralisação * ocorrências

Tamanho dos dados transmitidos

A quantidade de dados transmitidos pela rede para a operação de comunicação coletiva durante a duração do perfil.

Largura de banda necessária

A largura de banda necessária para transmitir dados no período de tolerância fornecido. Use essa métrica para conferir o número de operações de comunicação coletiva que disputam a largura de banda da rede durante a duração do perfil. A largura de banda necessária é calculada da seguinte forma:

Largura de banda necessária = tamanho dos dados transmitidos/tempo de tolerância

Status da ferramenta

A tabela a seguir mostra a versão do TensorFlow ou do ambiente de execução de TPU necessária para cada métrica exibida na ferramenta de estatísticas coletivas da DCN.

Estatísticas coletivas da DCN Versão aceita do TensorFlow ou do ambiente de execução de TPU
Período de tolerância TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Duração da paralisação TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Duração observada TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Ocorrências TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Tempo total agregado de paralisação tf-nightly, tb-nightly, tbp-nightly
Tamanho dos dados transmitidos tf-nightly, tb-nightly, tbp-nightly
Largura de banda necessária tf-nightly, tb-nightly, tbp-nightly

Como analisar a ferramenta de estatísticas coletivas da DCN

  1. Execute o servidor do TensorBoard e acesse a guia Perfil.

  2. Classifique a tabela na ferramenta de estatísticas coletivas da DCN por Total agregado de paralisação em ordem decrescente.

  3. Identifique o nome da operação de comunicação coletiva da DCN com o maior Total agregado de paralisação. Se a duração agregada da paralisação dessa operação de comunicação coletiva é significativamente alta em comparação com outras operações, isso pode indicar um gargalo na operação de comunicação coletiva da DCN.

  4. Multiplique a largura de banda necessária da operação de comunicação coletiva da DCN pelo número de núcleos. Há oito núcleos por host de TPU v4. Portanto, a largura de banda necessária para uma operação de comunicação coletiva é oito vezes o valor mostrado. Se a largura de banda necessária é maior que a largura de banda máxima da rede da TPU, isso pode significar que a rede está congestionada. Para reduzir a largura de banda necessária, tente mudar o mecanismo de fragmentação usado. Para mais informações sobre mecanismos de fragmentação, consulte Visão geral das várias frações do Cloud TPU .

  5. Gere um despejo de HLO para determinar se há problemas no compilador. É melhor distribuir as operações send e recv-done para uma operação de comunicação coletiva e permitir a programação de mais operações HLO sobrepostas. A sobreposição de mais operações HLO reduz o tempo de paralisação da TPU.

  6. Verifique a duração das operações recv-done no visualizador de traces para a operação de comunicação coletiva da DCN que tem o total agregado máximo de paralisação. Se a duração da transferência é alta, pode haver um gargalo de largura de banda, porque as operações recv-done geralmente são bloqueadas na rede para receber os dados.

  7. Se a duração das operações recv-done não é muito alta em comparação com o período de tolerância, isso pode indicar um problema de hardware.