LabHub

한국어

시작하기
블로그

블로그

RDMA와 NCCL로 읽는 GPU 네트워크: InfiniBand, RoCE, 쿠버네티스 배치

2026-10-07 · 41 분 읽기 · #RDMA#InfiniBand#RoCE#NCCL#GPUDirect#NVLink#쿠버네티스#NetworkOperator#토스 ML/AI Infra 준비

상태: 초안 (2026-10-06 갱신). 공식 문서로 확인한 서술이 바탕이고, 소프트웨어 RoCE(rxe)로 직접 본 부분(10절 끝의 「실측」)만 일회용 가상 머신에서 잰 값입니다. 실제 RDMA 하드웨어와 GPU 를 쓴 측정은 없습니다. 글 끝의 「확인한 버전과 날짜」와 「확인하지 못한 것」을 먼저 읽으십시오. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.

목차

요약

GPU 여러 장이 한 모델을 함께 계산하면 통신이 곧 성능입니다. 서버 안에서는 NVLink 가, 서버 사이에서는 RDMA(Remote Direct Memory Access)를 지원하는 InfiniBand 나 RoCE(RDMA over Converged Ethernet) 망이 이 일을 맡고, NCCL(NVIDIA Collective Communications Library)은 이 계층을 감지해 집합 통신(all-reduce 등)을 배치합니다. 이 글은 계층별 대역폭 차이, RoCE 가 어려운 이유, NCCL 환경변수와 측정 도구, 장애 진단 순서, 쿠버네티스 구성을 다룹니다.

이 글을 읽고 나면 면접에서 설명할 수 있는 것

  1. TCP 로는 부족한 이유와, InfiniBand 와 RoCE v2 의 차이(특히 RoCE 에서 PFC, ECN 이 하는 일과 설정이 틀렸을 때의 증상).
  2. NCCL 이 집합 통신을 어떻게 수행하는지, nccl-tests 의 busbw 를 어떻게 읽는지, 멀티노드 성능이 떨어졌을 때 점검하는 순서.
  3. 쿠버네티스에서 파드가 RDMA 를 쓰는 데 필요한 구성 요소와, 추론에서 RDMA 가 필요한 지점(KV 전송, 전문가 병렬, 모델 로딩).

글쓴이의 위치. 저는 일반 이더넷(1~2.5GbE 급) 환경에서 실험하고 있으며 RDMA, InfiniBand, NVLink, VAST 경험이 없습니다. 이 글은 공식 문서를 읽고 정리한 것이며 운영 경험담이 아닙니다. 직접 해 보기는 가능한 범위로 한정했고, 실행해 보지 않은 것은 그렇게 표시했습니다.

1. 왜 TCP 로는 부족한가

Dynamo 문서에 따르면 RDMA 는 네트워크 어댑터가 한 호스트의 메모리에서 다른 호스트의 메모리로(GPUDirect RDMA 를 쓰면 GPU 에서 GPU 로) CPU, 커널, TCP/IP 스택을 거치지 않고 데이터를 옮기게 합니다. 일반적으로 TCP 는 사용자 버퍼와 커널 버퍼 사이 복사, 시스템 호출, 인터럽트가 따릅니다. RDMA 는 미리 등록(ibv_reg_mr)해 페이지를 고정(pin)해 둔 메모리를 NIC 가 직접 읽고 쓰므로 커널 우회(kernel bypass)와 제로카피(zero-copy)가 가능합니다. 속도 차이도 산술로 큽니다. 1GbE 는 0.125GB/s, 400Gb/s NIC 는 50GB/s 로 400배입니다. 그래서 TCP 는 RDMA 가 없을 때의 대체 경로입니다(NCCL_IB_DISABLE=1 이면 NCCL 이 IP 소켓으로 내려갑니다).

2. InfiniBand 와 RoCE v2

항목 InfiniBand RoCE v2
망 RDMA 전용 망 일반 이더넷 스위치 위에서 동작
프로토콜 자체 전송 계층 UDP/IP 목적지 포트 4791 위에 올라 L3 라우팅 가능
관리 서브넷 매니저(SM) 필요 PFC, ECN, DSCP 등 이더넷 설정이 핵심
진단 ibstat, perfquery, ibdiagnet, sminfo ethtool -S, 스위치 카운터, rping

RoCE v1 은 이더넷 링크 계층만 쓰는 단일 브로드캐스트 도메인용이고, v2 가 UDP/IP 를 얹어 라우팅이 됩니다(Wikipedia).

RoCE 가 어려운 이유. RDMA 는 패킷 손실에 약하므로 이더넷에서는 손실을 막거나 줄여야 합니다. NVIDIA Cumulus 문서는 두 수단을 설명합니다. PFC(Priority Flow Control)는 우선순위별로 홉 단위 일시 정지를 걸어 버퍼 넘침을 막고, ECN(Explicit Congestion Notification)은 스위치가 혼잡한 패킷에 표시를 하면 수신 NIC 가 CNP(Congestion Notification Packet)를 돌려보내 송신 속도를 낮추게 합니다. 기본 설정에서 RoCE 데이터는 우선순위 3, CNP 는 우선순위 6 의 엄격 우선 큐를 씁니다. Onyx 문서는 무손실(망 전체 PFC), 반무손실(호스트와 랙 상단 스위치 사이만 PFC), 손실(PFC 없음) 모드를 구분합니다. DCQCN(SIGCOMM 2015)은 PFC 의 부작용을 줄이려는 ECN 기반 RoCE v2 혼잡 제어로, 초록에 따르면 Mellanox NIC 에 구현되어 Microsoft 데이터센터에 배포 중입니다. DCQCN 이 PFC 를 대체하는 것은 아닙니다. 논문 7절은 손실률이 0.1% 를 넘으면 처리량이 급감하므로 PFC 가 여전히 필요하다고 적습니다. PFC 는 망 전체 교착을 일으킬 수 있고(Microsoft 의 2016년 논문이 시험 클러스터에서 MAC 주소를 모르는 패킷의 플러딩과 PFC 가 얽혀 교착이 실제로 생긴 사례와, NIC 하나가 PAUSE 를 계속 내보내 망 전체를 막은 사고를 보고합니다. 아래 「외부 근거」) 이더넷 DCB 구성이 InfiniBand 보다 복잡하다는 평가가 있습니다(Wikipedia).

실패는 조용히 나타납니다. MinIO MemKV 런북(NVIDIA 문서가 아닌 제3자 자료)은 PFC 우선순위, DSCP 매핑, MTU 가 서로 맞아야 하고, 이더넷 MTU 1500 이면 RoCE 활성 MTU 가 1024 로 협상되며, 어긋나면 IBV_WC_RETRY_EXC_ERR 로 끝나는데 노드 사이에서만 드러난다고 적습니다.

3. 계층과 대역폭

 노드(예: 8 GPU)
 GPU0 ... GPU7 ══ NVLink / NVSwitch ══ (노드 안 전체 연결)
   │PCIe          │PCIe
  NIC0    ...    NIC7 ──> 같은 번호 NIC 끼리 같은 리프 스위치 (rail)
계층 대역폭 출처와 단위
NVLink 4세대(H100) GPU 당 900GB/s NVIDIA 사양, 양방향 합계
NVLink 5세대(Blackwell) GPU 당 1,800GB/s 같은 쪽 표기
PCIe 5.0 x16 레인당 32GT/s, 방향당 약 63GB/s 32GT/s 는 Rambus 문서, 63GB/s 는 128b/130b 인코딩을 가정한 글쓴이 계산
ConnectX-7 한 장 400Gb/s, 방향당 50GB/s NVIDIA. DGX H100 은 계산용 InfiniBand 카드 8장
일반 이더넷 0.125~0.31GB/s 1GbE, 2.5GbE 이론값

NVLink 4세대를 방향당(절반)으로 환산하면 약 450GB/s 로 NIC 한 장의 약 9배입니다(글쓴이 환산). DeepSeek-V3 보고서의 H800 클러스터도 NVLink 160GB/s 대 InfiniBand 50GB/s 였고, 이 격차가 6편의 "TP 는 노드 안, PP 와 EP 는 노드 사이" 경향을 낳습니다. NVL72 같은 시스템은 72개 GPU 가 한 NVLink 도메인이라 경계가 달라집니다. rail 구조는 DGX SuperPOD 참조 아키텍처에서 확인했으며, 각 서버의 같은 번호 NIC 를 같은 리프 스위치에 연결해 같은 rail 의 서버끼리는 스위치 한 개만 거치게 합니다.

4. GPUDirect RDMA 와 GPUDirect Storage

GPUDirect RDMA 는 NIC 가 GPU 메모리를 직접 읽고 써서 호스트 메모리 경유를 없앱니다. 공식 문서의 전제는 두 장치가 같은 PCIe 루트 컴플렉스를 공유하고 사이에 PCIe 스위치만 있을 때 최적이며(QPI/UPI 를 건너면 저하), IOMMU 가 꺼져 있거나 1:1 통과여야 한다는 것입니다. NCCL 문서는 nvidia-peermem 모듈을 부팅마다 올리거나 오픈 소스 드라이버의 DMA-BUF 경로를 쓰라고 안내하고(미적재와 ACS 도 흔한 원인), NCCL_NET_GDR_LEVEL 로 NIC 와 GPU 사이 최대 거리(LOC, PIX, PXB, PHB, SYS)를 제한합니다.

GPUDirect Storage(GDS)는 저장소와 GPU 메모리 사이 DMA 로 CPU 바운스 버퍼를 없애며, cuFile API 와 로컬 NVMe, NVMe-oF, Lustre, WekaFS, NFS over RDMA 를 지원합니다. 조건이 안 맞으면 CPU 메모리를 거치는 호환 모드로 내려가 이득이 사라집니다.

5. NCCL

연산. NCCL 2.32.3 문서의 집합 연산은 AllReduce, Broadcast, Reduce, AllGather, ReduceScatter, AlltoAll, Gather, Scatter 이고 점대점 send/recv 도 있습니다. 모든 rank 가 같은 count 와 datatype 으로 호출해야 하며, 어긋나면 행, 충돌, 데이터 손상 같은 정의되지 않은 동작이 생깁니다.

알고리즘과 토폴로지. NCCL_ALGO 문서가 나열하는 알고리즘은 Ring, Tree, CollnetChain, CollnetDirect, NVLS, NVLSTree, PAT 입니다(NVLS 는 NVLink SHARP 오프로드). NCCL 2.4 블로그에 따르면 링은 대역폭을 다 쓰지만 지연이 GPU 수에 비례하고, 이중 이진 트리는 대역폭을 유지하며 지연이 로그로 늘어 Summit 24,576 GPU 에서 링보다 최대 180배 지연이 개선되었다고 합니다(NVIDIA 의 측정 주장). NCCL 은 초기화 때 NVLink, PCIe, NIC 연결을 감지해 그래프를 만들고, NCCL_TOPO_DUMP_FILE 로 감지 결과를 내보냅니다.

변수 역할(문서 기준)
NCCL_DEBUG VERSION, WARN, INFO, TRACE(2.32 에서 ATTN 추가). NCCL_DEBUG_SUBSYS 로 하위 시스템 필터
NCCL_SOCKET_IFNAME 쓸 IP 인터페이스. 접두사 목록, ^ 제외, = 정확 일치
NCCL_IB_HCA 쓸 RDMA 어댑터. <hca>[:<port>] 목록, ^ 제외, = 정확 일치
NCCL_IB_DISABLE 1 이면 IB/RoCE 를 끄고 IP 소켓 등으로 대체
NCCL_NET_GDR_LEVEL NIC 와 GPU 사이 GPUDirect RDMA 허용 최대 거리
NCCL_IB_GID_INDEX, NCCL_IB_TC RoCE 의 GID 와 트래픽 클래스. 2.21 이상은 GID 자동 선택이므로 설정하지 않음
NCCL_CROSS_NIC 링과 트리가 서로 다른 NIC 를 쓰도록 허용할지. rail 최적화 망 여부에 좌우

문서는 디버깅과 튜닝 변수를 운영 설정에 남기지 말라고 경고하며, 한 벤치마크의 이득이 다른 곳에서 손해일 수 있다고 적습니다. 추론에서 NCCL 은 TP 의 층별 all-reduce 에 쓰이고, EP 는 백엔드(allgather_reducescatter, DeepEP 등)에 따라 경로가 다릅니다. KV 전송은 NIXL/UCX 가 맡아 NCCL 변수가 적용되지 않습니다(6편).

6. 측정하는 법

./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8                    # 노드 안 GPU 8장
mpirun -np 64 -N 8 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1  # 8노드 x 8 GPU (MPI=1 빌드)
ib_write_bw -d mlx5_0 -a                       # perftest 서버
ib_write_bw -d mlx5_0 <서버주소> -a            # 클라이언트. --use_cuda=0 을 더하면 GPU 메모리 경로
ib_write_lat -d mlx5_0 <서버주소>              # 꼬리 지연 확인

nccl-tests 는 시간, algbw(크기/시간), busbw 를 출력합니다. busbw 는 연산별 보정 계수를 곱해 rank 수와 무관하게 하드웨어 한계와 비교하려는 값으로, AllReduce 는 algbw × 2(n−1)/n, ReduceScatter·AllGather·AlltoAll 은 algbw × (n−1)/n 입니다. 큰 메시지의 busbw 가 NVLink 나 NIC 이론 한계에 얼마나 가까운지를 보고, 작은 메시지에서는 시간(지연)을 봅니다. NCCL 문서의 순서는 노드 안은 nvbandwidth 와 nvidia-smi topo -m, 노드 사이는 ib_write_bw/ib_write_lat 를 먼저 보고, 이 값이 기대와 맞는데 NCCL 만 느릴 때 NCCL 설정을 의심하는 것입니다.

7. 흔한 장애

증상 확인 근거
IB 링크 강등 ibstat 의 Rate 와 Active 상태, mlxlink 의 폭과 속도 NCCL 문서
잘못된 HCA·인터페이스 UP 이지만 통신 불가인 인터페이스를 고르면 초기화 실패나 행. NCCL_SOCKET_IFNAME, NCCL_IB_HCA 지정. 로그에 NET/IB/GDRDMA 대신 NET/Socket 이면 TCP NCCL, vLLM 문서
고정 메모리 한도 ibv_create_qp, ibv_reg_mr 실패면 memlock 무제한. 쿠버네티스는 IPC_LOCK 또는 노드 단 해제 NCCL, vLLM, Dynamo 문서
RoCE GID 오류 ibv_modify_qp ... Invalid argument. 2.21 미만이면 show_gids 로 RoCE v2 GID 확인 NCCL 문서
MTU 불일치 ibv_devinfo 의 active_mtu. 노드 사이에서만 실패 제3자 런북
PFC·ECN 오설정 지연 꼬리, 처리량 불안정. ethtool -S pause·PFC 카운터와 rdma statistic 재시도 카운터를 보고, NCCL 보다 혼잡 제어를 먼저 조사 NCCL 문서
느린 링크 하나 집합 연산은 모든 rank 가 참여하므로 가장 느린 구간이 전체를 늦춥니다(글쓴이 설명). 한 rail 만 느리면 ibdiagnet NCCL 문서

8. 쿠버네티스에서의 RDMA

flowchart TB
  subgraph Node[GPU 노드]
    OFED[MOFED 드라이버<br/>ofedDriver]
    PEER[nvidia_peermem<br/>GPU Operator]
    DP[RDMA 공유 디바이스 플러그인]
    MUL[Multus + NetworkAttachmentDefinition]
  end
  OFED --> DP
  DP -->|rdma/hca_shared_devices_a 광고| KL[kubelet]
  KL --> Pod[파드: GPU + rdma 자원 + 보조 인터페이스 net1]
  MUL --> Pod
  PEER --> Pod

NVIDIA Network Operator(최신 v26.4.2, 2026-09-16)는 NicClusterPolicy(README 표기는 NICClusterPolicy, 이름은 nic-cluster-policy 로 고정) 하나로 하위 구성을 켭니다. 항목은 MOFED 드라이버 컨테이너(ofedDriver), rdmaSharedDevicePlugin, sriovDevicePlugin, secondaryNetwork(Multus, containernetworking 플러그인, IPoIB CNI), nvIpam, nicConfigurationOperator 등이며, MacvlanNetwork, HostDeviceNetwork, IPoIBNetwork CRD 가 NetworkAttachmentDefinition 으로 변환됩니다.

9. 추론에서 RDMA 가 필요한 지점 (6편과 연결)

지점 통신 근거
KV 캐시 전송 NIXL(UCX)로 prefill 에서 decode 로 GPU-to-GPU. NCCL 이 아님 Dynamo RDMA, vLLM NixlConnector 문서
전문가 병렬 층마다 all-to-all. DeepSeek-V3 는 decode 에서 IB 점대점과 IBGDA 로 지연을 줄임 DeepSeek-V3, vLLM EP 문서
노드를 넘는 TP 층마다 all-reduce이므로 InfiniBand 같은 고속 어댑터가 바람직(vLLM 문서의 표현은 「preferably」). 노드 사이 TP 의 확장성이 나쁘다는 측정도 있음(아래 「외부 근거」) vLLM 병렬화 문서, Singhania 외 2026
대형 모델 로딩 공유 저장소와 GDS. Dynamo 는 70B 초과 모델을 파드마다 내려받으면 수 시간이라고 경고 Dynamo 설치, GDS 문서

NVIDIA 의 Dynamo 문서는 TCP 로 KV 를 옮기면 TTFT 가 약 98초, RDMA 면 200~500ms 라고 적습니다. 문서 세트 안에 조건이 있습니다. 98초는 Llama-3.1-8B, 입력 8,000토큰, AWS p5.48xlarge 에서 EFA 파드의 NIXL 이 UCX 의 느린 경로로 조용히 떨어졌을 때의 측정값이고, 200~500ms 는 같은 문서가 「사양 기반 기대치」라고 표시한 값입니다(같은 조건의 EFA 에서 실제로 잰 KV 전송 추가분은 37ms). 일반적인 TCP 대 RDMA 의 대비로 읽으면 안 됩니다(6편 「외부 근거」).

10. 직접 해 보기

RDMA 하드웨어가 없으므로 소프트웨어와 TCP 범위입니다. 1, 2번은 직접 실행하지 않았고, 3번(소프트웨어 RoCE)은 아래 「실측」에서 직접 실행한 결과를 적었습니다.

  1. iperf3 로 이더넷 한계 확인. 두 서버에서 iperf3 -s 와 iperf3 -c <서버> -P 4 -t 10 을 실행해 위 표의 1GbE, 2.5GbE 이론값과 비교합니다. 컨트롤 플레인(etcd) 노드는 피하고 한가한 시간에 합니다. 직접 실행한 결과: 서로 다른 세 쌍의 노드(파드 네트워크, 10초)에서 단일 스트림이 894~902Mbit/s, 4개 스트림이 901~912Mbit/s 로 모두 같았고(재전송 0), 1GbE 선속도의 약 90~91%(약 112MB/s)입니다. 이 망으로 KV 를 옮기면 8,000토큰(토큰당 114,688바이트의 1.7B 모델이면 약 917MB)에 약 8초, 토큰당 256KiB 인 32B 모델이면 약 2.1GB 에 약 19초입니다(계산). 같은 1.7B 모델이 8GB급 GPU 에서 8,000토큰의 입력 처리에 약 1초(8.2k tok/s, 21편)가 걸리므로, 이 망에서는 KV 를 옮기는 것보다 다시 계산하는 편이 빠릅니다(14편, 21편의 측정과 이 계산의 비교).
  2. TCP 소켓 NCCL. GPU 가 한 장씩인 두 서버(예: hostA, hostB)에서 MPI=1 로 빌드한 nccl-tests 를 호스트에서 직접 mpirun 합니다. 다른 워크로드가 GPU 를 쓰고 있지 않은지 먼저 확인합니다.
    mpirun -np 2 -H hostA:1,hostB:1 -x NCCL_IB_DISABLE=1 -x NCCL_SOCKET_IFNAME=<인터페이스> \
  -x NCCL_DEBUG=INFO ./build/all_reduce_perf -b 8 -e 256M -f 2 -g 1
    예상은 소켓 전송이 로그에 보이고 큰 메시지의 busbw 가 링크 속도(1GbE 면 0.125GB/s)를 넘지 못하는 것이며 실측이 아닙니다. GPU 한 장짜리 단일 노드는 통신 상대가 없어 의미가 없습니다.
  3. 소프트웨어 RoCE(rxe)로 verbs 흐름 보기. RHEL 문서에 따르면 Soft-RoCE 는 기술 미리보기이고 RHEL 10 에서 제거 예정입니다. 성능은 CPU 가 좌우해 숫자에 의미가 없고, 장치 열거, 포트 상태, MTU 같은 개념을 확인하는 용도입니다. 커널 모듈과 RDMA 장치를 만들므로 운영 중인 노드가 아닌 일회용 VM 에서 합니다.
    sudo rdma link add rxe0 type rxe netdev <이더넷 인터페이스>
rdma link show; ibv_devices; ibv_devinfo -d rxe0 | grep -E "state|active_mtu"
ib_write_bw -d rxe0 -a          # VM 두 대에 rxe 를 만들고 서버/클라이언트로
sudo rdma link delete rxe0      # 정리 (man rdma-link 로 확인)

실측: 소프트웨어 RoCE(rxe)로 verbs 흐름과 장애 두 가지를 재현

환경. 일회용 가상 머신(4 vCPU, 4GiB, 리눅스 6.8, 가상 NIC 의 MTU 1500) 한 대 안에서 서버와 클라이언트를 모두 돌렸습니다(자기 주소로 접속). rdma-core, ibverbs-utils, perftest(ib_write_bw, ib_write_lat), iperf3 를 설치했습니다. 기본 클라우드 커널 이미지에는 rdma_rxe 모듈이 들어 있지 않아 modprobe 가 모듈을 찾지 못했고, 추가 모듈 패키지(linux-modules-extra-<커널 버전>)를 설치하니 올라왔습니다. 성능 숫자는 CPU 가 좌우하므로 개념 확인용입니다.

확인한 것 결과
장치 만들기 rdma link add rxe0 type rxe netdev <인터페이스> 한 줄로 ACTIVE, LINK_UP. ibv_devinfo 는 transport: InfiniBand, link_layer: Ethernet, max_mtu 4096, active_mtu 1024
GID 표 4개, 모두 RoCE v2. 링크로컬 IPv6, IPv4 를 매핑한 ::ffff:a.b.c.d, 그리고 같은 머신의 다른 인터페이스(오버레이 망)의 주소까지 한 장치의 GID 표에 올라왔습니다(커널 소스는 RDMA 가 붙은 장치와 그 상위 장치의 주소를 올린다고 합니다. 오버레이 인터페이스 flannel.1 은 VXLAN 장치이고 sysfs 에서 enp1s0 의 상위 장치(upper_flannel.1)로 보여, 이 설명과 맞습니다)
MTU 이더넷 MTU 1500 위의 장치는 active_mtu 1024, MTU 65536 인 루프백 위의 장치는 4096. 쓰기 처리량은 각각 533MB/s 와 1,643MB/s 로 3.1배(경로가 달라 엄밀한 비교는 아님)
크기별 쓰기 처리량 2B 0.30MB/s(메시지율 약 0.16Mpps), 1KiB 208MB/s, 64KiB 536MB/s, 2MiB 529MB/s 로 약 0.53GB/s 에서 포화. 작은 메시지의 메시지율은 약 0.24Mpps 가 상한
같은 경로의 TCP iperf3 단일 스트림 34.7Gbit/s(약 4.3GB/s), 4개 스트림 137Gbit/s. rxe 쓰기보다 약 8배 빠름
쓰기 지연 2B 전형값 2.09µs(같은 머신 안이라 네트워크 왕복이 없어 하드웨어 값과 비교할 수 없음)
통계 카운터 rdma statistic show link rxe0/1 에 sent_pkts, rcvd_pkts, duplicate_request, out_of_seq_request, rcvd_rnr_err, retry_exceeded_err, completer_retry_err, link_downed 등이 있음. 7절 표의 「재시도 카운터」가 실제로 있는 것을 확인
없는 장치 이름 ib_write_bw -d rxe9 → IB device rxe9 not found, Unable to find the Infiniband/RoCE device, 종료 코드 1

이 시험의 한계는 가상 머신 한 대, 소프트웨어 구현, GPU 없음입니다. 두 노드 사이의 RDMA, 실제 NIC 의 처리량과 지연, PFC 와 ECN, nccl-tests, GPUDirect RDMA 는 측정하지 못했습니다(미실측).

외부 근거: 논문과 공식 자료로 확인한 것

직접 재지 못한 RoCE 혼잡 제어와 NCCL·GPUDirect 서술, 그리고 소프트웨어 RoCE 의 성능을 1차 자료로 확인했습니다. 외부 수치는 장비와 조건이 달라 방향과 구조의 일치만 판정했습니다.

주제 자료와 확인한 위치 확인한 내용과 조건 이 글과의 관계
DCQCN Zhu 외, 「Congestion Control for Large-Scale RDMA Deployments」, SIGCOMM 2015, 1·2·6·7절 ECN 기반 종단 간 혼잡 제어를 NIC 에 구현. 40Gbps 환경에서 2KB 전송 평균 지연 TCP 25.4µs, RDMA 읽기와 쓰기 1.7µs. incast 정도 10 에서 PAUSE 메시지가 DCQCN 없이 600만 개 넘음, 사용 시 약 3,000개. 7절은 손실률 0.1% 초과 시 처리량 급감, PFC 가 필요 없어지지는 않는다고 명시 지지. 「PFC 의 부작용을 줄이는 혼잡 제어」 서술과 일치. 우리 글의 「배포되었습니다」는 초록의 「배포 중」으로 바로잡음
PFC 교착과 PAUSE 폭풍 Guo 외, 「RDMA over Commodity Ethernet at Scale」, SIGCOMM 2016, 4.2·4.3·6.2절 시험 클러스터에서 MAC 주소를 모르는 패킷의 플러딩과 PFC 상호작용으로 교착이 발생해 서버를 재시작해도 풀리지 않음. NIC 버그로 한 서버가 초당 2천 개 넘는 PAUSE 를 내 고객 서버의 절반이 영향. 99번째 지연 RDMA 90µs, TCP 700µs(반반 혼합 트래픽) 지지. 「PFC 오설정이 망 전체 문제가 된다」의 실제 사고 근거
정밀 혼잡 제어 Li 외, 「HPCC」, SIGCOMM 2019 인밴드 텔레메트리를 쓰는 속도 제어. 3KB 미만 흐름의 99번째 완료 시간 슬로다운이 DCQCN 53.9에서 HPCC 2.70(Alibaba 자체 측정, FPGA NIC 와 P4 스위치 전제) 관련. ECN 기반 방식의 한계와 PFC 의존성을 보여 줌
NCCL 흔한 장애 NCCL 2.32.3 「Networking Troubleshooting」, 「GPU troubleshooting」 ibv_create_qp·ibv_reg_mr 실패는 고정 가능 메모리 한도 문제(memlock 무제한). GID 선택이 틀리면 ibv_modify_qp ... Invalid argument, 2.21 이상은 GID 를 동적으로 고름. ACS 와 IOMMU 가 켜져 있으면 GPUDirect P2P 가 우회되어 성능 저하나 멈춤 지지. 7절 표와 이번 memlock 재현이 같은 해법과 맞음
memlock 과 권한 리눅스 커널 drivers/infiniband/core/umem.c(master, 조사일) 사용자 메모리 등록 시 RLIMIT_MEMLOCK 초과는 CAP_IPC_LOCK 이 없을 때 -ENOMEM 으로 실패 지지. root 가 한도에 걸리지 않은 이유를 설명
MTU NVIDIA MLNX_OFED v5.9 「RoCE」 문서의 ibv_devinfo 예시, 커널 rxe_param.h 이더넷 MTU 1500 인 mlx5 장치가 max_mtu 4096, active_mtu 1024. rxe 는 80바이트 헤더를 빼고 내림 지지. 위 MTU 서술을 소스 기준으로 바로잡음
GPUDirect RDMA NVIDIA 「GPUDirect RDMA」 문서 1·3.4절 NIC 와 GPU 가 같은 PCIe 루트 컴플렉스를 공유해야 하고, PCIe 스위치만 있을 때 최적, CPU 를 지나면 느리고 QPI 를 지나면 성능 제한이나 불안정. 성능 수치는 문서에 없음 지지. 4절 서술과 일치. 이점의 수치는 DCQCN, 2016 논문에 있음(CPU 사이클 20% 대 3% 미만)
소프트웨어 RoCE linux-rdma 메일링 리스트(2019, 메인테이너 진단), 커널 rxe_icrc.c, Red Hat RHEL 9 문서 soft-RoCE 약 2Gbps 대 TCP 20Gbps 보고, 패킷마다 CPU 가 ICRC(CRC32)를 계산. RHEL 문서는 기술 미리보기이며 RHEL 10 에서 제거 예정이라고 적음 제한적으로 지지. 우리 결과(rxe 쓰기 약 4.2Gbit/s, 같은 머신 TCP 약 34Gbit/s)와 같은 방향. 통제된 측정 논문은 접근 가능한 범위에서 찾지 못함
노드를 넘는 병렬화 DeepSeek-V3 기술 보고서(arXiv 2412.19437) 3.2·3.4절. Singhania 외, arXiv 2511.09557. vLLM 병렬화 문서 전문가 병렬은 토큰을 최대 4개 노드까지만 보내고 IB 후 NVLink 로 전달, decode 는 IB 점대점과 IBGDA(NVLink 160GB/s 대 IB 50GB/s). 노드 사이 TP 의 확장성이 나쁘고 decode 가 무거운 배치에서는 PP 도 TP 보다 못한 사례가 있음. vLLM 문서는 고속 어댑터가 「바람직」하다고 표현 지지. 9절 표와 일치하되 「필요」는 「바람직」으로 낮춤

접근 제한으로 열지 못한 자료(IEEE Network 2019 논문, 커널 버그질라 190951, SoftRDMA)의 수치는 쓰지 않았습니다.

11. 면접에서 나올 만한 질문

  1. TCP 대신 RDMA 를 쓰는 이유는 무엇입니까? 커널 복사와 CPU 개입 없이 NIC 가 고정된 메모리를 직접 읽고 쓰므로 지연과 CPU 부담이 줄고, GPUDirect RDMA 는 호스트 메모리 경유까지 없앱니다.
  2. InfiniBand 와 RoCE v2 중 무엇을 고르고 RoCE 의 위험은 무엇입니까? IB 는 전용 망과 SM 으로 설정이 단순하고, RoCE 는 기존 이더넷과 L3 라우팅을 쓰는 대신 PFC, ECN, DSCP, MTU 를 모두 맞춰야 합니다. 틀리면 꼬리 지연이나 노드 사이에서만의 실패로 나타나 스위치 카운터로 확인합니다.
  3. all_reduce_perf 의 busbw 가 NIC 선속도의 절반이면 어디부터 봅니까? ib_write_bw 로 NIC 자체가 선속도를 내는지, nvidia-smi topo -m 으로 GPU-NIC 거리를 보고, NCCL_DEBUG=INFO 로 선택된 전송(NET/IB, GDRDMA 여부)과 rail 구성을 확인합니다.
  4. 멀티노드 학습이 갑자기 느려지면 진단 순서는? 링크 강등(ibstat Rate), 포트 오류 카운터, 특정 rail 편중(ibdiagnet), RoCE 라면 PFC·ECN 카운터 순서로 봅니다. 하드웨어가 정상일 때만 NCCL 변수를 조정합니다.
  5. 쿠버네티스에서 파드가 RDMA 를 쓰려면 무엇이 필요합니까? MOFED 와 디바이스 플러그인(Network Operator), 파드의 rdma/... 자원 요청, nvidia_peermem, memlock 한도, 필요하면 Multus 보조 인터페이스나 SR-IOV, 그리고 GPU 와 가까운 NIC 를 받는 배치입니다.

12. 흔한 오해

참고 자료(실제로 열어 본 것)

확인한 버전과 날짜, 확인하지 못한 것

확인일은 2026-10-05 입니다. NCCL v2.32.3-1(2026-09-17), perftest 26.07.8(2026-09-28), Network Operator v26.4.2(2026-09-16), RDMA 공유 디바이스 플러그인 v1.5.4(2026-07-28), Multus v4.3.1(2026-09-08), SR-IOV 디바이스 플러그인 v3.11.0(2025-12-16)을 GitHub 릴리스 API 로 확인했고, nccl-tests 는 릴리스 없이 master(2026-10-02 커밋)를 읽었습니다.

확인하지 못한 것: (1) DCQCN 논문 본문은 이제 직접 읽었습니다(아래 「외부 근거」). (2) Network Operator README 의 시스템 요구사항(ConnectX-5, Ubuntu 20.04)은 낡아 보이며 현재 지원 매트릭스는 확인하지 못했습니다. (3) 쿠버네티스에서 GPU-NIC 짝을 맞춰 할당하는 방법. (4) rdma link delete 와 nccl-tests 예상 출력은 실행하지 않았습니다. (5) MTU 협상 규칙은 제3자 런북 기준입니다. (6) InfiniBand 링크 계층 흐름 제어와 NVLink 6세대 세부는 다루지 않았습니다. (7) 10절의 실습 세 가지는 모두 미실행입니다.

로그인하면 좋아요를 누를 수 있습니다

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다