PyTorch 2.14 FlightRecorderHook, NCCL 밖 백엔드에서도 집단통신 추적이 되는 이유 | DAKER 커뮤니티
분산 학습에서 집단통신이 어긋나거나 멈출 때 가장 답답한 순간은, 문제가 났는데도 남는 추적 정보가 거의 없을 때입니다. 특히 예전처럼 Flight Recorder를 NCCL 전용으로만 생각하면, Gloo 같은 백엔드에서는 원인 파악이 더 어려워지기 쉬웠습니다.
PyTorch 2.14의 FlightRecorderHook은 이 지점을 바꿉니다. Flight Recorder를 ProcessGroup 훅으로 올리면서, NCCL에 묶여 있던 추적 경로를 백엔드 공용으로 가져갈 수 있게 됐습니다. 그래서 NCCL이 아닌 백엔드에서도 DebugMode를 통해 휴대 가능한 콜렉티브 트레이스를 남길 수 있는지가 이번 변화의 핵심입니다.
PyTorch 2.14의 FlightRecorderHook은 집단통신 행·불일치 진단을 위한 Flight Recorder를 ProcessGroup 훅으로 올려, NCCL에만 묶이던 추적을 백엔드 공용으로 만듭니다.
무엇이 달라졌나
이전에는 Flight Recorder가 사실상 NCCL 중심으로 받아들여지기 쉬웠습니다. 그래서 Gloo 잡에서 행이 났을 때는 추적 버퍼가 비어 있거나, 애초에 남길 수 있는 정보가 부족해 진단이 끊기는 경우가 있었습니다.
이번 변화는 추적 지점을 ProcessGroup 훅 경로로 옮겼다는 데 의미가 있습니다. 백엔드가 무엇이든 같은 진단 흐름을 기대할 수 있고, 적어도 어떤 백엔드에서 추적이 남았는지 비교하기가 쉬워집니다. 결과적으로 문제를 푸는 것만큼, 어떤 조건에서 재현되고 어떤 로그가 남는지를 정리하는 일이 더 수월해집니다.
재현해 볼 실험 조건
작은 월드에서 백엔드를 Gloo처럼 NCCL이 아닌 경로로 두고, 훅이 ProcessGroup에 걸린 뒤 의도적으로 어긋난 콜렉티브를 한 번 만들어 보면 됩니다. 이때 참가자 노트에는 백엔드 이름, 훅 등록 여부, DebugMode 로그에 트레이스가 남았는지를 적어두는 것이 좋습니다. 행이 실제로 풀렸는지보다, 어떤 백엔드에서 추적이 됐는지가 재현에는 더 도움이 됩니다.
- NCCL이 아닌 백엔드(예: Gloo)로 ProcessGroup을 열고, 예전 NCCL 전용 Recorder만으로는 추적이 비었던 조건을 재현합니다.
FlightRecorderHook을 ProcessGroup 훅 경로로 등록한 뒤, 행 또는 불일치 콜렉티브를 짧게 유도하고 DebugMode 직렬화 로그에 콜렉티브 트레이스가 남는지 확인합니다.- 같은 진단 절차를 NCCL 백엔드에서도 한 번 돌려, 백엔드가 달라도 같은 훅·로그 경로를 쓰는지 비교합니다.
핵심은 로그 직렬화가 DebugMode를 통해 휴대 가능해졌다는 점입니다.
실험이 끝나면 사용한 백엔드 문자열, 월드 사이즈, 훅 등록 코드를 한 줄로 정리해 두면 다음 참가자가 같은 조건을 바로 따라오기 좋습니다.
실무에서 바로 볼 포인트
실무에서는 행이나 불일치 진단을 NCCL 전용 도구에만 기대지 않는 것이 중요합니다. ProcessGroup 훅 기반이라면 백엔드를 바꿔도 같은 추적 경로를 기대할 수 있기 때문입니다.
또한 학습 노트에는 백엔드 이름, DebugMode 출력 유무, 재현한 콜렉티브 종류를 남겨두는 편이 좋습니다. DAKER 학습 보드에서도 훅을 걸었다는 사실과 트레이스가 비지 않았는지를 한 줄로 적어두면, 이후 재현과 비교가 훨씬 쉬워집니다.
관련 DAKER 학습
참고 자료
https://daker.ai/public/learning/tracks/pytorch-practice-advanced-track
https://daker.ai/community/post-mu3emq0u-130369ca
https://daker.ai/community
여러분은 NCCL이 아닌 백엔드에서 집단통신 문제를 재현할 때 어떤 로그를 가장 먼저 확인하시는지 궁금합니다.