Hacker News 의견

• 이 프로젝트가 Tinker와는 다른 계층을 겨냥하는 것 같음
  Tinker 소개 글을 보면 Tinker는 관리형 파인튜닝 서비스이고, Monarch는 인프라 프리미티브를 제공하는 구조임
  그래서 Monarch 위에 Tinker 같은 서비스를 구축할 수도 있을지 궁금함

  • 지금은 TorchForge 같은 게 그 위에서 동작하고 있음

• PyTorch의 oxidation이 시작된 것 같음
  Monarch는 Python 기반 프런트엔드와 Rust로 구현된 백엔드로 나뉘어 있음
  전체적으로 꽤 흥미로운 프로젝트로 보임

  • 여러 출처에 따르면 Monarch는 PyTorch의 실험적 프레임워크이지 대체품은 아님
    여전히 std::shared_ptr 기반의 순환 그래프와 메모리 누수를 즐길 수 있을 듯함
    함수형 언어로 완전히 새로 작성하지 않은 게 아쉬움
  • 이건 기존 프로젝트의 산화 버전이 아니라 완전히 새로운 프로젝트로 보임

• 나는 직접 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의 최근 협업 발표를 보면 더 그렇다고 느낌
    관련 블로그

• 흥미롭네, 본질적으로 Fortran coarray(2008) 개념을 떠올리게 함

  • 혹은 Hadoop(2006) 같기도 함
    다만 MapReduce나 Fortran을 직접 쓸 필요가 없어서 훨씬 낫다고 생각함

• “단일 호스트 병목을 피하고 메시지 전달을 위한 분산 클러스터로 전체 메쉬를 활용한다”는 문구가 있었는데,
  수정할 수 있는 사람이 본다면 참조용 수치를 추가해줬으면 함

• 좋은 프로젝트로 보임
  궁금한 점이 있음

  • 이게 openMPI와 유사한가?
  • 메쉬는 어떻게 구성되는가? 같은 호스트 내에서만 가능한가?

• 이게 coarray 세계에서 중요한 프로젝트가 될 수도 있지만, 이미 문제의 조짐이 있음
  텐서 엔진이 CUDA와 RDMA(ibverbs)에 묶여 있고, GPUDirect RDMA를 사용하는 코드라
  결국 CUDA 종속성이 더 심해질 것 같음
  OpenUCX를 썼다면 더 나았을 것 같음

• Jax보다 기능적으로 약한 것처럼 보임
  Jax는 강력한 컴파일러로 노드 간 통신을 최적화함

  • 하지만 Monarch는 단일 컨트롤러 패러다임에 초점을 맞춘 반면, Jax는 멀티 컨트롤러 SPMD 구조임
    단일 컨트롤러는 이해하기 쉽고, 멀티 컨트롤러는 특정 데이터플로우에 더 최적임
    두 접근을 혼합한 흥미로운 시도들도 있음