전문가 혼합 · MoE

전문가 혼합이란?

MoE가 실제로 바꾸는 것은 모델 덩치와 추론 비용이 한 몸으로 묶여 있던 관계입니다. 지금까지는 파라미터를 두 배로 키우면 토큰 하나를 처리하는 연산량도 대략 두 배가 됐습니다. MoE에서는 이 둘이 분리되기 때문에, 모델 스펙을 볼 때 총 파라미터와 활성 파라미터 두 숫자를 함께 확인해야 합니다. 답변 품질은 총량이 끌어올리고, 청구서에 찍히는 금액은 활성량이 결정합니다.

구조로 보면 트랜스포머 블록의 피드포워드 층을 전문가 여러 개로 쪼개고, 라우터가 토큰 단위로 상위 한두 개만 고르는 방식이 일반적입니다. 전문가가 64개인데 2개만 쓰면 활성 비율은 3% 남짓입니다. 여기서 앙상블과 헷갈리면 안 됩니다. 앙상블은 여러 모델을 전부 돌려 결과를 합치지만, MoE는 애초에 하나만 골라 돌리는 구조입니다. 또 하나, 전문가는 '법률 담당' '의료 담당'처럼 사람이 알아볼 분야로 나뉘지 않습니다. 학습 과정에서 저절로 갈라지므로 어느 전문가가 무엇을 맡을지 사람이 지정할 수 없고, 특정 전문가 쏠림을 막으려 별도의 균형 손실을 걸어 학습합니다.

도입 판단 기준은 의외로 단순합니다. API로 빌려 쓰는 회사라면 MoE 여부는 토큰 단가와 응답 속도로만 드러나므로 내부 구조를 따질 실익이 크지 않습니다. 반대로 모델을 직접 올려 운영할 계획이라면 이야기가 완전히 달라집니다. 같은 품질을 내는 밀집(dense) 모델과 비교하면 메모리는 더 쓰고 연산은 덜 쓰는 교환이어서, 장비를 고르는 기준 자체가 바뀌기 때문입니다.

현장에서 가장 많이 깨지는 지점이 바로 이 메모리입니다. '활성 파라미터가 130억이니 GPU 한 장이면 되겠다'고 계산하고 자체 구축에 들어갔다가, 총 파라미터 전부를 메모리에 올려 둬야 한다는 벽에 부딪혀 장비 견적이 몇 배로 뛰는 일이 흔합니다. MoE가 줄여 주는 것은 연산량이지 메모리가 아니라는 점을 놓친 탓입니다. 동시 요청이 몰릴 때도 마찬가지입니다. 배치에 담긴 토큰들이 제각각 다른 전문가를 부르면 결국 대부분의 전문가가 깨어나, 기대했던 절감분은 트래픽이 몰리는 시간대에 가장 먼저 사라집니다.