Mixture of Experts(MoE) 구조를 이해할 때 가장 먼저 나오는 숫자가 Mixtral 8x7B의 것이다. 전체 파라미터는 47B인데 토큰당 활성화 파라미터는 약 13B다. 각 레이어의 8개 FFN expert 중 top-2만 선택되니, attention (~5B) + 선택된 FFN 2개 (~2×4B) = 약 13B의 연산이 발생한다. 연산량은 dense 13B 모델과 비슷하면서 품질은 Llama 2 70B 수준이다.
이 구조는 FLOPs를 줄이지만 메모리 요구량은 그대로다. 47B 전체가 GPU에 올라가 있어야 한다. bfloat16 기준 약 94GB라 A100 80GB 단일 장비로는 올라가지 않는다. sparse model serving이 매력적인 동시에 까다로운 이유다.
Mixture of Tokens(MoT)는 같은 희소성 아이디어에서 출발해 라우팅 단위를 뒤집는다. MoE에서 gate network는 각 토큰에게 어느 expert로 가라고 지시한다. MoT에서는 각 토큰이 여러 expert의 결과를 soft하게 섞어 받는다. 이 라우팅 단위의 차이가 서빙 레이어에서 전혀 다른 문제를 만든다.
MoE: expert capacity, token dropping, 분산 서빙 비용
MoE 라우팅의 핵심 제약은 Switch Transformer(Fedus et al., 2021)가 공식화한 expert capacity다.
expert capacity = (T / N) × capacity_factor
T는 배치 내 총 토큰 수, N은 expert 수, capacity_factor는 보통 1.0~1.25 사이다. 각 expert는 이 용량까지만 토큰을 받고, 초과분은 해당 expert를 건너뛴다. 이게 token dropping이다.
token dropping은 버그가 아니라 capacity 설계의 트레이드오프다. capacity_factor를 높이면 drop이 줄어드는 대신 메모리와 연산 낭비가 생기고, 낮추면 drop이 잦아져 품질이 저하된다. 잘 튜닝된 모델에서 token drop rate는 훈련 분포 기준으로 1% 미만을 유지한다. 서빙 시 배치 구성이 훈련 분포와 달라지면 특정 expert에 부하가 몰려 drop이 튀기 시작한다. 배치 크기 1에서는 거의 발생하지 않다가 배치가 커질수록 비결정론적으로 증가하는 게 이 문제의 성격이다. 이를 서빙 레이어에서 무시하면 품질 저하가 배치 크기에 따라 예측 불가능하게 발생한다.
load imbalance는 여기서 직접 이어진다. 배치 내 토큰들이 의미적으로 유사하면(동일 도메인 쿼리가 한 배치에 묶이는 상황) 같은 expert에 집중되고, 나머지 expert들은 idle 상태가 된다. auxiliary load balancing loss를 훈련에 써서 균등 분배를 유도하지만, 이건 훈련 시 incentive지 서빙 때 보장이 아니다. 입력 도메인이 바뀌면 imbalance가 다시 나타난다.
분산 서빙에서는 통신 구조도 달라진다. dense 모델의 텐서 병렬화는 all-reduce 패턴이다 — 각 GPU가 레이어를 나눠 연산하고 합산한다. MoE는 어떤 토큰이 어느 GPU의 expert로 가야 하는지가 동적으로 결정되므로 all-to-all 통신이 발생한다. all-to-all은 배치 내 모든 토큰을 각 담당 expert가 있는 GPU로 보내고 처리 결과를 다시 받는 과정이다. 통신 바이트 수는 배치 크기 × 시퀀스 길이 × 히든 차원 규모로 올라가고, expert를 어느 GPU에 배치하느냐가 서빙 latency의 핵심 변수가 된다.
vLLM은 --enable-expert-parallel 플래그로 MoE 전용 expert 병렬화를 지원한다. 기본 tensor parallelism이 레이어를 column/row-wise로 나누는 방식과 달리, expert parallelism은 expert 자체를 GPU별로 분산한다. 단일 노드에서의 설정 예다.
vllm serve mistralai/Mixtral-8x7B-v0.1 \
--tensor-parallel-size 1 \
--data-parallel-size 8 \
--enable-expert-parallel
TensorRT-LLM에서는 expert_parallel_size를 tensor_parallel_size와 독립적으로 설정해 더 세밀한 제어가 가능하다.
Mixture of Tokens — soft routing이 바꾸는 것
MoT의 접근은 Kim et al. (2023)에서 구체화됐다. 핵심 아이디어는 cross-example aggregation이다. 한 배치 내 여러 예제에서 온 토큰들을 expert로 보내고, 각 expert의 출력을 원래 토큰에 가중합으로 돌려준다. 토큰이 특정 expert에 배정되는 게 아니라 expert 출력의 혼합을 받으니, 구조적으로 token dropping이 발생하지 않는다. 논문은 dense Transformer 대비 3× 학습 속도를 보고했다.
비슷한 방향의 이전 연구로 Zuo et al.의 THOR(ICLR 2022)가 있다. THOR는 gating network를 제거하고 training과 inference 모두 무작위 라우팅을 쓴다. 각 expert가 일관된 예측을 내도록 consistency regularization loss를 추가한다. Switch Transformer를 2 BLEU 초과하면서도 동급 최강 MoE 대비 18배 작은 모델로 유사 성능을 달성했다고 보고했다. 이 연구에서 주목할 점은 gating 기반 라우팅이 무작위 라우팅보다 낫다는 증거를 찾지 못했다는 결론이다 — MoE 연구의 기본 전제에 의문을 던진다.
MoT의 비용 구조는 MoE와 다르다. soft routing은 더 많은 expert 연산을 유지하므로 FLOPs 절감 효과가 hard routing보다 작을 수 있다. top-2 / 8 expert 방식의 MoE가 FFN의 25%만 활성화하는 것과 달리, MoT는 aggregation 방식에 따라 더 높은 비율을 처리한다. KV 캐시 재사용에도 영향을 준다. vLLM의 prefix caching은 같은 prefix에서 KV cache를 재사용하는데, soft routing에서는 같은 토큰이라도 배치 구성에 따라 expert 혼합 비율이 달라질 수 있어 캐시 무효화가 잦아진다.
서빙 관점 직접 비교
| 항목 | MoE (hard routing) | MoT (soft routing) |
|---|---|---|
| token dropping | capacity 초과 시 발생 | 구조적으로 없음 |
| load imbalance | 배치 분포에 따라 발생 | expert 간 균등 처리 |
| activated 비율 | top-k / N (예: 25%) | 높음 (구현 의존) |
| GPU 통신 패턴 | all-to-all | dense에 가까운 all-reduce |
| 배치 크기 감수성 | 클수록 imbalance 완화 | 상대적으로 낮음 |
| KV prefix caching | 가능 | 어려움 |
| 프로덕션 서빙 스택 | vLLM, TensorRT-LLM 지원 | 미지원 |
continuous batching 환경에서 새 request가 합류하는 시점에 두 구조는 다르게 동작한다. MoE에서는 새 request의 토큰이 배치 내 분포를 바꾸어 특정 expert에 추가 부하가 생길 수 있다. capacity buffer 여유가 충분치 않으면 기존 request 토큰의 drop이 시작된다. MoT는 이 문제가 없지만 request 수에 비례해 전체 expert 연산량이 증가하는 구조다.
배치가 클수록 MoE throughput이 올라가는 이유는 토큰 다양성이 커지면서 expert 활용률이 균등해지기 때문이다. 반면 TTFT(Time to First Token)는 배치가 클수록 길어진다. prefill 단계에서 all-to-all 통신이 더 많이 일어나서다.
프로덕션 채택 현황
MoE는 대형 모델 서빙의 현재 기본 구조다. Mixtral 8x7B, DeepSeek-V2, Switch Transformer 모두 hard routing 기반이다. DeepSeek-V2는 fine-grained expert segmentation(각 expert를 더 잘게 쪼개 전문화를 높임) + shared expert(항상 활성화되는 공통 expert)를 추가하고, device-limited routing으로 각 토큰의 target expert를 최대 M개 GPU에만 분산시켜 all-to-all 통신량을 제한했다.
MoT는 아직 연구 단계이며 주요 서빙 스택의 정식 지원이 없다. soft routing이 autoregressive 생성의 KV 캐시 재사용과 어떻게 공존할 수 있는지를 해결하는 것이 MoT가 프로덕션으로 넘어오기 위한 다음 엔지니어링 과제로 남아 있다.