사례9건

9건 중 1~5번째

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 는 하드웨어 수명 내내 나타나므로 장비를 계속 지켜봐야 한다.

   사례 보기
2. IL-0478 GPU 한 개의 네트워크 어댑터가 고장 났는데 NCCL이 알림 없이 통신을 우회시켜 MoE 학습 스텝이 느려졌다

   Amazon2026

   증상

   대규모 MoE 학습의 스텝 시간이 약 0.3초 늘어 8.4초가 아닌 8.7초가 걸렸다. 하드웨어 고장 알림은 없었고, 노드는 표준 상태 점검을 통과했다.

   처리량 저하

   촉발

   노드 안 GPU 한 개에 배정된 고대역폭 네트워크 어댑터가 고장 나 내려갔다.

   원인

   하드웨어 고장

   구성 요소

   NCCLNIC·케이블·스위치 포트 링크

   기여 요인

   모니터링 사각지대

   감지

   하드웨어 고장 알림은 없었다. network packets transmitted 지표에서 남은 어댑터의 트래픽이 비정상적으로 높게 나타났고, GPU와 NIC의 배정을 보니 GPU7의 통신이 NIC 0으로 나가고 있었다.

   조치

   • 성능이 떨어진 통신 경로를 바로잡았고, 학습 스텝 시간이 8.7초에서 8.4초로 줄었다.

   후속 조치

   • 네트워크 장치의 링크 상태를 계속 모니터링해, 성능 저하가 번지기 전에 영향받은 노드를 찾아 격리한다.
   • 온라인 모니터링이 표시한 노드는 정상 노드 풀에서 빼고 오프라인 검증 일정을 잡는다.
   • 노드 사이 집합 통신에 부하를 거는 다중 노드 스윕을 돌려, 성능이 떨어진 링크와 통신 라이브러리의 우회를 찾는다.
   • 모든 노드를 주기적으로 스윕하지 않고, 온라인 모니터링이 이상을 찾았을 때나 수리를 마친 뒤에 스윕을 실행한다.

   교훈

   NCCL의 대체 경로는 작업 실패를 막지만 하드웨어 문제를 가린다. 짧게 도는 NCCL 테스트와 GPU burn-in은 기능의 정확성만 확인하므로, 점검을 통과한 노드도 실제 학습에서는 계속 뒤처질 수 있다. 동기화가 많은 MoE 학습에서는 1초도 안 되는 차이가 층과 스텝을 지나며 큰 효율 손실로 쌓인다. 그래서 학습 중에 성능을 보는 모니터링과, 노드를 다시 서비스에 넣기 전의 독립된 오프라인 검증이 함께 필요하다.

   사례 보기
3. IL-0421 Alibaba 의 LLM 학습 클러스터에서 GPU 결함을 비롯한 오류로 작업이 거듭 죽어 2023년 6월 한 작업이 시간의 31.19% 를 잃었다

   Alibaba Group2025

   증상

   GPU 수천 개로 도는 LLM 학습 작업이 자주 죽었고, 사용자 눈에는 원인 대부분이 "NCCL Error" 로만 보였다. 새로 배포한 클러스터에서 GPU 4,096개를 쓰는 대표 작업은 한 달에 40번 죽었다.

   학습 작업 실패NCCL 타임아웃GPU 인식 불가

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCLPyTorch

   기여 요인

   모니터링 사각지대미검증 가정

   감지

   사용자는 작업이 죽은 뒤 대부분 "NCCL Error" 로만 오류를 봤고, 오류가 난 뒤에도 작업이 멈춘 줄 바로 알지 못했다. PyTorch 작업은 elastic agent 가 프로세스를 죽일 때까지 최대 30분 동안 멈춰 있을 수 있었다. 원인을 찾고 결함 노드를 가려내는 일은 사람이 직접 했다. C4D 를 배포한 뒤에는 C4 에이전트가 학습 워커의 상태를 중앙 마스터로 보내고, 마스터가 워커끼리 비교해 이상을 수십 초 안에 찾았다.

   조치

   • GPU 1,024개, 곧 서버 128대마다 백업 서버 8대, 곧 백업 GPU 64개를 더 두었다. 그래서 서버 136대 풀 안의 어느 128대로도 같은 통신과 성능으로 학습을 이어 갈 수 있었다.
   • C4D 가 이상을 찾으면 작업 관리 서비스가 문제 노드를 격리하고 가장 최근의 유효한 체크포인트에서 작업을 다시 시작했다. 같은 이벤트를 백그라운드 근본 원인 분석 시스템으로 보내 오프라인으로 진단했다.
   • 고성능 인프라를 활용해 체크포인트를 더 자주 저장하게 했고, 사용자는 10분마다 체크포인트를 저장할 수 있게 되었다. 마지막 체크포인트 뒤에 잃는 시간이 33배 줄었다.
   • GPU 과열을 막으려고 팬 속도를 높이고 공조를 개선해 냉각을 강화했다.
   • 여섯 달 동안 시스템에서 가장 취약한 부품을 찾아 보강했고, 평균 오류율이 3.33배 줄었다.

   후속 조치

   • 전문가 병렬처럼 워커 사이의 부하가 고르지 않은 경우에도 느린 워커를 정확히 찾도록 C4D 에 부하 변동을 반영한다.

   교훈

   작업을 죽인 오류의 대부분은 특정 노드나 장치에 국한되어 있어서, 결함 부품만 격리하면 다수의 오류에 대처할 수 있었다. 분산 학습은 데이터 병렬 묶음 안의 계산 비용이 고르고 이터레이션마다 동기화하므로, 이 성질을 이용하면 결함 노드를 자동으로 찾을 수 있다. Alibaba 는 결함을 찾으면 곧바로 격리하고 다시 시작했으며, 깊은 원인 분석은 오프라인으로 미뤘다. 그러자 사람이 개입할 일이 없어져 수십 분 걸리던 일이 몇 초로 줄었다. 마지막 체크포인트 뒤에 잃는 시간을 줄이려면 체크포인트를 자주 저장해야 한다.

   사례 보기
4. IL-0479 가속기 노드의 조용한 데이터 손상이 오류 신호 없이 LLM 학습의 계산값과 기울기와 가중치를 바꿨다

   Amazon Web Services2025

   증상

   클라우드 플랫폼의 플릿 관리 테스트가 가속기 노드 15대를 SDC 때문에 운영에서 뺐다. SDC는 조용한 데이터 손상으로, 하드웨어가 아무 오류 신호 없이 틀린 계산 결과를 내는 고장이다. 이 노드들에서 학습해도 학습 손실은 대부분 정상 노드와 똑같이 나왔다.

   학습 발산과 손실 급등

   원인

   하드웨어 고장

   구성 요소

   –

   기여 요인

   모니터링 사각지대

   감지

   클라우드 플랫폼의 플릿 관리 스트레스 테스트가 SDC를 보인 노드를 잡아 운영에서 뺐다. 이 테스트는 결정적으로 실행한 작은 LLM 학습의 결과를 미리 계산한 정답과 비교해, 정답과 다르거나 실행마다 결과가 달라지면 SDC로 본다. 학습 손실만 봐서는 SDC가 드러나지 않았다.

   조치

   • 운영 마진 스트레스 테스트에서 떨어진 노드를 운영 가용 풀에 넣지 않았다.
   • 연구를 위해 잠시 붙잡아 둔 비정상 노드를 수리에 넘겨 운영 풀로 돌려보내기 시작했다.

   교훈

   SDC는 학습 손실에 뚜렷한 신호 없이 일어날 수 있다. Node 10의 SDC는 하위 모듈 계산과 기울기를 꾸준히 흔들었지만 학습 손실은 사전 학습과 미세 조정 내내 정상 노드와 같았다. 따라서 손실이 튀기 전에 SDC가 얼마나 오래 학습에 영향을 줬는지 알 수 없다. 학습 손실만 모니터링해서는 SDC를 놓칠 수 있고, 극단적인 경우 손실이 튀며 모델이 완전히 망가진다. 체크섬을 붙인 행렬 곱셈인 ABFT로는 SDC를 높은 정밀도와 재현율로 잡지 못했다. 그래서 그림자 데이터 병렬 복제본으로 다시 계산해 기울기를 비교하는 방법이 실제로 SDC를 잡는 가장 나은 방법일 수 있다.

   사례 보기
5. IL-0411 헬스 체크를 통과하는 레몬 노드가 Meta 연구 클러스터의 학습 작업을 거듭 실패시켰다

   Meta2024

   증상

   헬스 체크에 걸리지 않는 특정 노드들에서 학습 작업이 평균보다 자주 실패했다. 작업이 실패해 다시 스케줄되면 이 노드들이 새 작업을 또 받았고, 그 작업도 결국 실패했다. 논문은 이런 노드를 레몬 노드라고 불렀다.

   학습 작업 실패

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리Slurm 작업 스케줄러

   기여 요인

   모니터링 사각지대

   감지

   팀은 일부 노드의 작업 실패율이 평균보다 높다는 것을 보고 문제를 알았다. 실패율이 특정 노드에 몰려 있었지만, 통계적으로 의미 있게 판단하려면 오랜 기간의 실패 기록을 봐야 해서 빨리 찾기는 어려웠다.

   조치

   • 레몬 노드를 미리 찾아 Slurm 에서 격리하고 교체하는 레몬 노드 탐지를 설계해 넣었다.
   • 레몬 노드 탐지로 RSC-1 의 24대와 RSC-2 의 16대, 모두 40대의 결함 노드를 찾아냈다.

   교훈

   논문은 결함 있는 노드를 찾으려면 과거 기록이 꼭 필요하다고 밝혔다. 레몬 노드 탐지를 넣으면 대형 작업의 완료율을 30% 넘게 높일 수 있다. 결함 있는 노드에 작업이 거듭 스케줄되면 실패가 잇따르므로, 그런 노드를 확실히 빼낼 수 있어야 무작위 고장에서 회복하는 장치도 제대로 효과를 낸다. 노드를 빼는 부담을 ML 개발자에게 맡기지 않고 레몬 노드를 미리 찾아야 한다.

   사례 보기

원인별1