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.

Para usar o DCGM e solucionar problemas no ambiente de GPU, siga estas etapas:

  • Verifique se você está usando o driver mais recente recomendado da NVIDIA para o modelo de GPU 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 nesta seção da saída pode ajudar a resolver o problema.

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 deixam toda a operação mais lenta. 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 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 mercado da 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ê executar 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 térmica da GPU

As VMs da série A3 podem sofrer degradação de desempenho se atingirem consistentemente temperaturas superiores a 87 °C sob carga. Para verificar se há limitação térmica de GPU em 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.

Erros de 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.

Como o Google lida com erros de Xid

O Google usa verificações de integridade passivas para avaliar sistemas de GPU. Se for indicada a substituição de hardware, o Google vai iniciar automaticamente uma manutenção de emergência. O Google detecta erros de Xid e envia proativamente as máquinas para conserto quando os códigos de erro indicam uma alta probabilidade de falha de hardware, como Xid 74, 79 e 140. Para alguns códigos Xid, como eles podem ser causados por problemas de software ou hardware, o Google usa a correspondência de padrões para acionar reparos. Portanto, nem toda ocorrência resulta em um reparo automático.

Tipos de erros de Xid

A lista a seguir descreve as três principais categorias de erros de XID e as ações de recuperação recomendadas:

  • Erros de aplicativo:indicam problemas no código do aplicativo. Os erros de aplicativo incluem Xids como 13, 31, 94, 95 e 137, que indicam vários tipos de violação de acesso à memória, semelhante a uma falha de segmentação. Isso não indica um erro de ECC. Para resolver esses erros, a NVIDIA recomenda usar uma das seguintes abordagens de depuração:

    • Depuração direta:execute o aplicativo diretamente em cuda-gdb ou execute a ferramenta Compute Sanitizer memcheck.
    • Depuração pós-exceção:execute o aplicativo com CUDA_DEVICE_WAITS_ON_EXCEPTION=1. Quando uma exceção ocorre, o driver da GPU congela o estado do aplicativo sem sair para que você possa anexar um depurador mais tarde (cuda-gdb -p <PID>) para inspecionar o stack trace ativo.

  • Erros de driver:indicam problemas causados pelo driver da GPU NVIDIA. Para resolver esses erros, verifique se você está usando a versão mais recente do driver da NVIDIA. O Google monitora esses erros e colabora com a NVIDIA para corrigir os drivers.

  • Erros recuperáveis de firmware ou hardware:indicam erros de firmware ou hardware que permitem a recuperação sem substituição de hardware. Para resolver esses erros, aplique medidas de recuperação manual, como redefinir a GPU ou reiniciar a instância. Os erros recuperáveis de firmware ou hardware incluem erros de código de correção de erros (ECC, na sigla em inglês), aplicáveis a Xids como 48, 63 e 64, que indicam vários estágios de detecção e mitigação de erros de ECC. Para mais informações sobre a desativação de páginas e a mitigação de erros de ECC, consulte as Perguntas frequentes sobre a desativação dinâmica de páginas da NVIDIA.

Analisar mensagens Xid

Para diagnosticar rapidamente por que uma carga de trabalho de GPU falhou, parou de responder ou teve uma degradação de performance, verifique os registros do kernel da instância (dmesg ou /var/log/kern.log) em busca de códigos de erro numéricos Xid da NVIDIA.

Analisar as tabelas de erros de Xid nas subseções a seguir ajuda você imediatamente a:

  • Identifique a causa raiz:determine se a falha é causada por um bug de aplicativo (como acesso ilegal à memória), um conflito de driver ou uma falha física de hardware (como erros de memória ECC de bit duplo).
  • Determine a propriedade operacional:verifique quais medidas de recuperação manual imediata você precisa aplicar, como redefinir GPUs, reiniciar VMs ou executar depuradores, em comparação com quais ações automatizadas de reparo e substituição de hardware o Google está gerenciando ativamente no host.
  • Siga as etapas de recuperação corretas:evite procedimentos desnecessários de solução de problemas e saiba exatamente quando a recuperação manual é suficiente e quando é necessário informar que o host está com falha. Às vezes, a recuperação manual não é suficiente, por exemplo, se a origem do erro estiver no cache da GPU (SRAM), que não pode ser remapeado, indicado por Xid 48 com SRAM Threshold Exceeded=Yes, ou se a GPU esgotou o banco de remapeamento, indicado por Xid 64: All reserved rows for bank are remapped. Nesses casos, o Google detecta que a GPU está qualificada para substituição de hardware e envia proativamente a máquina para reparo. Se as cargas de trabalho encontrarem erros recorrentes ou se você observar falhas de memória repetidas, denuncie o host com falha para iniciar o reparo ou a substituição automatizados. Para o GKE, consulte Como informar hosts com falha no GKE.

Processamento de Xid

As seções a seguir agrupam mensagens de erro comuns do Xid por categoria técnica, além das resoluções e responsabilidades oficiais:

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 incorrigíveis (DBE, na sigla em inglês).

Esses erros de memória devem ocorrer durante a vida útil de uma GPU. 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 para erros de HBM (DRAM). O ECC está ativado por padrão, e o Google recomenda manter esse recurso ativado.

A tabela a seguir lista erros comuns de memória da GPU e as resoluções sugeridas:

Mensagem de erro Xid Ação do cliente Ação do Google
Xid 48: Double Bit ECC

Um erro de memória de bit duplo (não corrigível) foi detectado pelo ECC. Esse erro sempre interrompe a carga de trabalho em execução e gera Xid 48.
  1. Interrompa suas cargas de trabalho.
  2. Dependendo do seu ambiente, redefina as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

O Google monitora quando a GPU está qualificada para substituição de hardware, por exemplo, se o banco de remap HBM estiver esgotado ou se a GPU exceder o limite de erros de SRAM de vida útil. Ele envia proativamente a máquina para conserto e substituição da GPU.
Xid 63: ECC page retirement or row remapping recording event

Indica que um evento dinâmico de desativação de página ou remapeamento de linha foi registrado devido a um erro de memória.
  1. Interrompa suas cargas de trabalho.
  2. Dependendo do seu ambiente, redefina as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

O Google monitora os limites de erros e envia a máquina para conserto quando a GPU precisa de reparo ou substituição física.
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
  1. Interrompa suas cargas de trabalho.
  2. Dependendo do seu ambiente, redefina as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

Quando o banco de remapeamento se esgota (All reserved rows for bank are remapped), o Google detecta que a GPU está qualificada para substituição de hardware e envia proativamente a máquina para conserto.

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
  1. Interrompa suas cargas de trabalho.
  2. Dependendo do seu ambiente, redefina as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

O Google envia a máquina para conserto se o banco de remapeamento estiver esgotado ou quando a GPU precisar de reparo ou substituição física.
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.

Nenhum
Xid 94: Contained error

Indica que ocorreu um erro de GPU e se ele estava contido em um único aplicativo.

Sozinho, o Xid 94 não indica a causa raiz do erro. Ele precisa ser interpretado com outros erros de Xid simultâneos para determinar a causa fundamental.
  1. Como o erro estava contido em um único aplicativo, reinicie o aplicativo para fazer a recuperação.
  2. Se necessário, redefina as GPUs ou pare as cargas de trabalho.
  3. Investigue outros erros de Xid simultâneos para mais etapas de recuperação e determinação da causa raiz.

Nenhum
Xid 95: Uncontained error

Indica que ocorreu um erro de GPU que não ficou restrito a um único aplicativo.

Sozinho, o Xid 95 não indica a causa raiz do erro. Ele precisa ser interpretado com outros erros de Xid simultâneos para determinar a causa fundamental.
  1. Como o erro não foi contido, pare as cargas de trabalho e redefina as GPUs ou reinicie a VM para fazer a recuperação.
  2. Investigue outros erros de Xid simultâneos para determinar a causa raiz e outras etapas de recuperação.

Nenhum

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 Ação do cliente Ação do Google
Xid 119: GSP RPC timeout
  1. Interrompa suas cargas de trabalho.
  2. Confira Ramificações recomendadas do driver NVIDIA para garantir que você esteja usando uma ramificação compatível e uma versão recente ou mais recente do driver, já que bugs em versões anteriores são uma das principais causas de erros do GSP.
  3. Se o erro persistir depois de verificar ou atualizar o driver, 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.

Nenhuma. Se o erro persistir e você registrar um caso de suporte, o Google investigará o estado do hardware ou do driver pelo fluxo de trabalho de suporte.
Xid 120: GSP error

Erros de acesso ilegal à memória

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

Mensagem de erro Xid Ação do cliente Ação do Google

Xid 13: Graphics Engine Exception

Xid 31: GPU memory page fault

Xid 137: Memory access fault

Uma violação de acesso à memória foi detectada, análoga a uma falha de segmentação. Esses erros geralmente indicam um bug de aplicativo em que a memória da GPU é acessada fora dos limites ou em buffers liberados, como a remoção da referência de um ponteiro inválido ou de uma matriz fora dos limites. Eles não representam erros de ECC, a menos que o Xid 48 também esteja presente.

Para resolver esse problema, depure as falhas de acesso à memória no seu aplicativo. Você pode usar cuda-gdb, Compute Sanitizer ou cuda-memcheck.

Para mais detalhes, consulte a documentação da NVIDIA Xid (em inglês).

Nenhuma. Em casos raros em que a degradação do hardware pode causar erros de acesso ilegal à memória relatados incorretamente, use o NVIDIA Data Center GPU Manager (DCGM) para executar dcgmi diag -r 3 ou dcgmi diag -r 4 em diferentes níveis de cobertura e duração do teste. Se você identificar um problema de hardware, registre um caso no Customer Care.

Outras mensagens de erro comuns do Xid

Mensagem de erro Xid Ação do cliente Ação do Google
Xid 74: NVLINK error
  1. Interrompa suas cargas de trabalho.
  2. Redefina as GPUs.

Nenhum
Xid 79: GPU has fallen off the bus

Isso significa que o driver não pode se comunicar com a GPU porque um problema de hardware fez com que a GPU desaparecesse do barramento PCI.

Para recuperar as cargas de trabalho, use uma das abordagens a seguir, dependendo se a manutenção de emergência está ativada para seu projeto:

  • Solicite uma manutenção de emergência:se uma manutenção de emergência for lançada para seu projeto, acione o evento de manutenção quando for mais conveniente para você.
  • Aguardar a manutenção automatizada:caso contrário, aguarde um evento de manutenção não planejado na instância.

O Google detecta que a GPU caiu do barramento PCI e envia a máquina para reparo.
Xid 109: Context switch timeout

O Xid 109 é um erro genérico informado pelo driver da GPU NVIDIA, gerado quando uma instância de GPU não consegue fazer a substituição preemptiva ou alternar tarefas dentro do período de tempo limite esperado.

O Google tem um longo histórico de investigação do Xid 109 com a NVIDIA, e as causas conhecidas de bugs de driver são corrigidas nos drivers mais recentes. O Xid 109 não é causado por um problema de hardware.
  1. Interrompa suas cargas de trabalho.
  2. Dependendo do seu ambiente, redefina as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:
  3. Considere fazer upgrade para uma versão mais recente do driver NVIDIA no seu ambiente como instalar o driver mais recente na sua VM do Compute Engine ou fazer upgrade do pool de nós/DaemonSet de driver do GKE.

Nenhum
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.
  1. Interrompa suas cargas de trabalho.
  2. Redefina as GPUs.

Nenhum

Redefinir GPUs

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

  • Para VMs N1, G2, A2 e G4 com uma ou mais GPUs anexadas, reinicie a VM.
  • Para VMs G4 com GPUs fracionárias (menos de uma GPU anexada), siga estas etapas:
    1. Exclua a VM.
    2. Recrie a VM.
  • Para instâncias A3, A4, A4X e A4X Max, 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.
  • Para instâncias A3, A4, A4X e A4X Max em nós do GKE, também é possível usar a gpu-reset-tool 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 interrompe e reinicia uma VM. Para mais informações sobre os estados do ciclo de vida da VM e as diferenças entre as ações de recuperação de VM, consulte Ciclo de vida da instância do Compute Engine e Suspender, interromper ou redefinir instâncias do Compute Engine.

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 em que as instâncias afetadas estão localizadas.
  • Lista de todos os nomes ou IDs de instâncias 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 um relatório de bugs da NVIDIA para GPUs Blackwell.
  • Detalhes sobre as mudanças recentes feitas no seu ambiente que precedem a falha.

A seguir

Consulte os tipos de máquina de GPU.