트랜스포머를 크게 만들면서도 추론 비용을 낮추는 방법으로 두 방향이 있다. 하나는 전문가를 여러 개 두고 그중 일부만 쓰는 것, 다른 하나는 레이어마다 처리할 토큰을 줄이는 것이다. 전자가 Mixture of Experts(MoE)이고, 후자의 대표 구현이 Mixture-of-Depths(MoD)다. 같은 "희소 활성화(sparse activation)" 아이디어지만, 무엇을 건너뛰느냐에 따라 LLM 서빙 시스템이 만나는 문제가 완전히 달라진다.
희소성의 축이 다르다
MoE는 파라미터 공간에서 희소성을 취한다. 각 토큰이 레이어마다 전체 전문가 중 top-k를 선택해 연산한다. 모든 토큰이 모든 레이어를 통과하되, FFN 블록에서 전문가 서브셋만 활성화된다.
Mixture of Tokens(MoT) 또는 MoD 계열은 시퀀스 공간에서 희소성을 취한다. 레이어가 처리할 토큰을 선택한다. 파라미터는 전부 쓰이지만, 시퀀스의 상당 부분이 해당 레이어의 self-attention과 MLP를 건너뛴다. 이 접근을 conditional computation이라고도 부른다.
| MoE | MoT/MoD | |
|---|---|---|
| 희소성 축 | 파라미터 (전문가) | 시퀀스 (토큰) |
| 선택 방향 | 토큰 → 전문가 | 레이어 → 토큰 |
| 처리 토큰 수 | 레이어마다 전체 | 레이어마다 부분집합 |
| VRAM 가중치 | 전체 상주 필요 | dense와 동일 |
MoE 추론의 비용 구조
Mixtral 8x7B는 총 파라미터 46.7B, 토큰당 활성 파라미터 12.9B다. 각 레이어에서 8개 전문가 중 top-2를 선택하는 expert routing 방식이라 추론당 FLOPs는 12.9B dense 모델과 비슷하다. 그런데 46.7B 전체 가중치가 항상 VRAM에 올라가 있어야 하므로 FP16 기준으로 약 93GB가 필요하다. A100 80GB 한 장으로는 올리지 못한다.
메모리보다 실제 서빙에서 더 자주 마주치는 문제는 expert load imbalance다. 배치 내 토큰이 특정 전문가에 몰리면 그 전문가의 capacity가 초과되고 남은 토큰이 드롭된다.
expert_capacity = (tokens_per_batch / num_experts) × capacity_factor
capacity_factor를 1.25로 잡는 게 일반적인 출발점이다. 이론 최대치보다 25% 더 많은 버퍼를 예약하는 셈인데, 요청이 특정 전문가에 쏠리면 그래도 드롭이 발생한다. ST-MoE(Zoph et al., 2022)는 auxiliary load balancing loss로 불균형을 완화했지만 쏠림 자체를 제거하지는 못한다.
배치 크기도 throughput을 크게 좌우한다. MoE에서 배치가 작으면 각 전문가에 배정되는 토큰 수가 적어 GEMM 행렬이 작아지고 GPU 활용률이 낮다. MoE-Inference-Bench(2025) 결과에서 배치 크기 1에서 128로 키웠을 때 throughput이 약 100배 증가했다. 배치가 적을수록 MoE의 희소성이 오히려 독이 된다는 뜻이다.
분산 추론에서는 all-to-all 통신이 추가된다. 토큰을 담당 전문가가 있는 GPU로 보내야 하기 때문이다. vLLM은 fused MoE 커널로 전문가 선택·라우팅·FFN 연산을 단일 커널에 합쳐 이를 완화하지만, expert parallelism은 벤치마크에서 tensor parallelism 대비 일관되게 낮은 GPU 활용률을 보인다.
Mixture of Tokens: 토큰을 건너뛰는 방식
Raposo et al. (2024)의 Mixture-of-Depths가 이 계열의 핵심 작업이다. 각 트랜스포머 레이어에서 처리할 토큰 수를 k개로 고정하고, 학습된 라우터가 상위 k개 토큰을 선택해 self-attention과 MLP를 통과시킨다. 나머지 토큰은 residual connection만 타고 넘어간다.
k를 미리 고정하므로 계산 그래프가 정적으로 유지된다. XLA나 CUDA 그래프 최적화를 그대로 적용할 수 있다는 구현 장점이다. 논문 결과, 시퀀스의 50% 토큰만 처리하도록 설정했을 때 동일 FLOPs 예산에서 vanilla 트랜스포머 대비 최대 1.5% 낮은 훈련 loss를 달성했다. forward pass당 FLOPs를 절반으로 줄이면서 성능이 오히려 올라간다.
어떤 토큰이 스킵되는지 관찰하면 패턴이 있다. 공백, 구두점, 앞뒤 컨텍스트로 충분히 예측 가능한 연속 토큰은 얕은 레이어를 건너뛰는 경향이 있다. 드문 단어, 문장 전환점, 의미론적으로 중요한 위치의 토큰은 더 많은 레이어에서 처리된다. "얼마나 많이 생각할지"를 모델이 스스로 결정하는 구조라서 MoT LLM이라는 별칭이 붙는다.
서빙 관점에서 무엇이 달라지나
| 항목 | MoE | MoT/MoD |
|---|---|---|
| VRAM 풋프린트 | 크다 (전체 가중치 상주) | dense와 동일 |
| prefill 예측성 | 배치 구성에 따라 가변 | 토큰별 가변 (더 불확실) |
| 분산 통신 오버헤드 | all-to-all 추가 | 없음 |
| 배치 처리 효율 | 클수록 좋음 | 상대적으로 둔감 |
| production 서빙 성숙도 | 높음 (vLLM, TRT-LLM, SGLang) | 연구 단계 |
MoE는 VRAM이 많이 필요하지만 배치가 크면 전문가 간 부하가 분산되고 GPU 활용률이 올라간다. Mixtral, Grok 계열이 지금 실서비스에서 이 포지션을 차지하고 있다.
MoT/MoD의 문제는 prefill 예측성이다. continuous batching 환경에서 같은 시퀀스 길이라도 어떤 토큰이 어떤 레이어를 통과하느냐에 따라 실제 FLOPs가 달라지므로, prefill 소요 시간 추정이 어렵다. 기존 LLM 서빙 아키텍처가 가정하는 "같은 길이 = 같은 비용" 모델과 충돌한다. KV cache 할당도 attention을 받은 토큰만 저장하면 cache 크기가 줄지만, 비연속적 토큰 인덱스를 paged attention이 어떻게 처리할지는 구현 의존적이다.
MoE 서빙에 유리한 환경은 배치가 크고 요청 분포가 고른 API 서버다. MoT/MoD 아이디어가 더 매력적인 환경은 단일 GPU나 latency-critical한 저배치 워크로드, 긴 컨텍스트다. 긴 시퀀스에서는 예측 가능한 토큰 비율이 높아져 skip 효율이 좋아진다. 그런데 지금(2025년 기준) MoD를 올릴 수 있는 production 서빙 프레임워크가 존재하지 않는다. prefill 불규칙성을 처리하는 스케줄러나 비균일 KV cache를 다루는 memory manager가 아직 구현되지 않았기 때문이다.