Criar perfis de ambientes Multislice

Os ambientes Multislice do Cloud TPU são compostos por várias frações de pod de TPU que se comunicam pela rede do data center (DCN, na sigla em inglês). Você pode usar a ferramenta de estatísticas coletivas do DCN para conferir informações sobre a eficiência com que seu ambiente de várias fatias está usando a rede DCN. Especificamente, a ferramenta Estatísticas coletivas do DCN permite:

  • Analisar e entender a performance da rede entre fatias com base nos dados coletados
  • Identificar gargalos de desempenho
  • Otimizar a performance do modelo

Todas as métricas na ferramenta de estatísticas coletivas do DCN são geradas por TPU.

Terminologia

A ferramenta de estatísticas coletivas da DCN mostra métricas que descrevem a comunicação que ocorre entre frações de TPU em um ambiente Multislice. Quando o ambiente de execução da TPU inicia a comunicação entre fatias, uma série de operações é usada:

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
Informa 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
Informa ao host que os dados foram recebidos.

Um coletivo é iniciado quando uma operação send ocorre e é concluído quando a operação recv-done correspondente ocorre.

Tempo de inatividade

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

Chip do pod v5e

O tempo de folga é calculado neste exemplo como:

Tempo de folga = t1 + t2 + t3

Aumentar o tempo de inatividade reduz as chances de interromper a TPU para um coletivo. É possível aumentar o tempo de folga escolhendo um método de fragmentação diferente.

Duração da interrupção

A duração média do tempo que o coletivo gasta nas operações de envio, envio concluído, recebimento e recebimento concluído. Isso não inclui o tempo gasto na transmissão de dados. Por exemplo, considerando a seguinte linha do tempo:

Chip do pod v5e

A duração da parada é calculada neste exemplo como:

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

Duração observada

O tempo entre as operações send e recv-done, incluindo o tempo de envio e recebimento de dados. Por exemplo, considerando o seguinte cronograma:

Chip do pod 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 coleção é iniciada e concluída durante a duração de um perfil. Um coletivo é iniciado quando uma operação send ocorre e é concluído quando a operação recv-end correspondente ocorre. A operação send e a operação recv-done correspondente precisam ocorrer em uma duração de perfil para serem incluídas nessa métrica.

Parada total agregada

O tempo total em que um coletivo interrompe uma TPU durante a duração de um perfil. A parada total de agregação é calculada da seguinte forma:

Total de paradas agregadas = duração da parada * ocorrências

Tamanho dos dados transmitidos

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

Largura de banda necessária

A largura de banda necessária para transmitir dados dentro do slack fornecido. É possível usar essa métrica para conferir o número de coletivos 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 folga

Status da ferramenta

A tabela a seguir mostra a versão do TensorFlow ou do runtime do TPU necessária para cada métrica exibida na ferramenta Estatísticas coletivas do DCN.

Estatísticas coletivas do DCN Versão do ambiente de execução do TensorFlow com suporte para TPU
Tempo de folga TensorFlow 2.15.0, tensorboard 2.15.1 e tensorboard-plugin-profile 2.15.0
Duração da interrupçã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
Parada total agregada 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 do DCN

  1. Execute o servidor do TensorBoard e acesse a guia Perfil.
  2. Classifique a tabela na ferramenta de estatísticas coletivas do DCN por Aggregated Total Stall em ordem decrescente.
  3. Identifique o nome coletivo do DCN com o maior Aggregated Total Stall. Se a duração de paralisação agregada desse coletivo for significativamente alta em comparação com outros, isso poderá indicar que há um gargalo no coletivo de DCN.
  4. Multiplique a largura de banda necessária do coletivo de DCN pelo número de núcleos. Há oito núcleos por host do TPU v4. Portanto, a largura de banda necessária para um coletivo é 8 x o valor mostrado. Se a largura de banda necessária for maior que a largura de banda máxima da rede do TPU, isso pode significar que a rede está congestionada. Para reduzir a largura de banda necessária, tente mudar o mecanismo de fragmentação que você usa. Para mais informações sobre mecanismos de fragmentação, consulte Visão geral do Cloud TPU Multislice.
  5. Gere um despejo de HLO para determinar se há algum problema com o compilador. É melhor distribuir as operações send e recv-done para que um coletivo permita a programação de mais operações HLO sobrepostas. A sobreposição de mais operações de HLO reduz o tempo de interrupção da TPU.
  6. Verifique a duração das operações recv-done no Visualizador de rastros do coletivo DCN que tem a parada total agregada máxima. Se a duração da transferência for alta, poderá 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 de recv-done não for muito alta em comparação com o tempo de inatividade, isso poderá indicar um problema de hardware.