사례3건

3건 중 1~3번째

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-0238 PCIe A100 1만 장 규모의 Fire-Flyer 2 학습 클러스터에서 GPU Xid 오류와 InfiniBand 링크의 순간 끊김으로 학습 작업이 끊기고 실패했다

   DeepSeek2024

   증상

   DeepSeek-AI 의 Fire-Flyer 2 학습 클러스터에서 NVIDIA 드라이버가 운영체제의 커널 로그나 이벤트 로그에 GPU Xid 오류를 남겼다. 지난 1년 동안 Xid 오류는 12970건이었고, 그중 NVLink 오류인 Xid 74 가 5521건으로 42.57% 였다. InfiniBand 링크가 순간적으로 끊겨 애플리케이션 통신이 끊기고 작업이 실패하기도 했다.

   GPU 인식 불가링크 플래핑학습 작업 실패학습 발산과 손실 급등

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리InfiniBand 패브릭

   기여 요인

   –

   감지

   Xid 오류는 NVIDIA 드라이버가 운영체제의 커널 로그나 이벤트 로그에 남긴 메시지로 잡았다. 플랫폼의 자동 운영 시스템은 매주 노드에서 validator 를 돌려 하드웨어 이상을 찾았다. ECC 가 잡지 못한 계산 오류와 GPU 메모리 오류는 모델의 gradnorm 급등과 손실 폭발로 드러났다.

   조치

   • 메모리 ECC 오류인 Xid 63, Xid 64, Xid 94, Xid 95 는 A100 의 row remapping 기술 덕에 대부분 GPU 를 리셋하는 것만으로 풀었다.
   • 고칠 수 없는 GPU 오류인 Xid 44, Xid 48, Xid 61, Xid 62, Xid 69, Xid 79 는 GPU 리셋이나 노드 재부팅으로 지웠다.
   • GPU GSP 모듈이 실패한 Xid 119 가 난 GPU 는 fieldiag 테스트를 거쳐 대부분 RMA 로 보냈다.
   • 자동 운영 시스템이 매주 노드에서 validator 를 돌려 고장 난 노드를 스케줄링 플랫폼에서 뺐다.
   • 하드웨어 장애로 끊긴 학습은 보통 5분마다 비동기로 저장한 체크포인트에서 이어 돌렸고, 그래서 마지막 5분의 진행만 잃었다.

   교훈

   장치를 안정되게 하려면 문제가 터지기 전에 찾는 것이 가장 좋다. 하드웨어 장애를 빨리 찾아 분류하는 것이 클러스터 노드의 가동률과 사용률을 높이는 핵심이다. 애플리케이션의 성능과 정확도를 지키려면 GPU ECC 오류를 곧바로 처리해야 한다. Xid 74 는 되풀이되는 오류를 스트레스 테스트로 걸러 내는 것 말고는 막을 방법이 마땅치 않다. 소프트웨어 쪽 Xid 오류도 메모리 데이터 손상에서 생길 수 있으므로, 소프트웨어 버그가 아니라면 하드웨어 고장을 의심해야 한다. NVLink 는 단점도 있으므로 실제로 필요할 때 설치해야 한다.

   사례 보기
3. IL-0239 LLM 개발 클러스터 Acme 의 Seren 과 Kalos 에서 사전 학습 작업이 하드웨어, 네트워크, 프레임워크 오류로 자주 실패해 학습 진행을 잃었다

   Shanghai AI Laboratory2024

   증상

   Shanghai AI Laboratory 의 LLM 개발 클러스터 Seren 과 Kalos 에서 장기 사전 학습 작업이 오류로 끝나거나, 손실이 갑자기 올라 돌아오지 않거나, 오류 없이 멈춰 섰다. 작업을 다시 시작하면 마지막 체크포인트로 돌아가 그 뒤의 학습 진행을 잃었다. 전체 작업의 약 40% 가 실패로 끝났다.

   학습 작업 실패GPU 인식 불가NCCL 타임아웃학습 발산과 손실 급등

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCL학습 데이터 로더오브젝트 스토리지데이터센터 전력·냉각

   기여 요인

   –

   감지

   팀은 실행 로그의 stdout 과 stderr, Prometheus 와 NVIDIA DCGM, IPMI 에서 15초 간격으로 모은 하드웨어 모니터링 데이터로 장애를 살폈다. 규칙과 LLM 을 함께 쓰는 진단 시스템이 실행 로그에서 오류를 뽑았고, 사람이 그 결과를 확인하고 바로잡았다. loss spike 는 사전 학습 프레임워크가 자동으로 잡았다. 오류 없이 멈춘 작업은 사용자가 직접 들여다보고서야 알았다.

   조치

   • 기존 LLM 프레임워크에 자동 복구가 없어 개발자가 끊긴 학습 작업을 손으로 다시 시작했다. 개발자들은 사전 학습을 제때 끝내려고 돌아가며 당직을 섰다. 작업은 마지막 체크포인트에서 다시 시작했다.
   • 123B 모델 학습에서 프레임워크를 고치고 체크포인트 저장 간격을 줄였다. 작업을 끝내기 전에 그때까지의 학습 결과를 저장하는 기능도 넣어 롤백으로 잃는 학습 진행을 줄였다.
   • 클러스터의 냉각 능력을 높여 과열로 생기던 NVLinkError 와 ECCError 를 크게 줄였다.
   • 자주 나는 NVLinkError 를 빨리 풀려고 두 단계 NCCL 테스트를 썼다. 먼저 모든 노드를 두 대씩 묶어 allgather 를 돌렸다. 그다음 실패한 묶음의 노드를 정상 노드와 다시 묶어 allgather 를 돌려 결함 노드를 찾고 격리했다.
   • 사전 학습 프레임워크가 loss spike 를 잡으면 더 앞의 정상 체크포인트에서 다시 시작하고 그 뒤의 데이터 배치를 건너뛰었다.
   • InternEvo V2 코드에서 Python 가비지 컬렉터 인터페이스로 가비지 컬렉션 시점을 직접 정했다. rank 마다 가비지 컬렉션 간격을 고정해 시점이 무작위로 몰리지 않게 했다.
   • num_worker=0 으로 설정하고 dataloader 의 가비지 컬렉션을 켜서 Dataloader Worker Killed 를 피했다.

   후속 조치

   • 장애 진단에 지금 쓰는 GPT-4 를 자체 LLM 으로 바꿀 계획이다.
   • 인프라를 업그레이드하면서 특히 NIC 를 개선하고, 더 큰 규모의 사전 학습을 위해 컴퓨팅 클러스터를 넓힌다.

   교훈

   인프라 장애가 가장 큰 피해를 냈다. 장기 사전 학습 작업에서 흔한 인프라 장애는 학습 효율을 크게 떨어뜨린다. 그래서 빠르게 진단하고 복구하는 것이 학습 효율을 높이는 데 결정적이다. 오류 없이 멈추는 작업과 사람이 손으로 재시작하는 부담을 보면, 문제가 있는 작업을 스스로 찾아 바로잡는 장애 처리 시스템이 필요하다. 실패한 작업의 로그를 규칙과 정규식으로 거르는 흔한 방법은 오류 로그가 너무 다양하고 복잡해 자주 틀렸다. 오류 문구가 없거나 여러 오류가 함께 찍히는 경우가 많아, 모든 경우를 규칙으로 맞추는 것은 현실적이지 않았다. GPU 온도가 높게 나타난 것은 클러스터 냉각 시스템을 개선해야 한다는 뜻이었다.

   사례 보기

원인별1