04. Pipeline·data·sequence·context parallelism — 여러 축을 한 표에서 비교하기

이 장의 핵심 질문

• TP 말고도 병렬화 "축"이 왜 여럿인가? 각 축은 서로 다른 무엇을 나누는가?
• 파이프라인·데이터·시퀀스·컨텍스트 병렬화를 같은 골격 표(나눔/복제/통신)에 넣으면 무엇이 보이는가?
• 추론의 데이터 병렬화와 학습의 데이터 병렬화는 왜 다른가?

앞 장과의 연결 — 03장에서 TP는 "레이어 안"을 나누고 매 레이어 all-reduce가 생긴다고 했다. 이 장은 나누는 대상을 바꿔 본다: 레이어 사이(PP), 요청 배치(DP), 시퀀스 길이(SP), 긴 컨텍스트(CP). 각 축의 통신 성격이 왜 다른지가 핵심이다.

먼저: "축(axis)"이라는 말

병렬화 축이란 "무엇을 기준으로 일을 나누는가"의 방향이다. TP는 가중치 행렬 차원을 기준으로 나눴다. 다른 축들은 다른 것을 기준으로 나눈다:

• 파이프라인 병렬화(PP) — 레이어(깊이) 를 기준으로. 앞쪽 레이어들은 GPU0, 뒤쪽은 GPU1.
• 데이터 병렬화(DP) — 요청/배치 를 기준으로. 요청 A는 복제본0, 요청 B는 복제본1.
• 시퀀스 병렬화(SP) — 시퀀스(토큰) 길이 를 기준으로. 한 요청의 토큰들을 device끼리 나눔.
• 컨텍스트 병렬화(CP) — 아주 긴 컨텍스트 를 기준으로. 초장문 입력의 어텐션을 나눠 계산.

여러 축은 동시에 겹쳐 쓸 수 있다(예: TP × PP × DP). 이를 종종 3D(또는 그 이상) 병렬화라 부른다. 축이 겹치면 통신도 겹친다.

Pipeline parallelism (PP) — 레이어를 깊이로 나눈다

개념

모델의 레이어들을 여러 스테이지(stage) 로 갈라, 각 device가 연속된 레이어 묶음을 맡는다. 데이터(활성값)가 컨베이어 벨트처럼 GPU0 → GPU1 → GPU2로 흐른다. 자동차 조립 라인 비유가 잘 통한다: 각 스테이션이 정해진 공정만 하고 반제품을 다음으로 넘긴다.

골격 표

특징과 함정: pipeline bubble

PP의 통신은 인접 스테이지끼리 활성값을 넘기는 p2p라 TP의 all-reduce보다 대체로 성기고 노드 경계를 넘기기 쉽다(scale-out 허용). 하지만 고유의 함정이 있다: 파이프라인 버블(bubble). 첫 요청이 마지막 스테이지에 도달하기 전까지 뒤쪽 device는 놀고, 마지막 요청이 빠져나갈 때 앞쪽 device가 논다. 조립 라인 시작·끝에서 일부 스테이션이 비는 것과 같다.

버블을 줄이려면 여러 요청(micro-batch)을 촘촘히 흘려보내 라인을 채워야 한다. 하지만 이는 배치·스케줄링 복잡도를 높인다.

⚖️ 절충 — PP는 레이어를 나눠 capacity(①)를 풀고, 통신이 성겨 노드 경계를 넘기 쉽다(scale-out 친화). 그 대가로 버블에 의한 device 유휴와 스케줄링 복잡도가 생긴다. TP(레이어 안, 통신 집약, 노드 안)와 PP(레이어 사이, 통신 성김, 노드 넘김)는 상호 보완적이라 흔히 함께 쓴다: TP는 노드 안, PP는 노드 사이.

Data parallelism (DP) — 요청/배치를 나눈다 (추론 맥락 주의)

개념

같은 (병렬화된) 모델을 여러 벌 복제하고, 서로 다른 요청·배치를 각 복제본이 처리한다. 식당을 여러 지점으로 복제해 손님을 나눠 받는 것(01장 비유).

골격 표 — 추론 기준

⚠️ 경계 혼동 주의 — 추론 DP ≠ 학습 DP — 학습(training) 의 DP는 각 복제본이 gradient를 계산한 뒤 all-reduce로 gradient를 합쳐 가중치를 동기화한다(매 스텝 큰 통신). 추론(inference) 의 DP는 가중치가 고정이라 gradient가 없다. 그래서 추론 DP는 "엔진을 복제해 요청을 나눠 받는 것"에 가깝고, 매 스텝 collective가 아니라 라우팅·로드밸런싱·상태(KV) 관리가 문제가 된다(09장). 이 안내서는 추론 인프라가 주제이므로, 흔한 학습 중심 설명을 그대로 옮기지 않는다.

DP는 01장의 traffic(③) 을 푸는 정통 해법이다: 복제본을 늘리면 감당하는 요청 수가 는다. 오토스케일링(09장)은 이 복제 수를 부하에 맞춰 조절한다.

📌 핵심 — 추론에서 DP는 "collective를 새로 만드는 축"이 아니라 "복제와 라우팅의 축"이다. 통신 문제가 아니라 분배·상태 문제로 이어진다. 이 전환이 뒤 묶음(②·서비스 경로)의 시작점이다.

Sequence parallelism (SP) — 한 요청의 토큰을 나눈다

개념

한 요청의 시퀀스(토큰 축) 를 device끼리 나눠, 시퀀스에 걸친 연산(정규화·일부 활성값 처리 등)의 메모리·연산을 분산한다. TP와 함께 쓰여 활성값 메모리를 더 줄이는 데 자주 등장한다.

골격 표

SP는 주로 활성값 메모리 압박(긴 시퀀스에서 활성값이 커지는 문제)을 완화한다. TP와 짝지어 "가중치는 TP로, 시퀀스 활성값은 SP로" 나누는 조합이 흔하다.

Context parallelism (CP) — 아주 긴 컨텍스트의 어텐션을 나눈다

개념

컨텍스트가 매우 길어질 때(수십만 토큰급), 어텐션 계산과 그에 딸린 KV(선수 과정 ②) 가 한 device에 부담이 된다. CP는 긴 컨텍스트를 device끼리 나눠 어텐션을 분산 계산한다.

골격 표

⚠️ 경계 혼동 주의 — SP vs CP — 둘 다 "시퀀스/토큰 축을 나눈다"고 뭉뚱그리기 쉽지만 목적이 다르다. SP는 주로 활성값 메모리를 줄이는 데(TP 보조), CP는 초장문 컨텍스트의 어텐션·KV를 감당하는 데 초점이 있다. 구현·명명이 프레임워크마다 다르므로, 어떤 문서가 "sequence/context parallel"이라 하면 정확히 무엇을 나누고 왜 나누는지를 확인해야 한다(용어가 겹친다).

네 축(+TP)을 한 표에서

flowchart TB
    subgraph AXES["병렬화 축 — 무엇을 나누는가"]
        TP["TP<br/>레이어 안 가중치<br/>→ all-reduce (집약)"]
        PP["PP<br/>레이어(깊이)<br/>→ p2p (성김)"]
        DP["DP (추론)<br/>요청/배치<br/>→ 복제·라우팅"]
        SP["SP<br/>시퀀스 활성값<br/>→ all-gather/reduce-scatter"]
        CP["CP<br/>긴 컨텍스트·KV<br/>→ KV 교환"]
    end

    classDef comm fill:#ffe0b2,stroke:#e07b00,color:#000
    classDef req fill:#fff3c4,stroke:#d4a017,color:#000
    classDef mem fill:#e9d8fd,stroke:#7c3aed,color:#000
    class TP,PP comm
    class DP req
    class SP,CP mem

📌 핵심 — 축마다 나누는 대상·통신 성격·푸는 한계·노드 경계 적합성이 다르다. 그래서 실제 배포는 여러 축을 겹친다: 흔한 조합은 "노드 안 TP(+SP), 노드 사이 PP, 그 위에 DP 복제". 이 겹침을 설계하는 것이 분산 추론의 핵심 기술이며, 최적 조합은 모델·하드웨어·워크로드에 의존한다(조건 의존).

배포 D1 — 척추에 병렬화를 얹다

01장의 배포 D0(1 GPU·1 replica)에 이제 병렬화를 얹는다:

배포 D1 — 큰 모델이 한 장에 안 들어가므로(① capacity), 팀은 노드 안 TP로 레이어 안을 나누고(03장), 모델이 노드 하나로도 부족하면 PP로 노드 사이를 나눈다. 피크 트래픽(③)은 이 병렬화된 엔진을 DP로 복제해 감당한다. 각 선택마다 통신(all-reduce·p2p)과 노드 경계 비용이 붙는다는 것을 표로 추적한다.

이 D1에는 아직 "요청을 어느 복제본으로 보낼지"(라우팅, 09장), "PD 간섭을 어떻게 뗄지"(07장), "KV를 어디 둘지"(08장)가 빠져 있다. 다음 묶음(②)에서 채운다.

🔬 증거 읽기 — 어떤 배포가 "N-way 병렬화로 M배 처리량"이라고 하면 확인할 것: 어떤 축을 몇 도로 겹쳤는가(TP×PP×DP 각각), 각 축이 노드 안/밖 어디인가, M배의 분모는 무엇인가(요청 수? 토큰 수? device당?). 축 구성과 분모가 다르면 다른 배포의 "M배"와 비교 불가다(15장).

이 장에서 배운 것

• 병렬화 축은 "무엇을 기준으로 나누는가"의 방향이다: TP(레이어 안 가중치), PP(레이어 깊이), DP(요청/배치), SP(시퀀스 활성값), CP(긴 컨텍스트·KV).
• 각 축의 통신 성격이 다르다: TP는 all-reduce(집약, 노드 안), PP는 p2p(성김, 노드 넘김), 추론 DP는 매 스텝 collective 없이 복제·라우팅.
• 추론 DP ≠ 학습 DP: 추론은 gradient all-reduce가 없어, 통신 문제가 아니라 분배·상태(KV) 문제로 이어진다.
• SP와 CP는 목적이 다르다: SP는 활성값 메모리(TP 보조), CP는 초장문 어텐션·KV. 용어가 겹치니 "정확히 무엇을 왜 나누는지" 확인이 필수.
• 실제 배포는 여러 축을 겹치며, 최적 조합은 조건 의존이다.

🔎 이 장의 '지지하지 않는 결론' + 'unknown으로 남겨야 할 것'

• 지지하지 않는 결론 — "병렬화 축을 더 많이 겹치면 항상 낫다"는 지지되지 않는다. 축마다 통신·유휴(버블)·복잡도 비용이 있고, 겹치면 통신도 겹친다.
• unknown으로 남길 것 — 특정 모델·하드웨어의 최적 축 조합과 각 도(degree), SP/CP의 정확한 collective 패턴은 프레임워크·구현 의존이라 일반값을 못박지 않는다. 문서마다 SP/CP 명명이 다를 수 있으므로 정의 확인 전엔 unknown.

✍️ 확인 문제

1. PP와 TP는 둘 다 capacity를 풀지만 통신 성격이 정반대에 가깝다. 각각의 대표 collective와 "노드 경계를 넘기기 쉬운 정도"를 대비해, 왜 흔히 "노드 안 TP + 노드 사이 PP"로 조합하는지 설명하라.

1. (경계 혼동 유형) 어떤 학습 중심 튜토리얼이 "DP는 매 스텝 all-reduce로 gradient를 동기화한다"고 설명한다. 이 문장을 추론 배포에 그대로 적용하면 무엇이 틀리는가? 추론 DP에서 실제로 문제가 되는 것은 무엇인가?

1. (비교 가능성 유형) 배포 X는 "TP4×PP2로 2.5배", 배포 Y는 "DP8로 6배"라고 주장한다. 두 "배수"를 같은 표에 순위로 놓기 전에 반드시 물어야 할 것을 들고, 두 주장이 01장의 서로 다른 축(capacity/latency/traffic)을 다루고 있을 가능성을 지적하라.

다음 장에서는 특수하지만 중요한 축인 MoE와 expert parallelism을 연다. total vs activated 파라미터의 구분, 그리고 expert 사이의 all-to-all 통신이 왜 topology에 특히 민감한지가 초점이다.
다음 → 05. MoE와 expert parallelism — total vs activated, 그리고 all-to-all