166편 · 약 16분

Mixture-of-Experts(MoE) 아키텍처 심화: Expert Parallelism·부하 균형·Router Collapse 방지 운영 기준

요약

Mixture-of-Experts(MoE)는 2025~2026년 프런티어 LLM의 지배적 아키텍처다. DeepSeek-V3/V4(256 전문가, top-8), Kimi K3(242 전문가, top-8), GLM-5.2(128 전문가, top-8), Qwen3 235B-A22B 등 대형 오픈 모델 대부분이 Sparse MoE 구조를 채택한다. MoE의 핵심 아이디어는 단순하다: 각 토큰이 전체 전문가(expert FFN) 중 소수(top-K)만 활성화해 총 파라미터는 크게, 토큰 당 실제 연산은 적게 유지한다. 이 글은 MoE 라우터 메커니즘, Expert Parallelism(EP), 부하 불균형(load imbalance), Router Collapse 방지까지 아키텍처와 운영을 함께 다룬다.

1. MoE가 필요한 이유: Dense 모델의 병목

Transformer 기반 Dense 모델에서 FFN은 각 레이어 연산량의 약 2/3를 차지한다. 파라미터 수를 두 배로 늘리면 모든 토큰에 대한 연산량도 두 배가 된다. 성능을 높이려면 비용이 선형 증가한다.

MoE는 이 관계를 끊는다. E개의 전문가 FFN을 두고 각 토큰이 그중 K개만 선택해 계산한다. E=64이고 K=2이면 토큰 당 활성 FFN은 전체의 3%에 불과하다. 전체 파라미터는 Dense 대비 E/K배 클 수 있지만 추론 FLOPs는 비슷하게 유지된다.

이른바 조건부 계산(conditional computation)이다. 모든 전문가가 동시에 활성화되지 않기 때문에, 같은 추론 예산으로 훨씬 큰 모델을 운영할 수 있다.

2. Sparse MoE 구조: 라우터와 전문가

전통적인 Transformer FFN 레이어는 다음과 같다:

h' = FFN(h) = W₂ · GeLU(W₁ · h)

MoE는 이를 E개의 독립적 FFN으로 교체하고, 라우터가 각 토큰의 상위 K개를 선택한다:

h' = Σᵢ ∈ TopK(h) gᵢ · FFNᵢ(h)
gᵢ = softmax(router_logits)[i]     # 게이팅 가중치
router_logits = Wᵣ · h             # 라우터 선형 레이어

실제 모델 파라미터 비교:

모델	총 전문가 수	Top-K	공유 전문가	총 파라미터 / 활성 파라미터
Mixtral 8x7B	8	2	없음	~47B / ~13B
Qwen3-235B-A22B	128	8	없음	235B / 22B
DeepSeek-V3	256	8	1	671B / 37B
Kimi K3	242	8	1	~1015B / 55B
GLM-5.2	128	8	없음	744B / 40B

공유 전문가(Shared Expert): DeepSeek-V3·Kimi K3 등은 항상 활성화되는 공유 전문가 1~2개를 별도로 둔다. 전 토큰에 공통된 '기초 지식'을 담당하고, 나머지 라우팅 전문가들이 특화 역할을 나누는 설계다.

3. 라우터 설계: Token-Choice vs Expert-Choice

Token-Choice (현재 주류)

각 토큰이 자신의 라우터 로짓을 계산해 상위 K개 전문가를 스스로 선택한다.

장점: 구현 단순, 토큰 당 정확히 K번의 FFN 연산. 문제: 특정 전문가에 토큰이 몰리는 부하 불균형이 발생한다. 인기 있는 전문가는 배치 내에서 용량을 초과하고, 일부 토큰이 "드롭"되거나 패딩으로 처리된다.

전문가 용량 제한(Expert Capacity):

capacity = capacity_factor × (batch_tokens / num_experts)

capacity_factor가 1.0이면 각 전문가는 평균 토큰 수만큼만 처리한다. 초과 토큰은 드롭되거나(구현에 따라) 다음으로 넘어간다. capacity_factor를 높이면 드롭이 줄지만 메모리·연산 낭비가 늘어난다.

Expert-Choice (연구 단계)

각 전문가가 자신에게 보낼 토큰을 선택한다. 전문가 당 균일한 토큰 수를 보장하지만, 특정 토큰이 여러 전문가에 선택받거나 하나에도 선택받지 못할 수 있다. 현재 프로덕션 모델에서는 드물다.

4. 부하 균형: Auxiliary Loss 접근

Token-Choice 라우팅에서 라우터는 쉽게 특정 전문가에 편향된다. 다른 전문가들이 학습 기회를 잃어 더 나빠지면, 좋은 전문가가 더 많은 트래픽을 받는 양의 피드백 루프가 생긴다.

이를 막기 위해 부하 균형 보조 손실(Load Balancing Auxiliary Loss)을 추가한다:

L_aux = α × Σᵢ fᵢ × Pᵢ

fᵢ = 전문가 i에 배정된 토큰 비율 (실측)
Pᵢ = 전문가 i의 평균 라우터 확률 (모델 예측)

이 손실은 fᵢ와 Pᵢ가 균일(1/E)에 가까울 때 최소가 된다. α(보통 0.001~0.01)를 너무 크게 하면 전문가 분화가 억제되어 성능이 떨어지고, 너무 작으면 부하 불균형이 계속된다.

z-loss(라우터 로짓 정규화)도 자주 함께 쓰인다:

L_z = β × mean_batch[ log²( Σᵢ exp(router_logitsᵢ) ) ]

라우터 로짓 크기를 제한해 수치 불안정성과 라우팅 집중을 동시에 억제한다. Google ST-MoE 논문에서 제안됐으며 β=1e-2가 일반적이다.

5. DeepSeek의 Auxiliary-Loss-Free 접근

DeepSeek-V3는 보조 손실 없이 부하 균형을 달성하는 대안을 제시했다. 핵심은 전문가별 동적 바이어스(Dynamic Expert Bias)다:

adjusted_logits_i = router_logits_i + bias_i

학습 중 배치마다:

전문가 i가 평균보다 많이 선택되면: bias_i -= γ (바이어스를 낮춤)
전문가 i가 평균보다 적게 선택되면: bias_i += γ (바이어스를 높임)

게이팅 가중치(gᵢ) 계산에는 원래 라우터 로짓을 쓰고, top-K 선택 결정에만 바이어스가 개입한다. 이 분리 덕분에 "선택은 균등하게, 기여는 역량대로"가 된다.

DeepSeek-V3 기술 보고서에 따르면 보조 손실 없이도 전문가 부하 분산을 달성했으며, 이 방식이 보조 손실 방식보다 모델 성능이 향상됐다고 보고한다. 다만 바이어스 업데이트 단계(γ 하이퍼파라미터 튜닝)가 추가된다.

입력 토큰 h (벡터)

임베딩 / 이전 레이어 출력

↓

라우터 (Router)

logits = Wᵣ · h

↓ (+dynamic bias)

Top-K 선택 (K=2~8)

↓

게이팅 가중치 g₁…gₖ (원래 logits 기준)

↓

전문가 합산

h' = Σ gᵢ · FFNᵢ(h)

E개 전문가 (예: E=256)

FFN₁ ✓ 활성 (GPU 0)

FFN₂ ✓ 활성 (GPU 1)

FFN₃ ✗ 비활성

⋮

FFN₂₅₆ ✗ 비활성

Expert Parallelism (EP=4 예시)

GPU 0: FFN₁~FFN₆₄

GPU 1: FFN₆₅~FFN₁₂₈

GPU 2: FFN₁₂₉~FFN₁₉₂

GPU 3: FFN₁₉₃~FFN₂₅₆

EP All-to-All 통신 흐름

① 라우팅 결정 (각 GPU)

② Dispatch All-to-All (토큰 → 전문가 GPU)

③ 로컬 전문가 연산

④ Gather All-to-All (결과 → 원래 GPU)

Sparse MoE 아키텍처: 라우터·전문가·부하 균형·Expert Parallelism 전체 흐름

6. Expert Parallelism: 전문가를 GPU에 분산하는 방법

E개의 전문가를 하나의 GPU에 올리는 것은 전문가 수가 수백 개일 때 불가능하다. Expert Parallelism(EP)은 전문가 집합을 여러 GPU에 나눠 배치한다.

EP=4인 경우 (전문가 256개):

GPU 0: FFN₁~FFN₆₄
GPU 1: FFN₆₅~FFN₁₂₈
GPU 2: FFN₁₂₉~FFN₁₉₂
GPU 3: FFN₁₉₃~FFN₂₅₆

토큰이 GPU 0에 있는데 FFN₁₂₇을 선택했다면 GPU 1에 해당 토큰을 전송해야 한다. 이를 All-to-All 통신으로 처리한다.

MoE 레이어 실행 순서 (EP 사용 시):

모든 GPU에서 라우팅 결정 (각 토큰이 어느 전문가를 원하는지)
All-to-All Dispatch: 각 GPU에서 다른 GPU로 토큰 벡터를 전송
각 GPU에서 자신의 전문가 FFN으로 해당 토큰들을 처리
All-to-All Gather: 처리 결과를 원래 GPU로 모음
게이팅 가중치를 곱해 합산

All-to-All 통신 비용은 EP 정도에 비례하여 증가한다. 최신 서버의 NVLink(~900 GB/s)나 InfiniBand(~400 Gb/s)가 이 병목을 처리하지만, 네트워크 대역폭이 추론 속도를 제한하는 주요 인자 중 하나가 된다.

EP와 다른 병렬화의 조합:

조합	설명	주 용도
EP + DP	전문가 분산 + 배치 복제	처리량 극대화
EP + TP	전문가 분산 + 어텐션 텐서 병렬화	초대형 모델 단일 추론
EP + PP	전문가 분산 + 파이프라인 병렬화	깊은 모델 레이어 분산

DeepSeek-V3는 서비스 환경에서 EP=32(전문가 256개, GPU 당 8개)와 TP=1을 조합하고, NVLink와 InfiniBand를 계층별로 활용한다.

7. Router Collapse: 정의·원인·방지

Router Collapse는 라우터가 대부분의 토큰을 동일한 전문가 1~2개에 보내는 퇴화 현상이다. 이 상태에서는:

선택받지 못한 전문가들이 기울기를 받지 못해 학습이 정체된다
MoE의 조건부 계산 이점이 사라지고 Dense 모델처럼 동작한다
과부하된 전문가에서 토큰 드롭이 대규모로 발생한다

주요 원인:

초기 라우터 불안정: 학습 초기 특정 전문가가 우연히 더 잘 학습되면 더 많은 토큰이 몰리는 양의 피드백이 시작된다.
라우터 로짓 폭발: 라우터 가중치가 커지면 softmax가 거의 one-hot이 되어 항상 같은 전문가가 선택된다.
불충분한 부하 균형 강도: auxiliary loss α 또는 dynamic bias γ가 너무 작을 때.

방지 기법:

기법	방식	효과
Auxiliary Loss	L_aux = α·Σ fᵢ·Pᵢ 추가	라우팅 균일화 압력
z-loss	라우터 로짓 크기 정규화	수치 불안정성 억제
Dynamic Bias	per-expert 바이어스 동적 조정	보조 손실 없이 균형
Jitter Noise	라우팅 로짓에 가우시안 노이즈 추가	초기 탐색 다양성 확보
Expert Dropout	학습 중 전문가 무작위 비활성화	전문가 다양성 강제
Capacity Factor	전문가 당 최대 토큰 수 제한	폭발적 집중 물리적 차단

8. 운영 체크리스트

MoE 모델을 프로덕션에서 서빙할 때 확인할 지표와 행동.

라우팅 건강도 모니터링:

전문가별 토큰 배정 비율의 표준편차 / 평균 (변동계수) → 0.2 이하 목표
전문가별 활성화 빈도 분포 히스토그램 (vLLM: --enable-expert-token-histogram)
라우팅 엔트로피: H = -Σᵢ pᵢ log pᵢ → 높을수록 균일한 라우팅

Expert Parallelism 운영:

All-to-All 통신 시간 모니터링 (NCCL 프로파일러)
GPU 간 부하 불균형 확인 (특정 GPU의 전문가에만 트래픽 집중 여부)
EP 정도는 전문가 수와 GPU 수의 최대공약수로 설정하는 것이 일반적

드롭된 토큰 추적:

드롭 비율 > 1% 이면 capacity_factor 조정 필요 (1.0 → 1.25 → 1.5)
드롭이 집중되는 전문가 식별 → Router Collapse 조기 경보 신호

단계별 진단 흐름:

전문가 부하 불균형 발견 → auxiliary loss α 확인 또는 dynamic bias γ 조정
드롭 토큰 과다 → capacity_factor 증가
라우팅 엔트로피 저하 → jitter noise 추가 또는 z-loss 강화
여전히 Router Collapse → 학습 체크포인트 롤백 후 하이퍼파라미터 재조정

요점 정리

MoE는 전체 파라미터는 크게, 토큰 당 연산은 적게 유지해 Dense 모델 대비 비용 효율을 높인다.
Token-Choice 라우팅이 주류이며, 부하 불균형 방지를 위해 Auxiliary Loss 또는 DeepSeek의 Dynamic Bias를 쓴다.
Expert Parallelism은 All-to-All 통신으로 전문가를 GPU에 분산하며, EP 정도가 높을수록 통신 비용이 증가한다.
Router Collapse는 MoE의 가장 심각한 퇴화 현상으로, 라우팅 엔트로피와 전문가 활성화 분포를 지속 모니터링해야 한다.
운영 시 전문가 부하 변동계수, 드롭된 토큰 비율, 라우팅 엔트로피 세 지표를 핵심 SLI로 관리한다.

References

Mixtral of Experts (Mistral AI, arXiv:2401.04088): https://arxiv.org/abs/2401.04088
DeepSeek-V3 Technical Report (arXiv:2412.19437): https://arxiv.org/abs/2412.19437
Switch Transformers: Scaling to Trillion Parameter Models (arXiv:2101.03961): https://arxiv.org/abs/2101.03961
ST-MoE: Designing Stable and Transferable Sparse Expert Models (arXiv:2202.08906): https://arxiv.org/abs/2202.08906
Kimi K3 Technical Report (arXiv:2607.24653): https://arxiv.org/abs/2607.24653
MegaBlocks: Efficient Sparse Training with Mixture of Experts (arXiv:2211.15841): https://arxiv.org/abs/2211.15841
Expert Choice Routing (arXiv:2202.09368): https://arxiv.org/abs/2202.09368