두 구조 모두 "모든 파라미터를 쓰지 않겠다"는 희소성 전략에서 출발한다. 하지만 어느 축에서 희소성을 취하느냐가 추론 시스템 전체를 다르게 만든다. MoE는 FFN 계층의 expert 가운데 일부만 활성화하고, MoT는 attention에서 토큰 간 상호작용 자체를 솎아낸다. 이 차이 하나가 메모리 요구량, 배치 효율, 로드 밸런싱 문제를 전혀 다른 방향으로 만들어 놓는다.
왜 희소 모델인가
Dense 모델은 추론할 때 모든 파라미터가 동원된다. 파라미터가 많아질수록 메모리와 FLOPs가 함께 늘어나는 구조여서, 성능을 올리려면 비용이 선형 이상으로 증가한다. Sparse 모델은 이 연결고리를 끊는다 — 파라미터 수는 늘리되, 토큰 하나를 처리할 때 실제로 활성화되는 파라미터는 일부로 제한한다. 단, "어떤 파라미터를 건너뛸 것인가"라는 설계 선택에 따라 추론 시스템이 짊어지는 문제의 종류가 달라진다.
Mixture of Experts 구조와 추론 시 실제 비용
MoE에서 각 Transformer 레이어의 FFN은 여러 개의 expert — 독립된 MLP 네트워크 — 로 교체된다. 토큰이 레이어를 통과할 때마다 라우터(gate)가 상위 k개의 expert를 선택하고, 그 expert의 출력을 가중 합산해 결과를 낸다.
Mixtral 8x7B가 현재 가장 널리 참조되는 오픈 MoE 모델이다. 8개 expert 중 top-2를 선택하는 구조로, 전체 파라미터는 46.7B지만 토큰당 활성 파라미터는 약 12.9B에 그친다. 겉보기엔 효율적인 것 같지만, 서빙 시스템에서 이 숫자를 순진하게 해석하면 낭패다.
메모리는 전체 파라미터를 기준으로 잡힌다. 추론 중 어느 레이어에서 어떤 expert가 활성화될지 미리 알 수 없으므로, 모든 expert 가중치가 메모리에 올라가 있어야 한다. bf16 기준 Mixtral 8x7B의 실제 VRAM 요구량은 약 87GB로, 활성 파라미터 12.9B짜리 dense 모델(~26GB)이 아니라 46.7B dense 모델 수준이다. 이 구조가 극단으로 가면 DeepSeek V3처럼 전체 671B, 활성 37B가 된다 — 연산은 37B 수준이지만 BF16 기준 가중치만 1.3TB를 먹는다.
Expert Parallelism과 통신 오버헤드
단일 GPU나 노드에 모든 expert를 올리기 어려워지면 expert parallelism(EP)을 쓴다. 각 GPU가 서로 다른 expert 집합을 담당하고, 라우터 결과에 따라 토큰을 맞는 GPU로 보내는 구조다. 문제는 이 과정이 all-to-all 통신을 요구한다는 점이다. Dense 모델의 tensor parallelism이 all-reduce를 쓰는 것과 달리, all-to-all은 배치 안 각 토큰의 라우팅 결과에 따라 통신 패턴이 매번 달라진다. 노드 간 InfiniBand 대역폭이 이 통신을 받쳐줄 수 있어야 하고, 대규모 배포에서는 집합적으로 2TB/s 수준의 aggregate throughput이 필요하다는 보고도 있다.
Load Imbalance: MoE 서빙의 핵심 통증
MoE가 서빙 관점에서 가장 까다로운 이유는 load imbalance다. 라우터는 학습 중 보조 손실(auxiliary loss)로 균등 분배를 유도하지만, 실제 추론 트래픽에서는 특정 expert에 토큰이 몰린다. Switch Transformer 이래 MoE 연구들이 capacity factor와 auxiliary loss를 조합해 이 문제를 완화했지만 완전히 해결되지는 않는다. 잘 학습된 MoE 모델조차 "significantly imbalanced routing"을 보인다는 것이 최근 연구의 관찰이다. Expert parallelism 환경에서 특정 GPU에 토큰이 쏠리면 그 GPU가 병목이 되고 나머지 GPU는 기다린다. 동적 재분배 알고리즘(LLEP)을 적용하면 throughput이 최대 5배 가까이 개선됐다는 결과도 있는데, 이는 역으로 imbalance가 얼마나 심각한지를 보여준다.
Mixture of Tokens: 토큰 축으로 희소성을 이동시키면 무엇이 달라지는가
MoT 계열의 접근은 희소성의 위치를 FFN에서 attention으로 옮긴다. "어떤 expert를 쓸 것인가"가 아니라 "어떤 토큰이 어떤 토큰과 정보를 교환할 것인가"를 선택하는 것이다. Transformer의 self-attention은 시퀀스 내 모든 토큰 쌍의 관계를 계산하므로 O(n²) 비용이 발생하는데, 이 토큰 간 상호작용을 선택적으로 제한하면 prefill 비용과 KV cache 크기를 함께 줄일 수 있다.
구현 형태는 여럿이다. 블록 단위로 attention 범위를 끊는 방식 — MOBA(Mixture of Block Attention) 계열 — 이 있고, head별로 서로 다른 토큰 집합을 학습해 선택하는 방식 — Mixture of Sparse Attention(MoSA) — 도 있다. Token Sparse Attention은 Q, K, V를 압축된 토큰 집합으로 처리하고 attention 출력을 다시 복원하는 방식으로, 128K 컨텍스트에서 attention 연산을 3.23배 빠르게 하면서 정확도 손실은 1% 미만이라고 보고한다.
파라미터 메모리는 동일한 dense 모델과 같다. 대신 시퀀스 길이에 비례하는 비용 — prefill 시 attention 계산량과 decoding 중 KV cache 크기 — 이 줄어든다. KV cache가 줄면 같은 VRAM에 더 많은 시퀀스를 올릴 수 있어 배치 크기가 커진다. 긴 컨텍스트를 다루는 서빙에서 이 구분이 중요하다.
단, 토큰 선택 패턴이 시퀀스마다 다르면 배치 처리가 복잡해진다. Dense attention은 배치 내 모든 시퀀스에 동일한 causal mask를 적용하지만, sparse attention은 시퀀스마다 혹은 head마다 마스킹 패턴이 달라진다. GPU 입장에서는 하나의 monolithic GEMM을 돌리는 대신 패턴이 다른 여러 sub-operation을 처리해야 해서, 나이브한 구현에서는 오히려 dense attention보다 느릴 수도 있다. 이론적 sparsity가 실측 처리량 개선으로 연결되려면 FlashAttention 수준의 커널 최적화가 선행되어야 한다.
서빙 관점 비교
두 구조의 서빙 부담을 직접 비교하면 다음과 같다.
| 항목 | MoE | MoT |
|---|---|---|
| 파라미터 메모리 | 전체 expert 가중치 (dense 대비 수 배) | dense와 동일 |
| 활성 FLOPs | 활성 expert 기준 절약 | sparsity ratio에 비례 절약 |
| 통신 패턴 | all-to-all (EP 환경) | all-reduce (dense와 동일) |
| 로드 밸런싱 문제 | expert 쏠림으로 GPU 유휴 발생 | head/layer 내 국소적 |
| KV cache | 구조 자체 변화 없음 | sparsity만큼 감소 가능 |
| prefill 비용 | FFN 절약, attention 변화 없음 | attention 절약, FFN 변화 없음 |
| 프레임워크 지원 | vLLM, TGI, SGLang 폭넓게 지원 | 제한적 (커널 구현 필요) |
MoE의 부담은 배포 규모에서 집중된다. 모델을 올리기 위한 노드 수, 노드 간 통신 인프라, load imbalance를 흡수하기 위한 오버프로비저닝이 요구된다. 반면 MoT의 부담은 커널 구현에 있다. Sparsity가 이론 수치대로 작동하려면 GPU의 irregular access pattern을 처리하는 저수준 최적화가 선행되어야 한다.
현시점에서 선택 가능한 모델 생태계는 MoE 쪽이 훨씬 넓다. Mixtral, Mixtral 8x22B, DeepSeek V3, Llama 4처럼 프로덕션에서 검증된 MoE 모델이 다수 존재하고, vLLM과 SGLang 모두 EP를 포함한 MoE 서빙을 지원한다. MoT 계열은 아직 대부분 연구 단계 구현이고, 서빙 프레임워크에서 native 지원을 받는 모델이 많지 않다.
두 구조는 희소성 축이 다르기 때문에 이론상 결합이 가능하다 — FFN에서 expert를 희소하게 활성화하면서 attention에서 토큰 상호작용도 제한하는 식. 그러나 서빙 시스템 측면에서 두 가지 동적 라우팅 복잡성을 동시에 관리하는 비용은 상당하고, 그만한 이점을 얻을 수 있는 체제가 아직 확립되지 않았다.