RDMA 완전 가이드 2025: InfiniBand, RoCE, NCCL, GPU 통신 — AI 학습의 숨은 인프라

들어가며: AI 학습의 숨은 병목

GPT-4의 비밀

GPT-4가 10만 개의 H100 GPU로 학습되었다는 건 들어봤을 것이다. 각 GPU는 80GB 메모리 + 1 PFLOPS 성능. 어떻게 이 10만 개가 하나의 거대한 컴퓨터처럼 작동하는가?

답: RDMA (Remote Direct Memory Access).

GPU 하나는 빠르다. 그런데 여러 GPU가 같은 모델을 학습하려면 gradient를 교환해야 한다. 매 step마다. 매초 수 GB의 데이터가 GPU들 사이를 오간다.

일반 TCP/IP로는 불가능하다. 지연이 너무 크고, CPU가 병목이 된다. 그래서 AI 슈퍼컴퓨터는 RDMA 기반 네트워크를 사용한다.

RDMA의 의미

Remote Direct Memory Access. 이름대로:

• Remote: 다른 머신의.
• Direct: 직접.
• Memory Access: 메모리 접근.

일반 네트워크는 이렇다:

App → OS → TCP/IP stack → NIC → 네트워크 → NIC → TCP/IP stack → OS → App

각 단계마다 CPU 개입, 복사, 컨텍스트 스위치. 수십 μs 지연.

RDMA는 이렇다:

App → NIC → 네트워크 → NIC → App (memory)

CPU 개입 없음. OS 개입 없음. 복사 없음. 1 μs 지연.

차이는 극적:

• Latency: 50 μs → 1 μs (50배).
• Throughput: 10 GB/s → 200 GB/s (20배).
• CPU: 100% → 5% (20배).

이 글에서 다룰 것

1. RDMA의 기본: Zero-copy, kernel bypass.
2. InfiniBand: 원조 RDMA 네트워크.
3. RoCE: Ethernet 위의 RDMA.
4. Verbs API: RDMA 프로그래밍 모델.
5. NVIDIA GPU Direct: GPU ↔ NIC 직접 통신.
6. NCCL: Multi-GPU collective operations.
7. 실전 AI 학습: 3D parallelism.
8. Cloud와 RDMA: AWS EFA, Azure HB.

1. 왜 일반 네트워크로 부족한가

TCP/IP의 비용

데이터 하나를 다른 서버로 보낼 때:

1. App buffer → syscall → kernel buffer (복사 1).
2. Kernel이 TCP headers 추가.
3. Socket buffer → Network buffer (복사 2).
4. NIC이 DMA로 메모리에서 가져감.
5. 네트워크 전송.
6. 수신 NIC이 메모리에 DMA.
7. Interrupt → CPU가 처리.
8. TCP stack이 header 제거.
9. Kernel buffer → App buffer (복사 3).

문제:

• 3번의 메모리 복사: CPU와 메모리 대역폭 소모.
• Context switching: 매 syscall마다.
• Interrupt handling: 수신 측 CPU 부하.
• Header processing: TCP/IP stack overhead.

결과:

• 10 Gbps 네트워크에서 라인 속도에 못 미침.
• CPU가 100% 써도 실제 데이터 처리는 적음.
• Latency 수십 μs.

구체적 숫자

10 Gbps Ethernet, TCP:

• Bandwidth: ~9 Gbps (90%).
• Latency (localhost): 30-50 μs.
• CPU overhead: ~1 GHz per 10 Gbps.

100 Gbps Ethernet, TCP:

• 단일 core로는 불가능.
• 여러 core 사용.
• Latency: 여전히 수십 μs.

AI 학습의 요구사항:

• 수 μs latency (gradient sync).
• 수백 Gbps throughput (큰 모델).
• 낮은 CPU 사용 (CPU는 데이터 로드에 필요).

일반 TCP/IP로는 절대 충족 불가.

Solution: Kernel Bypass + Zero Copy

핵심 아이디어:

1. Kernel 건너뛰기: Application이 직접 NIC에게 명령.
2. Zero copy: 데이터를 복사하지 않고 NIC이 직접 메모리에서 DMA.
3. CPU 최소 개입: NIC이 스스로 처리.

이것이 RDMA의 본질이다.

2. RDMA의 작동 원리

Basic Concept

기존 방식:

Sender: 데이터 → kernel → TCP → network
Receiver: network → TCP → kernel → 데이터

RDMA:

Sender: "주소 X의 1 MB를 receiver의 주소 Y에 써라"
NIC이 메모리 X에서 직접 읽어서 Y에 직접 씀

마치 원격 메모리를 로컬 메모리처럼 다룬다.

Operation Types

RDMA는 주로 4가지 연산:

1. SEND/RECV:

• 메시지 전송. 수신측은 버퍼 준비 필요.
• TCP와 비슷하지만 훨씬 빠름.

2. RDMA WRITE:

• "내 메모리의 X를 너의 메모리 Y에 써라".
• 수신측 CPU 개입 없음.
• One-sided: 수신측은 참여 안 함.

3. RDMA READ:

• "너의 메모리 Y에서 읽어서 내 메모리 X에 써라".
• One-sided.

4. Atomic Operations:

• Compare-and-swap, fetch-and-add.
• 원격 메모리에 atomic 연산.
• 분산 lock, counter 등에 유용.

One-sided vs Two-sided

Two-sided (SEND/RECV):

• 양쪽이 모두 참여.
• 기존 소켓과 유사.
• 간단하지만 상대방 CPU 필요.

One-sided (WRITE/READ):

• 한쪽만 참여.
• 상대방 CPU 개입 없음.
• 더 빠름.
• 메모리 주소를 알아야 함.

One-sided이 진짜 RDMA의 파워다. 수신측은 자기 메모리가 수정되는 것도 모른다 (폴링하면 감지 가능).

Memory Registration

RDMA를 쓰려면 먼저 메모리를 등록해야:

struct ibv_mr *mr = ibv_reg_mr(pd, buffer, size, 
                               IBV_ACCESS_LOCAL_WRITE | 
                               IBV_ACCESS_REMOTE_READ | 
                               IBV_ACCESS_REMOTE_WRITE);

역할:

• Pin memory: 페이징 안 되게 고정.
• DMA 매핑: NIC이 직접 접근 가능하게.
• 권한 설정: 읽기/쓰기 허용.
• rkey 반환: 원격 접근용 키.

rkey (remote key): 원격 노드가 이 메모리에 접근할 때 사용. 일종의 "포인터 + 인증 토큰".

Connection Setup

RDMA 통신을 시작하려면:

1. QP (Queue Pair) 생성: Send Queue + Receive Queue.
2. 메모리 등록.
3. 연결 교환: QP 번호, rkey, 주소 등을 상대방과 교환 (out-of-band, TCP로).
4. QP 상태 전환: INIT → RTR → RTS.
5. 데이터 교환 시작.

Queue Pair는 TCP socket의 RDMA 버전. 모든 통신이 QP를 통해.

3. InfiniBand: 원조 RDMA

역사

InfiniBand (IB): 1999년 Intel, HP, IBM, Sun 등이 공동 개발. 본래 PCI 대체 버스로 기획. 이후 고성능 네트워크로 방향 전환.

2000년대: HPC (High-Performance Computing) 슈퍼컴퓨터의 표준.

2020년대: AI 클러스터의 표준으로 부활.

Mellanox (현재 NVIDIA 소속)가 주된 공급자.

특징

Hardware-based:

• 전용 스위치, NIC, 케이블.
• Ethernet과 별도 네트워크.
• 비쌈.

Lossless:

• Credit-based flow control: 수신측이 받을 준비가 된 만큼만 전송.
• 패킷 손실 없음.
• 재전송 로직 불필요.

Low latency:

• End-to-end: ~1 μs.
• Switch latency: ~100 ns.

High bandwidth:

• 최신: 400 Gbps (NDR).
• 이전: 200 Gbps (HDR), 100 Gbps (EDR).

InfiniBand 계층

┌────────────────────┐
│  Upper Layer       │  (Verbs API, MPI)
├────────────────────┤
│  Transport Layer   │  (RC, UC, UD)
├────────────────────┤
│  Network Layer     │  (IB addressing)
├────────────────────┤
│  Link Layer        │  (VL, flow control)
├────────────────────┤
│  Physical Layer    │  (copper, fiber)
└────────────────────┘

Transport Modes

RC (Reliable Connected):

• 연결형.
• 순서 보장, 재전송.
• TCP와 유사.

UC (Unreliable Connected):

• 연결형.
• 순서 보장, 재전송 없음.

UD (Unreliable Datagram):

• 비연결형.
• UDP와 유사.
• Multicast 지원.

대부분의 RDMA 통신은 RC 사용.

Subnet Manager

InfiniBand는 중앙 관리자가 필요:

SM (Subnet Manager):

• 네트워크 토폴로지 발견.
• 라우팅 테이블 설정.
• LID (Local ID) 할당.

OpenSM: 오픈소스 SM. 거의 모든 IB 클러스터가 사용.

Performance Example

8노드 InfiniBand HDR (200 Gbps) 클러스터:

• Per-node bandwidth: 200 Gbps.
• All-reduce 연산: 수 μs (작은 메시지).
• CPU 사용: 5% 이하.

동일 규모의 Ethernet (100 Gbps + TCP):

• Bandwidth: 60-80% (실효).
• All-reduce: 수백 μs.
• CPU: 50%+.

InfiniBand가 5-10배 효율.

4. RoCE: Ethernet 위의 RDMA

왜 RoCE

InfiniBand는 강력하지만:

• 별도 네트워크: 기존 Ethernet 인프라 재사용 불가.
• 비쌈: 전용 장비.
• 운영 복잡: SM, 라우팅 등 InfiniBand 특유의 관리.

해결: RoCE (RDMA over Converged Ethernet).

RoCE 버전

RoCE v1 (2010):

• Ethernet L2 위에 RDMA.
• 같은 L2 세그먼트만.
• 라우팅 불가.

RoCE v2 (2014):

• UDP/IP 위에 RDMA.
• L3 라우팅 가능.
• 데이터 센터에 적합.
• 현재 표준.

작동 원리

RoCE v2 패킷:

[Ethernet][IP][UDP][IB transport][RDMA payload]

Ethernet과 IP가 있으므로 일반 Ethernet 스위치 위에서 작동.

Lossless Requirement

RDMA는 패킷 손실에 취약. InfiniBand는 credit-based로 무손실. Ethernet은 기본적으로 손실 있음. 해결 필요.

PFC (Priority Flow Control):

• IEEE 802.1Qbb.
• 특정 트래픽 클래스만 pause.
• RDMA 트래픽을 무손실로.

설정:

• 모든 스위치에 PFC 활성화.
• QoS 설정으로 RDMA 트래픽 분류.
• 네트워크 전체가 lossless 도메인이어야.

DCQCN (Data Center Quantized Congestion Notification):

• 혼잡 알림 + 송신 속도 조절.
• RoCE의 end-to-end congestion control.

RoCE의 과제

"Lossless Ethernet" 구축이 어려움:

1. 모든 hop 설정 일치: 한 스위치만 틀려도 깨짐.
2. PFC deadlock: 순환 pause → 영구 정지.
3. Buffer 관리: Head-of-line blocking.
4. Debugging: 정상 동작 확인 복잡.

많은 조직이 RoCE 운영에 실패. 큰 이유 중 하나.

RoCE vs InfiniBand 비교

5. Verbs API: RDMA 프로그래밍

Verbs란

libibverbs: RDMA 프로그래밍의 표준 라이브러리. C 언어.

"Verbs" = 동작 (create, register, post, poll 등).

기본 코드 구조

초기화:

#include <infiniband/verbs.h>

// Device 찾기
struct ibv_device **dev_list = ibv_get_device_list(NULL);
struct ibv_device *dev = dev_list[0];

// Context 열기
struct ibv_context *ctx = ibv_open_device(dev);

// Protection Domain
struct ibv_pd *pd = ibv_alloc_pd(ctx);

// Completion Queue
struct ibv_cq *cq = ibv_create_cq(ctx, 1024, NULL, NULL, 0);

메모리 등록:

void *buffer = malloc(1024 * 1024);
struct ibv_mr *mr = ibv_reg_mr(pd, buffer, 1024 * 1024,
                               IBV_ACCESS_LOCAL_WRITE |
                               IBV_ACCESS_REMOTE_READ |
                               IBV_ACCESS_REMOTE_WRITE);

Queue Pair 생성:

struct ibv_qp_init_attr qp_attr = {
    .send_cq = cq,
    .recv_cq = cq,
    .qp_type = IBV_QPT_RC,
    .cap = {
        .max_send_wr = 256,
        .max_recv_wr = 256,
        .max_send_sge = 1,
        .max_recv_sge = 1,
    },
};
struct ibv_qp *qp = ibv_create_qp(pd, &qp_attr);

연결 설정:

QP 상태 전환:

• INIT: 로컬 포트 설정.
• RTR (Ready to Receive): 원격 QP 정보 설정.
• RTS (Ready to Send): 송신 준비.

상세는 여러 ioctl + 원격 정보 교환 필요.

데이터 송신 (RDMA Write):

struct ibv_sge sge = {
    .addr = (uintptr_t)buffer,
    .length = 1024,
    .lkey = mr->lkey,
};

struct ibv_send_wr wr = {
    .wr_id = 0,
    .sg_list = &sge,
    .num_sge = 1,
    .opcode = IBV_WR_RDMA_WRITE,
    .send_flags = IBV_SEND_SIGNALED,
    .wr.rdma = {
        .remote_addr = remote_addr,
        .rkey = remote_rkey,
    },
};

struct ibv_send_wr *bad_wr;
ibv_post_send(qp, &wr, &bad_wr);

완료 확인:

struct ibv_wc wc;
int n = ibv_poll_cq(cq, 1, &wc);
if (n > 0 && wc.status == IBV_WC_SUCCESS) {
    // 성공
}

복잡성

보다시피 극도로 low-level이다:

• 메모리를 명시적으로 관리.
• QP 상태 수동 전환.
• 원격 정보 수동 교환.
• 에러 처리 복잡.

이 때문에 고수준 라이브러리가 필요:

고수준 라이브러리

libfabric (OFI):

• 다양한 백엔드 지원 (Verbs, UCX, EFA).
• 더 단순한 API.

UCX (Unified Communication X):

• 여러 전송 자동 선택.
• OpenMPI 등이 사용.

MPI (Message Passing Interface):

• HPC 표준.
• OpenMPI, MVAPICH, MPICH.
• Verbs 위에 구축.

NCCL: GPU collective operations (뒤에서 설명).

gRPC over RDMA: 최근 시도.

대부분의 실제 애플리케이션은 Verbs를 직접 쓰지 않고 이들 고수준 라이브러리 사용.

6. NVIDIA GPU Direct

GPU와 네트워크의 문제

일반적인 GPU ↔ Network:

GPU memory → (DMA copy) → CPU memory → NIC → 네트워크

• CPU memory를 경유.
• 2번의 DMA.
• CPU 메모리 대역폭 낭비.
• 추가 latency.

GPU Direct RDMA

GPU Direct RDMA (2013+):

• NIC이 GPU 메모리에 직접 DMA.
• CPU 메모리 우회.

GPU memory → NIC → 네트워크

조건:

• NVIDIA GPU + CUDA-aware NIC (Mellanox ConnectX).
• Same PCIe root complex (일반적으로).
• Kernel module.

효과:

• Latency 절반.
• Bandwidth 2배.
• CPU 개입 거의 없음.

GPU Direct의 종류

1. GPU Direct P2P:

• 같은 서버 내 GPU 간 직접 통신.
• NVLink: 전용 고속 링크 (600 GB/s+).
• PCIe: 일반 (32 GB/s).

2. GPU Direct RDMA:

• 원격 GPU와 RDMA.
• NIC ↔ GPU 메모리.

3. GPU Direct Storage (GDS):

• NVMe ↔ GPU 직접.
• 데이터 로딩 가속.

NVLink

NVIDIA 전용 고속 링크:

• GPU ↔ GPU 직접 연결.
• PCIe의 수십 배 대역폭.
• 최신 H100: 900 GB/s.

NVSwitch: 여러 GPU를 all-to-all 연결.

DGX H100: 8 GPU, 전용 NVSwitch, 각 GPU 900 GB/s.

AI 학습에 결정적: Gradient sync가 PCIe 기반보다 수십 배 빠름.

7. NCCL: Multi-GPU Collectives

NCCL이란

NCCL (NVIDIA Collective Communications Library):

• GPU collective operations 라이브러리.
• NVIDIA 개발.
• AI 학습의 표준.

Collective Operations

여러 GPU 간 동시 통신:

1. All-Reduce:

• 모든 GPU의 값을 합친 후 모든 GPU에 결과 전달.
• Gradient sync에 핵심.

2. All-Gather:

• 모든 GPU가 각자의 데이터를 모두에게 전달.

3. Reduce-Scatter:

• All-Reduce + Scatter.

4. Broadcast:

• 한 GPU의 데이터를 모두에게.

5. Reduce:

• 모든 GPU → 한 GPU.

All-Reduce가 중요한 이유

Data parallel training:

GPU 1: 일부 데이터로 gradient 계산 → g1
GPU 2: 일부 데이터로 gradient 계산 → g2
GPU 3: 일부 데이터로 gradient 계산 → g3
GPU 4: 일부 데이터로 gradient 계산 → g4

All-reduce: 모든 GPU가 g = (g1 + g2 + g3 + g4) / 4 를 가짐

Each GPU: model 업데이트

매 step마다 all-reduce. 효율이 학습 속도 결정.

Ring All-Reduce

단순 접근: 중앙 집중.

• 모든 GPU → 1 GPU (합산) → 브로드캐스트.
• Bottleneck: 중앙 GPU.

Ring All-Reduce:

GPU0 → GPU1 → GPU2 → GPU3 → GPU0 (ring)

단계:

1. Scatter-reduce: N-1 단계 동안 데이터를 ring으로 전달하며 부분 합.
2. All-gather: N-1 단계 동안 각 chunk를 ring에 전파.

이점:

• 모든 GPU가 동시에 송신/수신.
• Bandwidth 최대 활용.
• Optimal algorithm (대역폭 관점에서).

NCCL의 최적화

NCCL은 토폴로지 인식:

• NVLink 우선 사용.
• 같은 node 내: NVSwitch로 직접.
• 다른 node: RDMA (InfiniBand/RoCE).
• GPU Direct: CPU 우회.

자동 선택: 하드웨어를 감지해 최적 경로.

Example

import torch
import torch.distributed as dist

# NCCL backend 사용
dist.init_process_group(backend='nccl')

# Model parallel
model = torch.nn.parallel.DistributedDataParallel(
    model,
    device_ids=[rank]
)

# 학습
for batch in dataloader:
    output = model(batch)
    loss = criterion(output, target)
    loss.backward()
    # 자동으로 NCCL All-Reduce 수행
    optimizer.step()

PyTorch의 DistributedDataParallel이 NCCL을 내부적으로 사용. 개발자는 기본값만 설정하면 수천 GPU에서 학습 가능.

성능

8 GPU (single node, NVLink):

• All-Reduce: ~5 μs (작은 메시지).
• Near-optimal.

64 GPU (multi-node, InfiniBand):

• All-Reduce: ~50 μs.
• 95% efficiency.

1024 GPU:

• All-Reduce: ~200 μs.
• 80% efficiency.

네트워크 토폴로지가 결정적.

8. 3D Parallelism

대형 모델의 도전

GPT-3 (175B 파라미터)조차 단일 GPU 메모리에 못 들어간다. GPU 메모리 80GB, 모델 파라미터만 350GB (FP16).

해결: 모델과 데이터를 분할.

Data Parallelism (DP)

각 GPU가 전체 모델, 다른 데이터:

GPU 1: [Full Model] × Batch 1
GPU 2: [Full Model] × Batch 2
GPU 3: [Full Model] × Batch 3
GPU 4: [Full Model] × Batch 4

Sync: All-Reduce gradients

제약: Model이 single GPU에 들어가야.

Tensor Parallelism (TP)

Model을 여러 GPU에 수평 분할:

Linear Layer (1024 × 4096):
GPU 1: [1024 × 2048]
GPU 2: [1024 × 2048]

필요: 매 연산마다 GPU 간 통신 (AllGather, ReduceScatter).

용도: 매우 큰 layer (거대 LLM).

Pipeline Parallelism (PP)

Model을 stage로 분할:

GPU 1: Layers 1-8
GPU 2: Layers 9-16
GPU 3: Layers 17-24
GPU 4: Layers 25-32

문제: Bubble (유휴 시간). GPU 1이 끝나면 GPU 2로 넘어감, GPU 1은 다음 batch 대기.

해결: Micro-batching. 여러 작은 batch로 나눠 pipeline을 채움.

3D Parallelism

DP + TP + PP를 모두 결합:

8 GPUs = 2 DP × 2 TP × 2 PP

DP dim: [group1, group2]
Each group: 2 TP × 2 PP = 4 GPUs

GPT-4 급 모델:

• 10000+ GPUs.
• 수백 DP × 수십 TP × 수십 PP.

통신 패턴

각 parallelism 타입은 다른 통신 요구:

• DP: All-Reduce (gradient sync). 매 step.
• TP: All-Gather, Reduce-Scatter. 매 layer.
• PP: Point-to-point. Stage 간.

NCCL이 모두 지원. RDMA가 필수.

통신과 계산의 오버랩

고급 기법: 통신을 계산에 숨김.

Step 1: 계산 (forward)
Step 2: backward 시작 + 이전 gradient 통신 (동시)
Step 3: 통신 끝날 때쯤 backward 끝남

잘 되면 통신 오버헤드 거의 0.

9. Cloud의 RDMA

클라우드의 도전

Bare metal HPC: InfiniBand 직접. Public Cloud: 가상화, multi-tenant.

클라우드에서 RDMA는 어려움:

• Virtualization: NIC 공유.
• Isolation: 테넌트 간.
• Performance: 라인 속도.

AWS EFA (Elastic Fabric Adapter)

Amazon EFA: AWS의 RDMA 솔루션.

특징:

• SRD (Scalable Reliable Datagram): 자체 프로토콜.
• RoCE 아님: AWS 전용.
• libfabric API.
• NCCL 지원.

사용:

• P4d, P5, Trn1 인스턴스 (ML용).
• HPC 워크로드.

성능:

• 400 Gbps per instance.
• Low latency (~10 μs, InfiniBand보다 느림).

Azure HB/HC Series

Azure: Bare metal에 가까운 HPC 인스턴스:

• InfiniBand HDR (200 Gbps).
• HB (high bandwidth), HC (high compute).
• SAP HANA, 금융 시뮬레이션 등.

GCP A3

Google: A3 인스턴스 (H100 GPU).

• 200 Gbps per GPU (8 GPU = 1.6 Tbps).
• Google 자체 인터커넥트.

OCI Cluster Networking

Oracle Cloud Infrastructure:

• RDMA over Converged Ethernet.
• Full bisection bandwidth.
• Low latency.

클라우드 vs 온프레미스

온프레미스 HPC:

• ✅ 최고의 성능.
• ✅ Customization.
• ❌ 초기 투자 큼.
• ❌ 유지보수 복잡.

클라우드:

• ✅ Pay-as-you-go.
• ✅ 빠른 scale up.
• ✅ 최신 GPU 접근.
• ❌ 약간의 오버헤드.
• ❌ Cloud lock-in.

대부분의 AI 기업이 클라우드 채택. OpenAI, Anthropic, Meta 등.

10. 실전 AI 인프라

xAI의 Colossus

**xAI (Elon Musk)**의 슈퍼컴퓨터:

• 100,000 H100 GPU.
• InfiniBand NDR (400 Gbps).
• 122일 만에 구축.
• 대형 LLM 학습.

Meta의 AI 클러스터

Meta: 24,576 H100 cluster × 2 (2024).

• RoCE 기반.
• Llama 3 학습.
• 거대 투자.

NVIDIA DGX SuperPOD

NVIDIA 레퍼런스 아키텍처:

• H100 기반.
• InfiniBand fabric.
• 32-노드 × 8 GPU = 256 GPU unit.
• 여러 unit 확장 가능.

학습 시간

GPT-3 (175B):

• 원래 논문: 수 개월, 수천 GPU.
• 현재 하드웨어: 수 주.

GPT-4 (추정):

• 수 개월.
• 20,000+ GPU.
• 수천만 달러 비용.

핵심: 네트워크가 계산만큼 중요.

11. Monitoring과 Troubleshooting

RDMA Metrics

핵심 지표:

Bandwidth: 실제 처리량 vs 이론치.

Latency: End-to-end 지연.

Packet loss: RoCE에서 특히 중요.

PFC events: Pause 발생 빈도.

QP errors: 연결 문제.

측정 도구

ib_send_bw: InfiniBand 대역폭 벤치마크.

# Server
ib_send_bw

# Client
ib_send_bw server_ip

ib_send_lat: Latency 측정.

perftest: 다양한 RDMA 테스트.

NCCL tests:

./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8

GPU all-reduce 성능.

일반적 문제

1. PFC 미설정:

• 증상: 패킷 손실, 성능 급락.
• 해결: 모든 스위치 PFC 확인.

2. MTU 불일치:

• RoCE는 특정 MTU 요구 (보통 9000 jumbo frame).
• 불일치 시 성능 저하.

3. NUMA affinity:

• GPU와 NIC이 같은 NUMA node에.
• 아니면 성능 저하.

4. GPU Direct 미활성:

• 커널 모듈 로드.
• BIOS 설정 확인.

5. Queue pair 한계:

• 큰 규모에서 QP 수 제한.
• NIC 펌웨어 확인.

12. 미래

Ultra Ethernet

Ultra Ethernet Consortium (2023):

• AMD, Broadcom, Cisco, HPE, Intel, Meta, Microsoft.
• AI 워크로드용 Ethernet 표준.
• InfiniBand 대안.
• 2025+ 제품.

CXL (Compute Express Link)

CXL: 차세대 인터커넥트.

• CPU ↔ Memory ↔ Accelerator.
• Cache coherent.
• 원격 메모리를 로컬처럼.

CXL 3.0: 원격 메모리 풀링. RDMA를 넘어선 모델.

Optical Networking

광전 변환:

• 초고속, 저전력.
• 미래의 데이터센터.
• 실리콘 포토닉스.

In-Network Computing

NIC에서 일부 연산:

• NVIDIA BlueField DPU.
• AMD Pensando.
• AWS Nitro.

SmartNIC: RDMA + 프로그래머블 처리.

퀴즈로 복습하기

마치며: 보이지 않는 고속도로

핵심 정리

1. RDMA: Zero-copy + kernel bypass. 원격 메모리 직접 접근.
2. InfiniBand: 원조. 최고 성능. 전용 네트워크.
3. RoCE: Ethernet 기반. 운영 복잡하지만 비용 낮음.
4. NCCL: GPU collective operations. AI 학습의 표준.
5. GPU Direct: GPU ↔ NIC 직접.
6. 3D Parallelism: DP + TP + PP로 거대 모델 학습.

중요한 관점

RDMA는 AI 인프라의 숨은 기반이다. 사용자는 ChatGPT와 대화할 때 RDMA를 모른다. 하지만 모델 학습 단계에서 수십억 번의 RDMA 연산이 이루어졌다.

AI가 더 발전할수록 네트워크의 중요성이 커진다. 계산 능력과 네트워크 대역폭의 격차가 병목이 된다. Ultra Ethernet, CXL, Optical 같은 차세대 기술이 이를 해결하려 한다.

언제 필요한가

RDMA가 필요한 경우:

• 대형 AI 학습.
• HPC 시뮬레이션.
• 고빈도 거래.
• 분산 데이터베이스 (일부).
• 대규모 분산 스토리지.

필요 없는 경우:

• 일반 웹 애플리케이션.
• 작은 규모 배치.
• 대부분의 엔터프라이즈 워크로드.

대부분의 엔지니어가 직접 RDMA를 다루지 않는다. 하지만 그것이 존재한다는 사실과 원리를 이해하면, 현대 컴퓨팅의 큰 그림이 보인다.

마지막 교훈

GPT-4, Gemini, Claude — 우리가 매일 쓰는 AI들. 이들의 학습에는 수천, 수만의 GPU + RDMA 네트워크가 필요했다. 한 대의 GPU도, 한 번의 통신도 없었다면 지금의 AI는 없었다.

RDMA는 작지만 결정적인 조각이다. 알려지지 않은 기술이 혁명을 가능하게 한 경우는 많다. 인터넷의 TCP, 웹의 HTTP, 데이터의 SQL처럼, AI의 RDMA.

당신이 다음에 LLM에게 질문할 때, 그 답변의 뒤에 10만 GPU가 RDMA로 대화한 역사가 있음을 기억해 보자. 기술의 계층은 깊고, 각 층이 다음 층을 가능하게 한다. 이것이 현대 컴퓨팅의 경이로움이다.

참고 자료

• InfiniBand Trade Association
• NVIDIA Networking
• OpenFabrics Alliance
• RDMA Programming Tutorial
• NCCL Documentation
• CUDA Programming Guide
• Ultra Ethernet Consortium
• AWS EFA Documentation
• Azure HPC
• Tal Ben-Nun and Torsten Hoefler: Demystifying Parallel and Distributed Deep Learning (2018)
• Mellanox Academy