Single controller programming with Monarch

SPMD (Single Program Multiple Data) 는 학습 시대의 천재적 결정이었다. torchrun --nproc_per_node=8 한 줄이면 8 GPU 가 같은 코드를 같은 속도로. 그러나 — RL 학습, agentic 시스템, multimodal serving 에서는 GPU 마다 다른 역할이다. SPMD 가 자연스럽지 않다.

강의의 끝에 손에 잡혀야 하는 건 4개의 추상(ProcMesh, ActorMesh, broadcast, RDMA)과 1개의 패러다임 전환(SPMD → single controller). 그리고 “언제 SPMD 를 깨고 single controller 로 갈 가치가 있는가” 의 판단 기준.

강의의 가장 중요한 슬라이드. 두 패러다임의 nuance 를 이 자리에서 잡지 못하면 Monarch 의 디자인이 안 풀린다.

그러나 RL 학습은 — rollout 은 sampler GPU, reward 는 별도 GPU, learner 는 backward GPU. 같은 코드가 아니다. SPMD 위에서 if rank in rollout_ranks: 식으로 분기하면 코드가 빠르게 망가진다. 역할 분리가 첫 시민이어야 깨끗하다.

Monarch 의 코드는 결국 4개 추상 위에서 짜인다. 이 4개를 잡으면 나머지는 derivative.

# pseudo-code — Monarch 패턴
from monarch import proc_mesh, Actor, endpoint

class Worker(Actor):
    def __init__(self):
        self.model = build_model().cuda()

    @endpoint
    async def forward(self, x):
        return self.model(x)

    @endpoint
    async def sync(self, peer):
        # RDMA point-to-point
        await rdma.transfer(self.model, peer)

# controller 측 — single machine 처럼
async def main():
    # 32 worker mesh
    procs = await proc_mesh(
        hosts=4, gpus_per_host=8,
    )
    workers = await procs.spawn(
        "workers", Worker,
    )

    # 모든 worker 에 broadcast 호출
    outputs = await workers.forward(batch)

    # 한 worker 에만 unicast — index
    one = await workers[0].forward(batch)

    # actor 사이 RDMA
    await workers[0].sync(workers[1])

Monarch 의 디자인 결정은 새로운 게 아니다 — Erlang/OTP 의 actor model 이 30년간 fault-tolerant distributed system 의 표준 방법이었다. Monarch 는 그 정신을 ML stack 에 옮긴다.

• actor = 격리된 process. 자기 state 만 관리. 다른 actor 와는 message 로만 소통.
• message passing. 공유 메모리 없음 — race condition 의 큰 부류 제거.
• let it crash. 한 actor 죽으면 — supervisor 가 새 actor 로 교체. 방어 코드 대신 단단한 격리.
• location transparency. actor 가 같은 process 안인지 다른 머신 위인지 — 호출자는 모름. controller 코드는 어느 쪽이든 같음.

Monarch 의 fault tolerance 는 Erlang/OTP 의 supervision tree 를 차용. actor 가 죽으면 부모 actor (또는 supervisor) 에 통보. supervisor 가 정책에 따라 — restart, escalate, ignore.

• one-for-one: 죽은 actor 만 restart. 가장 단순. RL 의 rollout actor 가 한 개 죽었을 때.
• all-for-one: 한 actor 죽으면 같은 그룹 전체 restart. 학습의 데이터 병렬에서 한 GPU 가 ECC 에러 → 전체 batch 다시.
• rest-for-one: 죽은 actor 와 그 후속 actor 만 restart. pipeline 의 한 stage 가 망가졌을 때.
• escalate: 자식의 실패를 부모에 위임. 부모도 못 풀면 더 위로.

그리고 RDMA 의 자리. Monarch 는 direct GPU↔GPU memory transfer 를 1차 시민으로. NCCL collective 의 단순한 broadcast 위에 — point-to-point custom transfer. RL 의 weight sync (learner → rollout) 같은 비균질한 패턴이 자연스럽게 표현된다.

실제 코드로 보면 Monarch 의 ergonomic 이 SPMD 대비 어떤 형태인지가 명확해진다. RL 학습의 한 step 을 두 패러다임으로.

# SPMD — 같은 코드를 모든 rank 가 실행
def train_step():
    rank = dist.get_rank()
    if rank in ROLLOUT_RANKS:
        traj = collect_trajectory()
        # trajectory 를 learner 로 전달?
        # gather/scatter 가 복잡
        dist.gather(traj, dst=LEARNER_RANK)
    elif rank in LEARNER_RANKS:
        traj = dist.gather(...)
        loss = compute_loss(traj)
        loss.backward()
        # 새 weight 를 ROLLOUT_RANKS 로
        broadcast_weights(model, ROLLOUT_RANKS)
    elif rank in REWARD_RANKS:
        ...

# 코드가 if/elif 폭발 — 역할이 늘면 더 더러워짐

# Monarch — controller 가 imperative 하게
async def train_step(rollouts, rewards, learners):
    # 1. rollout 그룹에 sample
    trajs = await rollouts.collect()

    # 2. reward 계산
    scored = await rewards.score(trajs)

    # 3. learner 가 backward
    new_w = await learners.update(scored)

    # 4. weight 를 rollout 으로 RDMA
    await rollouts.set_weights(new_w)

# 코드가 그냥 한 흐름 — 마치 single machine

같은 일을 한다. 그러나 두 코드의 가독성이 결정적으로 다르다. Monarch 의 controller 코드는 “이 학습이 무엇을 하는지” 가 직접 읽힌다. SPMD 코드는 “이 rank 가 어떤 일을 하는지” 의 분기를 머릿속에서 풀어야 한다.

Monarch 의 차별점은 “PyTorch native”. tensor 가 1차 시민이고, RDMA 가 framework 안에 있고, supervision tree 가 actor 의 기본 행태. Ray 는 더 generic 한 distributed Python — 그래서 ML 외 영역에서도 강력하지만 ML 쪽으로는 한 layer 의 wrapping 이 필요.

Monarch 가 v0 단계임에도 흥미로운 자리에서 등장하기 시작.

• torchforge — PyTorch 의 agentic RL framework. Monarch 위에 actor 분산. OpenEnv (L091) 와 자연스럽게 결합.
• internal Meta workloads — 정확한 사례는 미공개. RL training run 의 일부 자리.
• research workloads — Berkeley, CMU 등의 분산 RL 연구. Ray 의 친숙함 + PyTorch native 의 타협으로 매력.
• 학습 운영 layer — L090 (resilient ML eng) 의 자동화된 형태. supervision tree 가 framework default 면 운영 코드가 줄어든다.

• 대규모 학습의 hot path 가 아님 — pure data 병렬 학습은 여전히 FSDP/Megatron 이 더 빠름.
• collective 의 부분 지원 — NCCL all-reduce 같은 patterned collective 는 Monarch 안에서 actor 로 표현하면 overhead. 하이브리드가 권장.
• build 부담 — Rust nightly + cmake + CUDA 가 모두 필요. 특히 source build 가 거칠다.
• pre-built wheel — 일부 플랫폼 한정. 일반 사용자가 시도하기 아직 진입장벽.
• API 변동 가능성 — repo 가 명시. 1.0 까지 backward compat 보장 없음.
• 디버깅 도구 — actor mesh 위 분산 디버깅의 도구가 미성숙. SPMD 의 py-spy 같은 standard 가 아직.

실습 시퀀스

1. Monarch hello world — repo 의 example 로 첫 ProcMesh 띄우고 actor spawn. 가장 작은 controller 코드 한 step 실행.
2. actor 죽이기 — 일부러 한 actor 안에서 raise. supervisor 가 어떻게 받는지, 다른 actor 가 어떻게 살아남는지 확인.
3. broadcast vs unicast — workers.foo() 와 workers[i].foo() 의 차이. 같은 mesh 위 두 패턴.
4. RDMA transfer — actor 사이 GPU 메모리 직접 transfer. tensor 시간 측정 + NCCL all-reduce 시간 비교.
5. RL toy — 4 rollout actor + 1 learner actor 의 simple GRPO. SPMD 버전과 코드 길이 비교.

• transcript 가 실패해서 본 노트의 코드 예시는 repo README + 일반 actor model 패턴. 정확한 API 시그니처는 repo 의 example 코드에서.
• Ray 와의 throughput 비교 — 같은 RL workload 에서 두 framework 의 이득/손해 정량 비교가 강의에 있었을 가능성.
• FSDP 와의 hybrid — Monarch controller 안에서 SPMD 그룹을 actor 로 두는 패턴. 강의에서 어떻게 권장했는지.
• RDMA backend 의 정확한 지원 — IB / NVLink / RoCE 의 어디까지 자동인지.
• internal use 의 사례 — Meta 안에서 어떤 학습 run 에서 실제로 채택됐는지 (강의에 살짝 등장 가능성).
• 1.0 로드맵 — API freeze 시점, 빌드 단순화, 디버깅 도구 도입 일정.