# PyTorch Monarch 공개 > Clean Markdown view of GeekNews topic #23893. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23893](https://news.hada.io/topic?id=23893) - GeekNews Markdown: [https://news.hada.io/topic/23893.md](https://news.hada.io/topic/23893.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-25T01:32:57+09:00 - Updated: 2025-10-25T01:32:57+09:00 - Original source: [pytorch.org](https://pytorch.org/blog/introducing-pytorch-monarch/) - Points: 3 - Comments: 1 ## Topic Body - **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 인프라의 민주화와 접근성 향상**에 기여할 전망 ## Comments ### Comment 45426 - Author: neo - Created: 2025-10-25T01:32:58+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45680237) - 이 프로젝트가 **Tinker**와는 다른 계층을 겨냥하는 것 같음 [Tinker 소개 글](https://thinkingmachines.ai/blog/announcing-tinker/)을 보면 Tinker는 관리형 파인튜닝 서비스이고, Monarch는 인프라 **프리미티브**를 제공하는 구조임 그래서 Monarch 위에 Tinker 같은 서비스를 구축할 수도 있을지 궁금함 - 지금은 [TorchForge](https://pytorch.org/blog/introducing-torchforge/) 같은 게 그 위에서 동작하고 있음 - PyTorch의 **oxidation**이 시작된 것 같음 Monarch는 Python 기반 프런트엔드와 Rust로 구현된 백엔드로 나뉘어 있음 전체적으로 꽤 흥미로운 프로젝트로 보임 - 여러 출처에 따르면 Monarch는 PyTorch의 **실험적 프레임워크**이지 대체품은 아님 여전히 `std::shared_ptr` 기반의 순환 그래프와 메모리 누수를 즐길 수 있을 듯함 함수형 언어로 완전히 새로 작성하지 않은 게 아쉬움 - 이건 기존 프로젝트의 산화 버전이 아니라 완전히 **새로운 프로젝트**로 보임 - 나는 직접 **PyTorch 확장**을 만들어봤음 — [mycelya-torch](https://github.com/alyxya/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 공식 사이트](https://www.dask.org/) 참고 - 나도 같은 생각을 했음. 특히 PyTorch와 Ray의 최근 **협업 발표**를 보면 더 그렇다고 느낌 [관련 블로그](https://pytorch.org/blog/pytorch-foundation-welcomes-ray-to-deliver-a-unified-open-source-ai-compute-stack/) - 흥미롭네, 본질적으로 **Fortran coarray(2008)** 개념을 떠올리게 함 - 혹은 **Hadoop(2006)** 같기도 함 다만 MapReduce나 Fortran을 직접 쓸 필요가 없어서 훨씬 낫다고 생각함 - “단일 호스트 병목을 피하고 메시지 전달을 위한 분산 클러스터로 전체 메쉬를 활용한다”는 문구가 있었는데, 수정할 수 있는 사람이 본다면 **참조용 수치**를 추가해줬으면 함 - 좋은 프로젝트로 보임 궁금한 점이 있음 - 이게 **openMPI**와 유사한가? - 메쉬는 어떻게 구성되는가? 같은 호스트 내에서만 가능한가? - 이게 **coarray 세계**에서 중요한 프로젝트가 될 수도 있지만, 이미 문제의 조짐이 있음 텐서 엔진이 CUDA와 RDMA(ibverbs)에 묶여 있고, **GPUDirect RDMA**를 사용하는 코드라 결국 CUDA 종속성이 더 심해질 것 같음 **OpenUCX**를 썼다면 더 나았을 것 같음 - Jax보다 **기능적으로 약한** 것처럼 보임 Jax는 강력한 컴파일러로 노드 간 통신을 최적화함 - 하지만 Monarch는 **단일 컨트롤러 패러다임**에 초점을 맞춘 반면, Jax는 **멀티 컨트롤러 SPMD** 구조임 단일 컨트롤러는 이해하기 쉽고, 멀티 컨트롤러는 특정 데이터플로우에 더 최적임 두 접근을 혼합한 흥미로운 시도들도 있음