Databricks AI 전반에서 GPU 안정성을 유지하는 방법

분산 GPU 학습은 이제 업계 전반에서 일상적인 작업이 되었습니다. 이제 여러 팀에서 파운데이션 모델을 학습시키고, 프론티어 규모의 모델을 미세 조정(fine-tune)하며, 대규모 비전 시스템을 구축하고, 예전에는 최첨단 연구소만의 영역이었던 규모로 딥 추천 네트워크를 실행하고 있습니다.

오늘날의 규모를 감당할 수 있는 GPU 인프라를 구축하려면 많은 것을 올바르게 처리해야 합니다. 실행을 중단시키는 장애를 감지하고, 겉으로 드러나지 않는 느린 성능 저하를 찾아내며, 수천 개의 링크에서 패브릭 상태를 검증하고, 결국 고장 나기 마련인 하드웨어를 피해서 스케줄링하고, 장애가 발생했을 때 깔끔하게 복구하는 일 등이 그렇습니다. 이들 중 상당수는 기초적인 부분이며, 스택의 더 높은 곳에 있는 더 어려운 문제들이 이들에 의존하고 있습니다.

Databricks AI에서는 매주 대규모로 학습 워크로드를 실행하고 있으며, 이 과정에서 하드웨어, 패브릭, 소프트웨어 전반에 걸쳐 장애가 지속적으로 발생합니다. 이 시리즈에서는 이러한 규모에서 GPU의 안정성을 유지하기 위해 필요한 사항을 다룹니다. 첫 번째 포스트에서는 그 기초로서 GPU를 실행할 때 발생하는 장애 모드, 이를 드러내는 다양한 워크로드, 그리고 이를 잡아내는 다단계 헬스 체크 시스템을 소개합니다. 학습은 가장 까다로운 워크로드 클래스이자 이번 글의 핵심 주제이지만, 동일한 엔지니어링 기술이 Databricks의 추론 및 기타 GPU 워크로드에도 적용됩니다.

학습 부하 상황에서 GPU가 고장 나는 방식

대규모 환경에서 발생하는 대부분의 GPU 장애는 작업 중단(crashed jobs), 보이지 않는 성능 저하(silent slowdowns), 수치 손상(numerical corruption)의 세 가지 범주로 나뉩니다. 작업 중단은 발생 즉시 알 수 있다는 점에서 비교적 쉬운 케이스입니다. 더 까다로운 장애는 모델에 잘못된 수치가 포함된 채로 워크로드가 완료되거나, 아무도 모르게 몇 시간 동안 성능이 저하된 상태로 실행되는 경우입니다.

작업 중단. 분산 학습 작업은 GPU 성능 저하 또는 버스 이탈, RDMA 패브릭 문제, I/O 시스템 중단(hang), CPU 측 랭크(rank)의 분기 등 다양한 이유로 중단됩니다. 워크로드 관점에서는 이러한 문제 대부분이 동일한 현상으로 나타납니다. 즉, 로그에 악명 높은 NCCL watchdog timeout 메시지가 표시되며 작업이 중단되는 것입니다. 모든 랭크가 동일한 콜렉티브(collective)에서 차단되고, watchdog이 결국 작업을 강제 종료하면 마지막 체크포인트부터 다시 시작해야 합니다. 하지만 타임아웃 자체는 근본 원인에 대해 거의 아무것도 알려주지 않습니다. 실제로 무엇이 잘못되었는지 진단하려면 증상만 보여주는 스택 추적(stack trace)에서 시작하여 하드웨어, 패브릭, 파일 시스템, 소프트웨어 레이어 전체를 추적해야 하는 경우가 많습니다.

보이지 않는 성능 저하. 조용히 성능이 저하된 GPU는 로그가 정상으로 보이고 손실(loss)이 계속 감소하면서 학습을 계속 진행할 수 있습니다. 하지만 처리량(throughput)은 가장 느린 GPU에서 병목 현상이 발생하여 컴퓨팅 자원과 비용이 낭비됩니다. 이러한 속도 저하는 지속적인 부하로 인해 열 센서가 작동하거나, 지속적인 오류로 인해 상호 연결(interconnect) 링크의 등급이 낮아지거나, 결함이 누적되어 메모리 대역폭이 떨어지는 등 하드웨어가 저하된 상태로 실행될 때 발생합니다. 각각은 서로 다른 하드웨어 수준의 신호로 나타납니다. 예를 들어, 열 문제의 경우 DCGM 스로틀 원인인 HW_SLOWDOWN 또는 HW_THERMAL_SLOWDOWN으로 나타나거나, 상호 연결의 경우 링크 상태(link health)로 나타납니다.

수치 손상. 최신 GPU는 ECC(Error Correction Code)를 사용하여 학습을 중단하지 않고도 많은 일시적인 메모리 결함을 감지하고 자동으로 수정합니다. 하지만 모든 결함을 복구할 수 있는 것은 아닙니다. 손상은 메모리, 상호 연결, 커널 또는 소프트웨어 레이어에서 발생할 수 있으며, 감지되거나 차단되기 전에 전파될 수 있습니다. 이러한 경우 학습이 즉시 중단되거나 잘못된 값으로 계속 진행될 수 있습니다. 장애는 NaN 손실, 불안정한 수렴(convergence), 또는 나중에야 발견되는 모델 품질 저하 등으로 나타날 수 있습니다.

GPU 안정성을 확보하기 위한 당사의 접근 방식

GPU 하드웨어 장애 발생률은 CPU보다 한 자릿수(order of magnitude) 더 높을 수 있습니다. 보수적으로 대략 가정해 보면, 각 GPU의 연간 장애 발생률을 1%로 잡을 수 있습니다. T일 동안 N개의 GPU를 사용하는 작업의 경우, 최소 하나의 장애가 발생할 확률은 대략 다음과 같습니다.

256개의 GPU를 사용하는 작업을 30일 동안 실행할 때 장애가 발생할 확률은 약 19%입니다. GPU가 1,024개로 늘어나면 이 확률은 57%로 치솟습니다. 이 정도 규모에서는 실행 중 장애가 발생하는 것이 예외적인 일이 아니라 당연한 일입니다. 기본적으로 두 가지 엔지니어링 투자를 통해 이러한 장애에도 불구하고 안정적으로 학습을 유지할 수 있습니다. 첫째는 장애를 조기에 드러내는 다양하고 최첨단인 워크로드로 스트레스 테스트를 수행하는 것이고, 둘째는 전체 플릿(fleet)에서 장애를 잡아내는 다단계 헬스 체크 시스템을 운영하는 것입니다.

최첨단 워크로드로 플랫폼 스트레스 테스트하기

Databricks AI는 고객이 사용하는 것과 동일한 플랫폼에서 다음과 같은 다양하고 까다로운 학습 워크로드를 실행합니다. KARL과 같은 모델을 위한 강화 학습(RL) 학습, 에이전트 기반 코딩 모델(agentic coding models), 실제 서비스 환경의 PDF(PDFs in production)를 지원하는 문서 인텔리전스 시스템 등이 있습니다. 이는 일반적인 학습 작업이 아닙니다. RL 워크로드는 여러 GPU에 걸쳐 긴밀한 루프 내에서 학습, 추론, 보상 계산을 결합합니다. 에이전트 기반 코딩 모델은 학습과 함께 추론 집약적인 평가를 실행합니다. 문서 인텔리전스 파이프라인은 모델 학습과 대용량 이미지 기반 데이터 로딩을 결합합니다.

이러한 워크로드들은 각각 고유한 방식으로 플랫폼에 부하를 주므로, 패브릭 불안정성, 열 핫스팟, 콜렉티브 통신의 예외 상황(edge case)과 같은 운영상의 문제를 더 광범위한 프로덕션 워크로드에 도달하기 전에 효과적으로 드러내 줍니다.

최근에 발생한 한 가지 문제는 다음과 같았습니다. 학습을 시작한 지 7시간 만에 NCCL 타임아웃으로 인해 학습 실행이 실패했습니다. 조사 결과, RDMA NCCL 콜렉티브에 사용되는 단일 InfiniBand 포트가 한 번 다운되었다가 복구된 것으로 나타났습니다. 그 이후로는 다시 플래핑(flapping)이 발생하지 않았습니다. 당사의 지속적인 헬스 체크는 IB 포트 플래핑을 모니터링하지만, 단 한 번의 격리된 플랩은 보통 포트 상태가 불량함을 의미하지 않으므로 그 자체로는 임계값을 초과하지 않습니다.

이 중단은 두 개의 NCCL 타임아웃 중 어느 것이 먼저 발생하는지에 따른 문제였습니다. NCCL 구성에 대한 대부분의 논의는 init_process_group(timeout=...)를 통해 구성할 수 있는 PyTorch NCCL watchdog 타임아웃에 초점을 맞춥니다. 이는 설정 가능한 일정 시간(보통 10분)이 지난 후 중단된 콜렉티브를 강제 종료합니다. 두 번째 타임아웃은 스택의 더 아래쪽에 위치하며 이보다 훨씬 전에 발생합니다. InfiniBand 전송 레이어의 NCCL_IB_TIMEOUT는 연결을 끊기 전에 다운된 포트가 복구될 때까지 연결이 대기하는 시간을 제어합니다. 재시도를 감안한 실제 기본값은 약 7초로, 대부분의 팀이 생각하는 것보다 훨씬 짧습니다. 단일 포트 다운 창이 이 시간을 초과하면 PyTorch watchdog 타임아웃 설정과 관계없이 연결이 끊어지고 콜렉티브는 이미 작동을 멈춥니다. watchdog이 중단을 감지할 때쯤에는 이미 실행이 중단될 수밖에 없는 상태가 됩니다.

학습에 미치는 영향에서 중요한 신호는 플랩 횟수가 아니라 누적 다운타임입니다. 단 한 번이라도 충분히 긴 플랩이 발생하면 몇 시간 동안 반복되는 플랩과 마찬가지로 며칠 동안 진행된 학습 실행을 중단시킬 수 있습니다. 당사는 더 탄력적으로 대응할 수 있도록 NCCL_IB_TIMEOUT 기본값을 조정했으며, 동일한 포트 다운 신호를 통해 watchdog이 작동할 때까지 GPU를 유휴 상태로 두지 않고 작업을 중단한 후 체크포인트부터 재시작할 수 있도록 했습니다. 이번 조사는 이 글의 나머지 부분에서 설명할 헬스 체크 시스템에 반영된 여러 사례 중 하나입니다.

노드 라이프사이클 전반에 걸친 헬스 체크

당사는 전체 노드 라이프사이클을 아우르며 모든 GPU 노드에서 실행되는 다단계 헬스 체크 및 관찰 가능성(observability) 서비스로 gpu-monitor를 구축했습니다. 서로 다른 조건에서 서로 다른 장애 모드를 포착할 수 있기 때문에 단계별로 다른 범주의 체크가 실행됩니다.

활성 부트스트랩 체크(Active bootstrap checks)는 노드가 처음 프로비저닝될 때와 고객 워크로드 간에 노드가 정리될 때마다 실행됩니다. 모든 워크로드는 전체 체크 제품군을 방금 통과한 노드에서 시작됩니다. 이를 통해 사전에 타겟팅된 테스트를 통해 확실하게 드러날 수 있는 결정론적 장애를 잡아냅니다. gpu-monitor가 실행하는 대표적인 체크 항목은 다음과 같습니다.

• GPU 컴퓨팅 속도 및 번인(burn-in) 검증
• 모든 쌍에 대해 검증된 GPU 간 피어 연결성(NVLink 및 NVSwitch 상태)
• 노드 내부(Intra-node) NCCL all-reduce 정확성 및 대역폭
• 호스트 로컬 루프백을 통한 RDMA NIC 대역폭
• 행 재매핑(row-remap) 여유 공간을 포함한 ECC 및 HBM 메모리 상태
• PCIe 토폴로지 및 링크 무결성
• 레벨 2에서의 NVIDIA DCGM 진단

활성 검사를 통과하지 못한 노드는 워크로드가 실행되기 전에 즉시 플릿에서 제거됩니다. 문제가 있는 노드는 격리된 후, 재설정 및 철저한 재테스트를 거쳐 플릿으로 복귀하거나 영구적으로 제거됩니다.

수동적 지속 검사는 이전 섹션에서 언급한 비결정론적 오류 모드, 즉 지속적인 워크로드 부하가 있을 때만 발생하는 오류를 감시합니다. 이를 위해 gpu-monitor는 모든 활성 노드에서 다음과 같은 두 번째 레이어의 검사를 실행합니다:

• NVLink 레인 상태 (비활성화되는 레인은 모두 플래그 표시됨)
• GPU 클록 스로틀링 원인 (HW_SLOWDOWN, HW_THERMAL_SLOWDOWN, HW_POWER_BRAKE)
• RDMA 패브릭 포트 다운 감지 (플랩 횟수가 아닌 누적 다운타임 기준 임계값 적용)
• 커널 로그의 심각한 XID 오류
• PCIe AER 수정 불가능한 오류
• GPU 코어와 HBM 간의 온도 구배(thermal gradient)
• NVSwitch 오류 상태

지속 검사 실패를 보이는 노드는 코돈(cordon) 및 드레인(drain) 처리되며, 활성 부트스트랩 검사 실패와 동일한 격리 프로세스를 거칩니다.

주기적 다중 노드 활성 검사는 단일 노드 자체만으로는 발견할 수 없는 노드 간 패브릭 동작을 검증합니다. 이 검사는 고객 워크로드 사이의 유휴 노드에서 주기적으로 실행되어, 부트스트랩 레이어가 이미 감지한 단일 노드 성능 저하와 노드 간 패브릭 문제를 분리합니다. 유휴 노드에서 실행되고 고객 워크로드에 노드가 필요할 때 선점(preempt)될 수 있기 때문에, 프로비저닝 시점의 활성 검사에 포함하기 어려운 더 무거운 테스트를 수행할 수 있습니다.

테스트 자체에는 노드 그룹 전반의 NCCL 집합 통신 대역폭 프로브가 포함되며, 페이로드 크기는 8바이트부터 2 GiB까지 다양하게 테스트합니다. 페이로드 크기가 중요한 이유는 NCCL이 크기에 따라 서로 다른 코드 경로를 트리거하기 때문입니다. KB 범위의 작은 메시지는 LL 및 LL128과 같은 저지연 프로토콜을 통해 실행되며 지연 시간에 크게 좌우되므로, p95 지연 시간이 유용한 통과 기준이 됩니다. MB 범위의 중간 크기 메시지는 NCCL이 알고리즘을 트리(tree)에서 링(ring)으로 전환하는 임계값을 넘나듭니다. 대용량 메시지는 대역폭 한계에 도달함에 따라 청킹(chunking) 및 파이프라이닝을 실행하므로, BusBW(버스 대역폭)가 유용한 통과 기준이 됩니다. 하드웨어 문제는 종종 이러한 코드 경로 중 하나에서만 나타납니다. 헬스 체크에서 all-reduce 대역폭에 대해 확인하는 조건의 대표적인 출력 예시입니다:

AlgBW(알고리즘 대역폭)는 워크로드 관점에서의 처리량을 측정합니다. BusBW(버스 대역폭)는 all-reduce와 같은 집합 통신이 패브릭을 통해 각 바이트를 여러 번 이동시킨다는 사실을 반영하므로, 실제 링크 사용률과 하드웨어 상태를 더 잘 나타냅니다.

이 세 가지 레이어가 함께 작동하여 워크로드가 시작되기 전에 하드웨어를 검증하고, 실행되는 동안 이를 모니터링하며, 그 사이에는 더 넓은 범위의 패브릭을 검증합니다. 새로운 오류 모드가 나타나면 새로운 헬스 체크를 통합하고 전체 플릿에 gpu-monitor을 배포합니다.

결론

GPU 안정성은 지속적으로 누적되어 발전하는 시스템입니다. 새로운 하드웨어 세대와 워크로드 패턴은 검사 프로세스에 다시 반영해야 하는 새로운 오류 모드를 계속해서 발생시키며, 이러한 피드백 하나하나가 시스템을 더욱 견고하게 만듭니다. 이번 포스트에서는 다른 모든 것의 기초가 되는 기반을 다루었습니다. 이 시리즈의 향후 포스트에서는 이를 바탕으로 실행 규모가 커지고 아키텍처가 변경되며 RL 워크로드가 동일한 루프에서 학습과 추론을 결합함에 따라 학습의 안정성을 유지하기 위한 작업들을 다룰 예정입니다.

이 정도 규모에서 안정적인 GPU 인프라를 구축하는 것이야말로 차세대 AI 제품을 가능하게 만드는 원동력입니다. 대규모 GPU 안정성 문제를 해결하는 데 관심이 있으시다면, 지금 지원하세요!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)