Mixture of Experts (MoE): 내부 동작 원리와 이점이 발생하는 시점

당신은 7B 모델을 프로덕션 환경에 배포했습니다. 응답 시간은 토큰당 45ms로 괜찮지만, GPU 4개를 더 구매하지 않고 70B 규모로 확장하고 싶습니다. 누군가 MoE를 언급합니다: "7B의 연산량으로 70B의 성능을." 마치 공짜 점심처럼 들립니다. 그래서 Mixtral 8x7B 논문을 살펴보니, 450억 개의 파라미터(parameters)가 있고 각 토큰은 그중 약 130억 개만 활성화한다는 주장이 적혀 있습니다. 당신은 궁금해집니다: 이것이 물리적으로 어떻게 가능한가, 그리고 함정은 무엇인가?

이 포스트는 Mixtral, DeepSeek-MoE, Qwen2.5-MoE, DBRX, 그리고 Grok-1을 구동하는 희소 MoE (sparse MoE) 아키텍처를 설명합니다. 라우터 (router)가 실제로 무엇을 하는지, 왜 부하 분산 (load-balancing)이 이들을 학습시킬 때 가장 어려운 문제인지, 그리고 MoE가 당신의 배포 환경에 적합한 선택인지 결정하는 세 가지 구체적인 제약 조건에 대해 다룹니다.

전체 파라미터와 활성 파라미터의 구분이 중요한 이유

밀집 트랜스포머 (dense transformer, 예: Llama 3.2)는 모든 토큰에 대해 파라미터의 100%를 활성화합니다. 각 트랜스포머 블록의 FFN (Feed-Forward Network) 레이어는 모든 입력에 대해 동일한 행렬 곱셈 (matrix multiplication)을 수행합니다. 이는 메모리 사용량을 예측 가능하게 하고 처리량 (throughput) 모델링을 쉽게 만들지만, 7B에서 70B로 확장할 때 메모리와 연산량 (compute)이 모두 10배로 증가함을 의미합니다.

MoE는 이 두 가지를 분리합니다. 모델은 더 많은 파라미터를 저장하지만 (더 많은 메모리), 각 토큰은 그중 일부만 사용합니다 (더 적은 연산량). 숫자로 표현된 핵심 트레이드오프 (trade-off)는 다음과 같습니다:

지표	Dense 7B	Dense 70B	MoE 45B (Mixtral)
전체 파라미터 (Total parameters)	7B	70B	45B (8 experts)
...

핵심은 이것입니다: MoE는 밀집 70B 모델보다 더 나은 연산 효율성을 제공하지만, 여전히 훨씬 더 큰 모델의 메모리 비용을 지불해야 합니다. Mixtral은 단일 소비자용 GPU에서 실행할 수 없습니다. 가중치 (weights)를 수용하려면 최소 두 개의 24GB 카드가 필요합니다. 연산량 절감은 모델이 이미 로드된 후에만 나타납니다. 이것이 바로 "70B 성능을 7B 연산량으로"라는 슬로건이 종종 생략하는 함정입니다.

트랜스포머(Transformer)에서 희소 MoE(sparse MoE)가 작동하는 방식

표준 트랜스포머(standard transformer)에서는 모든 레이어(layer)가 FFN 블록(두 개의 선형 투영(linear projections)과 그 사이의 활성화 함수(activation)로 구성)을 가집니다. 희소 MoE(sparse MoE) 트랜스포머에서는 각 FFN이 여러 개의 병렬적인 "전문가(expert)" FFN과, 각 토큰(token)에 대해 어떤 전문가를 사용할지 선택하는 학습된 라우터(router)로 대체됩니다.

다음은 하나의 MoE 레이어를 통과하는 단일 토큰의 데이터 흐름입니다:

flowchart LR
    A[입력 토큰(Input token)<br/>은닉 상태(hidden states)] --> B[라우터 / 게이트(Router / Gate)<br/>학습된 선형 레이어(learned linear layer)]
    B --> C{N개의 전문가에 대한<br/>소프트맥스(Softmax)}
...```

라우터는 토큰의 은닉 상태(hidden state)를 입력받아 각 전문가에 대한 점수를 출력하는 작은 학습된 선형 레이어(learned linear layer)입니다. 모든 전문가에 대해 소프트맥스(softmax)를 수행하여 점수가 가장 높은 $k$개를 선택하고, 해당 전문가들을 통해서만 토큰을 통과시킨 뒤, 라우터 점수에 따라 가중치를 두어 결과를 결합합니다. Mixtral의 경우 8개의 전문가 중 $k=2$를 선택합니다. DeepSeek-MoE의 경우 64개의 전문가 중 $k=6$을 선택합니다. 라우터 자체는 (hidden_dim, n_experts) 크기의 단일 행렬 곱셈(matrix multiply)만 수행하므로 연산량이 무시할 수 있는 수준입니다.

### 라우터는 단순히 "이것을 어떤 GPU로 보낼 것인가"가 아닙니다

흔히 하는 오해는 라우터를 분산 스케줄러(distributed scheduler)가 머신에 작업을 할당하는 것과 유사하게, 토큰을 전문가에게 할당하는 로드 밸런서(load balancer)로 생각하는 것입니다. 이는 잘못된 모델링입니다. 라우터는 역전파(backpropagation)를 통해 모델의 나머지 부분과 함께 엔드 투 엔드(end-to-end)로 학습되는 **학습 가능한 미분 가능한 게이트(learned differentiable gate)**입니다. 라우터는 명시적인 감독(supervision) 없이도 어떤 전문가가 어떤 유형의 패턴(주제 전문성, 구문 구조, 토큰 위치 등)에 특화되어 있는지를 스스로 학습합니다.

### 전문가의 전문화는 설계되는 것이 아니라 나타나는 것입니다

학습 후 라우팅된 출력(routed outputs)을 조사해 보면, 개별 전문가(experts)들이 각자의 선호도를 발달시킨다는 것을 알 수 있습니다. Mixtral의 한 전문가는 산술 연산이 많은 토큰을 불균형적으로 자주 처리합니다. 다른 전문가는 기능어(function words)와 문장 부호를 처리합니다. 세 번째 전문가는 코드 구문(code syntax)을 처리합니다. 하지만 이러한 전문화는 경직된(hard) 것이 아니라 유연한(soft) 것입니다. 즉, "전문가 3은 수학 전문가이다"라고 규정하는 제약 조건은 없습니다. 라우터는 단순히 손실(loss)을 최소화하는 할당 방식을 학습할 뿐입니다.

## MoE 모델 학습: 부하 분산(load-balancing) 문제

MoE 학습에서 가장 어려운 부분은 라우터가 모든 토큰을 동일한 두 명의 전문가에게만 보내는 것을 방지하는 것입니다. 교정 신호가 없다면 라우터는 빠르게 붕괴(collapse)됩니다. 라우터는 우연히 초기화가 잘 된 전문가들에게 모든 것을 보내게 되고, 해당 전문가들은 더 많은 그래디언트 업데이트(gradient updates)를 받아 더 성능이 좋아지며, 라우터는 그들에게 더 많은 트래픽을 보냅니다. 결국 사용되지 않는 전문가들은 퇴화(atrophy)하게 됩니다.

표준적인 해결책은 전체 학습 손실(total training loss)에 **보조 부하 분산 손실(auxiliary load-balancing loss)**을 추가하는 것입니다. 가장 일반적인 공식(Mixtral, GShard, ST-MoE에서 사용됨)은 불균형에 대해 라우터에 페널티를 부여합니다.

단순화된 부하 분산 손실 (Switch Transformer 공식을 따름)

def load_balancing_loss(router_logits, num_experts, num_tokens):
"""...

`num_experts` 승수는 전문가 수에 따라 손실이 사라지지 않도록 손실을 스케일링(scaling)합니다. 전형적인 `aux_loss` 계수는 0.01에서 0.001 사이입니다. 계수가 너무 높으면 라우터가 판별력(discriminative power)을 잃게 되고, 너무 낮으면 전문가 붕괴(expert collapse) 현상이 다시 나타납니다.

### 보조 손실을 넘어: 현대적인 라우팅 전략

최근 연구들은 보조 손실을 줄이거나 제거하는 대안들을 도입했습니다:

- **DeepSeek-MoE**는 공유 전문가 (shared experts, 항상 활성화되어 공통 패턴을 처리)와 top-6 선택 방식을 사용하는 라우팅된 전문가 (routed experts)의 조합을 사용합니다. 공유 전문가는 모든 토큰이 필요로 하는 기본 연산을 담당하므로, 라우팅된 전문가들이 붕괴 (collapse) 현상 없이 더욱 공격적으로 전문화될 수 있습니다.
- **Qwen2.5-MoE**는 더 많은 수의 미세한 입자 크기의 전문가 (finer-grained experts, 더 작은 중간 크기)를 사용하며, 이를 공유 전문가 및 "라우팅 제약" (route-constrained) 보조 손실과 결합하여 사용합니다.
- **Dense-to-Sparse training** (DeepSpeed-MoE)은 밀집 (dense) 체크포인트에서 시작하여 점진적으로 희소화 (sparsify)하는 방식을 취하며, 이를 통해 초기화 단계에서의 붕괴 문제를 완전히 방지합니다.

## MoE 서빙 (Serving): 처리량과 메모리가 만나는 지점

MoE 모델을 서빙하는 것은 밀집 (dense) 모델과는 다른 인프라를 요구합니다. 핵심적인 통찰은 전문가 가중치 (expert weights)가 _폭은 넓지만(wide)_, _사용 범위는 좁다(narrowly used)_는 점입니다:

- **전문가 병렬화 (Expert parallelism)**: 서로 다른 전문가를 서로 다른 GPU에 배치합니다. 토큰당 $k$개의 전문가만 활성화되므로, 각 GPU는 전체 전문가 FFN (Feed-Forward Network)의 $2/k$만을 계산합니다. 이는 vLLM, TGI, SGLang에서 MoE 모델을 다루는 표준적인 방식입니다.
- **메모리 오버헤드 (Memory overhead)**: 모든 전문가 가중치는 결합된 GPU 메모리 전체에 상주해야 합니다. 8개의 전문가 중 토큰당 2개가 활성화되는 경우, 활성 파라미터 수(active-parameter count) 대비 총 GPU 메모리가 4배 더 필요합니다. Mixtral (총 45B, 활성 12.9B)의 경우 약 90 GB의 VRAM이 필요하며, 이는 최소 2개의 A100-80GB 또는 4개의 L40S가 필요함을 의미합니다.
- **All-to-all 통신 (All-to-all communication)**: MoE 레이어 이전에, 토큰들은 어떤 전문가로 라우팅되었는지에 따라 그룹화되어 올바른 GPU로 전송된 후, 처리되어 다시 돌아와야 합니다. 라우터의 디스패치 (dispatch) 및 결합 (combine) 연산은 전문가의 연산 자체보다 MoE 추론에서 주요한 지연 시간 (latency) 병목 구간이 됩니다.

다음은 구체적인 서빙 비교 예시입니다:

4x A100-80GB 환경에서 MoE vs 밀집(dense) 모델의 vLLM 설정

Dense 70B:

model: meta-llama/Llama-3.3-70B-Instruct
...

MoE의 처리량 (throughput) 이점은 실재하지만, 디스패치 오버헤드와 메모리 한계로 인해 파라미터 수에서 기대하는 것보다는 그 폭이 좁습니다.

## 일반적인 실수 (Common pitfalls)

**학습 중 라우터 붕괴 (Router collapse).** 부하 분산 손실 (load-balancing loss)을 사용하더라도, 초기 수천 단계 동안 라우터가 붕괴될 수 있습니다. 학습 중에 전문가 활용도 히스토그램 (expert utilization histogram)을 모니터링하십시오. 만약 한 전문가가 토큰의 30% 이상을 받는 반면 다른 전문가는 5% 미만을 받는다면, 보조 손실 계수 (auxiliary loss coefficient)를 높이거나 다른 라우팅 전략 (예: DeepSeek의 공유 전문가 설계 (shared-expert design))으로 전환하십시오.

**지연 시간 예산 (latency budgets)에서 디스패치 오버헤드 (dispatch overhead) 무시.** 전문가 라우팅에서의 올투올 (all-to-all) 통신은 배치 크기 (batch size)와 상호 연결 대역폭 (interconnect bandwidth)에 따라 MoE 레이어당 5-15ms를 추가합니다. 16개의 MoE 레이어를 가진 32레이어 모델의 경우, 실제 연산이 시작되기 전에 80-240ms의 오버헤드가 발생합니다. 지연 시간에 민감한 애플리케이션의 경우, 이 비용이 처리량 (throughput) 이득을 상쇄할 수 있습니다.

**너무 작은 배치 크기로 학습.** MoE 모델은 밀집 모델 (dense models)보다 더 큰 배치 크기를 필요로 합니다. 전문가 용량 제약 (expert capacity constraint)으로 인해 각 전문가가 배치의 일부만을 보기 때문입니다. 8개의 전문가와 k=2인 환경에서 256개의 토큰 배치는 각 전문가가 대략 64개의 토큰을 처리함을 의미합니다. 작은 배치로 학습하면 전문가 활용도가 낮아지고 그래디언트 (gradients)에 노이즈가 발생합니다.

**적응 과정 없는 미세 조정 (fine-tuning)에 MoE 사용.** 대부분의 MoE 모델은 MoE 아키텍처를 사용하여 처음부터 학습되었습니다. 밀집 체크포인트 (dense checkpoint)를 가져와 MoE로 변환하는 것 (DeepSpeed-MoE의 d2s 방식과 같이)은 세심한 초기화와 웜업 스케줄 (warm-up schedule)을 필요로 합니다. 기존 MoE 모델에 단순한 LoRA 미세 조정을 적용하면 학습된 라우팅 패턴이 깨질 수 있습니다. 라우팅이 이탈하지 않았는지 확인하기 위해 미세 조정 전후로 항상 다운스트림 태스크 (downstream task)를 평가하십시오.

**메모리를 잘못 측정하는 경우.** MoE 모델의 전체 파라미터 수는 `model.parameters()`를 결정하지만, 모델을 서빙하는 데 필요한 메모리는 모든 전문가 (experts)와 공유 레이어 (shared layers)의 합입니다. DeepSeek-MoE-16B의 경우, 64개의 전문가 (각각 hidden_size 2048에서 intermediate_size 1408 보유)는 전문가 가중치만으로 FP16 기준 약 45 GB를 차지함을 의미합니다. 전체 16B라는 라벨은 활성 파라미터 수 (active parameter count)를 나타내며, 저장 용량 요구 사항이 아닙니다.

## 사용하지 말아야 할 때

MoE가 항상 귀하의 모델에 적합한 아키텍처인 것은 아닙니다:

- **모든 요청에 대해 일관된 지연 시간 (latency)이 필요한 경우.** 라우터 (router)의 top-k 선택이 토큰마다 달라지고, 배치 구성 (batch composition)이 어떤 전문가가 활성화될지에 영향을 미치기 때문에, MoE의 지연 시간은 밀집 모델 (dense models)보다 변동성 (variance)이 더 큽니다. 만약 귀하의 SLO (Service Level Objective)가 토큰당 99번째 백분위수 (99th percentile) 지연 시간을 200ms 미만으로 유지해야 한다면, 밀집 모델이 보정하기 더 쉽습니다.
    
- **VRAM이 48 GB 미만인 단일 GPU에 배포하는 경우.** 실제 품질을 갖춘 MoE 모델 (활성 파라미터가 20~30억 개 이상인 경우)은 전체 가중치를 수용하기 위해 최소 두 개의 GPU가 필요합니다. 만약 배포 환경이 단일 RTX 4090 또는 A5000이라면, 7B-13B 범위의 밀집 모델을 사용하는 것이 좋습니다.
    
- **3B 파라미터 미만의 작은 모델을 구축하는 경우.** 라우터, 보조 손실 (auxiliary loss), 그리고 전문가 병렬성 (expert parallelism) 인프라의 오버헤드는 이 정도 규모에서는 그만한 가치가 없습니다. MoE는 극복하려는 밀집 모델 기준점 (dense baseline)이 30-50B 파라미터 이상일 때부터 이점이 생기기 시작합니다.
    
- **배치 크기 (batch size)가 작고 지연 시간에 민감한 경우.** 배치 크기가 1인 경우 (스트리밍 채팅)에는 디스패치 오버헤드 (dispatch overhead)가 지배적이기 때문에 전문가 병렬성의 이점을 얻을 수 없습니다. MoE의 처리량 (throughput) 이점은 배치 크기가 64 이상일 때 가장 뚜렷하게 나타납니다.
    
- **엔지니어링 복잡성을 감당할 수 없는 경우.** MoE 서빙은 커스텀 커널 지원 (fused experts, dispatch, combine을 위한 Triton 또는 CUDA 커널), 부하 분산 (load-balancing) 검증을 위한 까다로운 CI, 그리고 여전히 MoE 지원을 고도화하고 있는 추론 엔진 (inference engines)과의 통합을 필요로 합니다.

만약 팀의 ML 인프라가 제한적이라면, QLoRA를 사용한 밀집 모델 (dense model)이 더 안전한 선택입니다.
    
## 요약 (TL;DR)

- MoE는 각 토큰을 전문가 FFN (Feed-Forward Networks)의 하위 집합으로 라우팅함으로써, 전체 파라미터 수와 토큰당 연산량 (per-token compute)을 분리합니다.
- Mixtral 8x7B는 총 45B 파라미터를 보유하고 있지만, 토큰당 약 13B만 활성화하여 14B급 비용으로 70B급의 연산 효율성을 제공합니다.
- 라우터 (router)는 스케줄러 (scheduler)가 아니라, 엔드 투 엔드 (end-to-end)로 학습되는 학습된 선형 레이어 (learned linear layer)입니다. 전문가의 전문화 (expert specialization)는 자연스럽게 나타납니다.
- 라우터 붕괴 (router collapse)를 방지하기 위해서는 학습 과정에서 부하 분산 손실 (load-balancing loss)이 필수적입니다. 일반적인 계수 (coefficients) 범위는 0.01에서 0.001 사이입니다.
- MoE 서빙 (serving)을 위해서는 GPU 간의 전문가 병렬성 (expert parallelism)이 필요합니다. 지연 시간 (latency)의 주요 병목 현상은 전문가의 연산량이 아니라 디스패치 오버헤드 (dispatch overhead)입니다.
- MoE의 메모리 점유율 (memory footprint)은 활성 파라미터가 아닌 전체 파라미터(모든 전문가)에 비례합니다. Mixtral을 단일 24GB GPU에 담을 수는 없습니다.
- MoE는 대규모 스케일(대상 밀집 모델 베이스라인이 30B 이상인 경우)에서 이점을 얻습니다. 소규모 모델, 단일 GPU 배포, 또는 지연 시간에 민감한 애플리케이션의 경우, 밀집 모델 (dense)이 더 단순하고 종종 더 낫습니다.

**다음 포스트:** 구조화된 출력 (structured output) — JSON 모드, 함수 호출 (function calling), 그리고 문법 제약 디코딩 (grammar-constrained decoding)이 내부적으로 어떻게 작동하는지, 그리고 각 방식이 언제 실패하는지에 대해 다룹니다.