본문으로 건너뛰기

GPU 주도 RDMA와 DeepEP로 MoE 통신 병목을 해소하는 방법과 Nebius 설정 가이드

NVSHMEM 기반 GPU-발기 RDMA와 DeepEP를 통해 Wide-EP MoE 학습에서 all-to-all 통신 병목을 줄여 256 B200 환경에서 최대 약 65%의 처리량 향상을 달성했다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

MoE의 불규칙한 all-to-all 통신은 NCCL 집단 연산에서 심각한 병목을 만들기 때문에 Nebius는 GPU가 직접 원격 메모리를 접근하는 RDMA 경로(NVSHMEM + IBGDA)와 DeepEP의 GPU-발기 커널을 통해 이 병목을 해소했다. 설치는 IBGDA·GDRCopy 커널 적용, nvidia-nvshmem 패키지 설치, DeepEP 빌드와 NVSHMEM/HCA 환경 변수 설정, memlock 한도 인상과 InfiniBand 포트 화이트리스트 선택으로 구성되며 컨테이너와 VM 환경별 절차가 제시되어 있다. TorchTitan에서 256 B200 GPU로 실행한 벤치마크는 DeepSeek-16B에서 MFU가 8.29%에서 13.64%로, DeepSeek V3-671B에서 11.22%에서 13.99%로 올라 각각 약 65%와 25%의 처리량 이득을 보였고 메모리 사용에는 의미 있는 변화가 없었다. 실제 운영에서는 NIC 선택, 커널 호환성, memlock 설정 같은 플랫폼 요인이 결과에 직접적인 영향을 주므로 환경별 재검증이 필요하다.

빠른 이해

새로운 점

GPU-발기 RDMA(NVSHMEM+IBGDA)와 DeepEP를 256 B200 환경에 적용해 DeepSeek 계열에서 최대 약 65% 처리량 향상을 확보한 실사용 벤치마크와 설치 레시피가 공개되었다.

핵심 메커니즘

입력: MoE의 불규칙한 토큰-전문가 매핑과 작은 가변 메시지; 처리: NVSHMEM의 대칭 메모리와 GPU-발기 RDMA(IBGDA)를 통해 CUDA 커널이 직접 원격 GPU 메모리에 읽기/쓰기 수행 및 DeepEP의 디스패치/컴바인 커널로 메시지 전송 회피; 출력: 집단 통신 오버헤드가 감소해 MFU와 처리량이 증가함.

핵심 수치

  • DeepSeek-16B (64 experts) MFU before: 8.29%- 벤치마크 표에 기재된 적용 전 MFU
  • DeepSeek-16B (64 experts) MFU after: 13.64%- DeepEP 적용 후 MFU, 약 65% 상대 처리량 향상
  • DeepSeek V3-671B (256 experts) MFU before: 11.22%- 벤치마크 표에 기재된 적용 전 MFU
  • DeepSeek V3-671B (256 experts) MFU after: 13.99%- DeepEP 적용 후 MFU, 약 25% 상대 처리량 향상

섹션별 상세

RDMA로 전환하는 이유

MoE는 라우터 결정에 따라 각 단계마다 전송 대상과 크기가 달라지는 불규칙한 통신 패턴을 만들기 때문에 전통적 NCCL 집단 통신이 비효율적이다. 집단 통신은 높은 처리량을 내도록 설계되어 있지만 MoE의 작은 가변 메시지에는 집단 설정과 동기화 비용이 오히려 병목으로 작용한다. 따라서 ML 연구실과 인프라 팀은 CPU 개입을 최소화하고 GPU가 직접 원격 메모리를 읽고 쓰는 RDMA 기반 점대점 전송으로 전환해 지연과 오버헤드를 줄이고자 한다.

Mixture-of-Experts와 Wide Expert Parallel의 특성

MoE는 FFN을 다수의 전문가로 분할하고 토큰마다 소수(예: top-K) 전문가만 활성화해 계산을 절감하는 설계를 채택한다. 전문가 수가 많고 EP 차수가 높아지면 각 레이어에서 수행되는 디스패치와 컴바인 단계가 모든 프로세스 간의 all-to-all 통신으로 귀결되어 메시지 수가 작업자 수의 제곱에 비례해 증가한다. 이로 인해 Wide-EP 구성을 통해 메모리와 연산 집약도를 개선하더라도 통신이 지배적인 비용 요소가 되어 전체 이득을 갉아먹는다.

NVSHMEM, GPUDirect, IBGDA 같은 빌딩 블록

NVSHMEM은 각 GPU가 대칭 메모리 영역을 매핑한 Partitioned Global Address Space를 제공해 CUDA 커널 내부에서 동시 원격 읽기·쓰기를 가능하게 한다. GPUDirect RDMA는 NIC이 GPU HBM에 직접 접근하도록 확장하고, IBGDA는 GPU가 NIC을 직접 구동하게 해 CPU-주도 NIC 제어를 제거하여 작은 빈번한 메시지의 지연을 낮춘다. GDRCopy는 CPU가 GPU 메모리에 RDMA로 접근하도록 도우며, NVSHMEM은 가능한 경우 NVLink를 우선 사용하고 노드 간에는 InfiniBand를 활용해 최적의 전송 경로를 선택한다.

DeepEP의 작동 방식과 경로

DeepEP는 NVSHMEM 기반의 GPU-발기 커널을 통해 디스패치와 컴바인 단계의 통신을 직접 처리하도록 설계된 라이브러리로, 학습·프리필용 고처리량 커널군과 디코드용 저지연 순수 RDMA 커널군을 모두 제공한다. 라이브러리는 GPU에서 원격 메모리를 읽고 쓰는 경로를 사용해 집단 통신 설정과 동기화 비용을 회피하며 FP8 등 저정밀 연산을 지원해 메모리와 연산 효율을 추가로 개선한다. 이러한 설계로 Wide-EP와 프리필/디코드 분리(disaggregation)를 결합한 추론 파이프라인에서 특히 저지연 이점을 얻을 수 있다.

Nebius에서의 DeepEP 벤치마크 결과

PyTorch와 협력해 TorchTitan에서 256 B200 GPU 환경으로 DeepSeek 기반 학습 레시피를 실행한 결과 DeepEP 적용 전후 MFU와 처리량 변화를 측정했다. DeepSeek-16B(64 experts)에서 MFU는 8.29%에서 13.64%로 올라 약 65%의 상대적 처리량 이득을 보였고 DeepSeek V3-671B(256 experts)는 11.22%에서 13.99%로 올라 약 25%의 이득을 기록했다. 이 측정치는 메모리 사용량에 의미 있는 증가를 동반하지 않았으며, 프런티어급 MoE 학습에서 비용과 실행 시간에 실질적 영향을 준다.
근거
  • DeepEP 적용으로 DeepSeek-16B의 MFU는 8.29%에서 13.64%로, DeepSeek V3-671B의 MFU는 11.22%에서 13.99%로 상승해 각각 약 65% 및 약 25%의 처리량 이득을 기록했다. Benchmarking DeepEP on Nebius 섹션의 표(모델별 MFU 전후 값 및 처리량 이득)

Nebius에서 DeepEP를 설정하는 절차

설치는 IBGDA와 GDRCopy 커널 확인·설치, NVSHMEM 패키지 설치, DeepEP 빌드·설치, 그리고 환경 변수와 메모리 잠금(limts) 조정의 순서로 진행된다. 핵심 항목으로는 커널 파라미터 NVreg_EnableStreamMemOPs와 PeerMappingOverride 설정, GDRCopy v2.5.1 소스 빌드, pip로의 nvidia-nvshmem-cu12 설치, DeepEP 레포지토리의 특정 커밋(예: 29d31c0) 체크아웃 및 빌드가 포함된다. 또한 컨테이너 환경에서는 LimitMEMLOCK=infinity 설정과 UCX_NET_DEVICES 및 NVSHMEM_HCA_LIST를 실제 InfiniBand 포트에 맞춰 화이트리스트하는 것이 전송 실패와 성능 문제를 예방하는 핵심 제어점이다.
bash
cat /proc/driver/nvidia/params | grep -E "EnableStreamMemOPs|PeerMappingOverride"

클러스터에서 IBGDA 활성화 여부를 검사해 커널 파라미터가 설정되어 있는지 확인하는 명령어이다.

bash
gdrcopy_sanity

GDRCopy가 올바르게 설치되어 GPU 메모리에 대한 RDMA 접근을 테스트하는 간단한 실행 명령어이다.

bash
echo 'NVreg_EnableStreamMemOPs=1 NVreg_RegistryDwords="PeerMappingOverride=1;"' | sudo tee /etc/modprobe.d/nvidia.conf
sudo update-initramfs -u

NVIDIA 커널 모듈 설정을 갱신해 IBGDA 관련 플래그를 커널에 적용하는 절차의 핵심 명령이다.

bash
git clone https://github.com/NVIDIA/gdrcopy.git
cd gdrcopy
git checkout v2.5.1
cd packages
CUDA=/usr/local/cuda ./build-deb-packages.sh
sudo dpkg -i gdrdrv-dkms_*.deb
sudo dpkg -i libgdrapi_*.deb
sudo dpkg -i gdrcopy-tests_*.deb
sudo dpkg -i gdrcopy_*.deb

GDRCopy v2.5.1을 소스에서 빌드해 커널 모듈과 사용자 공간 라이브러리를 설치하는 전체 빌드/설치 절차이다.

bash
git clone https://github.com/deepseek-ai/DeepEP.git
cd DeepEP && git checkout 29d31c0
python3 setup.py build && python3 setup.py install

DeepEP의 특정 커밋(29d31c0)을 체크아웃해 빌드하고 설치하는 기본 명령으로, NVSHMEM과 TORCH_CUDA_ARCH_LIST 환경 설정이 선행되어야 한다.

현장 적용과 한계

MoE 워크로드에서 RDMA 기반 GPU-발기 전송은 통신 병목을 연산 여유로 되돌려 학습 비용을 절감하지만 설정 난이도와 커널·드라이버 호환성 문제가 적용 장벽으로 남는다. InfiniBand 포트 선택, 가상화된 NIC(예: mlx5_12) 제외, memlock 한계 조정 같은 플랫폼 운영 작업이 누락되면 전송 실패나 성능 저하가 발생한다. 또한 특정 환경에서의 이득 크기는 EP 차수, 전문가 수, 네트워크 토폴로지에 따라 달라져 재현 가능한 벤치마크와 레시피를 통해 환경별 검증이 필요하다.

용어 해설

혼합 전문가 모델 (MoE)(Mixture-of-Experts (MoE))
MoE는 Transformer 블록의 FFN을 다수의 전문가(expert)로 분할하고 각 토큰마다 소수의 전문가만 활성화해 계산 비용을 줄이는 구조이다. 라우터가 활성화할 top-K 전문가를 토큰별로 결정하므로 레이어마다 통신 대상과 전송 크기가 불규칙하게 변한다. 이 특성 때문에 모델 병렬화 시 전통적인 집단 통신(collective)이 비효율적이며, 고성능 분산 학습에서는 RDMA 기반의 점대점 전송이 대안으로 떠올랐다.
전문가 병렬(Expert Parallel (EP))
EP는 MoE의 전문가 집합을 여러 GPU에 분산해 각 GPU가 일부 전문가만 소유하도록 하는 분할 방식이다. Wide-EP는 전문가 수를 노드·GPU에 넓게 퍼뜨려 각 토큰당 활성 파라미터를 줄이는 대신 노드 간 소통 비중을 높인다. EP 차수가 증가할수록 모든-대-모든(all-to-all) 통신 횟수와 메시지 수가 급증해 통신이 병목이 된다.
원격 직접 메모리 접근(RDMA)
RDMA는 CPU 개입을 최소화하고 NIC이 직접 원격 메모리(DRAM 또는 GPU HBM)에 읽기/쓰기를 수행하게 하는 전송 방식이다. GPUDirect RDMA는 이 동작을 GPU 메모리(HBM)로 확장해 GPU가 다른 GPU의 메모리를 직접 접근하도록 허용하며, IBGDA는 CPU 개입조차 줄여 GPU가 NIC을 직접 제어하게 한다. 작은, 빈번하고 대상이 동적으로 변하는 MoE의 GPU↔GPU 통신에서 지연과 오버헤드를 크게 낮춘다.
InfiniBand GPUDirect Async(IBGDA)
IBGDA는 전통적 GPUDirect RDMA에서 남아있는 CPU-주도 NIC 제어를 제거해 GPU가 NIC를 직접 구동하도록 만든 기술이다. 이로 인해 작은 빈번한 GPU 간 전송의 지연과 CPU 오버헤드가 줄어들며 MoE처럼 메시지 패턴이 불규칙한 워크로드에서 유리하다. NVSHMEM과 결합하면 GPU-발기 점대점 전송의 실효적 지연을 더 낮출 수 있다.

기술

  • PyTorch
  • TorchTitan
  • DeepEP
  • NVSHMEM
  • GDRCopy
  • IBGDA
  • vLLM
  • Soperator
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

수집 2026. 07. 23.출처 타입 WEB

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.