Resolver problemas de VMs de GPU

Este guia descreve como diagnosticar e resolver problemas comuns com VMs do Compute Engine que têm GPUs anexadas, incluindo erros de hardware e gargalos de desempenho.

Resolver problemas de VMs de GPU usando DCGM da NVIDIA

O NVIDIA Data Center GPU Manager (DCGM) é um pacote de ferramentas para gerenciar e monitorar GPUs de data center NVIDIA em ambientes de cluster.

Se você quiser usar o DCGM para solucionar problemas no ambiente de GPU, conclua o seguinte:

• Verifique se você está usando o driver mais recente recomendado do NVIDIA para o modelo de GPU está anexado à sua VM. Para analisar as versões do driver, consulte Versões recomendadas do driver NVIDIA.
• Verifique se você instalou a versão mais recente do DCGM. Para instalar a versão mais recente, consulte Instalação do DCGM.

Diagnosticar problemas

Quando você executa um comando de diagnóstico dcgmi, os problemas relatados pelo diagnóstico incluem as próximas etapas para tomar medidas em relação ao problema. O exemplo a seguir mostra a saída acionável do comando dcgmi diag -r memory -j.

{
  ........
   "category":"Hardware",
   "tests":[
      {
         "name":"GPU Memory",
         "results":[
            {
               "gpu_id":"0",
               "info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
               "status":"Fail",
               ""warnings":[
                  {
                     "warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
                     "error_id":83,
                     "error_category":10,
                     "error_severity":6
                  }
               ]
            }
  .........

No snippet de saída anterior, é possível notar que GPU 0 tem desativações de páginas pendentes causadas por um erro irrecuperável. A saída forneceu o error_id exclusivo e orientações sobre como depurar o problema. Para este exemplo de saída, recomendamos que você drene a GPU e reinicie a VM. Na maioria dos casos, seguir as instruções desta seção da resposta pode ajudar a resolver o problema.

Dica profissional: observe a gravidade do erro. No exemplo, gere um valor de "error_severity":6 corresponde a um DCGM_ERROR_RESET, o que significa que uma redefinição resolve problemas com esse valor de gravidade.

Para uma lista completa dos valores error_severity, revise a seção dcgmErrorSeverity_enum do arquivo dcgm_errors do GitHub.

Resolver problemas de desempenho da GPU para VMs A3

A série de máquinas A3 está disponível com GPUs NVIDIA H200 ou H100 anexadas. Essa série inclui os tipos de máquina A3 Ultra (H200), A3 Mega (H100), A3 High (H100) e A3 Edge (H100).

Identificar um nó com falha

Jobs de treinamento ou comparativos de grande escala em um cluster de GPU de vários nós podem parar de responder ou ter um desempenho ruim. Isso geralmente acontece porque um ou mais nós têm desempenho abaixo do esperado e diminuem a velocidade de toda a operação. Nesta seção, descrevemos como identificar um nó ou uma máquina host com falha executando um teste de comparativo de mercado do NCCL ou analisando os registros do NCCL.

Executar o teste de comparativo de mercado da NCCL

Para identificar o grupo de nós que está causando a falha, teste sistematicamente subconjuntos do cluster usando comparativos de NCCL, como all_reduce_perf.

1. Para identificar seus conjuntos de nós, agrupe os nós em conjuntos lógicos, por exemplo, partições no Slurm.
2. Para criar arquivos de host, crie um arquivo separado para cada conjunto de nós, listando nomes de host e o número de GPUs por nó. O número de slots especificados depende da contagem de GPUs do tipo de VM A3. Por exemplo, as VMs a3-highgpu-8g têm 8 GPUs, então você precisa especificar slots=8.
3. Para executar comparativos de mercado, execute o all_reduce_perf em cada conjunto de nós individualmente.

   mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \
       ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODE
             

   Substitua:

   • HOSTFILE_NAME: o nome do arquivo de host que contém a lista de nós e o número de GPUs por nó para o conjunto de nós.
   • TOTAL_PROCESSES: o número total de processos do MPI a serem iniciados em todos os hosts no conjunto de nós.
   • NUM_GPUS_PER_NODE: o número de GPUs por nó. Para todos os tipos de máquina A3, esse valor é 8.
4. Para analisar os resultados, se um job travar ou mostrar uma largura de banda de barramento significativamente menor (busbw) em um conjunto de nós específico, é provável que esse conjunto esteja com falha.
5. Para subdividir, se um conjunto de nós estiver com falha, divida o arquivo de host pela metade e teste novamente para restringir a pesquisa binária até identificar o nó individual com comportamento inadequado.

Analisar registros do NCCL

Se o método de comparativo de mercado não identificar um nó, analise os registros detalhados do NCCL.

1. Para ativar o registro de depuração, defina as seguintes variáveis de ambiente na sessão do shell em que você planeja executar sua carga de trabalho:

   export NCCL_DEBUG=INFO
           export NCCL_DEBUG_SUBSYS=INIT,NET,COLL
           export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"
           

   Substitua LOG_DIRECTORY pelo diretório em que você quer armazenar os registros.

   Definir NCCL_DEBUG_FILE com %h e %p cria arquivos de registro exclusivos e não intercalados para cada processo.

   Se você estiver executando uma carga de trabalho de vários nós usando mpirun, propague essas variáveis para todos os nós usando a flag -x. Por exemplo:

   mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ...
             

2. Para encontrar o primeiro erro, use o comando a seguir para encontrar os eventos de tempo limite ou falha mais antigos em todos os arquivos de registro:

   grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \
     | sort | head -n 20
             

   Substitua LOG_DIRECTORY pelo diretório em que os registros estão armazenados.

3. Para contar operações coletivas, um nó lento conclui menos operações coletivas. Contagem de entradas "opCount" para classificações de suspeitos:

   grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l
             

   Substitua:

   • LOG_DIRECTORY: o diretório onde seus registros são armazenados
   • HOSTNAME: o nome do host do nó
   • PID: o ID do processo NCCL.
4. Para coletar mais dados de registro em log antes que um job seja anulado, aumente temporariamente o tempo limite de transferência de dados:

   export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
           

Monitorar a redução da velocidade da GPU por motivos térmicos

As VMs da série A3 podem sofrer degradação de desempenho se atingirem consistentemente temperaturas superiores a 87 °C sob carga. Para verificar o controle térmico da GPU em todos os nós de um cluster, use nvidia-smi ou dcgmi.

Como usar o nvidia-smi

Para verificar a temperatura atual e o status de limitação de todas as GPUs em um nó, execute o seguinte comando:

nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
    

Na saída, um valor de Active na coluna clocks_throttle_reasons.hw_slowdown indica que a GPU está sendo limitada devido a temperaturas altas.

Como usar o dcgmi

O pacote de diagnóstico do NVIDIA Data Center GPU Manager (DCGM) inclui verificações de violações térmicas. Para executar um diagnóstico de nível 1, execute o seguinte comando:

dcgmi diag -r 1

Um resultado de Warn ou Fail na seção Thermal indica que ocorreu uma violação térmica durante o teste. Se uma violação térmica for acompanhada de limitação de clock, a GPU provavelmente está superaquecendo e requer mais investigação.

Abrir um caso de suporte

Se você não conseguir resolver os problemas usando a orientação nesta página, reúna as seguintes informações e abra um caso de suporte:

• O ID do projeto e uma lista de todos os nomes ou IDs de instância no cluster.
• Lista de nós suspeitos identificados durante a solução de problemas.
• Registros do NCCL completos e não intercalados com as configurações de depuração ativadas.
• Saída das verificações de integridade do hardware (dcgmi, nvidia-smi).
• Comando exato de comparativo ou carga de trabalho que está falhando.
• Arquivos de registro relevantes, como registros do mecanismo do host e de diagnósticos. Para coletar esses dados, execute gather-dcgm-logs.sh, localizado em /usr/local/dcgm/scripts nas instalações padrão.
• Relatório de bug da NVIDIA. Execute nvidia-bug-report.sh. Para GPUs Blackwell, siga as instruções em Gerar relatório de bugs da NVIDIA para GPUs Blackwell.
• Detalhes sobre as mudanças recentes feitas no seu ambiente que precedem a falha.

Analisar mensagens Xid

Depois de criar uma VM com GPUs anexadas, você precisa instalar drivers de dispositivo NVIDIA nas VMs de GPU para que seus aplicativos possam acessar as GPUs. No entanto, às vezes esses drivers retornam mensagens de erro.

Uma mensagem Xid é um relatório de erros do driver NVIDIA que é impresso no registro do kernel ou no log de eventos do sistema operacional para a VM do Linux. Essas mensagens são colocadas no arquivo /var/log/messages.

Para mais informações sobre mensagens Xid, incluindo possíveis causas, consulte a documentação da NVIDIA.

A seção a seguir contém orientações sobre como lidar com algumas mensagens Xid agrupadas pelos tipos mais comuns: erros de memória da GPU, erros do processador do sistema da GPU (GSP, na sigla em inglês) e erros de acesso ilegal à memória.

Erros de memória da GPU

A memória da GPU é aquela disponível em uma GPU que pode ser usada para armazenamento temporário de dados. A memória da GPU é protegida com o código de correção de erro (ECC, na sigla em inglês), que detecta e corrige erros de bit único (SBE, na sigla em inglês) e detecta e informa erros de bit duplo (DBE, na sigla em inglês).

Antes do lançamento das GPUs NVIDIA A100, a desativação dinâmica de páginas era possível. Na NVIDIA A100 e nas versões de GPU mais recentes (como NVIDIA H100), foi introduzida a recuperação de erro de remapeamento de linhas. O ECC está ativado por padrão. O Google recomenda seriamente manter o ECC ativado.

Confira a seguir os erros comuns de memória da GPU e as resoluções sugeridas.

Mensagem de erro Xid	Resolução
Xid 48: Double Bit ECC	Interrompa suas cargas de trabalho. Exclua e recrie a VM. Se o erro persistir, registre um caso no Cloud Customer Care.
Xid 63: ECC page retirement or row remapping recording event	Interrompa suas cargas de trabalho. Redefina as GPUs.
Xid 64: ECC page retirement or row remapper recording failure E a mensagem contiver as seguintes informações: Xid 64: All reserved rows for bank are remapped	Interrompa suas cargas de trabalho. Exclua e recrie a VM. Se o erro persistir, registre um caso no Cloud Customer Care.
Se você receber pelo menos duas das seguintes mensagens Xid: Xid 48 Xid 63 Xid 64 E a mensagem contiver as seguintes informações: Xid XX: row remap pending	Interrompa suas cargas de trabalho. Redefina as GPUs. Redefinir a GPU permite que o processo de desativação de páginas e o remapeamento de linhas sejam concluídos e corrijam a GPU.
Xid 92: High single-bit ECC error rate	Essa mensagem Xid é retornada depois que o driver da GPU solucione um erro corrigível e não afeta suas cargas de trabalho. Essa mensagem Xid é apenas informativa. Nenhuma ação é necessária.
Xid 94: Contained ECC error	Interrompa suas cargas de trabalho. Redefina as GPUs.
Xid 95: Uncontained ECC error	Interrompa suas cargas de trabalho. Redefina as GPUs.

Erros de GSP

O processador do sistema da GPU (GSP) é um microcontrolador executado em GPUs e desempenha algumas funções de gerenciamento de hardware de baixo nível.

Mensagem de erro Xid	Resolução
Xid 119: GSP RPC timeout	Interrompa suas cargas de trabalho. Exclua e recrie a VM. Se o erro persistir, colete o relatório do bug da NVIDIA e registre um caso no Cloud Customer Care.
Xid 120: GSP error

Erros de acesso ilegal à memória

Os Xids abaixo são retornados quando os aplicativos têm problemas de acesso ilegal à memória:

• Xid 13: Graphics Engine Exception
• Xid 31: GPU memory page fault

Os erros de acesso ilegal à memória geralmente são causados por cargas de trabalho que tentam acessar a memória que já está liberada ou está fora dos limites. Isso pode ser causado por problemas como o desreferenciamento de um ponteiro inválido ou uma matriz de limites externos.

Para resolver esse problema, é preciso depurar seu aplicativo. Para depurar o aplicativo, use cuda-memcheck e CUDA-GDB (links em inglês).

Em alguns casos muito raros, a degradação do hardware pode fazer com que erros de acesso ilegal à memória sejam retornados. Para identificar se o problema é com seu hardware, use o NVIDIA Data Center GPU Manager (DCGM). Execute dcgmi diag -r 3 ou dcgmi diag -r 4 para executar diferentes níveis de cobertura e duração de teste. Se você identificar que o problema está no hardware, registre um caso no Cloud Customer Care.

Outras mensagens de erro comuns do Xid

Mensagem de erro Xid	Resolução
Xid 74: NVLINK error	Interrompa suas cargas de trabalho. Redefina as GPUs.
Xid 79: GPU has fallen off the bus Isso significa que o driver não pode se comunicar com a GPU.	Reinicialize a VM.
Xid 149 que menciona 0x02a, como no exemplo a seguir: Xid (PCI:0000:c0:00): 149,NETIR_LINK_EVT Fatal XC0 i0 Link 04 (0x02a485c6 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000) Isso indica um problema conhecido que afeta o firmware das GPUs NVIDIA B200.	Interrompa suas cargas de trabalho. Redefina as GPUs.

Redefinir GPUs

Alguns problemas podem exigir a redefinição das GPUs. Para redefinir as GPUs, siga as etapas a seguir:

• Para VMs N1, G2 e A2, reinicie a VM.
• Para VMs G4 com menos de uma GPU anexada, exclua e recrie a VM.
• Para VMs A3 e A4, execute sudo nvidia-smi --gpu-reset.
  • Para a maioria das VMs do Linux, o executável nvidia-smi está localizado no diretório /var/lib/nvidia/bin.
  • Para nós do GKE, o executável nvidia-smi está localizado no diretório /home/kubernetes/bin/nvidia.
  • Se você estiver usando nós do GKE, poderá usar a ferramenta gpu-reset para automatizar a redefinição de todas as GPUs em um nó. Essa ferramenta exige apenas que você especifique o nome do nó de destino.

Como alternativa, as GPUs também são redefinidas sempre que você redefine uma VM ou reinicia uma VM.

Se os erros persistirem após a redefinição da GPU, será necessário excluir e recriar a VM.

Se o erro persistir após uma exclusão e recriação, registre um caso no Cloud Customer Care para mover a VM para o estágio de reparo.

A seguir

Consulte os tipos de máquina de GPU.