Resolva problemas com VMs com 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 estrangulamentos de desempenho.

Resolva problemas de VMs com GPU através do NVIDIA DCGM

O NVIDIA Data Center GPU Manager (DCGM) é um conjunto de ferramentas para gerir e monitorizar as GPUs do centro de dados da NVIDIA em ambientes de cluster.

Para usar o DCGM para resolver problemas no seu ambiente de GPU, conclua o seguinte:

  • Certifique-se de que está a usar o controlador NVIDIA recomendado mais recente para o modelo de GPU que está ligado à sua VM. Para rever as versões dos controladores, consulte as versões recomendadas dos controladores NVIDIA.
  • Certifique-se de que instalou a versão mais recente do DCGM. Para instalar a versão mais recente, consulte o artigo Instalação do DCGM.

Diagnostique problemas

Quando executa um comando de diagnóstico do dcgmi, os problemas comunicados pela ferramenta de diagnóstico incluem os passos seguintes para tomar medidas relativamente ao problema. O exemplo seguinte mostra o resultado 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 fragmento de saída anterior, pode ver que o GPU 0 tem retiradas de páginas pendentes causadas por um erro não recuperável. O resultado forneceu o error_id único e conselhos sobre como depurar o problema. Para este exemplo de saída, recomendamos que drene a GPU e reinicie a VM. Na maioria dos casos, seguir as instruções nesta secção do resultado pode ajudar a resolver o problema.

Resolva 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. Esta série inclui os tipos de máquinas A3 Ultra (H200), A3 Mega (H100), A3 High (H100) e A3 Edge (H100).

Identifique um nó com defeito

As tarefas de benchmark ou de preparação em grande escala num cluster de GPUs com vários nós podem deixar de responder ou ter um desempenho fraco. Isto ocorre frequentemente porque um ou mais nós têm um desempenho inferior e abrandam toda a operação. Esta secção descreve como identificar um nó ou uma máquina anfitriã com defeito, executando um teste de referência da NCCL ou analisando os registos da NCCL.

Execute o teste de referência da NCCL

Para identificar o grupo de nós que está a causar a falha, teste sistematicamente subconjuntos do cluster usando referências da NCCL, como all_reduce_perf.

  1. Para identificar os seus conjuntos de nós, agrupe os nós em conjuntos lógicos, por exemplo, partições no Slurm.
  2. Para criar ficheiros de anfitrião, crie um ficheiro de anfitrião separado para cada conjunto de nós, indicando os nomes de anfitrião e o número de GPUs por nó. O número de espaços que especifica depende do número de GPUs do seu tipo de VM A3. Por exemplo, as VMs a3-highgpu-8g têm 8 GPUs, pelo que tem de especificar slots=8.
  3. Para executar testes de referência, execute o teste de referência all_reduce_perf em relação a 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 o seguinte:

    • HOSTFILE_NAME: o nome do ficheiro de anfitriões 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 iniciar em todos os anfitriões no conjunto de nós.
    • NUM_GPUS_PER_NODE: o número de GPUs por nó. Para todos os tipos de máquinas A3, este valor é 8.
  4. Para analisar os resultados, se uma tarefa ficar suspensa ou apresentar uma largura de banda do barramento significativamente inferior (busbw) num conjunto de nós específico, é provável que esse conjunto esteja com defeito.
  5. Para subdividir, se um conjunto de nós estiver com defeito, divida o respetivo ficheiro de anfitrião em dois e repita o teste para restringir a pesquisa binária até identificar o nó individual com comportamento incorreto.

Analise os registos da NCCL

Se o método de referência não identificar um nó, analise os registos detalhados da NCCL.

  1. Para ativar o registo de depuração, defina as seguintes variáveis de ambiente na sessão de shell onde planeia executar a 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 onde quer armazenar os registos.

    Definir NCCL_DEBUG_FILE com %h e %p cria ficheiros de registo únicos e não intercalados para cada processo.

    Se executar uma carga de trabalho de vários nós com o mpirun, propague estas variáveis para todos os nós com a sinalização -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 ficheiros de registo:
    grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \
      | sort | head -n 20
              

    Substitua LOG_DIRECTORY pelo diretório onde os seus registos estão armazenados.

  3. Para contabilizar as operações coletivas, um nó atrasado conclui menos operações coletivas. Contagem de "opCount" entradas para classificações suspeitas:
    grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l
              

    Substitua o seguinte:

    • LOG_DIRECTORY: o diretório onde os registos estão armazenados
    • HOSTNAME: o nome do anfitrião do nó
    • PID: o ID do processo do processo NCCL
  4. Para recolher mais dados de registo antes de uma tarefa ser anulada, aumente temporariamente o limite de tempo da transferência de dados:
    export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
            

Monitorize a limitação térmica da GPU

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

Usar o nvidia-smi

Para verificar a temperatura atual e o estado de limitação de todas as GPUs num 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á a ser limitada devido a temperaturas elevadas.

Usar o dcgmi

O conjunto de diagnósticos 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 secção Thermal indica que ocorreu uma violação térmica durante o teste. Se uma violação térmica for acompanhada por limitação do relógio, é provável que a GPU esteja a sobreaquecer e requer uma investigação adicional.

Erros de Xid

Depois de criar uma VM com GPUs anexadas, tem de instalar os controladores do dispositivo NVIDIA nas VMs com GPU para que as suas aplicações possam aceder às GPUs. No entanto, por vezes, estes controladores devolvem mensagens de erro.

Uma mensagem Xid é um relatório de erro do controlador NVIDIA que é impresso no registo do kernel do sistema operativo ou no registo de eventos da sua VM Linux. Estas mensagens são colocadas no ficheiro /var/log/messages. Para mais informações sobre as mensagens Xid, incluindo potenciais causas, consulte a documentação da NVIDIA.

Como a Google processa erros Xid

A Google usa verificações de funcionamento passivas para avaliar os sistemas de GPU. Se for indicada a substituição de hardware, a Google inicia automaticamente a manutenção de emergência. A Google deteta erros Xid e envia proativamente as máquinas para reparação quando os códigos de erro indicam uma elevada probabilidade de falha de hardware, como Xid 74, 79 e 140. Para alguns códigos Xid, uma vez que podem ser causados por problemas de software ou hardware, a Google usa a correspondência de padrões para acionar reparações, pelo que nem todas as ocorrências resultam numa reparação automática.

Tipos de erros Xid

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

  • Erros da aplicação: indicam problemas no código da aplicação. Os erros de aplicação incluem Xids como Xid 13, 31, 94, 95 e 137, que indicam vários tipos de violação de acesso à memória, semelhantes a uma falha de segmentação. Estes não indicam um erro de ECC. Para resolver estes erros, a NVIDIA recomenda que use uma das seguintes abordagens de depuração:

    • Depuração direta: execute a aplicação diretamente em cuda-gdb ou execute a ferramenta Compute Sanitizer memcheck.
    • Depuração pós-exceção: execute a aplicação com CUDA_DEVICE_WAITS_ON_EXCEPTION=1. Quando ocorre uma exceção, o controlador da GPU bloqueia o estado da aplicação sem sair, para que possa anexar um depurador mais tarde (cuda-gdb -p <PID>) para inspecionar o rastreio de pilha em direto.
  • Erros do controlador: indicam problemas causados pelo controlador da GPU NVIDIA. Para resolver estes erros, certifique-se de que está a usar a versão mais recente do controlador NVIDIA. A Google monitoriza estes erros e colabora com a NVIDIA em correções de controladores.

  • Erros recuperáveis de firmware ou hardware: estes indicam erros de firmware ou hardware que permitem a recuperação sem substituição de hardware. Para resolver estes erros, aplique medidas de recuperação manuais, como repor 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) (aplicáveis a Xids, como Xid 48, 63 e 64) que indicam várias fases de deteçã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.

Reveja as mensagens do Xid

Para diagnosticar rapidamente o motivo pelo qual uma carga de trabalho da GPU falhou, deixou de responder ou sofreu uma degradação do desempenho, verifique os registos do kernel da instância (dmesg ou /var/log/kern.log) para ver códigos de erro numéricos NVIDIA Xid.

A revisão das tabelas de erros de Xid nas seguintes subsecções ajuda imediatamente a:

  • Identificar a causa principal: identifique se a falha é causada por um erro da aplicação (como acesso ilegal à memória), um conflito de controladores ou uma falha de hardware físico (como erros de memória ECC de dois bits).
  • Determine a propriedade operacional: verifique que medidas de recuperação manual imediatas tem de aplicar, como repor GPUs, reiniciar VMs ou executar depuradores, em comparação com as ações de reparação automatizadas e substituição de hardware que a Google está a gerir ativamente no anfitrião.
  • Tome as medidas de recuperação corretas: evite procedimentos de resolução de problemas desnecessários e saiba precisamente quando a recuperação manual é suficiente em comparação com quando tem de comunicar que o anfitrião está com defeito. Por vezes, a recuperação manual não é suficiente, por exemplo, se a origem do erro estiver na cache da GPU (SRAM), que não pode ser remapeada, indicada por Xid 48 com SRAM Threshold Exceeded=Yes, ou se a GPU tiver esgotado o respetivo banco de remapeamento, indicado por Xid 64: All reserved rows for bank are remapped. Nestes casos, a Google deteta que a GPU é elegível para substituição de hardware e envia proativamente a máquina para reparação. Se as suas cargas de trabalho encontrarem erros recorrentes ou se observar falhas de memória repetidas, pode comunicar o anfitrião com falhas para iniciar a reparação ou a substituição automática. Para o GKE, consulte o artigo Como denunciar anfitriões com falhas no GKE.

Tratamento de Xid

As secções seguintes agrupam as mensagens de erro Xid comuns por categoria técnica, juntamente com as respetivas resoluções e responsabilidades autorizadas:

Erros de memória da GPU

A memória de GPU é a memória disponível numa GPU que pode ser usada para o armazenamento temporário de dados. A memória da GPU está protegida com o código de correção de erros (ECC), que deteta e corrige erros de bit único (SBE) e deteta e comunica erros incorrigíveis de dois bits (DBE).

Espera-se que estes erros de memória ocorram ao longo da vida útil de uma GPU. Antes do lançamento das GPUs NVIDIA A100, a retirada dinâmica de páginas era compatível. Para as GPUs NVIDIA A100 e versões posteriores (como a NVIDIA H100), é introduzida a correção de erros de remapeamento de linhas para erros de HBM (DRAM). O ECC está ativado por predefinição e a Google recomenda vivamente que o mantenha ativado.

A tabela seguinte apresenta os erros de memória da GPU comuns e as respetivas resoluções sugeridas:

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

Foi detetado um erro de memória de dois bits (não corrigível) pelo ECC. Este erro interrompe sempre a carga de trabalho em execução e gera o Xid 48.

  1. Pare as suas cargas de trabalho.
  2. Consoante o seu ambiente, reponha as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

A Google monitoriza quando a GPU é elegível para substituição de hardware, por exemplo, se o banco de remapeamento de HBM estiver esgotado ou se a GPU exceder o respetivo limite de erros de SRAM durante a vida útil, e envia proativamente a máquina para reparação para substituir a GPU.

Xid 63: ECC page retirement or row remapping recording event

Indica que foi registado um evento de retirada de página dinâmica ou de remapeamento de linha devido a um erro de memória.

  1. Pare as suas cargas de trabalho.
  2. Consoante o seu ambiente, reponha as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

A Google monitoriza os limites de erros e envia a máquina para reparação quando a GPU requer reparação ou substituição física.

Xid 64: ECC page retirement or row remapper recording failure

Além disso, a mensagem contém as seguintes informações:

Xid 64: All reserved rows for bank are remapped
  1. Pare as suas cargas de trabalho.
  2. Dependendo do seu ambiente, reponha as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

Quando o banco de remapeamento está esgotado (All reserved rows for bank are remapped), a Google deteta que a GPU é elegível para substituição de hardware e envia proativamente a máquina para reparação.

Se receber, pelo menos, duas das seguintes mensagens Xid em conjunto:

  • Xid 48
  • Xid 63
  • Xid 64

E a mensagem contém as seguintes informações:

Xid XX: row remap pending
  1. Pare as suas cargas de trabalho.
  2. Consoante o seu ambiente, reponha as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:

A Google envia a máquina para reparação se o banco de remapeamento estiver esgotado ou quando a GPU precisar de reparação ou substituição física.

Xid 92: High single-bit ECC error rate Esta mensagem Xid é devolvida depois de o controlador da GPU corrigir um erro corrigível e não deve afetar as suas cargas de trabalho. Esta mensagem Xid é meramente informativa. Não é necessária nenhuma ação.

Nenhum

Xid 94: Contained error

Indica que ocorreu um erro de GPU e se o erro estava contido numa única aplicação.

Por si só, o Xid 94 não indica a causa principal do erro. Tem de ser interpretado juntamente com outros erros Xid simultâneos para determinar a causa fundamental.

  1. Uma vez que o erro estava contido numa única aplicação, reinicie a aplicação para recuperar.
  2. Se necessário, reponha as GPUs ou pare as suas cargas de trabalho.
  3. Investigue outros erros de Xid que ocorram em simultâneo para ver mais passos de recuperação e determinar a causa principal.

Nenhum

Xid 95: Uncontained error

Indica que ocorreu um erro de GPU e não estava contido numa única aplicação.

Por si só, o Xid 95 não indica a causa principal do erro. Tem de ser interpretado juntamente com outros erros Xid simultâneos para determinar a causa fundamental.

  1. Uma vez que o erro não foi contido, pare as cargas de trabalho e repita as GPUs ou reinicie a VM para recuperar.
  2. Investigue outros erros Xid que ocorram em simultâneo para determinar a causa principal subjacente e os passos de recuperação adicionais.

Nenhum

Erros do GSP

Um processador do sistema da GPU (GSP) é um microcontrolador que é executado em GPUs e processa algumas das funções de gestão de hardware de baixo nível.

Mensagem de erro Xid Ação do cliente Ação Google
Xid 119: GSP RPC timeout
  1. Pare as suas cargas de trabalho.
  2. Consulte os ramos de controladores NVIDIA recomendados para garantir que está a usar um ramo compatível e uma versão recente ou mais recente do controlador, uma vez que os erros de controladores em versões anteriores são uma causa importante de erros de GSP.
  3. Se o erro persistir depois de verificar ou atualizar o controlador, elimine e recrie a VM. Se o erro continuar, recolha o relatório de erro da NVIDIA e apresente um registo ao Cloud Customer Care.

Nenhum. Se o erro persistir e apresentar um registo de apoio ao cliente, a Google investiga o estado do hardware ou do controlador através do fluxo de trabalho de apoio técnico.

Xid 120: GSP error

Erros de acesso ilegal à memória

Os seguintes Xids são devolvidos quando as aplicações têm falhas de acesso ilegal à memória:

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

Xid 13: Graphics Engine Exception

Xid 31: GPU memory page fault

Xid 137: Memory access fault

Foi detetada uma violação de acesso à memória, análoga a uma falha de segmentação. Normalmente, estes erros indicam um erro de aplicação em que a memória da GPU é acedida fora dos limites ou em buffers libertados, como a desreferenciação de um ponteiro inválido ou uma matriz fora dos limites. Estes não representam erros de ECC, a menos que o Xid 48 também esteja presente.

Para resolver este problema, depure as falhas de acesso à memória na sua aplicação. Pode usar o cuda-gdb, o Compute Sanitizer ou o cuda-memcheck.

Para mais detalhes, consulte a documentação do NVIDIA Xid.

Nenhum. Em casos raros em que a degradação do hardware pode causar erros de acesso ilegal à memória comunicados falsamente, pode usar o NVIDIA Data Center GPU Manager (DCGM) para executar o dcgmi diag -r 3 ou o dcgmi diag -r 4 para diferentes níveis de cobertura e duração do teste. Se identificar um problema de hardware, apresente um registo junto ao apoio ao cliente.

Outras mensagens de erro Xid comuns

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

Nenhum

Xid 79: GPU has fallen off the bus

Isto significa que o controlador não consegue comunicar com a GPU porque um problema de hardware fez com que a GPU desaparecesse do barramento PCI.

Para recuperar as suas cargas de trabalho, use uma das seguintes abordagens, consoante a manutenção de emergência esteja ou não ativada para o seu projeto:

  • Peça uma manutenção de emergência: se a manutenção de emergência for implementada no seu projeto, acione o evento de manutenção quando lhe for mais conveniente.
  • Aguarde pela manutenção automática: Caso contrário, aguarde por um evento de manutenção não planeado diretamente na instância.

A Google deteta que a GPU se desligou do barramento PCI e envia a máquina para reparação.

Xid 109: Context switch timeout

O Xid 109 é um erro genérico comunicado pelo controlador da GPU NVIDIA, gerado quando uma instância da GPU não consegue antecipar ou mudar de tarefas dentro do período de limite de tempo esperado.

A Google tem um longo historial de investigação do Xid 109 com a NVIDIA, e as causas conhecidas de erros de controladores foram corrigidas nos controladores mais recentes. O Xid 109 não é causado por um problema de hardware.

  1. Pare as suas cargas de trabalho.
  2. Consoante o seu ambiente, reponha as GPUs ou reinicie a VM para recuperar e retomar as cargas de trabalho:
  3. Considere atualizar para uma versão mais recente do controlador NVIDIA para o seu ambiente, como instalar o controlador mais recente na VM do Compute Engine ou atualizar o conjunto de nós/DaemonSet do controlador do GKE.

Nenhum

Xid 149 que mencione 0x02a, como no seguinte exemplo:
Xid (PCI:0000:c0:00): 149,NETIR_LINK_EVT Fatal XC0 i0 Link 04 (0x02a485c6 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000)

Isto indica um problema conhecido que afeta o firmware das GPUs NVIDIA B200.

  1. Pare as suas cargas de trabalho.
  2. Reponha as GPUs.

Nenhum

Resolva problemas de nvidia-smi falhas após a aplicação de patches ao SO ou a atualização do kernel

Se o nvidia-smi falhar com o NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver após um período de manutenção, uma execução de aplicação de patches do SO ou um reinício da VM, verifique os bloqueios de pacotes do kernel. Os bloqueios de pacotes de uma instalação de controladores anterior no modo binary podem impedir a instalação de cabeçalhos de kernel correspondentes.

Para diagnosticar e resolver este problema, selecione o seu sistema operativo:

Ubuntu

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

    uname -r
    
  2. Verifique se uma instalação anterior do controlador no modo binary bloqueou os pacotes do kernel, como quando 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 é apresentado.

  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 pacotes:

    sudo apt-mark unhold linux-image-gcp linux-headers-gcp
    
  5. Instale os cabeçalhos do kernel para o kernel em execução:

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)
    
  6. Reconstrua e carregue o módulo de kernel da NVIDIA:

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

      sudo dkms autoinstall
      sudo modprobe nvidia
      nvidia-smi
      
    • Se o comando sudo dkms status não mostrar nenhum módulo NVIDIA registado (por exemplo, se o controlador tiver sido instalado anteriormente através de um binário .run sem --dkms), execute novamente o Google Cloud instalador do controlador da GPU:

      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 controlador no modo binary bloqueou os pacotes do kernel, como quando usa --force-version, --installation-branch=lts ou instâncias de computação da NVIDIA RTX Virtual Workstation (vWS):

    apt-mark showhold
    

    Verifique se o linux-image-cloud-amd64 ou o linux-headers-cloud-amd64 é apresentado.

  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 pacotes:

    sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64
    
  5. Instale os cabeçalhos do kernel para o kernel em execução:

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)
    
  6. Reconstrua e carregue o módulo de kernel da NVIDIA:

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

      sudo dkms autoinstall
      sudo modprobe nvidia
      nvidia-smi
      
    • Se sudo dkms status não mostrar nenhum módulo NVIDIA registado (por exemplo, se o controlador tiver sido instalado anteriormente através de um ficheiro binário .run sem --dkms), volte a executar o Google Cloud instalador do controlador de GPU:

      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 controlador no modo binary bloqueou os pacotes do kernel, como quando usa --force-version, --installation-branch=lts ou instâncias de computação da 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 estiverem excluídos, remova kernel* da linha exclude= em /etc/dnf/dnf.conf.

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

    sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)
    
  6. Reconstrua e carregue o módulo de kernel da NVIDIA:

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

      sudo dkms autoinstall
      sudo modprobe nvidia
      nvidia-smi
      
    • Se o comando sudo dkms status não mostrar nenhum módulo NVIDIA registado (por exemplo, se o controlador tiver sido instalado anteriormente através de um binário .run sem --dkms), execute novamente o Google Cloud instalador do controlador da GPU:

      sudo python3 cuda_installer.pyz install_driver
      

Resolução de problemas do Arranque seguro

Se instalar o controlador NVIDIA numa instância de computação com o Arranque seguro ativado e nvidia-smi não conseguir comunicar com o controlador NVIDIA, o Arranque seguro pode impedir o carregamento do módulo de kernel não assinado.

Para diagnosticar e resolver este problema, conclua os seguintes passos:

  1. Verifique se o Arranque seguro rejeitou o módulo de kernel devido a uma assinatura em falta ou inválida:

    sudo dmesg | grep -iE 'secure boot|nvidia'
    
  2. Se o arranque seguro bloqueou o módulo, assine manualmente os módulos de controlador e inscreva a sua chave de proprietário do computador (MOK) ou use uma imagem do SO com módulos do kernel pré-assinados. Para ver instruções, consulte o artigo Instale controladores de GPU (VMs de arranque seguro).

Reponha as GPUs

Alguns problemas podem exigir que reponha as GPUs. Para repor as GPUs, conclua os seguintes passos:

  • 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), conclua os seguintes passos:
    1. Elimine 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 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 pode usar a gpu-reset-tool para automatizar a reposição de todas as GPUs num nó. Esta ferramenta só requer que especifique o nome do nó de destino.

Em alternativa, as GPUs também são repostas sempre que repõe uma VM ou para e reinicia uma VM. Para mais informações sobre os estados do ciclo de vida das VMs e as diferenças entre as ações de recuperação de VMs, consulte os artigos Ciclo de vida da instância do Compute Engine e Suspenda, pare ou reponha as instâncias do Compute Engine.

Abra um registo de apoio ao cliente

Se não conseguir resolver os problemas através das orientações nesta página, reúna as seguintes informações e abra um registo de apoio técnico:

  • ID do projeto onde 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 através da resolução de problemas.
  • Registos NCCL completos e não intercalados com as definições de depuração ativadas.
  • Resultados das verificações de saúde do hardware (dcgmi, nvidia-smi).
  • Comando de carga de trabalho ou teste de referência exato que está a falhar.
  • Ficheiros de registo relevantes, como registos do motor anfitrião e de diagnóstico. Para recolher estas informações, execute gather-dcgm-logs.sh, localizado em /usr/local/dcgm/scripts nas instalações predefinidas.
  • Relatório de erro da NVIDIA. Executar nvidia-bug-report.sh. Para GPUs Blackwell, siga o artigo Gere um relatório de erro da NVIDIA para GPUs Blackwell.
  • Detalhes sobre quaisquer alterações recentes feitas ao seu ambiente antes da falha.

O que se segue?

Reveja os tipos de máquinas com GPU.