Sparse Mixture of Experts(MoE)는 지금 배포 중인 주요 LLM 아키텍처다. Mixtral 8x7B, DeepSeek-V3, Qwen2-57B-A14B가 모두 이 범주에 속한다. 파라미터는 많되 활성화는 적게, 이론적으로 FLOPs를 아끼면서 모델 용량을 키울 수 있다. 그런데 실제 서빙 비용이 이론만큼 내려가지 않는 경우가 많다. 그 이유는 라우팅 자체에 있다.
Mixture of Tokens(MoT)는 이 구조를 반대 방향에서 다시 설계한 아키텍처다. 2023년 말 arXiv에 올라와 NeurIPS 2024에 발표된 Mixture of Tokens: Continuous MoE through Cross-Example Aggregation이 기준 논문이다. MoE와 MoT의 차이는 라우팅의 주체와 방향이 뒤집혀 있다는 데 있고, 이 방향 전환이 서빙 비용 구조 전체를 바꾼다.
MoE의 기본 구조와 추론 비용의 실체
Standard transformer의 FFN 블록 자리에 N개의 expert FFN을 두고, 각 토큰마다 그 중 top-k를 선택해 실행한다. Mixtral 8x7B는 레이어당 expert 8개, 토큰당 top-2를 선택하는 구조다. 전체 파라미터는 46.7B지만 한 번의 forward pass에 실제로 연산하는 파라미터는 12.9B 수준이다.
라우팅은 게이팅 네트워크(선형 레이어 + softmax)가 각 토큰에 대해 expert별 점수를 계산하고, 점수가 높은 k개를 선택하는 방식으로 동작한다. 이 단순함이 세 가지 실제 비용을 낳는다.
Expert load imbalance. 게이팅 네트워크가 특정 expert를 편향되게 선택하는 현상은 학습 초기부터 나타나고 한번 고착되면 교정하기 어렵다. Mixtral 8x7B에서는 최대 25%까지 expert 간 처리 토큰 수가 불균형하게 분포한다. 더 구체적으로는, 초반 레이어와 마지막 레이어에서 소수의 expert에게 토큰이 몰리는 경향이 뚜렷하고 중간 레이어는 상대적으로 균일하다. 배치 크기가 작을수록 이 불균형이 심해진다 — 충분한 토큰이 없으면 확률적으로 고른 분포가 나오기 어렵고, 배치 1 수준에서는 한두 expert에 전부 몰리는 경우도 생긴다.
All-to-all 통신. 분산 서빙에서 expert parallelism을 쓰면 각 GPU가 서로 다른 expert를 담당한다. 토큰이 어느 expert로 가야 할지는 게이팅 결과가 나온 뒤에야 알 수 있으므로, 모든 GPU가 자신의 토큰을 담당 expert가 있는 GPU로 보내고 결과를 다시 받아오는 all-to-all 통신이 레이어마다 두 번씩 발생한다. NVLink 도메인 내에서도 총 실행 시간의 약 20%를 잡아먹고, EP를 단일 노드에서 8노드로 확장하면 all-to-all 비율이 22%에서 78%까지 치솟는다. Expert 수가 많은 모델일수록 이 오버헤드가 더 일찍 지배적이 된다.
KV 캐시 파편화. 동일한 프롬프트 내에서도 레이어마다 다른 expert 조합이 선택되면, KV 캐시가 어느 expert의 컨텍스트를 기반으로 생성된 것인지 추적하기 복잡해진다. prefill과 decode 단계에서 expert 선택 패턴이 달라지면 캐시 재활용률이 떨어진다.
이 세 비용이 이론 FLOPs 절감을 잠식한다. "파라미터의 1/4만 활성화하니까 4배 빠르다"는 주장이 실제 서빙에서 맞지 않는 이유다.
Mixture of Tokens란 무엇인가 — 라우팅 방향을 뒤집다
MoT는 이 구조를 반대로 뒤집는다. 토큰이 expert를 고르는 것이 아니라, expert가 토큰 집합 전체에 soft하게 접근한다.
각 expert가 배치 내 모든 토큰(cross-example으로 혼합된 토큰 집합)에 대해 어텐션 유사 메커니즘으로 가중치를 계산해 집계된 표현을 받는다. 특정 토큰이 특정 expert로 라우팅되는 과정 자체가 없다. Expert 입장에서 토큰 풀 전체를 부드럽게 보고 자신에게 필요한 정보를 직접 추출하는 구조다. 논문의 표현을 빌리면 "cross-example aggregation" — 배치 내 서로 다른 예시들의 토큰이 섞인 혼합물을 각 expert가 처리한다.
이 방향 전환의 즉각적 효과는 load balance 문제의 구조적 소거다. 특정 expert가 과부하를 받는 현상 자체가 사라진다. Expert 수에 맞게 연산이 정확히 분할되고, auxiliary load balancing loss도 필요 없다. 학습 안정성도 올라간다 — MoE top-k의 discrete 선택은 gradient가 선택되지 않은 expert로 흐르지 않아 학습 후반에 dead expert가 생기는 문제가 알려져 있는데, MoT의 soft 접근은 모든 expert가 매 스텝 gradient를 받는다.
성능 수치로는, 동일한 FLOPs 기준에서 dense transformer 대비 학습 속도 3배를 보고했고 state-of-the-art MoE 아키텍처와 동등한 성능을 달성했다. Autoregressive 생성과의 호환성도 확보했다 — 이전의 soft/continuous MoE 계열이 자기회귀 추론을 지원하지 못하거나 성능이 크게 떨어졌던 문제를 이 논문이 처음으로 해결했다.
다만 새로운 비용이 생긴다. Expert가 배치 내 전체 토큰을 봐야 하므로, 시퀀스 길이와 배치 크기가 커질수록 메모리 접근량과 계산량이 선형 이상으로 증가한다. MoE에서는 토큰이 자신이 갈 expert만 보면 됐지만, MoT에서는 모든 expert가 전체 토큰 풀을 참조한다. 이 접근 비용은 메모리 대역폭 병목으로 직결된다.
추론 시 어디서 갈리는가
두 아키텍처가 실제 서빙에서 부딪히는 병목은 위치가 다르다.
MoE는 통신이 병목이다. Expert parallelism에서 all-to-all이 필수고, 이 통신 지연은 GPU 간 인터커넥트 속도에 직결된다. InfiniBand를 넘어가는 순간 지연이 급격히 커지고, expert 수가 많을수록(DeepSeek-V3는 256 expert) 라우팅 복잡도와 통신 빈도 모두 증가한다.
vLLM에서 MoE 모델을 서빙할 때 EP(expert parallelism)와 TP(tensor parallelism)를 조합하면 TP 단독 대비 의미 있는 차이가 난다. H100 기준 Qwen3.5-35B-A3B 모델 실측:
| 전략 | 처리량 (tok/s) | TPOT (ms) |
|---|---|---|
| TP=2 (EP 없음) | 5,419 | 60.85 |
| EP+TP=4 | 7,188 | 41.49 |
약 33% 처리량 향상, 32% latency 단축이다. vLLM에서 EP를 활성화하는 명령어:
vllm serve Qwen/Qwen3.5-35B-A3B \
--tensor-parallel-size 4 \
--enable-expert-parallel \
--gpu-memory-utilization 0.9 \
--max-model-len 32768
MoT는 메모리 대역폭이 병목이다. 배치 내 전체 토큰에 대한 접근을 expert 수만큼 반복하므로, 배치 크기 B, 시퀀스 길이 L, expert 수 E 기준으로 메모리 접근 복잡도가 O(B × L × E)가 된다. 배치나 시퀀스가 길어지면 선형보다 빠르게 메모리 대역폭 한계에 도달한다. All-to-all 통신이 없으므로 단일 노드 환경에서는 MoT가 통신 지연에서 자유롭지만, 시퀀스 길이가 길어질수록 이 이점이 빠르게 상쇄된다.
배치 크기가 크고 시퀀스가 긴 환경에서는 MoT의 메모리 접근 비용이 급격히 커진다. 분산 다노드 환경에서는 MoE의 all-to-all 통신 오버헤드가 지배적이 된다. 어느 쪽이 더 나쁜 병목인지는 서빙 환경의 스펙에 달려 있다.
현황과 실제 선택
지금 대규모 서빙에 쓰이는 아키텍처는 사실상 전부 MoE다. vLLM, TGI 같은 주요 서빙 프레임워크는 expert parallelism 기반 MoE 최적화에 수년간 투자가 누적되어 있다. MoT 계열은 연구 단계에 머물러 있고 이런 프레임워크에서 일급 지원을 받지 못한다.
이유는 구조적이다. MoT가 배치 내 토큰 혼합을 전제하기 때문에, 현재 서빙 프레임워크가 당연하게 여기는 "요청 단위 격리 처리" 패러다임과 맞지 않는다. 서빙에서는 각 사용자 요청이 독립적으로 처리되는 것이 기본 가정인데, MoT는 expert가 배치 내 다른 요청의 토큰까지 함께 보는 구조다. 이 구조를 안전하게 서빙하려면 배치 구성 전략, 메모리 관리, 스케줄링 로직을 처음부터 재설계해야 한다.
서빙 엔지니어 관점에서 지금 당장 선택해야 한다면 MoE가 현실적이다. 다만 MoT가 구조적으로 소거하는 문제들 — load imbalance, dead expert, auxiliary loss 튜닝 — 은 MoE에서 실제로 골머리를 썩이는 문제다. 그 해결책이 아직 운영 환경으로 내려오지 않았을 뿐이다.