사례1건

1건 중 1~1번째

1. IL-0249 공유 GPU 클러스터의 대규모 학습 작업이 멈추지 않은 채 느려지는 fail-slow 로 완료 시간이 평균 1.34배로 늘었다

   Alibaba Group2024

   증상

   학습 작업은 멈추지 않았지만 처리량이 떨어졌고, 그 작업이 쓰는 모든 GPU 의 SM 사용률이 같은 순간에 함께 떨어졌다. 이런 fail-slow 는 수십 초에서 열 시간 가까이 이어졌다.

   처리량 저하

   원인

   용량 한계

   구성 요소

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

   기여 요인

   장애 중첩모니터링 사각지대

   감지

   당시 현장에서는 fail-slow 를 사람이 손으로 찾았다. 조사에서는 프로브 작업이 실행 중에 성능 지표를 모아 연산과 통신 fail-slow 를 찾았고, 대규모 학습 작업의 한 달 치 기록은 연구자들이 손으로 살폈다. Meta 와 ByteDance 도 대규모에서는 fail-slow 를 찾기 어렵다고 보고했고, 다른 회사 엔지니어들의 의견도 같았다.

   조치

   • 당시 현장에서는 fail-slow 를 손으로 찾은 뒤 fail-stop 처럼 다뤄, 체크포인트를 남기고 학습 작업을 다시 시작하는 장애 조치로 대응했다.

   후속 조치

   • Falcon-Detect 를 만든다. Falcon-Detect 는 학습 프레임워크에 손대지 않고 워커마다 반복 시간을 추적한다. 시계열에서 변화 시점을 찾는 BOCD 알고리즘으로 반복이 길어진 시점을 찾고, 가벼운 프로파일링으로 의심되는 워커 그룹을 좁힌다. 그 뒤 학습을 잠깐 멈추고 벤치마크를 돌려 느린 GPU 와 링크를 찾아낸다.
   • Falcon-Mitigate 를 만든다. Falcon-Mitigate 의 대응은 네 단계다. 아무것도 하지 않기, 데이터 병렬 그룹 사이에서 micro-batch 다시 나누기, 병렬화 토폴로지를 바꿔 혼잡한 링크를 트래픽이 적은 그룹으로 옮기기, 체크포인트에서 재시작하기다. 비용이 낮은 단계부터 시작하고, fail-slow 가 이어지는데 지금 방법이 듣지 않으면 다음 단계로 넘어간다. 체크포인트에서 재시작하기는 마지막 수단이다.

   교훈

   fail-slow 는 대개 일시적이다. 연산 저하는 느린 GPU 나 CPU 경합에서 오고, 통신 저하는 주로 네트워크 혼잡에서 온다. 연산 fail-slow 는 짧고 드물지만 노드 사이 통신 fail-slow 는 더 잦고 오래 이어져 학습을 더 크게 늦춘다. 학습 규모가 커지면 여러 성능 문제가 동시에 생길 가능성이 커지고, 겹친 영향으로 학습이 90% 넘게 느려질 수 있다. fail-slow 는 대개 일시적이므로 체크포인트에서 재시작하는 fail-stop 대응은 지나치다. 어떤 대응이 맞는지는 fail-slow 가 얼마나 오래, 얼마나 심하게 이어질지에 달렸지만 이는 미리 알 수 없다.

   사례 보기

원인별1