MoE 추론 정리

MoE의 총 파라미터와 활성 파라미터가 왜 다른지부터 짚고 top-k 라우팅과 공유 전문가 구성을 정리했다. Dense 대비 메모리와 연산의 트레이드오프도 표로 비교한다.

MoE란

MoE(Mixture of Experts)란 FFN(Feed Forward Network) 레이어를 여러 전문가(Expert)로 나눠 두고 토큰마다 일부만 골라 계산하는 구조

Dense 구조에서는 모델을 키우면 품질과 함께 토큰 하나당 연산도 그대로 불어남.

총 파라미터는 모델이 가진 가중치 전부이고, 활성 파라미터는 토큰 하나를 처리할 때 실제로 곱해지는 가중치

게이팅(Gating)이란 토큰마다 어느 전문가로 보낼지 점수를 매겨 정하는 절차

전문가 하나를 얼마나 작게 쪼갤지, 항상 켜두는 전문가를 둘지가 구성의 두 축

세분화 전문가(Fine-grained Expert): 전문가 하나를 작게 만들고 개수를 늘리는 방식
Qwen3.6-35B-A3B의 Expert Intermediate Dimension은 512로, 같은 세대 Dense인 Qwen3.6-27B의 FFN Intermediate Dimension 17408에 견주면 매우 작음
전문가가 잘게 나뉘면 고를 수 있는 조합이 늘어 표현력↑
공유 전문가(Shared Expert): 라우팅과 무관하게 항상 활성화되는 전문가
Qwen3.6-35B-A3B의 토큰당 활성 구성은 8 Routed + 1 Shared
공유 전문가가 모든 토큰에 공통으로 드는 계산을 맡음 → 라우팅 전문가끼리 같은 것을 중복해 익히는 낭비가 줄어듦

같은 세대에 컨텍스트 길이도 같아 구조 차이만 놓고 견줄 수 있음

메모리를 용량과 대역폭으로 갈라서 봐야 손익이 드러남

활성 파라미터가 깎아 주는 것은 FFN 몫이고, 나머지 비용은 Dense와 같은 값을 냄

전문가로 나뉜 것은 FFN뿐 → 어텐션 연산은 활성 파라미터와 무관하게 그대로 듦
KV cache 크기는 전문가 수가 아니라 레이어·KV 헤드·시퀀스 길이로 정해짐
임베딩과 출력 레이어도 라우팅 대상이 아님
컨텍스트가 길어질수록 FFN이 아니라 어텐션과 KV cache가 병목을 잡음 → 크기 어림과 decode 대역폭 병목은 LLM 추론 서빙 정리에서 다룸

로컬은 가속기 대수가 아니라 한 대의 메모리 용량과 대역폭이 상한을 정하는 환경

고를 전문가를 미리 알 수 없어 쓰지 않을 가중치까지 메모리에 상주시켜야 함

활성 3B는 연산 쪽 이야기이지 메모리 쪽 이야기가 아님 → UD-Q4_K_M 기준 22.13GB 전부가 상주해야 함
토큰마다 전문가가 바뀌므로 필요할 때 디스크에서 꺼내 쓰는 구성은 스텝마다 저장장치를 때림 → 속도 이득이 사라짐
전문가 가중치만 시스템 RAM으로 내리는 오프로드는 실용적이고, llama.cpp의 --cpu-moe와 --n-cpu-moe가 이 용도
토큰당 오가는 것이 활성 전문가 몫뿐이라 Dense를 같은 방식으로 내렸을 때보다 성능 하락이 완만함 → VRAM이 부족한 환경에서는 오히려 MoE 쪽 실행 가능성이 높음
통합 메모리에는 CPU·GPU 메모리 구분이 없어 이 오프로드가 해당하지 않음

용량과 대역폭 중 어느 쪽이 먼저 바닥나는지가 선택을 가름