PyTorch 2.15 NCCL 전환: 분산 학습이 멈출 때 기록을 읽는 순서

학습 작업이 멈췄다. 네 프로세스 가운데 하나가 통신 시간 초과를 보고하고, 나머지도 곧 종료된다. 이때 가장 먼저 오류를 출력한 GPU를 교체하거나 제한 시간을 늘리면 원인을 찾을 수 있을까?

그럴 수도 있지만, 그 프로세스는 다른 참여자를 기다리고 있었을 수 있다. 기다려야 할 프로세스가 데이터 읽기에서 멈췄는지, 다른 연산으로 들어갔는지, 올바른 연산을 요청했는데 통신이 진행되지 않았는지에 따라 다음 행동이 달라진다. 이 글은 분산 학습의 기록을 서로 대조하는 방법을 다룬다. 제품 벤치마크나 실제 장애 재현 보고서는 아니다.

같은 nccl 설정 아래에서 바뀐 것

PyTorch는 2026년 10월 28일 2.15를 발표했다. 2.14에서 선택적으로 사용하던 새 NCCL 백엔드를 2.15의 기본값으로 바꿨다. NVIDIA GPU의 통신 라이브러리인 NCCL 자체와, 그것을 PyTorch의 프로세스 그룹에 연결하는 백엔드 구현은 구별해야 한다. 이번 변경은 후자의 교체다. 공식 릴리스 소개

프로세스 그룹은 함께 통신하는 프로세스들의 묶음이고, rank는 그 안에서 참여자를 구별하는 번호다. 한 프로세스가 GPU 하나를 맡는 흔한 학습 구성을 떠올리면 된다. 여러 GPU가 값을 모으거나 더하는 집단 통신을 collective라고 부른다.

이번 공식 설명은 통신 정지 때 rank별 상태를 디스크에 남기는 flight recorder와, 시간 초과 발생 시 여러 rank의 덤프 수집을 유도하는 진단 경로도 소개한다. 여기서 덤프는 사고 뒤 비교할 실행 기록이다. 기록이 만들어졌다는 사실만으로 원인이 자동 확정되거나 학습이 복구되는 것은 아니다. 실제 설정과 수집 성공 여부는 대상 환경에서 확인해야 한다. 진단 기능의 발표 범위

11월 5일 확인한 상세 릴리스 노트는 초기화와 장치 연결의 변화도 적고 있다. 통신기는 그룹 생성 시점에 만들어지며, 쓰지 않는 그룹도 GPU 메모리를 할당할 수 있다. 그룹은 CUDA 장치 하나에 연결된다. 이전처럼 torch.cuda.set_device()만으로 그룹 장치 선택이 같을 것이라 기대하지 말고, device_id와 rank 배치를 확인해야 한다. v2.15.0 호환성 변경

따라서 업그레이드 후 첫 학습 스텝에 도달하기도 전에 문제가 생겼다면, “첫 AllReduce가 느려졌다”는 조사부터 시작할 이유가 없다. 프로세스가 시작됐는지, 그룹 생성이 끝났는지, 의도한 장치와 연결됐는지부터 나누어야 한다.

통신을 읽기 위한 최소 단위

AllReduce를 예로 들자. 각 rank가 같은 길이의 배열을 보내고 합 연산을 선택하면, 모든 rank가 원소별 합을 받는다. NCCL 문서는 collective의 참여 rank들이 일치하는 원소 수와 자료형으로 호출해야 하며, 어기면 정지·충돌·데이터 손상 같은 정의되지 않은 동작이 가능하다고 설명한다. 이 글이 확인한 문서의 표시 버전은 NCCL 2.32.3이다. 특정 PyTorch 설치에 그 버전이 들어 있다고 추정하지 않는다. NCCL collective 규칙

다음은 통신 전 입력과 합의 관계를 보여 주는 작은 산술 예다. GPU 실행 결과가 아니다.

rank 0 입력: [1, 2]
rank 1 입력: [3, 4]
같은 그룹의 SUM AllReduce가 완료된 뒤 각 rank의 값: [4, 6]

한쪽이 합을 요청하고 다른 쪽이 전혀 다른 collective를 요청했다면, 두 입력이 있다는 사실만으로 위 결과를 기대할 수 없다. 또 그룹 A의 42번째 기록과 그룹 B의 42번째 기록은 같은 작업이 아니다. 그룹·참여자·해당 그룹 안의 진행 위치를 먼저 맞춰야 한다.

PyTorch 2.15의 그룹 문서는 기본적인 그룹 생성 순서를 모든 프로세스에서 맞추도록 요구한다. 여러 NCCL 프로세스 그룹을 함께 쓸 때도 rank 간 collective 실행 순서가 일관돼야 하며, 여러 스레드와 비동기 통신에는 추가 동기화가 필요하다. 따라서 한 파일의 호출 순서만 맞아 보인다는 이유로 전체 순서가 맞다고 판단할 수 없다. 버전 문서의 Groups 경고

네 rank의 ‘다음 행동’을 나란히 놓는다

아래는 직접 만든 가상 진단 기록이다. PyTorch 덤프의 실제 필드명이나 출력 형식을 복사한 것이 아니다. 하나의 그룹 G에 rank 0부터 3까지 참여하고, 모두 41번까지 완료했다고 가정한다. 42는 이 사례 안의 그룹별 논리 순번이며 학습 스텝 번호와는 다르다. 한 스텝에 여러 collective가 있을 수 있다.

rank	마지막 완료	다음 요청으로 관측한 것
0	G의 41번	G의 42번, AllReduce, 1,024개, fp32
1	G의 41번	G의 42번, AllReduce, 1,024개, fp32
2	G의 41번	G의 42번, AllReduce, 1,024개, fp32
3	G의 41번	G의 42번 요청 기록 없음, 데이터 읽기 예외 있음

이 경우 0번에서 시간 초과가 났더라도 먼저 조사할 곳은 rank 3의 통신 전 경로다. 데이터 읽기 예외가 그 실행에 속하는지, 예외 뒤에 해당 프로세스가 종료됐는지 확인한다. 다른 rank에 네트워크 오류가 전혀 없다고 단정하는 것은 아니지만, 이미 관측한 선행 실패를 건너뛸 이유는 없다.

단, 표의 마지막 칸에서 “데이터 읽기 예외 있음”이 빠지고 덤프 파일만 없다면 결론이 달라진다. 3번이 호출하지 않았을 수도 있고, 기록 수집이 실패했을 수도 있다. 로그 보관 경로·쓰기 권한·프로세스 종료 시점과 수집 범위를 확인해야 한다. 관측 누락은 행동 부재와 다르다.

대표 설명도는 이 표의 관계를 그린 자체 그림이다. 앞선 세 rank의 기다림과 마지막 rank의 통신 전 예외를 구분하며, 실제 GPU 화면이나 시간 측정은 아니다.

한 칸을 바꾸면 조사 대상도 바뀐다

이제 rank 3의 마지막 칸을 다음과 같이 바꿔 보자. 나머지 조건은 동일하다고 가정한다.

rank 3의 관측	가장 먼저 비교할 대상	아직 말할 수 없는 것
42번이 AllGather	조건 분기, 호출 순서, 그룹 식별	네트워크 장비가 원인이라는 결론
42번이 AllReduce, 512개, fp32	해당 rank의 입력·배치·텐서 생성 경로	메모리 용량 부족이라는 결론
42번이 AllReduce, 1,024개, fp16	자료형 변환과 혼합 정밀도 설정	데이터 개수만 맞으면 안전하다는 결론
같은 연산·개수·자료형을 요청했으나 완료 없음	GPU 실행 오류·스트림 진행·통신 경로와 더 앞선 오류	네트워크 문제로 원인이 확정됐다는 결론
해당 구간 기록 자체가 없음	수집 성공 여부와 프로세스 생존 기록	그 rank가 collective를 건너뛰었다는 결론

첫 세 행은 대조할 조건이 구체적이다. 반면 네 번째 행은 후보를 더 좁혀야 한다. 요청이 기록된 것과 GPU에서 연산이 시작된 것, 연산이 끝난 것은 서로 다른 상태다. “모두 같은 요청을 했다”는 정보만으로 앞선 GPU 작업이나 스트림의 대기를 지울 수 없다.

순번을 비교할 때도 로그 파일의 줄 번호를 그대로 쓰지 않는다. 각 파일의 버퍼링과 수집 시작 시점이 다를 수 있기 때문이다. 사건의 시계가 어긋났다면 가장 이른 타임스탬프를 원인으로 고르는 대신, 그룹과 작업 식별자로 순서를 연결하고 시간 차이의 불확실성을 남긴다.

업그레이드 전후를 비교하는 세 번의 시험

다음은 독자가 자신의 시험 환경에서 수행할 검증 계획이다. 이 글에서 PyTorch·CUDA·NCCL을 설치하거나 다중 GPU 시험을 수행한 것은 아니다. 예상 결과를 이미 관측한 값처럼 채우지 않았다.

첫째, 첫 연산 이전을 독립적으로 본다. 동일한 프로세스 배치로 시작해 그룹 생성 완료와 각 그룹의 장치를 기록한다. 모델을 읽기 전부터 GPU 메모리가 달라졌다면 통신 그룹의 생성 개수와 수명을 함께 확인한다. 첫 collective까지 도달하지 못했다는 사실은 통신 처리량의 비교 자료가 될 수 없다.

둘째, 작은 입력으로 참여와 순서를 확인한다. 정상 입력 하나에 더해, 일부 rank가 통신 전에 종료되는 경우와 호출 조건이 달라지는 경우를 격리된 시험으로 설계한다. 목적은 오래 멈추게 만드는 것이 아니라 어느 rank까지 기록을 회수하고 원인을 좁힐 수 있는지 확인하는 데 있다. 종료 한도와 작업 정리 절차를 먼저 정하고 운영 학습에는 오류를 주입하지 않는다.

셋째, 실제 학습의 완료 조건을 확인한다. 같은 입력·모델·배치 정책을 고정한 짧은 학습에서 손실 값의 허용 오차, 스텝 진행, 저장·재시작 결과를 비교한다. 통신만 끝났다고 학습 결과가 같은 것은 아니다. 변경한 PyTorch 패키지와 백엔드, GPU·드라이버·통신 라이브러리 버전을 각각 기록해야 한 번에 바뀐 조건을 찾을 수 있다.

시험의 질문	남겨야 할 결과	실패하면 돌아갈 곳
그룹이 의도한 장치로 생성됐나?	rank·그룹·장치 대응, 초기화 완료 여부	실행 배치와 그룹 생성 설정
모든 참여자의 진행을 비교할 수 있나?	기대 rank 수 대비 회수한 기록, 누락 이유	수집 경로·프로세스 종료 기록
같은 학습을 끝내고 다시 시작하나?	정해 둔 수치 오차·체크포인트·복원 결과	입력 고정·학습 설정·저장 형식

이 세 단계의 장점은 실패를 빨리 분류한다는 데 있다. 성능 개선을 보장하는 절차는 아니다. 대규모에서만 생기는 통신 경로나 동시성 문제는 작은 시험을 통과해도 남을 수 있다.

구형 백엔드 복귀와 패키지 다운그레이드는 다르다

v2.15.0 노트는 TORCH_DIST_USE_NCCL2=0을 모든 rank에서 그룹 생성 전에 적용하거나 nccl-legacy를 선택하는 임시 복귀 경로를 제공한다. 동시에 이 경로는 2.15에 한정되며 다음 릴리스에서 제거 예정이라고 명시한다. 장기 운영 해법으로 고정할 설정이 아니다. 복귀 조건

새 백엔드와 구형 백엔드를 같은 2.15 환경에서 비교하면 구현 변경의 영향을 좁히는 데 도움이 된다. 그러나 구형 백엔드에서 성공했다는 한 번의 결과만으로 새 구현의 버그가 증명되지는 않는다. 타이밍 변화가 기존 경쟁 조건을 가렸을 가능성도 남는다. 같은 입력과 배치를 반복하고, 실패가 시작되는 구간을 최소화한 자료가 필요하다.

PyTorch 자체를 2.14로 내리는 것은 더 넓은 변경이다. 특히 릴리스 노트는 2.15의 분산 체크포인트 저장 형식이 2.14 이하에서 로드되지 않는다고 설명한다. 이 조건은 해당 분산 체크포인트 형식에 관한 것이며 모든 저장 파일의 일반 법칙으로 확대하지 않는다. Distributed Checkpointing 변경

그래서 이 글의 제안은 기존 버전으로 복원 검증을 마친 체크포인트를 보존하고, 새 버전의 시험 출력은 별도 위치에 두는 것이다. “실패하면 패키지만 내리자”는 계획에는 어느 데이터로 다시 시작할지가 빠져 있을 수 있다. 멈춘 프로세스에서 설정만 바꿔 계속 실행하는 대신 종료·정리 후 새 실행으로 비교하고, 성공한 복원 자료를 남긴다.

시간 제한을 늘리는 결정도 원인 확인 뒤에 둔다. 정상적인 큰 작업에 시간이 더 필요한 경우와 참여자가 빠진 경우는 다르다. 앞의 가상 사례처럼 rank 3이 이미 종료됐다면 기다림을 연장해도 그 참여자가 돌아오지는 않는다. 일반적인 시간 예산 설계는 타임아웃과 재시도 예산에서 이어 볼 수 있다.

다음 장애 때 다시 쓸 기록

rank별 진단 기록지는 실제 덤프를 읽으며 필요한 정보를 옮겨 적는 빈 양식이다. 공식 파서나 실행 프로그램이 아니며, 이 글의 가상 순번을 실제 덤프 스키마로 가정하지 않는다.

실행 식별자 / PyTorch·백엔드·통신 라이브러리·드라이버:
모델·입력·배치 정책 / 비교 실행에서 바꾼 조건:
그룹 식별자 / 기대 rank 목록 / rank→장치 대응:
각 rank의 마지막 완료 / 다음 요청 종류·개수·자료형:
요청·시작·완료를 구별할 수 있는 기록 / 누락된 기록:
통신보다 앞선 예외 / 시계·수집 지연의 불확실성:
현재 가설 / 반대 증거 / 다음 한 번의 비교 시험:
복귀할 환경 / 보존한 체크포인트 / 복원 확인 결과:

그룹별 기록이 서로 맞는데도 여러 작업이 같은 장비 경로에서 느려진다면, 조사 범위를 작업과 GPU·네트워크의 연결 관계로 넓힐 수 있다. 먼저 프로세스 사이의 불일치를 찾고, 남은 의문을 장비·통신 경로의 증거와 연결하는 순서다.

다시 조사할 때는 오류 문장 하나보다 어느 참여자의 어느 진행 단계까지 확인했는지가 유용하다. 이 글을 저장해 다음 이행 시험에서 대조하거나, AI 시스템 글 모음과 RSS에서 관련 분석을 이어 읽을 수 있다.