두 접근 모두 "모든 파라미터를 매 토큰마다 돌릴 필요는 없다"는 전제에서 출발한다. 그런데 이걸 실제로 구현하는 방식이 정반대다. MoE는 토큰이 전문가를 고르고, Mixture of Tokens는 레이어가 토큰을 고른다. 뒤집힌 라우팅 방향 하나가 서빙 시스템에 완전히 다른 문제를 일으킨다.
라우팅의 방향이 다르다
MoE에서 각 레이어 구조는 동일하게 유지된다. 대신 토큰이 "어느 전문가에게 갈지"를 게이팅 네트워크가 결정한다. Mixtral-8x7B 기준으로 레이어마다 8개 전문가(FFN 블록)가 있고, 토큰 하나당 top-2로 두 전문가를 선택해 출력을 가중합한다. 같은 시퀀스 안의 토큰이라도 서로 다른 전문가로 라우팅된다.
Mixture of Tokens는 반대 방향으로 움직인다. 레이어가 "이번 레이어는 어떤 토큰을 처리할까"를 결정한다. Antoniak et al.의 NeurIPS 2024 논문에서 제안한 MoT는 레이어가 배치 내 여러 예제의 토큰들을 섞어 처리하는 cross-example aggregation을 쓴다. 특정 레이어가 현재 시퀀스의 토큰 A, B와 다른 시퀀스의 토큰 C를 함께 받아 처리하는 구조다.
라우팅 주체가 토큰이냐 레이어냐는 메모리 요구, 배치 구성, GPU 간 통신 패턴 전부를 바꾼다.
MoE 구조: 희소 활성화가 추론 비용에 미치는 실제 영향
Mixtral-8x7B의 총 파라미터는 47B다. 토큰 하나를 처리할 때 실제로 활성화되는 파라미터는 13B뿐이다. 이론적으로는 dense 모델 대비 연산량이 줄어야 맞다.
문제는 서빙이다. 추론 시에도 나머지 34B 파라미터가 GPU 메모리에 올라와 있어야 한다. 어느 토큰이 어느 전문가로 갈지 런타임 전에 알 수 없기 때문이다. Mixtral-8x7B를 서빙하려면 fp16 기준 약 94GB의 GPU 메모리가 필요하다.
멀티-GPU 환경에서는 전문가를 GPU에 분산하는 expert parallelism을 쓴다. vLLM은 이를 위해 allgather_reducescatter, deepep_high_throughput, deepep_low_latency 등 다섯 가지 통신 백엔드를 지원한다. 각 레이어를 처리할 때 토큰을 담당 GPU로 보내고 출력을 다시 모으는 all-to-all 통신이 레이어마다 발생한다. H100/H200 기준 NVLink 단방향 대역폭은 450 GB/s로 이 통신 비용을 감당할 수 있다. PCIe 환경에서는 대역폭이 대략 1/10 수준이어서 all-to-all이 바로 병목이 된다. vLLM 포럼에서는 P2P 연결이 없는 소비자용 GPU에서 naive broadcast 방식으로 폴백하며 불필요한 데이터 전송이 늘어난다고 보고한다.
더 근본적인 문제는 load imbalance다. 게이팅 네트워크가 특정 전문가에 토큰을 몰아주면 해당 GPU만 바빠진다. 최근 연구에 따르면 MoE 레이어당 평균 18.6%의 GPU 시간이 불균형 때문에 낭비되고, 심각한 경우 GPU가 80% 이상의 시간을 유휴 상태로 보낸다. MegaBlocks는 block-sparse 연산으로 이 문제를 완화해 기존 프레임워크 대비 1.8~2.4배 처리량을 달성했지만, 토큰 쏠림 자체를 없애지는 못한다.
Mixtral 논문 실험에서 연속된 토큰이 같은 전문가를 선택하는 비율이 중간 레이어에서 62~67%에 달한다는 점도 주목할 만하다. 이 locality는 캐싱 최적화 기회를 열어주지만, expert parallelism 환경에서는 특정 GPU에 부하가 몰리는 원인이 되기도 한다.
Mixture of Tokens: 레이어가 처리할 토큰을 고른다
모든 레이어가 모든 토큰을 처리하지 않아도 된다는 발상이다. 각 레이어가 "지금 내가 처리할 토큰이 무엇인가"를 선택하고, 나머지는 건너뛴다.
Antoniak et al.의 구현에서 이 선택은 continuous하게 일어난다. 레이어는 배치 내 여러 토큰을 가중합으로 섞어 입력을 구성하는데, 가중치 자체가 학습 가능한 파라미터다. sparse MoE와 달리 완전히 미분 가능하다는 게 구조적으로 중요한 차이다. 기존 discrete top-k 라우팅은 gradient가 끊기는 지점에서 auxiliary loss로 우회해야 했다. MoT는 이 제약이 없다.
성능 측면에서 논문은 dense Transformer 대비 학습 속도 3배, 동급 sparse MoE와 유사한 정확도를 보고한다. 또한 transition tuning이라는 방법으로 학습된 MoE 가중치에서 MoT 구조로 이식하는 경로도 제시한다. 이 기법은 MoT를 처음부터 학습하는 비용 없이 기존 MoE 모델을 MoT로 변환할 가능성을 열어두는데, 실제 서빙 생태계에서 이 경로가 얼마나 유효한지는 아직 검증이 부족하다.
서빙에서 MoT가 만드는 문제는 MoE와 종류가 다르다. expert parallelism이 없으니 GPU 간 all-to-all 통신은 사라진다. 대신 레이어마다 처리하는 토큰 수가 달라지면서 KV 캐시 구조가 흔들린다. 어떤 레이어가 시퀀스 토큰의 60%만 처리한다면, 그 레이어의 KV 캐시는 전체 시퀀스 길이와 일치하지 않는다. 배치 내에서 각 시퀀스가 레이어별로 다른 수의 토큰을 처리하면 패딩이 불규칙해진다. 정적 KV 캐시 할당에 기반한 기존 서빙 스택(PagedAttention 포함)이 MoT를 네이티브로 지원하지 않는 이유가 여기에 있다.
서빙 관점 비교: 메모리, 배치, 레이턴시
| MoE | Mixture of Tokens | |
|---|---|---|
| 전체 파라미터 메모리 | GPU에 전부 상주 필수 | 구조 동일 (절감 없음) |
| GPU 간 통신 | all-to-all (레이어마다) | 없음 |
| 배치 병목 | 토큰 분배 불균형 | 레이어별 가변 토큰 수 |
| KV 캐시 형태 | 레이어 간 균일 | 레이어마다 크기 다름 |
| 주류 프레임워크 지원 | vLLM, TensorRT-LLM 등 | 아직 미지원 |
throughput 위주 워크로드에서 MoE가 상대적으로 잘 맞는다. 배치가 크고 시퀀스가 짧을 때 토큰이 전문가들 사이에 고루 분배될 가능성이 높아지고, all-to-all 통신 오버헤드가 계산 비용에 비해 작아진다. 온라인 추론처럼 배치가 작고 토큰이 한 번에 몇 개씩 오는 환경에서는 통신 비용이 계산 비용을 앞서는 순간이 생긴다.
MoT는 단일 GPU에서도 동작하고 inter-GPU 통신 부담이 없다는 점에서 소규모 배포나 엣지 추론에 이론적으로 유리하다. 다만 가변 토큰 구조를 처리할 서빙 스택이 없는 현재 상황에서는 실측 비교 자체가 어렵다. 활성 파라미터 수만 보면 두 구조 모두 dense 대비 이득처럼 보이지만, MoE에서 서빙 결정을 실제로 가르는 것은 "전체 파라미터를 몇 GPU에 분산할 수 있는가"이고, MoT에서는 "가변 토큰 구조를 배치 스케줄러가 얼마나 효율적으로 처리할 수 있는가"다.
두 접근을 같이 쓸 때
MoE와 token-level sparsity를 동시에 적용하면 FLOPs가 이중으로 줄어야 맞다. 실제로는 스케줄러가 두 단계의 라우팅 결정을 순서대로 처리해야 한다. 첫 번째 단계(토큰 선택)의 결과가 나와야 두 번째 단계(전문가 선택)가 시작되는 순차 의존성이 GPU 파이프라인을 비게 만들고, 라우팅 오버헤드와 스케줄링 복잡도가 중첩된다. 이 때문에 실측 없이 이득을 예측하기 어렵고, 두 기법을 결합한 서빙 시스템에서 이득이 단순 합산되지 않는다.