PyTorch 2.14에서 nccl2 백엔드로 ProcessGroup을 열면 달라지는 점 | DAKER 커뮤니티
분산 학습에서는 코드가 돌아간다는 사실만으로는 충분하지 않을 때가 많습니다. 같은 집단통신이라도 어떤 백엔드 계약 위에서 실행됐는지에 따라 재현성과 디버깅 포인트가 달라지기 때문입니다. PyTorch 2.14에서 nccl2를 선택하면 기본 분산 스택 안에서 torchcomms 경로를 쓰게 된다는 점은, 이런 차이를 확인해 볼 만한 변화입니다.
특히 기존에 레거시 nccl만 써 온 팀이라면, 백엔드 문자열 하나를 바꾸는 것만으로도 집단통신 경로가 달라질 수 있습니다. 이 글에서는 작은 월드 사이즈로 nccl2 ProcessGroup을 초기화하고, allreduce 한 번이 어떤 Work 핸들로 돌아오는지 확인하는 데 초점을 맞춥니다.
분산이 된다보다 어떤 백엔드 계약으로 끝나는지를 기록해 두는 편이 재현에 더 도움이 됩니다.
nccl2 백엔드에서 바로 달라지는 점
PyTorch 2.14의 nccl2 c10d 백엔드는 torchcomms 경로를 트리 안에 넣습니다. 따라서 ProcessGroup을 nccl2로 열면 전체 Work 계약, 논블로킹 커뮤니케이터, eager split을 기본 분산 스택에서 바로 쓰게 됩니다.
이 변화는 겉으로 보기에는 단순한 백엔드 선택처럼 보이지만, 실제로는 어떤 통신 경로와 완료 대기 방식이 적용되는지에 영향을 줍니다. 그래서 실험 노트에는 백엔드 이름과 빌드 플래그를 함께 남겨 두는 것이 좋습니다.
재현해 볼 실험 조건
가장 먼저 볼 조건은 USE_C10D_NCCL이 켜진 2.14 빌드에서 백엔드를 nccl2로 지정해 ProcessGroup을 만드는 것입니다. 그다음 같은 코드로 레거시 nccl 또는 명시적 legacy 경로와 비교해, 커뮤니케이터가 eager로 잡히는지와 Work 완료 대기 API가 동일한지 확인하면 됩니다.
여기에 논블로킹 콜렉티브 한 개를 던진 뒤, 핸들이 준비될 때까지 다른 연산을 끼워 넣어 경로 차이를 로그로 남기면 비교가 더 분명해집니다. 이번 글에서는 내결함성 재구성이나 단방향 윈도우처럼 같은 백엔드 계열의 다른 기능보다는, 백엔드 선택과 Work 계약 자체에만 초점을 둡니다.
옵션 플래그로 이름만 바꾼 뒤 조용히 폴백되지 않는지부터 확인하는 것이 좋습니다.
실무에서 먼저 확인할 포인트
nccl2는 eager 전용입니다. 따라서 예전 lazy 초기화가 필요한 경우라면 호환 래퍼 경로를 따로 확인해야 합니다. 또한 학습 노트에는 PyTorch 버전, 백엔드 문자열, 월드 사이즈, NCCL 관련 env를 함께 남겨 두는 편이 좋습니다.
실험이 끝난 뒤에는 사용한 env와 월드 사이즈를 한 줄로 정리해 두면 다음 참가자가 같은 조건을 바로 따라오기 쉽습니다. DAKER 학습 보드에서도 백엔드를 바꿨다는 사실과 콜렉티브가 같은 계약으로 끝나는지를 함께 적어 두면 재현에 도움이 됩니다.
관련 DAKER 학습
함께 보면 좋은 자료는 아래 링크에서 확인할 수 있습니다.
참고 자료
https://daker.ai/public/learning/tracks/pytorch-practice-advanced-track
https://daker.ai/public/learning/materials/pytorch-advanced-2-embedding-self-attention-mini-i
여러분은 분산 실험 기록을 남길 때 백엔드 문자열과 Work 계약까지 함께 적어 두는 편인가요?