전문가 병렬화

전문가 병렬화 (Expert Parallelism)

SGLang의 Expert Parallelism (EP)은 MoE(Mixture-of-Experts) 모델에서 전문가(expert) 가중치를 여러 디바이스에 분산해 메모리 병목을 해결하고 고성능 추론을 위한 효율적 확장을 가능하게 합니다. 대규모 MoE 모델 서빙에 특히 중요하며, 토큰이 GPU 전반의 전문화된 전문가로 동적으로 라우팅됩니다.

출처: 문서

본문

SGLang의 Expert Parallelism (EP)은 MoE(Mixture-of-Experts) 모델에서 전문가 가중치를 여러 디바이스에 분산해 메모리 병목을 해결하고 고성능 추론을 위한 효율적 확장을 가능하게 합니다. 토큰이 GPU 전반의 전문화된 전문가로 동적으로 라우팅되는 대규모 MoE 모델 서빙에 특히 중요합니다. 최적화된 all-to-all 통신과 그룹 행렬 곱셈(GEMM, grouped matrix multiplications)을 활용해 EP는 지연을 줄이고 처리량을 높이며 유휴 GPU 시간을 최소화합니다. SGLang의 EP는 모듈형 프레임워크를 통해 강력한 확장성을 제공하며, 핵심 로직을 리팩토링하지 않고도 커스텀 커널·백엔드·최적화를 매끄럽게 통합하고 다양한 하드웨어와 양자화 방식을 지원합니다.

지원 백엔드와 선택 가이드 (Supported Backends and Selection Guidance)

SGLang의 EP는 다양한 사용 사례에 맞는 여러 고효율 백엔드를 통합해 성능 트레이드오프를 세밀하게 제어할 수 있게 합니다. 사용자는 명령줄 플래그로 백엔드를 지정합니다:

  • --moe-a2a-backend: all-to-all 통신용 백엔드 선택.
  • --moe-runner-backend: MoE 계산용 백엔드 선택.

All-to-All 통신용 백엔드 (Backends for All-to-All Communication)

Backend Description Use Cases
none (default) EP용 all-to-all 비활성화. 토큰 디스패치에 All-Reduce 또는 All-Gather 사용. Hybrid EP 및 TP 설정.
deepep DeepEP, MoE 모델의 효율적 토큰 셔플링용 통신 라이브러리. 대규모 EP 배포.
mooncake 탄력적 추론을 위한 DeepEP 확장. RDMA를 활용한 고성능 데이터 전송. Elastic EP 서빙.
nixl NIXL-EP, NVIDIA의 NIXL 프레임워크 위에 구축된 탄력적 EP 통신 라이브러리. 네이티브 RDMA·NVLink 지원. 내결함성·동적 확장을 갖춘 Elastic EP 서빙.
mori MORI-EP, ROCm에 최적화된 AMD의 네이티브 all-to-all 통신 구현. AMD GPU 배포.
flashinfer Flashinfer의 all-to-all 구현. 대규모 EP 배포.
ascend_fuseep Ascend NPU 네이티브 fused all-to-all 통신. Ascend NPU 배포.
pplx pplx-kernels, Perplexity의 NVSHMEM 기반 all-to-all dispatch/combine 커널. 저지연(masked) 전용. Hopper의 FP8 (DeepGEMM) MoE 모델 대상. NVSHMEM 3.2.5, nvshmem4py, cuda-python, 미리 빌드된 libpplx_kernels.so(sm_90a) 필요. Hopper의 저지연 decode EP.

DeepEP와 Mooncake 백엔드는 토큰 디스패치에 두 가지 모드를 지원합니다: normal 모드(높은 처리량의 prefill 워크로드에 최적화)와 low_latency 모드(저지연·CUDA Graph 호환 decode 워크로드에 최적화). MORI 백엔드는 현재 normal 모드만 지원합니다. NIXL-EP와 PPLX는 현재 CUDA Graph 지원으로 저지연 모드에서 동작합니다(PPLX는 DeepEP 저지연 masked expert-compute 경로를 재사용). 사용자에게는 런타임 자동 디스패치 모드 전환을 위한 --deepep-mode auto 설정을 권장합니다. --deepep-mode normal 또는 --deepep-mode low_latency 설정은 디버깅·개발 목적에 유용합니다.

현재 DeepEP, Mooncake, NIXL-EP, ascend_fuseep, pplx, MORI는 ep_size = tp_size인 경우만 지원합니다. Hybrid EP·TP(ep_size < tp_size)에는 none 백엔드(All-Reduce 또는 All-Gather 기반 디스패칭)만 지원됩니다. 또한 pplx는 DP 그룹이 2개 이상인 --enable-dp-attention(즉 tp_size / attention_tp_size > 1)이 추가로 필요합니다. 그렇지 않으면 pplx-kernels의 AllToAll을 구성할 수 없습니다.

MoE 계산용 백엔드 (Backends for MoE Computation)

Backend Description Use Cases
auto (default) 모델 아키텍처, 하드웨어(예: NVIDIA 아키텍처 Ampere, Hopper, Blackwell), 양자화 방식(예: FP8, FP4), 런타임 조건에 따라 최적 백엔드를 자동 선택. 일반 목적 배포. 사용자 개입 없이 호환성·성능 보장.
triton Grouped GEMM용 Triton 기반 구현. 더 높은 성능을 위해 tuned configurations 생성 권장. 커스텀 커널 개발 또는 Torch 컴파일 지원을 통한 높은 확장성 시나리오.
deep_gemm MoE 행렬 곱셈에 최적화된 DeepGEMM 백엔드. Prefill용 연속(contiguous) 레이아웃과 decode용 masked 레이아웃 지원. 성능 위해 JIT 컴파일되는 경우 많음. FP8 블록별 양자화를 쓰는 대규모 EP 배포.
cutlass 효율적 GEMM용 CUTLASS 기반 백엔드. CUTLASS 지원 NVIDIA 아키텍처.
flashinfer_trtllm TensorRT-LLM과 통합된 FlashInfer로 MoE 계산 가속. FP4 통신 연산자와 고성능 GEMM 지원. Blackwell with TRT-LLM.
flashinfer_trtllm_routed TensorRT-LLM과 통합된 FlashInfer로 routed MoE 계산 가속. SGLang이 계산한 top-k expert 할당과 가중치를 소비. flashinfer all-to-all과 호환. Blackwell with TRT-LLM.
flashinfer_cutlass CUTLASS와 결합된 FlashInfer로 MoE 레이어의 고성능 grouped GEMM 처리. FP4/FP8 양자화를 효율적으로 처리. flashinfer all-to-all과 호환. FP4/FP8 모델을 쓰는 Blackwell.
flashinfer_mxfp4 MoE 러너의 MXFP4(mixed FP4) 양자화에 최적화된 FlashInfer 변형. 메모리 효율적 저정밀 추론에 초점. MXFP4 저정밀 모델.
flashinfer_cutedsl 커스텀 DSL을 가진 FlashInfer로 유연·효율적 MoE 커널 생성. ModelOpt FP4 양자화와 통합. flashinfer all-to-all과 호환. NVFP4 저정밀 모델.

예시 (Examples)

DeepSeek-V3에 DeepEP와 DeepGEMM으로 시작:

python -m sglang.launch_server --model-path deepseek-ai/DeepSeek-V3 --moe-a2a-backend deepep --moe-runner-backend deep_gemm --tp 8 --ep 8

확장 가능한 EP 프레임워크 (Extensible EP Framework)

SGLang의 EP 프레임워크는 커스텀 커널·백엔드·최적화의 쉬운 통합을 위한 모듈형 추상화를 제공합니다. MoE forward pass를 스테이지로 분리(dispatch → pre-permute → core runner → post-permute → combine)해 핵심 로직을 리팩토링하지 않고도 매끄러운 확장이 가능하게 합니다.

프레임워크 개요 (Framework Overview)

프레임워크는 단일·확장 가능 구조의 통합 진입점으로 FusedMoE를 중심으로 합니다. 핵심 컴포넌트는:

  • Dispatcher: DeepEP 같은 백엔드의 dispatch/combine 관리(BaseDispatcher 서브클래스 구현).
  • MoeRunner: MoeRunnerCore 구현(예: TritonRunnerCore)으로 grouped-GEMM 실행 조정.
  • PermuteMethodPool: 레이아웃 변환 자동 등록(동적 모드의 pre/post-permute용 register_pre_permute·register_post_permute, 또는 torch.compile 호환 정적 fused 연산용 register_fused_func).
  • TopK Router: 백엔드 무관한 전문가 선택.

이 설계는 --moe-a2a-backend와 --moe-runner-backend로 여러 백엔드를 지원하고, 양자화는 표준화된 apply() 메서드로 통합됩니다. 계산 흐름은 모듈성을 보장합니다:

[input_hidden_states]
          |
          v
     TopK.forward -> select_experts / triton_kernels.routing / bypass
          |
          v
     [TopKOutput]
          |
          v
   FusedMoE.forward -> Dispatcher.dispatch -> DeepEP / bypass
          |                     |
          |                     v
          |              [DispatchOutput]
          |                     |
          |                     v
          |             quant_method.apply -> MoeRunner.forward
          |                     |              |
          |                     |              v
          |                     | pre-permute + grouped_gemm + post-permute
          |                     |              |
          |                     |--------------
          |                     v
          |               [CombineInput]
          |                     |
          |                     v
          |            Dispatcher.combine -> DeepEP / bypass
          |                     |
          |---------------------
          v
[final_hidden_states]

자세한 내용은 MoE Refactor Roadmap을 참고하세요.

새 백엔드 구현 (Implementing New Backends)

새 백엔드를 추가하려면:

  1. 새 all-to-all 디스패처는 dispatch·combine 메서드를 가진 BaseDispatcher 서브클래스를 구현.
  2. 새 MoE 러너 백엔드는 core 연산(예: grouped GEMM)용 MoeRunnerCore 서브클래스 정의.
  3. 디스패처·모델 러너의 새 입력/출력 포맷 정의(예: RunnerInput, RunnerOutput).
  4. 호환성 보장을 위해 permute/unpermute 메서드 등록:
    • Fused Mode (static, torch.compile 호환): end-to-end 연산에 register_fused_func 사용.
    • Permute Mode (dynamic): 유연한 레이아웃에 register_pre_permute와 register_post_permute 등록.

전체 변경사항(타입 힌트와 설정 확장 포함)은 MoE Refactor Implementation PR을 참고하세요.

예시 (Examples)

구현 예시는 등록된 fused·permutation 함수를 갖춘 Triton 기반 grouped GEMM을 보여주는 moe_runner/triton.py를 참고하세요.

계산과 통신 오버랩 (Computation and Communication Overlap)

SGLang의 EP는 통신 지연을 계산 뒤에 숨기는 고급 오버랩 기법을 사용해 MoE 레이어의 GPU 활용을 최대화합니다.

Two-Batch Overlap (TBO)

TBO는 요청을 micro-batch로 나누고 attention 계산을 dispatch/combine 연산과 인터리브합니다. 실행 그래프의 yield 포인트가 오버랩을 위해 일시 중지하게 해 피크 메모리 스파이크 없이 전체 처리량을 높입니다:

operations = [
    self._forward_attn,
    YieldOperation(),  # Overlap with dispatch of prior micro-batch
    self._forward_dispatch,
    self._forward_mlp,
    YieldOperation(),  # Overlap with combine
    self._forward_combine,
]

최대 2배 처리량을 위해 --enable-two-batch-overlap을 지정해야 합니다. 자세한 내용은 Large-Scale EP Blog를 참고하세요.

Single-Batch Overlap (SBO)

SGLang은 Single-Batch Overlap (SBO)용 디스패처 훅 시스템을 도입해, 단일 배치 내 작업(예: 공유 전문가 계산과 통신)의 오버랩을 가능하게 하면서 모듈성을 높이기 위해 로직을 분산화합니다. 이 훅은 core MoE 모듈을 수정하지 않고 dispatch·combine 연산 전후에 실행됩니다. 이 설계는 인터페이스를 단순화하고 결합도를 줄이며 확장성을 개선합니다. 구현 세부사항과 DeepEP의 combine 연산과 공유 전문가를 오버랩하는 예는 PR #13327을 참고하세요. --enable-single-batch-overlap으로 이 기능을 활성화할 수 있습니다.

워크로드 밸런서 (Workload Balancer)

SGLang은 MoE 모델의 라우팅 불균형을 해결하기 위해 DeepSeek의 Expert Parallelism Load Balancer (EPLB)를 통합합니다. 전문가 활성화 통계를 분석해 EPLB가 최적의 전문가 배치를 계산하고, GPU 활용 변동을 줄이고 유휴 사이클을 줄이며 확장성을 높이기 위해 전문가를 전략적으로 배치·복제합니다.

EPLB를 활성화하려면 --enable-eplb 플래그를 사용하세요. 최적 성능을 위해 활성화 통계를 안정화하려면 배치 크기를 늘리고, 진화하는 워크로드에 적응하기 위해 주기적 재밸런싱(예: 요청 1000개마다)을 구성하세요. 시뮬레이션은 부하 균형도(균형성, mean 대 max 계산 시간 비율)의 상당한 개선을 보여주며, 이는 처리량 이득과 강하게 상관됩니다.

자세한 내용은 Large-Scale EP Blog의 EPLB 섹션과 EPLB Repository를 참고하세요.

Ascend NPU 가이드 (Ascend NPU Guidance)

Ascend NPU에서의 SGLang 구성 가이드 (Guidance on SGLang configuration in Ascend NPU)

  • --moe-a2a-backend는 deepep와 ascend_fuseep 백엔드만 지원하며,

    • deepep: 메커니즘은 위 설명과 일치합니다.

    • ascend_fuseep: dispatch와 combine 사이의 모든 연산을 통합한 대형 fused 연산자를 제공해 MoE 계산을 가속합니다. PD Disaggregation Mode의 decode 단계에서만 사용됩니다.

  • --moe-runner-backend 파라미터는 구성할 필요가 없습니다.

  • --deepep-mode:

    • PD mixed mode에서는 --deepep-mode auto로 설정하세요.

    • PD Disaggregation Mode에서는 prefill 인스턴스가 --deepep-mode normal, decode 인스턴스가 --deepep-mode low_latency로 설정합니다.

DeepEP Ascend 소개 (DeepEP Ascend Introduction)

DeepEP Ascend는 Huawei Ascend NPU용으로 적응된 DeepEP 통신 라이브러리 버전으로, MoE(Mixture-of-Experts) 모델의 Expert Parallelism (EP)을 위해 특별히 설계되었습니다. Ant-moving Function(시퀀스 길이를 라운드로 나눠 스트리밍 배치 전송)을 지원해, 특히 긴 시퀀스에서 prefill 단계의 집단 통신 중 버퍼 크기 점유를 최적화합니다.

Ant-moving Function은 다음 환경 변수로 dispatch·combine 양쪽에서 활성화할 수 있습니다:

  • DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS: dispatch 단계에서 ant-moving function 활성화. 각 랭크에서 라운드당 전송되는 토큰 수, 기본 8192.

  • DEEPEP_NORMAL_LONG_SEQ_ROUND: dispatch 단계에서 ant-moving function 활성화. 각 랭크에서 전송되는 라운드 수, 기본 1.

  • DEEPEP_NORMAL_COMBINE_ENABLE_LONG_SEQ: combine 단계에서 ant-moving function 활성화, 기본 0(비활성 의미).

DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS * DEEPEP_NORMAL_LONG_SEQ_ROUND는 입력 시퀀스 길이를 뜻합니다. 입력 시퀀스 길이가 8192를 초과하면 dispatch·combine 양쪽에서 ant-moving function을 활성화하는 것이 권장됩니다.

환경 변수 HCCL_BUFFSIZE는 실제 할당되는 버퍼 크기(MB)를 구성하는 데 사용됩니다. 계산 공식은 다음과 같습니다:

# Enable Ant-moving Function
HCCL_BUFFSIZE >= 2 * (102MB + 4MB + DEEPEP_NORMAL_LONG_SEQ_PER_ROUND_TOKENS * (hidden_size + hidden_size + hidden_size) * topk) + PADDING_BUFFSIZE

# Disable Ant-moving Function
HCCL_BUFFSIZE >= 2 * (102MB + 4MB + TOTAL_SEQ_LEN * (hidden_size + hidden_size) * topk) + PADDING_BUFFSIZE

여기서 파라미터는 다음과 같습니다:

  • hidden_size: 모델 설정의 hidden size.

  • topk: 선택된 라우팅 전문가 수.

  • TOTAL_SEQ_LEN: 입력 시퀀스 길이.

  • PADDING_BUFFSIZE: 20 이상 권장.

더 알아보기 (Learn more)