MoE(Mixture of Experts)를 서빙해본 사람이라면 이상한 경험을 했을 것이다. 활성 파라미터 수는 작다고 했는데 GPU 메모리는 가득 찼고, 배치 크기가 작아질수록 처리량이 예상보다 훨씬 빠르게 무너진다. 이 간격은 MoE 라우팅 구조 자체에서 온다.
MoE 기본 구조 — 왜 추론이 비싼가
MoE의 핵심은 FFN(Feed-Forward Network) 레이어를 N개로 복제해 놓고, 각 토큰마다 그 중 top-k개를 골라 통과시키는 구조다. Mixtral 8x7B는 8개 전문가 중 항상 2개를 선택한다. 활성 파라미터는 12.9B, 전체 파라미터는 46.7B다. 연산량만 보면 13B 모델과 비슷하다.
여기서 함정이 있다. 연산량은 줄어도 메모리 점유는 줄지 않는다. 어떤 토큰이 어떤 전문가를 선택할지 미리 알 수 없으므로, 8개 전문가 파라미터 전부를 GPU 메모리에 올려두어야 한다. Mixtral 8x7B를 FP16으로 서빙하면 약 90GB가 필요하다. H100 한 장(80GB)으로는 모자라다.
메모리보다 더 다루기 어려운 게 load imbalance다. 라우터가 각 토큰에서 top-k 전문가를 선택하는 구조에서 특정 전문가에게 요청이 쏠리는 현상이 자연스럽게 발생한다. 훈련 중에는 이를 막기 위해 auxiliary load balancing loss를 추가한다. Switch Transformer(Fedus et al., 2022)가 이 방식을 정착시켰는데, 배치 내 각 전문가에게 할당된 토큰 비율 f_i와 라우터 확률 P_i를 곱한 합을 손실에 더해 편중을 억제한다. 효과는 있지만 완전히 해결하지 못한다. 서빙 환경에서는 요청 길이가 제각각이고 배치 구성이 훈련 시와 달라서 imbalance가 다시 나타난다.
분산 서빙으로 가면 통신 비용이 겹친다. 전문가들을 여러 GPU에 나눠 올리는 expert parallelism에서, 각 토큰이 선택한 전문가가 어느 GPU에 있는지에 따라 GPU 간 all-to-all 통신이 발생한다. MoE 레이어 하나를 통과할 때마다 dispatch와 gather, 두 차례의 all-to-all이 필요하다. 배치 크기가 커질수록 이 통신이 전체 추론 시간의 79.2%까지 올라가는 사례가 보고됐다.
Mixture of Tokens — 라우팅 방향이 뒤집히면 무엇이 달라지는가
MoT는 라우팅의 주체를 바꾼다. "각 토큰이 어떤 전문가로 갈 것인가"가 아니라 "각 전문가가 어떤 토큰을 처리할 것인가"를 결정하는 구조다. Expert Choice 라우팅이라고도 부르며, Zhou et al.이 NeurIPS 2022에서 발표한 "Mixture-of-Experts with Expert Choice Routing"에서 구체화됐다.
작동 방식은 이렇다. 전문가 수가 N개이고 배치 내 토큰 수가 T라면, 각 전문가는 배치에서 라우터 점수 상위 c개 토큰을 선택한다(c = k × T / N, k는 평균 전문가 수). 선택 주체가 토큰에서 전문가로 넘어간 것 외에 나머지 구조는 MoE와 동일하다.
이 역전이 load imbalance 문제를 구조적으로 제거한다. 각 전문가가 정확히 c개의 토큰을 처리하도록 설계되어 있으므로, 특정 전문가에 부하가 몰리는 현상이 애초에 생기지 않는다. auxiliary load balancing loss도 필요 없다. MoE에서 훈련 손실을 흐리면서까지 써야 했던 패널티 항이 처음부터 없다.
그러나 이 구조에는 다른 비용이 따른다. 토큰별 전문가 수가 균일하지 않다. 어떤 토큰은 여러 전문가에게 선택받고, 어떤 토큰은 아무 전문가도 고르지 않을 수 있다. prefill 단계에서는 이 가변성이 허용되지만, decode 단계에서는 토큰을 순서대로 하나씩 생성하면서 해당 토큰이 몇 개의 전문가에게 선택될지를 미리 알 수 없다. 배치 전체를 모아야 전문가별 선택 결과가 나오는 구조이기 때문이다. 결국 autoregressive 디코딩을 MoT 구조 그대로 서빙하려면 별도의 구현 전략이 필요하다.
KV 캐시 관점에서도 차이가 있다. MoE는 각 토큰이 어떤 전문가를 거쳤는지 경로가 고정되어 있어 캐시 관리가 비교적 단순하다. MoT에서는 전문가별로 선택한 토큰 집합이 배치마다 달라지므로 캐시 재활용 패턴이 복잡해진다.
서빙 관점에서의 트레이드오프
| 항목 | MoE (Token Choice) | MoT (Expert Choice) |
|---|---|---|
| 부하 균형 | 보조 손실 필요, 런타임 imbalance 잔존 | 구조적으로 완벽한 균형 |
| 토큰 처리 보장 | top-k 초과 시 토큰 드롭 가능 | 전문가가 선택 → 드롭 없음 |
| GPU 메모리 | 전체 전문가 상주 필요 | 동일 |
| All-to-All 통신량 | 토큰 목적지 불균등, 예측 어려움 | 전문가별 처리량 고정, 예측 가능 |
| Decode 서빙 | vLLM·SGLang 등 성숙한 지원 | 구현 복잡, 스택 지원 미성숙 |
| 토큰별 연산량 | 균일 (k × FFN 비용) | 가변 |
고동시성·대배치 환경: MoE는 all-to-all 통신 비중이 배치 크기에 따라 급격히 올라간다. MoT는 전문가별 처리 토큰 수(c)를 배치 크기에 비례해 조정하면 되므로 통신량 예측이 쉽고 throughput 확장성도 이론상 낫다.
소배치·짧은 요청 다수: MoE의 연산 절감 효과가 가장 흔들리는 구간이다. 배치에 토큰이 적으면 전문가 대부분이 유휴 상태가 되고, 전체 전문가 파라미터를 메모리에 올려둔 고정 비용이 절감 효과를 상쇄한다. MoT는 배치 토큰 수에 비례해 전문가가 처리량을 맞추기 때문에 소배치에서도 활용률이 나은 편이다.
긴 컨텍스트 prefill: MoT의 배치 수준 부하 균형이 특히 유리한 구간이다. 수천 개 토큰을 한 번에 처리하는 상황에서 전문가 활용률이 고르게 유지된다. 단 decode 단계에서 MoT를 지원하는 서빙 스택이 현재 주류 프레임워크에는 없어 실제 배포 시 제약이 된다.
실측 수치와 현황
Mixtral of Experts(Jiang et al., 2024)는 top-2 라우팅으로 46.7B 파라미터 중 12.9B만 활성화하지만 서빙에는 90GB FP16이 필요하다. "FLOP은 작다"는 약속이 메모리 비용에는 전달되지 않음을 실물로 보여준다. expert parallelism을 쓰면 all-to-all 오버헤드가 대배치에서 전체 latency의 절반을 훌쩍 넘는다.
Expert Choice 방식에서는 Zhou et al.이 동일 FLOPs 예산에서 token-choice MoE보다 perplexity가 낮고 downstream 정확도가 높다는 결과를 보고했다. dead expert가 없어지고 모든 전문가가 고르게 학습되기 때문이다.
현재 vLLM과 SGLang은 MoE expert parallelism을 지원하고, SGLang은 EP와 grouped GEMM 최적화를 결합해 latency를 개선하고 있다. MoT(Expert Choice) 구조를 decode 단계에서 그대로 서빙하는 기능은 아직 주류 프레임워크에 없다. 아이디어는 NeurIPS 2022에서 검증됐지만 서빙 레벨 구현이 아직 따라오지 못했다. 지금 당장 MoT를 활용하려면 decode 지원을 직접 구현하거나, prefill-only 워크로드(문서 임베딩, 리랭킹 등)에서 쓰는 방식이 현실적이다.