MoE 입문: 36B 모델이 27B보다 6배 빨랐던 이유

로컬에서 AI 모델을 돌리다 보면 이런 상식이 생깁니다. 모델이 크면 똑똑하지만 느리다. 대체로 맞습니다.

그런데 얼마 전에 정반대를 겪었습니다. 파라미터가 더 많은 모델로 바꿨더니 6배 빨라졌습니다. 답변 품질도 더 좋았고요.

27B 모델   →  100토큰 답변에 113.8초
36B 모델   →  같은 답변에 17.8초

차이는 크기가 아니라 구조였습니다. 뒤쪽이 MoE라는 방식으로 만들어진 모델이었습니다.

먼저, 파라미터가 뭔가요

모델 이름에 붙는 27B, 36B는 파라미터 수입니다. 270억 개, 360억 개라는 뜻입니다.

파라미터는 모델이 학습하면서 조정해둔 숫자들입니다. "이 단어 다음에는 저 단어가 올 확률이 높다" 같은 판단이 전부 이 숫자들에 담겨 있습니다. 많을수록 더 많은 것을 기억하고 더 섬세하게 판단합니다.

문제는 글자 하나를 만들 때마다 이 숫자들을 읽어야 한다는 점입니다.

보통 모델은 매번 전부 읽습니다

일반적인 모델을 dense(밀집) 모델이라고 부릅니다. 이름 그대로 빽빽합니다.

dense 모델은 글자 하나를 만들 때 파라미터 전체를 훑습니다. 270억 개면 270억 개 전부입니다. 다음 글자를 만들 때도 또 전부 읽습니다.

회사에 비유하면 이렇습니다.

질문이 하나 들어올 때마다 전 직원 270명이 회의실에 모입니다. 대부분은 그 질문과 상관없지만 어쨌든 다 들어옵니다. 회의를 마치고 답을 하나 내면, 다음 질문에 또 270명이 모입니다.

정확하긴 한데 느립니다. 그리고 직원이 많아질수록 회의 소집 자체가 오래 걸립니다.

MoE는 일부만 부릅니다

MoE는 Mixture of Experts, 우리말로 혼합 전문가입니다.

파라미터를 여러 덩어리로 나눠두고 각각을 "전문가"라고 부릅니다. 그리고 글자 하나를 만들 때 그중 몇 명만 부릅니다.

같은 비유로 이어가면 이렇습니다.

직원 270명을 256개 팀으로 나눠뒀습니다. 질문이 들어오면 관련 있는 8개 팀만 회의에 부릅니다. 나머지 248개 팀은 자기 자리에서 대기합니다.

제가 쓰는 모델의 실제 설정값이 이렇습니다.

general.architecture          qwen35moe
general.parameter_count       35,951,822,704   ← 총 360억 개
expert_count                  256              ← 전문가 256명
expert_used_count             8                ← 그중 8명만 사용
block_count                   40               ← 이 판단을 40번 반복

256명 중 8명이면 약 3%입니다. 그래서 총 360억 개짜리 모델인데 매번 읽는 양은 30억 개어치뿐입니다. 모델 이름의 35b-a3b에서 a3b가 그 뜻입니다 — active 3b, 활성 30억.

누가 8명을 고르나요

여기서 가장 많이 오해하는 부분입니다.

사람이 고르는 게 아닙니다. "이건 코딩 질문이니까 코딩 전문가에게" 같은 지정을 하지 않습니다.

모델 안에 라우터라는 작은 장치가 있어서, 지금 처리 중인 내용을 보고 어느 전문가를 부를지 스스로 정합니다. 이 판단 방법도 학습으로 익힌 것입니다.

그리고 전문가에게 "수학 담당", "한국어 담당" 같은 이름표는 없습니다. 학습 과정에서 자연스럽게 역할이 갈린 것이라 사람이 들여다봐도 무엇을 맡았는지 알기 어렵습니다. 그냥 1번 전문가, 2번 전문가입니다.

또 하나. 위 설정에서 block_count가 40인데, 이는 층이 40개라는 뜻입니다. 층마다 8명을 새로 고릅니다. 1층에서 뽑힌 8명과 2층에서 뽑힌 8명이 다를 수 있습니다. 그래서 문장 하나를 만드는 동안 결국 꽤 많은 전문가가 동원되지만, **한 번에 읽는 양은 늘 3%**입니다.

그럼 공짜인가요 — 아닙니다

대가가 있습니다. 전문가 256명 전부가 메모리에 올라가 있어야 합니다.

누가 뽑힐지 미리 알 수 없으니 전원 대기시켜야 합니다. 앞의 비유로 돌아가면, 회의에는 8팀만 들어가지만 256팀 전원이 출근은 해 있어야 합니다.

숫자로 보면 이렇습니다.

	dense 27B	MoE 36B
메모리에 올릴 용량	17.4GB	23.9GB
글자 하나당 읽는 양	27B 전부	3B

메모리는 더 먹고 계산은 덜 합니다. 이 교환이 이득인지는 어느 쪽이 병목이냐에 달렸습니다.

그래서 언제 유리한가

제가 쓰는 서버는 전용 그래픽 메모리가 없고 시스템 메모리를 GPU와 나눠 쓰는 구조입니다. 이런 환경에서는 계산 능력보다 메모리를 읽는 속도가 먼저 한계에 부딪힙니다.

글자 하나마다 27GB어치를 읽어야 하는 dense 모델은 그 읽기 속도에 그대로 묶입니다. 반면 3GB어치만 읽는 MoE는 같은 대역폭으로 훨씬 자주 읽을 수 있습니다.

그래서 6배가 났습니다.

반대로 전용 그래픽 메모리가 넉넉하고 대역폭이 아주 빠른 장비라면 격차가 훨씬 작습니다. dense 모델도 충분히 빠르게 돌기 때문입니다.

같은 모델이 장비에 따라 정반대 평가를 받습니다. MoE가 무조건 좋은 게 아니라, 메모리는 남는데 대역폭이 아쉬운 환경에서 특히 좋습니다.

모델 이름에서 알아보는 법

MoE 모델은 이름에 표시가 붙습니다.

qwen3.6:35b-a3b       총 35B / 활성 3B
qwen3.5:122b-a10b     총 122B / 활성 10B
nemotron-3-super:120b-a12b   총 120B / 활성 12B

a 뒤의 숫자가 활성 파라미터입니다. a가 없으면 dense입니다.

고를 때 기준이 둘로 나뉩니다.

• 앞의 숫자(총 파라미터) → 메모리에 들어가는지
• 뒤의 숫자(활성 파라미터) → 얼마나 빠른지

122b-a10b는 활성이 10B라 빠르겠지만, 총 122B라 메모리가 80GB 넘게 필요합니다. 아무리 빨라도 안 올라가면 못 씁니다.

정리하면

MoE는 "여러 모델을 섞는 것"이 아닙니다. 파일 하나 안에서 파라미터를 나눠두고 매번 일부만 쓰는 방식입니다.

총 파라미터와 활성 파라미터는 다른 것을 뜻합니다. 전자는 메모리, 후자는 속도입니다.

크기만 보고 속도를 짐작하면 틀립니다. 저는 "36B가 27B보다 느리겠지"라고 생각했다가 6배 차이를 반대로 맞았습니다.

로컬에서 모델을 돌리신다면, 지금 쓰는 모델의 같은 세대에 -a 붙은 태그가 있는지 한 번 보시길 권합니다. 메모리에 여유가 있다면 더 크고 더 빠른 선택지가 이미 있을 수 있습니다.