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.
- Para identificar os seus conjuntos de nós, agrupe os nós em conjuntos lógicos, por exemplo, partições no Slurm.
- 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-8gtêm 8 GPUs, pelo que tem de especificarslots=8. - Para executar testes de referência, execute o teste de referência
all_reduce_perfem 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_NODESubstitua 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.
- 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. - 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.
- 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
DefinirLOG_DIRECTORYpelo diretório onde quer armazenar os registos.NCCL_DEBUG_FILEcom%he%pcria 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 ... - 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 20Substitua
LOG_DIRECTORYpelo diretório onde os seus registos estão armazenados. - 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 -lSubstitua o seguinte:
LOG_DIRECTORY: o diretório onde os registos estão armazenadosHOSTNAME: o nome do anfitrião do nóPID: o ID do processo do processo NCCL
- 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 48comSRAM Threshold Exceeded=Yes, ou se a GPU tiver esgotado o respetivo banco de remapeamento, indicado porXid 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 (Xids
48,63,64,92,94,95) - Erros do processador do sistema da GPU (GSP) (Xids
119e120) - Erros de acesso ilegal à memória (Xids
13,31e137) - Outras mensagens de erro Xid comuns (Xids
74,79,109e149)
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. |
|
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. |
|
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
|
|
Quando o banco de remapeamento está esgotado
( |
Se receber, pelo menos, duas das seguintes mensagens Xid em conjunto:
E a mensagem contém as seguintes informações: Xid XX: row remap pending
|
|
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. |
|
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. |
|
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 |
|
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 |
|---|---|---|
|
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 |
Outras mensagens de erro Xid comuns
| Mensagem de erro Xid | Ação do cliente | Ação Google |
|---|---|---|
Xid 74: NVLINK error |
|
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:
|
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. |
|
Nenhum |
Xid 149 que mencione 0x02a, como no
seguinte exemplo:
Isto indica um problema conhecido que afeta o firmware das GPUs NVIDIA B200. |
|
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
Verifique a versão do kernel em execução:
uname -rVerifique se uma instalação anterior do controlador no modo
binarybloqueou os pacotes do kernel, como quando usa instâncias de computação--force-version,--installation-branch=ltsou NVIDIA RTX Virtual Workstation (vWS):apt-mark showholdVerifique se
linux-image-gcpoulinux-headers-gcpé apresentado.Verifique se os cabeçalhos do kernel estão instalados para o kernel em execução:
dpkg -l | grep "linux-headers-$(uname -r)"Se os metapacotes do kernel estiverem retidos, remova os bloqueios de pacotes:
sudo apt-mark unhold linux-image-gcp linux-headers-gcpInstale os cabeçalhos do kernel para o kernel em execução:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)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-smiSe o comando
sudo dkms statusnão mostrar nenhum módulo NVIDIA registado (por exemplo, se o controlador tiver sido instalado anteriormente através de um binário.runsem--dkms), execute novamente o Google Cloud instalador do controlador da GPU:sudo python3 cuda_installer.pyz install_driver
Debian
Verifique a versão do kernel em execução:
uname -rVerifique se uma instalação anterior do controlador no modo
binarybloqueou os pacotes do kernel, como quando usa--force-version,--installation-branch=ltsou instâncias de computação da NVIDIA RTX Virtual Workstation (vWS):apt-mark showholdVerifique se o
linux-image-cloud-amd64ou olinux-headers-cloud-amd64é apresentado.Verifique se os cabeçalhos do kernel estão instalados para o kernel em execução:
dpkg -l | grep "linux-headers-$(uname -r)"Se os metapacotes do kernel estiverem retidos, remova os bloqueios de pacotes:
sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64Instale os cabeçalhos do kernel para o kernel em execução:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)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-smiSe
sudo dkms statusnão mostrar nenhum módulo NVIDIA registado (por exemplo, se o controlador tiver sido instalado anteriormente através de um ficheiro binário.runsem--dkms), volte a executar o Google Cloud instalador do controlador de GPU:sudo python3 cuda_installer.pyz install_driver
RHEL e Rocky Linux
Verifique a versão do kernel em execução:
uname -rVerifique se uma instalação anterior do controlador no modo
binarybloqueou os pacotes do kernel, como quando usa--force-version,--installation-branch=ltsou instâncias de computação da NVIDIA RTX Virtual Workstation (vWS):grep "^exclude=.*kernel" /etc/dnf/dnf.confVerifique se os cabeçalhos do kernel estão instalados para o kernel em execução:
rpm -qa | grep "kernel-devel-$(uname -r)"Se os pacotes do kernel estiverem excluídos, remova
kernel*da linhaexclude=em/etc/dnf/dnf.conf.Instale os cabeçalhos do kernel para o kernel em execução:
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)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-smiSe o comando
sudo dkms statusnão mostrar nenhum módulo NVIDIA registado (por exemplo, se o controlador tiver sido instalado anteriormente através de um binário.runsem--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:
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'
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:
- 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-smiestá localizado no diretório/var/lib/nvidia/bin. - Para nós do GKE, o executável
nvidia-smiestá localizado no diretório/home/kubernetes/bin/nvidia.
- Para a maioria das VMs Linux, o executável
- 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/scriptsnas 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.