Dense 모델은 모든 토큰이 모든 파라미터를 활성화한다. Transformer FFN 블록 하나를 통과할 때마다 전체 가중치 행렬을 곱한다는 뜻이고, 파라미터가 늘수록 FLOPs도 선형으로 올라간다. 희소 활성화(sparse activation)는 이 관계를 끊으려는 시도다. 파라미터 수를 늘려 학습 용량을 키우면서도, 추론 때는 일부만 활성화해 FLOPs를 낮춘다. 단 그 대가로 전체 파라미터를 메모리에 올려야 하고, "어떤 파라미터를 활성화할지" 결정하는 라우팅 오버헤드가 생긴다.
Mixture of Experts(MoE)와 Mixture of Tokens(MoT, Soft MoE라고도 부른다)는 이 희소 활성화를 구현하는 두 갈래다. 둘 다 같은 목표를 향하지만, 라우팅 결정의 단위가 다르다 — 전문가를 선택하느냐, 토큰을 혼합하느냐. 그 차이 하나가 서빙 시스템에서 전혀 다른 문제를 만들어낸다.
MoE: 전문가를 선택하는 이산 결정
Shazeer 등(2017)이 제안한 Sparsely-Gated MoE 이후 주류가 된 구조다. 각 Transformer 레이어에서 FFN 블록을 N개의 expert FFN으로 분리하고, 토큰마다 게이트(라우터)가 어느 expert를 사용할지 결정한다. Top-K 게이팅이 표준이다. K=2일 때 수식은 다음과 같다.
G(x) = softmax(TopK(x · W_g, K=2))
y = Σ_i G_i(x) · FFN_i(x)
W_g는 학습 가능한 게이팅 가중치이고, TopK는 점수 상위 K개만 남기고 나머지를 −∞로 마스킹한다. 토큰 x는 선택된 2개의 expert만 거치고, 가중합으로 출력을 낸다.
Mixtral 8x7B 기준으로 보면 이 구조의 의미가 명확해진다. 전체 파라미터는 46.7B이지만 토큰 하나당 활성 파라미터는 12.9B뿐이다. 추론 FLOPs는 dense 13B 모델과 거의 같다. 그런데 메모리에는 46.7B를 모두 올려야 한다. dense 13B 대비 3.6배 VRAM을 잡아먹으면서 속도는 13B 수준이다.
load imbalance: MoE 서빙의 실질적인 문제
이론상 8개 expert가 균등하게 토큰을 받아야 한다. 실제로는 그렇지 않다. auxiliary load balancing loss 없이 학습하면 일부 expert가 대부분의 토큰을 독차지하는 붕괴(collapse)가 일어난다고 Shazeer 등(2017) 논문부터 확인됐다. 학습 때 이 문제를 억제해도 추론 시 특정 입력 분포에서 imbalance가 다시 나타난다.
배치 내 토큰이 특정 expert에 몰리면 나머지 expert는 놀고 그 expert만 연속으로 연산한다. GPU는 expert 단위로 행렬 곱을 처리하기 때문에, 한 expert에 토큰이 32개 몰리고 다른 expert에 2개 오면 전체 레이어 처리 시간은 32개짜리 expert의 레이턴시로 결정된다. latency tail이 길어진다.
배치 크기가 커질수록 이 문제는 통계적으로 완화된다. 토큰이 충분히 많으면 각 expert가 받는 토큰 수의 분산이 줄어든다. offline batch 추론에서 MoE가 관리하기 쉬운 이유가 여기에 있다. 실시간 서빙에서는 배치가 작고 입력 분포가 편향될 때 worst case가 자주 나온다.
DeepSeek-MoE는 이 문제를 다른 방향에서 파고들었다. Expert FFN을 더 잘게 쪼개(fine-grained expert) 같은 연산량에서 expert 수를 늘리고, 각 expert가 다루는 지식 범위를 좁혔다. load balancing은 학습 때 expert-level loss와 device-level loss를 함께 적용하고, 이후 버전인 DeepSeek-V3에서는 auxiliary loss 없이 라우터 bias를 동적으로 조정하는 방식으로 전환했다. 어떤 expert가 평균보다 많이 사용되면 해당 expert의 bias를 낮춰 다음 토큰에서 선택될 확률을 줄이는 식이다.
expert parallelism이 필요해지는 시점
46.7B 모델을 single GPU에 올리기 어려우니 분산 추론이 필요하다. MoE에서는 Tensor Parallelism(TP)에 더해 Expert Parallelism(EP)이 등장한다. EP는 각 expert를 서로 다른 GPU에 올리는 방식이다. 토큰이 라우팅될 때 해당 expert가 있는 GPU로 토큰을 보내야 하므로, all-to-all 통신이 필연적으로 발생한다.
vLLM은 현재 EP를 정식 지원한다. --tensor-parallel-size와 --data-parallel-size를 조합해 EP 크기를 결정하는 구조다.
# 8-GPU 단일 노드에서 8-way expert parallelism
vllm serve deepseek-ai/DeepSeek-V3-0324 \
--tensor-parallel-size 1 \
--data-parallel-size 8 \
--enable-expert-parallel
EP_SIZE = TP_SIZE × DP_SIZE로 자동 계산된다. --enable-eplb 플래그를 추가하면 Expert Parallel Load Balancer가 활성화되며, 매 forward pass마다 expert별 부하 통계를 수집해 주기적으로 expert를 GPU 간 재배치한다. 자세한 설정 옵션은 vLLM EP 공식 문서에 있다.
Soft MoE: 이산 결정을 없앤 토큰 혼합
Puigcerver 등(Google DeepMind, 2023)이 제안한 Soft MoE는 문제 설정 자체를 바꾼다. "어느 expert를 선택하느냐"는 이산 결정을 버리고, 토큰들을 연속적으로 혼합해 각 expert에 넘기는 방식이다.
핵심 메커니즘은 토큰-slot 할당 행렬이다. m개의 토큰, n개의 expert, 각 expert가 s개의 slot을 가진다면:
Φ = softmax(X · Φ_W) # (m × n·s) 할당 행렬, 열 방향 softmax
X̃_i = Φ_i^T · X # i번째 expert input: s개 slot, 각각 모든 토큰의 가중합
Ỹ_i = FFN_i(X̃_i) # expert 처리
Y = Φ_i · Ỹ_i (전체 합산) # 출력을 원래 토큰 위치로 복원
각 expert input은 특정 토큰 하나가 아니라 모든 토큰의 가중 평균이다. Expert가 받는 입력은 항상 s개로 고정되고, 배치 내 토큰이 몇 개든 expert별 연산량이 일정하다.
load imbalance가 구조적으로 사라진다. 모든 expert가 항상 같은 수의 slot을 처리하기 때문이다. Soft MoE Huge/14(128 expert, 16개 MoE 레이어) 기준으로, ViT Huge/14 대비 파라미터 수는 40배 이상 많으면서 추론 시간 증가는 2% 수준이었다고 논문은 보고한다.
autoregressive 생성에서의 궁합 문제
그렇다면 왜 LLM 서빙 스택에서 Soft MoE는 보이지 않는가.
토큰 독립성 가정이 깨지기 때문이다. 각 expert input이 모든 토큰의 가중합이므로, 특정 위치 토큰의 출력이 다른 모든 토큰에 의존한다. 자동 회귀 생성에서는 현재 토큰 생성 시 이전 토큰들의 KV 값만 참조하면 되고, 이를 KV 캐시로 재사용한다. Soft MoE 방식에서는 새 토큰이 추가될 때마다 모든 토큰의 혼합 비율이 재계산되어야 한다 — KV 캐시의 기본 가정이 무너진다.
Soft MoE 논문도 이 문제를 인식하고 있으며, 실험은 주로 ViT(Vision Transformer) 기반 image classification에서 이루어졌다. 텍스트 생성 태스크에 적용하려면 인과적 마스킹(causal masking)과의 호환성 문제를 해결해야 하는데, 아직 이를 대규모 언어 모델에서 실용적으로 풀었다는 결과는 나오지 않았다.
서빙 지표로 나란히 놓기
| 항목 | MoE | Soft MoE |
|---|---|---|
| 메모리 footprint | 전체 파라미터 로딩 필수 | 동일 (전체 expert 메모리 필요) |
| Expert별 연산량 | 배치·입력에 따라 편차 | 고정 (slot 수 = 상수) |
| Load imbalance | 구조적 문제, auxiliary loss / EP LB 필요 | 구조적으로 없음 |
| all-to-all 통신 | EP 구성 시 필수 | 이론상 불필요 |
| KV 캐시 호환성 | 표준 KV 캐시 그대로 사용 | autoregressive 환경에서 미해결 |
| 현재 서빙 스택 지원 | vLLM, TensorRT-LLM 정식 지원 | 연구 구현 수준 |
메모리 footprint는 둘 다 동일하다. 어떤 방식이든 모든 expert 파라미터를 올려야 한다는 사실은 변하지 않는다. Soft MoE가 MoE 대비 가진 장점은 연산 균형이고, 그 장점을 텍스트 생성에서 쓰려면 아직 해결되지 않은 문제들이 있다.
KV 캐시 구조 차이는 특히 중요하다. MoE에서 KV 캐시는 attention 레이어에만 관여하고 expert FFN 레이어와는 무관하다. 토큰이 어느 expert를 거치든 KV는 동일하게 쌓인다. vLLM의 PagedAttention은 이 가정 하에 동작하므로 MoE 모델에서도 그대로 적용된다. Soft MoE에서는 token mixing이 FFN 레이어 전반에서 일어나므로, 이 가정이 성립하지 않는다.
MoE 모델을 받았을 때 먼저 볼 것
실제 서빙 엔지니어 입장에서 지금 당장 다뤄야 할 모델은 Mixtral, DeepSeek-V3, Qwen MoE 계열 등 대부분 MoE다. Soft MoE를 프로덕션에서 만날 가능성은 현재로서 거의 없다. Soft MoE를 알아야 하는 이유는 배포 때문이 아니라, MoE의 load imbalance 문제가 왜 그렇게 까다로운지를 역으로 설명해 주기 때문이다. 이산 라우팅 결정을 없애면 문제가 사라지는데 그걸 못 하는 이유가 autoregressive 생성과의 충돌이라는 것 — 이 점을 이해하고 나면 MoE 서빙 최적화 작업의 방향이 훨씬 명확해진다.
MoE 모델을 받으면 먼저 세 가지를 확인한다. Expert 수와 Top-K 값으로 이론적 활성 파라미터 비율을 계산하고, GPU 수 대비 expert 수 배치를 검토해 EP 구성이 필요한지 판단한다. 배치 크기 목표가 작다면(실시간 low-latency 서빙) imbalance worst case를 가정한 latency budget을 따로 잡아야 한다. vLLM으로 서빙한다면 --enable-eplb로 동적 load balancing을 켜는 것이 기본값에 가까워지고 있다.
MoT 관련 연구는 계속 나오고 있다. 인과적 마스킹과의 호환 문제를 우회하려는 시도들이 있고, diffusion 기반 언어 모델처럼 autoregressive 가정 자체가 없는 설계에서 Soft MoE 계열이 더 자연스럽게 들어맞을 가능성도 있다. 언제 이 구도가 바뀔지는 아직 열려 있다.