상태: 초안 (2026-10-06 갱신). 공식 문서로 확인한 서술이 바탕이고, 소비자용 GPU 세 종에서 읽기 전용으로 확인한 부분(10절 끝의 「실측」)만 직접 확인한 값입니다. 데이터센터 GPU 와 실제 장애 사건은 측정하지 못했습니다. 글 끝의 「확인한 버전과 날짜」와 「확인하지 못한 것」을 먼저 읽으십시오. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.

GPU 하드웨어·드라이버 장애 진단

요약

GPU 장애 진단은 세 갈래의 신호를 읽는 일입니다. 커널 로그의 XID 메시지, DCGM(Data Center GPU Manager)과 nvidia-smi 지표, 쿠버네티스의 노드 상태입니다.

이 글을 읽고 나면 면접에서 설명할 수 있는 것

1. XID 를 「번호, 카탈로그의 즉시 조치 버킷, 단독 발생 여부」 순서로 읽어 앱 오류와 하드웨어 오류를 가르는 법
2. ECC, NVLink, 스로틀링, PCIe 강등이 어떤 지표와 코드로 드러나는지, 그리고 느린 GPU 하나를 찾는 법
3. 자동 격리·복구 파이프라인의 구성, 그리고 무엇에 페이지를 울리고 무엇을 티켓으로 남길지의 기준

1. 신호가 흐르는 길

GPU + 드라이버(NVML)
 ├─ 커널 로그 "NVRM: Xid (PCI:0000:ca:00): 79, ..." ─► 로그 수집기(syslog 모니터)
 ├─ NVML 이벤트(XID) ─► 디바이스 플러그인 ─► 장치 unhealthy ─► kubelet allocatable 감소
 └─ DCGM ─┬─ dcgm-exporter :9400/metrics ─► Prometheus ─► 알림
          └─ health watch, dcgmi diag (능동 점검)

dcgm-exporter 기본 지표 파일(default-counters.csv, main)에서 진단에 쓰는 것입니다. 괄호는 기본 상태입니다.

DCGM API 문서의 필드 이름(예: ..._TEMP_CELSIUS)과 exporter 지표 이름이 다를 수 있으니 쓰는 exporter 의 CSV 를 기준으로 삼습니다.

2. 소비자용 GPU 와 데이터센터 GPU

실험 환경 실측입니다. 8GB급 노트북 GPU(드라이버 595.91.07)의 dcgm-exporter 원문에는 XID_ERRORS 와 PROF_* 줄이 없었고 MEMORY_TEMP 와 리매핑 행 지표는 0 이었습니다. 0 이 「지원하고 정상」인지 「미지원이라 0」인지, XID 줄이 없는 이유가 exporter 판인지 소비자용 GPU 제약인지는 확인하지 못했습니다. XID 카탈로그의 「적용 대상」 열도 A100 이상 데이터센터 제품뿐입니다.

3. XID 읽는 법

형식은 NVRM: Xid (PCI 주소): 번호, 부가 정보 입니다. 읽는 순서는 ① 카탈로그의 즉시 조치 버킷, ② 단독(solo)인지 다른 XID 와 함께인지(45 는 다른 오류의 결과로도 찍힘), ③ 같은 GPU 에서 반복되는지입니다. 버킷은 RESTART_APP(앱만 재시작), RESET_GPU, RESTART_BM(노드 재시작), IGNORE, CONTACT_SUPPORT 입니다. Xid 154 는 필요한 복구 조치(None, Drain P2P, Drain and Reset, GPU Reset Required, Node Reboot Required)를 알려 줍니다.

31 은 카탈로그가 앱 쪽이 흔하다 하고 GPU 디버그 가이드는 「Suspected Hardware Problems」라 하므로 단발은 앱, 반복은 하드웨어라는 분기를 직접 둬야 합니다. 디바이스 플러그인은 13, 31, 43, 45, 68, 109 를 「앱 오류」로 하드코딩해 무시하고, NVML 이 critical 로 알리는 나머지 XID 에서 장치를 unhealthy 로 표시합니다(소스). 소스의 FIXME 는 unhealthy 에서 돌아오는 경로가 없다고 하므로 리셋 뒤 플러그인 재시작이 필요하다고 추론합니다(미확인).

4. ECC, 행 리매핑, 리타이어

단일 비트 오류는 하드웨어가 정정하고 이중 비트는 검출만 합니다. 카운터는 드라이버 로드 이후의 volatile 과 평생 누적인 aggregate 로 나뉩니다. Ampere 이후는 행 리매핑이 페이지 리타이어(구형 최대 64)를 대체해 최대 512 번 리매핑하며 적용에는 GPU 리셋이 필요합니다. 리매핑 실패 플래그는 이미 8행이 리매핑된 은행에 또 시도하거나, 이미 리매핑한 행에 또 시도하거나, 총 512회에 닿을 때 서며 RMA 판단의 근거가 됩니다. 근거 문서는 A100 이후 기준입니다.

nvidia-smi -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT

5. NVLink, NVSwitch, Fabric Manager

Fabric Manager(FM)는 NVSwitch 시스템에서 GPU 전체를 하나의 메모리 패브릭으로 묶고 링크를 감시합니다. HGX A100 은 FM 초기화 전에 CUDA 를 시작하면 cudaErrorSystemNotReady 가 납니다. Hopper 이후는 GPU 와 스위치가 자체 링크 학습을 하고 리셋에 FM 이 필요 없습니다. FM 은 드라이버와 같은 버전이어야 합니다. 74 가 나오면 nvidia-smi nvlink -e 로 CRC·replay·recovery 오류 카운터를 봅니다. 치명적 SXid 는 CUDA 작업을 중단시키고 74 와 45 를 함께 남깁니다. Blackwell 계열은 NVLink 5 용 XID 144 부터 150 번대를 쓰고 SXid 는 적용되지 않습니다. Ampere NVSwitch 시스템은 FM 이 돌 때만 GPU 하나씩 리셋할 수 있고, 아니면 NVLink 로 묶인 GPU 를 함께 리셋합니다.

6. 스로틀링과 PCIe 강등

clocks_event_reasons 는 비트마스크입니다. 값은 GPU 유휴 0x1, 애플리케이션 클럭 0x2, SW 전력 상한 0x4, HW 슬로다운 0x8, 동기 부스트 0x10, SW 열 0x20, HW 열 0x40, HW 전력 브레이크 0x80, 디스플레이 클럭 0x100, 보드 한계 0x200, 신뢰성 0x400 입니다(go-nvml). 0x8 과 0x40 은 코어 클럭을 절반 이하로 낮추고 0x80 은 외부 전원 브레이크 신호라 의미가 큽니다. Llama 3 논문은 한낮 기온 때문에 처리량이 하루 주기로 1 에서 2% 변했다고 적습니다. PCIe 는 pcie.link.gen.current 와 pcie.link.gen.max, pcie.link.width.current 를 비교하되, 현재 값은 유휴 때 낮아질 수 있다는 매뉴얼 설명에 따라 부하 중에 재야 합니다. 재시도는 PCIE_REPLAY_COUNTER 이고, DCGM health 의 예시 출력은 분당 8회 초과를 경고로 보여 줍니다.

7. 느린 GPU 하나가 전체를 늦춘다

Meta 는 Llama 3 405B 의 54일 구간에서 466회 중단(예기치 않음 419)이 있었고 예기치 않은 중단의 약 78% 가 하드웨어 원인(GPU 58.7%)이라고 보고했습니다. 논문 원문을 열어 확인하니 이 58.7% 는 본문에 그렇게 적혀 있지만 표 5 의 인쇄된 비율을 더한 값이고, 같은 표의 건수로 다시 세면 GPU 분류가 268건이라 419건 중 64.0% 입니다(표의 「Faulty GPU」 30.1% 는 건수 148건과 맞지 않는 인쇄 오류로 보이며 건수로는 35.3%). 아래 「외부 근거」에 정리했습니다. 같은 글은 작동은 하지만 느린 낙오자가 찾기 어렵고 하나가 수천 GPU 를 늦출 수 있으며 느린 통신으로 나타난다고 적습니다. 찾는 순서는 제 정리입니다. ① 랭크별 스텝·집합 통신 시간을 비교합니다(PyTorch flight recorder). ② 느린 랭크 GPU 의 스로틀 사유, 온도, 전력, PCIe 세대와 폭, NVLink 오류를 나란히 놓습니다. ③ 노드를 비운 뒤 dcgmi diag -r 3(targeted_stress, nvbandwidth, nccl_tests 포함)으로 확인합니다. DCGM 문서는 이것이 포괄적 하드웨어 진단과 RMA 근거를 대신하지 않는다고 밝힙니다.

8. 쿠버네티스 대응: 격리와 자동 복구

flowchart LR
  D["탐지<br/>XID, DCGM, 플러그인"] --> C["분류<br/>카탈로그 버킷, 반복 여부"]
  C --> Q["cordon·taint"]
  Q --> R["drain<br/>PDB 존중"]
  R --> X["복구<br/>GPU 리셋, 노드 재시작, 교체"]
  X --> V["검증<br/>dcgmi diag -r 1 또는 2"]
  V --> U["uncordon"]
  X -. 반복 실패 .-> H["사람 호출"]

unhealthy 가 되어도 이미 배정된 파드는 그 장치에 묶여 있으므로(쿠버네티스 문서) 드레인이 필요합니다. 1.36 의 ResourceHealthStatus(베타)는 컨테이너 상태 allocatedResourcesStatus 로 장치 건강을 알려 줍니다. NVSentinel(v1.25.0, Beta/Stable, 쿠버네티스 1.34+, standalone DCGM 필요)은 DCGM 과 syslog 의 XID 를 내장 카탈로그로 분류해 cordon, drain, 리셋·재부팅까지 잇고, 5분 안에 노드의 50% 가 cordon 되면 멈추는 회로 차단기가 있고 기본은 모니터링만 켭니다. Amazon EKS 의 node monitoring agent 는 잘 알려진 XID 를 노드 조건 AcceleratedHardwareReady=False 로 올려 48 은 재부팅, 74·79 는 교체로 매기고 모르는 XID 는 이벤트로만 남깁니다. 벤더 문의 전에는 nvidia-bug-report.sh 출력, FM 로그, DCGM 진단 로그를 모읍니다(GPU 디버그 가이드).

9. 알림 설계

구글 SRE 책은 「응답이 기계적이면 페이지가 아니다」라고 합니다. 아래는 이를 적용한 제 제안입니다.

10. 직접 해 보기 (읽기 전용)

# GPU 가 있는 노드에서 실행
journalctl -k --no-pager | grep -E "NVRM: Xid" | tail   # dmesg 가 막힌 계정에서도 읽힘, 아래 「실측」 참고
nvidia-smi --query-gpu=index,name,pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current,temperature.gpu,power.draw,clocks_event_reasons.active --format=csv
nvidia-smi -q -d PERFORMANCE,ECC,ROW_REMAPPER | head -80

# 쿠버네티스에서 dcgm-exporter 지표 확인
kubectl -n gpu-operator get po -l app=nvidia-dcgm-exporter -o wide
curl -s http://<파드IP>:9400/metrics | grep -E "XID|REMAP|PCIE_REPLAY|VIOLATION"

사용률, 전력, 온도, VRAM, 클럭만 보는 대시보드에서는 GPU 전용 알림 규칙이 빠지기 쉽습니다. 필자는 8GB 카드에서 서버 프로세스의 할당자 캐시가 6분 만에 6.4 GB 에서 7.8 GB 로 늘어난 것을 관찰했고, 이런 VRAM 추세가 경보를 연습하기 좋은 자료입니다.

외부 근거: 논문과 공식 자료로 확인한 것

데이터센터 GPU 와 대규모 클러스터가 없어 실제 장애 사건은 재지 못했습니다. 대신 대규모 운영 보고와 NVIDIA 공식 문서를 열어 11편의 서술을 대조했습니다. 외부 수치는 장비와 조건이 달라 방향과 일치 여부만 판정했습니다.

벤더 수치는 조건이 본문에 적힌 것만 옮겼고, 논문 본문을 열지 못한 자료는 쓰지 않았습니다.

11. 면접에서 나올 만한 질문

1. XID 79 를 봤습니다. 어떻게 합니까? PCIe 로 GPU 에 접근할 수 없다는 뜻이고 카탈로그 버킷은 노드 재시작입니다. cordon 과 drain 뒤 재부팅하고, 반복되면 링크, 전원, 시스템 이벤트 로그를 보고 교체합니다.
2. XID 13 과 48 은 어떻게 다룹니까? 13 은 대개 앱 오류라 Compute Sanitizer 로 보고, 같은 TPC·GPC 에서 반복되면 하드웨어를 의심합니다. 48 은 정정 불가 ECC 라 리셋 또는 재부팅이 필요하고 63·64 가 동반되면 drain 후 리셋합니다.
3. 느린 GPU 하나를 어떻게 찾습니까? 랭크별 통신 시간으로 의심 랭크를 좁히고 그 GPU 의 스로틀 사유, 온도, PCIe, NVLink 오류를 비교합니다. 노드를 비운 뒤 dcgmi diag -r 3 으로 확인합니다.
4. 자동 복구에서 무엇을 조심합니까? 동시성 상한과 회로 차단기로 한꺼번에 격리되지 않게 하고, 반복 실패는 사람에게 넘깁니다. 리셋은 GPU 를 쓰는 프로세스가 없어야 합니다.
5. 무엇에 페이지를 울립니까? 기계적으로 처리되는 것은 자동화하고 기록만 남깁니다. 자동 복구가 실패하거나 반복될 때, 가용 GPU 가 임계 아래일 때 페이지합니다.

12. 흔한 오해

• 「XID 가 찍히면 GPU 가 고장이다」: 13, 31, 43, 45 는 앱 오류인 경우가 많습니다.
• 「XID_ERRORS 는 오류 횟수다」: 마지막 XID 값입니다.
• 「사용률이 높으면 정상」: 느린 GPU 도 사용률은 높습니다.

13. 참고 자료와 확인한 버전

모두 2026-10-05 에 열었습니다.

• https://docs.nvidia.com/deploy/xid-errors/ (카탈로그, 최종 갱신 2026-09-09)
• https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/ , https://docs.nvidia.com/deploy/gpu-debug-guidelines/
• https://docs.nvidia.com/datacenter/dcgm/latest/ (feature-overview, dcgm-diagnostics, getting-started, dcgm-api-field-ids)
• https://github.com/NVIDIA/dcgm-exporter (default-counters.csv), https://github.com/NVIDIA/k8s-device-plugin (health.go), https://github.com/NVIDIA/go-nvml (const.go)
• https://docs.nvidia.com/deploy/nvidia-smi/index.html , https://docs.nvidia.com/datacenter/tesla/fabric-manager-user-guide/index.html
• https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/troubleshooting.html
• https://github.com/NVIDIA/NVSentinel , https://docs.nvidia.com/nvsentinel/ , https://docs.aws.amazon.com/eks/latest/userguide/node-health-nma.html
• https://arxiv.org/abs/2407.21783 , https://arxiv.org/abs/2505.05713 , https://sre.google/sre-book/monitoring-distributed-systems/
• https://docs.pytorch.org/tutorials/unstable/flight_recorder_tutorial.html , https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

실측: 소비자용 GPU 세 종에서 읽은 값 (읽기 전용)

데스크톱 24GB급(Ampere 세대, 드라이버 570.195.03), 노트북 8GB급(Ada 세대, 595.91.07), 노트북 6GB급(Ampere 세대, 595.91.07)에서 nvidia-smi -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT, --query-gpu 필드, 커널 로그를 읽었습니다. 셋 다 유휴 상태였고 아무것도 바꾸지 않았습니다.

• 2절 표가 말한 「GA10x·Ada 열에 행 리매핑이 표시됨」은 제품마다 달랐습니다. Ampere 세대의 소비자용 두 종은 드라이버가 N/A 를 돌려주었고, Ada 세대 노트북만 값을 주었습니다. 이 GPU 에서는 0 이 「지원하고 정상」이었고, 지원하지 않는 GPU 에서는 같은 질의가 0 이 아니라 N/A 로 나왔습니다. 그러므로 대시보드에서 N/A 와 0 을 구별해야 하고, 값이 항상 0 이라는 이유로 정상으로 읽으면 안 됩니다. 2절에서 8GB급 노트북 GPU 의 exporter 가 보인 리매핑 0 은 이 값과 일치합니다.
• 이 세 종(GDDR6 세대)에서는 ECC 카운터가 노출되지 않았습니다. 세 종 모두 N/A 였으므로 메모리 오류를 하드웨어 카운터로 잡을 수 없고, Xid 로그와 응용의 이상 동작에 기대야 합니다. 「소비자용 GPU 에는 ECC 가 없다」로 일반화하지는 않습니다. NVIDIA 의 RTX Blackwell 백서는 GDDR7 의 ECC 가 DRAM 다이에 내장되어 항상 켜져 있고 소프트웨어로 끌 수 없다고 설명하며(카운터가 보이는지는 별개), RTX 30·40 세대 소비자용 제품군 에 ECC 가 없다고 직접 적은 공식 문장은 찾지 못했습니다(nvidia-smi 문서의 「소비자용 제품군 는 정보가 매우 제한적」이라는 서술과 ECC 모드 항목이 InfoROM 객체를 요구한다는 서술이 간접 근거).
• 질의 필드 이름은 드라이버 570 과 595 에서 모두 유효했습니다. remapped_rows.correctable, remapped_rows.uncorrectable, remapped_rows.pending, remapped_rows.failure, retired_pages.pending, ecc.errors.corrected.volatile.total, inforom.ecc, clocks_event_reasons.hw_thermal_slowdown, clocks_event_reasons.sw_power_cap, pcie.link.gen.gpucurrent 가 오류 없이 값 또는 [N/A] 를 돌려주었습니다. 즉 필드 이름이 틀렸다는 오류는 나지 않으므로, N/A 는 필드가 없다는 뜻이 아니라 GPU 가 값을 제공하지 않는다는 뜻입니다.
• 커널 로그는 dmesg 가 막혀 있을 수 있습니다. 세 노드 모두 kernel.dmesg_restrict=1 이라 일반 계정의 dmesg 가 read kernel buffer failed: Operation not permitted 로 실패했고, journalctl -k 는 읽혔습니다. sudo 가 필요하다고 안내된 명령이 비밀번호 없는 계정에서는 막히므로, 운영 점검 스크립트는 journalctl -k 를 우선 쓰는 편이 낫습니다.
• grep -iE "NVRM|Xid" 는 틀린 줄을 잡습니다. 같은 로그에서 이 패턴은 (1) NIC 드라이버가 칩 개정을 찍은 XID 541 줄과 (2) Xid 가 아닌 NVRM: 메시지(할당 실패 NV_ERR_NO_MEMORY)를 함께 잡았습니다. 둘 다 GPU 장애가 아니므로 알림 규칙과 점검 명령은 NVRM: Xid 로 좁혀야 합니다. 실제 NVRM: Xid 줄은 세 노드에서 0건이었습니다.
• PCIe 세대는 유휴에서 1 로 내려가 있었습니다. 세 노드 모두 gpucurrent 가 1 이어서 최대(4)와 달라 보이는데, 유휴 절전일 수 있으므로 6절의 강등 판정은 부하를 건 상태에서 다시 읽어야 합니다. 노트북 GPU 하나는 폭이 x8(최대 x16)로 나왔고, 설계 때문일 수 있어 판정하지 않았습니다.
• 부하를 걸고 다시 읽었습니다(8GB급 노트북 GPU 한 장). 서빙 서버로 약 80초 동안 부하를 걸며 2초마다 표본 38개를 읽었습니다. PCIe 세대는 최대인 4 였고(37개, 나머지 1개는 2), 폭은 8 로 일정했습니다. SM 클럭은 중앙값 2,640MHz(최대 3,105MHz 에 못 미침, 부하가 시작될 때 375MHz 까지 내려간 표본이 있었음), 전력은 중앙값 78W 와 최대 91.8W, 온도는 최대 63°C, 사용률 중앙값 100% 였습니다. **클럭 제한 사유는 부하 표본 37개에서 모두 0(없음)**이었고 유휴 표본 하나만 0x01(유휴)이었습니다. 즉 이 부하에서는 전력 상한이나 열 감속이 걸리지 않았고, 최대 클럭에 못 미친 것은 제한 사유 없이 부하와 전력 정책에 따른 것으로 보입니다(추정). 유휴 상태에서도 서버 프로세스가 GPU 를 잡고 있으면 PCIe 세대가 4 로 유지되었고(표본 6개, SM 클럭 1,890MHz, 전력 8.7W), 프로세스가 없는 노드에서 읽은 세대 1 은 컨텍스트가 없는 절전 상태였을 가능성이 큽니다(추정). 열 감속과 전력 상한이 실제로 걸리는 고온·밀폐 환경은 시험하지 않았습니다(15분 지속 부하는 아래에서 확인했고 클럭 제한이 걸리지 않았습니다).
• 15분 지속 부하에서도 클럭 제한 사유가 걸리지 않았습니다(8GB급 노트북 GPU 한 장). 같은 서버로 동시 32 부하를 15분 동안 이어서 걸며 2초 간격 표본 443개를 읽었습니다. PCIe 는 세대 4, 폭 8 로 일정했고, SM 클럭은 중앙값 2,625MHz(범위 1,890~2,640), 전력은 중앙값 78W 와 최대 93.2W, 온도는 최대 70°C 였습니다. 클럭 제한 사유는 유휴 비트 1개 표본을 빼면 모두 0 이었습니다(전력 상한이나 열 감속이 걸린 표본 없음). 같은 시간 동안 처리량은 829~832 tok/s 로 23번의 측정에서 ±0.2% 였습니다. 80초 시험의 최대 온도 63°C 보다 7°C 높아졌지만 이 환경에서는 열이 성능을 깎지 않았습니다. 데이터센터의 장시간 학습이나 더 더운 환경과는 다릅니다.
• 부하를 걸어도 PCIe 세대가 올라가지 않는 GPU 를 실제로 만났습니다(24GB급 데스크톱 GPU 한 장). 이 GPU 는 장치가 지원하는 최대 링크가 16GT/s(세대 4)이고 폭이 x16 이지만, 행렬곱과 호스트에서 GPU 로 복사를 25초 동안 겹쳐 돌려 P0 상태, 사용률 100%, SM 클럭 1,950MHz 가 되었는데도 nvidia-smi 의 현재 세대는 1 이었고, 호스트 쪽에서 /sys/bus/pci/devices/<장치>/current_link_speed 를 3초마다 20번 읽은 값도 모두 2.5GT/s(세대 1)였습니다. 고정(pinned) 메모리 1GiB 의 호스트에서 GPU 전송은 1.7~1.9GB/s, GPU 에서 호스트는 1.6~2.2GB/s 로 세 번 반복해도 같았습니다. PCIe 4.0 x16 의 이론 대역폭(약 31.5GB/s)의 약 6% 입니다. 같은 GPU 의 메모리 대역폭(읽기 905GB/s)과 연산 처리량(fp16 행렬곱 63~71 TFLOPS)은 정상이어서, 링크만 낮은 세대에 고정된 문제로 보입니다. 원인(메인보드 설정, 절전 정책, 라이저, 슬롯)은 확인하지 못했습니다(미확인). 이 GPU 의 모델 적재와 KV 오프로드는 호스트-GPU 전송이 병목이 되므로, 7GB 모델을 올릴 때 전송만으로 약 4초(7 ÷ 1.8), 8편의 KV 불러오기 이득도 줄어듭니다(계산). 점검 방법은 두 가지입니다. 부하 중에 nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max --format=csv 를 읽고, 호스트의 current_link_speed 와 max_link_speed 를 비교합니다. 유휴에서 세대가 낮은 것은 정상이지만 부하 중에도 낮으면 강등입니다.

한계: 소비자용 세 종뿐이며 데이터센터 GPU 의 ECC, 행 리매핑 실패, XID 79 같은 실제 장애는 만나지 못했습니다. DCGM 의 XID_ERRORS 지표가 소비자용 GPU 에서 나오지 않는 이유(exporter 판인지 GPU 제약인지)도 이 시험으로는 가르지 못했습니다(미확인).

확인한 버전: GPU Operator 26.7.1 번들의 DCGM 4.6.1-1, DCGM Exporter 4.6.1-4.8.4, 쿠버네티스 안정판 v1.37.1.

확인하지 못한 것: 소비자용 GPU 의 ECC·행 리매핑·XID 지표 실제 출력, 실험 환경 exporter 의 판, 질의 필드명(제3자가 공개한 --help-query-gpu 출력 기준)이 드라이버 595 에서 유효한지, 카탈로그의 소비자용 GPU 적용 여부. 알림 등급표와 조사 순서는 공식 규정이 아닌 제 판단입니다.