PyTorch 2.14 ProcessGroup 제자리 재구성으로 랭크 장애 뒤 복구하는 흐름 | DAKER 커뮤니티
대규모 분산 학습에서는 랭크 하나의 장애가 전체 작업 중단으로 이어지기 쉽습니다. 그동안은 프로세스 그룹을 통째로 다시 만들고 웜 상태를 포기한 채 재시작하는 경우가 많았습니다. PyTorch 2.14에서 드러난 변화는 바로 이 지점을 겨냥합니다.
이번 글은 작은 다중 프로세스 잡에서 한 랭크를 의도적으로 중단한 뒤, ProcessGroup 재구성 API로 그룹을 제자리에서 다시 붙이는 흐름만 간단히 따라갑니다. Flight Recorder로 행을 보는 실험과는 목적이 다르므로, 복구 경로만 분리해 보는 것이 좋습니다.
PyTorch 2.14에서 Backend·ProcessGroup이 제자리 재구성 인터페이스를 노출합니다.
무엇이 달라졌나
핵심은 랭크가 죽었을 때 프로세스 그룹을 완전히 부수고 다시 만드는 대신, abort 훅과 집단통신 전후 훅을 같은 경로로 묶어 그룹을 다시 세울 수 있다는 점입니다. 여기에 Gloo의 장애 허용 지원도 더해졌습니다.
이 변화는 단순히 복구 가능 여부를 넘어, 이미 올라가 있던 웜 상태를 얼마나 유지할 수 있는지와도 연결됩니다. 옵티마이저 상태나 캐시를 모두 버리지 않고 이어갈 수 있다면, 장애 이후의 회복 비용을 줄이는 데 도움이 됩니다.
재현해 볼 실험 조건
실험은 작은 world size에서 시작하면 됩니다. 예를 들어 2~4 정도의 프로세스로 ProcessGroup을 연 뒤, 간단한 allreduce 루프를 먼저 워밍업합니다. 그 다음 한 랭크를 종료하거나 중단하고, 문서화된 재구성 경로로 그룹을 제자리에서 다시 붙입니다.
이후에는 재구성 전후로 집단통신이 다시 통과하는지, 그리고 웜 상태를 얼마나 남길 수 있는지를 기록하면 됩니다. 이때 Flight Recorder 덤프와 동시에 돌리기보다는, 복구 경로만 따로 떼어 측정하는 편이 결과를 보기 좋습니다.
이번 글의 축은 그룹을 부수지 않고 다시 맞추는 것입니다.
nccl2 백엔드 미리보기와 함께 쓸 수는 있지만, 재현 노트에는 백엔드 이름과 훅 호출 순서를 남겨 두는 것이 좋습니다.
실무에서 먼저 볼 포인트
실무에서는 우선 랭크 장애 시 전체 재시작 대신 제자리 재구성이 가능한지부터 확인하면 됩니다. 그 다음 abort 훅과 pre/post collective 훅이 같은 경로에 묶여 있는지 점검하는 것이 좋습니다.
또 하나 중요한 점은 진단 실험과 복구 실험을 섞지 않는 것입니다. Flight Recorder를 통한 관찰과 장애 복구 측정은 목적이 다르기 때문에, 변수를 분리해야 복구 경로의 효과를 더 분명하게 볼 수 있습니다.
관련 DAKER 학습
참고 자료
https://daker.ai/public/learning/tracks/pytorch-practice-advanced-track
https://daker.ai/community
작은 분산 잡에서 랭크 중단 뒤 재구성 성공 여부를 확인해 본 경험이 있다면, 어떤 지점이 가장 까다로웠는지 함께 이야기해 주셔도 좋겠습니다.