Dense 트랜스포머는 매 토큰마다 모든 파라미터를 동원한다. 175B 규모 모델이라면 한 토큰을 처리할 때 175B짜리 네트워크가 풀가동된다는 뜻이고, 규모를 키울수록 연산 비용이 선형으로 따라온다. 파라미터 수와 FLOPs를 분리하고 싶다는 욕구에서 희소 활성화(sparse activation)가 나왔다. 파라미터는 많이 두되 실제 추론엔 일부만 쓰는 것.
MoE(Mixture of Experts)와 MoT(Mixture of Tokens)는 둘 다 이 철학을 구현하지만, 풀려는 문제의 각도가 다르다. MoE는 "이 토큰을 어느 전문가에게 보낼까?"를 묻고, MoT는 "이 전문가에게 어떤 토큰들을 섞어줄까?"를 묻는다. 라우팅의 주체와 방향이 뒤집혀 있다.
Mixture of Experts
MoE의 구조는 단순하다. Transformer 레이어 내 FFN을 N개의 전문가(expert FFN)로 대체하고, 각 토큰이 게이팅 네트워크(라우터)를 통해 그 중 K개만 선택해 활성화한다. 나머지 N-K개의 전문가는 해당 토큰에 대해 전혀 계산하지 않는다.
라우터는 각 토큰의 hidden state를 입력받아 N개 전문가에 대한 확률을 계산하고, 상위 K개를 고른다:
$$G(x) = \text{TopK}(\text{softmax}(W_g \cdot x))$$
선택된 K개 전문가의 FFN 출력을 게이팅 가중치로 합산한 결과가 최종 레이어 출력이 된다. Switch Transformer(Fedus et al., 2021)는 이를 K=1로 극단화한 Top-1 라우팅으로 대규모 실험을 처음 성공시킨 논문이다. T5 대비 사전학습 속도 7배 향상을 실증했고, 파라미터 수를 수조 단위까지 스케일하는 경로를 열었다.
Mixtral 8x7B는 현재 가장 잘 알려진 MoE 구현이다. 레이어당 전문가 8개, Top-2 라우팅 구조로, 전체 파라미터는 46.7B이지만 추론 시 활성화되는 것은 약 13B에 불과하다. 단일 forward pass의 FLOPs는 14B Dense 모델 수준이면서 Llama 70B와 경쟁하는 성능을 낸다.
Expert Collapse와 보조 손실
Top-K 라우팅의 가장 큰 실전 문제는 라우터 편향이다. 학습이 진행되면서 라우터가 특정 전문가에 집중적으로 토큰을 보내기 시작하고, 나머지 전문가는 점점 업데이트를 받지 못해 의미 없는 파라미터로 굳어진다. Expert Collapse다. 심해지면 N개의 전문가 중 1~2개만 실질적으로 작동하는 상태가 되고, MoE 설계 자체가 무력화된다.
보조 로드 밸런싱 손실(auxiliary loss)이 표준 대응이다. Switch Transformer의 공식은:
$$\mathcal{L}{aux} = \alpha \cdot N \cdot \sum{i=1}^{N} f_i \cdot P_i$$
$f_i$는 현재 배치에서 i번째 전문가에 실제로 라우팅된 토큰 비율, $P_i$는 라우터가 i번째 전문가에 할당한 평균 확률이다. 두 값이 동시에 크면 손실이 커지므로 라우터가 분산을 유지하도록 압력을 받는다. 권장값은 $\alpha = 0.01$이다.
PyTorch로 구현하면:
import torch
import torch.nn.functional as F
def router_auxiliary_loss(router_logits, n_experts, alpha=0.01):
"""
Switch Transformer 방식 로드 밸런싱 보조 손실.
router_logits: [T, N] (T = 배치의 총 토큰 수, N = 전문가 수)
"""
probs = F.softmax(router_logits, dim=-1) # [T, N]
# P_i: 라우터가 각 전문가에 할당한 평균 확률
router_prob = probs.mean(dim=0) # [N]
# f_i: 실제로 각 전문가에 라우팅된 토큰 비율 (top-1 기준)
top1_idx = probs.argmax(dim=-1) # [T]
token_fraction = F.one_hot(top1_idx, n_experts).float().mean(dim=0) # [N]
return alpha * n_experts * (token_fraction * router_prob).sum()
ST-MoE(Zoph et al., 2022)는 이 안정화 기법들을 체계화해 269B 파라미터 희소 모델에서 전이학습 최고 성능을 처음 달성했다.
분산 학습 환경에서는 통신 오버헤드가 추가 문제로 붙는다. 전문가를 여러 GPU에 나눠 배치(expert parallelism)하면 각 토큰이 자신이 배정된 전문가 GPU로 이동해야 하므로, 배치가 클수록 all-to-all 통신 비용이 무시하기 어려운 수준이 된다.
Mixture of Tokens — 라우팅 방향을 뒤집다
MoT는 같은 전문가 구조를 유지하면서 라우팅의 방향을 뒤집는다. 토큰이 전문가를 선택하는 게 아니라, 각 전문가가 배치 내 여러 시퀀스의 토큰들을 혼합한 입력을 받는다.
NeurIPS 2024에 발표된 MoT 논문의 메커니즘은 이렇다. 컨트롤러 네트워크가 각 토큰에 대해 softmax 기반 중요도 가중치를 계산한다. 같은 시퀀스 포지션에 있는 여러 예제의 토큰들이 전문가마다 다른 가중치로 혼합되어 하나의 입력 벡터를 구성하고, 이것이 전문가 FFN을 통과한다. 출력은 동일한 가중치로 다시 원본 토큰들에게 재분배된다.
라우팅 결정이 연속적(soft)이라는 게 이 방식의 본질적 차이다. MoE의 Top-K 선택은 비미분적(non-differentiable)이고 그 때문에 gradient가 라우터를 통해 깔끔하게 흐르지 않는다. MoT는 weighted average이므로 엔드투엔드 미분이 그냥 된다. auxiliary loss 없이도 자동으로 균형이 잡히고, Expert Collapse도 구조적으로 발생하지 않는다 — 모든 전문가가 배치 내 전체 토큰 풀에 접근하기 때문이다.
토큰 드롭도 없다. MoE는 expert buffer capacity를 초과하는 토큰을 드롭하거나 패딩으로 처리하지만, MoT는 가중치 합산 구조상 모든 토큰이 각 전문가 입력에 기여한다.
논문이 보고하는 수치로는 vanilla Transformer와 동등한 품질을 달성하면서 벽시계 학습 시간 3배 단축, FLOPs는 4분의 1 수준이다. Baseline 모델의 최종 손실에 도달하는 학습 스텝이 24% 수준이다.
오토리그레시브 디코딩에서는 제약이 따른다. MoT는 배치 내 다른 시퀀스의 토큰을 섞으므로, 인과적 마스킹(causal masking)을 유지하려면 같은 시퀀스 포지션에 있는 토큰들끼리만 혼합해야 한다. 배치가 충분히 클 때 섞을 풀이 넓어져 이점이 극대화되고, 단일 샘플 추론에서는 섞을 토큰이 없어 효과가 줄어든다.
MoE vs MoT: 어떤 병목을 공략하는가
두 방식을 같은 축에서 비교하면:
| 비교 축 | MoE (Top-K 라우팅) | MoT (소프트 토큰 혼합) |
|---|---|---|
| 라우팅 단위 | 토큰 → 전문가 선택 | 전문가 ← 여러 토큰 혼합 |
| 로드 밸런싱 | auxiliary loss 필수 | 구조적으로 자동 균일 |
| 토큰 드롭 | 발생 가능 (capacity 초과 시) | 없음 |
| 분산 통신 비용 | 높음 (all-to-all) | 낮음 (배치 내 처리) |
| 학습 안정성 | Expert Collapse 위험 | 상대적으로 안정적 |
MoE가 실제로 원하는 것은 도메인 전문화다. 서로 다른 입력 패턴을 각기 다른 전문가가 처리하면 같은 파라미터 수의 Dense 모델보다 다양한 지식을 인코딩할 수 있고, Mixtral의 수치(46.7B 전체, 13B 활성)가 그 결과다. 대신 그 전문화를 유지하는 데 엔지니어링 비용이 따른다 — auxiliary loss 계수 튜닝, expert capacity 설정, 분산 환경의 all-to-all 통신이 모두 손이 간다.
MoT가 원하는 것은 학습 효율이다. 안정성과 수렴 속도에 집중하고, 라우팅 불균형이라는 엔지니어링 문제를 구조 자체로 없앤다. 대신 MoE처럼 명시적인 도메인 전문화가 일어나는지, 서빙 시 배치 의존성이 어떤 영향을 주는지는 아직 분석이 많지 않다.
Mixture-of-Depths(Raposo et al., 2024)도 같은 스펙트럼 위에 있다. 전문가가 아닌 레이어를 토큰별로 건너뛰는 방식으로, "어떤 레이어를 계산할지"를 토큰이 결정한다. MoE가 "어떤 전문가를", MoT가 "어떤 토큰들을", MoD가 "어떤 레이어를" 희소하게 처리할지를 각자 다른 차원에서 구현한다.
선택 기준
HuggingFace의 MoE 가이드에서도 확인할 수 있듯, MoE는 이미 프로덕션에서 충분히 검증된 선택이다. Mixtral, Qwen, DeepSeek 등 주요 오픈소스 모델이 MoE 기반이고, vLLM을 포함한 서빙 라이브러리 지원도 갖춰져 있다. 도메인 다양성이 높고 여러 GPU에 분산할 수 있는 인프라라면 MoE는 지금 당장 쓸 수 있는 선택지다.
MoT는 학습 비용이 극도로 중요한 실험 단계, 또는 Expert Collapse와 auxiliary loss 튜닝에 시간을 쓰기 어려운 상황에서 선택지가 된다. 배치 추론 중심의 API 서버라면 MoT의 배치 의존성이 오히려 강점이 되고, 단일 요청 레이턴시가 중요한 온프레미스 단일 GPU 환경이라면 MoE의 예측 가능한 추론 비용이 더 낫다.
MoT에 관심이 있다면 지금은 실험 단계에서만 써보는 게 현실적이다. 서빙 라이브러리 지원이 MoE 수준으로 갖춰지는 시점이 실질적인 전환점이 될 것이다.