사례2건
2건 중 1~2번째
- 증상
학습 작업은 멈추지 않았지만 처리량이 떨어졌고, 그 작업이 쓰는 모든 GPU 의 SM 사용률이 같은 순간에 함께 떨어졌다. 이런 fail-slow 는 수십 초에서 열 시간 가까이 이어졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
당시 현장에서는 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 가 얼마나 오래, 얼마나 심하게 이어질지에 달렸지만 이는 미리 알 수 없다.
- 증상
96개 노드에서 돌던 GLM-130B 사전 학습이 2022년 5월과 6월 내내 노드 고장, GPU 누락, 연결 끊김으로 여러 번 멈췄다. 2022-05-30 에는 재시작이 데이터 로딩에서 멈춰 더 나아가지 않았다.
- 촉발
학습 중에 계산 노드가 고장 나거나 연결이 끊기거나 GPU 를 잃었고, 2022-05-30 재시작 때는 Lustre 파일 시스템 오류가 났다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
처리량 저하는 학습 flops 가 127T 로 전보다 낮은 것을 보고 알아챘다. Lustre 파일 시스템 오류는 재시작이 데이터 로딩에서 멈춘 것을 보고 찾아냈다. n30039 는 GPU 가 없다고 스스로 보고했다.
- 조치
- 노드가 고장 날 때마다 마지막으로 저장한 step 에서 학습을 다시 시작했다.
- 체크포인트 저장 간격을 500 step 에서 100 step 으로 줄였다. 500 step 은 너무 길었다.
- 다른 노드 풀로 옮겨 15600 step 에서 다시 시작했다.
- 교체해 넣은 n30076 에 알 수 없는 오류가 있다고 보고 16600 step 부터 이 노드를 뺐지만, 처리량은 달라지지 않았다.
- 2.3T 텍스트 말뭉치를 백업 디스크에서 파일 시스템으로 다시 복사했고, 며칠이 걸렸다.
이 2건에서 가장 많이 나오는 구성 요소: GPU 하드웨어·메모리, InfiniBand 패브릭. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.