두 이름이 대칭적으로 생겼다. MoE(Mixture of Experts)가 "이 토큰을 어떤 전문가에게 보낼지"를 선택하는 구조라면, MoT(Mixture of Tokens)는 "어떤 토큰에게 연산을 집중할지"를 선택하는 구조다. 두 방식 모두 모든 파라미터를 항상 다 쓰지 않겠다는 목표를 공유하지만, 희소성의 축이 전문가(파라미터 집합) 쪽이냐 토큰(연산 깊이) 쪽이냐로 반전되어 있어서 서빙 비용이 어디서 쌓이는지가 근본적으로 다르다.
MoE: 희소성이 '전문가 선택'에 있을 때 생기는 일
Mixtral 8×7B가 현재 MoE 구조의 기준점으로 자주 쓰인다. 32개 레이어 각각에 8개의 전문가 FFN이 있고, 각 토큰은 레이어마다 top-2 라우팅으로 그중 2개만 통과한다. 전체 파라미터는 46.7B지만 한 토큰 처리 시 활성화되는 파라미터는 12.9B다. 실제 추론 FLOPs는 Llama 2 70B 대비 약 19% 수준이다. 파라미터 규모가 주는 표현력을 유지하면서 계산량을 극적으로 줄이는 것이 MoE의 명확한 가치다.
서빙 인프라 입장에서는 두 곳에서 비용이 발생한다.
라우팅 불균형이 첫째다. 특정 전문가에 토큰이 편중되면 straggler 문제가 생긴다. 어떤 GPU가 담당 전문가의 과부하로 아직 처리 중일 때, 다른 GPU는 이미 다음 배치를 기다린다. vLLM은 이를 위해 EPLB(Expert Placement with Load Balancing)를 도입했고, forward pass마다 부하 통계를 수집해 주기적으로 전문가를 재배치한다. 코드·수학·자연어 같은 도메인별로 선호하는 전문가가 달라서, 트래픽이 특정 도메인으로 쏠리면 불균형이 더 심해지는 경향이 있다.
AllToAll 통신이 둘째다. 전문가들이 여러 GPU에 나뉘어 배치된 상황에서 각 토큰을 올바른 전문가로 전달하려면 all-to-all 집합 통신이 필요하다. 배치 내 토큰 분산이 고를 때는 효율적이지만, 편중되는 순간 통신 오버헤드와 GPU 유휴 시간이 같이 올라간다. Wide Expert Parallelism처럼 전문가를 NVLink 도메인(8 GPU) 너머 16~72 GPU로 넓게 펼치는 시도는 이 문제를 다른 스케일에서 재접근하는 방향이다.
Mixture of Tokens란 무엇인가
arXiv:2310.15961에 발표된 Mixture of Tokens 논문은 MoE의 하드 라우팅이 가진 불연속성 문제를 정면으로 건드린다. 아이디어는 단순하다. MoE에서 "토큰 A는 전문가 1로, 토큰 B는 전문가 2로"처럼 경계를 딱 그어버리는 대신, 각 전문가가 배치 내 여러 토큰의 가중합을 받아 처리하게 한다. 불연속적인 top-k 선택이 사라지고 토큰이 전문가에 연속적으로 분배되는 구조다. 로드 불균형이 구조적으로 없어진다 — 어떤 토큰도 특정 전문가에 배타적으로 배정되지 않기 때문이다. 논문이 보고한 수치로는 dense transformer 대비 학습 속도 3배 향상이 있고, 성능은 하드 라우팅 MoE와 비등하다.
"토큰별 연산 깊이를 동적으로 정하는" 방향으로 더 나아간 것이 Google DeepMind의 Mixture-of-Depths(MoD, arXiv:2404.02258)다. 레이어마다 top-k 토큰만 attention과 MLP를 실제로 계산하고, 나머지 토큰은 해당 레이어를 residual connection으로 건너뛴다. isoFLOP 조건에서 vanilla transformer 대비 최대 1.5% 성능 향상을 보고했고, forward pass당 FLOPs를 절반 이하로 낮춰도 기준 성능을 유지한다고 밝혔다. 샘플링 속도는 최대 50% 향상이다.
이 계보의 아이디어적 뿌리는 Graves의 Adaptive Computation Time(ACT, 2016)이다. 입력마다 처리 단계 수를 다르게 할당해야 한다는 생각을 RNN에서 처음 구체화했고, Universal Transformer를 거쳐 MoD·MoT 계열로 이어졌다.
희소성의 축이 달라지면 서빙 비용이 어떻게 달라지는가
| MoE (Mixtral 8×7B 기준) | MoT / MoD 계열 | |
|---|---|---|
| 희소성 단위 | 전문가(파라미터 집합) | 토큰(연산 깊이/레이어) |
| 파라미터 메모리 | 전체 전문가 가중치 (46.7B) | dense 모델과 동일 |
| 활성 FLOPs | 낮고 예측 가능 (~12.9B active) | 평균은 낮지만 런타임까지 불확실 |
| 배치 구성 어려움 | 전문가 부하 불균형, AllToAll | 토큰별 연산량 불균일 |
| FLOPs 확정 시점 | 라우팅 결정 즉시 (레이어 진입 시) | 포워드 패스 완료 후 |
| 전문가 간 통신 | AllToAll 필요 | 없음 |
| 서빙 지원 성숙도 | vLLM, SGLang 프로덕션 수준 | 연구 단계 |
FLOPs가 언제 확정되느냐가 서빙에서 핵심 차이다.
MoE는 각 레이어 시작 시점에 라우팅 결정이 나면 그 순간 FLOPs가 정해진다. 한 요청이 전체적으로 얼마나 계산을 쓸지 미리 알 수 있고, 이것이 continuous batching과 비교적 잘 맞는 이유다.
MoD 계열에서는 어떤 토큰이 어떤 레이어를 실제로 통과할지가 포워드 패스를 돌려봐야 안다. 배치 내 요청들이 서로 다른 레이어를 다른 시점에 거치면, 배치를 일정한 깊이로 묶는 게 불가능해진다. 패딩으로 처리하면 얕은 경로를 선택한 토큰들이 빈 연산을 쓴다. 32-레이어 모델에서 배치 내 절반의 토큰이 16레이어만 쓴다고 하면, 32레이어 기준으로 배치를 맞출 경우 GPU 연산의 이론상 약 25%가 패딩 낭비다. 이를 피하려면 비슷한 레이어 깊이를 가진 토큰끼리 배치를 묶어야 하는데, 이는 latency와 처리량 사이에 새로운 트레이드오프를 만든다.
어떤 상황에서 어떤 쪽이 맞는가
두 방식을 "어느 쪽이 낫다"로 결론 내리는 건 질문 자체가 틀렸다. 파라미터 규모를 키우고 싶을 때와 동일한 파라미터 내에서 연산 예산을 줄이고 싶을 때, 목적이 다르기 때문이다.
파라미터 규모 자체를 늘리면서 FLOPs 예산은 유지하고 싶다면 MoE가 맞다. 46.7B 파라미터의 표현력을 갖추면서 13B dense 수준의 계산량으로 추론하겠다는 명확한 트레이드오프다. 대신 전문가 병렬 인프라, 로드 밸런싱, AllToAll 통신 최적화까지 서빙 스택이 받쳐줘야 한다. vLLM과 SGLang은 이 수준의 지원을 이미 갖추고 있다.
동일한 파라미터 크기 내에서 연산 예산을 줄이고 싶다면 MoT/MoD 계열이 맞다. 전문가 통신 오버헤드가 없고 구조도 dense 모델과 크게 다르지 않아 기존 서빙 스택에 통합하기 쉬울 것 같지만 — 실제로는 런타임에 연산량이 결정된다는 특성이 latency SLA를 맞추기 어렵게 만든다. P99 지연을 보장해야 하는 프로덕션에서 MoD를 실전 배치한 사례는 MoE에 비해 아직 드물고, "continuous depth batching" 같은 스케줄러 접근이 탐색되고 있지만 프로덕션 검증과는 거리가 있다.
두 방식을 결합해 토큰별로 전문가와 레이어 깊이를 모두 동적으로 정하는 시도도 연구되고 있다. 최적화 변수가 두 배로 늘어나는 만큼 서빙 복잡도도 배가된다. 성능 이득이 그 복잡도를 정당화할 만한지는 아직 데이터가 부족하다.