전문가 혼합(MoE): 거대 모델을 싸게 돌리는 법

왜 필요했나: 모델을 키우면 계산도 같이 커진다

딥러닝에서는 데이터가 충분히 많으면 모델의 용량, 곧 파라미터 수를 늘릴수록 예측이 좋아진다. 문제는 보통 모델이 입력이 들어올 때마다 모든 파라미터를 다 계산한다는 점이다. Sparsely-Gated MoE 논문논문은 이런 구조에서는 모델 크기와 학습 데이터가 함께 커질 때 학습 비용이 대략 제곱으로 늘어나고, 계산 자원이 늘어나는 속도가 이를 따라가지 못한다고 지적했다.

해법으로 오래전부터 거론된 것이 조건부 계산(conditional computation)이다. 입력마다 네트워크의 일부만 켜고 나머지는 꺼 두면, 용량은 키우면서 계산량은 덜 늘릴 수 있다. 하지만 같은 논문은 이 생각이 실제로 잘 작동한 적이 없다고 짚고 그 이유를 정리했다. GPU는 분기 처리보다 산술 계산에 훨씬 강하고, 일부만 켜면 각 부분에 들어가는 배치가 작아져 효율이 떨어지며, 여러 GPU 사이의 네트워크 대역폭이 병목이 되고, 고르게 일을 나누려면 별도의 손실 항이 필요하다는 것이다.

MoE는 이 문제들을 엔지니어링으로 풀어 '파라미터는 크게, 토큰당 계산은 작게'를 실제로 해낸 방법이다. 이 논문에 따르면 전문가 혼합 아이디어 자체는 1991년 무렵부터 연구됐지만, 현대 대규모 언어 모델의 한 부품으로 자리 잡은 출발점은 이 2017년 연구다.

핵심 아이디어: 필요한 진료과만 부르는 종합병원

종합병원을 떠올리면 쉽다. 병원에는 수십 개 진료과가 있지만, 환자 한 명은 안내 데스크에서 증상을 듣고 정해 준 한두 과에서만 진료를 받는다. 병원 전체의 전문성(용량)은 크지만 환자 한 명에게 드는 진료 시간(계산량)은 작다. MoE에서 진료과는 '전문가(expert)', 안내 데스크는 '라우터' 또는 '게이팅 네트워크'다.

트랜스포머로 말하면, 각 층에는 어텐션 다음에 피드포워드 네트워크(FFN, 토큰 하나하나를 따로 변환하는 작은 신경망)가 있다. Switch Transformer논문는 이 FFN 하나를 여러 벌의 FFN 전문가로 바꾸고, 라우터가 토큰마다 어느 전문가로 보낼지 정하게 했다. 모델에 들어 있는 전체 파라미터와, 토큰 하나를 처리할 때 실제로 계산에 쓰이는 활성 파라미터가 이렇게 갈라진다.

중요한 점은 라우터가 사람이 짠 규칙이 아니라 함께 학습되는 작은 신경망이라는 것이다. 어떤 전문가가 무엇을 맡을지는 미리 정하지 않는다. Sparsely-Gated MoE 논문논문은 학습이 끝난 뒤 전문가들이 문법과 의미에 따라 상당히 전문화되는 경향을 관찰했다.

어떻게 작동하나: 점수 매기기, 고르기, 섞기

한 MoE 층이 토큰 하나를 처리하는 과정은 네 단계로 볼 수 있다. 첫째, 토큰의 Representation(그 시점까지 계산된 벡터)이 라우터에 들어간다. 둘째, 라우터는 간단한 행렬 곱으로 전문가마다 점수를 내고, 이를 소프트맥스로 확률처럼 바꾼다. 셋째, 점수가 가장 높은 k개 전문가만 고른다(top-k). 넷째, 고른 전문가들이 각자 토큰을 계산하고, 그 출력을 라우터 점수로 가중합해 다음 층으로 넘긴다. Switch Transformer논문는 이 계산을 수식으로 정리했는데, 고르지 않은 전문가는 아예 계산하지 않는다는 것이 핵심이다.

이 선택은 토큰마다, 층마다 따로 일어난다. Mixtral논문을 예로 들면 각 층에 FFN 전문가 8개가 있고 라우터가 토큰마다 2개를 고른다. 같은 문장 안에서도 단어마다, 같은 단어라도 층마다 다른 전문가 조합이 쓰일 수 있다. 그 결과 토큰 하나가 접근할 수 있는 파라미터는 47B지만 추론 때 실제로 쓰는 활성 파라미터는 13B다.

여러 GPU로 학습할 때는 전문가를 장치마다 나눠 둔다. Switch Transformer논문는 서로 다른 전문가의 가중치를 서로 다른 장치에 두기 때문에 장치를 늘릴수록 모델 가중치도 늘고, 장치 하나의 메모리와 계산 부담은 감당할 만하게 유지된다고 설명한다. 대신 토큰을 자기 전문가가 있는 장치로 보내고 결과를 다시 받아 와야 하므로 통신이 생긴다. 이 통신 비용이 MoE 설계의 핵심 제약 중 하나다.

발전 흐름: LSTM 사이의 MoE에서 공개 MoE 모델까지

Sparsely-Gated MoE논문는 출발점이다. 최대 수천 개의 피드포워드 전문가와 학습 가능한 게이팅 네트워크로 MoE 층을 만들고, 이를 쌓인 LSTM 층 사이에 끼워 최대 137B 파라미터 모델을 만들었다. 저자들은 현대 GPU 클러스터에서 계산 효율을 조금만 잃고 모델 용량을 1000배 넘게 키웠으며, 언어 모델링과 기계 번역에서 더 적은 계산으로 당시 최고 성능보다 좋은 결과를 냈다고 보고했다.

Switch Transformer논문는 이 아이디어를 트랜스포머로 옮기면서 단순하게 만들었다. 이전 연구는 라우터가 제대로 학습되려면 전문가를 2개 이상 골라야 한다고 추측했지만, Switch는 라우팅 알고리즘을 단순화해 통신과 계산 비용을 줄였다. 저자들은 MoE 보급을 막은 원인으로 복잡성, 통신 비용, 학습 불안정을 꼽았고, 학습 기법을 다듬어 큰 희소 모델을 처음으로 bfloat16 같은 낮은 정밀도로 학습했다. 같은 계산 자원으로 T5-Base·T5-Large 기반 모델보다 사전학습이 최대 7배 빨랐고, 101개 언어 모두에서 개선을 확인했으며, 1조 파라미터 규모까지 키워 T5-XXL보다 4배 빠른 사전학습을 보고했다. 전문가가 2개뿐일 때도 이득이 있었고, 큰 희소 모델을 작은 밀집 모델로 Distill하면 모델 크기를 최대 99% 줄이면서 품질 이득의 30%를 유지했다.

Mixtral논문은 MoE를 연구실 밖으로 끌어낸 사례다. Mistral 7B와 같은 구조에 층마다 전문가 8개를 두고 토큰마다 2개를 쓰는 방식으로, 32k 토큰 컨텍스트로 학습했다. 저자들은 평가한 모든 벤치마크에서 Llama 2 70B와 GPT-3.5보다 좋거나 비슷했고, 특히 수학·코드 생성·다국어에서 Llama 2 70B를 크게 앞섰다고 밝혔다. Base 모델과 Instruct 모델을 Apache 2.0 라이선스로 공개해, 누구나 내려받아 쓸 수 있는 오픈웨이트 MoE의 대표 사례가 됐다.

요즘 어디로 가고 있나: 몇 개를, 어떤 모양으로, 어떻게 서빙할까

최근 연구의 질문은 'MoE가 되느냐'에서 '어떻게 설계하고 운영하느냐'로 옮겨 갔다. 첫째는 용량 배분이다. 다국어 MoE 스케일링 연구논문는 활성 파라미터, 언어별 학습 토큰, 전문가 수, 언어 수를 함께 다루는 스케일링 법칙을 제안했다. 사전학습한 64개 구성에서 얻은 26,300개 언어별 손실 관측값으로 맞췄고, 처음 보는 구성에 대한 예측 오차를 가장 강한 비교 기준보다 28% 줄였다. 활성 파라미터와 언어별 학습 토큰을 같게 맞췄을 때, 전문가 32개를 둔 모델은 지원 언어를 12개에서 200개로 늘릴 때 생기는 손실 증가를 밀집 모델보다 83% 줄였다. 언어를 넓게 다룰수록 전문가를 더 많이 두는 편이 유리하다는 뜻이다.

둘째는 전문가의 모양이다. 요즘 세밀한(fine-grained) MoE는 전문가 하나하나를 좁게 만드는 대신 개수를 늘리는 경우가 많다. 전문가 모양 연구논문는 이렇게 모양을 라우팅 단위에 따라 덤으로 정할 일이 아니라고 본다. 전문가의 입력 차원과 중간 폭을 명시적인 설계 선택으로 다뤘더니, 모델 규모와 라우팅 단위를 바꿔 가며 실험해도 두 값이 비슷한 '정사각형에 가까운' 전문가가 일관되게 유리했다. 층마다 전문가 수와 모양을 다르게 배분하는 방식도 같은 파라미터·계산량·통신량에서 검증 손실을 낮췄다.

셋째는 서빙이다. DuoRate논문는 MoE 서빙이 정밀도 비용을 두 번 낸다고 지적한다. 저장할 때는 라우터가 고를 수 있는 모든 전문가의 비용을, 디코딩 한 단계에서는 실제로 고른 전문가의 비용만 낸다. 둘의 차이를 'store-read gap'이라 부르는데, 공개된 BitsMoE 체크포인트에서는 저장 기준 가중치당 2.54비트가 디코딩 트래픽으로는 7.50비트가 됐다. DuoRate는 한 번 저장하고 작업에 맞춰 읽는 비트 수를 정하는 방식으로, Qwen3-30B-A3B에서 가중치당 2.9비트로 4비트 양자화 형식들과 같은 수준을 냈다고 보고했다.

한계와 쟁점

첫째, 계산이 줄어도 메모리는 줄지 않는다. 토큰당 13B만 계산하는 Mixtral논문도 어떤 토큰이 어느 전문가를 부를지 모르므로 47B 파라미터를 모두 메모리에 올려 둬야 한다. DuoRate논문가 말한 '저장 비용은 모든 전문가에 대해 낸다'는 지적이 바로 이 문제다. 그래서 MoE는 'GPU 메모리(VRAM)는 넉넉하지만 계산은 아끼고 싶은' 환경에 잘 맞고, 메모리가 작은 기기에서는 오히려 부담이 될 수 있다.

둘째, 부하 분산과 통신이다. 라우터가 몇몇 전문가에게만 토큰을 몰아 주면 나머지 전문가는 놀고, 몰린 전문가가 있는 장치는 병목이 된다. Sparsely-Gated MoE논문는 처음부터 원하는 희소성과 부하 균형을 얻으려면 별도의 손실 항이 필요할 수 있다고 짚었다. 전문가가 여러 장치에 흩어져 있으면 토큰을 주고받는 네트워크 비용도 커진다. Switch Transformer논문가 복잡성·통신 비용·학습 불안정을 보급의 걸림돌로 꼽은 것도 같은 맥락이다.

셋째, 효율 비교는 기준을 잘 봐야 한다. 'MoE가 더 크고 더 싸다'는 말은 대개 같은 활성 파라미터나 같은 FLOPS 기준의 비교다. 전체 파라미터, 메모리, 실제 처리량(토큰/초) 기준으로 보면 결론이 달라질 수 있다. 다국어 연구논문처럼 '활성 파라미터와 학습 토큰을 맞췄을 때'라는 조건이 붙은 결과는 그 조건 안에서만 읽어야 한다.

더 공부하려면

처음이라면 Switch Transformer논문의 2장부터 읽기를 권한다. 라우터 점수 계산, top-k 선택, 가중합이 짧은 수식 두 개로 정리돼 있고, 밀집 FFN을 Switch FFN으로 바꾼 그림이 있어 구조를 잡기 좋다. 이어서 Sparsely-Gated MoE논문의 1장을 읽으면 조건부 계산이 왜 그전까지 실패했는지(분기, 배치 축소, 대역폭, 부하 균형)를 알 수 있어, MoE 설계 결정의 이유가 보인다.

실제 모델 감각을 원하면 Mixtral논문의 초록과 구조 설명을 보며 '8개 중 2개', '47B 대 13B'가 무엇을 뜻하는지 확인하자. 그다음 관심사에 따라 최근 연구를 고르면 된다. 모델 설계는 전문가 모양 연구논문와 다국어 스케일링 연구논문, 배포와 비용은 DuoRate논문가 좋은 출발점이다.