희소 활성화(sparse activation)는 이유가 명확하다. 트랜스포머의 매 레이어에서 모든 파라미터를 모든 토큰에 적용하는 것은 낭비다. 연산 예산이 고정되어 있다면, 그 예산을 더 많은 파라미터에 분산시키거나 더 필요한 위치에만 집중시키는 쪽이 낫다.
MoE(Mixture of Experts)와 MoT(Mixture of Tokens)는 이 동기를 공유한다. 희소성을 구현하는 축이 다를 뿐이다. MoE는 파라미터 공간을 나눈다 — 여러 전문가(expert) 중 일부만 활성화한다. MoT는 각 expert가 처리하는 입력 자체를 배치 내 여러 예시의 토큰 혼합으로 구성한다. 이 한 가지 차이가 서빙 시 메모리와 라우팅 비용의 성격을 완전히 다르게 만든다.
MoE의 구조와 추론 시 실제 비용
MoE의 구조는 단순하다. Transformer FFN 레이어를 N개의 expert로 복제하고, 각 토큰마다 라우터가 그 중 k개를 선택해 연산을 수행한다. Fedus et al. (2022) Switch Transformers는 k=1로 줄여 라우팅 비용을 극단적으로 낮춘 첫 대규모 실험이다. Mixtral-8x7B는 8개 expert 중 2개를 선택하는 k=2 구성이다.
라우터는 토큰 임베딩을 입력으로 받아 softmax 점수를 계산하고, 상위 k개 expert에만 토큰을 보낸다:
gate_scores = softmax(W_g @ x) # shape: [num_experts]
selected = top_k(gate_scores, k=2)
output = sum(gate_scores[i] * FFN_i(x) for i in selected)
이 구조에서 per-token FLOP은 dense 모델 대비 k/N 배로 줄어든다. Mixtral의 경우 2/8 = 25%. k=1이면 절반으로 줄어들지만 특정 expert에 토큰이 쏠리는 load imbalance가 더 심하게 나타난다. k=2는 분산이 낫고 품질도 안정적이지만, 라우팅과 통신 비용이 두 배다.
실제 부담은 메모리다. Mixtral-8x7B는 총 파라미터 46.7B, 토큰당 활성 파라미터는 약 12.9B다. 그러나 추론 중 어느 토큰이 어떤 expert를 선택할지 사전에 알 수 없으므로, 8개 expert 가중치 전부가 GPU 메모리에 상주해야 한다. FP16 기준 약 87GB다. A100 80GB 단일 카드로는 서빙이 불가능하다. 활성 파라미터 12.9B라는 숫자는 VRAM 요구량에 전혀 영향을 주지 않는다.
이 문제를 해결하려면 텐서 병렬(TP) 또는 expert 병렬(EP)로 여러 GPU에 분산해야 한다. EP는 각 expert를 서로 다른 GPU에 올려두고, 토큰이 선택한 expert가 있는 GPU로 이동하는 방식이다. 이 과정에서 all-to-all 통신이 발생한다 — 배치 내 토큰들이 각자의 expert GPU로 흩어졌다가 연산 후 다시 모인다. NVLink 환경에서는 이 비용이 수용 가능하지만, PCIe 연결 환경에서는 throughput 병목이 된다. vLLM은 EP를 공식 지원하며, DeepEP 커널을 통합해 all-to-all 비용을 줄이고, --enable-eplb 플래그로 expert load balancing을 제어한다.
load imbalance는 별도 문제다. 라우터가 특정 expert에 토큰을 몰아주면, capacity를 초과한 토큰은 연산을 건너뛴다. Switch Transformers는 capacity factor를 기본값 1.25로 설정한다:
capacity = ceil(1.25 × tokens_in_batch / num_experts)
이 값을 초과하면 overflow 토큰은 residual connection으로 그냥 통과된다. capacity factor를 높이면 overflow는 줄지만 메모리 낭비가 늘고, 낮추면 token drop이 발생해 품질이 떨어진다. 라우터가 균등하게 토큰을 배분하도록 auxiliary load balancing loss를 함께 사용하는 것이 일반적이지만, 이 보조 손실이 본래 학습 목표와 충돌하는 tradeoff는 남는다.
FLOP 감소가 실제 서빙에서 의미 없다는 것은 아니다. Mixtral-8x7B는 활성 파라미터 기준으로 Llama 2 70B 대비 약 5배 적은 연산을 수행하며, 개별 요청 지연(latency) 측면에서 더 유리하다. 하지만 그 이점을 누리기 위해 치르는 비용이 메모리와 분산 통신 측면에서 크다는 것이 서빙 관점의 핵심이다.
Mixture of Tokens: 토큰이 섞이는 방식
Antoniak et al. (2023)의 MoT는 희소성 구현 방식 자체가 다르다. MoE가 파라미터를 N벌 복제하고 토큰을 이산적으로 라우팅하는 방식이라면, MoT는 각 expert가 처리하는 입력을 배치 내 서로 다른 예시(example)의 토큰 혼합으로 구성한다.
MoT에서 각 expert는 하나의 시퀀스에서 온 토큰만 받는 것이 아니라, 배치 내 여러 시퀀스의 토큰을 가중 혼합한 표현을 처리한다. 라우터가 이 혼합 비율을 학습한다. "Continuous MoE"로도 불리는 이유가 여기 있다 — 토큰을 이산적으로 특정 expert에 배정하는 것이 아니라, 배치 수준에서 연속적으로 혼합 비율을 결정한다.
파라미터 효율은 높다. 논문 보고 수치 기준 dense Transformer 대비 학습 속도 3배 향상이며, 당시 MoE 아키텍처와 동등한 성능이다. expert 가중치를 N벌 복제하지 않으므로, 파라미터 수와 GPU 메모리 요구량이 늘지 않는다.
대신 배치 내 예시 간 의존성이 생긴다.
자동회귀 생성에서 요청 A의 현재 토큰이 배치 내 요청 B의 토큰과 혼합되어 처리된다면, 요청 A의 출력이 배치 구성에 따라 달라진다. 동일한 프롬프트를 보내도 어떤 다른 요청과 함께 배치에 묶이느냐에 따라 결과가 미세하게 바뀔 수 있다. 결정론적이어야 할 추론이 배치 구성에 의존하게 된다.
KV 캐시 문제는 더 구체적이다. vLLM의 PagedAttention은 요청별 KV 캐시를 독립 단위로 관리한다. MoT에서 토큰의 표현이 배치 내 다른 토큰에 영향을 받는다면, 이 요청별 독립성 가정이 맞지 않는다. Prefill 결과를 캐싱하거나 decode 단계에서 토큰을 독립적으로 처리하는 구조가 무너진다. Continuous batching도 — 요청을 언제든 배치에 추가하거나 제거할 수 있다는 유연성이 기반인데 — 배치 내 토큰 의존성이 있으면 그 유연성을 그대로 유지하기 어렵다.
두 방식의 트레이드오프 직접 비교
| 항목 | MoE | MoT |
|---|---|---|
| 가중치 메모리 | expert 수 × FFN 크기 (전부 상주 필요) | dense 모델과 동일 수준 |
| 라우팅 방식 | 이산, top-k expert 선택 | 연속, 배치 토큰 가중 혼합 |
| 요청 간 독립성 | 완전 독립 | 배치 구성 의존 |
| KV 캐시 관리 | 요청별 독립, PagedAttention 호환 | 배치 수준 의존성으로 복잡 |
| 분산 통신 비용 | EP 필요, all-to-all 발생 | 단일 GPU로 충분 |
| load balancing | capacity factor + auxiliary loss 필요 | 연속 혼합으로 불필요 |
| 프로덕션 스택 지원 | vLLM, TRT-LLM 공식 지원 | 범용 지원 없음 |
작은 배치나 단일 GPU 환경에서는 MoT가 유리하다. 파라미터를 N배 복제하지 않아 메모리 부담이 없고, EP와 all-to-all 통신이 불필요하다. 대규모 동시 요청을 처리하는 프로덕션 서빙에서는 MoE가 더 다루기 쉽다. 요청이 서로 독립이기 때문에 continuous batching이 자연스럽고, KV 캐시를 요청 단위로 관리할 수 있다. EP가 복잡하고 메모리가 많이 필요하지만, vLLM과 TRT-LLM이 이 복잡성을 이미 흡수했다.
현재 서빙 스택에서의 현실
vLLM은 Expert Parallelism을 공식 지원하며, DeepEP 커널 통합과 EPLB(Expert Parallel Load Balancer)로 MoE 서빙의 주요 복잡성을 처리한다. TensorRT-LLM도 MoE 전용 플러그인을 포함한다. Mixtral, DeepSeek-V2 같은 모델이 이미 이 경로로 프로덕션에서 서빙된다.
MoT는 다르다. cross-example 토큰 혼합이 vLLM의 PagedAttention이나 continuous batching 아키텍처와 정렬되지 않는다. 같은 추론 스택을 그대로 가져다 쓸 수 없고, 배치 관리와 KV 캐시 로직을 처음부터 다시 설계해야 한다. 현재까지 MoT를 지원하는 범용 추론 프레임워크는 없다.