Skip to content
Published on

MoE 라우팅 — 전문가는 어떻게 뽑히는가

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드✨Start Quiz
공유하기
Authors

들어가며

앞 글에서 config.json으로 조밀한 모델의 파라미터를 세어 봤습니다. 그런데 요즘 큰 모델의 config를 열면 num_experts나 n_routed_experts 같은 낯선 필드가 나옵니다. 전문가 혼합, 즉 MoE 계층입니다.

아이디어는 단순합니다. 층마다 하나뿐이던 FFN을 여러 개의 작은 FFN으로 쪼개고, 토큰마다 그중 몇 개만 실행합니다. 이 글은 그 "몇 개만"이 config에 어떻게 적히고, 무엇을 아끼고 무엇을 아끼지 못하는지를 다룹니다.

수치는 2026-08-12에 논문·공식 리포트·config.json에서 직접 확인했습니다. 모델은 갱신되므로 원본을 다시 확인하세요.

가장 단순한 형태: Mixtral

Mixtral-8x7B의 config에서 MoE 관련 필드만 뽑으면 이렇습니다.

{
  "num_local_experts": 8,
  "num_experts_per_tok": 2,
  "intermediate_size": 14336,
  "router_aux_loss_coef": 0.02
}

전문가가 8개이고 토큰마다 2개를 씁니다. Mixtral 논문은 이 구조를 두고 전체 470억 파라미터 중 토큰당 130억만 사용한다고 적습니다(arXiv:2401.04088). 같은 논문은 라우터가 매 층, 매 토큰마다 두 전문가를 고르며 시점마다 다른 전문가가 선택될 수 있다고 설명합니다.

활성 파라미터와 전체 파라미터

여기서 가장 중요한 오해를 짚고 갑니다. 활성 파라미터가 줄어드는 것은 연산량이지 메모리가 아닙니다. 전문가는 언제 호출될지 모르므로 전부 메모리에 올라가 있어야 합니다. Mixtral 논문도 서빙 메모리 비용은 희소 파라미터 수인 470억에 비례한다고 명시합니다.

Qwen3-30B-A3B로 직접 계산해 보겠습니다. config는 hidden_size 2048, 층 48개, 전문가 128개, num_experts_per_tok 8, moe_intermediate_size 768입니다.

전문가 하나 (게이트/업/다운 3개 행렬)
  = 3 x 2,048 x 768 = 4,718,592

층 하나의 전문가 전체 : 128 x 4,718,592 = 603,979,776
층 하나에서 실제 실행 :   8 x 4,718,592 =  37,748,736

전체 파라미터 (계산) = 30,532,122,624   -> 공개 값과 정확히 일치
활성 파라미터 (계산) =  3,353,032,704   -> 약 3.35B, 이름의 A3B와 일치

비율 = 3.35B / 30.53B = 약 11%

연산은 11퍼센트만 하지만 메모리는 100퍼센트 필요합니다. MoE의 본질은 메모리를 연산으로 바꿔 주는 거래가 아니라, 메모리를 더 쓰는 대신 같은 연산으로 더 많은 지식을 담는 거래입니다.

공유 전문가와 조밀한 첫 층

DeepSeek-V3는 조금 다른 구조를 씁니다. 기술 리포트의 모델 하이퍼파라미터 절에 따르면 층은 61개, 각 MoE 계층은 공유 전문가 1개와 라우팅 전문가 256개로 이루어지고, 라우팅 전문가 중 8개가 토큰마다 활성화됩니다. 전문가 내부 차원은 2048입니다. 전체 6710억 중 토큰당 370억이 활성화됩니다(arXiv:2412.19437).

공유 전문가는 라우팅과 무관하게 모든 토큰이 항상 통과하는 전문가입니다. 어느 토큰에나 필요한 공통 기능을 여기에 몰아 두면, 라우팅 전문가들은 더 특화된 역할을 맡을 수 있습니다.

또 하나 눈여겨볼 필드가 first_k_dense_replace입니다. DeepSeek-V3는 이 값이 3이고, 리포트도 첫 세 층을 제외한 모든 FFN을 MoE로 바꿨다고 적습니다. Kimi K2는 같은 필드가 1입니다. 초기 층은 토큰별 특화보다 일반적인 표현을 만드는 일을 하므로 조밀하게 두는 편이 안정적이라는 판단입니다.

로드 밸런싱: 두 갈래

라우터를 그냥 두면 소수의 전문가에게 토큰이 몰립니다. 나머지 전문가는 학습되지 않고, 병렬화한 장비 사이에 부하가 쏠립니다. 해결책은 크게 두 갈래입니다.

첫째는 보조 손실입니다. 부하가 균등해지도록 손실 항을 추가합니다. config의 router_aux_loss_coef가 그 계수이고, Mixtral은 0.02, Qwen3 MoE 모델들은 0.001입니다. Qwen3 리포트는 전문가 특화를 장려하기 위해 전역 배치 단위의 로드 밸런싱 손실을 채택했다고 밝힙니다(arXiv:2505.09388). 문제는 이 손실이 본래 목적함수와 다투기 때문에 성능을 조금 깎는다는 점입니다.

둘째는 보조 손실을 쓰지 않는 방식입니다. DeepSeek-V3는 전문가마다 편향 항을 두고 상위 k개를 고를 때만 그 편향을 더합니다. 리포트에 따르면 편향은 라우팅에만 쓰이고, 매 스텝 끝에 과부하 전문가는 편향을 낮추고 저부하 전문가는 올립니다. 편향 갱신 속도는 처음 14.3조 토큰 동안 0.001이었다가 남은 5000억 토큰에서는 0으로 바뀝니다. 극단적 쏠림만 막기 위한 시퀀스 단위 균형 손실은 계수 0.0001로 아주 작게 유지합니다.

두 방식의 차이는 분명합니다. 보조 손실은 구현이 단순하지만 목적함수를 오염시키고, 편향 방식은 목적함수를 건드리지 않지만 조정할 하이퍼파라미터와 학습 중 스케줄이 늘어납니다.

희소도를 얼마나 올릴 것인가

Kimi K2는 전문가 수를 384개로 늘렸습니다. 리포트의 표 2는 DeepSeek-V3와 나란히 비교합니다. 층 수는 61개로 같고, 전체 파라미터는 6710억에서 1.04조로 늘었지만 활성 파라미터는 370억에서 326억으로 오히려 줄었습니다. 전문가는 256개에서 384개로 늘고 토큰당 활성 전문가는 8개로 같습니다(arXiv:2507.20534).

같은 리포트는 희소도를 전체 전문가 수를 활성 전문가 수로 나눈 값으로 정의하고, 활성 파라미터를 고정한 채 전체 전문가를 늘리면 학습·검증 손실이 일관되게 낮아졌다고 보고합니다. 검증 손실 1.5를 기준으로 희소도 48은 희소도 8, 16, 32 대비 각각 1.69배, 1.39배, 1.15배 적은 연산량으로 같은 지점에 도달했다고 적습니다.

대가도 같은 문단에 적혀 있습니다. 희소도를 올리면 인프라 복잡도가 올라가고, 그래서 성능과 비용의 균형점으로 48을 골랐다고 밝힙니다. 전문가가 많아질수록 장비 간 all-to-all 통신량과 배치 스케줄링 난이도가 함께 올라갑니다.

라우팅 범위 제한

DeepSeek-V3의 config에는 n_group 8, topk_group 4가 있습니다. 전문가를 그룹으로 묶고 토큰 하나가 닿을 수 있는 그룹 수를 제한하는 장치입니다. 리포트도 각 토큰이 최대 4개 노드로만 전송되도록 보장한다고 적습니다. 통신 비용에 상한을 두는 설계입니다. 반면 Kimi K2는 표 2에서 전문가 그룹화를 쓰지 않는다고 명시합니다. 같은 문제를 서로 다른 인프라 전제 위에서 푼 결과입니다.

마치며

MoE의 config는 네 가지만 보면 됩니다. 전문가가 몇 개인지, 토큰당 몇 개를 쓰는지, 공유 전문가가 있는지, 그리고 균형을 손실로 잡는지 편향으로 잡는지입니다. 이 네 값에서 활성 파라미터를 계산할 수 있고, 활성 파라미터는 연산 비용을, 전체 파라미터는 메모리 비용을 알려 줍니다. 두 숫자를 분리해서 읽는 것이 MoE를 이해하는 출발점입니다.

참고 자료

직접 해보기

시리즈

Discuss on Twitter • View on GitHub