
dcgmi diag -r 3 명령어 완벽 정리
GPU 서버 장애 진단에 사용하는 DCGM Level 3 진단 명령어
GPU 서버를 운영하다 보면 단순히 nvidia-smi 결과만으로는 GPU가 정상인지 판단하기 어려운 경우가 있습니다.
예를 들어 GPU는 보이는데 학습 작업이 실패하거나, Xid Error, ECC Error, NVLink 문제, GPU Reset 실패 같은 증상이 발생할 수 있습니다.
이럴 때 NVIDIA GPU 상태를 더 깊게 점검하기 위해 사용하는 명령어가 바로 다음 명령어입니다.
dcgmi diag -r 3
이 글에서는 dcgmi diag -r 3 명령어가 무엇인지, 어떤 상황에서 사용하는지, 실행 시 주의사항은 무엇인지 실무 관점에서 정리해보겠습니다.
1. dcgmi란?
dcgmi는 NVIDIA DCGM(Data Center GPU Manager)에서 제공하는 명령어 도구입니다.
DCGM은 데이터센터 GPU를 관리하고 모니터링하기 위한 NVIDIA의 관리 도구입니다.
GPU 상태 확인, 헬스 체크, 진단, 메트릭 수집, 장애 분석 등에 사용됩니다.
쉽게 말하면 다음과 같습니다.
nvidia-smi = GPU 상태를 조회하는 기본 도구
dcgmi = GPU 상태를 더 깊게 진단하고 관리하는 도구
nvidia-smi가 현재 GPU 사용률, 메모리 사용량, 온도, 프로세스 상태를 확인하는 데 주로 사용된다면, dcgmi는 GPU 하드웨어 상태와 장애 가능성을 더 정밀하게 검사하는 데 사용됩니다.
2. dcgmi diag -r 3 명령어 의미
명령어를 나누어 보면 다음과 같습니다.
dcgmi diag -r 3
항목의미
| dcgmi | NVIDIA DCGM 명령어 도구 |
| diag | Diagnostic, GPU 진단 실행 |
| -r | 실행할 진단 레벨 지정 |
| 3 | Level 3 진단 실행 |
즉, 이 명령어는 DCGM 진단 기능 중 Level 3 테스트를 실행하라는 의미입니다.
3. -r 3은 어떤 진단 레벨인가?
DCGM 진단은 레벨별로 검사 강도와 시간이 다릅니다.
| 진단 레벨 | 설명 | 특징 |
| -r 1 | Quick Test | 아주 빠른 기본 점검 |
| -r 2 | Medium Test | 중간 수준의 진단 |
| -r 3 | Long Test | 장시간 하드웨어 진단 |
| -r 4 | Extra Long Test | 더 긴 시간의 심층 진단 |
여기서 -r 3은 Long / System Hardware Diagnostics에 해당합니다.
단순 확인용이라기보다는 GPU에 실제 부하를 주면서 하드웨어 이상 여부를 점검하는 진단입니다.
4. dcgmi diag -r 3은 무엇을 검사하나?
dcgmi diag -r 3은 GPU에 실제 연산 부하와 메모리 부하를 주면서 여러 항목을 검사합니다.
대표적으로 다음 항목들을 확인합니다.
| 검사 항목 | 설명 |
| GPU 기본 상태 | GPU가 정상적으로 인식되는지 확인 |
| Driver / CUDA 상태 | NVIDIA Driver, CUDA, NVML 접근 가능 여부 확인 |
| GPU Memory | GPU 메모리 이상 여부 확인 |
| Memory Bandwidth | GPU 메모리 대역폭 정상 여부 확인 |
| PCIe 상태 | 서버와 GPU 간 PCIe 통신 상태 확인 |
| NVLink / NVSwitch | GPU 간 고속 통신 상태 확인 |
| GPU 연산 테스트 | 실제 연산을 수행하면서 오류 여부 확인 |
| 전력 상태 | 부하 상황에서 전력 공급 문제가 없는지 확인 |
| 온도 상태 | 부하 중 GPU 온도 이상 여부 확인 |
| Xid Error | GPU 드라이버/하드웨어 오류 발생 여부 확인 |
| ECC Error | GPU 메모리 오류 여부 확인 |
즉, dcgmi diag -r 3은 단순 조회 명령어가 아니라 GPU를 실제로 테스트해보는 진단 명령어입니다.
5. 언제 사용하면 좋을까?
1) GPU 장애가 의심될 때
예를 들어 아래와 같은 로그가 보일 때 사용합니다.
dmesg -T | grep -i xid
결과 예시:
NVRM: Xid ...
Xid Error는 NVIDIA GPU에서 발생하는 대표적인 오류 코드입니다.
GPU 하드웨어, 드라이버, CUDA 작업, PCIe, 메모리 문제 등 다양한 원인으로 발생할 수 있습니다.
이런 경우 dcgmi diag -r 3을 실행해서 GPU 자체에 문제가 있는지 추가로 확인할 수 있습니다.
2) ECC Error가 발생했을 때
GPU 메모리 오류가 의심되는 경우에도 사용합니다.
nvidia-smi -q -d ECC
여기서 Uncorrectable Error, SRAM Error, DRAM Error 등이 보이면 GPU 상태를 더 자세히 확인해야 합니다.
이때 다음 명령어를 실행합니다.
dcgmi diag -r 3
3) GPU 서버 리부팅 후 정상 여부 확인
서버를 리부팅한 뒤 GPU가 정상적으로 올라왔는지 확인할 때도 사용할 수 있습니다.
기본 확인은 다음 순서로 진행합니다.
nvidia-smi
dcgmi discovery -l
dcgmi diag -r 3
nvidia-smi에서 GPU가 보인다고 해서 실제 연산까지 정상이라고 단정할 수는 없습니다.
따라서 장애 조치 후에는 DCGM 진단을 통해 추가 검증하는 것이 좋습니다.
4) 장애 노드를 다시 운영에 투입하기 전
Kubernetes나 Slurm 환경에서 GPU 노드를 운영 중이라면, 장애가 발생한 노드를 바로 다시 투입하기보다는 진단 후 복귀시키는 것이 좋습니다.
예를 들어 Slurm 환경에서는 다음과 같은 절차를 사용할 수 있습니다.
scontrol update nodename=gpu001 state=drain reason="GPU diagnostic"
dcgmi diag -r 3
scontrol update nodename=gpu001 state=resume
이렇게 하면 장애 의심 노드를 먼저 격리하고, 진단 후 정상일 때만 다시 작업을 받을 수 있게 됩니다.
6. 운영 중 실행해도 될까?
결론부터 말하면 운영 중인 GPU에서는 신중하게 실행해야 합니다.
dcgmi diag -r 3은 GPU에 실제 부하를 주는 진단입니다.
따라서 이미 학습, 추론, CUDA 작업이 실행 중인 GPU에서 실행하면 다음 문제가 발생할 수 있습니다.
| 영향 | 설명 |
| 성능 저하 | 기존 작업과 GPU 리소스 경합 발생 |
| 작업 실패 | 민감한 학습/추론 작업이 실패할 수 있음 |
| 온도 상승 | 스트레스 테스트로 GPU 온도 상승 가능 |
| 전력 사용 증가 | 부하 테스트로 전력 사용량 증가 |
| 진단 실패 | 이미 GPU를 사용 중인 프로세스 때문에 테스트가 실패할 수 있음 |
따라서 운영 환경에서는 반드시 해당 노드에 실행 중인 작업이 없는지 확인한 후 실행하는 것이 좋습니다.
7. Kubernetes 환경에서 실행 절차
Kubernetes에서 GPU 노드를 운영 중이라면 먼저 노드를 비워야 합니다.
kubectl cordon <node명>
kubectl drain <node명> --ignore-daemonsets --delete-emptydir-data
그 다음 GPU 서버에 접속해서 진단합니다.
dcgmi diag -r 3
진단이 정상적으로 끝났다면 다시 스케줄링 가능 상태로 변경합니다.
kubectl uncordon <node명>
정리하면 다음 순서입니다.
1. 노드 cordon
2. 기존 Pod drain
3. dcgmi diag -r 3 실행
4. 결과 확인
5. 정상일 경우 uncordon
8. Slurm 환경에서 실행 절차
Slurm 환경에서는 먼저 노드를 Drain 상태로 변경합니다.
scontrol update nodename=gpu001 state=drain reason="GPU diagnostic"
이후 GPU 진단을 실행합니다.
dcgmi diag -r 3
정상 확인 후 다시 운영 상태로 복귀시킵니다.
scontrol update nodename=gpu001 state=resume
Slurm 환경에서는 진단 중 다른 Job이 해당 GPU를 사용하지 않도록 사전에 상태를 변경하는 것이 중요합니다.
9. 특정 GPU만 진단하는 방법
서버 전체 GPU가 아니라 특정 GPU만 점검하고 싶다면 -i 옵션을 사용합니다.
GPU 0번만 검사하려면 다음과 같이 실행합니다.
dcgmi diag -r 3 -i 0
GPU 0번과 1번만 검사하려면 다음과 같이 실행합니다.
dcgmi diag -r 3 -i 0,1
GPU 번호는 다음 명령어로 확인할 수 있습니다.
nvidia-smi
또는 DCGM 기준으로 확인할 수도 있습니다.
dcgmi discovery -l
10. JSON 형식으로 결과 출력하기
운영 자동화나 로그 수집 목적이라면 JSON 출력이 유용합니다.
dcgmi diag -r 3 -j
JSON 형식으로 출력하면 스크립트에서 Pass, Fail, Warn 결과를 파싱하기 좋습니다.
예를 들어 장애 점검 스크립트, 정기 점검 자동화, GPU 상태 리포트 생성 등에 활용할 수 있습니다.
11. 로그 확인 위치
DCGM 진단 로그는 일반적으로 아래 경로에 남습니다.
/var/log/nvidia-dcgm/nvvs.log
진단 실패나 경고가 발생했다면 다음 명령어로 로그를 확인합니다.
tail -n 200 /var/log/nvidia-dcgm/nvvs.log
실시간으로 보고 싶다면 다음과 같이 실행합니다.
tail -f /var/log/nvidia-dcgm/nvvs.log
12. 결과 해석 방법
dcgmi diag -r 3 실행 결과는 보통 테스트 항목별로 다음과 같이 표시됩니다.
| 결과 | 의미 | 조치 |
| Pass | 정상 | 운영 복귀 가능 |
| Warn | 경고 | 온도, 성능 저하, 환경 문제 확인 필요 |
| Fail | 실패 | GPU, PCIe, NVLink, Memory 등 상세 분석 필요 |
| Skip | 테스트 생략 | 지원 불가, 권한 부족, 환경 미충족 가능 |
Pass가 나오면 대체로 정상으로 볼 수 있습니다.
하지만 Warn이나 Fail이 나오면 추가 확인이 필요합니다.
특히 Fail이 발생한 경우 바로 GPU 불량으로 단정하기보다는 관련 로그를 함께 확인해야 합니다.
13. Fail 발생 시 추가 확인 명령어
진단 실패가 발생하면 다음 명령어들을 함께 확인하는 것이 좋습니다.
GPU 기본 상태 확인
nvidia-smi
GPU 상세 정보 확인
nvidia-smi -q
ECC Error 확인
nvidia-smi -q -d ECC
Row Remapper 확인
nvidia-smi -q -d ROW_REMAPPER
Page Retirement 확인
nvidia-smi -q -d PAGE_RETIREMENT
Xid Error 확인
dmesg -T | grep -i xid
커널 로그에서 NVIDIA 오류 확인
journalctl -k | grep -i NVRM
DCGM 진단 로그 확인
tail -n 200 /var/log/nvidia-dcgm/nvvs.log
14. NVLink / NVSwitch 환경 추가 확인
H100, A100 같은 다중 GPU 서버에서는 NVLink나 NVSwitch 문제가 발생할 수 있습니다.
이 경우 다음 명령어도 함께 확인하는 것이 좋습니다.
nvidia-smi nvlink -s
nvidia-smi topo -m
Fabric Manager 상태도 확인합니다.
systemctl status nvidia-fabricmanager
특히 HGX 서버나 NVSwitch 기반 서버에서는 Fabric Manager가 정상 동작하지 않으면 GPU 간 통신 문제가 발생할 수 있습니다.
15. 실무 점검 순서 예시
장애 의심 GPU 서버에서는 다음 순서로 점검하면 좋습니다.
# 1. GPU 인식 상태 확인
nvidia-smi
# 2. DCGM에서 GPU 인식 확인
dcgmi discovery -l
# 3. Xid Error 확인
dmesg -T | grep -i xid
# 4. ECC Error 확인
nvidia-smi -q -d ECC
# 5. Row Remapper 확인
nvidia-smi -q -d ROW_REMAPPER
# 6. DCGM Level 3 진단 실행
dcgmi diag -r 3
# 7. DCGM 로그 확인
tail -n 200 /var/log/nvidia-dcgm/nvvs.log
운영 환경이라면 이 전에 반드시 작업 중인 프로세스나 Job이 없는지 확인해야 합니다.
16. 운영 환경 권장 절차
실제 운영 환경에서는 아래 절차를 권장합니다.
1. 장애 의심 노드 확인
2. 해당 노드의 작업 중지 또는 Drain 처리
3. nvidia-smi로 GPU 기본 상태 확인
4. Xid / ECC / Row Remapper 확인
5. dcgmi diag -r 3 실행
6. 결과가 Pass인지 확인
7. Fail 또는 Warn이면 로그 추가 분석
8. 정상일 경우 노드 운영 복귀
9. 반복 Fail이면 벤더 점검 또는 GPU 교체 검토
단순히 nvidia-smi가 정상이라고 해서 GPU가 완전히 정상이라고 판단하면 안 됩니다.
특히 대규모 학습, 분산 학습, GPUaaS, Slurm, Kubernetes 환경에서는 DCGM 진단 결과를 함께 보는 것이 안정적입니다.
17. 자주 사용하는 명령어 정리
| 목적 | 명령어 |
| GPU 상태 확인 | nvidia-smi |
| DCGM GPU 목록 확인 | dcgmi discovery -l |
| 전체 GPU Level 3 진단 | dcgmi diag -r 3 |
| 특정 GPU 진단 | dcgmi diag -r 3 -i 0 |
| JSON 출력 | dcgmi diag -r 3 -j |
| 상세 출력 | dcgmi diag -r 3 -v |
| DCGM 로그 확인 | tail -n 200 /var/log/nvidia-dcgm/nvvs.log |
| Xid 확인 | dmesg -T | grep -i xid |
| ECC 확인 | nvidia-smi -q -d ECC |
| Row Remapper 확인 | nvidia-smi -q -d ROW_REMAPPER |
| Fabric Manager 확인 | systemctl status nvidia-fabricmanager |
18. 한 줄 요약
dcgmi diag -r 3
이 명령어는 NVIDIA DCGM을 이용해 GPU에 실제 부하를 걸고 하드웨어 이상 여부를 진단하는 Level 3 GPU 진단 명령어입니다.
GPU 장애, Xid Error, ECC Error, NVLink 문제, 서버 리부팅 후 정상성 검증, 장애 노드 운영 복귀 전 점검 등에 유용하게 사용할 수 있습니다.
다만 운영 중인 GPU에 바로 실행하면 기존 작업에 영향을 줄 수 있으므로, Kubernetes나 Slurm 환경에서는 반드시 노드를 격리하거나 작업을 비운 후 실행하는 것이 안전합니다.
마무리
GPU 서버 운영에서는 단순히 GPU가 보이는지만 확인하는 것으로는 부족합니다.
nvidia-smi
는 기본 상태 확인용이고,
dcgmi diag -r 3
는 GPU 하드웨어 상태를 더 깊게 검증하는 진단용 명령어입니다.
따라서 GPU 장애가 의심되거나, 장애 조치 후 노드를 다시 운영에 투입하기 전에는 dcgmi diag -r 3을 활용해 GPU 상태를 검증하는 것이 좋습니다.
특히 H100, A100, L40S 같은 고가의 데이터센터 GPU를 운영하는 환경에서는 DCGM 진단 결과를 장애 분석과 벤더 대응 자료로 함께 남겨두는 것을 권장합니다.
'[GPUaaS] > GPUmgt' 카테고리의 다른 글
| [🧯 systemctl timeout 장애 분석] systemd/D-Bus, Lustre, InfiniBand 문제 쉽게 이해하기 !! (0) | 2026.06.15 |
|---|---|
| [GPU] KubeRay Operator란? 🚀 (2) | 2026.06.09 |
| [CUDA] NVIDIA GPU를 계산 작업에 사용할 수 있게 해주는 기술!! (1) | 2026.05.31 |
| [GPU] Lustre RDMA Failure 발생 의미 🚨 (0) | 2026.05.23 |
| [🚀GPU] VAST 스토리지 vs Lustre vs DDN 완전 정리 !! (0) | 2026.05.18 |
| [🚀 k9s 설치 방법] 실무 단축키 20개 완벽 가이드 (초보자용) (0) | 2026.04.29 |
| [k9s] Kubernetes를 터미널에서 쉽게 관리해주는 UI 도구 !! (0) | 2026.04.29 |
| [🚀 NVIDIA] NCCL, NVLink, InfiniBand 완벽 이해 (초보자용) (0) | 2026.04.29 |
댓글