[논문리뷰] Mixtral of Experts

hyo._.op·2026년 8월 4일

논문리뷰

목록 보기

15/16

Overview

논문명: Mixtral of Experts
학회(출판연도): arXiv (2024)
연구분야: Large Language Models (LLM), Mixture of Experts (MoE), Efficient AI

Abstract

Mixtral 8x7B라는 Sparse Mixture of Experts(SMoE)기반 언어모델 제안
- 여기서 중요한 키워드는 Sparse인데,
  - 기존의 Transformer는 입력 → FFN으로 모든 FFN을 항상 계산함
  - 하지만, SMoE는 입력 → Router → Expert1 Expert5 처럼 필요한 Expert만 선택해서 계산해서 계산량이 크게 줄어듦
Mixtral은 기본적으로 Mistral 7B와 동일한 구조를 사용하지만, 각 Transformer layer의 FFN 대신 8개의 Feed Forward Network(Expert)를 둔 것이 차이점
- 기존 Transformer layer
  - Attention → FFN
- Mixtral Transformer layer
  - Attention → Expert1 Expert2 Expert3 Expert4 Expert5 Expert6 Expert7 Expert8
각 토큰이 각 layer를 통과할 때마다, Router가 8개의 Expert 중 2개를 선택하고 선택된 Expert의 출력을 합쳐서 다음 layer로 전달
- 그래서 토큰마다 선택되는 Expert가 달라질 수 있음
  - “The” → Router → Expert2 Expert6
  - “cat” → Router → Expert1 Expert8
- 각 토큰은 항상 2개의 Expert만 사용하지만, 어떤 Expert를 사용할지는 토큰마다 다름 ⇒ 각 토큰은 전체 47B 파라미터를 활용할 수 있지만, 실제 추론 시에는 13B정도의 파라미터만 활성화되어 계산됨
  ✓ 왜 13B일까?
  - Mixtral은 Expert x 8이 있지만, Top-2만 계산함
    - 즉, 전체 파라미터는 47B이고 실제 계산은 Expert 2개 ≈ 13B
      
      ⇒ 큰 모델의 표현력과 작은 모델 수준의 계산량을 동시에 얻을 수 있음
또한 Mixtraldms 32,000토큰의 긴 문맥을 처리할 수 있도록 학습됨
대부분의 벤치마크에서 Llama2 70B와 GPT-3.5 이상의 성능을 보임
- 특히, 수학, 코드생성, 다국어에서는 Llama 2 70B보다 훨씬 우수한 성능을 달성함
instruction tuning을 수행한 Mixtral 8x7B-Instruct도 함께 공개
사람이 평가한 벤치마크에서는 GPT-3.5 Turbo, Claude 2.1, Gemini Pro, Llama 2 70B Chat 보다도 높은 평가를 받음

1. Introduction

본 논문에서는 Mixtral 8x7B 라는 Sparse Mixture of Experts(SMoE)기반의 오픈소스 언어모델을 소개함(Apaceh 2.0 라이선스)
✓ SMoE(Sparse Mixture of Experts)**
- MoE(Mixture of Experts)
  - 여러 개의 작은 전문가 모델(Expert)를 만들고, 입력마다 적절한 전문가만 선택해서 사용하는 구조
  - 라우터가 “누가 이 입력을 처리할지”를 결정함
- Sparse
  - 모든 Expert를 사용하지 않고 일부 Expert만 사용한다
- 해당 모델은 대부분의 벤치마크에서 Llama 2 70B와 GPT-3.5를 능가함
- 각 토큰마다 자신의 파라미터 중 일부만 사용하기 때문에 작은 배치에서 더 빠른 추론 속도, 큰 배치에서는 더 높은 처리량 제공
Mixtral은 Sparse Mixture-of-Experts 네트워크
- GPT랑 똑같이 Decoder-only Transformer 구조이고, FFN(Feedforward block)부분에서 8개의 Expert 중 필요한 것만 선택함
  ✓ Transformer란?
  - 현재 대부분의 LLM의 기반이 되는 모델로, 기본적인 구조로는 입력 문장 — Encoder(여러 층) — Encoder Output — Decoder(여러 층) — 출력 문장
    
    !image.png
  ✓ Encoder은 무슨 역할을 할까?
  - 입력 문장을 이해하는 것
  - 예를 들어, The cat sat on the mat. 이라는 문장이 들어오면, 인코더에서는 The → 벡터, cat → 벡터 처럼 단어를 숫자로 바꿈
    - 각 단어가 무엇을 의미하는지, 다른 단어와 어떤 관계인지 학습
      
      → 그래서 BERT, RoBERTa 같은 모델을 사용함
  ✓ Decoder은 무슨 역할을 할까?
  - 다음 단어를 생성하는 것
  - 예를 들어, 오늘 날씨가 가 입력되면, 디코더에서는 좋네요 를 예측함. 이후 좋네요 를 생성하고 다음 단어를 생성
  ✓ 그러면 왜 GPT는 Decoder만 사용할까?
  - 원래 트렌스포머는 Encoder → Decoder 구조 이지만, GPT의 경우에는 Decoder만 사용함
    - 왜냐하면, GPT의 목표는 “다음 단어 맞추기” 이기 때문
      
      입력을 별도로 압축해서 전달할 필요가 없기 때문에 인코더를 제거함
      
      → GPT, Llama, Mistral, Mixtral 모두 디코더 온리 모델
  - 디코더 layer 하나를 보면, input → self attention -FFN → output 구조인데 이 layer가 여러번 반복됨
    - self attention: 문장 안에서 어떤 단어가 중요한지를 찾는 과정
    - FFN: 작은 신경망(MLP)
      
      입력 → linear → activation → linear → 출력
  - Attention과 FFN의 차이?
    - attention은 단어들끼리 관계를 찾는 것을 의미
    - FFN은 attention이 만든 표현을 더 좋은 표현으로 변환하는 것
    - 그래서 attention은 정보를 모으는 역할, FFN은 정보를 가공하는 역할
  - Mixtral에서는 FFN 하나가 하던 일을 여러개의 FFN(Expert)로 나눔(각 Expert는 독립적인 FFN)
    - 전체 구조를 살펴보면,
      
      self-attention(다른 토큰과의 관계) → Router(어떤 Expert를 사용할지) → Top-2 Expert(각 Expert는 하나의 FFN) → 선택된 두 Expert 출력 가중합 → 다음 Decoder layer

2. Architectural details

Mixtral은 기본적으로 Mistral과 같은 Transformer 구조를 사용하지만 크게 아래 두가지가 다름
- 긴 문맥(32K 토큰)을 처리할 수 있도록 개선
- ⭐️ 기존 FFN을 MoE Layer로 교체
모델 구조 파라미터

2.1 Sparse Mixture of Experts

MoE Layer

입력 $x$ 에 대한 MoE 모듈 출력은 Expert들의 출력을 가중합해서 계산되며, 그 가중치는 Gating Network(라우터) 출력으로 결정됨
- $\sum_{i=0}^{N-1} G(x)_{i} \cdot E_{i}(x)$
  - $E_{i}(x)$ : Expert의 출력
  - $G(x)_{i}$ : 라우터가 준 점수
⭐️ 만약, Gating Vector가 Sparce하다면, Gate가 0인 Expert는 계산하지 않아도 됨 → 연산량 크게 줄어듦
$G(x)$ 를 구현하는 방법은 여러 가지가 있지만, 간단하면서도 성능이 좋은 방법은 Linear layer의 Logit에 대해 Top-K softmax를 사용하는 것
- $G(x) = \operatorname{Softmax}\left(\operatorname{TopK}(x \cdot W_g)\right)$
  - $x$ : 현재 입력 토큰의 벡터(이미 attention을 거친 표현)
  - $W_g$ : Router가 학습하는 가중치. 즉, 어떤 입력이 어떤 Expert로 가야하는가?
$(\operatorname{TopK}(\ell))_i$
- $\ell_i$ 가 상위 K개의 Logit 중 하나라면 그대로 유지하고, 그렇지 않다면 -∞로 설정
  - 그렇다면 왜 하필 -∞이냐라고 하면, Softmax에 넣었을 때 $e^{-∞}$ =0이기 때문
- K는 토큰 1개당 사용하는 Expert의 개수이고, 각 토큰을 처리하는 계산량을 조절하는 하이퍼파라미터임
Expert 개수(n)를 늘리고 K를 그대로 유지하면, 모델 파라미터 수는 증가하지만, 계산 비용은 거의 일정하게 유지됨
- Expert가 아무리 늘어나봐야 어차피 K개 만큼만 계산하니까 ⇒ 따라서 모델 전체 파라미터 수와 토큰 하나를 처리할 때 실제로 사용하는 파라미터 수는 구분할 필요가 있음
MoE layer는 Expert가 여러개라서 느릴 것 같지만, 고성능 특수 커널(GPU에 특화된 연산 방식)을 사용하면, 단일 GPU에서도 효율적으로 실행 가능
- MegaBlocks
  - MoE Layer의 FFN 연산을 큰 Sparse Matrix Multiplication으로 변환해서 실행 속도를 크게 향상시키고, Expert마다 서로 다른 개수의 토큰이 할당되는 경우도 자연스럽게 처리
- 일반적인 Model Parallelism과 Expert Parallelism(EP)를 활용하여 여러 GPU에 분산하기도 함
  - Model Parallelism: 모델 자체를 여러 GPU에 나누어 넣는 것
  - Expert Parallelism(EP): layer가 아니라 Expert를 나눔
MoE layer를 실행할때 특정 Expert가 처리해야하는 토큰은 해당 Expert가 있는 GPU로 전달되고, 처리가 끝난 후, 원래 위치로 반환
- 그런데, Expert Parallelism은 Load Balancing 문제를 발생시킴 → GPU마다 작업량이 균등하게 분배하지 않으면, 일부 GPU가 과부하되거나 병목 현상이 발생할 수 있기 때문
  - 이게 무슨소리냐하면,
    Expert1은 10개의 토큰, Expert2는 500개의 토큰을 담당하고 있다고 하자. 그러면 Expert2가 있는 GPU는 엄청 바쁘고, Expert1이 있는 GPU는 거의 놀고 있겠죠? → 때문에 각 Expert들을 비슷하게 분배해야함!!
    ✓ 이렇게 Expert가 균등하게 사용되면 전문성이 떨어지는 것은 아닐까?
    - MoE는 2가지 목표를 동시에 만족해야함
      
      각 토큰에 적합한 Expert를 선택해서 성능을 높인다
      
      Expert 사용이 한쪽으로 쏠리지 않게 해서 계산 효율을 유지한다
      
      ⇒ 그래서 실제 학습에서는 Load Balancing Loss 를 추가하여 특정 Expert만 계속 선택되는 것을 막음
      
      그렇다고 모든 Expert를 동일한 빈도로 사용하는 것은 아니고, Specialization과 Balance 사이의 적절한 타협점을 찾는 것이 핵심!
Transformer 모델에서 MoE layer는
- 각 토큰마다 독립적으로 적용
  - 예를들어, “I love BOAZ” 라고 했을 때,
    I | love | BOAZ 이렇게 토큰이 나뉘어서 각 토큰마다 router를 실행한다는 것
  - 이때, 문장 전체가 Expert 하나 선택하는 게 아니라 토큰마다 서로 다른 Expert를 선택 → Sparse Routing
- Transformer block의 Feed-Forward(FFN) 서브 블록을 대체함
  - Transformer에서 토큰마다 router를 실행해서 Expert를 선택하고, 기존의 FFN 대신에 MoE를 넣음
Mixtral에서는 Expert 함수 $E_i(x)$ 로 SwiGLU구조를 사용하고, 여기서 K는 2를 선택함
- 이때 Expert는 Linear → SwiGLU → Linear 구조를 가지고 있음 → 즉, FFN과 거의 동일한 구조 but 차이점은 이게 1개가 아니라 8개라는 점
  ✓ SwiGLU?
  - SwiGLU = Swish + GLU(Gated Linear Unit) 를 결합한 활성화 함수 구조
  - 먼저 Transformer의 FFN구조를 보면 일반적인 Transformer의 FFN은 보통 입력x → Linear 1 → Activation → Linear2 → 출력 와 같이 생김
    - $FFN(x) = W_2\sigma(W_1x)$
    - Linear: 입력 벡터를 다른 공간으로 변환함
      
      768차원 → 3072차원 처럼 차원을 키움 (더 많은 특징을 표현하기 위함)
  - GLU는 일반적인 FFN에 Gate를 한 추가하는 구조
    
    → 일반적은 FFN의 경우에는 모든 특징을 동일한 방식으로 처리하지만, GLU의 경우에는 입력을 2번 Linear하여 하나는 실제 정보, 다른 하나는 그 정보를 얼마나 사용할지 결정하는 Gate가 있음(즉, 중요한 특징만 getget!)
    - ⭐️ 왜 그냥 Attention만으로 안되는지 의문이 생길 수 있는데, Attention의 경우에는 토큰 간의 관계를 학습하고, GLU의 경우에는 그 feature마다 사용량을 조절함
  ✓ 예시를 들어보자면,
  - Attention
    - I love BOAZ라는 문장이 있다고 할 때, love의 경우 I와 BOAZ를 많이 참고함
  - GLU
    - love라는 벡터 안에는 수천 개의 feature가 존재하는데 그 GLU가 그 feature마다 사용량을 조절함
      → 벡터 내부 특징 조절
    - 입력이 두 갈래로 나뉨
      
      → $\operatorname{GLU}(x) = (W_1x) \odot \sigma(W_2x)$
      
      $W_1x$ : 정보부분 — 이 정보를 전달할까?
      
      $\sigma(W_2x)$ : Gate부분 — 얼마나 열어줄까?
  - Swish(SiLU)는 Google이 제안한 활성화함수
    - $\operatorname{Swish}(x)=x \cdot \operatorname{sigmoid}(x)$
    - 중요한 값을 통과시키고 중요하지 않은 값은 줄이는 부드러운 Gate 역할
  - ⭐️ 그렇다면, SwiGLU는?
    - GLU의 Gate부분의 sigmoid를 Swish로 수정
    - $\operatorname{SwiGLU}(x)=\operatorname{Swish}(W_1x)\odot(W_2x)$
      
      Gate가 있는 활성화 함수 부분
    - $\operatorname{SwiGLU}(x) = W_2\left(\operatorname{Swish}(W_1x) \odot W_3x\right)$
      
      FFN은 $W_2\sigma(W_1x)$ 구조이므로, 위와 같은 식이 논문에 적혀 있는 것
      
      $W_1$ 은 첫번째 변환으로 $x → W_1x$ 를 진행한 후 Swish를 적용
      
      $W_3$ 는 Gate 역할, GLU의 핵심이고 “얼마나 통과시킬지”를 결정함
      
      $W_2$ 는 출력 projection으로 곱한 결과를 다시 원래 차원으로 돌리는 역할
  ✓ 왜 SwiGLU?
  - 기존의 FFN은 하나의 변환 → Activation → 출력 이었다면,
  - SwiGLU는 2개의 변환 → 하나는 정보, 하나는 조절 → 결합 구조이므로, “어떤 정보를 얼마나 사용할지”를 더 세밀하게 학습할 수 있음
  ✓ Mixtral에서 SwiGLU는 어디에 들어갈까?
  - Mixtral 구조
    - Token → Attention → Router → Expert 선택 → Expert FFN → 출력
      
      여기서 Expert = SwiGLU FFN임
      
      즉, Expert마다 Linear → SwiGLU → Linear 과 같은 구조
  - 그러면 SwiGLU와 MoE는 무슨 관계인지!
    - SwiGLU는 FFN 내부 구조 개선 목적 → FFN을 어떻게 더 잘 만들지
    - MoE는 FFN을 여러 개 만들고 선택 → FFN을 여러 개 두고 어떤 것을 사용할지
      
      ⇒ 즉, SwiGLU는 Swish 활성화 함수와 GLU의 Gate 구조를 결합한 FFN 구조로, 중요한 정보를 선택적으로 통과시키는 능력을 높이는 방식임. Mixtral에서는 각 Expert가 하나의 SwiGLU기반 FFN으로 구성되고, Router가 각 토큰마다 8개의 Expert 중 2개를 선택함
이 구조는 GShared와 유사한데, Mixtral의 경우
- 모든 FFN을 MoE Layer로 바꾸었고, GShard는 한 층 건너 하나씩만 바꾸었음
- 그리고 GShard는 토큰에 할당되는 두 번째 Expert를 선택할 때 더 복잡한 Gating 전략을 사용함 → Mixtral이 Router 구조를 더 단순하게 만듦

3. Result

Mixtral과 Llama와 비교했고, 공정하게 비교하기 위해 모든 벤치마크를 자체 평가 파이프라인으로 다시 실행함
또한, LLM의 경우 한 가지 능력만 좋으면 안되기 때문에 (상식, 독해, 수학, 코딩 등 모든 영역에서 잘해야함) 여러 벤치마크를 활용했음
- Commonsense Reasoning
  - 모델이 사람이라면 당연히 아는 상식을 이해하는지 평가
- World Knowledge
  - 모델이 세상에 대한 지식을 얼마나 많이 알고 있는지를 평가
- Reading Comprehension
  - 긴 글을 읽고 질문에 답할 수 있는지 평가
- Math
  - 수학 성능은 GSM8K(초중등수준) MATH 데이터세트로 평가함
- Code
  - 코드 생성 능력을 HumanEval과 MBPP로 평가
    - HumanEval은 OpenAI가 만든 python 코드 생성 벤치마크
    - MBPP는 간단한 Python 문제 모음
- Popular Aggregated Results
  - 여러 분야를 한꺼번에 평가하는 종합 실험임
    - MMLU(57개 과목 — 의학, 법학, 역사, 철학 등)
    - BBH(매우 어려운 추론 문제)
    - AGI Eval(LLM 종합 시험)

Mixtral은 대부분 평가 지표에서 Llama 2 70B를 능가함
- 특히, 코드 생성 과 수학 벤치마크에서 더 뛰어난 성능을 보였음

Size and Efficiency

Llama 2 계열 모델과 성능을 비교해서 Mixtral이 비용 대비 성능 측면에서 얼마나 효율적인지 분석함 (→ 즉, 같은 계산량이면 누가 더 성능이 좋을지)
- Sparse MoE 모델인 Mixtral은 모델 자체는 47B이지만, 토큰 하나를 처리할 때 13B Active 파라미터들만 사용
  - Expert가 8개이지만, K=2로 실제 계산량은 13B정도
- 또한, 이 분석은 계산량만 비교한 것
  - 추론 비용에는 계산량, 메모리, GPU 활용률 3가지 가 있는데, 여기서는 계산량만!
Mixtral은 13B만 계산하지만, GPU에는 47B를 올려야 하긴함
- Router가 어떤 Expert를 선택할지 모르기 때문임
- 그럼에도 Llama2의 70B보다는 메모리가 작긴함
장치 활용 측면에서는 SMoE Layer는 Routing과 여러 Expert 실행 때문에 추가적인 오버헤드(본래 목적 외 추가적으로 드는 비용)를 발생시킴
- MoE는 Arithmetic Intensity가 높은 Batch 작업에 더 적합함(→ 토큰이 많을수록 더 효율적)

Comparison with Llama 2 70B and GPT-3.5

대표적인 대형 오픈소스 모델인 Llama2 70B와 대표적인 폐쇄형 모델 GPT-3.5와 비교 진행
결과를 보면, Mixtral이 70B Dense 모델과 GPT-3.5를 따라잡거나 넘어섰음을 볼 수 있음
- MMLU에서 Mixtral이 훨씬 작은 용량임에도 더 높은 성능을 보였음
- MT-Bench 에서는 당시 사용가능한 최신 GPT-3.5-turbo-1106 성능과 비교함

Evaluation Differences

같은 모델이라도 평가 방식이 조금만 달라져도 점수가 달라질 수 있음
- 일부 벤치마크에서는 본 논문의 평가 프로토콜과 Llama2논문에서 사용한 프로토콜 사이에 차이가 있다
  - MBPP에서는 hand-verified된 부분집합(subset)을 사용했음
  - TriviaQA에서는 위키피디아 문서를 제공하지 않았음

3.1 Multilingual Benchmarks

Mistral 7B와 비교하여 사전학습 과정에서 다국어(multilingual) 데이터의 비중을 크게 늘렸음
- 보통은 다국어를 많이 학습하게 되면 영어 성능이 조금 떨어질 수도 있지만, Mixtral의 경우에는 영어도 잘하고, 프랑스어, 독일어 등등 모두 잘했음
  - 왜그런가하면, Dense 모델의 경우에는 FFN 하나만 가지고 있지만, Mixtral의 경우에는 Expertrk 8개이므로 모델 전체 파라미터가 늘어나서임!

3.2 Long Range Performance

Mixtral이 긴 문맥을 처리하는 능력을 평가하기 위해 Passkey Retrieval 이라는 테스트를 진행함
- 32K Context는 30,000~40,000 단어 정도를 한 번에 읽을 수 있다는 의미인데, 읽는다고 해서 다 기억하는 건 아님 → 즉, 기억력을 테스트해봐야함
- Passkey Retrieval은 긴 프롬프트 안에서 무작위로 삽입된 Passkey를 모델이 찾아낼 수 있는지를 측정하기 위한 Synthetic task임

Mixtral이 context의 길이나 passkey의 위치와 관계없이 100%정확도 달성(모두 초록색 1.0)
- passkey가 앞에 있어도, 뒤에 있어도 항상 다 찾아냄!
Proof-Pile 데이터세트의 일부에서 Context 크기가 증가할수록 Mixtral의 Perplexity가 단조적으로 감소함
- 즉, 문맥을 더 많이 보여줄수록 더 정확하게 다음 단어를 예측했다는 의미임
  ✓ Perplexity?
  - LLM이 다음 단어를 얼마나 잘 맞추는지를 측정하는 지표임
  - 이는 작을 수록 좋은데,
    
    PPL 의미
    100 매우 나쁨
    20 보통
    10 좋음
    5 매우 좋음

PPL	의미
100	매우 나쁨
20	보통
10	좋음
5	매우 좋음

3.3 Bias Benchmarks

파인튜닝하고 preference modeling을 통해 수정해야할 결함을 찾기 위해서 base 모델 성능을 BBQ와 BOLD 벤치마크에서 측정함
- BBQ는 사람이 직접 작성한 질문들로 이루어진 데이터세트이고, 사회적으로 확인된 편향을 9개의 범주(나이, 장애 여부, 성 정체성, 국적, 외모, 인종/민족, 종교, 사회 경제적 지위, 성적 지향)에 대해 평가함
- BOLD는 5개의 영역에서 편향을 평가하기 위한 23,679개의 영어 생성 프롬프트로 구성된 대규모 데이터세트임 → BBQ는 질문-답변 구조인데, BOLD는 문장을 생성함
Mixtral과 Llama2를 Evaluation Framework를 사용하여 평가함
- BBQ의 경우, 점수가 높을수록 더 공정한 답변을 함
- BOLD는 ① 평균 감성 점수 ② 표준편차를 활용함
  - 평균 감성점수는 높을수록 긍정적인 문장 생성
  - 표준편차는 낮을수록 사람마다 비슷하게 대함 → 예를 들어, 여성에 대해서는 항상 긍정적으로 말하고 남성에 대해서는 항상 부정적으로 말한다면 평균만 보면 판단하기 어려움. 때문에 그룹마다 얼마나 차이가 나는지도 측정함
결과적으로, Mixtral은 전체적으로 더 긍정적인 표현을 사용했고, 특정 집단만 특별히 다르게 대하지도 않았음

4. Instruction Fine-tuning

Mixtral-Instruct는 한 번에 만들어진 건 아니고 총 2단계로 학습 진행
- Instruction dataset를 사용하여 supervised fine-tuninig(SFT)을 수행한 후,
- Paired Feedback Dataset을 사용하여 Direct Preference Optimization(DPO)을 적용하여 Mixtral-Instruct를 학습시킴
  
  ⇒ 사람이 작성한 좋은 예시를 따라 배우고(SFT), 그 다음에는 사람이 더 선호하는 답변을 선택하도록(DPO) 추가학습
Mixtral-Instruct는 MT-Bench에서 8.30점을 기록햇고, 23년 12월 기준으로 가장 우수한 Open-Weights 모델이 됨

LMSys라는 기관에서 평가를 진행했을 때, 다른 모델들보다 더 우수한 성능을 보였음

5. Routing analysis

본 절에서는 “Router가 도대체 어떤 기준으로 Expert를 고르는지”
- 특히 학습과정에서 일부 Expert가 특정 도메인(ex. 수학, 생물학, 철학 등)에 전문화되었는지를 확인하고자 함
The Pile Validation Dataset의 여러 하위 데이터세트에서 선택된 Expert의 분포를 측정함
- 0층, 15층, 31층을 분석함
- transformer에서는 layer가 깊어질수록 표현이 바뀜
  - layer0 → 거의 단어 자체
  - layer31 → 의미가 많이 반영된 표현

⭐️ 결과적으론, 주제에 따라 Expert가 할당되는 명확한 패턴을 관찰하지는 못함 ⭐️
- 모든 Layer에서 ArXiv 논문, 생물학 문서, 철학 문서는 모두 비슷한 Expert분포를 보였음

⇒ ❓ 그러면 어디에 특화된거지?

Expert분포는 DM Mathematics에서만 다르게 나타났음, 근데 차이가 그렇게 크진 않았음

수학이라서 생긴 차이라고 보진 않았고, 그냥 데이터세트가 인위적이라서로 판단

Expert분포의 경우에는 첫 번째 layer와 마지막 layer에서 특히 차이가 두드러졌음

이 layer들의 hidden state는 각각 입력 임베딩과 출력 임베딩이 매우 높은 상관 관계를 갖기 때문

layer0의 경우에는 거의 입력 단어 그 자체이고(DM Mathematics의 특이한 입력 구조가 그대로 반영됨)

layer 31의 경우에는 거의 출력 단어 직전 상태임(수학 토큰 같은 특수 출력이 반영됨)
⇒ 즉, 그 차이가 가장 잘 드러나는 위치가 맨 앞과 맨 뒤 층이라는 것
⇒ 이는 Router가 일정한 구문적 행동을 보인다는 것을 시사함

수학인지, 철학인지를 보는게 아니라 문법(구문)을 보고 있다는 것!!

✓ 왜 이런 결과가 나왔을까?

FFN은 문장을 이해하는 곳이라기보단, 각 토큰의 표현을 변환하는 곳임

도메인 정보의 경우에는 Attention에서 처리될 가능성이 존재함

즉, FFN(MoE)은 “이 토큰이 어떤 종류의 표현 반환을 필요로 하는가?”에 더 집중할 가능성이 있음

식별자, 들여쓰기, 함수호출, 조사 및 관사 처럼 비슷한 구조를 가진 토큰은 서로 비슷한 변환이 필요할 수 있음

때문에 router가 구문적 특징을 기준으로 Expert를 선택하는 것이 자연스러운 결과라고 볼 수 있음

좀 더 자세히 설명해보자면~

Transformer

하나의 layer에서는 input → multi-head self-attention → feed forward network(FFN) → output

Mixtral

Attention → MoE(=여러 Expert FFN)으로 바뀜

⇒ 즉, Attention은 FFN만 Expert 여러 개로 바뀐 것

Attention은 토큰끼리의 관계를 보는 곳임 → 즉, 문맥, 의미, 토큰 간의 관계를 만드는 것이 어텐션

반면, FFN은 토큰 하나를 독립적으로 변환하는 역할 → Attention이 끝나면 각 토큰은 이미 cat → "고양이 + 주변 문맥" 을 가지고 있음

→ FNN은 그래서 이 표현을 더 좋은 표현으로 바꾸는 역할을 함(벡터를 더 유용한 벡터로)

입력이 self 라고 하면, Attention이후에는 “python 코드 안의 self” 라는 의미를 가지고 있는데, FFN은 이 벡터를 더 코드에 적합한 표현으로 변환하는 역할

self → python 변수 → 클래스의 인스턴스 변수

그러면 왜 self를 항상 같은 Expert가 처리를 할까.

router가 “python 코드다!!” 를 본게 아니라
”self라는 토큰은 항상 비슷한 표현 변환이 필요하네” 라고 학습했을 가능성이 있기 때문이다.

✓ 그런데, 논문을 보면 self, 들여쓰기 와 같은 토큰은 Expert로 가는데, dog나 biology처럼 의미를 담고 있는 단어들은 같은 Expert로 가지 않는다. 왜 그럴까?

일단 먼저, Router의 목표는 무엇일까?

수학 → 수학 Expert라고 생각하지만, 실제로는 그렇지 않음

router은 도메인을 분류하는 모델이 아니다.

⇒ Router의 목표는 “이 ‘토큰’을 가장 잘 처리할 Expert가 누구인가”

예를 들면, python 코드가 아래와 같이 있다고 하자.

class Dog:
def bark(self):
print("멍")

⇒ Router는 문서전체를 보고 “이건 python이다.”라고 판단하지 않고, 대신 토큰 하나하나를 보는 편

class → 어떤 Expert?, def → 어떤 Expert? …

이때 self 를 보면, 역할이 거의 동일함(”현재 객체 자신”) → 때문에 표현을 변환하는 방식도 비슷

⇒ 그래서 Router의 입장에서는 self → 항상 Expert3으로 보내는 것이 학습하기 쉬울 것

반면, dog와 같이 의미가 담긴 토큰이라면, dog과 hotdog는 같은 dog가 들어가더라도 전혀 다른 의미를 가지고 있음 ⇒ 때문에 항상 같은 Expert로 보낼 이유가 없음!!

각 토큰은 자신이 선택된 Expert에 대응하는 배경색으로 표시되어 있음
- 즉, Router가 실제로 어떤 토큰을 어떤 Expert로 보내는지에 대해 나와있음
- python의 self, 영어의 Question 같은 단어가 여러 번 등장하더라도 같은 Expert로 라우팅됨을 보여줌
  - 이때, LLM은 단어(word)가 아닌 토큰(token)을 처리하는데, 이때 단어가 토크나이저에 의해 Quest/ion 처럼 2개 이상의 토큰으로 분리될 수도 있음에도 각 토큰들이 같은 Expert를 선택
- 들여쓰기 토큰들도 항상 같은 Expert에 할당됨
- 연속된 토큰들도 종종 같은 Expert에 할당됨을 확인할 수 있었음
  - 토큰 하나만 같은 Expert가 아니라 옆에 있는 토큰들까지도 같은 Expert로 가능 경우도 있었음
    
    ⇒ Positional Locality
    ✓ Positional Locality가 뭘까?
    - 결과적으로 옆에 있는 토큰들이 같은 Expert를 선택하는 경우가 많았다는 관찰 결과임
    - 본 논문에서는 왜 이런 현상이 나타났는지에 대해 나와있진 않고, 일반적인 연구자들의 해석은 어떻냐 하면!!
      
      문장이 I am glad to be a BOAZ member. 라고 하면, 토큰은 I am glad to be a BOAZ 가 됨
      
      Attention을 거친 후에는 이 토큰들의 hidden state가 완전히 독립적이지 x
      
      glad는 am도 보고 to 도 보고 be도 봄.
      
      a 도 be 를 보고 있음
      
      ⇒ 즉, 연속된 토큰들은 비슷한 문맥을 공유함
```
    ⇒ 그래서 **hidden state가 비슷하면** 선택되는 Expert도 비슷해질 가능성이 높아짐
```
    ✓ Positional Locality가 모델 성능 관점에 있어서도 괜찮을까?
    - 같은 Expert만 사용하게 된다면 다양성이 떨어지면서 더 낮지 않을까 라는 생각을 했었음
      
      논문에서는 성능이 떨어진다는 증거는 없었음 오히려, 더 좋은 성능을 냄
      
      → 하지만, Router는 학습됨 즉, 성능이 떨어지면 역전파를 통해 Router의 가중체 $W_g$ 도 함께 수정됨
    - 시스템 측면에서는 장단점이 존재함
      
      같은 Expert를 계속 사용하면 GPU가 계속 같은 Expert를 실행하면됨
      
      Expert3 → Expert3 → Expert3 이렇게 되면 메모리나 캐시를 재사용하기 쉬워서 추론이 빨라질 수 있음
      
      반면, Expert Parallelism에서는 문제가 될 수 있음
      
      GPU마다 Expert 하나씩 있다고 할 때, 토큰 1000개가 모두 Expert3로만 가면 GPU3만 엄청 바빠지게 됨

6. Conclusion

본 논문에서는 Mixtral 8x7B를 소개했음
- 오픈소스 모델 중 SOTA 성능을 달성한 최초의 Mixture-of-Experts 네트워크
- 사람들이 평가한 벤치마크에서도 당시의 대표적인 상용 LLM보다 더 좋은 평가를 받았었음
또한, Mixtral은 매 시점마다 2개의 Expert만 사용하기 때문에 토큰당 13B의 Active Parmeters만 사용하면서도, 토큰당 70B파라미터를 사용하는 기존 최고 모델(Llama2 70B)보다 더 뛰어난 성능을 달성함