이 가이드에서는 하드웨어 오류 및 성능 병목 현상을 포함하여 GPU가 연결된 Compute Engine VM의 일반적인 문제를 진단하고 해결하는 방법을 설명합니다.
NVIDIA DCGM을 사용하여 GPU VM 문제 해결
NVIDIA Data Center GPU Manager(DCGM)는 클러스터 환경에서 NVIDIA 데이터 센터 GPU를 관리하고 모니터링하기 위한 도구 모음입니다.
DCGM을 사용하여 GPU 환경의 문제를 해결하려면 다음 단계를 완료하세요.
- VM에 연결된 GPU 모델에 권장되는 최신 NVIDIA 드라이버를 사용하고 있는지 확인합니다. 드라이버 버전을 검토하려면 권장되는 NVIDIA 드라이버 버전을 참조하세요.
- 최신 버전의 DCGM이 설치되어 있는지 확인합니다. 최신 버전을 설치하려면 DCGM 설치를 참고하세요.
문제 진단
dcgmi 진단 명령어를 실행하면 진단 도구에서 보고하는 문제에 문제 해결을 위한 다음 단계가 포함됩니다. 다음 예에서는 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
}
]
}
.........
위의 출력 스니펫에서 GPU 0에 복구 불가능한 오류로 인한 대기 중인 페이지 중단이 있음을 확인할 수 있습니다. 출력에는 고유한 error_id와 문제 디버깅에 관한 조언이 제공되어 있습니다. 이 예시 출력의 경우 GPU를 드레이닝하고 VM을 재부팅하는 것이 좋습니다. 대부분의 경우 출력의 이 섹션에 있는 안내를 따르면 문제를 해결할 수 있습니다.
A3 VM의 GPU 성능 문제 해결
A3 머신 시리즈는 NVIDIA H200 또는 H100 GPU가 연결된 상태로 제공됩니다. 이 시리즈에는 A3 Ultra(H200), A3 Mega(H100), A3 High(H100), A3 Edge (H100) 머신 유형이 포함됩니다.
결함이 있는 노드 식별
다중 노드 GPU 클러스터에서 대규모 학습 또는 벤치마크 작업이 응답을 중지하거나 성능이 저하될 수 있습니다. 이는 하나 이상의 노드가 성능이 저하되어 전체 작업 속도가 느려지기 때문에 발생하는 경우가 많습니다. 이 섹션에서는 NCCL 벤치마크 테스트를 실행하거나 NCCL 로그를 분석하여 결함이 있는 노드 또는 호스트 머신을 식별하는 방법을 설명합니다.
NCCL 벤치마크 테스트 실행
실패를 일으키는 노드 그룹을 식별하려면 all_reduce_perf와 같은 NCCL 벤치마크를 사용하여 클러스터의 하위 집합을 체계적으로 테스트합니다.
- 노드 집합을 식별하려면 노드를 논리적 집합(예: Slurm의 파티션)으로 그룹화합니다.
- 호스트 파일을 만들려면 각 노드 세트에 대해 별도의 호스트 파일을 만들어 호스트 이름과 노드당 GPU 수를 나열합니다. 지정하는 슬롯 수는 A3 VM 유형의 GPU 수에 따라 다릅니다. 예를 들어
a3-highgpu-8gVM에는 GPU가 8개 있으므로slots=8을 지정해야 합니다. - 벤치마크를 실행하려면 각 노드 세트에 대해 개별적으로
all_reduce_perf벤치마크를 실행합니다.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다음을 바꿉니다.
HOSTFILE_NAME: 노드 목록과 노드 세트의 노드당 GPU 수가 포함된 호스트 파일의 이름입니다.TOTAL_PROCESSES: 노드 집합의 모든 호스트에서 실행할 총 MPI 프로세스 수입니다.NUM_GPUS_PER_NODE: 노드당 GPU 수입니다. 모든 A3 머신 유형의 경우 이 값은8입니다.
- 결과를 분석하려면 작업이 중단되거나 특정 노드 집합에서 버스 대역폭 (
busbw)이 현저히 낮으면 해당 집합에 결함이 있을 수 있습니다. - 하위 분할하려면 노드 세트에 결함이 있는 경우 호스트 파일을 절반으로 나누고 다시 테스트하여 개별 오작동 노드를 정확히 찾아낼 때까지 이진 검색 범위를 좁힙니다.
NCCL 로그 분석
벤치마크 메서드에서 노드를 정확히 파악하지 못하면 자세한 NCCL 로그를 분석하세요.
- 디버그 로깅을 사용 설정하려면 워크로드를 실행할 셸 세션에서 다음 환경 변수를 설정합니다.
export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=INIT,NET,COLL export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"LOG_DIRECTORY을 로그를 저장할 디렉터리로 바꿉니다.%h및%p로NCCL_DEBUG_FILE를 설정하면 각 프로세스에 대해 고유하고 인터리브 처리되지 않은 로그 파일이 생성됩니다.mpirun를 사용하여 멀티 노드 워크로드를 실행하는 경우-x플래그를 사용하여 이러한 변수를 모든 노드에 전파합니다. 예를 들면 다음과 같습니다.mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ... - 첫 번째 오류를 찾으려면 다음 명령어를 사용하여 모든 로그 파일에서 가장 빠른 타임아웃 또는 실패 이벤트를 찾습니다.
grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \ | sort | head -n 20LOG_DIRECTORY을 로그가 저장된 디렉터리로 바꿉니다. - 수집 작업을 계산하기 위해 느린 노드는 수집 작업을 더 적게 완료합니다. 의심스러운 순위의
"opCount"항목 수:grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l다음을 바꿉니다.
LOG_DIRECTORY: 로그가 저장된 디렉터리HOSTNAME: 노드의 호스트 이름PID: NCCL 프로세스의 프로세스 ID
- 작업이 중단되기 전에 로깅 데이터를 더 많이 수집하려면 데이터 전송 제한 시간을 일시적으로 늘리세요.
export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
GPU 열 조절 모니터링
A3 시리즈 VM은 부하가 걸린 상태에서 지속적으로 87°C를 초과하는 온도에 도달하면 성능이 저하될 수 있습니다. 클러스터의 노드에서 GPU 열 제한을 확인하려면 nvidia-smi 또는 dcgmi를 사용합니다.
nvidia-smi 사용
노드에 있는 모든 GPU의 현재 온도와 제한 상태를 확인하려면 다음 명령어를 실행합니다.
nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
출력에서 clocks_throttle_reasons.hw_slowdown 열의 Active 값은 고온으로 인해 GPU가 제한되고 있음을 나타냅니다.
dcgmi 사용
NVIDIA 데이터 센터 GPU Manager (DCGM) 진단 도구 모음에는 열 위반 검사가 포함되어 있습니다. 수준 1 진단을 실행하려면 다음 명령어를 실행합니다.
dcgmi diag -r 1
Thermal 섹션의 Warn 또는 Fail 결과는 테스트 중에 열 위반이 발생했음을 나타냅니다. 열 위반에 클록 제한이 수반되는 경우 GPU가 과열되었을 가능성이 높으며 추가 조사가 필요합니다.
Xid 오류
GPU가 연결된 VM을 만든 후에는 애플리케이션에서 GPU에 액세스할 수 있도록 GPU VM에 NVIDIA 기기 드라이버를 설치해야 합니다. 하지만 이러한 드라이버에서 오류 메시지를 반환하는 경우가 있습니다.
Xid 메시지는 Linux VM의 운영체제 커널 로그나 이벤트 로그에 출력되는 NVIDIA 드라이버의 오류 보고서입니다. 이러한 메시지는 /var/log/messages 파일에 저장됩니다. 가능한 원인을 포함한 Xid 메시지에 대한 자세한 내용은 NVIDIA 문서를 참조하세요.
Google에서 Xid 오류를 처리하는 방법
Google은 수동 상태 점검을 사용하여 GPU 시스템을 평가합니다. 하드웨어 교체가 표시되면 Google에서 자동으로 긴급 유지관리를 시작합니다. Google에서는 Xid 오류를 감지하고 오류 코드가 하드웨어 장애 가능성이 높음을 나타내는 경우(예: Xid 74, 79, 140) 선제적으로 기기를 수리하도록 보냅니다. 일부 Xid 코드는 소프트웨어 또는 하드웨어 문제로 인해 발생할 수 있으므로 Google은 패턴 일치를 사용하여 복구를 트리거하므로 모든 발생이 자동 복구로 이어지지는 않습니다.
Xid 오류 유형
다음 목록에서는 Xid 오류의 세 가지 주요 카테고리와 권장 복구 작업을 설명합니다.
애플리케이션 오류: 애플리케이션 코드 내부의 문제를 나타냅니다. 애플리케이션 오류에는 세그먼트 오류와 유사한 다양한 유형의 메모리 액세스 위반을 나타내는 Xid 13, 31, 94, 95, 137과 같은 Xid가 포함됩니다. 이는 ECC 오류를 나타내지 않습니다. 이러한 오류를 해결하기 위해 NVIDIA에서는 다음 디버깅 접근 방식 중 하나를 사용할 것을 권장합니다.
- 직접 디버깅: cuda-gdb에서 애플리케이션을 직접 실행하거나 컴퓨팅 Sanitizer memcheck 도구를 실행합니다.
- 예외 후 디버깅:
CUDA_DEVICE_WAITS_ON_EXCEPTION=1로 애플리케이션을 실행합니다. 예외가 발생하면 GPU 드라이버가 종료하지 않고 애플리케이션 상태를 고정하므로 나중에 디버거 (cuda-gdb -p <PID>)를 연결하여 라이브 스택 트레이스를 검사할 수 있습니다.
드라이버 오류: NVIDIA GPU 드라이버로 인해 발생하는 문제를 나타냅니다. 이러한 오류를 해결하려면 최신 NVIDIA 드라이버 버전을 사용 중인지 확인하세요. Google은 이러한 오류를 모니터링하고 NVIDIA와 협력하여 드라이버를 수정합니다.
펌웨어 또는 하드웨어 복구 가능 오류: 하드웨어 교체 없이 복구할 수 있는 펌웨어 또는 하드웨어 오류를 나타냅니다. 이러한 오류를 해결하려면 GPU 재설정이나 인스턴스 재부팅과 같은 수동 복구 조치를 적용하세요. 펌웨어 또는 하드웨어 복구 가능 오류에는 ECC 오류를 감지하고 완화하는 다양한 단계를 나타내는 오류 정정 코드 (ECC) 오류 (Xid 48, 63, 64와 같은 Xid에 적용됨)가 포함됩니다. 페이지 사용 중지 및 ECC 오류 완화에 대한 자세한 내용은 NVIDIA의 동적 페이지 사용 중지 FAQ를 참조하세요.
Xid 메시지 검토
GPU 워크로드가 실패하거나, 응답을 중지하거나, 성능 저하가 발생한 이유를 빠르게 진단하려면 인스턴스의 커널 로그 (dmesg 또는 /var/log/kern.log)에서 숫자 NVIDIA Xid 오류 코드를 확인하세요.
다음 하위 섹션의 Xid 오류 표를 검토하면 즉시 도움이 됩니다.
- 근본 원인 파악: 오류가 애플리케이션 버그 (예: 잘못된 메모리 액세스), 드라이버 충돌 또는 물리적 하드웨어 오류 (예: 이중 비트 ECC 메모리 오류)로 인해 발생했는지 확인합니다.
- 운영 소유권 결정: GPU 재설정, VM 재부팅, 디버거 실행과 같이 즉시 적용해야 하는 수동 복구 조치와 Google이 호스트에서 적극적으로 관리하는 자동 복구 및 하드웨어 교체 작업을 확인합니다.
- 올바른 복구 단계 수행: 불필요한 문제 해결 절차를 피하고 수동 복구로 충분한 경우와 호스트를 결함이 있는 것으로 보고해야 하는 경우를 정확하게 파악합니다. 오류 소스가 GPU 캐시(SRAM)에 있는 경우와 같이 수동 복구가 충분하지 않은 경우가 있습니다. 이는
SRAM Threshold Exceeded=Yes이 있는Xid 48로 표시되며, GPU의 리맵 뱅크가 소진된 경우(Xid 64: All reserved rows for bank are remapped로 표시됨)도 마찬가지입니다. 이러한 경우 Google은 GPU가 하드웨어 교체 대상임을 감지하고 사전에 머신을 수리하도록 전송합니다. 워크로드에 반복적인 오류가 발생하거나 메모리 오류가 반복적으로 관찰되는 경우 결함이 있는 호스트를 신고하여 자동 복구 또는 교체를 시작할 수 있습니다. GKE의 경우 GKE에서 결함이 있는 호스트를 신고하는 방법을 참고하세요.
Xid 처리
다음 섹션에서는 일반적인 Xid 오류 메시지를 기술 카테고리별로 그룹화하고 공신력 있는 해결 방법과 책임을 함께 제공합니다.
- GPU 메모리 오류 (Xid
48,63,64,92,94,95) - GPU 시스템 프로세서 (GSP) 오류 (Xid
119,120) - 잘못된 메모리 액세스 오류 (Xid
13,31,137) - 기타 일반적인 Xid 오류 메시지 (Xid
74,79,109,149)
GPU 메모리 오류
GPU 메모리는 데이터의 임시 저장에 사용할 수 있는 GPU에서 사용 가능한 메모리입니다. GPU 메모리는 단일 비트 오류(SBE)를 감지 및 수정하고 이중 비트 수정 불가능 오류 (DBE)를 감지 및 보고하는 오류 정정 코드 (ECC)로 보호됩니다.
이러한 메모리 오류는 GPU 수명 동안 발생할 수 있습니다. NVIDIA A100 GPU 출시 이전에는 동적 페이지 중단이 지원되었습니다. NVIDIA A100 이후 GPU 출시 버전 (예: NVIDIA H100)에는 HBM (DRAM) 오류에 대한 행 다시 매핑 오류 복구가 도입되었습니다. ECC는 기본적으로 사용 설정되어 있으며 ECC를 사용 설정 상태로 유지하는 것이 좋습니다.
다음 표에는 일반적인 GPU 메모리 오류와 권장 해결 방법이 나와 있습니다.
| Xid 오류 메시지 | 고객 액션 | Google 조치 |
|---|---|---|
Xid 48: Double Bit ECC
ECC에서 이중 비트 (수정 불가) 메모리 오류를 감지했습니다. 이 오류는 항상 실행 중인 워크로드를 중단하고 Xid 48을 생성합니다. |
|
Google에서는 HBM 리맵 뱅크가 소진되었거나 GPU가 수명 SRAM 오류 임계값을 초과하는 등 GPU의 하드웨어 교체가 필요한 시점을 모니터링하고 GPU 교체를 위해 머신을 수리하도록 선제적으로 보냅니다. |
Xid 63: ECC page retirement or row remapping recording
event
메모리 오류로 인해 동적 페이지 사용 중지 또는 행 재매핑 이벤트가 기록되었음을 나타냅니다. |
|
Google에서는 오류 기준점을 모니터링하고 GPU에 물리적 수리 또는 교체가 필요한 경우 머신을 수리하도록 보냅니다. |
Xid 64: ECC page retirement or row remapper recording
failure
그러면 메시지에 다음 정보가 포함됩니다. Xid 64: All reserved rows for bank are remapped
|
|
리매핑 뱅크가 소진되면( |
다음 Xid 메시지 중 최소 2개 이상이 함께 표시되는 경우:
그러면 메시지에 다음 정보가 포함됩니다. Xid XX: row remap pending
|
|
Google은 다시 매핑 뱅크가 소진되거나 GPU에 물리적 수리 또는 교체가 필요한 경우 수리를 위해 머신을 전송합니다. |
Xid 92: High single-bit ECC error rate |
이 Xid 메시지는 GPU 드라이버에서 수정 가능한 오류를 수정한 후에 반환되며 워크로드에 영향을 미치지 않습니다. 이 Xid 메시지는 정보 제공용입니다. 이와 관련해 별도의 조치를 취할 필요는 없습니다. |
없음 |
Xid 94: Contained error
GPU 오류가 발생했는지, 오류가 단일 애플리케이션 내에 포함되었는지를 나타냅니다. Xid 94만으로는 오류의 근본 원인을 나타내지 않습니다. 근본 원인을 파악하려면 동시에 발생하는 다른 Xid 오류와 함께 해석해야 합니다. |
|
없음 |
Xid 95: Uncontained error
GPU 오류가 발생했으며 단일 애플리케이션에 국한되지 않았음을 나타냅니다. Xid 95만으로는 오류의 근본 원인을 알 수 없습니다. 근본 원인을 파악하려면 동시에 발생하는 다른 Xid 오류와 함께 해석해야 합니다. |
없음 |
GSP 오류
GPU 시스템 프로세서(GSP)는 GPU에서 실행되며 일부 하위 수준의 하드웨어 관리 기능을 처리하는 마이크로 컨트롤러입니다.
| Xid 오류 메시지 | 고객 액션 | Google 작업 |
|---|---|---|
Xid 119: GSP RPC timeout |
|
없음 오류가 계속되고 지원 케이스를 제출하면 Google에서 지원 워크플로를 통해 하드웨어 또는 드라이버 상태를 조사합니다. |
Xid 120: GSP error |
잘못된 메모리 액세스 오류
애플리케이션에서 잘못된 메모리 액세스 오류가 발생하면 다음 Xid가 반환됩니다.
| Xid 오류 메시지 | 고객 액션 | Google 조치 |
|---|---|---|
|
세그먼트 오류와 유사한 메모리 액세스 위반이 감지되었습니다. 이러한 오류는 일반적으로 GPU 메모리가 범위를 벗어나 액세스되거나, 잘못된 포인터나 범위를 벗어난 배열을 역참조하는 등 해제된 버퍼에서 액세스되는 애플리케이션 버그를 나타냅니다. Xid 48도 표시되지 않는 한 ECC 오류를 나타내지 않습니다. |
이 문제를 해결하려면 애플리케이션에서 메모리 액세스 오류를 디버그하세요. cuda-gdb, Compute Sanitizer 또는 cuda-memcheck를 사용할 수 있습니다. 자세한 내용은 NVIDIA Xid 문서를 참조하세요. |
없음 하드웨어 성능 저하로 인해 잘못된 메모리 액세스 오류가 잘못 보고될 수 있는 드문 경우 NVIDIA Data Center GPU Manager (DCGM)를 사용하여 다양한 수준의 테스트 범위 및 기간에 대해 |
기타 일반적인 Xid 오류 메시지
| Xid 오류 메시지 | 고객 액션 | Google 작업 |
|---|---|---|
Xid 74: NVLINK error |
|
없음 |
Xid 79: GPU has fallen off the bus
이는 하드웨어 문제로 인해 GPU가 PCI 버스에서 사라졌기 때문에 드라이버가 GPU와 통신할 수 없음을 의미합니다. |
워크로드를 복구하려면 프로젝트에 긴급 유지보수가 사용 설정되어 있는지 여부에 따라 다음 방법 중 하나를 사용합니다.
|
Google은 GPU가 PCI 버스에서 분리된 것을 감지하고 머신을 수리하도록 보냅니다. |
Xid 109: Context switch timeout
Xid 109는 NVIDIA GPU 드라이버에서 보고하는 일반적인 오류로, GPU 인스턴스가 예상 제한 시간 내에 태스크를 선점하거나 전환하지 못할 때 생성됩니다. Google은 NVIDIA와 함께 Xid 109를 조사한 오랜 역사를 가지고 있으며 드라이버 버그로 인한 알려진 원인은 최신 드라이버에서 수정되었습니다. Xid 109는 하드웨어 문제로 인해 발생하지 않습니다. |
|
없음 |
0x02a를 언급하는 Xid 149(예: 다음 예시)
이는 NVIDIA B200 GPU의 펌웨어에 영향을 미치는 알려진 문제를 나타냅니다. |
|
없음 |
OS 패치 또는 커널 업그레이드 후 nvidia-smi 실패 문제 해결
유지보수 기간, OS 패치 실행 또는 VM 재부팅 후 nvidia-smi가 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver로 실패하면 커널 패키지 보류를 확인하세요. binary 모드에서 이전 드라이버 설치의 패키지 잠금으로 인해 일치하는 커널 헤더가 설치되지 않을 수 있습니다.
이 문제를 진단하고 해결하려면 운영체제를 선택하세요.
Ubuntu
실행 중인 커널 버전을 확인합니다.
uname -r--force-version,--installation-branch=lts또는 NVIDIA RTX 가상 워크스테이션 (vWS) 컴퓨팅 인스턴스를 사용할 때와 같이binary모드에서 이전 드라이버 설치로 인해 커널 패키지가 잠겼는지 확인합니다.apt-mark showholdlinux-image-gcp또는linux-headers-gcp가 표시되는지 확인합니다.실행 중인 커널에 커널 헤더가 설치되어 있는지 확인합니다.
dpkg -l | grep "linux-headers-$(uname -r)"커널 메타 패키지가 보류된 경우 패키지 잠금을 삭제합니다.
sudo apt-mark unhold linux-image-gcp linux-headers-gcp실행 중인 커널의 커널 헤더를 설치합니다.
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)NVIDIA 커널 모듈을 다시 빌드하고 로드합니다.
DKMS 모듈 소스가 등록된 경우 (
sudo dkms status확인):sudo dkms autoinstall sudo modprobe nvidia nvidia-smisudo dkms status에 등록된 NVIDIA 모듈이 표시되지 않으면 (예:--dkms없이.run바이너리를 사용하여 드라이버를 이전에 설치한 경우) Google Cloud GPU 드라이버 설치 프로그램을 다시 실행합니다.sudo python3 cuda_installer.pyz install_driver
Debian
실행 중인 커널 버전을 확인합니다.
uname -r--force-version,--installation-branch=lts또는 NVIDIA RTX 가상 워크스테이션 (vWS) 컴퓨팅 인스턴스를 사용할 때와 같이binary모드에서 이전 드라이버 설치로 인해 커널 패키지가 잠겼는지 확인합니다.apt-mark showholdlinux-image-cloud-amd64또는linux-headers-cloud-amd64이 나열되어 있는지 확인합니다.실행 중인 커널에 커널 헤더가 설치되어 있는지 확인합니다.
dpkg -l | grep "linux-headers-$(uname -r)"커널 메타 패키지가 보류된 경우 패키지 잠금을 삭제합니다.
sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64실행 중인 커널의 커널 헤더를 설치합니다.
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)NVIDIA 커널 모듈을 다시 빌드하고 로드합니다.
DKMS 모듈 소스가 등록된 경우 (
sudo dkms status확인):sudo dkms autoinstall sudo modprobe nvidia nvidia-smisudo dkms status에 등록된 NVIDIA 모듈이 표시되지 않는 경우 (예: 이전에--dkms없이.run바이너리를 사용하여 드라이버를 설치한 경우) Google Cloud GPU 드라이버 설치 프로그램을 다시 실행합니다.sudo python3 cuda_installer.pyz install_driver
RHEL 및 Rocky Linux
실행 중인 커널 버전을 확인합니다.
uname -rbinary모드의 이전 드라이버 설치로 인해--force-version,--installation-branch=lts또는 NVIDIA RTX 가상 워크스테이션 (vWS) 컴퓨팅 인스턴스를 사용할 때와 같이 커널 패키지가 잠겼는지 확인합니다.grep "^exclude=.*kernel" /etc/dnf/dnf.conf실행 중인 커널에 커널 헤더가 설치되어 있는지 확인합니다.
rpm -qa | grep "kernel-devel-$(uname -r)"커널 패키지가 제외된 경우
/etc/dnf/dnf.conf의exclude=줄에서kernel*를 삭제합니다.실행 중인 커널의 커널 헤더를 설치합니다.
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)NVIDIA 커널 모듈을 다시 빌드하고 로드합니다.
DKMS 모듈 소스가 등록된 경우 (
sudo dkms status확인):sudo dkms autoinstall sudo modprobe nvidia nvidia-smisudo dkms status에 등록된 NVIDIA 모듈이 표시되지 않는 경우 (예: 이전에--dkms없이.run바이너리를 사용하여 드라이버를 설치한 경우) Google Cloud GPU 드라이버 설치 프로그램을 다시 실행합니다.sudo python3 cuda_installer.pyz install_driver
보안 부트 문제 해결
안전한 부팅이 사용 설정된 컴퓨팅 인스턴스에 NVIDIA 드라이버를 설치하고 nvidia-smi가 NVIDIA 드라이버와 통신하지 못하는 경우 안전한 부팅이 서명되지 않은 커널 모듈의 로드를 차단할 수 있습니다.
이 문제를 진단하고 해결하려면 다음 단계를 완료하세요.
서명이 누락되었거나 잘못되어 보안 부팅에서 커널 모듈을 거부했는지 확인합니다.
sudo dmesg | grep -iE 'secure boot|nvidia'
보안 부트가 모듈을 차단한 경우 드라이버 모듈에 수동으로 서명하고 머신 소유자 키 (MOK)를 등록하거나 사전 서명된 커널 모듈이 있는 OS 이미지를 사용합니다. 자세한 내용은 GPU 드라이버 설치 (보안 부트 VM)를 참조하세요.
GPU 재설정
일부 문제에서는 GPU를 재설정해야 할 수 있습니다. GPU를 재설정하려면 다음 단계를 완료합니다.
- 하나 이상의 GPU가 연결된 N1, G2, A2, G4 VM의 경우 VM을 재부팅합니다.
- 부분 GPU(연결된 GPU가 1개 미만)가 있는 G4 VM의 경우 다음 단계를 완료합니다.
- A3, A4, A4X, A4X Max 인스턴스의 경우
sudo nvidia-smi --gpu-reset을 실행합니다.- 대부분의 Linux VM은
nvidia-smi실행 파일이/var/lib/nvidia/bin디렉터리에 있습니다. - GKE 노드의 경우
nvidia-smi실행 파일이/home/kubernetes/bin/nvidia디렉터리에 있습니다.
- 대부분의 Linux VM은
- GKE 노드의 A3, A4, A4X, A4X Max 인스턴스의 경우 gpu-reset-tool을 사용하여 노드의 모든 GPU 재설정을 자동화할 수도 있습니다. 이 도구에서는 대상 노드 이름만 지정하면 됩니다.
또는 VM을 재설정하거나 VM을 중지하고 다시 시작할 때마다 GPU도 재설정됩니다. VM 수명 주기 상태와 VM 복구 작업 간의 차이점에 대한 자세한 내용은 Compute Engine 인스턴스 수명 주기 및 Compute Engine 인스턴스 일시중지, 중지 또는 재설정을 참조하세요.
지원 사례 접수하기
이 페이지의 안내를 사용해도 문제를 해결할 수 없는 경우 다음 정보를 수집하고 지원 케이스를 엽니다.
- 영향을 받는 인스턴스가 있는 프로젝트의 프로젝트 ID입니다.
- 클러스터에 있는 모든 인스턴스 이름 또는 ID 목록입니다.
- 문제 해결을 통해 식별된 의심 노드 목록
- 디버그 설정이 사용 설정된 완전한 비인터리브 NCCL 로그
- 하드웨어 상태 점검 출력 (
dcgmi,nvidia-smi) - 실패하는 정확한 벤치마크 또는 워크로드 명령어
- 호스트 엔진 및 진단 로그와 같은 관련 로그 파일. 이를 수집하려면 기본 설치의
/usr/local/dcgm/scripts에 있는gather-dcgm-logs.sh를 실행합니다. - NVIDIA 버그 신고
nvidia-bug-report.sh를 실행합니다. Blackwell GPU의 경우 Blackwell GPU용 NVIDIA 버그 신고 생성을 따르세요. - 실패 전에 환경에 적용된 최근 변경사항에 관한 세부정보
다음 단계
GPU 머신 유형을 검토합니다.