PCCL — Pluralis Collective Communication Library

대규모 학습 클러스터의 hardware MTBF (mean time between failures) 는 GPU 당 보통 수개월 ~ 수년. 1 만 GPU 면 몇 시간마다 한 번 누군가가 실패한다. NCCL 은 “모두가 살아있다” 를 가정 — 한 GPU 라도 timeout/error 가 나면 collective 가 abort, communicator 재구성이 필요. 큰 학습 한 번에 재시작 수십 번.

강의의 출발 질문 셋.

1. 왜 NCCL 은 fault tolerant 하지 않은가 — design choice 였음. 작은 클러스터에서는 의미 없음.
2. 실패는 어떻게 분류되는가 — fail-stop, fail-slow (straggler), Byzantine. 각자 다른 치료.
3. collective semantics 를 유지하면서 일부 실패를 견딜 수 있는가 — PCCL 의 답은 yes — 단, 결과의 의미가 살짝 바뀐다.

PCCL 이전에 분산 학습 인프라가 노드 실패에 대처해온 방법 네 가지. 각자 다른 layer 에서 다른 의미로 푼다.

분산 시스템 이론의 표준 분류 — fault model 의 3 단계. PCCL 은 어디까지 다루나?

실 데이터 — Meta · OPT-175B 학습

OPT-175B 의 학습 보고서 (Zhang et al., 2022) 가 인용되는 흔한 reference. ~1000 GPU 학습에서 — 3 개월 학습 동안 100+ 번의 실패, 중간 ~25% 의 시간이 재시작 / 디버깅. 같은 비율을 10× scale 에 적용하면 1만 GPU 학습은 실패 시간만 한 달 단위.

straggler 의 특수성

fail-stop 은 timeout 으로 잡힌다. straggler 는 더 까다롭다 — 살아있지만 5× 느림. NCCL 의 ring 은 모든 rank 의 속도가 비슷할 때만 작동. 한 rank 가 5× 느리면 전체가 5× 느려짐. PCCL 의 입장 — “느린 rank 는 일정 시간 후 skip 하고 다음 step”. 의미적으로 “느린 rank 의 gradient 는 늦게 들어옴” 이 됨 (asynchronous learning 에 가까워짐).

PCCL 의 핵심 추상 — elastic group. NCCL 의 communicator 가 “고정 멤버십” 이라면, PCCL 의 group 은 “현재 시점의 멤버십”. 매 collective 호출 마다 group 이 변할 수 있다.

# 개념적 API
group = pccl.Group(initial_ranks=128,
                   min_ranks=96,
                   max_ranks=160)

for step in training_loop:
    # N 은 매 호출마다 다를 수 있음
    n_alive = group.allreduce(grad,
                              op='mean',
                              policy='skip_dead')
    if n_alive < group.min_ranks:
        wait_for_recovery()
    # 학습 step 진행

이 추상이 PCCL 의 power. 합 자체가 약속이 아니라, 합 + count + alive set 이 결과. application 은 이 셋으로 자기 의미 (mean, weighted mean, robust mean 등) 를 다시 만든다.

PCCL 은 NCCL 의 대체가 아니다 — 다른 trade-off 의 다른 라이브러리. 무엇이 같고 무엇이 다른지.

PCCL 의 또 다른 power — 죽음만이 아니라 합류도 처리. cluster 가 새 노드를 띄워줄 때, 이 노드를 학습에 합류시키는 비용이 “재시작” 이면 거의 못 쓰는 자원. PCCL 은 in-place 합류.

data parallel 만 단순

data parallel (DDP, FSDP) 에서 합류는 단순 — 모든 rank 가 같은 weight 를 보유. 한 rank 의 weight 를 새 rank 로 broadcast 하면 끝. tensor parallel / pipeline parallel 은 더 복잡 — 각 rank 가 다른 부분의 weight 를 가짐. 합류 시 sharding 자체를 다시 계산해야 함. PCCL 의 처음 target 은 DP, TP/PP 는 후속.

PCCL 의 내부 구조는 control plane + data plane 의 분리. NCCL 은 사실상 data plane 만 — 통신 자체. PCCL 은 그 위에 control plane (멤버십 관리, 실패 감지, view 동기화) 을 추가.

view synchronization

분산 합의의 핵심 — "이번 collective 에서 누가 참여하는지" 에 모든 rank 가 같은 답을 가져야 함. 한 rank 는 “R3 살았다” 라고 보고, 다른 rank 는 “R3 죽었다” 로 보면 — allreduce 의 결과 자체가 분기됨. PCCL 의 핵심 protocol 은 view 를 collective epoch 별로 동기화.

PCCL 의 production 적용은 2024-2025 시점에서 frontier lab 들에서 시작. 정확한 사례는 강의 영상 확인 필요하지만, 일반적 패턴을 정리한다.

• data parallel 학습의 elastic 부분 — DDP / FSDP 의 일부 group 에 PCCL 적용. TP 그룹은 NCCL, DP 그룹만 PCCL 같은 hybrid.
• fine-tuning 클러스터 — pre-training 만큼 critical 하지 않은 학습. 합류/이탈이 잦은 환경에 자연스러운 fit.
• RLHF rollout 클러스터 — actor 들이 동시에 sample 생성. PCCL 의 elastic 이 적합. L054 와 연결.
• shared cluster — multi-tenant 환경에서 priority preemption. 우선순위 높은 작업이 들어올 때 일부 rank 잠시 빠짐.

간단한 ROI 계산

1만 GPU 학습, 시간당 1회 실패, NCCL 재시작 비용 30분, 학습 1달. 손실 시간 = 24×30 day×1×30min = ~360 hours = ~15 days. 학습의 50% 가 재시작 비용. PCCL 로 이 비용을 ~5% 로 줄이면 학습 wall clock 이 ~2× 빠름. 큰 학습에서는 매우 큰 saving.

• NCCL 3.x 와의 수렴 — NCCL 자체가 partial recovery 를 도입. PCCL 의 idea 가 mainstream 으로. 향후 5년 내 “elastic NCCL” 이 default 될 가능성.
• TP/PP 의 elastic — 가장 어려운 부분. sharding 자체가 변해야 함. 미해결 frontier.
• predictive failure detection — GPU의 ECC error 패턴 등으로 실패 1-2분 전 예측. graceful drain. 운영팀의 일이지만 collective 가 hint 받을 수 있음.
• silent corruption 검증 — checksum, redundancy. PCCL 다음의 자연스러운 확장.
• cross-cluster federation — 여러 데이터센터 사이의 collective. WAN 위 collective 는 fault tolerance 가 사실상 default.

손에 새기기 — 실습 시퀀스

1. NCCL 의 실패 모드 직접 보기 — 작은 multi-GPU 학습을 돌리다가 한 process 를 강제 kill. NCCL 이 timeout / abort 어떻게 행동하는지 확인.
2. elastic torchrun 베이스라인 — torchrun --max-restarts=3 으로 같은 시나리오. checkpoint 부터 다시 시작하는 비용 측정.
3. failure injection — 학습 코드에 chaos monkey. step 마다 1% 확률로 한 rank 가 sleep 5초. straggler 시뮬.
4. view synchronization 직접 구현 — etcd 를 control plane 으로, alive set 을 매 step 동기화. NCCL 위에 simple PCCL prototype.
5. ROI 계산 — 자기 클러스터의 실 실패 빈도, 재시작 비용 측정. PCCL 도입의 break-even 시간 계산.
6. FSDP + PCCL shim — PyTorch FSDP 에 PCCL backend 적용 (가능하면). DP allreduce 만 elastic.

PCCL 은 통신 라이브러리 가족의 “fault tolerance 축” 위 노드.

• PCCL 의 정확한 API — 본문은 개념적 형태. repo / 문서가 공개되면 정확한 시그너처로 교체.
• throughput 95% NCCL 의 정확한 수치 — 일반적 추정. 강의의 정확한 measurement 확인 필요.
• mike64t 의 affiliation 과 background — username 만 있어 강의 영상에서 확인 필요.
• TP / PP 에서의 elastic 디자인 — 본문에서 “미해결” 로 적었지만 강의 영상에서 토론됐을 가능성. 확인 필요.
• 실제 production 채택 사례 — DeepSeek, Meta, Google 중 누가 PCCL 류 사용? 본문은 일반적 사례만.
• NCCL 3.x 의 fault tolerance 와의 정확한 차이 — 두 라이브러리가 같은 시점에 같은 problem 을 풀고 있어 비교 question 가 활발.