orangingq

NVIDIA GPUDirect Async (IBGDA)

오렌징큐 — Thu, 4 Jun 2026 18:31:52 +0900

참고자료: Improving Network Performance of HPC Systems Using NVIDIA Magnum IO NVSHMEM and GPUDirect Async | NVIDIA Technical Blog

What is IBGDA?

GPU Node 간 통신할 때, GPU가 CPU를 시켜서 네트워크 통신하는 게 아니라,
GPU가 직접 NIC(InfiniBand 카드)한테 일을 시키는 기술.

예전 구조: `GPU → CPU Proxy Thread → InfiniBand NIC → 목적지 GPU`

Fig 1. CPU를 거쳐가야 했던 이전 전송 구조.

GPU가 다른 노드의 GPU로 데이터를 보내고 싶을 때, GPU가 CPU한테 먼저 요청을 해서, CPU가 NIC(Netword Interface Card)에게 전달, 그러면 NIC이 데이터를 전송하는 순서였다.

통신 library NVSHMEM과 InfiniBand용 NIC (e.g., ConnectX-6 HCA)가 지원되는 환경 가정,

좀 더 자세한 기존 순서 설명:

application이 GPU memory에 data 생성하는 CUDA kernel launch. (Fig 1. ①)
application이 통신을 위해 NVSHMEM 연산 (e.g., `nvshmem_put`)을 호출.
NVSHMEM 연산이 host memory (RAM)에 있는 proxy buffer로 work descriptor를 write. (②)
NVSHMEM proxy thread가 work descriptor 감지하고 network 연산 개시. (③)
proxy thread가 work descriptor를 만들고 host memory에 있는 work queue (WQ) 버퍼에 enqueue. (④)
- work descriptor: RDMA write 같은 요청한 연산들, source/dest 주소, 데이터 크기 등등 network 관련 정보 명시.
CPU가 host mem에 있는 doorbell record (DBR) 버퍼를 update. (⑤)
- DBR buffer: NIC이 doorbell (DB)에 write하는 걸 drop하는 불상사를 대처하기 위한 recovery path 때 사용.
CPU가 NIC의 DB 레지스터에 write하면 (doorbell "띵동~"), NIC에서 읽음 ("예 누구세요"). (⑥)
그러면 NIC이 WQ buffer에서 work descriptor를 읽고 (⑦)
GPUDirect RDMA를 통해 GPU mem에 있는 data를 copy해서 (⑧)
목적지 node로 data를 전송한다. (⑨)
전송 완료했다는걸 CPU한테 알리기 위해서, NIC이 host memory의 completion queue (CQ) buffer에 event를 write. (⑩)
CPU는 그러면 CQ buffer에서 polling 해가지고 NIC이 전송 완료했음을 감지, 그리고 GPU한테 그걸 알림. (GPU mem에 바로 notification flag를 쓰기도 하고 proxy buffer 통해서 알리기도 함.)

-) CPU가 bottleneck이 된다. 요즘 H100 같은 GPU는 엄청난 속도로 연산한다. 게다가 MoE 연산 같은 경우 연산량 자체는 적은 반면 전송량이 작게 많다 (작은 데이터 패킷을 많이!! 발생시킨다). 그러면 CPU proxy thread는 그 많은 요청을 매번 하나하나 처리한다.

최신 NIC는 초당 수억 건의 통신 요청을 처리할 수 있고, GPU 역시 이 정도 속도로 요청을 생성할 수 있다. 반면, CPU 프록시의 처리 속도는 그보다 수 자릿수(orders of magnitude, $10^N$ 배) 낮기 때문에 세밀한(fine-grain) 통신 패턴에서 병목이 발생한다.

GPU : 야 빨리 보내

CPU : 잠깐만...
CPU : 이것도 처리해야 하고...
CPU : 이것도...
CPU : 이것도...

=> 그래서 낸 생각:

"아니 CPU 거쳐가려니까 너무 느린데, GPU가 직접 NIC를 건드리면 안 되나?"

그 결과가 GPUDirect Async다. 그리고 이를 InfiniBand에 적용한 것이 IBGDA다.

이제 CPU를 거치지 않고 바로: ` GPU → InfiniBand NIC → 목적지 GPU` 이렇게 데이터가 바로 전송된다.

Fig 2. IBGDA의 데이터 전송 구조.

자세히 말하면, GPU가 직접

Work Queue 작성
Doorbell 업데이트
RDMA 요청 생성

을 수행한다.

더 자세히 말하면 (Fig 2 참고):

① 애플리케이션이 CUDA 커널을 실행하고, 이 커널이 GPU 메모리에 데이터를 생성한다.

② 애플리케이션이 통신하기 위해 NVSHMEM 연산(예: nvshmem_put)을 호출한다.

② NVSHMEM 연산은 GPU의 SM을 사용하여 NIC용 Work Descriptor를 생성한 뒤 이를 Work Queue(WQ) 버퍼에 직접 기록한다. CPU Proxy 방식과 달리, 이 WQ 버퍼는 CPU 메모리가 아닌 GPU 메모리에 위치한다.

③ SM은 GPU 메모리에 위치한 Doorbell Record(DBR) 버퍼를 업데이트한다.

④ 이어서 SM은 NIC의 Doorbell(DB) 레지스터에 값을 기록하여 NIC에 새로운 작업이 등록되었음을 알린다.

⑤ NIC는 GPUDirect RDMA를 사용하여 GPU 메모리에 있는 WQ 버퍼로부터 Work Descriptor를 읽어온다.

⑥ NIC는 GPUDirect RDMA를 사용하여 GPU 메모리에 저장된 실제 데이터도 직접 읽어온다.

⑦ NIC는 해당 데이터를 목적지 노드로 전송한다.

⑧ 네트워크 작업이 완료되면 NIC는 GPUDirect RDMA를 사용하여 Completion Queue(CQ) 버퍼에 완료 정보를 기록함으로써 GPU에 작업 완료를 알린다.

=> 이로써 CPU 도움 없이 깔끔하게 전송!!

NVIDIA가 공개한 자료에서는 작은 메시지 전송 시, 최대 약 9.5배 높은 처리량(throughput)과 더 낮고 안정적인 지연시간(latency)을 보여준다. 특히 1KB 이하의 작은 메시지에서 효과가 크다.

Context Parallelism v.s. Sequence Parallelism (Megatron-LM 기준)

오렌징큐 — Wed, 27 May 2026 20:28:07 +0900

참고 코드: https://github.com/nvidia/megatron-lm

GitHub - NVIDIA/Megatron-LM: Ongoing research training transformer models at scale

Ongoing research training transformer models at scale - NVIDIA/Megatron-LM

github.com

참고 글: Introducing Context Parallelism · Better Tomorrow with Computer Science - https://insujang.github.io/2024-09-20/introducing-context-parallelism/

Sequence Parallelism (SP)

기준 논문 [MLSys'23]: REDUCING ACTIVATION RECOMPUTATION IN LARGE TRANSFORMER MODELS

SP(Sequence Parallelism) 는 Megatron-LM 기준으로 TP에 붙어서 동작하는 보조 기법에 가깝다. TP에서는 linear layer의 output이 hidden dimension 기준으로 all-reduce 이후 TP rank마다 동일한 activation이 생긴다. 그러면 LayerNorm, Dropout처럼 TP가 직접 적용되지 않는 구간 (i.e., weight가 hidden dim으로 나뉘지 않는 구간)에서는 rank마다 연산이 불필요하게 중복된다. 중복 연산으로 인한 연산량 자체는 뭐 크지 않더라도, activation 저장을 할 때 중복 저장하는 memory overhead를 줄이고 싶은 것이다.

따라서 SP는 activation을 sequence dimension으로 다시 나누어, TP rank들이 동일한 activation을 중복 저장하지 않도록 한다. 즉, SP는 주로 TP 내부에서 이미 존재하던 통신 패턴을 all-reduce 대신 reduce-scatter + all-gather 형태로 재구성하는 방식이다. all-reduce = reduce-scatter + all-gather로 볼 수 있기 때문에, 통신량 자체는 크게 늘지 않으면서 activation memory를 줄일 수 있다. 이 때문에 SP는 보통 추가 computation/communication overhead가 거의 없고, 시간 overhead도 작다고 볼 수 있다.

Context Parallelism (CP)

Megatron-LM / Megatron-Core 기준으로, Context Parallelism(CP)은 긴 sequence를 여러 GPU에 나누어 저장하고 계산하기 위한 parallelism이다. 즉, batch나 hidden dimension이 아니라 sequence length / context dimension을 shard한다.

`context_parallel_size` > 1일 때 켜지고, 기본값은 1이라서 CP가 꺼진 상태다. Megatron-Core 문서 기준으로 CP는 TP, PP, DP와 함께 조합 가능하며, 전체 GPU 수(`world_size`)는 기본적으로 TP × CP × PP × DP 구조로 잡힌다. `DP x CP` 수만큼 model weight가 replicate되고, `TP x PP` 수만큼 model weight shard된다. 각 `DP` rank의 model replica에 대해서 서로 다른 data batch가 들어오고, 그 안에서 `CP` rank만큼 이 batch가 sequence length가 잘라진다.

context_parallel_size > 1 일 때 CP가 켜지고, 기본값은 1이므로 기본적으로는 CP가 꺼져 있다. CP는 TP, PP, DP와 함께 조합 가능하며, 전체 GPU 수는 보통 다음과 같이 구성된다.

$$ \text{world\_size} = TP \times CP \times PP \times DP

CP는 weight를 shard하지 않는다. Sequence activation만 나누기 때문에, 같은 CP group 안의 GPU들은 model weight를 복제해서 가진다. Megatron-LM 코드 주석에서도 CP는 sequence length를 partition하므로 weight에는 영향을 주지 않고, CP group 내에서는 weight가 duplicated된다고 설명한다.

4D parallelism (출처: Scaling Llama 3 Training with Efficient Parallelism Strategies - https://dl.acm.org/doi/epdf/10.1145/3695053.3731410)

따라서 직관적으로는 다음과 같이 볼 수 있다.

TP × PP 방향으로는 model weight가 shard된다.
DP × CP 방향으로는 model weight가 replicate된다.
각 DP rank에는 서로 다른 data batch가 들어간다.
그 batch 안에서 CP rank들이 sequence length를 나누어 가진다.

핵심 목적은 long-context training에서 activation memory를 줄이는 것이다. Sequence length가 길어질수록 transformer activation memory가 커지기 때문에 (기본 attention일 경우 $O(L^2)$) OOM이 발생하기 쉽다. 물론 activation recomputation을 쓰면 activation을 저장하지 않고 backward 때 다시 계산해주기 때문에 메모리 용량이 줄지만, 그러면 사실상 forward pass를 한번씩 더 돌아야 하는거라 forward-backward 연산 시간이 약 1.33배 (forward:backward time=1:2) 증가한다. CP는 각 GPU가 전체 sequence가 아니라 자기에게 할당된 sequence chunk만 저장/처리하게 해서 per-GPU activation memory를 CP size에 비례해 줄인다.

구현 특이점: Symmetric chunk assignment

좌: 기본 naive partitioning / 우: megatron의 head-tail partitioning. (출처: USP - https://arxiv.org/abs/2405.07719)

Megatron-LM의 CP는 sequence를 단순히 앞에서부터 `cp_size`개로 균등하게 자르지 않는다. 특히 causal attention에서는 attention의 유효 영역이 lower triangular 형태이므로, causal mask를 실제로 활용해 불필요한 upper-triangle 계산을 생략하는 attention kernel (e.g., FlashAttention)에서는 뒤쪽 query chunk일수록 attend해야 하는 key/value 범위가 길어지고 연산량이 커진다. 즉, 같은 길이의 chunk라도 앞쪽 chunk는 연산량이 작고, 뒤쪽 chunk는 연산량이 크다. 따라서 sequence를 contiguous하게 나누면 뒤쪽 chunk를 맡은 rank에 load가 몰리는 imbalance가 생긴다.

이를 완화하기 위해 Megatron-LM은 sequence를 먼저 `2 × cp_size`개 chunk로 나눈 뒤, 앞쪽 chunk와 뒤쪽 chunk를 하나의 CP rank에 pair로 배정한다. 예를 들어 cp_size = 4라면 sequence를 8개 chunk로 나누고, 각 rank는 다음과 같이 두 chunk를 가진다.

rank 0: chunk 0 + chunk 7
rank 1: chunk 1 + chunk 6
rank 2: chunk 2 + chunk 5
rank 3: chunk 3 + chunk 4

이 구조 때문에 실제 indexing도 일반적인 slicing과 다르다. 각 CP rank의 local sequence는 원래 sequence에서 연속된 한 구간이 아니므로, attention input, position id, attention mask, packed sequence metadata가 모두 이 앞/뒤 pairing 구조를 따라야 한다. 특히 RoPE는 token의 position 정보를 사용하므로, local rank 안에서 position을 단순히 0, 1, 2, ...로 다시 매기면 안 된다. 예를 들어 rank 0이 chunk 0 + chunk 7을 들고 있다면, RoPE position도 chunk 0의 global positions와 chunk 7의 global positions를 함께 가져와야 한다.

또한 이 방식에서는 sequence를 `cp_size`개 chunk가 아닌 `2 × cp_size`개 chunk로 균등하게 나눌 수 있어야 하므로, sequence length가 `2 × cp_size`의 배수가 되도록 padding을 맞춰야 한다. 그렇지 않으면 rank별 chunk 크기나 앞/뒤 pairing index가 맞지 않아 CP layout이 깨질 수 있다.

CP vs SP

SP는 TP에 합쳐져 있다고 보면 되고, RS/AG 와 AG/RS 사이 Dropout, LN 부분이 SP가 활성화되는 구간이라고 보면 된다. 저 Ring Attention 부분이 CP로 인한 통신 overhead. (출처: https://docs.nvidia.com/megatron-core/developer-guide/0.16.0/user-guide/features/context_parallel.html)

공통점

둘 다 sequence length를 sharding한다.
activation memory가 병목이 되는 long-context training 상황에서 sequence 축으로 activation을 shard해서 per-GPU memory 사용량을 줄이는 것을 목표로 한다.
둘 다 보통 TP/DP/PP와 함께 조합되는 보조 parallelism으로 쓰인다. 특히 Megatron-LM 계열에서는 TP, PP, DP 위에 SP 또는 CP를 추가해서 메모리 병목을 완화한다.

차이점

적용 범위:

SP: 주로 LayerNorm, Dropout 등 TP가 적용되지 않는 일부 activation을 sequence dimension으로 shard.
CP: input batch와 대부분의 activation 전체를 sequence dimension으로 partition.

Communication 방식:

SP: TP와 SP 사이 boundary에서 reduce-scatter (hidden dim 축 shard를 reduce - sequence dim 축 shard로 scatter) / all-gather. (근데 사실상 identity/all-reduce -> reduce-scatter/all-gather 라서 통신량 자체는 같다.)
CP: attention 연산 때 K, V head를 ring-style P2P 방식 (또는 all-gather도 가능)으로 통신 & 연산. 통신량이 $O(LH_{kv})$ ($H_{kv}$: kv chunk의 head 수)만큼 증가. 통신 지연 시간을 고려하면 순수

Memory 이점:

SP: TP에서 중복되는 activation memory 감소. LayerNorm 전에 TP에서 all-reduce를 하고 나면 LayerNorm에서는 모든 TP rank들이 동일한 activation 값을 가지게 되는데 굳이 이렇게 중복 값을 가져서 쓸데없는 메모리 소모를 해야 할까? -> 이 때 바로 sequence 축으로 sharding을 해줌으로써 per-GPU activation memory를 늘 $1/TP$만큼으로 유지.
CP: sequence 축이 있는 모든 input, activation에 대해 $1/CP$만큼으로 감소시킴.

Deep EP

오렌징큐 — Fri, 24 Apr 2026 00:28:27 +0900

참고 사이트:

참고논문 : UCCL-EP - https://arxiv.org/pdf/2512.19849

MoE 상황에서 더 빠른 Expert Parallelism를 위한 Communication Library.

MoE 장인 DeepSeek AI에서, NVLink 및 GPUDirect RDMA를 통한 저지연 통신을 활용해 MoE & Expert Parallelism 전용 Comm. Library를 만들었다. MoE의 dispatch / combine 연산의 all-to-all 통신을 최적화해주는 고성능 GPU kernel을 제공하고, FP8 연산이나 heterogeneous domain (e.g., NVLink domain vs InfiniBand domain) 간 통신도 지원한다.

MoE Forward Pass in Expert Parallelism

DeepEP가 필요해진 문제 상황을 이해하려면, MoE가 어떻게 진행되는지, ragged 방식과 padding/drop 방식의 차이에 대한 이해부터 필요하다.

예를 들어 Expert가 128개, 그 중에 active experts가 4개인 MoE 구조 (아래 GPT-OSS 120B 구조)를 EP=8로 분산학습 한다고 생각해보자. 그러면 한 GPU에는 experts가 128/8=16개씩 올라간다.

처음에 한 batch로 들어온 input batch (batch size $B$ x token length $N$ x hidden dim size $H$)가 먼저 Attention block을 통과하고 residual connection을 거쳐서 MoE block에 도달한다.

GPT-OSS 모델 구조

그러면 MoE layer의 첫 단추, Router에서는 이 input batch를 token-wise하게 바라보고 (dim flatten: $ B \times N \times H \rightarrow BN \times H$ ), 각 token마다 어느 expert로 보내야 할지를 결정한다.

1) Router

즉 Router는 $BN \times H$ 를 input으로 받아서 gate weight score가 가장 큰 top-$k$ experts의 index와 score을 반환한다 (index와 score 둘다 $BN \times k$ 크기). 여기서 $k$는 활성화되는 experts 수, 즉 우리 상황에서는 $k$=4가 되겠다.

2) Dispatch

그러면 이제 어떤 experts로 보내야 할지 알았으니, 진짜 보내야 한다.

요즘 기본으로 쓰는 통신 방식은 (Dropless) Ragged tensor / Concat 방식이다.

Expert 별 router에 의해 할당된 token 수가 다 다를텐데, 이걸 굳이 똑같게 맞추려 하지 말고 variable size로 (GPU i가 Expert j에게 보내는 token 수 x H)만큼씩 All2All 통신을 한다.

통신 후 각 GPU의 각 expert는 tokens_per_expert x $H$ 만큼의 input을 가지게 된다.

Drop/Padding 방식

$BN \times H$ 였던 dimension shape을 expert 기준으로 $E \times C \time H$ 로 재배열한다 (group-by expert):

$E$: 총 expert 수. 이 사례에서는 $E=128$.
$C$: 각 expert가 품을 수 있는 최대 token 수 (capacity).
$H$: hidden dimension.

그러니까 각 expert에게 배정된 token들을 줄 세워서 $C$ 만큼 자르고 남은 token들은 drop. 만약에 배정된 token 수가 $C$보다 작은 expert 행의 경우에는 $C$ dimension에 맞게 padding 처리한다.

그러면 이제 i-번째 row $C\times H$를 expert i에게 발송 (dispatch)한다.

이때 모든 GPU에서 $ECH$ 크기의 padding처리된 sparse한 input을 발송하고, 각 GPU에 experts가 16개씩 있다고 했으니까, sparse All-to-All 통신을 하게 된다.

통신 후 각 GPU는 자기가 맡은 experts 수 ($E_{local}$. 이 사례에서는 $E_{local}=16$)만큼의 input을 받기 때문에 $E_{local}\times C \times H$ 만큼의 input을 가지고, 각 expert는 $C \times H$만큼의 input을 가진다.

Megatron-LM 코드 기준, 기본값은 Ragged (dropless) 방식이다. Drop/Padding은 `--moe-expert-capacity-factor` 설정 시 활성화되고, capacity 초과 토큰은 probs 또는 position 정책으로 drop된다.

항목	Ragged (Dropless) 방식	Padding (Capacity-based) 방식
기본 아이디어	expert별 token 수를 그대로 유지 (variable length)	모든 expert 입력을 동일한 크기(C)로 맞춤
데이터 형태	variable-sized tensor (ragged)	fixed-sized dense tensor
통신 방식	각 expert별 서로 다른 크기로 All-to-All	동일 크기 기준으로 All-to-All
추가 정보	offset / index 등의 metadata 필요	metadata 거의 불필요
메모리 효율	+) 높음 (불필요한 padding 없음)	낮음 (padding으로 낭비 발생)
compute 효율	+) 높음 (실제 token만 연산)	낮음 (padding까지 연산)
load imbalance 대응	token drop 없고, throughput이 줄어듦.	capacity 초과 시 token drop.
throughput	workload에 따라 다름 (irregularity 영향)	+) 안정적 (uniform workload)
사용 사례	training (특히 최신 MoE 모델)	inference 환경

그리고 각 expert는 자기에게 할당된 input에 대해 FFN 연산을 수행한다.

MoE 모델 (EP)의 통신 패턴

3) Combine

top-k routing (우리 상황: $k$=4) 기준으로 보면, 각 토큰은 expert E1, E2, E3, E4에게 할당되어 각 $H$ 길이만큼의 FFN output을 얻은 상황이다. 이제 이 experts 연산 결과를 다시 합쳐야 (combine) 한다.

dispatch 때와 정반대로 reverse all-to-all 통신으로 combine.

각 token이 expert 4개로부터 얻은 결과를 weighted sum으로 합쳐 하나의 output을 가지게 된다.

Problem

그런데 위 상황의 dropless ragged 방식은 전통적인 NCCL All-to-All에 잘 맞지 않는다.

전통적인 CC (collective comm.)는 각 GPU가 미리 정해진 크기의 buffer를 모든 GPU와 교환하는 구조인데, 따라서 보내기 전에 각 peer 간에 보낼 data 크기를 미리 알고 있어야 하고, data shape이 가능하면 균일해야 한다.

NCCL All-to-All을 사용한 기존 MoE 방식: CPU가 껴있어서 GPU stream 내에서도 유휴시간이 발생하고, Dispatch - Comp. - Combine이 순차적으로 발생.

그런데 dropless ragged 방식은 expert마다 할당되는 token 수가 dynamic하게 결정되니까 data 크기가 그때그때 매번 다르고 균일하지도 않다 (fragmented GPU-GPU transfer). 그럼 어떡하냐?:

균일한 조각 단위(tensor)으로 잘게 쪼개서 여러 번 통신하기
- -) 이러면 NIC의 WQE (work queue entry)가 폭증...! -> latency + overhead 증가.
expert 별로, token input들을 하나의 contiguous buffer로 packing해서 보내기
- -) 통신 latency 자체는 효율적이나, packing/unpacking하는데 overhead 생김.
Dropless Ragged 방식 포기하고 Padding/Drop 방식 택하기
- -) 위 더보기란에서 표로 정리했듯, padding/drop 방식은 padding으로 인한 추가 overhead와 drop으로 인한 학습 불안정성이 발생한다.

아무튼, 이러나 저러나 비효율적이다. 그래서 이 old NCCL All-to-All 대신 MoE ragged 방식에 찰떡으로 맞는 communication library가 없을까? 해서 나온 게 바로바로~~~ DeepEP (딥 이피 라고 읽음..ㅎ)이다!

DeepEP: GPU-initiated Token-level Communication

GPU thread가 host OS를 거치지 않고 NVIDIA IBGDA (InfiniBand GPUDirect Async) & NVSHMEM (NVIDIA Shared Memory)를 활용해서 NIC한테 direct하게 transfer command를 날린다 (submit한다).

DeepEP는 inference decoding용 low-latency mode와 training용 high-throughput mode 두 가지 모드를 제공한다.

low-latency mode에서는 IBGDA + NVSHMEM을 활용.

High-throughput mode에서는 CPU-initiated RDMA를 활용.

DeepEP를 통해 훨씬 빨라진 MoE 연산 & 통신.

GPU-initiated RDMA (IBGDA)
- 기존 EP 방식: CPU → NIC에게 send/recv 요청, GPU는 메모리만 제공
- DeepEP 방식: GPU thread (SM)가 직접 NIC에게 요청, CPU 개입 없음
  - NVIDIA GPUDirect Async (IBGDA) 기술을 통해 GPU kernel 내부에서 통신을 직접 실행한다.
  - +) 빠름.
Token-level Communication Kernel
- 기존 EP 방식: large batched All-to-All
- DeepEP 방식: token-level fine-grained transfer.
  - token 단위로 send/recv. => dynamic routing 그대로 반영 가능,
  - +) packing/unpacking 비용 제거 => latency $\downarrow$, throughput $\uparrow$
  - 참고) latency=output 한 번 내는데 걸리는 시간 / throughput=단위 시간에 몇 개의 output을 내는지. 한번 output 내는데 소요되는 end-to-end time은 길지만 병렬처리가 뛰어난 경우에는 latency가 높고 throughput도 높다.
Asynchronous & Overlap Execution
- 기존 EP 방식 (Drop/Padding): 모든 token이 한꺼번에 도착 후, 한번에 FFN 실행.
- DeepEP 방식: 일부 token이 도착하면 전체가 sync되기를 기다리지 않고 streaming 방식으로 바로 FFN 실행.
  - HOW? comm. kernel이랑 computation kernel이랑 섞지 않고, GPU SM 일부를 아예 communication kernel에 할당.
  - hook-based comm.-computation overlapping method
  - +) training / inference workload에 맞게 이 kernel 할당 비율을 tuning 가능. (SM Resource Control)
- +) expert load imbalance 문제로 인해서 slow expert가 전체를 기다리게 하는 문제를 완화해줌. 기존 synchronous 방식은 barrier를 걸어서, 모든 expert가 자기 token을 받을 때까지 기다렸다가 다같이 FFN compute를 시작하고, 모든 experts가 FFN compute를 끝나야만 combine A2A 통신을 진행한다. 반면 이 streaming 방식은 먼저 token 받으면 먼저 compute 시작할 수 있고, FFN 끝난 token은 바로 async하게 combine 전송할 수 있다.
  - => +) 빨라짐.

한 마디로 정리하면, DeepEP 덕분에 같은 MoE 연산에 대해 더 빠른 처리가 가능해졌다.

기존 NCCL에서는 `총 시간 = Dispatch Comm. + FFN Compute + Combine Comm.` 으로 걸렸다면, DeepEP에서는 Comm kernel과 Compute kernel을 따로 구분하니까, 대강.. `총 시간 = max(Dispatch+Combine Comm., FFN Compute)` 으로 걸린다고 보면 됨.

Distributed Optimizer ↔ FSDP 차이 (Megatron 코드 기준)

오렌징큐 — Wed, 15 Apr 2026 18:03:50 +0900

참고자료:

FSDP (Stage 1,2,3)

일단 FSDP (fully-sharded DP=Stage 3)를 적용했을 때의 학습 Flow는 다음과 같다:

* 정의 상으로 FSDP는 DeepSpeed ZeRO Stage 3과 같은데, Megatron FSDP는 Stage 1 (optimizer state만 sharding), stage 2 (optim state + grad sharding)도 지원한다. 일단 Stage 3 기준으로 설명한다.

FSDP degree=d, param 수=N, param dtype=bf16, Adam optimizer 가정.

FSDP (Stage 3) 적용했을 때의 학습 flow

0. 처음에 각 dp rank 별로 model param shard (N/d x fp16 -> 2N/d Byte), optim state shard (2N/d x fp32 -> 8N/d Byte), main param shard (N/d x fp32 -> 4N/d Byte) 가지고 있음.

기본적으로 알아야 하는 Model State Memory & Residual State Memory 종류. 근데 물론 구현마다 조금씩은 다르다. 예를 들어 megatron에서 gradients (FP16) 메모리는 parameter update할 때 잠깐 만들었다가 다시 free 시켜서 사실 steady state로 존재하지 않는다.

각 dp rank의 model param shard를 all-gather 통해 full param으로 모은다. (param: 2N/d -> 2N)
- stage 1, 2에서는 param sharding을 하지 않긴 하지만, optimizer update를 자기 param shard에 대해서만 하기 때문에 sync를 맞춰주고자 all-gather를 해줘야 한다.
[Forward] full param 가지고 각 dp rank에서 local하게 forward 진행.
backward 전까지 full param 필요 없으니까 free. (param: 2N -> 2N/d)
- stage 1, 2에서는 param sharding을 하지 않으니 이 부분 생략.
backward 전에, all-gather 통해 다시 full param 모은다. (param: 2N/d -> 2N)
- stage 1, 2에서는 param sharding을 하지 않으니 이 부분 생략.
[Backward] full param 가지고 각 dp rank의 data shard에 대한 backward prop. (local하게 독립적으로 수행. gradient 4N Byte 생성.)
각 dp rank의 gradient를 reduce-scatter 통해서 sync 해준다. (param 2N, grad 4N -> param 2N, grad 4N/d)
- stage 1에서는 gradient sharding을 하지 않으니 reduce-scatter 대신 all-reduce. (-> param 2N, grad 4N)
이제 full param도 자기 shard 빼고는 free. (param 2N, grad 4N/d -> param 2N/d, grad 4N/d)
- stage 1, 2에서는 param sharding을 하지 않으니 이 부분 생략. (stage 1: param 2N, grad 4N / stage 2: param 2N, grad 4N/d)
..이걸 microbatch별로, grad_accum_step 만큼 또 반복을 해주다가. optimizer update 때가 되면??
[Optimizer] 각 dp rank에서 local하게 자기 param shard에 대해서만 optim update.
- stage 1, 2에서도 마찬가지로, 자기 shard에 대해서만 update. 왜냐면 optimizer state가 sharding되어 있어서 전체 update가 불가.

Distributed Optimizer

Distributed Optimizer data flow

Distributed Optimizer는 ZeRO-1 (stage 1)와 관점이 조금 다를 뿐, 구현 자체는 굉장히 비슷하다.

유일한 다른 점은,

Distributed Optimizer은: throughput 향상과 일관된 parameter state 지향 -> eager sync -> optimizer update 직후에 parameter를 sync (=allgather).

반면 ZeRO Series는: memory consumption 최소화 목적 -> lazy on-demand sync -> forward 직전에 필요한 시점에 parameter sync.

lazy sync를 한다는 건, optim update 후 param sync 전까지동안, full parameter를 가지고는 있으나 사실상 유효한 (updated) parameter는 해당 dp shard의 parameter 뿐이라는 것이다. 반면 eager sync는 optimizer update 직후에 바로 sync해버리니까 늘 parameter가 synchronized 되어 있다.

Q. Megatron에서 왜 lazy sync 대신 eager sync를 선택했는가?

Megatron은 TP/PP와의 hybrid parallelism을 고려해서, 구현의 용이성을 위해 parameter의 consistency를 유지하고 싶었을 것이다.
미리 sync를 시작하면 comm. overlap 기능을 통해 좀 더 여유롭게(?) parameter bucket들을 sync할 수 있으니까 throughput 측면에서도 이득일 것이다.

Q. 헷갈리는 점은, Megatron FSDP는 stage 1, 2, 3을 모두 지원하는데, distributed optimizer도 같이 써야 한다는 점이다.

DO가 ZeRO-2랑 비슷하다고 했는데, 그러면 Megatron FSDP stage 1/2/3이랑 DO랑 같이 옵션을 켜면 어떻게 되는겨?
A. 구현 상에서, 그러면 Megatron FSDP를 먼저 따라간다. sharding 정책의 주도권은 Megatron-FSDP에 있고, Distributed Optimizer는 optimizer step / state / checkpoint 쪽 wrapper로 얹히는 형태.

예를 들어 `--use-distributed-optimizer --use-megatron-fsdp --data-parallel-sharding-strategy optim_grads_params` 이렇게 세 가지 옵션을 동시에 켰을 때, 그러니까 Distributed Optimizer도 쓰면서 Megatron-FSDP stage 3도 쓰면,

model grad (fp16/bf16) -> main grad (fp32) 복사: 건너뜀.
- `megatron/core/optimizer/distrib_optimizer.py > DistributedOptimizer class > _copy_model_grads_to_main_grads()`
main param (fp32) -> model param (fp16/bf16) 복사: FSDP buffer api 사용
- ` megatron/core/optimizer/distrib_optimizer.py > DistributedOptimizer class > _copy_main_params_to_model_params()`
optimizer step 후 param sync할 때: FSDP의 start_param_sync() 호출
- `megatron/core/optimizer/distrib_optimizer.py>DistributedOptimizer class>step_with_ready_grads()`

그리고 Distributed Optimizer 없이 Megatron-FSDP를 쓰는 것도 현재 지원되지 않는다.

https://docs.nvidia.com/megatron-core/developer-guide/latest/user-guide/features/custom_fsdp.html <- 여기에 "The custom FSDP must be used with a distributed optimizer since it provides distributed checkpointing." 라고 써 있다.

총정리

Memory Sharding State 비교

Column 설명:

DDP: Distributed Optimizer / Megatron-FSDP 없이 DDP만 사용.
D.O. only: Megatron-FSDP 없이 Distributed Optimizer만 사용.
FSDP Stage 1: `--use-distributed-optimizer` + `--use-megatron-fsdp` + `--parallel-sharding-strategy optim`
FSDP Stage 2: `--use-distributed-optimizer` + `--use-megatron-fsdp` + `--parallel-sharding-strategy optim_grads`
FSDP Stage 3: `--use-distributed-optimizer` + `--use-megatron-fsdp` + `--parallel-sharding-strategy optim_grdas_params`
Distributed Optimizer 없이 Megatron-FSDP만 쓰는 것은 현재 지원되지 않는다.

Row 설명:

optimizer state (fp32): Adam optimizer 계열 기준, 두 종류 (`exp_avg`, `exp_avg_sq`) 가 high-precision으로 저장됨.
- optimizer에 의해 저장/관리되는 steady-state memory. optimizer 계산용으로 저장되는 high-precision parameter 값.
main param (fp32): optimizer 계산용으로 저장되는 high-precision parameter 값.
main grad (fp32): optimizer step, grad norm, clipping, update에는 high-precision으로 쓰인다. (dtype custom 지정 가능)
model param (fp16/bf16): 매 forward 때 사용되는 model parameter 값.

Shard factor `d` 설명:

Non-MoE parameter의 shard factor: `d = WORLD_SIZE/(DPxCP)` (distributed optimizer state is sharded jointly over DP+CP.)
MoE expert parameter의 shard factor: `d = WORLD_SIZE/EDP`

항목	DDP	FSDP Stage 1	D.O. only	FSDP Stage 2	FSDP Stage 3
optimizer state (2N x 4Byte)	❌ full	✅ 1/d	✅ 1/d	✅ 1/d	✅ 1/d
main param (N x 4Byte)	❌ full	✅ 1/d	✅ 1/d	✅ 1/d	✅ 1/d
main grad (N x 4Byte)	❌ full	❌ full	❌ full	✅ 1/d	✅ 1/d
model param (N x 2Byte)	❌ full	❌ full	❌ full	❌ full	✅ 1/d
residual memory (e.g. activation, ...)	❌ full	❌ full	❌ full	❌ full	❌ full

Communication Overhead 비교

항목	DDP	FSDP Stage 1	FSDP Stage 2	Distributed Optimizer	FSDP Stage 3
Forward 전	None	Param (2N) AG	Param (2N) AG	None	Param (2N) AG
Forward 후	None	None	None	None	None
Backward 전	None	None	None	None	Param (2N) AG
Backward 후	Grad (2N) AR	Grad (2N) RS	Grad (2N) RS	Grad (2N) RS	Grad (2N) RS
Optim. Update	None	None	None	Param (2N) AG	None

* gradient 통신할 때의 dtype은 설정하기 나름이긴 한데, 기본값은 model param의 dtype을 따른다.

근데 여기서 AR = AG + RS 인 관계로, 사실상 통신량 자체는 DDP = FSDP Stage 1 = FSDP Stage 2 = Distributed Optimizer < FSDP Stage 3 로 볼 수 있다.

CUDA Multicast

오렌징큐 — Mon, 13 Apr 2026 12:03:50 +0900

CUDA multicast는 하나의 데이터를 여러 GPU에 동시에 전달해서 GPU 간 통신을 효율화하는 기술입니다.

구분	Unicast	Broadcast	Multicast
통신 방식	1 → 1	1 → 전체	1 → 특정 그룹
대상	한 개	모든 노드	선택된 여러 노드
효율성	낮음 (여러 번 전송 필요)	비효율적 (불필요한 대상 포함)	가장 효율적
네트워크 부담	높음	매우 높음	낮음
example	한 사람에게 전화 * GPU0 → GPU1	마이크로 모든 사람에게 방송 * GPU0 → 모든 GPU	특정 그룹방에만 메시지 전송 * GPU0 → GPU1, GPU3, GPU5

구현 방식

기본 NCCL ↔ CUDA 관계 구조

[사용자 코드]
↓
[NCCL (고수준 통신)]

* CUDA 기반으로, multi-GPU 통신 패턴 (broadcast, all-reduce, ...) 제공.

* 각 패턴 내부에서, hardware topology (NVLink/NVSwitch 여부, PCIe tree 구조, NUMA 등)를 보고, 어떤 알고리즘이 적합할지 (ring? tree? NVLS? ...), 그래서 data를 어떤 GPU ↔ GPU 경로로 보낼지 (direct? relay?) 결정 최적화.

↓
[CUDA (저수준 실행 + 메모리)]

* low-level에서 GPU 메모리 관리 / 커널 실행 / GPU ↔ GPU 데이터 복사
↓
[GPU HW (NVLink, PCIe, NVSwitch)]

Unicast

NCCL P2P Send/Recv:

여기서는 P2P 통신이기 때문에 ring/tree 같은 collective 알고리즘까지 고려하지는 않는다.

다만 hardware topology 고려해서 NVLink (또는 NVLink 없으면 PCIe P2P)로 direct GPU ↔ GPU transport할지 / 아니면 아예 P2P 불가능하다면 Host staging ( GPU ↔ CPU ↔ GPU) 할지 정도는 고려.

* `NCCL_P2P_DISABLE=1`: NVLink나 PCIe를 사용하는 direct GPU-to-GPU P2P transport를 끄는 옵션.

* `NCCL_P2P_LEVEL`:

// rank 0 -> rank 1
if (rank == 0) {
  ncclSend(sendbuf, count, ncclFloat, 1, comm, stream);
} else if (rank == 1) {
  ncclRecv(recvbuf, count, ncclFloat, 0, comm, stream);
}

NCCL 없이 CUDA만으로 P2P Copy 구현:

// GPU0 -> GPU1 로 1회 전송
cudaSetDevice(0);
float* src;
size_t bytes = N * sizeof(float);
cudaMalloc(&src, bytes);
// src 채우기 ...

cudaSetDevice(1);
float* dst;
cudaMalloc(&dst, bytes);

// device 0의 메모리를 device 1로 복사
cudaMemcpyPeerAsync(dst, 1, src, 0, bytes, stream1);

Broadcast

NCCL Broadcast:

NCCL이 ring/tree/NVLS 등 사용 가능한 알고리즘 중에서 topology에 맞춰 선택하므로, root 단일 병목이 줄고 전체 fabric을 더 잘 쓴다. 공식 문서상 기본값은 topology와 architecture에 따라 자동 선택.

// 모든 rank가 같은 collective 호출
ncclBroadcast(
    sendbuff,     // root에서만 의미 있음
    recvbuff,
    count,
    ncclFloat,
    /*root=*/0,
    comm,
    stream);

Multicast

Multicast는 Broadcast의 좀더 general한 개념. broadcast는 "모든" GPU에게 방송하는 방식인 반면, multicast는 "여러 몇몇" GPU에게 방송하는 방식.

NCCL에는 “사용자가 직접 `ncclMulticast(...)`를 호출하는 API”는 없다.

앱 코드에서는 여전히 `ncclBroadcast(...);` 또는 `ncclAllReduce(...);` 호출.

그런데 내부적으로 지원 환경이면 multicast/offload 성격의 hardware 경로를 사용할 수 있다.

대신 NCCL 문서에 따르면 알고리즘 선택 변수 `NCCL_ALGO`에 `NVLS`, `NVLSTree`가 있으며, 이들은 NVLink SHARP offload를 사용.

최고 성능 가능성: multicast-capable fabric일 때
하지만 조건이 까다로움: NVSwitch/NVLink SHARP 지원, 라이브러리/알고리즘 지원 필요
일반 PCIe-only 환경에서는 이런 이점이 없습니다

Q. NVLink SHARP?
A. GPU 간 통신 + 연산을 “네트워크(NVSwitch)” 안에서 처리하는 기술.
SHARP = Scalable Hierarchical Aggregation and Reduction Protocol. 네트워크 switch 안에서 reduce (sum, max 등) 연산을 수행하게 하는 기술이다. 원래는 노드 간 통신 때 쓰이는 InfiniBand에서 나온 기술임.

이걸 NVIDIA intra-node 환경(NVLink + NVSwitch)으로 끌고 와서, NVLink SHARP란, 이 SHARP 기술을 같은 노드 내 GPU 간 네트워크 (NVLink + NVSwitch)에 적용한 것이다. 따라서 NVSwitch가 단순히 네트워크 switch가 아니라 data 복제 + reduction 연산까지 수행할 수 있게 한다. (GPU ↔ NVSwitch ↔ GPU)

Ex) 기존 software 기반 allreduce는 GPU가 직접 연산을 하고 통신량이 많다:
GPU0 → GPU1 → GPU2 → GPU3 (데이터 이동 + 각 GPU에서 sum)

반면 NVLink SHARP는 각 GPU가 NVSwitch로 데이터를 보내면 NVSwitch가 연산하고 결과를 각 GPU에 분배한다:
NVSwitch
/ | \
GPU0 GPU1 GPU2 GPU3

즉, NVLink SHARP offload란 말은, 원래 GPU가 하던 연산을 NVSwitch한테 offloading한다는 뜻!

DGX A100 Hardware Topology

참고 사항) 아래 그림은 NVIDIA DGX A100 노드의 hardware topology이다. 하단부를 보면 GPU 8대가 각각 모두 6대의 NVSwitch에 NVLink로 연결되어 있고, NVSwitch가 중간다리 역할을 해주고 있다.

그리고 다른 DGX 노드에 data를 전송하기 위해서는:

GPU memory -> PCIe Bus -> PCIe Switch -> PCIe Bus -> NIC (InfiniBand HCA) 
    -> [InfiniBand Network: InfiniBand Cable -> InfiniBand Switch(es) -> InfiniBand Cable]
        -> Destination Node NIC -> ... -> Destination GPU memory

이렇게, NVSwitch 말고 PCIe Switch를 거쳐서 InfiniBand로 연결된다. (CPU도 안 거친다. a.k.a. GPU direct RDMA)

NVIDIA DGX A100 host (official 8-card machine) hardware topology 출처: https://www.naddod.com/blog/high-performance-gpu-server-hardware-topology-and-cluster-networking-2?srsltid=AfmBOooe4aSDdrvDSFdmrJDCWpPYn7Fr81pEGr6cTsLqH3s9gK1JiHkH

DISTMM: Accelerating Distributed Multimodal Model Training

오렌징큐 — Wed, 18 Mar 2026 13:52:44 +0900

논문 (NSDI'24) : DistMM - https://www.usenix.org/system/files/nsdi24-huang.pdf

Multimodal model을 분산학습시키는 상황.
이 상황에서 분산학습 시스템의 시간/연산 효율성을 개선하려면?

Summary

✨ 기존 분산 학습 시스템들은 이종적인(heterogeneous) 멀티모달 모델의 특성과 대규모 배치(large batch)를 요구하는 Contrastive Loss를 고려하지 않아 비효율적이었다.
️ DISTMM은 Modality-aware Partitioner, Data Load Balancer, Heterogeneity-aware Placement Manager를 통해 서브모듈의 이질성을 활용하고 통신 오버헤드를 줄이며, Pipeline Executor의 `batch-sync instruction` 및 DISTMM-Pipe 스케줄로 대규모 배치 요구사항을 충족한다.
다양한 구조와 규모(1.1B~26B 파라미터)의 CLIP, CoCa, LiT 모델 실험에서 DISTMM은 기존 Megatron-LM보다 1.32배에서 3.27배 빠른 학습 속도를 보였다.

Problem

Multimodal model의 submodules(모델 조각들)이 모델 구조로보나, input 크기로 보나 서로 이종적(heterogeneous)이다. -> -) 연산 비효율성을 초래한다.

기존 Multimodal Model의 특징:

Heterogeneous submodules: 각 modality마다 특징이나 구조가 다르고, 또 multimodal task가 어떤 modality를 주력으로 하는지에 따라서도 학습 구조가 달라짐. 그리고 이 modality의 구조적 이종성이 GPU utilization에도 영향을 미침.
- CLIP: Vision module (ViT) 크기 >> Text module 크기
- LiT: Vision module 크기 << Text module 크기
- CoCa (Contrastive captioner): Vision module 크기 $\approx$ Text module 크기
- -) 이 각 submodules을 동등하게 취급하면 sub-optimal한 시간 효율성을 가지게 됨.
Imbalanced input sizes: modality type에 따라 input size가 다름.
- e.g., CLIP: text input은 77 단어, image는 512x512 pixel 크기 제한.
Large batch size requirement: 기존 연구에 따르면 contrastive learning할 때 batch size 큰 게 더 성능 차원 (robust & generalized representation)이나 수렴 속도 차원에서 좋다.
- -) 여기에 pipeline parallelism을 적용하려면 최대 마이크로 배치 크기가 $(M-\frac{M_s}{P})/M_a$로 제한되어 batch size 키우기가 어렵다. ($M$: GPU total memory, $M_s$: static memory(weight, gradient, state), $M_a$: activation memory)

Multimodal Model Taxonomy:

항목	Dual Encoder	Dual-Stream Fusion	MLLM (LLM-based)
아키텍처 예시	- image → Enc →v - text → Enc →t => sim(v,t)	- image → Enc →v_tokens - text → Enc →t_tokens => cross-attn	- image→Enc→proj→LLM - text→LLM
구조 특징	완전 분리	encoder 분리 후 fusion	LLM 중심 구조
interaction 시점	없음	중간	LLM 내부
attention 구조	없음	cross-attention	causal self-attention
대표 모델	CLIP	BLIP, ALBEF	LLaVA, Qwen-VL
입력 형태	modality별 입력	tokenized separately	image→token + text
출력 형태	embedding	multimodal feature	text sequence
주요 목적	alignment	multimodal task	generation
loss function	contrastive	contrastive / ITM / LM	LM (cross entropy)
학습 방식	representation learning	hybrid learning	instruction tuning
장점	효율적	성능 균형	reasoning / generation
단점	interaction 없음	구조 복잡	매우 무거움

Method

⇒ 이 논문에서는 총 4가지 요소를 가지고 멀티모달 모델의 분산학습 시스템을 구성한다:

Modality-aware Partitioner: 전체 멀티모달 모델을 입력 모달리티(modality)에 기반하여 하위 모듈(submodules)로 분할한다. 각 하위 모듈의 신경망 아키텍처와 구성이 다르다는 점을 활용하여, 하위 모듈 크기에 따라 독립적인 병렬화 전략을 적용한다.
- e.g., 연산이 많은 submodule은 TP를 쓰고, 단일장치에 load 가능한 작은 크기의 submodule은 DP를 쓰도록.
- +) 각 모달 하위 모듈의 계산 지속 시간을 균형 있게 맞춰 전체적인 높은 계산 효율성을 달성.
Data Load Balancer: Modality-aware Partitioner에 의해 분할된 하위 모듈과 클러스터 구성을 입력으로 받아, 각 하위 모듈 파티션에 할당할 장치 수와 데이터 배치 크기를 결정한다. (Dynamic programming으로 최적화)
- +) 각 모달 하위 모듈의 계산 지속 시간을 균형 있게 맞춰 전체적인 높은 계산 효율성을 달성.
Heterogeneity-aware Placement Manager: 각 submodule의 locality (=어떤 submodule을 어떤 node의 어떤 GPU에 배치할지)를 최적화했다.
- 노드 내 NVLink와 노드 간 Ethernet의 bandwidth 차이를 고려.
- e.g., 동일 modality 내 submodules -> 서로 가깝게 배치하여 고대역폭 링크를 활용 / 다른 modality의 submodules -> 별도의 노드에 배치하여 저대역폭 링크에서의 통신량(communication volume)을 줄임.
- +) submodule 간 통신량을 고려하여 배치함으로써 통신량, 통신 시간 최적화.
Pipeline Executor: 기존의 pipeline execution schedule의 batch size 한계를 극복하고자 새로운 pipeline executor를 제안.

DistMM Overview

그림을 보면,

Modality-aware Partitioner가 image module (파랑)과 text module (노랑)을 각각 4등분, 16등분한다. 아마도 parameter size 같은 모델의 meta 정보 가지고 4와 16이라는 값을 결정한듯. 이 4등분/16등분 값은 다시 말해 TP degree x PP degree를 의미한다. (e.g., 파랑 모듈: TP degree x PP degree = 4가 되어야 함)
그 다음, Data Load Balancer가 전체 batch size (Gbs=72)에 맞춰서, DP degree와 각 DP group 별 batch size를 결정. 그래서 파랑 모듈은 4개의 replica가 필요하고 (dp degree=4, 각 replica 당 batchsize (Rbs)=18), 노랑 모듈은 3개의 replica가 필요하다 (dp degree=3, Rbs=24).
Heterogeneity-aware Placement Manager가 이제 마지막으로 실제로 GPU를 할당해주고, 이에 따라 TP degree와 PP degree도 결정된다. 이 예시에서는 전체 GPU cluster가 8개 GPU 짜리 node 8개인 상황에서, GPU 16개짜리 노랑 모듈 replica 3개와 GPU 4개짜리 파랑 모듈 replica 4개를 통신 효율적으로 배치해야 한다.
- 아무래도 DP replica들은 sync를 해줘야 하니까 replica들끼리는 TP degree / PP degree가 통일되는 게 연산 시간을 맞추는데 도움이 되겠지.
- 노랑이 먼저 생각해보면 TP deg x PP deg = 16이어야 하는데, TP가 통신량이 많이 heavy하니까 TP degree를 낮추고 TP group끼리는 같은 node에 배치해주어야 함. 그러면 TP deg = 2이거나 4 정도가 적당. 근데 TP deg =2인 경우는 PP deg=8이 되어 pipeline bubble 현상이 심화되는 문제도 발생할 수 있고, 파랑 모듈 replica들을 모두 서로 다른 node에 배치시켜야 해서 파랑 모듈의 DP grad sync 통신량도 상당해진다. 뭐 이러저러한 계산 결과로.. (실제 결정할 때는 이렇게 heuristic하게 결정하지는 않겠지. ~~아님 말고~~)
- 결과적으로 ... 최종 degree (DP deg, PP deg, TP deg)는 노랑 모듈: (3, 4, 4), 파랑 모듈: (4, 2, 2) 로 결정이 난다.
마지막, Pipeline Executor가 이 PP deg를 고려해서 interleaved 1f1b schedule을 만들었다. 이 때 각 GPU의 메모리 사정을 고려했을 때 microbatch size (Mbs)는 노랑 모듈이 3, 파랑 모듈이 2가 되고, 기존에 Rbs가 각각 18, 24이었으니까 microbatch 수는 각각 6, 12가 된다.
- 이 때 노랑 모듈과 파랑 모듈 feature vector를 짬뽕해서 similarity 계산하는 modality interactive module의 경우 언제 연산해주어야 하느냐? (이 모듈을 학습할 때는 노랑 pipeline과 파랑 pipeline 간 sync가 필요한 상황.) 얘는 모듈 간 통신이 필요하다보니까 매 microbatch마다 연산하지 않고, 그림에서 Interactive Computations로 적힌 빨간 선 부분에서 한번에 통합해서 연산함.

Modality-aware Partitioner

기존 분산학습 시스템에서는 submodule을 다 통합 고려해서 전체 모델 대상으로 모델을 split했다면, 이 Modality-aware Partitioner에서는 각 submodule을 독립적으로 고려해서 split한다.

즉, 이 단계에서는 GPU에다가 모델 쪼개는 방식을 최적화.

(a) 기존 Colocated solution 대비 (b) DistMM의 Modality-aware Partitioner

modality interactive submodule 같은 경우는 연산이 heavy하지 않고 통신량도 적기 때문에 각 device에 균등하게 나눠담는다.
그리고 각 modal module의 경우, efficiency를 최대화하는 방향으로 adaptive하게, 그리고 독립적으로 split해서 device에 나눠담는다.
- 이 때 parallelism strategy라던가 parallelism degree 같은 것들은 common practice를 따른다 (model size 고려해서 DP를 할 수도 있고 TP를 할 수도 있고 PP를 할 수도 있고).

Data Load Balancer

위에서 모델을 잘 쪼개줬다면, Data Load Balancer는 cluster setup(node 몇 개고 node 당 device 몇 개인지)과 training config(Modality-aware partitioner에 의해 쪼개진 model partition들 정보와 global batch size)를 input으로 받아서, 각 model partition이 몇 개의 device에 할당될지 (e.g., DP의 경우 여러 대 GPU에 model partition replica를 load해야 함)를 결정("resource assignment plan")한다.

목표는 가장 느린 model partition의 연산 시간을 최소화하는 것.

(a) 기존 Colocated solution 대비 (b) DistMM의 Data load balancer

Heterogeneity-aware Placement Manager

이제 각 model partition 별 GPU 수가 정해졌으니, 이를 바탕으로 Heterogeneity-aware Placement Manager에서는 bandwidth를 고려해 communication-efficient한 방식으로 실제 device에 배치해준다.

위에서 모델 어떻게 쪼개서 몇 개 GPU 쓰라고 결정했다면 여기서는 "그래서 어떤 GPU에 어떤 model partition을 배정할지"를 정하는 단계.

(a) 기존 Colocated solution 대비 (b) DistMM의 Heterogeneity-aware Placement

위 그림 예시를 보면, 원래 colocated solution에서는 파랑색 모달과 주황색 모달 모두 4개 GPU에 쪼갰다보니 4개 GPU가 다 통합적으로 gradient AllReduce를 해야 했는데, 이제는 파랑색 모달은 GPU 하나에 담겨서 allreduce가 필요 없어지고 주황색 모달은 3개 GPU끼리만 allreduce하면 돼서 확실히 comm. efficient해졌다.

Pipeline Executor

여기서 PP를 적용할 때 가장 포인트는, 학습에서 요구되는 batch size (Required batch size, Rbs)와 실제 GPU의 메모리가 감당할 수 있는 micro batch size (Mbs)의 격차를 고려하는 것이다.

K=Rbs/Mbs라고 할 때, DistMM-Pipe는 Mbs/2 크기의 2K개 microbatch로 쪼개서 ...???

Pipeline Executor는 실행 스케줄 명령하는 Batch-sync instruction 부분과

원래 PP에서는 각 stage에서 gradient까지Contrastive Learning할 때 similarity를 계산하는데, 이걸 위해서는 ...???

Batch-sync instruction은 총 4단계로 구성됨:

Memory movement: 이전 K개 microbatch의 forward 결과 feature vector를 continuous feature vector로 합치는 작업.
Forward pass of modal interactive submodule
Backward pass of modal interactive submodule: modality interactive submodule의 backward 실행 -> continuous feature vector에 대한 gradient 생성.
Memory dispatching: continuous gradients를 각 microbatch의 feature vector에 대한 개별적인 gradient (총 K개)로 분리하는 작업.

-) 근데 솔직히 .. pipeline executor 부분 이해 못했음. 그림에서 overhead reduction은 그냥 GPipe 쓸 거 1f1b 쓰고 microbatch 두 배로 쪼개서 줄어든 거 아니야? 이 논문의 novelty에 의한 감소는 아닌 거 같은데.. 그리고 논문에서 Mbs/2 크기의 2K개 microbatch로 나눴다는데, 왜 굳이 2야?

Strength

+) VLM의 모달리티 간 독립성을 고려한 분산 시스템 디자인이라는 점.

Weakness

-) 그리고 전반적으로 dual encoder (e.g., CLIP) 구조에 맞춰서 설계된 거 같다. 요즘 많이 쓰는 MLLM 구조랑은 잘 안 맞는 듯.

-) 그리고 transformer 구조들은 Sequence Parallelism도 많이 쓰는데 여기서는 고려가 안 되어 있다.

Sequence Parallelism: Long Sequence Training from System Perspective

오렌징큐 — Sun, 15 Mar 2026 00:18:13 +0900

논문 (ACL'23) : Sequence Parallelism: Long Sequence Training from System Perspective

(https://aclanthology.org/2023.acl-long.134.pdf)

Sequence Parallelism: Long Sequence Training from System Perspective

Transformer achieves promising results on various tasks. However, self-attention suffers from quadratic memory requirements with respect to the sequence length. Existing work focuses on reducing time and space complexity from an algorithm perspective. In t

arxiv.org

이 논문은 긴 context를 다루는 Transformer 모델에 대해 분산학습하는 상황을 가정한다.

#Long-Context #Transformer #Distributed_Learning

Problem

Transformer 모델에서 긴 context를 다루는 능력은 중요하고 많이 쓰이는데,

문제가 context size를 $ L $이라고 하면, 메모리 요구량이 $ L^2 $에 비례한다. 그래서 메모리의 한계로 인해 긴 context 학습이 어려운 상황이었다.

Q. 기존 분산학습 방법들을 가지고 해결할 수 없나?

A. 기존 분산학습은 주로 DP / PP / TP 방식이 있고, 이거도 방법은 될 수 있지만, directly $L$-term을 손 보는 게 아니라 다른 차원의 메모리량을 줄여서 (e.g., hidden_dim size를 줄인다거나 (TP), batch size를 줄인다거나 (DP), layer 단위로 모델을 잘라서 각 GPU에 넣는다거나 (PP)...) 전체 메모리 요구량을 줄이는 방식이다.

⇒ 이 논문은 long-context Transformer 모델의 메모리 요구량을 낮추기 위해 시스템 관점에서 직접적으로 context size (or sequence length) $ L $ 차원을 쪼개는 방법을 택한다.

아래 TP와의 비교 그림을 보면, layer의 hidden_dim 차원으로 모델을 쪼개는 TP와 달리 SP는 Input을 token dim으로 분리한다. 그래서 엄밀히 말하면 모델은 쪼개지지 않고 각 device에 replica로 올라간다. 모델을 안 쪼개고 input을 쪼갠다는 관점에서 오히려 DP랑 비슷한 느낌. Transformer를 위한 DP 느낌.

TP vs SP

Method: Ring Self-Attention

Input을 token-level로 쪼개서 각 device에 나눠담는다.
- input $X^{(n)}$: $ (L/N, d) $ (기본 transformer 구조에서 attention block 직전의 input dim이 $ (L, d) $이고 이걸 $N$개 GPU에 나눠담는다 가정)
각 GPU에서 local하게 Q, K, V projection 연산 ($Q ^{(n)} =X ^{(n)} W_Q, K ^{(n)} =X ^{(n)} W_K, V ^{(n)} =X ^{(n)} W_V$).
- Parameters $W_Q, W_K, W_V$: $(d, d_h) $가 각각 head 수 $H$개 만큼씩 있음. ($ d_h $: head 별 hidden dim.) 이거는 기본 transformer랑 동일함. 각 local device에 같은 parameter replica들이 복사되어 올라감.
- $Q ^{(n)} , K ^{(n)} , V ^{(n)} $: $(L/N, d_h) $
Attention 연산 ($A ^{(n)} = softmax(\frac{Q ^{(n)} K^\top}{\sqrt{d}})$).
- $K=\{K ^{(1)}, K ^{(2)} ,\dots, K ^{(N)} \}$ all-gather (Fig. 2 (a)): 원래 transformer 같으면 그냥 $QK^ \top $ 연산하면 되는데 여기는 $Q ^{(n)} , K ^{(n)} $로 쪼개져 있으니까 최소한 $K ^{(n)} $는 all-gather를 해줘야 함. 자기가 갖고 있던/혹은 받은 $K ^{(n)} $를 다음 device에 circular하게 총 $N-1$번 넘겨준다. => 모든 device가 전체 $L \times d_h$ 크기의 full $K$를 가지게 됨.
- $A ^{(n)} $: $(L/N, L)$. 쪼개진 $Q ^{(n)} $이랑 full $K$랑 matmul하고 softmax까지.
Output 연산 ($O ^{(n)} = A ^{(n)}V$).
- $V=\{V^{(1)}, V ^{(2)} ,\dots, V ^{(N)} \}$ all-gather (Fig. 2 (b)): 비슷하게 각 device에서 갖고 있던 / 혹은 이전 device로부터 받은 Value embedding $V^{(n)}$을 다음 device에 circular하게 총 $N-1$번 넘겨준다. => 모든 device가 전체 $L \times d_h$ 크기의 full $V$를 가지게 됨.
- $O ^{(n)} $: $(L/N, d_h)$

Ring Self-Attention 제안.

Q. 왜 꼭 ring style P2P 해야 하나? 사실상 결과 all-gather랑 같은 거 아닌가?

A. GPT의 정리에 의하면... 한마디로, ring-style P2P가 all-gather에 비해 시간이 더 오래걸리고 대신 memory usage를 줄인 버전이라고 보면 될듯. 약간 online streaming 버전의 all-gather 느낌.

	All-Gather	Ring-style P2P
기본 아이디어	각 GPU shard를 모두 모아서 full tensor 생성	tensor block을 GPU 사이에서 순환 전달하면서 계산
통신 패턴	각 GPU i가 xi 들고 있을 때, All-Gather 한 번으로 → GPU0: [x0 x1 x2 x3] GPU1: [x0 x1 x2 x3] GPU2: [x0 x1 x2 x3] GPU3: [x0 x1 x2 x3] 모든 GPU가 full tensor 보유	GPU0 → GPU1 → GPU2 → GPU3 → GPU0 총 N-1번의 P2P가 발생하고, 각 step 마다: 1) receive xi 2) compute (e.g., attention A 연산) 3) send xi
통신 방식	Collective communication	Point-to-point streaming
GPU topology	broadcast / tree	ring
통신 단계	1 step	N-1 steps
통신 후 tensor	full tensor 크기	여전히 local shard
latency	낮음	높음 (N-1 iteration)
pipeline overlap	제한적	가능 (compute + comm overlap)
softmax 처리	일반 softmax	online softmax 필요

Q. 이렇게 했을 때, PP나 TP 대비 memory usage / communication overhead 차원에서 어떤 이점이 있나?

A. 일단 메모리 차원 분석: 표 1에서 TP와의 memory 비교 제공함. TP와 SP를 비교하면, TP는 parameter들을 쪼갰고, SP는 input을 쪼갠다. 그래서 TP는 다음 layer의 input dim을 유지하기 위해 output dimension을 맞춰줘야 하고, 그러기 위해 output을 매번 all-gather해줘야 한다. 반면, SP는 어차피 다음 layer의 input dim도 쪼개진 상태니까 굳이 output dim을 맞추기 위해 추가적인 all-gather가 필요하지 않다. 다시 말해 output dim도 쪼개진 상태로 유지 가능!

Memory Usage Comparison: TP vs SP (B: batch size, H: hidden dim (=$d$), Z: head 수 (=$H$), A: (=$d_h$))

Tensor Parallelism 구조

그리고 communication cost도 비교해보면:

TP: forward, backward 때 한 layer당 각 2번 (=> 총 4번)의 all-gather 필요, 한 번 all gather 당 N-1 번의 송/수신 (=> 총 2(N-1)번) 필요 (ring all-gather), 매번 $(B, L, H/N)$ 크기의 data 송/수신
- => 총 $8(N-1) \times (BLH/N) $.
SP: forward 때 ring-style P2P가 (N-1)번씩 두 번 (each for K, V of size $BLH/N $) 발생, backward 때는 $\frac{\partial L}{\partial W^O}$와 $\frac{\partial L}{\partial A}$를 구하기 위해 all-reduce 한 번씩, $\frac{\partial L}{\partial K}$와 $\frac{\partial L}{\partial V}$ 얻기 위해 ring-style P2P (N-1)번씩 $BLH/N$ 크기의 data 통신.
- => 총 $6(N-1)\times (BLH/N)$.

Strength

+) context scaling에 좋은 기법인듯. TP랑 비슷하면서도 memory usage나 communication cost는 더 적고.

Weakness

-) online softmax를 썼을 것으로 추정되는데 관련 언급이 별로 없는..? online softmax가 전체 convergence에도 영향을 줄 것 같은데. Appendix B 보면 convergence performance가 TP랑 SP랑 완전히 같지가 않다. 물론 논문에서는 SP가 더 빠르게 수렴한다고 주장하지만, 좀 더 분석이 필요할지도.

DeepSpeed-Ulysses

오렌징큐 — Fri, 13 Mar 2026 10:51:29 +0900

논문 (ArXiv'23) : DeepSpeed Ulysses: System Optimizations for Enabling Training of Extreme Long Sequence Transformer Models

DeepSpeed Ulysses: System Optimizations for Enabling Training of Extreme Long Sequence Transformer Models

Computation in a typical Transformer-based large language model (LLM) can be characterized by batch size, hidden dimension, number of layers, and sequence length. Until now, system works for accelerating LLM training have focused on the first three dimensi

arxiv.org

사이트 : https://github.com/deepspeedai/DeepSpeed/tree/master/blogs/deepspeed-ulysses

DeepSpeed/blogs/deepspeed-ulysses at master · deepspeedai/DeepSpeed

DeepSpeed is a deep learning optimization library that makes distributed training and inference easy, efficient, and effective. - deepspeedai/DeepSpeed

github.com

이 당시 (2023년) 분산학습 기법은 크게 3 가지 (DP / TP / PP)로 나뉘었다. 그런데 얘네들은 long sequence Transformer model에 특화된 기법들이 아니다.

Q. long sequence를 다루는 transformer 모델이 왜 중요하냐?
A. "긴 문서에 대해 통합적으로 한번에 context를 이해하는 능력"이 어디에 중요할까?
- 긴 문서 (e.g., 책 한 권) 기반 요약 / reasoning / RAG 이런데에 잘 쓰임.
- video generation task에서도 spatial / temporal domain에서 하나의 video를 하나의 긴 context라고 볼 수 있음. -> 하나의 video를 통합적으로 이해하는 능력.
- multimodal 상황에서도, 일단 이미지가 들어가면 기본적으로 먹고 들어가는 token 수가 많아짐. 이미지를 보고 reasoning하려면 모델 자체가 long context를 다룰 줄 알아야 함.
- structure biology, large molecular simulation, weather forecasting 같은 과학 AI 분야에도 활용성이 높음.

-) Long sequence transformer model에 기존 분산학습 기법들을 적용했을 때의 한계점: sequence dimension으로 scaling이 안됨. 다시 말해, 'sequence 길이 늘어나면 그냥 지금 분산학습 구조에 GPU 하나 더 추가하면 되잖아~' 같은 발상이 (안되는건 아니겠지만 구현하기가) 어려움.

Previous Works: Sequence Parallelism

=> 그래서 sequence (tokens)-dimension으로 자르는 Sequence Parallelism (SP)이란 게 나왔다.

Related Work 1) Sequence Parallelism: Long Sequence Training from System Perspective
- layer의 hidden_dim 차원으로 모델을 쪼개는 TP와 달리, Input을 token dim으로 분리한다. 그래서 엄밀히 말하면 모델은 쪼개지지 않고 각 device에 replica로 올라간다. 오히려 DP랑 비슷한 느낌. Transformer를 위한 DP 느낌.
- 자세한 내용은 이 글 참고 -> 2026.03.15 - [분산 ML] - Sequence Parallelism: Long Sequence Training from System Perspective

TP vs SP

Related Work 2) Reducing Activation Recomputation in Large Transformer Models
- 기본 Megatron TP 구조에서, TP가 적용 안되는 Dropout, LayerNorm 같은 부분에 SP 적용. 따라서 중간 activation 값들도 device에 나눠 저장하게 되니까 전체 memory 요구량이 줄어듦. -> 원래는 이 activation 저장 용량이 커서 activation recomputation 같은 기법을 적용했는데, 이제 굳이 필요가 없어진,,

TP & SP 짬뽕

-) 근데 기존 SP는 memory, communication 차원에서 여전히 비효율적이다.

Communication Volume이 여전히 크다. Memory efficiency도 여전히 크다.
ColAI-SP (Related Work 1)의 경우 기존 self-attention 대신 특별한 ring self-attention을 사용해서 불편하다 (?).
기존 분산학습 코드가 좀 드러움 (=error prone, intrusive) -> 사용성이 떨어짐. (이거 실제로 돌려본 사람 입장에서 완전 인정ㅎ,, 특히 Megatron. 사용성 측면에서는 torchtitan이 탑임.)

=> 이 논문:

기존 두 SP 방식에 비해 communication volume ($M$)을 GPU 수 ($P$)에 비례하게 줄였다.
FSDP (DeepSpeed ZeRO)를 짬뽕해놔서 memory efficiency도 올렸다.

Method

기본 Transformer 연산 구조

기본 Transformer (Multi-head attention) 병렬연산 구조:

QKV 연산까지는 각 GPU에서 하든, 한 GPU에서 하든 해서 암튼 각자 연산함.
그리고 각 GPU가 각각 서로 다른 head를 담당해서 attention 연산. (head-wise 병렬 처리)
그 다음에 all-gather를 하든 gather를 하든 해서 head 별 P 값($P_h=S_h\cdot V_h$)을 한 GPU로 모은 다음에 마지막 $W_o$ 곱해서 output $O$ 만듦.

여기에 Sequence Parallelism를 적용해보면, 처음에 input $x$를 $(N, d) \rightarrow (N/P, d)$로 분할하는 건 모든 SP 방식들에서 동일.

그런데 그 뒤에 어떤 임베딩을 어떤 방식으로 통신할거냐에서 조금씩 다름.

기존 SP 구조에서는 K랑 V embedding을 ring-style P2P로 모든 GPU가 값을 공유했다 :

Attention 연산 전에, K embedding을 ring-style P2P로 GPU들 간 값 공유.
- Communication Volume: $Nd/P \times (P-1)=O(Nd) $ (각 GPU가 총 P-1개 GPU로부터 Nd/P 크기의 데이터를 받음.)
- Communication Time: P2P 통신시간 x (P-1) 회
- Memory Complexity: $O(Nd/P)$
attention score에 V 곱하기 위해, V embedding을 ring-style P2P로 GPU 간 공유.
- Communication Volume / Time / Memory Complexity는 K embedding 때랑 동일.

DeepSpeed-Ulysses 연산 구조

그런데 이 DeepSpeed-Ulysses는 ring-style P2P 대신 all2all 통신을 한다고 한다. 그리고 특이한 게, 이 논문에서는 all2all 통신을 할 때, 각 local에 원래 $(N/P, d)$ 차원의 tensor가 있었다면 (sequence-wise splitted), 이걸 all2all 통신을 통해 head-wise split으로 바꿔서 $(N, d/P)$ 차원의 tensor를 가지게 한다. 그러므로 통신 전후로 각 GPU가 가지는 memory 요구량은 동일한데, 통신량은 기존 ring-style P2P에 비해 줄어든다.

	All-Gather	Ring-style P2P	이 논문의 All-to-All 통신
기본 아이디어	각 GPU shard를 모두 모아서 full tensor 생성	tensor block을 GPU 사이에서 순환 전달하면서 계산	쪼개는 차원을 다르게. $(N/P, d) \rightarrow (N, d/P)$
통신 패턴	각 GPU i가 xi 들고 있을 때, All-Gather 한 번으로 → GPU0: [x0 x1 x2 x3] GPU1: [x0 x1 x2 x3] GPU2: [x0 x1 x2 x3] GPU3: [x0 x1 x2 x3] 모든 GPU가 full tensor 보유	GPU0 → GPU1 → GPU2 → GPU3 → GPU0 총 N-1번의 P2P가 발생하고, 각 step 마다: 1) receive xi 2) compute (e.g., attention A 연산) 3) send xi	각 GPU i가 full tensor $X$의 $X_{(i,:)}$를 들고 있었다면, all-to-all 통신으로 $X_{(:,i)}$를 가지게 됨.
Output Memory	V (V: full tensor 크기)	V/P (P: GPU 수)	V/P
중간 peak memory	V (어쨌든 full tensor를 모아야 하기에)	V/P (가장 streaming스러운. 메모리 절약형)	V/P와 V 사이. (차원을 바꾸려면 어쨌든 V/P보다는 많이 필요.)
Comm. Volume	O(V) (각 GPU가 $V/P$ 크기 데이터를 보내고, $V\cdot (P-1)/P$ 만큼의 데이터를 받음.)	O(V) (각 GPU가 $V/P \cdot (P-1)$ 만큼의 데이터를 보내고/받음.)	O(V/P) (각 GPU가 $V/P \cdot (P-1)/P$ 만큼의 데이터를 보내고/받음.

자세한 순서를 보면:

Attention 연산 전에, Q, K, V embeddings를 sequence-wise에서 head-wise로 all-to-all 재분배.
- Communication Volume: $3Nd/P=O(Nd/P) $ (각 GPU가 3Nd/P 크기의 데이터를 전송.)
- Communication Time: All2All 통신시간 x 1회 (아무래도 기준 시간은 All2All이 P2P보다 느리긴 하겠지)
- Memory Complexity: $O(Nd/P)$
각 GPU에서 자기에게 해당되는 head에 대해 self-attention 연산.
MLP block을 sequence parallel하게 처리하기 위해서 output $P_h=S_hV_h$를 다시 head-wise -> sequence-wise로 all-to-all 재분배.
- Communication Volume: $Nd/P=O(Nd/P) $ (각 GPU가 Nd/P 크기의 데이터를 전송.)
- Communication Time: All2All 통신시간 x 1회
- Memory Complexity: $O(Nd/P)$

+ DS-Ulysses는 DeepSpeed ZeRO-3를 결합한다. model states나 gradient를 각 GPU에 쪼개 담는 ZeRO 방식(FSDP)을 적용해서, 전체 DP x SP groups에 걸쳐서 분할하고, 연산에 필요한 순간에만 all-gather를 통해 분할된 조각들을 가져온다.

A. ring-style P2P vs all2all (all-gather) 통신 차이:

한마디로, ring-style P2P가 all-gather에 비해 시간이 더 오래걸리고 대신 memory usage를 줄인 버전이라고 보면 될듯. 약간 online streaming 버전의 all-gather 느낌.

	All-Gather	Ring-style P2P
기본 아이디어	각 GPU shard를 모두 모아서 full tensor 생성	tensor block을 GPU 사이에서 순환 전달하면서 계산
통신 패턴	각 GPU i가 xi 들고 있을 때, All-Gather 한 번으로 → GPU0: [x0 x1 x2 x3] GPU1: [x0 x1 x2 x3] GPU2: [x0 x1 x2 x3] GPU3: [x0 x1 x2 x3] 모든 GPU가 full tensor 보유	GPU0 → GPU1 → GPU2 → GPU3 → GPU0 총 N-1번의 P2P가 발생하고, 각 step 마다: 1) receive xi 2) compute (e.g., attention A 연산) 3) send xi
통신 방식	Collective communication	Point-to-point streaming
GPU topology	broadcast / tree	ring
통신 단계	1 step	N-1 steps
통신 후 tensor	full tensor 크기	여전히 local shard
latency	낮음	높음 (N-1 iteration)

비교하면,

	ColAI-SP (첫 SP 논문)	Megatron-SP (TP+SP)	DS-Ulysses (FSDP+SP)
통신 방법	ring-style P2P	all-gather, reduce-scatter	gather, scatter
Comm. Volume	$2Nd$	$4Nd$	$4Nd/P$

Strength

+) 기존 방법들보다 communication volume이 더 줄었다.

+) ring-style P2P 때처럼 특이한 연산구조를 하지 않아도 (?) 된다.

NVIDIA GeForce RTX3090 Architecture

오렌징큐 — Tue, 22 Jul 2025 15:48:26 +0900

출처: https://www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-architecture-whitepaper-v2.pdf

RTX 3090에는 Ampere GA102 architecture가 사용되었다.

GA102 Full GPU with 84 SMs

GPC 구조

High-Level Architecture

이전 NVIDIA GPU들과 비슷하게, GA102는 다음과 같이 구성된다:

7 Graphics Processing Clusters (GPCs) : 주요 graphics processing units가 다 들어 있는 hardware block.
- 각 GPC 안에는 Raster Engine, 2 ROP partitions (각 파티션에 8 ROP units 있음), 6 TPC가 있음.
- Raster Engine
- Raster Operators (ROPS) : GPC 구조 그림에서 밑줄 파란색 직사각형들.
  - 예전 GPU 구조들에서는 ROPs가 memory controller에 달려 있었는데, 이번 구조부터는 GPC 내부로 들어왔다. => raster operation performance $\uparrow$
- Texture Processing Clusters (TPCs) :
  - 각 TPC 안에는 2개의 SM, 1 PolyMorph Engine이 있음.
  - Streaming Multiprocessors (SMs) :
    - 각 SM은 128개의 CUDA Cores, 4개의 3rd-gen Tensor Cores, 256KB Register file, 4 Texture Units, 1 Ray Tracing Core, 128KB L1/Shared Memory를 가진다.

12 Memory controllers :
- 전체 GA102에는 12개의 32-bit memory controller와 각 memory controller에 달린 512 KB짜리 L2 cache가 있다.

$\therefore$ Full GA102 GPU는 7 GPCs, 42 TPCs (=7 GPCs x 6 TPCs/GPC), 84 SMs (=7 GPCs x 6 TPCs/GPC x 2 SMs/TPC)를 가진다.

GA10x SM Architecture

아래 그림에서 보이듯이, GA10x SM은 4개의 큰 processing block으로 이루어진다.

각 processing block에는:

64KB register file : GPU가 SIMD (Single Instruction, Multiple Data)가 아닌 SIMT (-, Multiple Threads)인 이유는, 하나의 thread에서 하나의 명령어로 여러 개의 데이터를 처리하는 SIMD 구조와 달리, GPU에서는 한 warp로 묶인 각 thread가 서로 다른 자기만의 execution context를 가지고 있기 때문이다. 이 각 thread 별 context는 바로 register로 관리된다. 한 SM에 배정된 thread block 내 모든 thread들이 각자의 register 영역을 가진다. 예를 들어 thread block 안에 512개 thread가 있으면 register file이 512등분되고 thread들이 이를 하나씩 사용한다.
L0 instruction cache
1 warp scheduler : 다음에 처리할 warp를 결정한다.
1 dispatch unit : 다음에 처리될 warp에 명령을 내린다.
1 3rd Gen Tensor Core : FP16 연산 담당.
2 datapaths. 각 datapath는 연두색 한 길쭉 직사각형을 의미.
- 16 FP32 CUDA Cores = clock 당 16개의 FP32 operation을 처리할 수 있음.
- 16 FP32 CUDA Cores & 16 INT32 Cores : 1 clock에 FP32 / INT32 연산 16개를 동시 처리 가능.
- 즉 한 clock 당 32개의 FP32 연산을 하거나, FP32 연산 16 + INT32 연산 16개를 처리할 수 있는 셈.
- 이전 GPU 구조인 turing 구조에서는 두 datapath 중 하나만 FP32 연산을 지원했는데 (나머지 하나는 INT32 only), 요즘에는 단순 integer 덧셈 연산에 비해 복잡한 floating point 연산이 부쩍 많아져서, 이번에는 두 datapath 모두 FP32 연산을 지원하게 되었다. 그래서 FP32 연산의 peak processing rate이 두 배가 되었다.

그리고 이 4개의 processing blocks는 하나의 128 KB L1 data cache / shared memory subsystem을 공유한다.

한 memory 공간을 cache와 shared memory로 쪼개서 사용할 수 있는 건데,

예를 들어 128 KB 전체를 L1 cache로만 쓸 수도 있고, 공유 메모리를 많이 써야 한다면 L1 cache 영역을 28 KB로 줄이고 shared memory를 100 KB로 설정할 수도 있다. 설정하기 나름임.

GA10x Streaming Multiprocessor (SM)

Fine-Grained Structured Sparsity

AI-based graphics inference 연산할 때, 속도를 더 높이고자 재밌는 방식을 지원한다.

딥러닝할 때, 사실 weights 중에서 중요한 정보를 담고 있는 weights는 일부고 나머지는 거의 0에 가까운 noise를 가진다. 이런 sparsity를 활용해서 아래 그림처럼 dense trained weights를 절반으로 압축해버린다.

그럼 연산 속도가 두배에 가깝게 빨라지겠지!

Fine-Grained Structured Sparsity

RTX IO

RTX IO는 게임 성능 향상을 위해 개발된 GPU 가속 storage 기술이다.

요즘 게임이 하도 삐까뻔쩍하니까 큰 게임은 200GB가 넘기도 한다. 어쨌든 그래서 system memory에 기본 적재할 수는 없고, hard drive에 넣던가 SSD에 넣던가 해야된다. 그래서 hard disk나 SSD에 game file을 넣어놓으면 그걸 CPU로 가지고 가서 decompress를 해서 게임을 로드했다.

게임 로딩 시간을 빠르게 하려면 SSD에 넣어놓는게 훨씬 빠르겠지. 원래는 hard drive에서 main memory로 load해오는 storage I/O가 병목이었는데, 요즘은 SSD 성능도 하도 좋아지고, 개발자들이 lossless compression을 써서 설치 용량도 줄이고 하니까, 오히려 이제 storage I/O보다 CPU에서 decompression 하는 게 병목이 되어버렸다.

옛날에 100MB/s 속도의 hard drive 시절에는 storage IO가 느리니까 압축 해제는 CPU core 몇 개만 써도 충분했다. 근데 이제는 PCIe Gen4 SSD는 7GB/s 속도로 가지고 와서, 그 속도에 맞춰서 decompress하려면 CPU core가 20개 이상이 필요해졌다.

Games Bottlenecked by Traditional I/O

그래서 NVIDIA에서 RTX IO는 Microsoft의 DirectStorage API와 최신 NVMe SSD가 장착된 gaming PC에서 가능한, GPU-based lossless decompression 기술을 지원한다. 다시 말해, CPU에서 먼저 decompress할 필요 없이 DirectStorage API를 통해 compress된 상태로 GPU로 읽어온 다음에 GPU에서 decompression을 진행한다. 그러니까 이제 CPU의 연산 부담을 확 줄여준 셈.

RTX IO Delivers 100x throughput, 20x lower CPU utilization

CUDA 함수들

오렌징큐 — Sun, 29 Jun 2025 23:50:32 +0900

Host Code <-> Device Code

https://ianfinlayson.net/class/cpsc425/notes/21-cuda

CUDA 프로그램은 host code와 device code로 구성됨.

host code: CPU용. 컴퓨터 시스템의 기본 연산 장치는 CPU니까 기본적으로 필요함. 이 host code에서 kernel을 호출해야만 GPU 등 다른 연산 장치에 접근, 사용할 수 있음.
- host: CPU
- host memory: system의 기본 DRAM 메모리 영역. 모든 데이터는 기본적으로 host memory에 저장되어 있음. GPU를 이용해 data를 처리하려면 host mem에 있는 data를 device mem으로 복사해야 함.
device code: GPU 등 다른 연산 장치를 사용하기 위해서 쓰는 코드.
- device: GPU
- device memory:

CUDA program 흐름

host -> device data 복사 through PCI bus.
host code에서 kernel call, GPU에게 연산 주문.
GPU의 연산 using device memory.
device memory의 저장된 연산 결과를 다시 host memory (main memory)로 복사.

`cudaMalloc(void ** ptr, size_t size)`
- device memory에, `ptr` 포인터 변수가 가리키는 시작 주소부터 `size` 만큼의 Byte 공간을 할당하기. 성공하면 0 (`cudaSuccess`) 반환, 실패하면 에러 코드 (ex. `cudaErrorMemoryAllocation`=2) 반환.
`cudaFree(void *ptr)`
- `ptr`이 가리키는 device 메모리 공간을 해제. 성공하면 0, 실패하면 에러 코드 반환.
`cudaMemset(void *ptr, int value, size_t size)`
- `ptr`이 가리키는 시작 주소부터 `size` Byte만큼 `value` 값으로 device memory 초기화하기.
`cudaMemcpy(void *dst, void* src, size_t size, enum cudaMemcpyKind kind)`
- `src` 주소로부터 `size` Byte만큼의 data를 `dst` 주소로 복사.
- `cudaMemcpyKind` 종류들:
  - `cudaMemcpyHostToHost`: host memory `src` 주소로부터 `size`만큼의 data를 host memory `dst` 주소로 복사
  - `cudaMemcpyHostToDevice`: host memory `src` 주소로부터 `size`만큼의 data를 device memory `dst` 주소로 복사
  - `cudaMemcpyDeviceToHost`: device memory `src` 주소로부터 `size`만큼의 data를 host memory `dst` 주소로 복사
  - `cudaMemcpyDeviceToDevice`: device memory `src` 주소로부터 `size`만큼의 data를 device memory `dst` 주소로 복사

CUDA Thread 계층

https://jdriven.com/blog/2024/02/gpu_part2

Thread: CUDA thread hierarchy에서 가장 작은 unit. CUDA core를 사용하는 기본 단위.
Warp: 연속된 32개의 thread를 하나로 묶은 것. CUDA의 기본 수행 단위.
- 한 warp에 속한 32개의 thread들은 하나의 제어 장치에 의해 제어됨.
- GPU의 SIMT 구조의 "Multiple Thread"가 한 warp를 의미함. 하나의 instruction에 따라 32개의 thread가 동시에 움직이는.
Block (thread block): warp들의 집합.
- 하나의 block에 포함된 각 thread는 자신만의 고유한 thread ID를 가진다. 약간 좌표값 마냥.
Grid: 여러 개의 block을 포함하는 block들의 그룹. GPU를 사용하는 단위.
- kernel이 호출되면 grid가 생성된다. kernel call : grid = 1:1 대응.
- 하나의 grid에 포함된 blocks는 서로 다른 고유한 block ID를 가진다. 따라서 grid 내 특정 block의 특정 thread를 지칭하려면, block ID와 thread ID를 표기하면 됨. 해당 block ID의 block 내에서 해당 thread ID를 가지는 thread를 찾을 수 있다. block ID가 단지 내 건물 번호면 thread ID는 건물 내 방 번호 (101호 같이).

커널 호출할 때:

Dim3 dimGrid(4,1,1); // (4,1,1) 차원의 그리드 생성하라는 뜻. 한 그리드 내에 4개의 block이 생성.
dim3 dimBlock(8,1,1); // (8,1,1) 차원의 block 생성하라는 뜻. 한 block 내에 8개의 thread 생성.
kernel<<<dimGrid, dimBlock>>>(); // kernel 호출.

CUDA Thread 계층 <-> GPU Hardware

[개념 정리] GPU 메모리 구조 및 용어 - https://xoft.tistory.com/75

Grid -> GPU: CUDA kernel call -> grid 생성. 하나의 grid는 한 GPU에서 실행된다.
Thread Block -> SM: grid가 배정된 GPU 속에서, 각 thread block은 각 SM에 배정된다.
- active block: SM에 할당된 block 중 현재 필요한 메모리 자원(register, shared memory 등)를 모두 할당 받고 실행할 수 있는 상태인 thread block. 활성 블록의 수가 많아야 GPU가 효율적으로 사용되고 있다고 말할 수 있음. 즉, 메모리 자원을 적절히 잘 조절 및 통제해야 GPU의 utilization을 높일 수 있음.
Warp & Thread -> SM 내 CUDA core:
- warp 하나를 명령 하나로 보면 됨. 그리고 SM 내의 datapath 하나가 warp 하나를 병렬 처리한다.
- SM 내에 datapath가 보통 2개 있는데, 각 datapath가 16개의 CUDA core 묶음에 연결돼 있다.
- 즉 SM 내부의 CUDA core 총 개수는 대체로 32의 배수임. 이는 warp가 32개의 thread로 구성되었기 때문.

CUDA의 동기화 (Synchronization)

동기화 (synchronization) : 둘 이상의 연산 주체가 서로 정보를 교환하는 행위.

`cudaMemcpyAsync`

`cudaMemsetAsync`

`cudaStreamWaitEvent`

`cudaEventSynchronize`

`cudaStreamSynchronize`

`vectorized_elementwise_kernel`