Incident Library

IL-0249 Alibaba Group · 2024-10-16 (게시일)ai-infranetworking

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

Alibaba Group 과 홍콩과기대 연구자들은 노드 4,000대 이상, 이기종 GPU 10,000장 이상이 있는 공유 운영 클러스터에서 fail-slow 를 조사했다. fail-slow 는 학습이 멈추는 fail-stop 과 달리, CPU, GPU, 통신 링크가 동작은 하지만 자원 경합, thermal throttling, 전원, 네트워크 혼잡으로 성능이 떨어지는 장애다. 최신 대규모 학습은 반복이 끝날 때마다 동기화하므로 구성 요소 하나가 느려지면 학습 전체가 느려진다. 클러스터에는 NVIDIA H800 약 1,800장과 A100 2,600장이 있다. 노드는 spine-leaf 구조의 RoCE 네트워크로 연결되고, A100 과 H800 노드는 최대 4×200/400 Gbps 대역폭을 쓴다. 연구자들은 운영 작업을 직접 계측할 수 없었다. 그래서 같은 작은 학습 작업을 spot 작업으로 반복 제출해 프로브로 썼고, GPU 512장 이상을 쓰는 대규모 학습 작업의 한 달 치 기록을 손으로 살폈다.

단일 노드 프로브 작업 392개 중 6개가 연산 fail-slow 를 겪었다. 4개는 CPU 경합, 2개는 GPU 성능 저하 때문이었다. 이 fail-slow 는 평균 약 10분 이어졌고 작업 완료 시간을 11.79% 늘렸다. 노드 4개짜리 프로브 작업 107개 중 43개가 fail-slow 를 겪었다. 1개는 CPU 경합, 42개는 네트워크 혼잡 때문이었다. 이 fail-slow 는 평균 약 24분 이어져 완료 시간을 15.45% 늘렸다. 2024년 7월에 제출된 GPU 512~1024장짜리 학습 작업 27개 중 16개가 fail-slow 를 겪었다. 평균 지속 시간은 72분이었고, 평균 완료 시간이 34.59% 늘었다. 이 중 20% 는 50% 넘게 늦어졌다. 13개는 네트워크 혼잡이, 나머지는 네트워크와 GPU 저하가 함께 원인이었다. 학습 노드를 단독으로 썼기 때문에 CPU 경합은 없었다.

연구자들은 fail-slow 가 대개 일시적이고 연산 저하와 통신 저하에서 온다고 정리했다. 연산 저하는 느린 GPU 나 CPU 경합에서, 통신 저하는 주로 네트워크 혼잡에서 왔다. 연산 fail-slow 는 짧고 드물어 성능 저하가 작지만, 노드 사이 통신 fail-slow 는 더 잦고 오래 이어져 학습을 크게 늦췄다. 학습 규모가 커질수록 여러 성능 문제가 겹칠 가능성이 높아지고, 겹치면 학습이 90% 넘게 느려질 수 있다. 당시 현장에서는 fail-slow 를 손으로 찾아 fail-stop 처럼 체크포인트에서 재시작했다. 연구자들은 이 방식에 품과 시간이 많이 든다고 보고 Falcon 을 만들었다.

심각도
–
영향 범위
Training jobs on a shared production GPU cluster: slower iterations and longer job completion time, more than 50% longer for 20% of the large jobs inspected
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

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

CPU 경합 사례에서는 단일 노드 작업이 22분과 55분에 두 번 느려져 성능이 최대 21.6% 떨어졌고, GPU 네 장의 SM 사용률이 동시에 내려가 GPU 가 느려진 것처럼 보였다. 작업을 멈추고 행렬 연산으로 GPU 성능을 재 보니 떨어진 것이 없었다. 느려진 시점은 같은 노드에서 CPU 를 많이 쓰는 작업이 갑자기 늘어난 시점과 겹쳤다. 학습 작업이 필요한 CPU 를 충분히 받지 못해 CPU 시간이 늘고 처리량이 줄었다.

GPU 성능 저하 사례에서는 작업이 처음 10분 동안 느려졌고 GPU 네 장 모두 사용률이 낮았다. 프로파일링하자 GPU0 이 다른 GPU 보다 20% 느렸고 온도가 70°C 가까이로 유난히 높았다. 온도가 오른다고 늘 성능 문제가 생기지는 않으므로, 이 경우는 하드웨어 문제일 수 있었다. 이런 문제의 발생률은 약 0.5% 였다.

네트워크 혼잡 사례에서는 노드 4개에 걸친 작업이 90분과 265분에 느려져 처리량이 0.57 iterations/s 에서 0.41 로, 다시 0.31 iterations/s 로 떨어졌다. GPU 여덟 장은 정상이었지만 SM 사용률이 동시에 내려갔다. NIC 가 보고한 혼잡 알림 패킷 CNP 가 급증한 시점은 학습이 느려진 시점과 강한 상관을 보였다. 통신 구성 요소 중 노드 사이 RDMA 링크의 지연 변동 계수가 0.29 로 가장 컸다.

GPU 1024장 규모에서는 두 종류의 저하가 겹쳤다. 한 작업은 62분에 심한 네트워크 혼잡으로 처리량이 80% 줄었고, 혼잡이 이어지던 80분 무렵 GPU thermal throttling 이 더해져 처리량이 정상의 10% 까지 떨어졌다. 120분부터는 다른 심한 혼잡이 약 두 시간 이어져 처리량이 다시 85% 줄었다.

증상 처리량 저하

원인

원인 용량 한계

구성 요소 InfiniBand 패브릭GPU 하드웨어·메모리
기여 요인 장애 중첩모니터링 사각지대
촉발
–

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: InfiniBand 패브릭, GPU 하드웨어·메모리. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.