PyTorch 2.14에서 Inductor simple_overlap 기본 적용, 분산 학습 통신 대기 줄어드는 이유 | DAKER 커뮤니티

통신과 연산을 겹칩니다

멀티 GPU 학습에서 성능이 기대만큼 나오지 않을 때, 병목은 의외로 모델 구조보다 통신 대기에서 드러나는 경우가 많습니다. PyTorch 2.14에서는 이런 지점을 볼 때 확인할 만한 변화가 하나 있습니다. Inductor의 simple_overlap이 기본으로 켜지면서, torch.compile 기반 분산 학습에서 통신과 독립 연산을 자동으로 겹치기 시작합니다.

그래서 이번 변화는 새 옵션을 더 챙겨 넣는 이야기라기보다, 같은 코드라도 기본 스케줄이 달라졌다는 점에 가깝습니다. 지금 분산 학습을 운영 중이라면 설정 파일을 먼저 뒤지기보다, 2.13과 2.14에서 프로파일이 어떻게 달라지는지부터 보는 것이 좋습니다.

PyTorch 2.14부터 Inductor의 simple_overlap이 기본으로 켜지며, torch.compile 분산 학습에서 GPU가 통신만 기다리는 구간이 줄어듭니다.

무엇이 달라졌나

핵심은 torch.compile로 실행하는 분산 학습에서 집단 통신과 독립적인 연산을 더 자연스럽게 겹치도록 기본 동작이 바뀌었다는 점입니다. 이전에는 별도 플래그를 켜야 하던 흐름이 있었다면, 2.14에서는 기본값 자체가 달라졌습니다.

이 변화는 설정 한 줄의 추가라기보다 실행 스케줄의 변화로 이해하는 편이 맞습니다. 따라서 체감 성능을 보려면 단순 평균 스텝 시간만 보기보다, 프로파일에서 통신 구간이 실제로 연산과 인터리브되는지를 함께 확인하는 것이 중요합니다.

비교할 때 볼 실험 조건

변화를 확인하려면 같은 모델과 같은 배치 조건에서 PyTorch 2.13과 2.14를 나란히 비교하면 됩니다. 두 버전 모두 torch.compile로 학습하고, 분산 집단 통신이 포함된 스텝을 프로파일하면 차이를 보기 좋습니다. 이때 2.14는 simple_overlap을 끄지 않은 기본값으로 두는 것이 기준이 됩니다.

이 조건에서 2.14 기본값은 독립 연산과 집단 통신이 인터리브되어, 통신만 크리티컬 패스에 남는 비율이 줄어드는 쪽으로 관측됩니다.

비교의 핵심은 속도 숫자 하나보다, 통신 구간이 연산과 실제로 겹치는지 여부입니다.

실무에서 바로 볼 포인트

모든 워크로드에서 체감 이득이 크게 나타나는 것은 아닙니다. 통신이 이미 충분히 가려진 경우라면 변화가 작을 수 있습니다. 이때 성능 향상이 없다고 해서 실패로 볼 필요는 없습니다. 겹칠 수 있는 여유가 원래 많지 않았던 상황일 수 있기 때문입니다.

또 하나는 기록입니다. API가 실험적인 만큼, 벤치마크를 남길 때는 PyTorch 버전과 torch.compile 사용 여부를 함께 적어두는 편이 좋습니다. 같은 모델이라도 실행 경로가 달라지면 결과 해석이 달라질 수 있습니다.

문제를 재현하거나 원인을 분리해야 할 때는 overlap 관련 설정을 일시적으로 끄고 같은 입력으로 다시 측정해 보면 도움이 됩니다. 이렇게 하면 성능 차이가 모델 자체인지, 통신과 연산의 겹침 때문인지 구분하기 쉬워집니다.

함께 보면 좋은 DAKER 학습 자료

참고 자료

https://daker.ai/public/learning/materials/pytorch-advanced-deployment-torchscript-onnx-perfo
https://daker.ai/public/learning/tracks/pytorch-practice-advanced-track

여러분의 환경에서는 PyTorch 2.14에서 통신 구간이 실제로 얼마나 더 겹쳐 보였는지 궁금합니다.