MoE 모델 추론 최적화: Expert 병렬성·WideEP·로드밸런싱 실전 패턴

요약

Mixture-of-Experts(MoE) 모델은 파라미터 수 대비 추론 비용을 낮추는 핵심 기술이 됐다. DeepSeek V3/V4(671B 파라미터, 37B 활성), Qwen3.8-Max(2.4T 파라미터, 22B 활성) 같은 모델이 대표 사례다. 파라미터 규모는 Dense 모델과 비교가 안 되지만 각 토큰에 실제로 사용되는 활성 파라미터는 훨씬 적어 FLOPs이 낮다.

문제는 서빙이다. MoE의 전문가(Expert) 가중치를 여러 GPU에 분산하면서도 Expert 간 통신 오버헤드와 로드 불균형을 어떻게 제어하느냐가 MoE 서빙의 핵심 과제다.

이 글은 Expert 병렬성(EP)의 구조, WideEP 패턴, Elastic EP, 그리고 All-to-All 통신과 로드 불균형 문제를 다룬다. vLLM을 기준으로 실제 운영 설정도 함께 정리한다.

MoE 구조 복습

MoE는 FFN(Feed-Forward Network) 레이어를 다수의 전문가(Expert)로 대체하고, 게이팅 네트워크(Router)가 토큰별로 상위 K개 전문가를 선택한다.

입력 토큰 → [Router] → top-K 전문가 선택 → 선택된 전문가만 활성화 → 출력 가중 합산

예: DeepSeek V3는 레이어당 256개 전문가 중 8개를 활성화한다(top-8/256). Qwen3.8-Max는 512개 중 10+1개(공유 전문가 포함).

Dense 모델과 비교:

파라미터 수: MoE >> Dense (비슷한 품질 기준)
토큰당 FLOPs: MoE ≈ Dense/전문가수 × top-K (훨씬 적음)
메모리 요구: 모든 전문가 가중치를 메모리에 올려야 함 → MoE가 불리

따라서 MoE 서빙의 핵심 문제는 거대한 가중치를 어떻게 배치하고, 어떻게 전문가 간 통신을 최소화하느냐다.

Expert 병렬성(EP): 기본 개념

병렬성 차원

MoE 서빙에서 사용할 수 있는 병렬성은 세 가지다:

병렬성	대상	특징
Tensor Parallel (TP)	개별 가중치 행렬 분할	Dense 모델의 표준; MoE FFN에도 적용 가능
Expert Parallel (EP)	전문가 단위 분배	각 GPU가 서로 다른 전문가를 보유
Data Parallel (DP)	배치 분할	Attention 레이어에 주로 적용

기본 EP 동작

EP에서는 전문가들을 GPU에 균등 분배한다. 256개 전문가를 8 GPU에 배치하면 GPU당 32개. 토큰이 어떤 전문가로 라우팅되느냐에 따라 GPU 간 토큰 이동이 필요하다.

GPU0: Expert 0~31
GPU1: Expert 32~63
...
GPU7: Expert 224~255

토큰 → Router → Expert 17 선택 → GPU0으로 전송
                 Expert 89 선택 → GPU2로 전송

이 토큰 이동이 All-to-All 통신이다. 모든 GPU가 서로에게 토큰을 보내고 받는다.

WideEP 패턴

MoE 서빙 병렬성: WideEP 레이아웃 — Attention은 DP로, Expert FFN은 EP로 분리

WideEP는 EP 규모를 매우 크게 확장하는 전략이다. 8 GPU가 아니라 64~256 GPU에 걸쳐 Expert를 분산한다. 각 GPU는 소수의 Expert만 갖지만, Attention은 여전히 DP로 동작해 KV 캐시를 각 노드에 보관한다.

이점: GPU당 Expert 가중치가 줄어 GPU 메모리 중 KV 캐시 예산이 늘어난다. 더 긴 컨텍스트나 더 많은 동시 요청을 처리할 수 있다.

vLLM의 DeepSeek V3 GB200 서빙 결과(2026년 초): WideEP로 26,200 prefill TPGS(tokens per GPU second), 10,100 decode TPGS를 달성했다.

Elastic Expert Parallelism (vLLM)

기존 EP는 정적(static)이었다. 서버를 시작할 때 EP 크기를 고정하면 부하가 바뀌어도 재시작 없이는 조정할 수 없었다.

Elastic EP(vLLM 2026-05 도입)는 요청 부하에 따라 EP 크기를 동적으로 조정한다.

낮은 부하 → 소규모 EP (예: EP=4) → 비활성 GPU 비용 절약
높은 부하 → 대규모 EP (예: EP=16) → 처리량 증가

작동 원리:

Ray Serve로 vLLM 인스턴스를 관리
요청 큐 깊이를 모니터링
임계값 초과 시 Worker 추가 → EP 크기 확장
유휴 시 Worker 제거 → EP 크기 축소

# vLLM Elastic EP 설정 예시 (참고용)
# vllm serve deepseek-ai/DeepSeek-V3 \
#   --tensor-parallel-size 1 \
#   --expert-parallel-size 8 \
#   --enable-elastic-ep \
#   --min-ep-size 4 \
#   --max-ep-size 16

All-to-All 통신 병목

EP의 가장 큰 비용은 All-to-All 통신이다. 각 토큰이 라우팅된 Expert가 있는 GPU로 이동해야 하므로, 매 FFN 레이어마다 집합 통신이 발생한다.

통신 비용 구조

디스패치 (Dispatch): 각 GPU가 다른 GPU로 토큰 전송
                    → All-to-All 발신

컴바인 (Combine): 각 GPU가 Expert 처리 결과를 원래 GPU로 전송
                → All-to-All 수신

FFN 레이어당 2회의 All-to-All이 발생한다. DeepSeek V3(61개 레이어)에서는 122회다.

통신 ↔ 계산 중첩

현대 MoE 추론 시스템은 통신과 계산을 중첩(overlap)시킨다.

GPU 0: [디스패치 전송] → [Expert 0~31 계산] → [컴바인 수신]
         ↕ 중첩           ↕ 중첩              ↕ 중첩
GPU 1: [디스패치 수신] → [Expert 32~63 계산] → [컴바인 전송]

vLLM의 WideEP 구현은 CUDA 스트림을 분리해 All-to-All 통신이 진행되는 동안 이전 Expert 계산을 계속한다.

InfiniBand vs RoCE: WideEP는 GPU 간 고대역폭 통신이 필수다. InfiniBand(HDR: 200Gbps, NDR: 400Gbps)를 권장한다. RoCE도 지원하나 지연과 대역폭에서 열세다.

로드 불균형 문제

Expert 부하 쏠림

Router가 특정 Expert에 토큰을 집중 라우팅하면, 해당 GPU만 과부하가 걸리고 나머지는 유휴 상태가 된다. 이를 Expert 로드 불균형이라 한다.

이상적:  Expert 0~3 → 각 25% 부하
현실:    Expert 0 → 60%, Expert 1 → 25%, Expert 2 → 10%, Expert 3 → 5%
                  ↑ GPU 0이 병목

결과: Expert 0이 있는 GPU 0의 처리가 끝날 때까지 전체 배치가 기다려야 한다.

해결 방법

1. 보조 손실(Auxiliary Loss): 훈련 시 Expert 사용률 균등화를 위한 로드밸런싱 손실 항 추가. DeepSeek V3는 시퀀스 레벨 보조 손실로 훈련 안정성을 유지하면서 균등화를 달성했다.

2. 토큰 드로핑(Token Dropping): 과부하 Expert에 할당된 토큰 일부를 버린다. 처리량은 유지되지만 해당 토큰의 품질이 저하된다. Mixtral 등에서 사용하나 현재는 기피 경향이 있다.

3. Expert 선택 편향 보정: Router 로짓을 사후 조정해 잘 사용되지 않는 Expert 쪽으로 일부 라우팅을 유도한다.

4. ReaLB (Real-Time Load Balancing): 다중 모달 MoE를 위한 실시간 로드밸런싱 연구(arXiv:2604.19503). Expert 활성화 통계를 실시간으로 집계해 Router 편향을 동적으로 조정한다.

5. UltraEP: 랙 스케일 MoE 훈련·추론에서 near-optimal 로드밸런싱을 달성하는 방법론(arXiv:2606.04101, 2026년 6월).

vLLM MoE 서빙 실전 설정

EP 크기 선택 기준

모든 Expert 가중치 크기 = 총 파라미터 - 비-Expert 파라미터
EP 크기 ≥ 모든 Expert 가중치 크기 / GPU 메모리 (가중치 여유분)

예: DeepSeek V3 (BF16, Expert 가중치 약 550GB) → 최소 H100 8장 이상 필요.

모델	권장 EP	GPU
DeepSeek-V2-Lite (16E/2A)	EP=4~8	A100×4~8
DeepSeek V3/V4 (256E/8A)	EP=8~32	H100/GB200×8~32
Qwen3.8-Max (512E/10A)	EP=16~64	H100×16~64

주요 vLLM 파라미터

vllm serve <model> \
  --expert-parallel-size <EP 크기>          # Expert 병렬 규모
  --tensor-parallel-size 1                  # EP 우선 시 TP=1
  --max-num-seqs 512                        # 높은 동시접속 처리
  --kv-cache-dtype fp8                      # KV 메모리 절반으로
  --enable-prefix-caching                   # 프리픽스 재사용

운영 관측 지표

지표	설명	이상 임계값
`expert_load_std_dev`	Expert 부하 표준편차	0.3 이상이면 불균형
`all_to_all_latency_ms`	All-to-All 평균 지연	워크로드별 다름
`gpu_utilization_per_rank`	EP 랭크별 GPU 사용률	편차 > 20% 이상 점검
`num_preempted_reqs`	선점 요청 수	지속 증가 시 EP 부족
`decode_tpgs`	GPU당 디코딩 처리량	모델별 기준 설정 필요

체크리스트

[ ] 서빙 모델의 Expert 수와 top-K를 파악하고 EP 크기의 최솟값을 계산했는가
[ ] GPU 간 통신 인프라(InfiniBand/RoCE 대역폭)를 All-to-All 요구에 맞게 준비했는가
[ ] WideEP를 쓸 경우 KV 캐시 예산이 서빙 목표(동시접속, 컨텍스트 길이)를 충족하는가
[ ] Expert 로드 불균형 지표를 모니터링 대시보드에 포함했는가
[ ] Elastic EP를 사용한다면 스케일업/다운 임계값과 쿨다운 시간을 설정했는가
[ ] FP8 KV 캐시와 Expert 병렬성을 함께 적용해 GPU당 메모리를 최적화했는가
[ ] All-to-All 통신 지연이 디코딩 처리량 병목인지 프로파일링으로 확인했는가

References

vLLM Elastic Expert Parallelism 블로그 (2026-05-14): https://vllm.ai/blog/2026-05-14-elastic-expert-parallelism
vLLM Expert Parallel Deployment 문서: https://docs.vllm.ai/en/latest/serving/expert_parallel_deployment/
vLLM WideEP GB200 DeepSeek 서빙 (2026-02): https://vllm.ai/blog/2026-02-03-dsr1-gb200-part1
UltraEP: 랙 스케일 near-optimal 로드밸런싱 (arXiv:2606.04101): https://arxiv.org/abs/2606.04101
ReaLB: 실시간 MoE 로드밸런싱 (arXiv:2604.19503): https://arxiv.org/abs/2604.19503
TensorOps MoE Field Guide 2026: https://tensorops.ai/blog/what-is-mixture-of-experts-llm
llm-d WideEP 문서: https://llm-d.ai/docs/well-lit-paths/foundations/wide-expert-parallelism
Spheron MoE Inference Optimization 2026: https://www.spheron.network/blog/moe-inference-optimization-gpu-cloud/