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로 전환하는 이유
Mixture-of-Experts와 Wide Expert Parallel의 특성
NVSHMEM, GPUDirect, IBGDA 같은 빌딩 블록
DeepEP의 작동 방식과 경로
Nebius에서의 DeepEP 벤치마크 결과
- 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를 설정하는 절차
cat /proc/driver/nvidia/params | grep -E "EnableStreamMemOPs|PeerMappingOverride"클러스터에서 IBGDA 활성화 여부를 검사해 커널 파라미터가 설정되어 있는지 확인하는 명령어이다.
gdrcopy_sanityGDRCopy가 올바르게 설치되어 GPU 메모리에 대한 RDMA 접근을 테스트하는 간단한 실행 명령어이다.
echo 'NVreg_EnableStreamMemOPs=1 NVreg_RegistryDwords="PeerMappingOverride=1;"' | sudo tee /etc/modprobe.d/nvidia.conf
sudo update-initramfs -uNVIDIA 커널 모듈 설정을 갱신해 IBGDA 관련 플래그를 커널에 적용하는 절차의 핵심 명령이다.
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_*.debGDRCopy v2.5.1을 소스에서 빌드해 커널 모듈과 사용자 공간 라이브러리를 설치하는 전체 빌드/설치 절차이다.
git clone https://github.com/deepseek-ai/DeepEP.git
cd DeepEP && git checkout 29d31c0
python3 setup.py build && python3 setup.py installDeepEP의 특정 커밋(29d31c0)을 체크아웃해 빌드하고 설치하는 기본 명령으로, NVSHMEM과 TORCH_CUDA_ARCH_LIST 환경 설정이 선행되어야 한다.
현장 적용과 한계
용어 해설
- 혼합 전문가 모델 (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 Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.