사례8건

8건 중 1~5번째

1. IL-0477 Tencent의 1만 GPU MoE 학습에서 계산이 느려진 노드 때문에 스텝 시간이 30초에서 90초 넘게 늘었다

   Tencent2026

   증상

   GPU 약 10,000개로 돌던 MoE 학습 작업의 반복 시간이 약 30초에서 90초 넘게 늘어 ARGUS의 L1 단계가 알림을 냈다. L1은 랭크마다 반복 시간 시계열을 모아 급등과 계단식 성능 저하를 찾는 단계다.

   처리량 저하

   원인

   하드웨어 고장

   구성 요소

   –

   기여 요인

   미검증 가정

   감지

   ARGUS의 L1 단계가 반복 시간이 약 30초에서 90초 넘게 늘어난 것을 잡아 알림을 냈다. 이어서 L2 단계가 DP 그룹 안의 랭크별 mlp 단계 소요 시간을 비교해 랭크 10352~10359를 찾았다.

   조치

   • 영향받은 노드를 교체했고, 교체 직후 학습 속도가 회복되었다.

   교훈

   인프라 수준에서 보이는 통신 이상이 꼭 네트워크 하드웨어에서 생긴 것은 아니다. 계산 성능 저하가 집합 통신의 의존성을 타고 번져 통신 이상처럼 보일 수 있다. 세밀한 가시성이 없으면 운영자가 문제를 잘못 진단하고 효과 없는 조치를 할 위험이 있다. 1만 GPU 넘는 학습 클러스터에서 느려지는 고장의 형태는 매우 다양해서 진단 단계 하나로는 모든 경우를 다룰 수 없다.

   사례 보기
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-0586 T0 스위치 트랜시버의 링크 네 개가 연달아 플래핑해 50K GPU 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다

   OpenAI2026

   증상

   OpenAI 의 Cluster A 에서 50K GPU 로 돌던 운영 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다. 같은 시각 T0 스위치 한 대의 광 트랜시버에 달린 링크 네 개가 짧은 간격으로 연달아 내려갔다 올라왔다.

   링크 플래핑처리량 저하

   촉발

   T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 그 트랜시버의 링크 네 개가 짧은 간격으로 연달아 플래핑했다.

   원인

   하드웨어 고장

   구성 요소

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

   기여 요인

   –

   감지

   NIC 와 T0 스위치가 각각 링크가 내려간 것을 기록했고, 두 기록의 시각은 정확히 같지 않았다. 작업 처리량 그래프와 노드별 패킷 손실률 그래프에 이 사건이 나타났다.

   조치

   • MRC 가 플래핑으로 잃은 패킷을 빠르게 복구해서 작업이 받은 영향은 비교적 작았다.

   교훈

   논문은 NIC 와 T0 사이의 링크를 잃으면 성능이 떨어진다고 했다. 다만 이런 사건은 대부분 잠깐이고, 작업이 노드를 빼지 않고도 금방 원래 속도로 돌아오는 경우가 많다고 했다. NIC 와 T0 사이의 링크와 T0 스위치는 눈에 띄는 영향을 주므로 T1 스위치보다 더 조심해서 다뤄야 한다고 했다. 단일 장애 지점도 남아 있다고 했다. 800 Gb/s NIC 광 모듈을 200 Gb/s 링크 네 개로 나눠 쓰므로 NIC 쪽 트랜시버 자체가 플래핑하면 그 NIC 의 포트를 모두 잃는다. 그러면 QP 가 실패하므로 작업이 이 상황을 견디지 못한다. 논문은 다른 광 설계를 쓰면 이 문제를 아예 피할 수 있을 것이라고 했다.

   사례 보기
4. IL-0476 ByteDance의 128대 V100 학습 작업이 머신 한 대의 PCIe 저하로 40분 동안 크게 느려졌다

   ByteDance2025

   증상

   128대 머신으로 돌던 분산 학습 작업이 멈추지는 않고 40분 동안 심하게 느려졌다. 수천 개의 V100 GPU가 그동안 계산 자원을 다 쓰지 못한 채 느리게 돌았다.

   처리량 저하

   촉발

   머신 한 대의 PCIe 링크가 6.4Gbps에서 4Gbps로 떨어졌다.

   원인

   하드웨어 고장

   구성 요소

   PCIe 링크InfiniBand 패브릭

   기여 요인

   한계 경보 부재

   감지

   작업이 멈추지 않아 알림이 오지 않았다. 여러 팀이 40분 동안 손으로 진단한 끝에 고장 난 머신을 찾았다.

   후속 조치

   • 모니터링 지표로 고장 난 머신을 자동으로 찾는 Minder를 설계하고 구현해 모든 분산 학습 작업에 배포한다.

   교훈

   작업이 완전히 멈출 때만 알리는 방식으로는 학습을 느리게만 하는 고장을 잡지 못한다. 엔지니어가 경험에 기대 볼 로그를 고르면 일부 내용을 빠뜨린다. 게다가 로그에는 GPU 전력, 온도, NVLink 대역폭, PFC 패킷 비율 같은 모니터링 지표가 없다. 여러 팀이 함께하는 수동 진단은 시간이 오래 걸린다. 분산 학습에서는 머신마다 부하가 고르게 나뉘므로 모니터링 지표도 비슷하게 움직이고, 한 머신만 다른 패턴을 몇 분 넘게 보이면 그 머신이 고장 났을 가능성이 높다.

   사례 보기
5. IL-0419 Vela 에서 GPU 768개로 돌던 Granite-20B 학습 작업의 스텝 시간이 거의 3배로 늘었다

   IBM2025

   증상

   Vela 에서 GPU 768개로 Granite-20B 를 학습하던 중 스텝 시간이 갑자기 거의 3배로 늘었고, 팀이 이 성능 저하를 알아챘다.

   처리량 저하

   촉발

   작업에 속한 노드 96대 가운데 한 대의 전원 카드에 문제가 생겼다.

   원인

   하드웨어 고장

   구성 요소

   서버 전원 공급 장치와 전력 제한

   기여 요인

   –

   감지

   학습 팀은 스텝 시간이 거의 3배로 늘어난 것을 알아챘다. 이 고장은 호스트를 죽이지 않고 작업을 느리게만 만드는 종류였다. 팀은 작업이 쓰던 노드 96대를 모두 디버깅해서 원인 노드를 찾았다.

   조치

   • 작업이 쓰던 노드 96대를 모두 디버깅해 전원 카드 문제로 전력을 낮춘 노드 한 대를 찾았다.

   후속 조치

   • AI 연구자와 시스템 관리자가 문제 노드를 빨리 찾고 버퍼 노드로 작업을 빨리 다시 시작할 수 있도록 인프라 계층에 경보를 더한다. 경보는 호스트 VM 로그, 애플리케이션 로그, 호스트 BMC 로그의 메시지로 만든다.
   • nvidia-smi 의 power break slowdown 같은 GPU 카운터로 전원 문제가 있는 노드를 찾는 검사를 Autopilot 에 넣고, Grafana 대시보드에 표시한다.

   교훈

   수백, 수천 개의 GPU 를 함께 쓰는 분산 학습에서는 노드 한 대의 성능만 떨어져도 작업 전체의 성능이 떨어진다. 그 상태는 느린 노드를 찾아 빼거나 고치기 전까지 이어진다. 호스트를 죽이지 않는 미묘한 하드웨어 고장도 작업을 실패시키거나 느리게 만들 수 있어서, IBM 은 로그 기반 경보와 Autopilot 의 주기 검사로 이런 노드를 먼저 찾는다. 이런 기능 덕분에 IBM 의 SRE 는 사용자가 신고하면 디버깅하던 방식에서 사용자가 알기 전에 먼저 알리는 방식으로 바뀌었고, 근본 원인을 찾는 시간을 2배 넘게 줄였다.

   사례 보기

원인별1