Incident Library

IL-0414 NCSA · 2025-03-14 (게시일)ai-infra

NCSA Delta 의 H100 GPU 에서 uncorrectable 메모리 오류가 A100 보다 잦게 나 사용자 작업이 실패하고 노드가 내려갔다

University of Illinois Urbana-Champaign, Nokia Bell Labs, IBM Research 의 연구진이 NCSA 가 운영하는 HPC 시스템 Delta 의 GPU 오류 로그를 분석한 논문이다. Delta 는 A100 40 GB GPU 448장을 단 4·8-way 노드 106대와, H100 96 GB GPU 608장을 단 4-way GH200 노드 152대로 이루어지며 GPU 는 모두 1,056장이다. A100 은 2022년 10월부터 2025년 3월까지 895일, H100 은 2024년 10월부터 2025년 3월까지 146일을 보았고, 합쳐 1,170만 GPU 시간이다. 데이터는 모든 계산 노드의 시스템 로그에서 정규식으로 뽑은 XID 오류와 복구 기록, Slurm 스케줄러 데이터베이스, 1분 단위의 NVIDIA DCGM 지표다. 같은 GPU 에서 짧은 시간 간격 안에 반복된 같은 오류는 하나로 묶었고, uncorrectable ECC 메모리 오류 수는 row remapping event 인 RRE 와 row remapping failure 인 RRF 를 더해 셌다. 작업 실패 20초 전 안에 GPU 오류가 나면 그 작업을 GPU 때문에 실패한 작업으로 분류했다.

A100 과 H100 은 uncorrectable ECC 메모리 오류를 주로 row remapping 으로 막는다. row remapping 은 고장 난 메모리 행을 예비 행으로 바꾸고 RRE 를 남긴다. 실제 교체는 다음 GPU 리셋 때 일어나고, 예비 행이 없으면 RRF 가 난다. 노드 중단을 줄이는 온라인 장치로 error containment 와 dynamic page offlining 도 있다. error containment 는 고장 난 메모리 주소를 쓰는 사용자 프로세스를 종료해 오류가 다른 애플리케이션으로 번지지 않게 하고, dynamic page offlining 은 GPU 리셋 없이 고장 난 페이지를 못 쓰게 표시한다. row remapping 이나 error containment 가 실패하면 GPU 리셋이나 노드 재부팅이 필요한 GPU 실패로 이어질 수 있다.

H100 은 uncorrectable ECC 메모리 오류 사이의 평균 시간인 MTBE 가 GPU 하나당 A100 보다 3.2배 낮았고, GB 당 MTBE 도 24% 낮았다. 논문은 그 주된 이유를 메모리 용량이 96 GB 대 40 GB 로 2.4배 커져 비트가 뒤집힐 기회가 늘어난 데서 찾았다. HBM3 의 신호 전압이 낮아 비트가 뒤집히기 쉬워진 것과 스택 수가 늘어 열을 빼기 어려워진 것도 가설로 들었다. 복구 장치는 H100 에서 uncorrectable 메모리 오류의 영향을 92% 의 경우에 덜어 GPU 를 계속 쓸 수 있게 했다. 하지만 row remapping 에 쓸 예비 행은 용량이 2.4배 늘어도 같은 512행이었다. H100 은 RRE 가 훨씬 잦았고, 운영 초기에 예비 행이 바닥나 RRF 가 8건 났다. Contained ECC, GPU DBE, Row remapping failed, Row remapping event 를 만난 H100 작업은 모두 실패했다. 146일 동안 H100 두 장이 uncorrectable 메모리 오류와 row remapping 실패로 교체됐고, A100 은 895일 동안 부팅 실패로 네 장이 교체됐다. GPU 노드당 가용성은 H100 이 약 99.3%, A100 이 약 99.4% 로 하루 9~10분의 다운타임에 해당했다.

심각도
–
영향 범위
Delta's 608 H100 GPUs over 146 days: 24 uncorrectable ECC memory errors, failed user jobs, and 19 hours of node unavailability in one incident
영향 사용자
Delta users from universities running HPC and ML jobs
지역
–
감지까지
–
복구까지
–

증상

Delta 의 H100 GPU 에서 uncorrectable ECC 메모리 오류가 나면 그 GPU 에서 돌던 사용자 작업이 실패했다. 노드 시스템 로그에는 XID 48 같은 XID 오류가 남았고, 복구하는 동안 노드는 새 작업을 받지 못했다.

오류는 XID 48 double bit ECC 메모리 오류, 같은 메모리 위치의 consecutive single-bit ECC 오류, XID 63 row remapping event, XID 64 row remapping failure, XID 94 Contained Memory Error, XID 95 Uncontained Memory Error 로 나타났다. H100 을 관찰한 146일 동안 uncorrectable ECC 메모리 오류는 24건이었고, 그 가운데 double bit ECC 오류인 DBE 가 17건, 같은 위치의 single-bit 오류가 잇따른 consecutive SBE 가 7건이었다. 같은 기간 row remapping event 인 RRE 는 16건, row remapping failure 인 RRF 는 8건, Contained Memory Error 는 14건, Uncontained Memory Error 는 19건이었다.

H100 의 메모리 오류는 A100 보다 잦았다. uncorrectable ECC 메모리 오류 사이의 평균 시간인 MTBE 는 GPU 하나당 H100 이 88,768 시간, A100 이 283,271 시간으로 H100 이 3.2배 낮았다. GB 당 MTBE 는 H100 의 HBM3 가 8,521,728 시간, A100 의 HBM2e 가 11,330,826 시간으로 24% 낮았다. uncorrectable ECC 메모리 오류의 H100 시스템 전체 MTBE 는 146 시간이었다.

오류를 만난 작업은 거의 모두 실패했다. H100 에서 Contained ECC 를 만난 작업 5개, GPU DBE 를 만난 작업 5개, Row remapping failed 를 만난 작업 3개, Row remapping event 를 만난 작업 2개가 모두 실패해 실패 확률이 100% 였다. error containment 가 오류를 막아도 그 작업은 종료됐고, 한 사례에서는 노드 재부팅으로 노드가 2분 내려갔다.

복구도 오래 걸릴 수 있었다. XID 48 이 난 한 사례에서는 작업이 실패한 뒤 row remapping 을 마치려고 노드를 drain 하고 GPU 를 리셋해야 했고, 오류를 감지하고 복구를 마치기까지 19시간 동안 노드가 새 작업을 받지 못했다. 실패한 노드를 복구하는 데 드는 예상 시간은 H100 이 2.2 시간, A100 이 0.88 시간이었다.

복구 장치는 따라가지 못했다. H100 에서 uncorrectable ECC 메모리 오류로 시작된 RRE 의 성공률은 0.59 였고, error containment 는 8% 의 경우에 실패했다. H100 은 운영 초기에 이미 RRF 를 8건 냈는데, 이는 예비 메모리 행이 바닥나 메모리 복구가 실패했다는 뜻이다. 훨씬 오래 운영한 A100 에서는 RRF 가 한 건도 없었다.

증상 GPU 인식 불가학습 작업 실패

원인

원인 하드웨어 고장

구성 요소 GPU 하드웨어·메모리
기여 요인 –
촉발
–

감지

노드 시스템 로그에 XID 오류와 복구 이벤트가 기록됐다. Delta SRE 는 uncorrectable ECC 메모리 오류와 오류 복구 실패를 계속 모니터링해 고장 난 GPU 를 제때 교체한다.

조치

후속 조치

–

교훈

논문은 H100 에서 복원력이 가장 취약한 부분이 메모리이고, 메모리 오류 복구 장치가 늘어난 메모리 용량과 그만큼 늘어난 row remapping 이벤트를 감당하지 못한다고 밝혔다. uncorrectable 메모리 오류 하나가 여러 GPU 를 쓰는 작업을 실패시킬 수 있어서, 큰 규모에서 이런 경우에도 작업을 멈추지 않게 하는 일은 아직 풀리지 않은 과제다. MMU 와 NVLink 오류를 빼면 애플리케이션 수준의 복구로는 GPU 오류를 다루지 못했으므로 GPU 메모리와 하드웨어 수준에서 복원력을 높여야 한다. 체크포인트는 관리, 저장, 복원을 합쳐 최대 40% 의 오버헤드가 든다. 608장의 H100 을 한 달 쓰는 작업이 작업 수준 가용성 99.9% 를 지키려면 복구 시간이 2.2시간일 때는 GPU 를 5% 더 확보해야 하지만, 복구 시간을 5분으로 줄이면 2% 만 더 있으면 된다. 그래서 복구 시간을 줄이는 일이 중요하다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: GPU 하드웨어·메모리. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.