Dense 모델을 생각해보면, 파라미터가 70B짜리라도 토큰 하나를 처리할 때 70B 전체가 돌아간다. 이 사실이 LLM 서빙에서 GPU 비용의 근본 원인이다. 같은 성능을 내면서 토큰당 활성 파라미터를 줄일 수 없을까—이 질문에서 희소 활성화(sparse activation) 전략들이 나왔다.
MoE(Mixture of Experts)는 이미 현장에서 쓰이는 답이다. Mixtral-8x7B, DeepSeek-V2, Grok-1이 이 구조 위에 있다. 그런데 최근 "Mixture of Tokens(MoT)"라는 이름이 논문들에서 등장하기 시작했다. MoE의 변종처럼 보이지만 라우팅의 방향이 정반대여서, 추론 시점에서 다른 병목이 나타난다. 두 전략을 서빙 비용 관점에서 나란히 놓으면 어디가 같고 어디가 갈라지는지가 보인다.
MoE: 토큰이 전문가를 고른다
MoE의 핵심 구조는 각 레이어의 FFN 블록을 E개의 독립된 전문가로 교체하고, 토큰마다 router가 그 중 top-k개만 선택해 통과시키는 방식이다. Mixtral-8x7B 기준으로 레이어마다 8개 전문가가 있고 k=2—각 토큰은 항상 2개만 쓴다. 전체 파라미터 합은 46.7B지만 추론 시 활성 파라미터는 12.9B로, Llama 2 70B 대비 약 19% FLOP으로 비슷한 성능이 나온다.
이 구조에서 추론 시 세 가지 문제가 겹친다.
전문가 부하 불균형이다. 배치 내 토큰이 8개 전문가에 균등하게 분산되어야 하지만, 특정 전문가가 집중적으로 선택되는 현상이 훈련 중에 나타난다. 이를 막으려고 auxiliary loss를 추가하는데, 이것 자체가 최적 routing을 제약하는 트레이드오프다. DeepSeek-V2는 여기서 한 걸음 더 나가서 expert-level, device-level, communication-level 세 종류의 보조 손실을 쓰고, 162개 전문가(160 routed + 2 shared) 중 6개를 활성화하는 세밀한 설계를 택했다.
GPU 활용률 저하도 있다. 배치 안에 토큰이 100개 있으면 각자 다른 전문가 조합을 선택할 수 있다. 어떤 전문가는 20개 토큰이 몰리고, 어떤 전문가는 3개만 들어온다. 3개짜리 전문가는 GPU 행렬 연산에서 배치 차원이 너무 작아 메모리 대역폭을 제대로 쓰지 못한다.
그리고 all-to-all 통신이다. 멀티 GPU 환경에서 expert parallelism을 쓰면 각 레이어마다 토큰을 담당 전문가 GPU로 보냈다가 다시 받아야 한다. vLLM이 Wide Expert Parallelism(Wide-EP) 도입으로 per-GPU 처리량을 1.8x 높였다는 게 2025년 말 기준 수치인데, 역설적으로 이 수치가 나오기까지 all-to-all이 그만큼 병목이었다는 뜻이기도 하다.
Mixture of Tokens: 라우팅이 뒤집히면 무엇이 달라지나
MoT의 출발점은 간단한 역전이다. 토큰이 전문가를 고르는 게 아니라, 전문가가 처리할 토큰을 고른다면.
이 아이디어의 초기 형태는 Zhou et al. (2022)의 Expert Choice Routing이다. 각 전문가가 배치 내 전체 토큰 중에서 자신이 처리할 상위 c개 토큰을 선택한다. 전문가마다 처리 토큰 수가 정확히 c개로 고정되므로 부하 불균형이 구조적으로 발생하지 않는다. 보조 손실 없이 완벽한 load balancing이 된다. 이 논문에서 Switch Transformer(top-1 routing) 및 GShard(top-2 routing) 대비 훈련 수렴이 2배 이상 빠르다는 결과가 나왔다.
2023년의 Mixture of Tokens(arXiv:2310.15961)는 여기서 더 나간다. 이산적(discrete) 토큰 선택이 아니라 연속적(continuous) 집계를 한다. 각 전문가는 배치 내 토큰들에 대해 softmax 가중치를 구하고, 그 가중 합으로 입력을 구성해 처리한 뒤 결과를 다시 토큰들에 분산한다. 토큰이 하나의 전문가에 통째로 가는 게 아니라, 여러 토큰의 정보가 섞인 상태로 전문가를 거친다.
이 역전이 계산 패턴을 어떻게 바꾸는지가 핵심이다.
MoE에서는 배치 내 토큰 분포가 어떻게 되든 router 결과가 나올 때까지 전문가별 워크로드를 알 수 없다. 전문가별 처리 토큰 수가 런타임에 결정된다. MoT에서는 각 전문가가 처리할 토큰 수(c개)가 사전에 고정이다. 이 고정성이 GPU 커널 최적화 관점에서 유리하다—배치 행렬 연산의 shape이 예측 가능해진다.
그러나 새 제약이 생긴다. KV 캐시 접근 패턴이다. 자기회귀 생성(autoregressive decoding)에서 KV 캐시는 이전 토큰들의 key, value를 저장해둔다. MoT에서는 전문가가 처리하는 입력이 여러 토큰의 가중 합이기 때문에, 이 "혼합된" 표현에 대한 KV 캐시 관리가 비자명해진다. 생성 단계에서 배치 구성이 바뀌면 각 전문가가 보는 토큰 혼합이 달라지는 문제도 있다. Prefix caching이나 PagedAttention 같은 최적화가 토큰 단위 정체성을 전제로 설계된 이상, MoT와의 결합은 별도 설계가 필요하다.
추론 비용이 갈라지는 지점
FLOP 수만 보면 두 방식은 비슷하다. 8개 전문가에서 top-2를 쓰든, 각 전문가가 전체 토큰의 25%를 처리하든, 실행되는 FFN 연산량은 유사하다. 하지만 실제 레이턴시와 처리량은 FLOP 이외의 요소에서 갈린다.
| MoE (token choice) | MoT (expert choice / soft) | |
|---|---|---|
| 로드 밸런싱 | 보조 손실 필요 | 구조적으로 보장 |
| GPU 커널 shape | 전문가마다 토큰 수 불균등 | 전문가당 토큰 수 고정 |
| all-to-all 통신 | expert parallelism 시 레이어마다 발생 | 동일 구조, 혼합 표현 처리 |
| KV 캐시 호환성 | PagedAttention 표준 동작 | decoding 시 비자명 |
| 서빙 스택 지원 | vLLM, TGI 등 성숙 | 초기 단계 |
멀티 GPU 배포에서 all-to-all이 실제로 얼마나 아픈지는 스케일에 따라 다르다. vLLM의 DeepSeek 대규모 서빙 실험에서 8-GPU expert parallelism 환경에서 H200당 2.2k 토큰/초를 달성했는데, 이는 FlashInfer 통합과 커널 자동 튜닝이 들어간 결과다.
배치 크기가 작은 low-latency 시나리오에서는 MoE의 불균형 문제가 더 도드라진다. 토큰 수가 적을수록 전문가별 토큰 수 분산이 커지고 GPU 활용률이 떨어진다. MoT의 고정 토큰 수 보장은 이 시나리오에서 이론적으로 유리하지만, 소규모 배치에서 soft mixing의 실제 레이턴시가 얼마인지는 공개된 측정치가 없다. "FLOP이 같으면 효율도 같다"는 추론은 두 방식 모두에서 틀린다—메모리 접근 패턴과 통신 비용이 FLOP과 따로 움직이기 때문이다.
서빙 스택이 아직 MoE 편이다
vLLM은 expert parallelism을 정식 지원하고, Mixtral-8x7B, Mixtral-8x22B, DeepSeek-V2/V3 시리즈를 프로덕션에서 서빙할 수 있다. Mixtral-8x7B에서 FP8 양자화로 H100 기준 FP16 대비 25~30% 처리량 향상도 확인됐다.
MoT 모델을 지원하는 서빙 프레임워크는 2026년 현재 시점에서 별도로 존재하지 않는다. 학습 코드는 공개된 것들이 있지만 continuous batching, paged KV cache, 양자화가 갖춰진 서빙 스택이 없다. 이 공백이 실제 배포 결정에서 MoT를 불리하게 만든다. load balancing이 더 깔끔하고 GPU 커널 효율 측면에서 유리할 가능성이 있어도, 서빙 인프라가 없으면 프로덕션 투입 자체가 어렵다.
MoT의 라우팅 아이디어가 실제 서빙 이점으로 이어지는지 확인하려면 decoding 단계 KV 캐시 문제를 해결한 구현체가 나와야 한다. 그게 나오기 전까지는 "이론적으로 병목 위치가 다르다"는 수준에서 멈춘다.