03. Tensor parallelism — tensor를 어디서 나누고 무엇을 통신하는가

이 장의 핵심 질문
텐서 병렬화는 모델의 무엇을 나누는가? 그리고 나누면 왜 통신이 반드시 따라오는가?
"무엇이 shard / 무엇이 replicate / 어떤 collective"라는 골격을, 실제 행렬 곱에서 어떻게 채우는가?
TP는 capacity·latency·traffic(01장) 중 무엇을 풀고, 무엇을 새로 만드는가?

앞 장과의 연결 — 01장에서 capacity 한계의 해법 동사는 "나눈다(shard)"였고, 02장에서 나누면 collective 통신이 생기며 그것이 scale-up/scale-out 배관을 탄다고 했다. 이 장은 그 "나눔"의 가장 통신-집약적인 형태를 연다.

먼저: tensor parallelism이 뭔가요?

텐서 병렬화(tensor parallelism, TP) 는 하나의 레이어(층) 안의 가중치 행렬을 여러 device에 쪼개, 그 레이어의 행렬 곱(matmul)을 여러 device가 나눠 계산하게 하는 방법이다. 여기서 "tensor"는 신경망의 가중치·활성값을 담는 다차원 배열을 말한다.

일상 비유: 커다란 곱셈 표(구구단 확장판)를 혼자 다 계산하는 대신, 표를 세로로 잘라 여러 사람이 각자 맡은 열(column)만 계산하는 것이다. 각자 부분 결과를 내고, 마지막에 그 조각들을 합치거나 이어 붙여야 완전한 답이 된다. 이 "합치기·이어붙이기"가 바로 collective 통신이다.

TP는 한 레이어 안을 나눈다는 점이 중요하다(레이어 사이를 나누는 파이프라인 병렬화(04장)와 대비된다). 그래서 매 레이어마다 device 사이 통신이 발생한다 — TP가 통신-집약적인 이유다.

용어: TP degree(TP 차수) — 하나의 레이어를 몇 개 device로 쪼갰는가. TP degree가 2면 각 행렬을 2조각, 8이면 8조각으로 나눈다. degree가 클수록 device당 메모리·연산 부담은 줄지만 통신 상대 수와 빈도가 는다.

shard / replicate / collective — 이 과정의 골격 표

이 안내서의 핵심 기율(원칙 2)은 병렬화를 설명할 때 무엇이 나뉘고(shard) / 무엇이 복제되고(replicate) / 어떤 collective가 생기는가를 매번 분리하는 것이다. TP에서 이 표를 처음 채워 보자.

트랜스포머 블록의 두 핵심 부분(어텐션의 QKV·출력 투영, 그리고 MLP의 두 선형층)에서 TP가 어떻게 나누는지가 잘 알려진 패턴이다. 세부 수식 없이 구조만 본다.

요소	shard(나눔)	replicate(복제)	결과를 맞추는 collective
입력 활성값(레이어 진입)	—	각 device가 동일 입력을 가짐(복제)	(없음, 이미 공유)
첫 선형층 가중치 (열 분할, column-parallel)	device별로 출력 차원을 나눠 가짐	—	(없음, 각자 부분 출력 생성)
중간 활성값	device별 부분 조각	—	다음 층 구성에 따라 이어짐
둘째 선형층 가중치 (행 분할, row-parallel)	device별로 입력 차원을 나눠 가짐	—	all-reduce — 부분합을 모두 더해 완전한 출력
레이어 최종 출력	—	all-reduce 후 모든 device가 동일 결과 보유(복제)	(완료)

핵심 패턴: 열 분할 → (통신 없이 부분 계산) → 행 분할 → all-reduce로 합산. 이 "column-parallel 다음 row-parallel" 조합은 중간에 통신을 한 번으로 줄이도록 설계된 것이다. 어텐션 블록과 MLP 블록 각각에서 이 패턴이 반복되므로, 트랜스포머 레이어 하나당 대체로 소수의 all-reduce가 생긴다(어텐션에서 1회, MLP에서 1회가 전형적 패턴 — 구현·버전에 따라 다를 수 있으므로 정확한 횟수는 구현 의존).

flowchart LR
    IN["입력 활성값<br/>(모든 device 복제)"] --> A1["GPU0: 열 조각 0<br/>부분 계산"]
    IN --> A2["GPU1: 열 조각 1<br/>부분 계산"]
    A1 --> B1["GPU0: 행 조각 0<br/>부분합"]
    A2 --> B2["GPU1: 행 조각 1<br/>부분합"]
    B1 --> AR{{"all-reduce<br/>부분합 합산"}}
    B2 --> AR
    AR --> OUT["완전한 출력<br/>(모든 device 복제)"]

    classDef req fill:#fff3c4,stroke:#d4a017,color:#000
    classDef comp fill:#cfe2ff,stroke:#2563eb,color:#000
    classDef comm fill:#ffe0b2,stroke:#e07b00,color:#000
    class IN,OUT req
    class A1,A2,B1,B2 comp
    class AR comm

📌 핵심 — TP에서 가중치는 shard(각 device가 조각만 보유), 레이어 입출력 활성값은 사실상 replicate(all-reduce 뒤 모두 같은 값), 그리고 그 replicate를 성립시키는 접착제가 all-reduce collective다. 이 세 가지를 분리해 말할 수 있으면 TP를 "이해"한 것이다.

all-reduce가 뭔가요? (02장에서 예고한 collective 정의)

all-reduce는 여러 device가 각자 가진 부분값을 모두 더한(또는 다른 축약 연산) 결과를, 모든 device가 똑같이 나눠 갖는 통신이다. "각자의 부분합을 합쳐 전원이 같은 총합을 갖게 한다." TP의 row-parallel 층 뒤에서 부분합을 완전한 출력으로 만드는 데 쓰인다. NCCL은 이를 링·트리 알고리즘으로 구현한다(02장).

TP는 01장의 무엇을 풀고, 무엇을 새로 만드는가

푸는 것

capacity(①) — 큰 레이어 가중치를 여러 device에 쪼개므로, 한 장에 안 들어가던 모델이 올라간다. TP의 1차 목적.
latency(②) — 조건부 — 한 레이어의 연산을 여러 device가 나눠 하므로 단일 요청의 레이어 계산 시간이 줄 수 있다. 단, all-reduce 통신 시간이 더해지므로 순이득은 통신이 충분히 빠를 때만(=scale-up 도메인 안일 때) 성립한다.

새로 만드는 것

매 레이어 통신 — 레이어마다 all-reduce가 생겨, 통신이 연산과 직렬로 붙으면 지연이 누적된다(06장의 오버랩이 이걸 완화하려 시도).
노드 경계 민감성 — TP degree를 노드 밖으로 키우면(scale-out) all-reduce가 느린 링크를 타 급격히 나빠진다. 그래서 TP는 보통 NVLink 도메인(노드 내)에 가둔다(02장의 scale-up 원칙).

⚖️ 절충 — TP degree를 키우면 device당 메모리·연산이 줄지만(capacity·latency 이득), all-reduce 통신량·빈도와 노드 경계 위험이 는다. "TP를 더 키우면 항상 빨라진다"는 거짓이다. 통신이 연산을 압도하는 지점을 넘으면 오히려 느려진다. 최적 TP degree는 모델·레이어 크기·인터커넥트에 의존하며 일반해가 없다(조건 의존).

⚠️ 경계 혼동 주의 — TP는 traffic(③)을 풀지 않는다 — TP는 요청 하나를 여러 device로 나누는 것이지, 요청 수를 늘리는 것이 아니다. 오히려 통신 오버헤드로 총 처리량(throughput)이 줄 수도 있다. traffic 한계는 복제(DP)·라우팅으로 푸는 것이다(04·09장). 01장의 "세 축을 섞지 말라"가 여기서 구체화된다.

reduce-scatter + all-gather — all-reduce의 다른 얼굴

구현에 따라 all-reduce 대신 reduce-scatter(부분합을 나눠 각자 조각만 축약해 가짐)와 all-gather(각자의 조각을 모아 전원이 전체를 가짐)의 조합을 쓰기도 한다. 통신 총량과 메모리 사용의 절충이 다르다. 세부는 구현·버전에 따라 다르므로 이 안내서는 "all-reduce가 대표 패턴이되, 등가 조합이 존재한다"까지만 못박고 상세는 구현 의존으로 둔다.

🔬 증거 읽기 — 어떤 시스템이 "TP로 latency를 N% 줄였다"고 하면 확인할 것: (a) TP degree 몇인가, (b) 통신이 노드 안(NVLink)인가 밖(IB)인가, (c) all-reduce 방식(순수 all-reduce vs reduce-scatter+all-gather)인가, (d) 어떤 모델·시퀀스 길이·배치인가. 이 조건들이 다르면 다른 배포의 "N%"와 직접 비교할 수 없다(15장). TP 개선 주장은 특히 인터커넥트 조건에 민감하다.

이 장에서 배운 것

텐서 병렬화(TP) 는 한 레이어 안의 가중치 행렬을 여러 device에 쪼개, 그 레이어의 행렬 곱을 나눠 계산한다. 레이어 사이가 아니라 레이어 안을 나눈다.
골격 표: TP에서 가중치는 shard, 레이어 입출력 활성값은 replicate, 이를 잇는 collective는 all-reduce(또는 reduce-scatter+all-gather 등가 조합).
전형 패턴은 column-parallel → row-parallel → all-reduce로, 레이어당 소수의 collective로 통신을 줄이도록 설계됐다.
TP는 capacity를 풀고, latency도 조건부로 낮추지만, 매 레이어 통신을 새로 만들고 노드 경계에 민감하다. 그래서 보통 NVLink 도메인 안에 가둔다.
TP는 traffic(요청 수)을 풀지 않는다. 그건 복제·라우팅의 몫이다(04·09장).

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

지지하지 않는 결론 — "TP degree를 키우면 언제나 더 빠르다"는 지지되지 않는다. 통신이 연산을 압도하면 역전된다. 순이득 여부는 인터커넥트·모델 조건에 달렸다.
unknown으로 남길 것 — 특정 모델·인터커넥트에서의 최적 TP degree와 레이어당 정확한 all-reduce 횟수는 구현·버전 의존이라 일반값을 못박지 않는다. 특정 배포의 실측 개선률은 그 조건 기록 없이는 unknown.

✍️ 확인 문제

TP에서 "가중치는 나뉘는데(shard) 레이어 출력은 모든 device가 같은 값을 갖는다(replicate)"가 어떻게 동시에 성립하는가? 둘을 잇는 collective의 이름과 역할로 설명하라.

(조건/분모 유형) 어떤 팀이 "TP degree 8로 latency를 30% 줄였다"고 한다. 이 주장을 다른 팀의 "TP degree 8로 20% 개선"과 나란히 순위 매기기 전에, 반드시 맞춰 확인해야 할 조건을 셋 이상 들어라. 특히 어떤 인터커넥트 조건이 결과를 뒤집을 수 있는가?

동료가 "요청이 몰려 큐가 밀리니 TP degree를 키우자"고 제안한다. 이 제안이 01장의 어떤 축 혼동인지 지적하고, 올바른 방향(어떤 전략)을 제시하라.

다음 장에서는 나머지 병렬화 축 — 파이프라인·데이터·시퀀스·컨텍스트 — 을 같은 골격 표(나눔/복제/통신)로 나란히 정리한다. 각 축이 무엇을 나누고 어떤 통신을 요구하는지가 서로 어떻게 다른지가 초점이다.
다음 → 04. Pipeline·data·sequence·context parallelism — 여러 축을 한 표에서 비교하기

← 이전02. PCIe, NVLink, InfiniBand, Ethernet — 무엇이 무엇과 어떻게 연결되는가다음 →04. Pipeline·data·sequence·context parallelism — 여러 축을 한 표에서 비교하기