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 desta seção da resposta 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 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 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 do 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 hosts, 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 que você especifica 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 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 ficar travado ou mostrar uma largura de banda de barramento (busbw) significativamente menor 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 a 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 seguinte comando 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 seus 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 em que 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 cancelado, 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 da 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, é provável que a GPU esteja superaquecendo e precise de 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 a substituição de hardware for indicada, 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 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.

Revisar 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) para 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:descubra 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 tiver esgotado 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 apresentarem 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 de 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 podem 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 essa opção ativada.

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, como 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 reparo 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 reparo 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 para fazer a recuperação.
  2. Se necessário, redefina as GPUs ou interrompa 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 as próximas 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 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.
  • 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 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 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

Resolver problemas de falha de nvidia-smi após aplicação de patch no SO ou upgrade do kernel

Se o nvidia-smi falhar com NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver após uma janela de manutenção, uma execução de patch do SO ou uma reinicialização da VM, verifique as retenções do pacote do kernel. Os bloqueios de pacote de uma instalação anterior de driver no modo binary podem impedir a instalação de cabeçalhos de kernel correspondentes.

Para diagnosticar e resolver esse problema, selecione seu sistema operacional:

Ubuntu

  1. Verifique a versão do kernel em execução:

    uname -r

  2. Verifique se uma instalação anterior do driver no modo binary bloqueou os pacotes do kernel, como quando você usa instâncias de computação --force-version, --installation-branch=lts ou NVIDIA RTX Virtual Workstation (vWS):

    apt-mark showhold

    Verifique se linux-image-gcp ou linux-headers-gcp está na lista.

  3. Verifique se os cabeçalhos do kernel estão instalados para o kernel em execução:

    dpkg -l | grep "linux-headers-$(uname -r)"

  4. Se os metapacotes do kernel estiverem retidos, remova os bloqueios de pacote:

    sudo apt-mark unhold linux-image-gcp linux-headers-gcp

  5. Instale os cabeçalhos do kernel em execução:

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

  6. Recrie e carregue o módulo do kernel da NVIDIA:

    • Se as origens do módulo DKMS estiverem registradas (verifique sudo dkms status):

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • Se sudo dkms status não mostrar nenhum módulo NVIDIA registrado (por exemplo, se o driver tiver sido instalado anteriormente usando um binário .run sem --dkms), execute novamente o instalador de driver de GPU Google Cloud :

      sudo python3 cuda_installer.pyz install_driver

Debian

  1. Verifique a versão do kernel em execução:

    uname -r

  2. Verifique se uma instalação anterior do driver no modo binary bloqueou os pacotes do kernel, como quando você usa instâncias de computação --force-version, --installation-branch=lts ou NVIDIA RTX Virtual Workstation (vWS):

    apt-mark showhold

    Verifique se linux-image-cloud-amd64 ou linux-headers-cloud-amd64 está na lista.

  3. Verifique se os cabeçalhos do kernel estão instalados para o kernel em execução:

    dpkg -l | grep "linux-headers-$(uname -r)"

  4. Se os metapacotes do kernel estiverem retidos, remova os bloqueios de pacote:

    sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64

  5. Instale os cabeçalhos do kernel em execução:

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

  6. Recrie e carregue o módulo do kernel da NVIDIA:

    • Se as origens do módulo DKMS estiverem registradas (verifique sudo dkms status):

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • Se sudo dkms status não mostrar nenhum módulo NVIDIA registrado (por exemplo, se o driver tiver sido instalado anteriormente usando um binário .run sem --dkms), execute novamente o instalador de driver de GPU Google Cloud :

      sudo python3 cuda_installer.pyz install_driver

RHEL e Rocky Linux

  1. Verifique a versão do kernel em execução:

    uname -r

  2. Verifique se uma instalação anterior do driver no modo binary bloqueou os pacotes do kernel, como quando você usa instâncias de computação --force-version, --installation-branch=lts ou NVIDIA RTX Virtual Workstation (vWS):

    grep "^exclude=.*kernel" /etc/dnf/dnf.conf

  3. Verifique se os cabeçalhos do kernel estão instalados para o kernel em execução:

    rpm -qa | grep "kernel-devel-$(uname -r)"

  4. Se os pacotes do kernel forem excluídos, remova kernel* da linha exclude= em /etc/dnf/dnf.conf.

  5. Instale os cabeçalhos do kernel em execução:

    sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)

  6. Recrie e carregue o módulo do kernel da NVIDIA:

    • Se as fontes do módulo DKMS estiverem registradas (verifique sudo dkms status):

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • Se sudo dkms status não mostrar nenhum módulo NVIDIA registrado (por exemplo, se o driver tiver sido instalado anteriormente usando um binário .run sem --dkms), execute novamente o instalador de driver de GPU Google Cloud :

      sudo python3 cuda_installer.pyz install_driver

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 ferramenta de redefinição de GPU 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.