[vLLM] Expert Parallelism & EPLB: 전문가 병렬화와 부하 균형

2026년 4월 7일수정: 2026년 4월 7일

들어가며

MoE 모델에서 전문가 수가 수백 개에 달하면, 모든 전문가를 하나의 GPU에 올리는 것이 불가능해진다. DeepSeek-V3/R1은 256개의 전문가를 가지며, 각 전문가가 상당한 파라미터를 차지한다. **Expert Parallelism(EP)**은 전문가를 여러 GPU에 분산 배치하고, 각 토큰을 해당 전문가가 있는 GPU로 라우팅하는 병렬화 전략이다. 그러나 EP의 근본적인 문제는 부하 불균형이다. 인기 있는 전문가가 있는 GPU는 과부하되고, 비인기 전문가의 GPU는 유휴 상태가 된다. **EPLB(Expert Parallelism Load Balancer)**는 이 문제를 런타임에 동적으로 해결한다.

논문:
- GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding
- DeepSeek-V3 Technical Report
공식 문서: https://docs.vllm.ai

공식 문서

vLLM 공식 문서: Expert Parallel Deployment

핵심 구조/코드 분석

EplbState: 전역 상태 관리

vllm/distributed/eplb/eplb_state.py에 EPLB의 핵심 상태가 정의되어 있다. 먼저 용어를 정리하자:

"""
- Logical Expert: 모델 파라미터에 정의된 원래 전문가. 256개 논리 전문가가 있다면
  MoE 레이어마다 256세트의 가중치가 존재한다.
- Redundant Expert: 부하 균형을 위해 인기 논리 전문가의 추가 복제본.
  32개 여분 전문가를 추가하면 총 288개 물리 전문가가 된다.
- Physical Expert: 실제 GPU에 인스턴스화된 전문가.
  288개 물리 전문가를 32개 GPU에 배치하면 GPU당 9개.
- Local Physical Expert: 현재 GPU에 있는 물리 전문가.
"""

EplbModelState: 매핑과 부하 추적

@dataclass
class EplbModelState:
    physical_to_logical_map: torch.Tensor
    """
    물리 전문가 → 논리 전문가 매핑.
    Shape: (num_moe_layers, num_physical_experts)

    예시 (2레이어, 6물리 전문가, 4논리 전문가):
    [[0, 1, 2, 3, 0, 1],
     [0, 2, 0, 1, 0, 3]]
    """

    logical_to_physical_map: torch.Tensor
    """
    논리 전문가 → 물리 전문가 매핑 (희소 행렬, -1은 매핑 없음).
    Shape: (num_moe_layers, num_logical_experts, num_redundant_experts + 1)

    예시:
    [[[0, 4, -1],
      [1, 5, -1],
      [2, -1, -1],
      [3, -1, -1]],
     [[0, 2, 4],
      [3, -1, -1],
      [1, -1, -1],
      [5, -1, -1]]]
    """

    logical_replica_count: torch.Tensor
    """
    각 논리 전문가의 복제본 수.
    Shape: (num_moe_layers, num_logical_experts)
    """

이 매핑이 EPLB의 핵심이다. 논리 전문가 0이 물리 전문가 0과 4에 복제되어 있다면, 라우터가 논리 전문가 0을 선택한 토큰은 물리 전문가 0 또는 4 중 부하가 적은 쪽으로 보내진다.

부하 추적: 슬라이딩 윈도우

    expert_load_pass: torch.Tensor
    """현재 forward pass의 전문가별 부하.
    Shape: (num_moe_layers, num_physical_experts)"""

    expert_load_window: torch.Tensor
    """슬라이딩 윈도우 기반 부하 기록.
    Shape: (window_size, num_moe_layers, num_physical_experts)"""

단일 forward pass의 부하만으로 재배치를 결정하면 노이즈에 취약하다. 슬라이딩 윈도우로 여러 pass의 부하를 평균하여 안정적인 재배치 결정을 내린다.

EplbStats: 재배치 알고리즘 입력

@dataclass
class EplbStats:
    global_expert_load_window: torch.Tensor
    """Shape: (window_size, num_moe_layers, num_physical_experts)"""
    num_replicas: int
    num_groups: int
    num_nodes: int
    num_gpus: int

global_expert_load_window는 all_reduce로 모든 GPU의 부하를 합산한 전역 통계이다. EPLB 정책은 이 전역 뷰를 기반으로 어떤 전문가를 어디로 이동할지 결정한다.

비동기 재배치 실행

from .async_worker import start_async_worker
from .rebalance_execute import (
    RecvMetadata,
    move_from_buffer,
    rearrange_expert_weights_inplace,
)

재배치는 비동기 워커에서 실행된다. 전문가 가중치는 먼저 버퍼로 전송(expert_buffer)되고, 적절한 시점에 실제 모델 가중치에 반영된다(rearrange_expert_weights_inplace). 이 과정은 buffer_lock으로 보호된다.

정책 플러그인

from .policy import EPLB_POLICIES, AbstractEplbPolicy, DefaultEplbPolicy

EPLB 정책은 플러그인 방식이다. AbstractEplbPolicy를 상속하여 커스텀 재배치 전략을 구현할 수 있다. DefaultEplbPolicy는 부하가 높은 논리 전문가에 더 많은 물리 복제본을 할당하는 기본 전략을 구현한다.

Elastic EP: 탄력적 전문가 병렬화

vllm/distributed/elastic_ep/ 디렉토리는 EP 크기를 동적으로 조정하는 기능을 구현한다:

파일	역할
`elastic_execute.py`	탄력적 실행 로직
`elastic_state.py`	EP 상태 관리
`standby_state.py`	대기 GPU 상태

부하에 따라 EP에 참여하는 GPU 수를 늘리거나 줄일 수 있어, 리소스 활용률을 최적화한다.

왜 이 설계인가

1. 중복 전문가(Redundant Experts): 인기 전문가를 단순히 여러 GPU에 복제하는 것이 가장 직관적인 부하 균형 방법이다. 256 + 32 = 288개 물리 전문가 중 32개가 여분이므로, 약 12%의 메모리 오버헤드로 부하 균형을 크게 개선한다.

2. 슬라이딩 윈도우 부하 추적: 단일 배치의 부하는 노이즈가 크다. 윈도우 크기만큼의 이력을 유지하면 일시적인 변동에 의한 불필요한 재배치를 방지한다.

3. 비동기 가중치 전송: 전문가 가중치(수 GB)를 GPU 간에 이동하는 것은 비용이 크다. 비동기 전송으로 추론을 블로킹하지 않으면서 재배치를 수행한다. 버퍼와 락을 사용하는 이유는 전송 중 모델이 해당 가중치를 읽지 않도록 보장하기 위해서이다.

4. 노드 인식(Node-aware) 배치: num_nodes와 in_the_same_node_as 함수가 보여주듯, EPLB는 노드 경계를 인식한다. 같은 노드 내 GPU 간 전송(NVLink)이 노드 간 전송(InfiniBand)보다 훨씬 빠르므로, 재배치 시 노드 내 이동을 우선시한다.

논문 핵심 내용

DeepSeek-V3 Technical Report (2412.19437)는 671B 파라미터 MoE 모델의 학습과 서빙 효율성을 다룬 기술 보고서다.

핵심 아이디어: DeepSeek-V3은 Multi-head Latent Attention(MLA)과 DeepSeekMoE 아키텍처를 결합한 모델로, 671B 총 파라미터 중 토큰당 37B만 활성화한다. 보조 손실 없는(auxiliary-loss-free) 부하 균형 전략과 멀티 토큰 예측 학습 목표가 핵심 혁신이다.

학습 효율성

메트릭	수치
총 학습 비용	2.788M H800 GPU hours (~$5.576M)
사전학습 비용	2.664M H800 GPU hours
학습 데이터	14.8T 토큰
학습 안정성	전 과정에서 복구 불가 loss spike 0회
GPU 클러스터	2048 H800 GPUs
Expert Parallelism	64-way EP, 8 노드
Pipeline Parallelism	16-way PP

주요 벤치마크 성능

벤치마크	DeepSeek-V3
MMLU	88.5
MMLU-Pro	75.9
GPQA	59.1
MATH-500	o1-preview 능가 (non-long-CoT 중 최고)
LiveCodeBench	코딩 대회 태스크 최고 성능

$5.576M이라는 학습 비용은 동급 성능의 다른 모델 대비 매우 저렴하다. 전체 학습 과정에서 단 한 번도 복구 불가능한 loss spike나 롤백이 없었다는 점도 주목할 만하다. 이 안정성은 보조 손실 없는 부하 균형 전략 덕분인데, 이것이 바로 vLLM의 EPLB가 런타임에 구현하려는 목표와 직결된다.

마무리

EPLB는 MoE 모델의 서빙에서 부하 불균형이라는 근본 문제를 런타임에 해결한다. 중복 전문가, 슬라이딩 윈도우 부하 추적, 비동기 가중치 전송, 노드 인식 배치라는 네 가지 메커니즘을 결합하여, DeepSeek-R1 같은 초대규모 MoE 모델의 효율적인 분산 서빙을 가능하게 한다.

vLLM 의 다른글

이전글 [vLLM] Disaggregated Prefill/Decode: 분리된 서빙
현재글 : [vLLM] Expert Parallelism & EPLB: 전문가 병렬화와 부하 균형
다음글 [vLLM] AsyncLLM: 비동기 엔진의 최상위 객체