MoE Analysis

MoE (Mixture of Experts) 심층 분석

Sparse Activation · Routing/Gating · Load Balancing · DeepSeekMoE · Expert Parallelism/Offloading

MoE(Mixture of Experts)는 토큰마다 모델 전체를 계산하지 않고, 라우터가 선택한 일부 전문가만 활성화하는 희소(sparse) 아키텍처입니다. 핵심은 총 파라미터(모델 용량)와 활성 파라미터(토큰당 계산)를 분리하는 데 있습니다. Shazeer et al.(2017)이 conditional computation을 대규모 언어 모델에 다시 실용화한 뒤, Switch Transformer, GShard, DeepSeekMoE, DeepSeek-V3 같은 계열이 이 흐름을 이어 왔습니다.

MoE는 계산 효율만의 이야기가 아닙니다. 라우팅 품질, 로드 밸런싱, all-to-all 통신, 전문가 병렬화, 오프로딩까지 함께 봐야 시스템으로서 성립합니다. 이 문서는 희소 활성화 -> 라우팅 -> 로드 밸런싱과 DeepSeekMoE -> 시스템 관점 -> 장단점과 채택 현황 -> 관련 기술의 순서로 정리합니다.

1. 핵심 아이디어 - 희소 활성화

Dense 모델은 토큰마다 FFN의 모든 파라미터를 계산하므로, 파라미터를 늘리면 계산량도 함께 증가합니다. MoE는 FFN을 여러 전문가로 나누고 라우터가 토큰마다 일부(top-k)만 고르게 하여, 용량과 계산을 분리합니다.

그림 1. Dense FFN은 항상 전체를 계산하고, MoE는 선택된 전문가만 활성화한다.

조건부 계산(Conditional Computation)

• 전문가(expert) - 보통 Transformer의 FFN(피드포워드) 층을 대체합니다. 어텐션은 dense로 그대로 공유됩니다.
• 라우터(게이팅) - 토큰 표현을 보고 각 전문가의 적합도 점수를 계산한 뒤 top-k를 선택합니다.
• 활성 파라미터 - 총 파라미터가 커져도 토큰당 계산은 작게 유지할 수 있습니다. 예를 들어 DeepSeek-V3는 671B total / 37B active, Mixtral 8x7B는 47B total / 13B active로 소개됩니다.
• 기원 - Jacobs et al.(1991)의 MoE 개념을 Shazeer et al.(2017)의 sparsely-gated MoE가 대규모 언어 모델에 다시 적용했습니다.

Dense vs MoE

2. 라우팅 - 게이팅과 top-k 선택

MoE의 동작을 좌우하는 것은 라우터입니다. 토큰을 어느 전문가로 보낼지 결정하고, 선택된 전문가들의 출력을 가중합합니다.

그림 2. 토큰 -> 라우터 점수 -> top-k 전문가 -> 가중합.

scores = softmax(W_g · x)
T = top_k(scores)
y = sum(g_i · E_i(x) for i in T)

라우팅의 핵심

• noisy top-k(Shazeer) - 점수에 잡음을 더해 특정 전문가로의 쏠림(collapse)을 완화합니다.
• k의 트레이드오프 - k를 키우면 계산과 품질이 오르고, 줄이면 효율이 오르지만 누락 위험이 커집니다. Switch=1, Mixtral=2, DeepSeek-V3=8로 자주 설명됩니다.
• 미분 가능성 - 라우팅은 이산 선택이므로, 실제 구현은 게이트 가중치를 곱해 학습 가능하게 만듭니다.
• capacity factor - 전문가가 수용할 토큰 수를 제한해 overflow를 다루는 방식입니다. 초과 토큰은 drop되거나 다른 경로로 처리됩니다.

라우팅 전략의 변천

3. 로드 밸런싱과 DeepSeekMoE

MoE의 고질적 문제는 routing collapse입니다. 일부 전문가만 과부하되고 나머지가 거의 학습되지 않으면, 모델 용량이 그대로 낭비됩니다. DeepSeekMoE와 DeepSeek-V3는 이 문제를 구조와 라우팅 양쪽에서 다룹니다.

그림 3. 라우팅 쏠림, 로드 밸런싱, 전문가 분할과 공유 전문가.

로드 밸런싱

• 보조 손실(auxiliary loss) - 쏠림에 페널티를 주는 항을 손실에 더합니다. Switch Transformer와 GShard 계열에서 널리 사용됩니다.
• auxiliary-loss-free(DeepSeek-V3) - 손실 함수를 건드리지 않고 라우팅 점수에 동적 bias를 더해 이용률 균형을 맞춥니다.

DeepSeekMoE의 두 가지 전략

• fine-grained 전문가 분할 - 전문가 N개를 mN개로 잘게 쪼개고, 더 많은 전문가를 활성화하되 계산량은 비슷하게 유지합니다. 전문가 조합이 유연해지고 지식 혼재를 줄입니다.
• shared expert - 항상 활성화되는 공유 전문가가 공통 지식을 담당해, 나머지 전문가가 특화에 집중하게 합니다.

보고된 효율

DeepSeekMoE 논문은 2B 규모에서 GShard 2.9B와 비교 가능한 성능을 보였고, 16B 규모에서는 LLaMA2-7B와 비교 가능한 성능을 약 40% 계산량으로 달성했다고 보고합니다. DeepSeek-V3는 671B total / 37B active와 함께 auxiliary-loss-free 전략을 사용합니다.

4. 시스템 - 전문가 병렬화와 메모리·오프로딩

MoE는 계산은 줄이지만 시스템 부담을 새로 만듭니다. 특히 전문가들이 어디에 있느냐가 통신과 메모리를 결정합니다.

그림 4. 전문가 병렬화(all-to-all), 메모리 역설, 전문가 오프로딩 계층.

시스템 관점의 함의

• 전문가 병렬화(EP) - 전문가들을 여러 GPU에 나눠 배치하고, 토큰을 해당 GPU로 보냅니다. MoE 블록마다 scatter/gather 형태의 all-to-all 통신이 필요합니다.
• 메모리 역설 - 토큰당 활성 파라미터는 작지만, 어느 전문가가 쓰일지 모르므로 모든 전문가를 메모리에 적재해야 합니다.
• 전문가 오프로딩 - VRAM을 hot expert 캐시로 보고, 비활성 전문가를 CPU DRAM, CXL, NVMe로 내립니다. 활성 전문가만 on-demand로 올리지만, PCIe/CXL 대역폭이 병목이 될 수 있습니다.
• CXL의 의미 - 더 큰 메모리 풀을 두고 전문가를 계층화할 수 있어, KV 캐시 오프로딩과 같은 설계 문제로 볼 수 있습니다.

5. 장단점과 채택 현황

그림 5. MoE의 장단점과 대표 모델.

장점과 단점

주요 MoE 모델

MoE와 다른 절감 기법의 관계

MoE는 계산 희소화에 초점이 있고, 양자화는 비트 수를 줄이며, MLA나 KV 캐시 최적화는 디코딩 메모리를 줄입니다. 서로 목적이 달라서 함께 쓸 수 있습니다. DeepSeek-V3처럼 MLA, MTP, MoE를 결합하는 방식이 그 예입니다.

6. 관련 기술

• Memory Centric LLM Serving Survey - KV 캐시와 서빙 메모리 관점
• PagedAttention Analysis - KV 캐시 페이징과 블록 테이블
• KV Cache Offloading Analysis - 메모리 티어링과 오프로딩
• MoE Serving Routing LoadBalance - 서빙 단계의 routing/dispatch 병목
• Disaggregated LLM Serving Analysis - 분리형 서빙과 메모리 분산

참고 문헌 - Shazeer et al. 2017 arXiv:1701.06538, GShard 2020 arXiv:2006.16668, Switch Transformer 2021 arXiv:2101.03961, DeepSeekMoE 2024 arXiv:2401.06066, DeepSeek-V3 arXiv:2412.19437.

7. 핵심 정리

MoE는 토큰마다 일부 전문가만 활성화해 총 파라미터와 활성 파라미터를 분리하는 구조입니다. 덕분에 계산을 크게 늘리지 않고도 모델 용량을 키울 수 있습니다. 다만 라우팅, 로드 밸런싱, all-to-all 통신, 메모리 적재 문제가 함께 따라옵니다.

Shazeer의 sparsely-gated MoE에서 시작해 Switch의 top-1 단순화, GShard의 자동 샤딩, DeepSeekMoE의 fine-grained 전문가와 shared expert로 발전했습니다. DeepSeek-V3는 auxiliary-loss-free 로드 밸런싱까지 더해 현재 MoE 설계의 대표 사례로 볼 수 있습니다.

결국 MoE는 "더 큰 모델"이 아니라 "더 똑똑한 계산 배분"에 대한 해법입니다. 그래서 성능만이 아니라 서빙 인프라와 메모리 계층 설계까지 함께 봐야 합니다.