사례1건

1건 중 1~1번째

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

   ByteDance2026

   증상

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

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

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리

   기여 요인

   모니터링 사각지대

   감지

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

   조치

   • 손실이 치솟은 사례에서는 학습을 멈추고 영향받은 노드를 오프라인으로 빼서 결함 GPU 가 있는지 확인했다.
   • SDCHunter 로 의심스러운 데이터 병렬 묶음을 먼저 떼어 내, 운영 학습 작업이 영향받은 장비를 벗어나 체크포인트에서 다시 시작하게 했다. 학습은 묶음을 뗀 뒤 1시간 안에 다시 돌았다.
   • 학습이 정상 장비에서 다시 돈 뒤, 경보를 낸 실행 기록을 오프라인에서 거듭 재실행하고 하드웨어 도구로 결과를 확인해 결함 장치를 확정했다.
   • 결함 GPU 는 1시간 안에 확정해 하드웨어 수리로 넘겼다.
   • 재현 가능한 학습을 위해 소프트웨어 스택의 결정성 설정을 모두 켰다. torch.backends.cudnn.benchmark 를 끄고, torch.backends.cudnn.deterministic 과 torch.use_deterministic_algorithms 를 켰다.

   교훈

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

   사례 보기

원인별1