96개 H100에서 DeepSeek-V3 서빙이 가능한 이유: SGLang Expert Parallelism의 통신 최적화와 메모리 단편화 해법

52,300 input tokens/s. 2025년 5월 LMSYS 팀이 96개 H100 GPU에서 DeepSeek-V3를 오픈소스로 최초 배포하며 공개한 수치입니다. 685B짜리 MoE 모델이 이 처리량을 낼 수 있다는 게 처음엔 직관에 반했습니다. 단일 노드로는 VRAM이 절대적으로 부족하고, 그렇다고 Tensor Parallelism을 무작정 늘리면 GPU들이 연산보다 서로 기다리는 시간이 더 길어지거든요. 저도 처음 이 수치를 봤을 때 "도대체 어떻게?" 싶었습니다.

비결은 Expert Parallelism(EP)이었는데, EP를 단순히 "Expert를 여러 GPU에 나눠 올린다"로 이해하면 절반만 아는 겁니다. 이 성능이 나오려면 노드 간 통신을 연산과 겹치는 오버랩 전략, Expert별 토큰 부하를 균형 잡는 EPLB, 그리고 TP 샤딩에서 조용히 일어나는 메모리 단편화까지 세 가지를 동시에 풀어야 합니다.

이 글은 LLM 서빙에 관심 있는 개발자와 ML 엔지니어를 대상으로, EP의 4단계 파이프라인 동작 원리부터 실제 배포 시 선택해야 할 백엔드와 설정, 그리고 진단하기 어려운 단편화 문제까지 한 흐름으로 풀어봅니다. 이 내용을 읽으면 실제 대규모 MoE 배포에서 TP·EP·DP 중 어떤 조합을 선택할지 판단 기준을 갖출 수 있습니다.

MoE와 EP 개념을 이미 알고 있다면 실전 적용 섹션부터 바로 이어가셔도 됩니다.

핵심 개념

MoE 게이팅과 Expert Parallelism의 관계

MoE(Mixture-of-Experts) 모델은 입력 토큰이 게이팅 네트워크를 통해 상위 K개의 전문가(Expert)에게만 라우팅되는 구조입니다. "이 토큰은 Expert 3번과 7번한테 보내"라는 방식이죠. 전체 파라미터는 수백 B이지만 실제로 활성화되는 연산량은 Dense 모델의 일부에 불과합니다.

여기서 Expert Parallelism의 아이디어는 단순합니다. 각 Expert를 다른 GPU에 올려두면, 토큰이 라우팅될 때 해당 GPU에서만 연산하면 됩니다. TP처럼 행렬을 잘라서 나눠 갖는 게 아니라, Expert 자체를 물리적으로 분리하는 방식입니다.

Expert Parallelism(EP): MoE 모델의 Expert 가중치를 여러 GPU에 분산 배치하는 병렬화 전략. Tensor Parallelism과 달리 각 GPU가 독립적인 Expert 연산을 담당하므로, 규모 확장 시 통신 패턴이 상대적으로 단순하게 유지됩니다.

실제로 EP를 TP 단독 구성과 비교했을 때, DeepSeek-V3 기준 2,000 토큰 입력·충분한 배치 크기 조건에서 최대 5배 처리량 향상이 보고됩니다. 배치 크기나 시퀀스 길이에 따라 편차가 있으니 자신의 워크로드에서 직접 측정해보는 게 좋습니다.

실제 대규모 배포에서는 EP를 단독으로 쓰기보다 TP와 병용하는 구성도 일반적입니다. 노드 내에서는 NVLink 대역폭이 충분하므로 TP를 작게 유지하고, 노드 간 확장은 EP로 처리하는 EP + TP 하이브리드 구성이 유연한 선택지가 될 수 있습니다.

SGLang EP의 4단계 파이프라인

SGLang은 MoE 순전파를 4단계로 명확히 분리합니다. 이 구조가 중요한 이유는 단계마다 독립적인 커널과 최적화 전략을 적용할 수 있기 때문입니다.

Pre-permute 단계가 왜 필요한지 처음엔 저도 의아했습니다. 이유는 Core Runner에서 쓰는 Grouped GEMM 커널이 동일 Expert에 할당된 토큰들이 메모리에 연속으로 배치되어 있어야 효율적으로 동작하기 때문입니다. Dispatch 이후 토큰 순서가 뒤섞여 있으면 GPU가 메모리를 제각각 찾아다니며 연산하게 되고, 텐서 코어 활용률이 크게 떨어집니다.

all-to-all 통신이 두 번 일어나는 구조라 "통신 비용이 두 배 아닌가?" 하는 의문이 자연스럽게 드는데, 이 의문이 곧 다음 섹션의 핵심 주제로 이어집니다.

실전 적용

전략 1: SBO와 TBO — 통신을 기다리는 시간을 연산으로 채우기

노드 간 통신이 병목이 되는 건 필연적입니다. NVLink는 노드 내 GPU 간 약 600 GB/s를 지원하지만, 노드 사이를 잇는 NDR InfiniBand는 400 Gb/s, 즉 실효 대역폭으로 환산하면 약 50 GB/s 수준입니다. 단위가 다르니 주의가 필요한데, 결국 노드 내부 대비 노드 간 통신이 10배 이상 느립니다. 노드가 많아질수록 이 격차가 전체 지연을 지배합니다.

SGLang의 접근법은 통신을 빠르게 만드는 게 아니라, 통신이 진행되는 동안 다른 연산을 병행하는 것입니다.

SBO(Single-Batch Overlap): 하나의 배치에서 all-to-all 통신이 진행되는 동안, 모든 토큰이 공통으로 거치는 Shared Expert 연산을 동시에 처리합니다. GPU가 네트워크를 기다리는 공백 시간을 없애는 방식입니다.

TBO(Two-Batch Overlap): 배치를 두 개의 마이크로 배치로 나눠서, 첫 번째 배치가 통신하는 동안 두 번째 배치가 연산을 수행합니다. 처리량이 올라가는 동시에 피크 메모리 사용량도 절반 수준으로 줄어드는 이중 효과가 있습니다.

아래는 SGLang 서버를 EP 구성으로 실행하는 CLI 명령어입니다. SGLang v0.4 이상 기준이며, 버전마다 플래그명이 달라질 수 있으니 사용 중인 버전의 공식 문서를 함께 확인해보시면 좋습니다.

# 단일 노드 8 GPU EP 구성
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3 \
  --tp-size 1 \           # TP는 최소화
  --ep-size 8 \           # 노드 내 8 GPU 전체를 EP로 활용
  --dp-size 1 \           # 단일 노드 기준
  --enable-dp-attention   # KV 캐시 복제 제거
 
# 멀티 노드 확장 시 (12노드 × 8 GPU = 96 H100)
# --dp-size 12 추가 후 각 노드에서 동일 명령 실행
# overlap 전략은 설정 파일 또는 버전별 추가 플래그로 지정

EP를 도입했는데 성능이 기대 이하라면, 통신 오버랩이 제대로 적용되었는지부터 살펴보는 것이 좋습니다. all-to-all이 동기 블로킹으로 돌고 있으면 EP의 이점이 절반 이상 사라집니다.

백엔드 선택: DeepEP와 RDMA 기반 비동기 통신

표준 NCCL의 all-to-all은 동기 차단 방식입니다. 통신이 완료될 때까지 GPU가 그냥 멈춰서 기다립니다. 이걸 해결하기 위해 DeepEP가 등장했습니다.

RDMA(Remote Direct Memory Access): CPU 개입 없이 GPU 메모리 간 직접 데이터를 전송하는 기술. NCCL은 내부적으로 여러 소프트웨어 레이어를 거치지만, RDMA는 하드웨어 수준에서 직접 통신하므로 CPU 오버헤드와 지연이 크게 줄어듭니다. InfiniBand 환경에서 특히 효과적입니다.

DeepEP는 순수 RDMA 기반 비동기 커널로 EP 전용 all-to-all을 구현하고, 워크로드 특성에 맞는 두 가지 모드를 제공합니다.

# DeepEP를 SGLang 백엔드로 지정
export SGLANG_EP_BACKEND=deepep
 
# Prefill 노드: 고처리량 Normal mode
export DEEPEP_MODE=normal
 
# Decode 노드: CUDA Graph 호환 저지연 모드
export DEEPEP_MODE=low_latency

이 환경 변수는 SGLang 버전에 따라 지원 여부가 다를 수 있습니다. 실제 배포 전에 사용 중인 SGLang 버전의 릴리즈 노트와 공식 문서에서 확인해보는 것을 권장합니다.

DeepEP Low-latency mode: Decode 전용으로 설계된 커널. SM(Streaming Multiprocessor, GPU 연산 단위)을 최소한으로 점유하는 훅 기반 설계로, 통신 오버랩이 오히려 연산 처리량을 갉아먹는 역설적 상황을 방지합니다.

Prefill 노드와 Decode 노드에 동일한 모드를 쓰면 둘 다 최적이 아닌 상태로 돌게 됩니다. PD Disaggregation 구성에서는 노드 유형별로 모드를 분리해서 지정하는 것이 좋습니다.

DeepEP 외에도 MoriEP(SGLang 직접 통합), UCCL-EP(클라우드 환경 이식성 중심) 같은 대안이 2025년 들어 경쟁적으로 등장하고 있습니다. NCCL 의존 없이 EP 전용 통신을 구현한다는 방향은 모두 동일합니다.

메모리 단편화 진단: DeepSeek-V3의 18,432 문제

실무에서 가장 소리 없이 성능을 갉아먹는 부분입니다. 눈에 보이지 않아서 더 골치 아픕니다.

DeepSeek-V3의 FFN 중간 차원은 18,432입니다. TP32를 적용하면 18,432 ÷ 32 = 576인데, H100 텐서 코어의 정렬 경계인 128의 배수가 아닙니다. 하드웨어가 내부적으로 패딩을 추가하고, 텐서 코어 활용률이 조용히 떨어집니다. GPU 점유율 지표는 멀쩡해 보이는데 실제 연산 효율은 낮은 전형적인 패턴이죠. 저는 프로파일러로 SM 활용률을 찍어보고 나서야 이 문제를 추적하게 됐습니다.

# 비정렬 단편화 진단 — TP 구성에서 정렬 여부 및 패딩 비율 확인
ffn_hidden_dim = 18432
tp_size = 32
alignment = 128
 
shard_size = ffn_hidden_dim // tp_size    # 576
is_aligned = (shard_size % alignment) == 0
 
if not is_aligned:
    aligned_size = ((shard_size + alignment - 1) // alignment) * alignment
    padding_ratio = (aligned_size - shard_size) / aligned_size
    print(f"샤드 크기: {shard_size}")
    print(f"128 정렬 여부: {is_aligned}")          # False
    print(f"패딩 비율: {padding_ratio:.1%}")        # 약 12.5% 낭비
    print("→ nvidia-smi dmon으로 실제 SM 활용률 모니터링을 권장합니다")

KV 캐시 단편화도 별도 이슈입니다. 동시 스트리밍 요청이 많을 때 가변 길이 시퀀스 때문에 PagedAttention 블록 풀에 내부 단편화가 누적되고, 실제 사용 VRAM의 2배 이상을 예약해야 하는 상황이 보고됩니다.

장단점 분석

장점

개인적으로 EP의 가장 큰 강점은 "확장 방식이 예측 가능하다"는 점입니다. TP에서 all-reduce는 참여 GPU 수에 비례해 통신량이 급격히 늘어나지만, EP의 all-to-all은 각 노드가 자신의 Expert 결과만 주고받는 구조라 노드 수가 늘어도 증가폭이 TP보다 완만합니다. 직접 두 구성을 비교해봤을 때 차이가 꽤 뚜렷했습니다.

단점 및 주의사항

솔직히 EP를 처음 현장에서 접했을 때 가장 당혹스러웠던 건 "설정은 됐는데 왜 느리지?" 하는 순간이었습니다. 대부분 아래 표의 두 번째나 세 번째 항목이 원인이었습니다.

EPLB(Expert Parallelism Load Balancer): DeepSeek이 공개한 Expert 배치 부하 균형 알고리즘. 토큰 라우팅 통계를 분석해 부하가 집중되는 Expert를 여러 GPU에 복제 배치합니다. 현재 DeepSeek-V3, Qwen3, Kimi-K2 등 주요 MoE 서빙 시스템에 표준으로 도입되고 있습니다.

실무에서 가장 흔한 실수

1. TP를 먼저 늘리는 접근: "GPU 더 써야 하니까 TP부터 올리자"는 직관은 MoE에서 역효과입니다. TP가 커질수록 FFN 정렬 단편화가 심해지고 all-reduce 통신도 비례해서 증가합니다. 현장에서도 이 순서로 접근하다 고생하는 경우를 자주 봤습니다. EP + DP 조합을 먼저 검토하는 것이 좋습니다.

2. SBO/TBO 없이 EP만 적용: EP를 켰는데 성능이 기대 이하라면 통신 오버랩이 꺼져 있는 경우가 많습니다. all-to-all이 동기 블로킹으로 돌고 있으면 EP의 이점이 절반 이상 사라집니다.

3. Prefill/Decode 동일 설정 사용: DeepEP의 Normal mode와 Low-latency mode는 단순한 옵션이 아니라 워크로드 특성에 맞는 별도 커널입니다. PD Disaggregation 구성에서 두 노드 유형에 동일 설정을 쓰면 둘 다 최적이 아닌 상태로 돌게 됩니다.

마치며

96개 H100 규모에서 핵심은 EP + DP 조합이며, 통신 오버랩(SBO)·부하 균형(EPLB)·메모리 정렬이라는 세 가지 문제를 함께 풀 때 비로소 효과가 나타납니다. 처음 EP를 적용한다면 SBO부터 시작해서 워크로드 특성을 확인한 뒤 TBO로 전환하는 경로가 가장 안전합니다.

지금 바로 시작할 수 있는 3단계입니다.

1. 메모리 단편화 사전 진단: 배포 구성을 결정하기 전에 TP 샤드 크기가 128의 배수인지 확인해보시면 좋습니다. 위의 진단 코드로 패딩 비율을 계산하고, nvidia-smi dmon으로 실제 SM 활용률 패턴도 관찰해두시면 이후 병목 분석이 훨씬 수월해집니다. 예약량과 실 사용량의 격차가 크다면 내부 단편화가 진행 중이라는 신호입니다.

2. 소규모 EP 테스트: 단일 노드 8 GPU에서 --ep-size 8 --dp-size 1로 시작해 SBO 적용 전후 처리량을 비교해보시면 됩니다. sglang.bench_serving으로 간단하게 측정할 수 있습니다. 이 단계에서 EPLB와 DP Attention도 함께 켜보시면 각 구성 요소의 기여도를 분리해서 확인할 수 있습니다.

3. 환경 및 대역폭 확인: 멀티 노드 구성을 앞두고 있다면 python -m sglang.check_env로 NCCL 버전과 GPU 간 NVLink 토폴로지를, ib_write_bw로 InfiniBand 실효 대역폭을 미리 측정해두시면 좋습니다. 노드 간 대역폭이 예상보다 낮으면 SBO만으로 충분한지, DeepEP 비동기 백엔드가 필요한지 판단하는 데 도움이 됩니다.

참고 자료

• Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs | LMSYS Blog
• Expert Parallelism | SGLang 공식 문서
• Expert Parallelism for MoE Models | DeepWiki
• DeepEP: an efficient expert-parallel communication library | GitHub
• UCCL-EP: Portable Expert-Parallel Communication | arXiv
• Semantic Parallelism: Redefining Efficient MoE Inference via Model-Data Co-Scheduling | arXiv
• Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI Architectures | arXiv
• SGLang GitHub 공식 레포지터리
• PD Disaggregation | SGLang 공식 문서