Neste documento, explicamos como usar os painéis do Cloud Monitoring para monitorar instâncias A4X Max, A4X, A4, A3 Ultra e A3 Mega criadas com capacidade vinculada à reserva. Usar esses painéis ajuda a identificar e resolver problemas de gargalos de desempenho nas suas instâncias autônomas do Compute Engine ou clusters do Slurm, minimizando a inatividade nas suas cargas de trabalho.
Ao criar painéis personalizados ou usar painéis predefinidos do Monitoring, é possível monitorar o seguinte:
Integridade da instância de computação
Performance da GPU
Eficiência da transmissão de rede
Eficiência da rede entre blocos e sub-blocos
Eficiência da carga de trabalho de machine learning (ML)
Detecção de tarefas retardatárias
Detecção de carga de trabalho sem resposta
Para monitorar clusters do Cluster Director, consulte Monitorar a performance do cluster com painéis pré-criados.
Antes de começar
Antes de monitorar sua carga de trabalho, conclua as etapas a seguir, se ainda não tiver feito isso:
Implante uma carga de trabalho que possa ser monitorada. Para saber quais cargas de trabalho são compatíveis, consulte as limitações neste documento. Para saber como implantar uma carga de trabalho, consulte Visão geral das opções de implantação.
Saiba mais sobre os Google Cloud serviços de monitoramento de cargas de trabalho:
As métricas neste documento usam painéis do Monitoring. Saiba mais sobre os painéis do Monitoring, os períodos de retenção do Monitoring e os preços do Monitoring.
A detecção de straggler também fornece entradas de registro no Cloud Logging. Saiba mais sobre interfaces do Logging, períodos de retenção do Logging e preços do Logging.
Quando você usa o console Google Cloud para acessar serviços Google Cloud e APIs, não é necessário configurar a autenticação.
Limitações
As métricas neste documento só são compatíveis com cargas de trabalho executadas em instâncias de computação que atendem a todos os critérios a seguir:
- As instâncias de computação precisam ser criadas como instâncias autônomas do Compute Engine ou como parte de um cluster do Slurm.
- As instâncias de computação precisam ter sido criadas usando capacidade vinculada à reserva.
- As instâncias de computação precisam usar a série de máquinas A4X Max, A4X, A4, A3 Ultra ou A3 Mega.
- No entanto, a detecção de atrasados também é compatível com instâncias de máquina virtual (VM) que usam a série de máquinas A3 Mega.
As métricas neste documento são compatíveis apenas com cargas de trabalho executadas em instâncias de computação que atendem a todos os seguintes critérios:
- As instâncias de computação precisam ser criadas como instâncias autônomas do Compute Engine ou como parte de um cluster do Slurm.
- As instâncias de computação precisam ter sido criadas usando capacidade reservada.
- As instâncias de computação precisam usar a série de máquinas A4X Max, A4X, A4, A3 Ultra ou A3 Mega.
Para monitorar as métricas de carga de trabalho de ML, é necessário configurar o monitoramento da carga de trabalho.
Limitações da detecção de tarefas retardatárias
As métricas de detecção de outliers têm as seguintes limitações adicionais:
- Para séries de máquinas compatíveis que não sejam A3 Mega, a detecção de straggler só é compatível com instâncias de computação que permitem que a biblioteca Collective Communication Analyzer (CoMMA) exporte a telemetria do NCCL para serviços Google Cloud . Para mais informações, consulte a visão geral do CoMMA.
- A detecção de atrasados geralmente leva até 10 minutos para informar um atrasado.
- Ao contrário das outras métricas neste documento, não é possível filtrar as métricas de detecção de outliers para seus projetos por cluster, bloco, subbloco ou instância de computação. No entanto, é possível filtrar consultas para registros de detecção de atrasos pelo ID de uma ou mais instâncias de computação suspeitas.
Limitações da detecção de cargas de trabalho sem resposta
As métricas de detecção de carga de trabalho sem resposta só são compatíveis com instâncias de computação que usam a biblioteca Collective Communication Analyzer (CoMMA) para exportar a telemetria do NCCL para serviços do Google Cloud . Para mais informações, consulte a visão geral do CoMMA.
Funções exigidas
Para receber as permissões necessárias para monitorar métricas de cargas de trabalho do AI Hypercomputer, peça ao administrador para conceder a você os seguintes papéis do IAM:
-
Para ver métricas no Cloud Monitoring:
Editor do Monitoring (
roles/monitoring.editor) no projeto -
Para ver os registros de detecção de atrasos no Logging:
Visualizador de registros (
roles/logging.viewer) no projeto
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Esses papéis predefinidos contêm as permissões necessárias para monitorar métricas de cargas de trabalho do Hipercomputador de IA. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:
Permissões necessárias
As permissões a seguir são necessárias para monitorar métricas de cargas de trabalho do Hipercomputador de IA:
-
Para ver painéis:
monitoring.dashboards.getno projeto -
Para criar painéis:
monitoring.dashboards.createno projeto -
Para ver entradas de registro:
logging.logEntries.listno projeto
Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.
Métricas disponíveis
Dependendo do seu caso de uso, as seguintes métricas estão disponíveis para monitorar suas instâncias de computação e clusters do Slurm:
Para monitorar a integridade, o desempenho e o desempenho da rede das GPUs conectadas às instâncias de computação, consulte Métricas de infraestrutura.
Para monitorar a eficiência das GPUs nas suas cargas de trabalho de ML, consulte Métricas de carga de trabalho de ML.
Para monitorar instâncias de computação lentas em cargas de trabalho de ML com desempenho lento, consulte Métricas de detecção de lentidão.
Para saber como visualizar essas métricas, consulte Visualizar métricas neste documento.
Métricas de infraestrutura:
Para monitorar a integridade, o desempenho e o desempenho da rede das GPUs conectadas às instâncias de computação, use as seguintes métricas:
Para uma visão geral das métricas disponíveis no Compute Engine, consulte métricas doGoogle Cloud .
Métricas de integridade da GPU
Para monitorar a integridade das GPUs, use as seguintes métricas:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Status da máquina | machine/machine_status |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | Mostra se a máquina usada pela instância de computação está íntegra ou se ela não está e precisa de reparo. |
| Status do NVSwitch | instance/gpu/nvswitch_status |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | Se um switch NVLink em uma GPU NVIDIA conectada a uma instância de computação está apresentando problemas. |
| Integridade da infraestrutura de VM | instance/gpu/infra_health |
A4X, A4, A3 Ultra ou A3 Mega | A integridade do cluster, do bloco, do subbloco e do host em que as instâncias de computação estão sendo executadas. Se essa métrica mostrar que a infraestrutura de uma instância de computação não está íntegra, ela também vai descrever o problema. |
| Pontuação de previsão de falha da VM | instance/gpu/failure_prediction_score |
A4X, A4, A3 Ultra ou A3 Mega |
A probabilidade de degradação do host em que a instância de computação é executada nas próximas cinco horas. O valor pode estar entre 0.0 e 1.0. Quanto mais próximo o valor permanecer de 1.0 por um período consistente, maior a probabilidade de degradação da instância de computação. Nesse caso, recomendamos que você mova o job para outra instância de computação e, se encontrar problemas com a instância, informe o host dela como com falha.
|
Métricas de desempenho da GPU
Para monitorar o desempenho das GPUs, use as seguintes métricas:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Uso de contexto acumulado | instance/gpu/accumulated_context_utilization_seconds |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | O tempo total, em segundos, que a GPU está ocupada processando uma carga de trabalho. |
| Consumo de energia da GPU | instance/gpu/power_consumption |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | A energia em watts (W) e em valores decimais consumida em GPUs individuais no host. Para instâncias de computação com várias GPUs anexadas, a métrica fornece o consumo de energia separadamente para cada GPU no host. |
| Utilização do SM | instance/gpu/sm_utilization |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | Um valor diferente de zero indica que os multiprocessadores de streaming (SMs) nas GPUs estão sendo usados ativamente. |
| Temperatura da GPU | instance/gpu/temperature |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | A temperatura em graus Celsius (℃) e em valores decimais de GPUs individuais no host. Para instâncias de computação com várias GPUs anexadas, a métrica fornece a temperatura separadamente para cada GPU no host. |
| Margem térmica da GPU | instance/gpu/tlimit |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | A margem térmica em graus Celsius (℃) e em valores decimais que as GPUs individuais têm antes de precisarem reduzir a velocidade devido à alta temperatura. Para instâncias de computação com várias GPUs anexadas, a métrica fornece o headroom térmico separadamente para cada GPU no host. |
Métricas de desempenho de rede da GPU
Para monitorar o desempenho da rede das GPUs, use as seguintes métricas. Para monitorar switches de rede ToR de back-end, consulte Métricas de switch ToR.
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Mudanças na operadora do link | instance/gpu/link_carrier_changes |
A4X, A4, A3 Ultra ou A3 Mega | Com que frequência a operadora do link de rede muda em um minuto. |
| RTT da rede | instance/gpu/network_rtt |
A4X, A4, A3 Ultra ou A3 Mega | O tempo de retorno, medido em microssegundos, para que os dados da rede viajem entre uma origem e um destino. |
| Tráfego de rede entre blocos | instance/gpu/network/inter_block_tx |
A4X, A4, A3 Ultra ou A3 Mega | O número de bytes de tráfego de rede entre blocos. |
| Tráfego de rede entre sub-blocos | instance/gpu/network/inter_subblock_tx |
A4X, A4, A3 Ultra ou A3 Mega | O número de bytes de tráfego de rede entre sub-blocos. |
| Tráfego de rede no nível intra-sub-bloco | instance/gpu/network/intra_subblock_tx |
A4X, A4, A3 Ultra ou A3 Mega | O número de bytes de tráfego de rede em um único subbloco. |
| Velocidade ativa do NVLink | instance/gpu/nvlink_active_speed |
A4X Max, A4X, A4, A3 Ultra ou A3 Mega | A velocidade atual da porta do link de acesso, em GBps. |
| Bytes de RX de capacidade de processamento | instance/gpu/throughput_rx_bytes |
A4X, A4, A3 Ultra ou A3 Mega | O número de bytes recebidos do tráfego de rede. |
| Bytes de TX de capacidade de processamento | instance/gpu/throughput_tx_bytes |
A4X, A4, A3 Ultra ou A3 Mega | O número de bytes transmitidos para o tráfego de rede. |
Métricas de switch ToR
Para clusters A4X Max e A4X, é possível monitorar a telemetria do switch de rede ToR de back-end para fazer o seguinte durante o treinamento distribuído de ML:
- Observe a integridade do switch e da porta.
- Avalie a capacidade de largura de banda disponível e as profundidades da fila do buffer.
- Diagnosticar eventos de descarte de pacotes, erros, oscilações de interface e gerenciamento de congestionamento.
Essas métricas usam o tipo de recurso monitorado compute.googleapis.com/NetworkSwitch e o prefixo de tipo de métrica compute.googleapis.com/.
No Metrics Explorer, selecione o tipo de recurso NetworkSwitch (compute.googleapis.com/NetworkSwitch).
As métricas de troca são organizadas nas seguintes categorias:
Alternar métricas de integridade e status
Use as métricas listadas nesta seção para fazer o seguinte:
- Verifique o status operacional das portas do switch.
- Monitore o uso de CPU e memória do switch.
- Verifique os tempos de inicialização para detectar reinicializações inesperadas.
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Status da portabilidade | network_switch/port_status |
A4X Max ou A4X | Indica o status operacional da interface física (porta) no switch de rede. O valor da métrica é sempre 1 para agregação. O estado real é fornecido no rótulo status (como UP ou DOWN).Rótulos principais: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Uso da CPU | network_switch/cpu_utilization |
A4X Max ou A4X | A utilização da CPU da troca de rede, medida como uma fração de 0.0 a 1.0.Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
|
| Memória usada | network_switch/memory_used |
A4X Max ou A4X | A memória usada pelo switch de rede, em bytes. Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
|
| Memória total | network_switch/total_memory_bytes |
A4X Max ou A4X | A capacidade total de memória do switch de rede, em bytes. Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
|
| Tempo de inicialização | network_switch/boot_time_in_ns |
A4X Max ou A4X | O carimbo de data/hora de inicialização do switch de rede, em nanossegundos desde a época do Unix. Rótulos principais: subblock_id, block_id, reservation_id, switch_type.
|
Alternar métricas de capacidade e fila
Para acompanhar a capacidade de rede de linha de base versus utilizável e monitorar as profundidades da fila do buffer e as quedas de fila no switch, use as seguintes métricas:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Capacidade de referência | network_switch/baseline_capacity_kbps |
A4X Max ou A4X | A capacidade total potencial de largura de banda de referência de uma conexão de switch ToR com o superbloco, em quilobits por segundo (kbit/s). Rótulos principais: subblock_id, block_id, reservation_id, switch_type.
|
| Capacidade efetiva | network_switch/effective_capacity_kbps |
A4X Max ou A4X | A capacidade operacional utilizável de uma conexão de switch ToR com o
superbloco, em quilobits por segundo (kbit/s). Essa métrica reflete as reduções de capacidade causadas por links corrompidos ou off-line. Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
|
| Profundidade máxima da fila de saída | network_switch/egress_max_queue_depth |
A4X Max ou A4X | A profundidade máxima da fila observada durante o ciclo de medição mais recente. Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
|
| Descartes da fila de saída | network_switch/egress_queue_drops_count |
A4X Max ou A4X | A contagem cumulativa de pacotes descartados das filas de saída devido a congestionamento ou esgotamento do buffer. Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
|
| Em descartes de buffer | network_switch/in_buffer_discards |
A4X Max ou A4X | A contagem cumulativa de pacotes de entrada descartados na entrada devido a estouro de buffer. Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
Métricas de desistências, erros e controle de fluxo de chaves
Use as métricas nesta seção para diagnosticar os seguintes problemas, que podem causar paralisações no treinamento distribuído ou tempos limite de comunicação coletiva (como tempos limite de watchdog do NCCL):
- Descarte de pacotes, erros de transmissão e flaps de link físico.
- Erros de palavra de correção de erros de encaminhamento (FEC).
- Eventos de gerenciamento de congestionamento, como pausas do controle de fluxo baseado em prioridade (PFC) e marcações de notificação explícita de congestionamento (ECN).
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Abas da interface | network_switch/interface_flaps_count |
A4X Max ou A4X | A contagem cumulativa de transições de estado do link físico (flaps
entre UP e DOWN) na interface da porta do switch.Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Erros de palavras fecais | network_switch/fec_word_error_count |
A4X Max ou A4X | A contagem cumulativa de erros de palavra da correção de erros de encaminhamento (FEC, na sigla em inglês). Use o rótulo booleano correctable (true ou false) para distinguir entre erros corrigíveis e não corrigíveis.Rótulos de chave: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
|
| Pacotes marcados com ECN | network_switch/ecn_marked_packets_count |
A4X Max ou A4X | A contagem cumulativa de pacotes marcados com bits de notificação explícita de congestionamento (ECN) devido a cruzamentos de limite de buffer. Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Pacotes de recebimento de Pfc | network_switch/pfc_rx_packets_count |
A4X Max ou A4X | A contagem cumulativa de frames de pausa do controle de fluxo baseado em prioridade (PFC) recebidos na porta. Observação:válido apenas para ambientes dedicados em que o PFC está ativado. Rótulos de chave: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
|
| Pacotes de transmissão Pfc | network_switch/pfc_tx_packets_count |
A4X Max ou A4X | A contagem cumulativa de frames de pausa do controle de fluxo baseado em prioridade (PFC, na sigla em inglês) transmitidos pela porta para limitar o tráfego de entrada. Observação:válido apenas para ambientes dedicados em que o PFC está ativado. Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
|
| Pacotes de transmissão de QoS | network_switch/qos_tx_packets |
A4X Max ou A4X | A contagem cumulativa de pacotes de qualidade de serviço (QoS) transmitidos na fila especificada. Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
|
| Em contagem de pacotes | network_switch/in_packets_count |
A4X Max ou A4X | A contagem cumulativa de pacotes recebidos na porta do switch. Rótulos principais: port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Em erros | network_switch/in_errors |
A4X Max ou A4X | A contagem cumulativa de pacotes recebidos com erros que impediram a entrega. Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Na lixeira | network_switch/in_discards |
A4X Max ou A4X | A contagem cumulativa de pacotes de entrada válidos que foram descartados
(por exemplo, devido à falta de espaço no buffer). Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Erros de saída | network_switch/out_errors |
A4X Max ou A4X | A contagem cumulativa de pacotes de saída que não foram transmitidos devido a erros. Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Descartes de saída | network_switch/out_discards |
A4X Max ou A4X | A contagem cumulativa de pacotes de saída que foram escolhidos para serem
descartados, mesmo que nenhum erro tenha sido detectado. Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Contagem de bytes de entrada | network_switch/in_bytes_count |
A4X Max ou A4X | A contagem cumulativa de bytes recebidos na porta do switch. Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
| Contagem de bytes de saída | network_switch/out_bytes_count |
A4X Max ou A4X | A contagem cumulativa de bytes de saída transmitidos pela porta do switch. Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
|
Métricas de erros fatais da GPU
Para monitorar os erros encontrados pelas GPUs que podem forçar a interrupção das instâncias de computação ou afetar negativamente o desempenho delas, use as seguintes métricas:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Erro de tempo de execução do NVLink | instance/gpu/nvlink_runtime_error |
A4X Max ou A4X | Se ocorreu um erro de execução do NVLink. |
| Erros de ECC da DRAM não corrigíveis | instance/gpu/dram_uncorrectable_ecc_error_count |
A4X Max ou A4X | O número de códigos de correção de erros (ECCs) não corrigíveis em uma memória de acesso aleatório dinâmica (DRAM) da GPU. |
| Contagem não corrigível de remapeamento de linhas da DRAM | instance/gpu/dram_uncorrectable_row_remapping_count |
A4X Max ou A4X | O número de remapeamentos de linhas de erros não corrigíveis em DRAMs da GPU. |
| Falha no remapeamento de linhas da DRAM não corrigível | instance/gpu/dram_row_remapping_failed |
A4X Max ou A4X | Indica se um remapeamento de linhas em DRAMs de GPU falhou devido a um dos seguintes problemas:
|
| Erros não corrigíveis de PCIe | instance/gpu/pcie_fatal_error_count |
A4X Max ou A4X | O número de erros incorrigíveis de interconexão de componentes periféricos express (PCIe). |
| Erros de ECC de cache não corrigíveis | instance/gpu/cache_uncorrectable_ecc_error_count |
A4X Max ou A4X | O número de ECCs não corrigíveis na memória cache. |
Métricas de carga de trabalho de ML
Para monitorar a produtividade, especificamente o goodput, das suas cargas de trabalho de ML, use as seguintes métricas:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Tempo produtivo | workload/goodput_time |
A4X, A4, A3 Ultra ou A3 Mega | O tempo, em segundos, que a carga de trabalho passa em atividades de goodput. Essas atividades são tarefas principais e úteis, como uma transmissão direta ou inversa durante o treinamento de modelo. |
| Tempo não produtivo | workload/badput_time |
A4X, A4, A3 Ultra ou A3 Mega | O tempo, em segundos, que a carga de trabalho gasta em atividades de badput. Essas atividades são tarefas de sobrecarga, como carregamento ou pré-processamento de dados para treinamento. |
Métricas de detecção de tarefas retardatárias
As métricas de detecção de atrasados ajudam você a notar e identificar suspeitos. Retardatários são falhas de ponto único que não causam falhas, mas acabam atrasando toda a carga de trabalho.
Para monitorar a detecção de tarefas lentas nas suas VMs, use a seguinte métrica:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Suspeita de stragglers | instance/gpu/straggler_status |
A4X, A4, A3 Ultra ou A3 Mega | Se uma VM é suspeita de ser um atraso que está afetando o desempenho da carga de trabalho. Recomendamos que você tome medidas em relação a suspeitas de atrasos somente quando outras métricas indicarem que a carga de trabalho está com problemas. |
Também é possível conferir as métricas de detecção de atrasos nas entradas de registro de uma instância A4X, A4, A3 Ultra ou A3 Mega. Por exemplo, você pode usar as seguintes consultas:
| Descrição | Consulta |
|---|---|
| Registros com suspeita de atrasos para VMs específicas. Use esta consulta para verificar se há atrasos suspeitos em uma carga de trabalho específica no seu projeto. |
logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Substitua
OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
|
| Todos os registros da detecção de valores discrepantes do seu projeto. Use esta consulta para verificar se o serviço de detecção de atrasados está em execução quando nenhum atrasado suspeito é detectado. Devido às limitações, não é possível filtrar os registros sem suspeita de stragglers por VMs específicas. |
|
As métricas de detecção de straggler são especialmente úteis para cargas de trabalho de ML em grande escala pelos seguintes motivos:
Cargas de trabalho de ML em grande escala são muito suscetíveis a atrasos. Cargas de trabalho de ML em grande escala usam computação síncrona e distribuída em massa. Em outras palavras, eles têm muitos componentes altamente interdependentes que são executados simultaneamente. Essa arquitetura torna as cargas de trabalho de ML em grande escala muito suscetíveis a falhas de ponto único, como atrasos.
É muito difícil notar e identificar outliers em cargas de trabalho de ML em grande escala. Para referência, considere que há dois tipos de falhas de ponto único:
Falhas de interrupção: falhas que causam a paralisação de todo o sistema, por exemplo, erros de host e eventos de manutenção. Eles são relativamente simples de detectar e resolver.
Falhas lentas: falhas que causam degradação grave de desempenho sem falhas. É muito difícil identificar e depurar esses problemas.
Devido à natureza de falha lenta, é difícil notar e identificar os atrasados, especialmente em cargas de trabalho síncronas de grande escala.
Métricas de detecção de carga de trabalho sem resposta
As métricas de detecção de carga de trabalho sem resposta ajudam você a:
- Perceber quando uma carga de trabalho inteira está parada (às vezes chamada de NCCL hang)
- Entenda por que a carga de trabalho foi interrompida, por exemplo, se foi causada por uma falha no processo ou por uma rede paralisada.
Para detectar e diagnosticar cargas de trabalho sem resposta nas suas instâncias de computação, use as seguintes métricas:
| Nome | Tipo de métrica | Série de máquinas compatível | Descrição |
|---|---|---|---|
| Eventos de carga de trabalho sem resposta detectados usando a telemetria do NCCL | instance/gpu/nccl_hang |
A4X Max, A4X, A4 e A3 Ultra | O número de eventos de carga de trabalho sem resposta detectados, como uma série temporal. |
Ativar a detecção de cargas de trabalho sem resposta
Para ativar a detecção de carga de trabalho sem resposta, é necessário ativar o CoMMA com a telemetria de pulsação, um sinal de ping periódico que indica que uma carga de trabalho está em execução. Para versões recentes do CoMMA, essa opção é ativada por padrão. No entanto, se você estiver usando a versão do CoMMA do pacote NICCL/gIB 1.1.1, será necessário ativar manualmente a telemetria de pulsação. Para verificar qual versão do pacote NICCL/gIB você está usando, consulte Verificar a versão do NCCL e do gIB.
Para ativar manualmente a telemetria de pulsação para o CoMMA, especifique as seguintes variáveis de ambiente no ambiente de treinamento:
NCCL_PROFILER_HEARTBEAT=true
NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s
Use NCCL_PROFILER_HEARTBEAT para ativar ou desativar a telemetria de pulsação e NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL para especificar a frequência dela. Para mais informações, consulte
Variáveis de ambiente do CoMMA.
Desativar a detecção de carga de trabalho sem resposta
Para desativar a detecção de cargas de trabalho sem resposta, desative a telemetria de pulsação no CoMMA especificando a seguinte variável de ambiente no ambiente de treinamento:
NCCL_PROFILER_HEARTBEAT=false
Entenda por que as cargas de trabalho não respondem
Para entender por que uma carga de trabalho não responde, verifique o valor do rótulo
hang_reason seguindo estas etapas:
-
No console Google Cloud , acesse a página do leaderboard Metrics explorer:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
Pesquise a seguinte métrica:
compute.googleapis.com/instance/gpu/nccl_hangUse o recurso Agregação e selecione os seguintes rótulos:
instance_idhang_reason
A tabela a seguir lista os valores possíveis para o rótulo, o que esses valores significam sobre suas cargas de trabalho e as próximas etapas recomendadas.
| Valor do rótulo | Descrição | Próximas etapas recomendadas |
|---|---|---|
MissingHeartbeatIssue |
A telemetria de pulsação foi interrompida para um ou mais ranks, o que geralmente indica uma falha fatal no processo ou no nó. |
|
StalledRankIssue |
A telemetria de pulsação ainda está sendo recebida, mas as classificações não estão progredindo nas operações do NCCL. |
|
MissingCommunicatorIssue |
Todos os ranks que pertencem a um comunicador NCCL pararam de progredir. |
|
NoHangIssue |
O valor padrão. Nenhum problema foi detectado. |
|
Ver métricas
Para conferir as métricas das instâncias de computação e dos clusters do Slurm, use os painéis do Monitoring da seguinte maneira:
Para conferir as métricas de infraestrutura e de detecção de atrasos, faça o seguinte:
Para ter uma visão geral rápida da integridade e da performance da sua infraestrutura ou personalizar um painel, use painéis pré-criados.
Para necessidades específicas de monitoramento, crie painéis personalizados.
Para conferir as métricas de carga de trabalho de ML, consulte a documentação sobre como configurar o monitoramento da sua carga de trabalho.
Para ver os registros da detecção de atrasos, acesse os registros de detecção de atrasos.
Se você tiver problemas ao usar um painel, consulte Solução de problemas de desempenho lento.
Usar painéis predefinidos
Use os painéis do Monitoring pré-criados para o Hipercomputador de IA e confira as métricas das suas instâncias de computação e clusters do Slurm. Também é possível criar uma cópia de um painel predefinido e modificar para atender às suas necessidades.
Para usar um painel predefinido para o Hipercomputador de IA, faça o seguinte:
-
No console Google Cloud , acesse a página Painéis:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
Na coluna Nome, clique no nome de um dos seguintes painéis com base nas métricas que você quer visualizar:
Para monitorar a integridade da instância de computação, o desempenho da GPU e a detecção de atrasos, use o painel Monitoramento da integridade do Cluster Director.
Para mais informações sobre como usar essas métricas para identificar e analisar problemas, use também o painel do Playbook interativo do GCE: monitoramento da integridade do Cluster Director.
Para monitorar a eficiência da transmissão de rede, use o painel Eficiência de transmissão do Cluster Director.
Para monitorar a eficiência da rede entre blocos e sub-blocos, use o painel Rede de blocos do Cluster Director.
Para mais informações sobre como usar essas métricas para identificar e analisar problemas, use também o painel do Playbook interativo do GCE: rede de bloqueio do Cluster Director.
A página de detalhes do painel escolhido é aberta. Use o seletor de período na barra de ferramentas para mudar o período dos dados.
Opcional: para criar uma cópia de um painel e personalizá-lo de acordo com suas necessidades, clique em Copiar painel.
Criar painéis personalizados
Para criar um painel personalizado do Monitoring, faça o seguinte:
Escolha as métricas a serem monitoradas. Se ainda não tiver feito isso, consulte Métricas disponíveis neste documento.
Ver registros de detecção de straggler
Para conferir os registros de detecção de outliers usando a Análise de registros, siga estas etapas:
-
No console do Google Cloud , acesse a página Análise de registros:
Acessar a Análise de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.
Por padrão, a página consulta todos os registros no seu projeto. Clique em Interromper consulta.
Use o seletor de período na barra de ferramentas para escolher o intervalo de tempo que você quer analisar.
No painel Consulta, insira uma consulta para registros de detecção de straggler.
Selecione Executar consulta.
Confira a seguir um exemplo de entrada de registro de detecção de atraso.
{
...
"jsonPayload": {
...
"@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
"suspectedStragglersDetection": {
"numNodes": 4,
"nodes": [
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_1"
},
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_2"
},
{
"instanceId": "INSTANCE_ID_3",
"latencyMs": 4
},
{
"instanceId": "INSTANCE_ID_4",
"latencyMs": 0
}
],
"message": "Suspected stragglers detected."
}
},
"resource": {
"type": "project",
"labels": {
"project_id": "PROJECT_NUMBER"
}
},
...
"severity": "INFO",
"logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
...
}
A entrada de registro inclui os seguintes campos:
numNodes: o número de instâncias de computação suspeitas de serem lentas detectadas no projeto. No exemplo, foram detectadas quatro instâncias de computação suspeitas.instanceId: o ID de uma instância de computação detectada como um possível elemento atrasado.
A seguir
- Observar e monitorar VMs
- Personalizar painéis para serviços do Google Cloud
- Resolver problemas de performance lenta