Incident Library

IL-0416 ByteDance · 2026-07-13 (게시일)ai-infra

LLM 학습에서 SDC 결함이 있는 GPU 가 ECC 오류나 온도 경보 없이 계산을 조용히 망가뜨려 손실이 치솟거나 작업이 멈췄다

ByteDance Seed 와 상하이교통대 연구진은 ByteDance 의 운영 클러스터에서 회수한 SDC 결함 GPU 23개를 분석했다. SDC 는 오류 신호 없이 데이터가 바뀌는 현상이다. 이 GPU 들은 계산을 간헐적으로 망가뜨리는 미세한 하드웨어 결함을 안고 있었고, 같은 장치가 학습 작업을 거듭 망가뜨릴 수 있었다. CPU 와 GPU 메모리는 ECC 로 보호되어 SDC 의 원인이 아니었다. 작업이 예외로 멈추면 유효한 체크포인트에서 학습 상태를 되살리고 결함 하드웨어를 격리할 때까지 할당된 GPU 가 놀았다. SDC 가 손실 급등으로 나타나면 학습은 계속 돌면서 쓸 수 없는 체크포인트를 만들었다.

SDC 는 새 장비에서만 나지 않았다. 배포 전 번인 테스트에서 찾은 것은 25% 뿐이었다. 25% 는 배포 뒤 두 달 안에, 10% 는 여섯 달 안에, 40% 는 배포 뒤 1년 무렵에 나타났다. GPU 가 SDC 를 내기 시작하면 오류율은 대개 시간이 갈수록 올라갔다. 공급사 분석은 반복된 고강도 계산의 전기적 스트레스가 연산 회로의 저항 값을 서서히 바꿔 산술 오류를 낸다고 봤다. SDC 는 특정 커널과 데이터 유형과 입력 값에서만 났다. 처음 SDC 가 감지된 커널은 GEMM 과 InplaceMoE 가 각각 17.3%, FlashAttention 이 13.0% 였고, GEMM 에서는 FP64 와 FP32 CUDA 코어가 더 자주 틀렸다. 한 GPU 는 FP64 에서 결과가 100% 틀리고 계산 지연이 평소의 50배였고, 다른 GPU 는 특정 값 범위에서만 틀렸다. 결함 GPU 마다 같은 워크로드를 결정적으로 재실행했을 때 틀린 텐서가 나오는 비율은 100% 에서 0.000001% 까지 달랐다.

합성 벤치마크는 결함을 일으키는 데이터 패턴과 명령 순서를 갖추지 못해 결함을 놓쳤다. ByteDance 는 장애를 낸 학습 워크로드와 입력 데이터를 그대로 재실행해 결함 GPU 를 찾는 SDCHunter 를 만들었다. SDCHunter 는 난수 시드를 고정하고 결정적 GPU 커널을 강제하며 통신 순서를 고정해, 정상 하드웨어라면 비트 단위로 같은 결과가 나오게 한다. 먼저 데이터 병렬 차원을 따라 클러스터를 두 복제본으로 나누고, 파이프라인 경계에서 텐서 해시를 비교해 문제 있는 묶음을 몇 시간 안에 좁힌다. 그 묶음을 빼고 학습을 다시 시작한다. 그다음 오프라인에서 의심 묶음과 정상 기준 묶음으로 문제가 난 이터레이션을 재실행해 처음 어긋나는 텐서와 커널을 찾고 결함 GPU 를 가린다. 결정적 학습을 켜도 스텝 시간은 0.01% 안에서만 달라졌고, 정규화한 디버깅 시간은 70% 줄었다. SDCHunter 는 운영에서 SDC 사고 40건을 처리했고, 결함 GPU 40개를 찾았으며, 오프라인 진단 시간을 며칠에서 1시간 안으로 줄였다.

심각도
–
영향 범위
LLM training jobs crashed or produced corrupted checkpoints and had to be restored from a valid checkpoint; engineers spent days or weeks debugging software before the GPU was found
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

운영 중인 LLM 학습 작업이 shape mismatch 나 out-of-bound access 같은 예외로 갑자기 멈추거나, 학습은 계속되는데 손실이 크게 치솟았다. 하드웨어 쪽에서는 ECC 오류도 온도 경보도 없어서, 엔지니어 눈에는 소프트웨어 버그나 수치 불안정과 똑같아 보였다.

SDC 는 오류 신호 없이 데이터가 바뀌는 현상이다. ByteDance 가 SDC 를 확인한 GPU 23개 가운데 10개는 실제 워크로드로 돌린 오프라인 스트레스 테스트에서 수치 검증에 실패해 드러났고, 13개는 운영 중인 LLM 학습을 중단시키며 드러났다. 처음 감지된 오류는 Workload Test Error, Suboptimal Convergence, Unexpected CUDA Error, Shape Error, Value Error, Program Crash, 손실이나 출력의 NaN 이었다.

MoE 학습의 한 사례에서는 Megatron 이 토큰 수를 모아 버퍼 크기를 정하는 단계에서 SDC 가 계산을 바꿨고, 뒤이은 scatter 연산이 잘못되어 torch.split 에서 shape mismatch 오류가 났다. 다른 사례에서는 잘못 계산된 나머지 연산이 out-of-bound 접근을 만들어 임베딩 조회에서 segmentation fault 가 났다. 오류가 난 줄의 코드는 맞았고, SDC 는 이미 앞선 커널에서 프로그램 상태를 바꿔 놓은 뒤였다.

같은 클러스터에서 같은 체크포인트로 시작한 학습 10번 가운데 Run 1 과 Run 2 에서 손실이 크게 치솟았고, Run 3 과 Run 4 는 아무 문제 없이 돌았다. Run 5 와 Run 6, 그 뒤 Run 8 과 Run 9 에서 다시 손실이 치솟았는데, 앞선 실패와 전혀 다른 스텝에서였다. 코드 오류라면 대개 같은 지점에서 실패한다. 엔지니어는 무작위로 나타나는 큰 기울기 값을 보고 부동소수점 장치의 하드웨어 결함을 의심했다.

엔지니어는 하드웨어 결함이 드물다고 보고 학습 프레임워크의 논리 버그나 모델 구조의 수치 불안정부터 의심했다. 파이프라인 구성 요소를 하나씩 떼어 보고 오류를 재현하는 데 며칠에서 몇 주를 썼지만 헛수고인 경우가 많았다. 하드웨어 결함은 소프트웨어 쪽 가설을 모두 배제한 뒤에야 남은 답으로 떠올랐다. 업계에서 흔히 쓰는 하드웨어 진단 도구와 GEMM 반복 같은 합성 스트레스 테스트는 결함 GPU 의 60% 이상을 놓쳤다.

결함 GPU 의 실행 기록을 정상 장비와 비교해도 machine check exception, 성능 카운터, 장치 상태 레지스터에는 차이가 없었다. ECC 오류 수는 SDC 와 상관이 없었고, 클럭 주파수와 온도 한계에도 이상이 보이지 않았다.

증상 학습 발산과 손실 급등학습 작업 실패

원인

원인 하드웨어 고장

구성 요소 GPU 하드웨어·메모리
기여 요인 모니터링 사각지대
촉발
–

감지

운영 학습에서 드러난 13개는 두 가지 경로로 드러났다. shape mismatch, out-of-bound access 같은 예외로 작업이 바로 멈췄거나, 학습 중 손실이 치솟아 엔지니어가 학습을 손으로 멈추며 알아챘다. 나머지 10개는 운영 워크로드로 돌린 오프라인 스트레스 테스트의 수치 검증에서 걸렸다. 하드웨어 진단 도구와 ECC, 온도 센서는 SDC 를 잡지 못했다.

조치

후속 조치

–

교훈

ByteDance 는 세 가지를 배웠다고 정리했다. 첫째, SDC 진단은 따로 도는 하드웨어 테스트가 아니라 학습 컨트롤 플레인과 묶어야 한다. 사고 중에는 의심 장비를 학습 경로에서 빨리 빼고 장치 수준 확인은 오프라인으로 미루는 것이 가장 쓸모 있었다. 둘째, 결함 GPU 는 원래 이상을 낸 모델 커널, 데이터 범위, 통신 순서에서만 실패하는 경우가 많아 합성 스트레스 테스트보다 실제 워크로드 재실행이 효과적이었다. 셋째, 결정적 학습은 손실 급등 같은 모호한 증상을 재현 가능한 비교로 바꿔 데이터 문제, 모델 문제, 인프라 문제, 연산자 버그, 하드웨어 손상을 가려 준다. 결함 GPU 마다 SDC 발생률이 크게 달라서 정해진 시간 동안 돌리는 스트레스 테스트는 인수 기준이 되지 못한다. 경보를 낸 실행 기록은 보관했다가 드문 결함을 확인할 때 재실행해야 한다. SDC 는 하드웨어 수명 내내 나타나므로 장비를 계속 지켜봐야 한다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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