PyTorch Monarch, AMD GPU로 확장…체크포인트 없는 장애 복구 실험

수천 개의 GPU로 대규모 언어 모델을 학습하는 환경에서 하드웨어 장애는 예외가 아니라 상수다. GPU 메모리 오류 하나, 네트워크 단절, 노드 크래시 하나가 며칠 혹은 몇 주 동안 진행된 학습 전체를 무너뜨린다. PyTorch 팀은 이 문제를 정면으로 다루기 위해 단일 컨트롤러(single-controller) 런타임인 Monarch를 AMD Instinct GPU와 ROCm 환경으로 이식했다. 지금까지 CUDA 생태계에 묶여 있던 이 런타임을 다른 하드웨어로 넓혔다는 점에서, 학습 인프라의 이식성과 안정성 양쪽을 겨냥한 작업으로 볼 수 있다.

왜 체크포인트만으로는 부족한가

전통적인 내결함성 전략은 주기적 체크포인트에 크게 의존한다. 일정 간격으로 모델 상태 전체를 영구 저장소에 저장해 두고, 장애가 나면 마지막 체크포인트로 돌아가 작업 전체를 재시작하는 방식이다. 개념은 단순하지만 대가가 크다. 장애가 잦은 초대형 클러스터에서는 마지막 저장 시점 이후의 연산이 통째로 버려지고, 재시작 과정에서 정상적으로 돌아가던 노드까지 함께 멈춰 서기 때문이다. 규모를 키우는 것만으로는 충분하지 않고, 학습 자체가 장애에서 회복할 수 있어야 한다는 문제의식이 여기서 출발한다.

Monarch가 제시하는 대안은 클러스터 전체를 하나의 파이썬 프로그램에서 오케스트레이션하는 프로그래밍 패러다임이다. 액터 기반 런타임, 프로세스 메시(process mesh) 추상화, 비동기 실행 모델을 통해 학습·평가·강화학습을 하나의 스크립트 안에 통합할 수 있다. 구조적으로는 파이썬 API 계층과 Rust로 작성된 런타임을 분리해 두었고, 각 학습 복제본 내부의 병렬화 전략과 복제본 사이의 내결함성 메커니즘을 따로 떼어냈다. 그 결과 장애는 액터 단위로 격리되고(크래시가 전파되지 않음), 가능한 가장 낮은 계층에서 처리되며, 복구는 로컬 재시작이면 수 초, 상위로 에스컬레이션돼야 할 때만 수 분이 걸리는 계층적 모델이 된다.

ROCm 이식의 실제

이식 작업은 GPU 런타임과 분산 통신 스택을 ROCm으로 옮기는 상당한 엔지니어링을 요구했다. 팀은 hipify_torch와 자동 감지를 활용해 CUDA에서 ROCm으로 넘어가는 세 갈래 경로를 구현했고, 그 과정에서 Rust에 HIP 타입 별칭(type alias)을 도입했다. 최종적으로 1,171개의 테스트가 모두 통과하며 ROCm 7.0 이상을 지원하게 됐고, 관련 기여는 PR #2393과 #2891로 오픈소스 커뮤니티에 반영됐다. 현재 ROCm 위의 Monarch는 액터 런타임, RDMA, 감독(Supervision), 텐서 샤딩 등 전체 생태계를 지원하며 SLURM, 쿠버네티스, SkyPilot 위에서 동작한다. 이는 학습 엔진 TorchTitan과 내결함성 엔진 TorchFT 같은 하위 구성 요소를 프로덕션 워크로드에 얹을 수 있다는 의미다.

실제 검증 구성은 세 계층으로 이뤄진다. Monarch가 감독 트리를 통해 세밀한 장애 감지와 격리를 담당하고, 장애가 학습 액터에 주입되면 Lighthouse가 이를 감지해 TorchFT가 처리한다. 핵심은 정상 복제본들이 동료 노드의 장애와 무관하게 계속 학습을 이어간다는 점이다. 네 개의 복제본 그룹을 가정한 시나리오에서는 전체 체크포인트를 다시 불러오는 대신 동료 복제본으로부터 체크포인트를 전달받아 복구가 진행되며, 이 과정 전체가 수작업 개입 없이 완료된다.

잦은 장애 주입 실험의 결과

검증은 MI300 계열 클러스터에서 SLURM과 쿠버네티스 양쪽으로 이뤄졌다. 128개 MI300 GPU를 갖춘 16노드 SLURM 클러스터에서 Llama 3 8B 모델을 학습하며 180초마다 RCCL 장애를 주입하고 20스텝마다 쿼럼 동기화를 수행했는데, 어떤 복제본도 30분 이상 다운되지 않았고 복제본들이 동적으로 죽고 회복되기를 반복하면서도 학습이 이어졌다. 실험을 256개 MI355 GPU를 쓰는 32노드 쿠버네티스 클러스터로 확장했을 때는 참여 노드 수가 복구 이벤트 동안 30~32 사이에서만 미세하게 흔들렸고, 전역 평균 손실이 12에서 약 4까지 매끄럽게 감소했다. 참고로 이전 연구에서는 1024-GPU MI325 클러스터에서 DeepSeekV3-671B의 FP8 학습이 96.16%의 확장 효율을 기록한 바 있다.

실무 관점에서 이 작업의 의미는 두 가지로 정리된다. 첫째, AMD GPU를 대규모 학습에 투입하려는 팀에게 CUDA 밖에서도 단일 컨트롤러 방식의 탄력적 내결함성을 쓸 수 있는 선택지가 생겼다. 둘째, 체크포인트 전면 재시작에 의존하지 않고 정상 노드가 계속 돌아가게 함으로써 낭비되는 연산을 줄이고 GPU 가동률을 끌어올리는 구체적 경로를 보여줬다. 다만 공개된 실험은 Llama 3 8B 규모에 16~32노드 수준이라는 점, 그리고 검증이 인위적으로 장애를 주입한 통제된 환경에서 이뤄졌다는 점은 감안해야 한다. 자사 워크로드에 적용하려면 모델 규모와 병렬화 전략, 쿼럼 동기화 주기 같은 파라미터를 실제 장애 특성에 맞춰 다시 튜닝하는 검증 단계가 필요하다. 그럼에도 액터 기반 격리와 쿼럼 기반 동기화를 결합해 장애를 국소화하는 설계 원리 자체는 하드웨어 벤더에 종속되지 않는 만큼, 대규모 학습 인프라를 설계하는 팀이라면 참고할 만한 레퍼런스가 된다.