전문가 혼합(MoE) 간단 설명: 최신 AI 모델은 크기는 커져도 속도는 유지된다

발행: 3일 전 (2026년 6월 11일 AM 03:01 GMT+9)

12 분 소요

Source: Dev.to

안녕하세요, 저는 Shrijith Venkatramana입니다. 매 커밋마다 실행되는 AI 코드 리뷰어인 git‑lrc를 만들고 있습니다. Star Us 를 눌러 프로젝트를 알리는 데 도움을 주세요. 한 번 사용해 보시고 제품 개선을 위한 피드백도 공유해 주세요.

대형 언어 모델은 계속해서 규모가 커지고 있습니다.

수백억, 심지어 수조 개의 파라미터를 갖지만, 놀랍게도 많은 모델이 여전히 빠르고 비용 효율적으로 동작합니다.

어떻게 가능할까요?

핵심은 최신 최첨단 모델 대부분이 모든 토큰에 대해 모든 파라미터를 사용하지 않는다는 점입니다.

대신 Mixture of Experts (MoE) 라는 기법을 사용합니다.

이를 하나의 거대한 소프트웨어 서비스를 여러 전문 마이크로서비스로 교체하는 것에 비유할 수 있습니다. 모든 요청이 모든 서비스에 전달되는 것이 아니라, 라우터가 어떤 전문 서비스가 해당 요청을 처리할지 결정합니다.

이것이 MoE의 기본 아이디어입니다.

아래에서는 MoE가 어떻게 작동하는지, 왜 중요한지, 그리고 엔지니어가 실제 서비스에 MoE 모델을 적용할 때 마주치는 도전 과제들을 살펴보겠습니다.

1. The Scaling Problem

전통적인 트랜스포머 모델은 dense(밀집) 형태입니다.

토큰이 트랜스포머 레이어에 들어가면:

어텐션이 실행된다.
피드포워드 네트워크(MLP)가 실행된다.
해당 레이어의 모든 파라미터가 연산에 참여한다.

모델 크기를 두 배로 늘리면 연산 비용도 대략 두 배가 됩니다.

이는 고통스러운 트레이드오프를 만들죠:

파라미터가 많을수록 → 품질이 향상된다.
파라미터가 많을수록 → 추론이 느려지고 학습 비용이 증가한다.

연산량을 비례적으로 늘리지 않으면서 모델 용량을 키우고 싶어하는 연구자들이 있었습니다.

MoE는 가장 성공적인 해결책 중 하나로 떠올랐습니다. 모든 파라미터를 활성화하는 대신, 토큰마다 작은 부분 집합만을 활성화합니다.

2. The Restaurant Analogy

전문가 8명이 있는 레스토랑을 상상해 보세요.

피자 셰프
스시 셰프
페이스트리 셰프
그릴 셰프
샐러드 셰프
수프 셰프
파스타 셰프
디저트 셰프

고객이 피자를 주문했을 때, 8명 전부가 작업에 참여할 필요는 없습니다.
레스토랑 매니저는 해당 주문을 관련 전문가에게만 전달합니다.

MoE도 같은 원리를 적용합니다.

하나의 거대한 신경망이 모든 토큰을 처리하는 대신,
여러 전문가 네트워크가 존재하고,
라우터가 각 토큰을 어느 전문가가 처리할지 선택합니다.
선택된 전문가만 연산을 수행합니다.

그 결과, 개별 추론 단계에서 실제로 사용되는 파라미터보다 훨씬 많은 파라미터를 모델이 보유할 수 있게 됩니다.

3. What Actually Changes Inside a Transformer?

MoE에 대한 놀라운 사실 하나는 대부분의 트랜스포머 구조는 그대로 유지된다는 점입니다.

보통:

어텐션 레이어는 그대로 dense
임베딩은 그대로 dense
정규화 레이어는 그대로 dense

피드포워드 네트워크(MLP)만이 전문가 집합으로 교체됩니다.

표준 트랜스포머 블록은 대략 다음과 같습니다:

Input
  ↓
Attention
  ↓
Feed Forward Network
  ↓
Output

MoE 블록은 다음과 같이 변합니다:

Input
  ↓
Attention
  ↓
Router
  ↓
Selected Experts
  ↓
Combine Outputs
  ↓
Output

각 전문가는 보통 또 다른 피드포워드 네트워크에 불과합니다.
하나의 MLP 대신 다음과 같이 여러 전문가가 존재할 수 있습니다:

Expert 1
Expert 2
Expert 3
...
Expert 64

라우터가 각 토큰을 어떤 전문가가 처리할지 결정합니다.

4. How Routing Works

라우터는 보통 가벼운 신경망입니다. 토큰마다 점수를 출력합니다:

Token: "database"

Expert 1: 0.05
Expert 2: 0.61
Expert 3: 0.09
Expert 4: 0.25

그 후 모델은 상위 전문가들을 선택합니다.

Top‑2 Routing

역사적으로 많은 MoE 시스템이 Top‑2 라우팅을 사용했습니다:

Selected:
Expert 2
Expert 4

두 전문가가 토큰을 동시에 처리하고, 라우터가 제공한 확률을 가중치로 하여 출력을 결합합니다.

Switch Routing

구글의 Switch Transformer는 이를 더 단순화했습니다. 두 전문가 대신 하나만 선택합니다:

Selected:
Expert 2

한 전문가만 실행되므로 통신 및 추론 오버헤드가 크게 감소하면서도 대부분의 이점을 유지합니다.

5. Why MoE Models Are So Efficient

두 가상의 모델을 비교해 보겠습니다.

Dense Model

100B parameters
100B active per token

MoE Model

8 experts × 100B parameters
= 800B total parameters

Only 2 experts active
= 200B active parameters

MoE 모델은 추론 시 전체 파라미터 중 극히 일부만 활성화하면서도 훨씬 큰 용량을 가질 수 있습니다. 이를 **조건부 연산(conditional computation)**이라고 부릅니다. 입력에 따라 서로 다른 연산 경로가 선택됩니다.

모델은 사실상 이렇게 말합니다:

“모든 문제에 내 뇌의 모든 부분이 필요하지는 않다.”

이 때문에 MoE 아키텍처는 대규모 LLM에서 매력적으로 떠올랐습니다. 파라미터 수는 추론 비용보다 훨씬 빠르게 증가할 수 있기 때문입니다.

6. The Hidden Engineering Challenges

기본 아이디어는 단순해 보이지만, 실제 서비스에 적용하면 어려운 부분이 곧 드러납니다.

Challenge 1: Expert Collapse

라우터가 다음과 같이 학습한다면:

90% of tokens → Expert 7

전문가 7이 거의 모든 학습을 차지하고, 다른 전문가들은 데이터가 부족해 쓸모 없게 됩니다. 연구자들은 로드 밸런싱 손실을 도입해 사용률을 고르게 만들려 합니다.

Challenge 2: Distributed Communication

예시:

GPU 1 → Experts 1-8
GPU 2 → Experts 9-16
GPU 3 → Experts 17-24

한 배치의 토큰이 여러 머신에 흩어져 있는 전문가를 필요로 하면, 토큰 활성값을 장치 간에 셔플해야 합니다. 많은 MoE 배포에서 통신이 주요 병목이 됩니다.

Challenge 3: Load Imbalance

실제 트래픽은 균일하지 않습니다. 일부 전문가는 과부하가 걸리고, 다른 전문가는 거의 사용되지 않습니다. 이는 GPU 활용률 문제를 일으키며, 현대 라우팅 방식은 전문가 워크로드 균형에 큰 비중을 둡니다.

Challenge 4: Token Dropping

전문가는 용량이 제한적입니다. 한 전문가에 너무 많은 토큰이 몰리면:

Capacity: 1000 tokens
Incoming: 1500 tokens

일부 토큰을 재라우팅하거나 버려야 할 수도 있습니다. 이런 오버플로우 상황을 관리하는 것이 생산 환경 MoE 서빙 인프라의 중요한 부분이 됩니다.

7. What MoE Looks Like in Production

AI 시스템을 구축하는 개발자에게 실용적인 의미가 큽니다.

Memory Footprint

MoE 모델은 다음과 같이 광고될 수 있습니다:

600B parameters

하지만 실제 토큰당 활성화되는 파라미터는 그 일부분에 불과합니다. 따라서 연산 비용은 훨씬 작은 dense 모델과 비슷하게 됩니다.

Inference Isn’t Automatically Cheaper

많은 개발자가 다음과 같이 가정합니다:

Fewer active parameters
=
Lower latency

하지만 라우팅 오버헤드, 전문가 간 통신, 분산 동기화 등이 이론적인 이득을 상쇄할 수 있습니다. MoE를 효율적으로 서비스하려면 특화된 추론 스택이 필요합니다.

Observability Matters

프로덕션 팀은 점점 더 다음을 모니터링합니다:

전문가 활용도
라우터 엔트로피
토큰 분포
전문가 핫스팟
장치 간 트래픽

과부하된 전문가는 AI 시스템에서 뜨거운 데이터베이스 샤드와 같은 역할을 합니다.