사례2건

2건 중 1~2번째

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

   ByteDance2025

   증상

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

   처리량 저하

   촉발

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

   원인

   하드웨어 고장

   구성 요소

   PCIe 링크InfiniBand 패브릭

   기여 요인

   한계 경보 부재

   감지

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

   후속 조치

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

   교훈

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

   사례 보기
2. IL-0420 Vela 의 GPU 노드에서 PCI-E 링크가 낮은 세대 속도로 떨어져 학습 작업이 몇 % 에서 2배까지 느려졌다

   IBM2025

   증상

   Vela 의 GPU 노드는 PCI-E Gen3 와 Gen4 링크를 쓴다. 그런데 때때로 링크 성능이 4 GB/s 처럼 PCI-E Gen 1 과 비슷한, 더 낮은 세대 수준으로 떨어졌다. 이 노드가 낀 학습 작업은 몇 % 에서 2배까지 느려졌다.

   처리량 저하

   원인

   unknown

   구성 요소

   PCIe 링크

   기여 요인

   –

   감지

   Autopilot 이 모든 노드에서 NVIDIA 의 CUDA 코드로 PCI-E 링크를 주기적으로 시험했다. 이 시험은 가벼워서 고객 워크로드를 거의 방해하지 않았다. 워크로드와 시험이 같은 자원을 두고 다퉈 생기는 오탐을 막으려고, 한 시간마다 모은 값 12개의 평균이 임계값 아래로 떨어질 때만 경보를 냈다. 링크가 저하된 노드는 Grafana 대시보드에 표시되었다. 임계값은 PCI-E 링크 세대마다 다르다.

   조치

   • 95% 이상의 경우 PCI-E 장치를 재설정해 문제를 풀었다. 재설정은 주로 VM 을 재부팅해서 했다.
   • VM 을 주기적으로 재부팅했다.

   후속 조치

   • Autopilot 으로 NVIDIA 의 CUDA 코드를 써서 PCI-E 링크 검사를 주기적으로 돌리고, 12시간 평균으로 경보를 낸다.
   • PCI-E 링크 저하의 근본 원인을 계속 조사한다.

   교훈

   수백, 수천 개의 GPU 를 함께 쓰는 분산 학습에서는 노드 한 대의 성능만 떨어져도 작업 전체가 느려진다. 그래서 IBM 은 작업이 도는 동안에도 가벼운 검사를 모든 노드에서 주기적으로 돌려, 성능을 서서히 떨어뜨리는 링크 저하를 미리 찾는다. 이런 검사와 경보 덕분에 SRE 는 사용자가 신고하면 디버깅하던 방식에서 사용자가 알기 전에 먼저 알리는 방식으로 바뀌었고, 근본 원인을 찾는 시간을 2배 넘게 줄였다.

   사례 보기

원인별2