PyTorch NCCL Watchdog 타임아웃 디버깅 가이드 및 Flight Recorder 활용법

섹션별 상세

NCCL 자체는 에러 체크 기능이 부족하여 PyTorch가 CPU 측에서 Work 객체와 모니터링 스레드를 통해 실행 상태를 감시한다. Work 객체는 NCCL API 호출 전후에 CudaEvent를 생성하여 GPU에서의 시작과 종료를 기록하며, 설정된 시간(기본 10분) 내에 완료되지 않으면 예외를 발생시킨다. 이는 실제 NCCL 라이브러리 내부의 에러가 아니라 PyTorch의 watchdog 스레드가 감지한 실행 지연임을 명확히 인지해야 한다.

타임아웃의 주요 원인은 집합 통신 간의 불일치(Desync)이며, 이는 크게 4가지 카테고리로 분류된다. CPU 측의 작업 지연(데이터 로딩, 컴파일 등)이나 코드 분기, GPU 연산 커널의 정지(Hang), 잘못된 집합 통신 인자(Shape, Dtype) 설정, 그리고 네트워크/하드웨어 결함이 포함된다. Meta의 통계에 따르면 CPU 측 이슈가 가장 지배적인 원인이며, 단순히 타임아웃 임계값을 늘리는 것만으로는 근본적인 해결이 불가능하다.

Flight Recorder는 각 랭크의 CPU 측 링 버퍼에 집합 통신의 타입, 상태(Missing, Scheduled, Started, Completed), 데이터 타입, 크기, 콜 스택 등을 기록한다. 타임아웃 발생 시 TCPStore를 통한 사이드 채널로 모든 랭크에 신호를 보내 데이터 덤프를 강제함으로써, 특정 랭크가 통신을 누락했거나 다른 순서로 실행했는지 사후 분석할 수 있는 환경을 제공한다. 이는 시스템이 불안정한 타임아웃 상황에서도 높은 덤프 성공률을 보장하도록 설계됐다.

덤프된 데이터를 fr_trace 도구로 정렬하고 시각화하여 랭크 간 집합 통신 실행 순서와 메타데이터를 비교 분석한다. Meta는 이를 테이블 형태로 시각화하여 색상 코딩으로 불일치 지점을 즉시 식별하고, 특정 셀 선택 시 해당 시점의 콜 스택을 확인하는 워크플로우를 구축하여 디버깅 시간을 단축했다. 특히 N-D 병렬성(FSDP 등)을 사용하는 복잡한 모델에서 프로세스 그룹별 통신 흐름을 파악하는 데 효과적이다.

기술

PyTorch
NCCL
CUDA
TCPStore
FSDP
TorchRec

활용 사례

분산 학습 중 발생하는 원인 불명의 학습 중단 디버깅
대규모 추천 시스템(RecSys)의 All-to-All 통신 최적화
LLM 학습 시 발생하는 CPU-GPU 동기화 병목 지점 파악

언급된 리소스

GitHubPyTorch Flight Recorder Visualization Proof-of-Concept