PyTorch Monarch 공개
(pytorch.org)- PyTorch Monarch는 대규모 모델의 효율적 분산 학습과 추론을 지원하기 위해 설계된 새로운 프레임워크
- 기존 PyTorch의 모듈식 구조를 확장해, 거대한 신경망을 여러 장치와 노드에 자동으로 분할하고 관리하는 기능 제공
- 모델 병렬화, 파이프라인 병렬화, 데이터 병렬화를 통합적으로 제어할 수 있는 API를 통해 개발자의 복잡한 설정 부담을 줄임
- Monarch는 특히 대규모 언어 모델(LLM)과 추천 시스템 등 메모리 집약적 워크로드에서 높은 효율성을 보임
- PyTorch 생태계 내에서 확장성과 성능 최적화를 동시에 달성하려는 시도의 일환으로, 차세대 분산 학습 인프라의 핵심 구성 요소
PyTorch Monarch 개요
- PyTorch Monarch는 대규모 모델의 분산 학습 및 추론을 단순화하기 위한 PyTorch의 새로운 구성 요소로 소개됨
- 기존 PyTorch의 유연성을 유지하면서, 수십억 개의 파라미터를 가진 모델을 여러 GPU 및 노드에 효율적으로 배치할 수 있도록 설계
- 복잡한 병렬화 전략을 수동으로 구성할 필요 없이, 자동화된 분할 및 통신 최적화 기능을 제공
- Monarch의 핵심 목표는 모델 병렬화의 추상화 수준을 높여, 개발자가 모델 구조 설계에 집중할 수 있도록 하는 것임
- 데이터 병렬화, 파이프라인 병렬화, 텐서 병렬화 등 다양한 병렬화 기법을 하나의 통합 인터페이스로 제어 가능
- 이를 통해 기존 분산 학습 프레임워크 대비 코드 복잡도와 통신 오버헤드를 크게 줄임
주요 기능과 기술적 특징
- Monarch는 자동 분할 알고리듬을 통해 모델의 각 레이어를 최적의 장치에 배치함
- GPU 메모리 용량, 통신 대역폭, 연산 부하 등을 고려해 분할 전략을 동적으로 결정
- 이러한 자동화는 특히 LLM, Transformer 기반 모델, 대규모 추천 시스템에서 높은 효율성을 발휘
-
통합 병렬화 API를 제공해, 개발자가 단일 코드베이스로 다양한 병렬화 전략을 실험 가능
- 예를 들어, 동일한 모델을 데이터 병렬화와 파이프라인 병렬화 조합으로 실행하거나, 텐서 병렬화로 전환 가능
- 이러한 유연성은 모델 크기와 하드웨어 구성에 따른 최적화 탐색을 용이하게 함
- Monarch는 PyTorch의 기존 DistributedDataParallel(DDP) 및 Fully Sharded Data Parallel(FSDP) 기능과 호환됨
- 기존 코드베이스를 크게 수정하지 않고 Monarch로 이전 가능
- PyTorch의 TorchScript 및 TorchDynamo와도 통합되어, 컴파일 및 실행 최적화 지원
성능 및 활용 사례
- 초기 벤치마크 결과, Monarch는 기존 PyTorch 분산 학습 대비 통신 효율 20~30% 향상, 메모리 사용량 15% 절감을 달성
- 특히 수십억 파라미터 규모의 모델에서 학습 속도 및 GPU 활용률이 크게 개선됨
- 대규모 언어 모델(예: GPT 계열)과 추천 시스템에서 실험적으로 검증됨
- Monarch는 클라우드 및 온프레미스 환경 모두에서 동작하며, AWS, Azure, GCP 등 주요 클라우드 인프라와 호환
- PyTorch Lightning, Hugging Face Transformers 등 상위 프레임워크와의 통합도 지원
PyTorch 생태계에서의 의미
- Monarch는 PyTorch가 대규모 AI 모델 시대에 대응하기 위한 핵심 인프라 확장으로 평가됨
- 기존의 단일 GPU 중심 학습 패러다임에서 벗어나, 수천 개 GPU를 활용한 초대형 모델 학습을 실현하는 기반 제공
- 연구자와 기업 모두에게 확장성과 효율성을 동시에 확보할 수 있는 표준화된 분산 학습 솔루션으로 작용
- PyTorch 팀은 Monarch를 오픈소스로 공개해, 커뮤니티 피드백을 반영하며 지속적으로 발전시킬 계획
- 향후 자동 최적화, 동적 스케줄링, 하이브리드 병렬화 기능이 추가될 예정
- PyTorch의 차세대 분산 학습 프레임워크로서, AI 인프라의 민주화와 접근성 향상에 기여할 전망
Hacker News 의견
-
이 프로젝트가 Tinker와는 다른 계층을 겨냥하는 것 같음
Tinker 소개 글을 보면 Tinker는 관리형 파인튜닝 서비스이고, Monarch는 인프라 프리미티브를 제공하는 구조임
그래서 Monarch 위에 Tinker 같은 서비스를 구축할 수도 있을지 궁금함- 지금은 TorchForge 같은 게 그 위에서 동작하고 있음
-
PyTorch의 oxidation이 시작된 것 같음
Monarch는 Python 기반 프런트엔드와 Rust로 구현된 백엔드로 나뉘어 있음
전체적으로 꽤 흥미로운 프로젝트로 보임- 여러 출처에 따르면 Monarch는 PyTorch의 실험적 프레임워크이지 대체품은 아님
여전히std::shared_ptr기반의 순환 그래프와 메모리 누수를 즐길 수 있을 듯함
함수형 언어로 완전히 새로 작성하지 않은 게 아쉬움 - 이건 기존 프로젝트의 산화 버전이 아니라 완전히 새로운 프로젝트로 보임
- 여러 출처에 따르면 Monarch는 PyTorch의 실험적 프레임워크이지 대체품은 아님
-
나는 직접 PyTorch 확장을 만들어봤음 — mycelya-torch
내 버전은 아직 노드 간 통신을 지원하지 않지만, Monarch가 성능을 확보하는 방식이 흥미로웠음
Monarch는 아마 cloudpickle을 사용해 코드를 모든 노드에 공유하는데, 이는 초기 설정 비용만 들고 효율적임
단일 컨트롤러에서 메시지를 fan-out하는 구조도 인상적이었음
다만 커스텀 커널 지원 여부나 액터 간 통신 제어의 세밀함이 궁금함
전체적으로 멀티 컨트롤러보다 이 접근이 더 마음에 듦- 커스텀 커널을 쓰려면 원격 워커 초기화 코드를 조금 수정해야 할 수도 있음
하지만 필요한 커널이나 시스템 코드를 직접 내장(bake-in) 할 수 있음
- 커스텀 커널을 쓰려면 원격 워커 초기화 코드를 조금 수정해야 할 수도 있음
-
이게 Ray와 비슷한 구조로 보임
- 코드 예시가 Ray와 거의 동일함
Monarch의Actor와 Ray의@ray.remote클래스가 같은 패턴을 따름 - Ray 대신 Monarch를 쓸 이유가 궁금함 — PyTorch나 tensor abstraction과의 더 긴밀한 통합 때문일까 생각함
-
Dask도 유사한 분산 처리를 하지만, 원래 HPC용이라 GPU 지원은 제한적임
Dask 공식 사이트 참고 - 나도 같은 생각을 했음. 특히 PyTorch와 Ray의 최근 협업 발표를 보면 더 그렇다고 느낌
관련 블로그
- 코드 예시가 Ray와 거의 동일함
-
흥미롭네, 본질적으로 Fortran coarray(2008) 개념을 떠올리게 함
- 혹은 Hadoop(2006) 같기도 함
다만 MapReduce나 Fortran을 직접 쓸 필요가 없어서 훨씬 낫다고 생각함
- 혹은 Hadoop(2006) 같기도 함
-
“단일 호스트 병목을 피하고 메시지 전달을 위한 분산 클러스터로 전체 메쉬를 활용한다”는 문구가 있었는데,
수정할 수 있는 사람이 본다면 참조용 수치를 추가해줬으면 함 -
좋은 프로젝트로 보임
궁금한 점이 있음- 이게 openMPI와 유사한가?
- 메쉬는 어떻게 구성되는가? 같은 호스트 내에서만 가능한가?
-
이게 coarray 세계에서 중요한 프로젝트가 될 수도 있지만, 이미 문제의 조짐이 있음
텐서 엔진이 CUDA와 RDMA(ibverbs)에 묶여 있고, GPUDirect RDMA를 사용하는 코드라
결국 CUDA 종속성이 더 심해질 것 같음
OpenUCX를 썼다면 더 나았을 것 같음 -
Jax보다 기능적으로 약한 것처럼 보임
Jax는 강력한 컴파일러로 노드 간 통신을 최적화함- 하지만 Monarch는 단일 컨트롤러 패러다임에 초점을 맞춘 반면, Jax는 멀티 컨트롤러 SPMD 구조임
단일 컨트롤러는 이해하기 쉽고, 멀티 컨트롤러는 특정 데이터플로우에 더 최적임
두 접근을 혼합한 흥미로운 시도들도 있음
- 하지만 Monarch는 단일 컨트롤러 패러다임에 초점을 맞춘 반면, Jax는 멀티 컨트롤러 SPMD 구조임