MoE 구조가 프로덕션 LLM 서빙에서 보편화된 건 2023-2024년 사이다. Mixtral 8x7B가 공개되면서 "희소 활성화(sparse activation)로 추론 비용이 줄어든다"는 말이 퍼졌는데, 이 말은 절반쯤 사실이다. FLOP은 줄어든다. VRAM은 줄어들지 않는다. 이 비대칭이 MoE 서빙 비용 계산을 단순하게 만들지 않는다.
Mixture of Tokens(MoT)는 이 문제를 다른 방향에서 접근한다. Google DeepMind의 Soft MoE 논문이 제안한 구조인데, 라우팅 결정 자체를 없애버린다. FLOP은 오히려 늘어나지만, 라우팅에서 비롯되는 불균형과 token dropping 문제가 사라진다. 두 구조가 풀려는 병목이 서로 다르다.
MoE의 희소 활성화, 그리고 메모리 역설
Transformer의 FFN 레이어 자리에 N개의 전문가(expert)를 두고, 각 토큰이 라우터를 거쳐 그 중 K개만 선택해서 통과하는 구조다. Shazeer et al. 2017이 제안한 Sparsely-Gated MoE의 핵심 아이디어로, Mixtral 8x7B는 8개 전문가 중 2개를 선택하는 Top-2 라우팅을 쓴다.
토큰당 활성화되는 파라미터는 전체의 K/N에 불과하다. Mistral AI의 기술 보고서에 따르면 Mixtral 8x7B의 전체 파라미터는 46.7B이고, 추론 시 활성화되는 것은 12.9B다. FLOP이 이 비율로 줄어드는 건 맞다.
그런데 VRAM은 다르다. 어떤 토큰이 어느 전문가를 선택할지는 런타임에 결정되므로, 8개 전문가 가중치를 모두 메모리에 올려둬야 한다. Mixtral 8x7B를 BF16으로 서빙하면 약 87-93GB가 필요하다 — A100 80GB 두 장이 필요한 수준이다. 활성 파라미터가 12.9B라고 해서 VRAM이 그 비율로 줄어들지는 않는다.
| Dense 모델(7B급) | Mixtral 8x7B | |
|---|---|---|
| 전체 파라미터 | ~7B | 46.7B |
| 추론 시 활성 파라미터 | ~7B | 12.9B |
| BF16 VRAM 요구량 | ~14GB | ~90GB |
| 토큰당 FLOP | 기준 | 약 2/8 수준 |
FLOP 기준으로는 가볍지만 메모리 기준으로는 훨씬 무겁다. 이 비대칭이 MoE 서빙 비용 계산의 복잡함이다.
메모리 외에 또 다른 문제가 있다. MoE는 각 전문가에게 처리할 수 있는 토큰 수의 상한(expert capacity)을 설정한다.
expert_capacity = (capacity_factor × total_tokens × top_k) / num_experts
배치 안에서 특정 전문가에 토큰이 몰리면 이 버퍼가 초과되고, 넘친 토큰은 해당 전문가를 건너뛴다. 이 drop rate가 프로덕션 환경에서 1-5%를 초과하면 출력 품질에 눈에 띄는 영향이 생기기 시작한다. 라우터가 학습 중에 자기강화(self-reinforcement)로 불균형을 키우는 경향이 있어, 특정 전문가에 트래픽이 계속 몰리는 상태가 정상 상태처럼 자리 잡기 쉽다는 것도 문제다.
Mixture of Tokens: 라우팅 결정 자체를 없애다
Puigcerver et al., ICLR 2024이 제안한 Soft MoE, 즉 Mixture of Tokens의 핵심은 토큰을 특정 전문가에 하드 할당하는 결정을 소프트 가중합으로 대체하는 것이다.
MoE에서는 토큰이 전문가를 선택한다. MoT에서는 각 전문가가 입력 시퀀스의 모든 토큰을 서로 다른 가중치로 혼합해서 받는다. 전문가마다 다른 "soft token" 조합을 입력으로 처리하고, 그 출력을 다시 가중합으로 합쳐서 원래 토큰 위치로 돌려보낸다. 어떤 토큰도 특정 전문가를 배타적으로 선택하지 않는다.
이 구조에서 load imbalance는 없다. 모든 전문가가 동일한 양, 즉 전체 시퀀스의 혼합을 처리한다. Token dropping도 없다. 버퍼를 초과할 개념 자체가 없기 때문이다. 라우팅 결정이 없으니 auxiliary loss를 써서 균형을 강제할 필요도 없다.
논문에서 보고한 수치는 이렇다. ViT Huge/14 대비 40배 이상의 파라미터를 가진 Soft MoE Huge/14(128 experts, 16 MoE layers)가 추론 시간을 2%만 늘리면서 image classification 품질을 크게 높였다. 각 전문가가 처리하는 입력 크기가 전문가 수와 무관하게 고정되어 있어, 전문가 수를 늘려도 개별 전문가의 계산량이 비례해서 늘어나지 않기 때문에 가능한 결과다.
라우팅 방식이 서빙 비용 구조를 어떻게 바꾸는가
두 구조의 차이를 서빙 관점에서 정리하면 다음과 같다.
| MoE (Hard Routing) | MoT (Soft Routing) | |
|---|---|---|
| 토큰당 활성 파라미터 | K/N | 전체 (N개 모두) |
| VRAM 요구량 | 전체 파라미터 상주 | 전체 파라미터 상주 |
| 토큰당 FLOP | 줄어듦 (K/N 비율) | 늘어남 (N배) |
| Load imbalance | 발생 (보조 손실로 완화) | 없음 |
| Token dropping | 발생 가능 | 없음 |
| Routing overhead | 라우터 연산 + scatter/gather | 가중합 행렬 연산 |
| 배치 효율성 | 배치 클수록 개선 | 배치 크기 무관하게 균일 |
MoE의 GPU 활용률 문제는 디코딩 단계에서 두드러진다. 배치 내 각 토큰이 다른 전문가를 선택하면, 각 전문가 입장에서는 자신에게 배정된 토큰만 처리하게 된다. FFN 관점에서 실효 배치 사이즈가 전체 배치의 K/N 수준으로 줄어드는 셈이다. vLLM의 expert parallelism 문서도 이 문제를 명시적으로 인정한다 — EP를 활성화해도 디코딩 단계에서 각 전문가가 처리하는 배치 크기가 줄어들어 GPU 활용률이 하락한다고.
배치 크기가 커질수록 이 문제는 완화된다. 배치 128짜리 요청이면 Mixtral 기준으로 각 전문가가 평균 32개 토큰(128 × 2/8)을 받아 처리할 수 있고, GPU는 이 정도 크기에서 합리적인 활용률을 낸다. 배치 크기 1짜리 단일 요청에서는 라우팅과 scatter/gather 오버헤드가 실제 행렬 연산 비용보다 커지는 상황이 생긴다. MoE가 단일 요청 레이턴시보다 배치 처리량(throughput)에서 강점이 두드러지는 이유다.
MoT는 이 구조적 문제가 없다. 모든 전문가가 항상 전체 입력을 처리하므로 배치 크기와 무관하게 GPU 활용률이 균일하다. 대신 전문가 수만큼 FLOP이 정직하게 늘어난다. 이건 숨길 수 없는 비용이다.
현재 프로덕션에서의 선택
Mixtral 8x7B, DeepSeek-MoE, Grok-1이 모두 MoE를 선택했다. DeepSeek-MoE는 전문가를 더 잘게 분리(fine-grained expert)하고 일부를 모든 토큰이 공유하는 shared expert로 지정해서 load imbalance를 줄이면서 전문화를 개선하는 방향으로 발전시켰다. vLLM과 TensorRT-LLM은 모두 MoE expert parallelism을 지원하며, vLLM v1(2025년 초)에서는 FlashInfer와 MoE 커널 오토튜닝을 추가해 배치 크기별 최적 설정을 스타트업 시점에 자동 선택한다.
MoT가 프로덕션 서빙에서 거의 쓰이지 않는 건 이 구조적 이유 때문이다. MoE를 택하는 첫 번째 이유가 FLOP 절감인데, MoT는 그걸 포기한다. Soft MoE 논문이 vision transformer 실험을 중심으로 결과를 제시한 것도, LLM 스케일에서 모든 전문가에 대한 전체 시퀀스 가중합 연산이 실제로 얼마나 비싼지에 대한 답이 아직 충분하지 않다는 뜻이다.
MoE는 배치가 충분히 크고 expert parallelism 인프라를 갖출 수 있을 때 선택하는 구조다. 라우팅 불안정성이 허용되지 않거나 FLOP 예산이 여유롭다면, 또는 학습 안정성이 최우선인 연구 맥락이라면 MoT 계열을 고려할 수 있다. 두 구조는 서로 다른 병목을 갖는다 — MoE는 라우팅 결정과 통신, MoT는 연산량 자체. 어느 병목이 더 비싼지는 하드웨어와 워크로드가 결정한다.