제4부 데이터센터와 스케일

4.12 스케일아웃 네트워킹 II — GPUDirect RDMA·스토리지

4.12.1 이 장에서 배우는 것 / 선수 지식

4.11가 네트워크 패브릭(IB·Spectrum-X)이었다면, 이 장은 그 위에서 데이터가 GPU 메모리에 닿는 경로다. 전통적으로 외부 데이터(다른 노드·스토리지)는 CPU·호스트 메모리(bounce buffer)를 거쳐 GPU로 들어왔다 — 대역·CPU·지연 낭비. GPUDirect 계열은 NIC·스토리지가 GPU 메모리에 직접 접근해 호스트를 우회하게 한다: GPUDirect RDMA(NIC↔GPU), GPUDirect Storage(스토리지↔GPU), 그리고 데이터 경로를 오프로드하는 BlueField DPU. NCCL(4.13)·데이터 로딩(3.8)의 대규모 성능이 여기 달렸다.

배우는 것:

bounce buffer 문제 — 외부 데이터가 호스트를 거쳐 GPU로 가는 전통 경로의 낭비.
GPUDirect RDMA — NIC가 GPU 메모리를 직접 read/write(호스트 우회)해 노드 간 GPU 통신을 가속(NCCL의 토대).
GPUDirect Storage(GDS) — 스토리지가 GPU 메모리로 직접 DMA, 데이터 로딩의 CPU 병목 제거.
GPU-NIC 친화도(rail-optimized) 와 BlueField DPU의 역할.

선수 지식: 2.5(pinned·H2D 전송 — bounce buffer의 뿌리), 4.6(GPUDirect P2P — GPU↔GPU 버전), 4.11(IB·RDMA·패브릭), 3.8(데이터 로딩·GPU 기아 — GDS가 푸는 병목), 4.13(NCCL — GPUDirect RDMA 사용). 환경은 0.3. GPUDirect 가용성·성능은 GPU·NIC·드라이버·스토리지·플랫폼 의존 → 확인 필요. 이 장은 데이터 경로에 집중.

4.12.2 동기 — bounce buffer 문제

외부 데이터(원격 노드 GPU, 스토리지)가 내 GPU로 들어오는 전통 경로는 호스트 메모리를 경유한다:

낭비: ① 데이터가 PCIe·호스트 RAM을 한 번 더 거침(대역·지연 2배), ② CPU가 복사·관리에 매여(CPU 병목), ③ 호스트 RAM 대역폭을 소모(다른 일과 경쟁).

대규모에서 이 bounce가 치명적이다 — 노드 간 GPU 통신(NCCL)·대용량 데이터 로딩이 전부 호스트를 거치면, GPU·네트워크가 빨라도 호스트·PCIe가 천장이 된다.

GPUDirect의 답: 외부 장치(NIC·스토리지·다른 GPU)가 GPU 메모리에 직접 DMA — 호스트 RAM bounce를 건너뛴다.

공통: GPU 메모리를 'DMA 가능한 1급 목적지'로 만들어 호스트를 건너뛴다.

4.12.3 GPUDirect RDMA — NIC가 GPU 메모리를 직접

GPUDirect RDMA는 네트워크 카드(NIC)가 원격 GPU의 HBM을 직접 read/write하게 한다(호스트 RAM·CPU 우회). 4.11의 RDMA를 GPU 메모리까지 확장한 것.

왜 결정적: NCCL(4.13)의 노드 간 집합연산이 이 위에서 동작한다. 다노드 all-reduce에서 그래디언트가 호스트를 거치면 PCIe·CPU 병목으로 확장이 안 된다. GPUDirect RDMA로 NIC가 GPU HBM을 직접 운반하면 노드 간 통신이 네트워크 대역(4.11)에 가깝게 — 대규모 학습 확장성의 토대.

GPU-NIC 친화도가 핵심. GPUDirect RDMA가 빠르려면 GPU와 NIC가 PCIe 상에서 가까워야(같은 스위치·소켓) 한다. 멀면(다른 소켓·여러 홉) 효과가 준다 — rail-optimized 설계(4.12.5)의 이유.

4.12.4 GPUDirect Storage — 스토리지가 GPU로 직접

GPUDirect Storage(GDS) 는 스토리지(로컬 NVMe·네트워크 스토리지)가 GPU 메모리로 직접 DMA하게 한다 — 데이터 로딩(3.8)의 호스트 bounce를 제거.

왜 중요: 대규모 학습·추론은 막대한 데이터를 스토리지에서 읽는다(대용량 코퍼스·체크포인트·임베딩). 이것을 CPU·호스트 RAM으로 bounce하면 CPU가 병목이고(3.8의 입력 바운드), 호스트 RAM 대역을 소모한다. GDS는 데이터를 스토리지에서 GPU로 직행시켜:

CPU 부하·호스트 RAM 사용↓, 데이터 로딩 처리량↑.
체크포인트 로드·대용량 임베딩·과학 데이터 등 I/O 집약 워크로드에 효과적.

GDS API는 cuFile(개략):

#include <cufile.h>
// GPU 버퍼를 cuFile에 등록하고, 파일에서 GPU 메모리로 직접 읽기
cuFileBufRegister(gpu_ptr, size, 0);
CUfileHandle_t fh; /* cuFileHandleRegister로 파일 핸들 */
cuFileRead(fh, gpu_ptr, size, file_offset, 0);  // 스토리지 → GPU HBM 직접(호스트 우회)
// DALI(3.8)·프레임워크가 내부적으로 GDS 경로를 쓰기도(시점 의존)

4.12.5 rail-optimized 토폴로지와 BlueField DPU

GPU-NIC 친화도(rail-optimized). 대규모 GPU 서버는 각 GPU에 가까운 NIC를 짝지어 둔다. GPU가 자기 짝 NIC로 통신하면 GPUDirect RDMA가 최단 PCIe 경로로 빠르다. 클러스터 패브릭(4.11 fat-tree)을 rail 별로(GPU0들끼리, GPU1들끼리…) 구성하면 노드 간 통신이 균형 잡힌 경로로 흐른다.

각 GPU가 가까운 NIC와 짝지어 GPUDirect가 최단 경로를 타고, 모든 노드의 GPU0↔NIC0가 같은 rail로 묶여 노드 간 통신이 rail별로 균형을 이뤄 혼잡이 준다(4.11 적응 라우팅과 결합). 친화도를 무시해 GPU가 먼 NIC로 통신하면 PCIe 여러 홉·소켓 횡단으로 GPUDirect 이득이 감소한다.

nvidia-smi topo -m으로 GPU-NIC 친화도(어느 GPU가 어느 NIC에 PIX/가까운지)를 확인하고, NCCL·앱이 올바른 NIC를 쓰게 한다.

BlueField DPU(Data Processing Unit). SmartNIC을 넘어, 네트워킹·스토리지·보안·데이터 경로를 CPU에서 오프로드하는 프로세서. 호스트 CPU가 데이터 이동·프로토콜·격리에 매이지 않게 하고(인프라 기능을 DPU가 수행), Spectrum-X(4.11)의 SuperNIC·혼잡 제어·멀티테넌트 격리를 담당하기도 한다. 요지: 데이터 경로를 CPU에서 떼어 전용 프로세서로 — GPU는 연산, DPU는 인프라.

4.12.6 워크스루 — 경로 확인·진단

1) GPU-NIC 친화도 확인.

nvidia-smi topo -m
#  GPU와 NIC(mlx5_0 등) 간 연결 표시: PIX(같은 PCIe 스위치, 최선) / PHB / SYS(소켓 횡단, 나쁨)
#  각 GPU의 '가까운 NIC'를 파악 → NCCL이 그 NIC를 쓰게(아래)

2) GPUDirect RDMA 사용 여부(NCCL).

# NCCL 디버그로 어떤 전송을 쓰는지 (4.13)
NCCL_DEBUG=INFO python train.py 2>&1 | grep -i -E 'NET|GDR|IB|Ring'
#  'GDRDMA' / 'GPU Direct RDMA' 같은 로그가 보이면 직접 경로 사용
#  안 보이면 호스트 bounce 가능 → 드라이버·nvidia-peermem 모듈·친화도 점검
NCCL_IB_HCA=mlx5_0,mlx5_1   # 사용할 IB NIC 지정(친화도에 맞춰)

3) GDS 사용 여부.

# GDS 설치·상태 확인 (cuFile)
gdscheck -p              # GDS 플랫폼 점검(지원·드라이버·호환)
# 데이터 로딩이 GDS 경로를 타는지 프로파일(2.13)로 호스트 RAM 트래픽·CPU 부하 비교

진단 흐름. 다노드 학습이 느리거나 데이터 로딩이 CPU 바운드면:

4.12.7 중간 점검 (체크포인트)

[ ] bounce buffer 문제(외부 데이터가 호스트·PCIe를 거치는 낭비)를 설명한다.
[ ] GPUDirect RDMA가 NIC↔GPU 직접 경로로 노드 간 GPU 통신(NCCL)을 가속함을, GPU-NIC 친화도가 중요함을 안다.
[ ] GPUDirect Storage가 스토리지↔GPU 직접 DMA로 데이터 로딩 CPU 병목을 제거함을 안다.
[ ] rail-optimized 친화도·BlueField DPU의 역할을 말하고, topo -m·NCCL_DEBUG로 경로를 진단한다.

증상→의심: 다노드 학습이 단노드 대비 확장 안 됨 → GPUDirect RDMA 미사용(호스트 bounce, NCCL_DEBUG·peermem 점검) 또는 GPU-NIC 친화도 나쁨. 데이터 로딩 CPU 100%·GPU 기아 상태 → 호스트 bounce I/O(GDS·DALI GPU 경로, 3.8). NCCL이 느린 NIC 사용 → 친화도 무시(NCCL_IB_HCA 지정). GDS가 효과 없음 → 플랫폼·스토리지 미지원(gdscheck).

4.12.8 트레이드오프·맥락

경로	우회 대상	효과	의존
GPUDirect P2P(4.6)	호스트(GPU↔GPU)	노드 내 GPU 통신	NVLink/PCIe P2P
GPUDirect RDMA	호스트(NIC↔GPU)	노드 간 GPU 통신(NCCL)	NIC·peermem·친화도
GPUDirect Storage	호스트(스토리지↔GPU)	데이터 로딩·체크포인트	스토리지·플랫폼 지원
BlueField DPU	CPU(인프라 경로)	네트워킹·보안·격리 오프로드	DPU 하드웨어

견해: GPUDirect는 대규모에서만 진가가 난다. 단노드·작은 워크로드는 호스트 bounce가 병목이 아닐 수 있어 이득이 작다. 다노드 학습(GPUDirect RDMA로 NCCL 가속)과 I/O 집약 로딩(GDS)에서 크다. 대부분 NCCL·프레임워크·DALI가 자동으로 GPUDirect를 쓰니, 우리 몫은 드라이버(nvidia-peermem)·친화도·플랫폼 지원이 갖춰져 실제로 직접 경로가 쓰이는지 확인하는 것 — 조용히 호스트 bounce로 폴백하면 대규모에서 손해.

비NVIDIA 정직: "장치가 가속기 메모리에 직접 DMA(호스트 우회)"는 보편 방향이다 — PCIe P2P, CXL, 다른 가속기의 직접 경로, NVMe-oF 등이 같은 문제를 푼다. GPUDirect는 그 NVIDIA 구현(+CUDA·NCCL·cuFile 통합)이고, 가용성은 하드웨어·드라이버·플랫폼 조합에 민감하다. 직접 경로가 실제로 동작하는지는 항상 실측·로그로 확인.

4.12.9 흔한 함정

GPUDirect가 자동으로 켜진다고 가정. 드라이버·nvidia-peermem 커널 모듈·NIC·플랫폼이 맞아야 한다. 안 갖춰지면 조용히 호스트 bounce로 폴백하고 대규모에서 느려진다. NCCL_DEBUG로 확인.
GPU-NIC 친화도 무시. GPU가 먼 NIC(소켓 횡단 SYS)로 통신하면 GPUDirect RDMA 이득이 준다. topo -m으로 짝 NIC를 확인하고 NCCL에 지정.
GDS를 만병통치로 기대. GDS는 스토리지·파일시스템·플랫폼이 지원해야 하고, 작은·임의 접근보다 대용량 순차에 유리. 지원·접근 패턴을 확인(gdscheck).
단노드에서 GPUDirect 효과 기대. 노드 간 통신·대용량 I/O가 없으면 호스트 bounce가 병목이 아니라 이득이 작다 — 대규모·I/O 집약에서 의미.
호스트 RAM·CPU를 무한으로 가정. bounce 경로는 호스트 RAM 대역·CPU를 소모해 다른 일(전처리, 3.8)과 경쟁. 직접 경로로 호스트를 비워야 전체가 산다.
DPU를 단순 NIC로 취급. BlueField는 인프라·보안·격리를 오프로드하는 프로세서다. 멀티테넌트 격리·Spectrum-X 기능이 DPU에 의존할 수 있어, 단순 NIC로 대체하면 그 기능이 빠진다.

4.12.10 연습문제

연습 1 (경로 비교). 다노드 all-reduce에서 (a) GPUDirect RDMA 없이, (b) 있이의 데이터 경로를 각각 그리고, (b)가 빠른 이유를 호스트·PCIe·CPU 관점에서 설명하라.

정답

(a) 없이: GPU0 HBM →PCIe→ 호스트 RAM →NIC→ 네트워크 →NIC→ 호스트 RAM →PCIe→ GPU1 HBM — 양쪽에서 호스트 RAM bounce, PCIe 2회·CPU 관여, 호스트 RAM 대역 소모. (b) 있이: GPU0 HBM →NIC→ 네트워크 →NIC→ GPU1 HBM — NIC가 GPU HBM을 직접 read/write, 호스트 우회. 빠른 이유: 호스트 RAM·PCIe bounce를 건너뛰어 대역 낭비·추가 지연 제거, CPU가 복사에서 해방, 호스트 RAM 대역을 안 씀. 노드 간 통신이 네트워크 대역(4.11)에 가까워져 대규모 학습이 확장된다(NCCL).

연습 2 (GDS 적용). 학습이 데이터 로딩에서 CPU 100%·GPU 기아(3.8)이고, 데이터는 고속 NVMe에 있다. GPUDirect Storage가 어떻게 돕는지, 그리고 적용 전 확인할 것.

정답

도움: 현재 스토리지 데이터가 NVMe → CPU → 호스트 RAM → PCIe → GPU로 들어와 CPU·호스트 RAM이 병목(input-bound). GDS는 NVMe ──직접 DMA──▶ GPU HBM로 CPU·호스트 RAM을 우회 → CPU 부하·RAM 대역 소모가 줄고 로딩 처리량↑ → GPU 기아 완화. 확인: ① gdscheck로 플랫폼·드라이버·파일시스템 GDS 지원, ② 접근 패턴이 GDS에 유리한지(대용량 순차 유리, 작은 임의 접근은 덜), ③ 데이터 경로(cuFile·DALI의 GDS 경로)가 실제로 직접 DMA를 타는지 프로파일로, ④ 입력 바운드임을 먼저 증명(3.8 고정배치 실험).

연습 3 (친화도 진단). 8-GPU 다노드 학습이 기대보다 느리다. nvidia-smi topo -m에서 GPU0–NIC가 SYS로 나온다. 문제와 해결.

정답

문제: GPU0이 통신에 쓰는 NIC가 소켓을 횡단(SYS) 하는 먼 경로 — GPUDirect RDMA가 PCIe 여러 홉·소켓을 거쳐 대역·지연이 나빠지거나 호스트 경유로 폴백. 해결: ① topo -m으로 각 GPU의 가까운 NIC(PIX/PXB)를 찾아 GPU-NIC를 올바로 짝짓고(rail-optimized), ② NCCL이 그 NIC를 쓰게 NCCL_IB_HCA로 지정, ③ NCCL_DEBUG=INFO로 GPUDirect RDMA(GDRDMA)가 실제 쓰이는지·올바른 NIC인지 확인, ④ nvidia-peermem 모듈·드라이버가 로드됐는지 점검. 친화도를 맞추면 노드 간 통신이 최단 경로로 빨라진다.

4.12.11 요약 · 다음 장

전통 경로는 외부 데이터가 호스트 RAM bounce를 거쳐 GPU로 와 대역·CPU·지연을 낭비한다. GPUDirect는 NIC·스토리지·다른 GPU가 GPU 메모리에 직접 DMA하게 해 호스트를 우회한다.
GPUDirect RDMA(NIC↔GPU 직접)는 노드 간 GPU 통신(NCCL)의 토대 — 대규모 학습 확장성. GPUDirect Storage(스토리지↔GPU 직접)는 데이터 로딩 CPU 병목 제거.
GPU-NIC 친화도(rail-optimized) 가 GPUDirect 효율을 좌우하고, BlueField DPU가 데이터 경로·인프라를 CPU에서 오프로드한다.
직접 경로는 보통 NCCL·프레임워크·DALI가 자동 사용 — 우리 몫은 드라이버·친화도·플랫폼이 갖춰져 실제로 직접 경로가 쓰이는지(topo -m·NCCL_DEBUG·gdscheck) 확인. 조용한 호스트 bounce 폴백이 대규모의 적.

다음 장: 4.13 NCCL I — 집합연산 원리·알고리즘. 지금까지 쌓은 NVLink·네트워크·GPUDirect 위에서 실제로 실행되는 집합 통신 라이브러리다. all-reduce·all-gather·reduce-scatter 같은 집합연산이 무엇이고, ring·tree 알고리즘이 토폴로지·대역폭에 어떻게 매핑되는지 — 분산 학습 통신의 기본기를 익힌다.