Incident Library

IL-0482 NERSC · 2025-09-04 (게시일)ai-infra

Perlmutter와 Polaris의 A100 GPU에서 정정할 수 없는 메모리 오류가 하루 1,000건 넘게 몰려 터졌다

NERSC, NCSA, Argonne의 운영 인력이 함께 쓴 이 연구는 NVIDIA A100 GPU를 쓰는 운영 중인 슈퍼컴퓨터 Delta, Polaris, Perlmutter 세 대에서 모은 GPU 메모리 오류 기록 6,777만 GPU 시간 분량을 분석했다. 오류는 DCGM이 GPU마다 누적하는 ECC SBE와 DBE 개수가 늘어나는 것으로 찾았다. SBE는 ECC가 고치는 단일 비트 오류이고, DBE는 ECC가 잡지만 고치지 못하는 이중 비트 오류다. DBE가 나면 개수와 관계없이 ECC가 예외를 던져 GPU 애플리케이션이 종료되므로, DBE 이벤트 한 번이 작업 한 번의 중단이다.

DBE는 Polaris와 Perlmutter에서 특정한 날에 몰려 터졌다. 하루 DBE가 1,000건을 넘은 날이 Polaris는 4.55%, Perlmutter는 9.32%였다. 시스템 사이 오류율 차이는 천 배를 넘어, Polaris의 DBE 비율은 Delta의 2,555.56배였다. 오류를 겪은 GPU 수는 적어서 DBE가 난 GPU는 모든 시스템에서 0.53% 미만이었다. Perlmutter에서 SBE와 DBE를 모두 겪은 GPU 29개에서는 DBE 이벤트 대부분이 같은 날 같은 GPU의 SBE와 함께 났다. 오류가 많은 GPU는 몇 주 단위로 바뀌었고, 오류에 주기가 없었으며, 환경 요인과 강한 상관관계도 없었다.

대규모 모델 학습에서는 DBE 하나가 하드웨어 예외로 프로그램 전체를 멈추게 해도 SLURM 작업은 끝나지 않는다. 그래서 모니터링과 재시작이 늦으면 할당된 자원이 낭비될 수 있다. 저자들은 오류가 몰려 터지므로 고정 간격 체크포인트로는 부족하고, 오류 모니터링에 따라 간격을 바꾸는 동적 체크포인트가 필요하다고 보았다.

심각도
–
영향 범위
A100 GPUs on Perlmutter (7,604 GPUs) and Polaris (2,240 GPUs): DBEs on 35 and 68 GPUs, each DBE event terminating the GPU application
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

Perlmutter와 Polaris의 A100 GPU에서 ECC가 정정하지 못하는 이중 비트 메모리 오류인 DBE가 특정한 날에 몰려 쏟아졌다. DBE 이벤트가 나면 ECC가 예외를 던져 그 GPU의 애플리케이션이 종료되었다.

DCGM이 GPU마다 누적해 올리는 ECC SBE와 DBE 개수가 늘어나는 것으로 새 오류가 드러났다. Polaris에서는 하루에 DBE가 1,000건을 넘은 날이 전체의 4.55%였고 Perlmutter에서는 9.32%였다. Polaris에서는 2023년 10월 26일 하루에 DBE가 39,144건 나왔다. DBE가 없는 날은 Polaris가 66.02%, Perlmutter가 84.97%였다.

오류를 겪은 GPU는 많지 않았다. DBE가 난 GPU는 Perlmutter 7,604개 중 35개, Polaris 2,240개 중 68개였다. Perlmutter의 DBE 이벤트는 77건, Polaris는 44건이었다.

Perlmutter에서 SBE와 DBE를 모두 겪은 GPU는 29개였고, DBE 이벤트 대부분은 같은 GPU에서 같은 날 SBE가 함께 났다. SBE는 ECC가 정정하지만, 앞으로 DBE가 날 수 있다는 신호가 되었다.

오류율은 시스템마다 크게 달랐다. Polaris의 DBE 비율은 GPU 하루당 0.069로 Delta의 2,555.56배, Perlmutter의 8.41배였다. 오류가 많은 GPU는 시간에 따라 바뀌었고, 오류 발생에 주기는 보이지 않았다. 온도, 전력, GPU 사용률 같은 환경 요인과도 강한 상관관계가 없었다.

증상 GPU 인식 불가

원인

원인 하드웨어 고장

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

감지

DCGM이 GPU마다 ECC가 보고한 SBE와 DBE의 누적 개수를 주기적으로 갱신했고, 이 개수가 늘어나면 새 오류로 보았다. 기록 주기는 Polaris가 4초, Delta가 1분, Perlmutter가 1시간이었다.

조치

–

후속 조치

교훈

클러스터 하나의 결과만 믿으면 오류 특성을 크게 잘못 볼 수 있다. 오류가 몰려 터지므로 오류 사이 평균 시간인 MTBE 숫자 하나로는 복원력을 제대로 평가할 수 없고, 오류 간격의 분포를 봐야 한다. 기록 주기가 길어도 정보 손실은 크지 않지만, 짧은 주기로 모니터링해야 오류에 더 빨리 대응할 수 있다. SBE는 앞으로 날 DBE의 신호가 될 수 있다. 오류가 많은 GPU는 시간에 따라 바뀌므로, 과거에 오류가 많았던 GPU만 지켜보는 것은 좋은 전략이 아니다. 고정 간격 체크포인트는 안정성 요구를 못 맞추거나 부담이 크므로, 오류가 몰리는 패턴에 맞춘 동적 체크포인트가 필요하다. V100과 A100은 둘 다 HBM2를 쓰며 메모리 오류 특성이 비슷하다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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