MoE는 어떻게 거대한 AI 모델을 가볍게 계산할까
💡 글의 핵심 3줄 요약
- MoE는 모든 파라미터를 매번 계산하지 않고, 라우터가 토큰마다 소수의 전문가만 골라 연산하는 희소 모델 구조입니다.
- 활성 파라미터가 적어도 전체 전문가 가중치는 메모리에 올려야 하므로, 낮은 FLOPs가 곧 낮은 VRAM 사용량을 뜻하지는 않습니다.
- 실제 도입에서는 모델 크기보다 라우팅 균형, 메모리 대역폭, GPU 간 통신량과 목표 동시 사용자 수를 함께 측정해야 합니다.
MoE는 어떻게 거대한 AI 모델을 가볍게 계산할까
거대한 언어 모델을 소개하는 표를 보다 보면 조금 이상한 표기를 만납니다. 전체 파라미터는 260억 개인데 토큰당 활성 파라미터는 40억 개라는 식입니다. “그렇다면 40억 모델처럼 가볍게 실행되는 것 아닐까요?”라는 질문이 자연스럽게 따라오죠. 답은 절반만 그렇습니다. 계산은 줄지만 저장해야 할 가중치와 데이터를 옮기는 비용은 여전히 남기 때문입니다.
이 차이를 만드는 구조가 Mixture of Experts, 줄여서 MoE입니다. 최근 공개 모델은 성능을 키우면서도 매 토큰의 계산량을 억제하기 위해 MoE를 적극적으로 사용합니다. Google의 Gemma 4 문서도 26B MoE 모델이 생성 시 토큰마다 4B 파라미터만 활성화하지만, 빠른 라우팅을 위해 전체 26B 파라미터를 메모리에 적재해야 한다고 안내합니다. 숫자 하나만 보고 하드웨어를 고르면 낭패를 보기 쉬운 이유입니다.
이번 글에서는 MoE의 수학을 길게 전개하기보다, 개발자가 모델 카드와 벤치마크를 읽을 때 꼭 구분해야 할 계산량, 메모리, 통신 비용을 차례로 살펴보겠습니다.
MoE 구조의 핵심은 토큰별 전문가 선택입니다
일반적인 Dense Transformer는 입력 토큰이 들어오면 각 층의 동일한 피드포워드 네트워크를 통과시킵니다. 반면 MoE 구조는 그 자리에 여러 개의 전문가 네트워크를 두고, 앞단의 라우터가 어떤 전문가에게 토큰을 보낼지 결정합니다. 회사의 대표 전화가 문의 내용을 듣고 담당 부서 두 곳만 연결해 주는 모습과 비슷합니다.
라우터와 Top-K 게이팅은 어떻게 움직일까요
라우터는 토큰의 은닉 상태를 받아 각 전문가에 대한 점수를 계산합니다. Top-2 방식이라면 점수가 높은 전문가 두 개만 선택하고, 두 결과를 가중 합산해 다음 층으로 보냅니다. 전문가가 64개여도 매 토큰은 그중 일부만 계산하므로 전체 모델 용량을 크게 늘리면서 활성 연산량을 제한할 수 있습니다.
여기서 “전문가”가 사람처럼 코딩, 법률, 번역을 명확히 하나씩 맡는다고 상상하면 곤란합니다. 실제로는 학습 과정에서 특정 토큰 패턴이나 표현에 더 자주 반응하는 피드포워드 블록에 가깝습니다. 어떤 전문성이 생겼는지는 데이터와 학습 방식에 따라 달라지며, 사람이 붙인 업무 이름과 일대일로 대응하지 않습니다.
라우팅에도 함정이 있습니다. 인기 있는 전문가 한두 개로 토큰이 몰리면 해당 장치만 바빠지고 나머지는 놀게 됩니다. 그래서 학습 단계에서는 보조 손실이나 용량 제한을 사용해 부하를 분산합니다. 추론 서버에서도 전문가별 토큰 수가 고르지 않으면 평균 연산량은 낮아도 꼬리 지연 시간이 길어질 수 있습니다.
MoE 메모리는 활성 파라미터만 계산해서는 안 됩니다
MoE를 검토할 때 가장 자주 생기는 오해는 활성 파라미터 수를 모델의 실제 크기로 받아들이는 것입니다. 토큰이 전문가 두 개만 방문하더라도 다음 토큰은 다른 전문가를 선택할 수 있습니다. 빠르게 응답하려면 후보 전문가의 가중치를 GPU 메모리나 가까운 계층에 준비해 둬야 합니다.
예를 들어 전체 26B 가중치를 4비트로만 저장해도 단순 계산상 약 13GB가 필요합니다. 여기에 양자화 메타데이터, 임베딩, KV 캐시, 실행 버퍼와 런타임 오버헤드가 더해집니다. 실제 요구량은 파일 크기보다 커집니다. “A4B”의 4B만 보고 4GB급 GPU를 선택해서는 안 되는 이유가 바로 여기에 있습니다.
VRAM 오프로딩은 공짜 메모리가 아닙니다
전문가 일부를 시스템 RAM이나 SSD로 내리면 작은 GPU에서도 모델을 열 수 있습니다. 하지만 토큰마다 필요한 가중치를 PCIe를 거쳐 가져오면 계산 장치가 데이터를 기다리게 됩니다. 모델이 실행된다는 것과 쾌적한 속도로 서비스된다는 것은 전혀 다른 문제입니다.
여러 GPU에 전문가를 나눠 담는 expert parallelism도 비슷합니다. 라우터가 선택한 전문가가 다른 GPU에 있으면 토큰을 네트워크로 보내고 결과를 다시 받아야 합니다. 이 all-to-all 통신은 GPU 계산량이 줄어든 이점을 삼킬 수 있습니다. 따라서 MoE 서버에서는 연산 성능뿐 아니라 GPU 간 연결 대역폭과 토폴로지가 중요합니다.
MoE 추론 성능은 네 가지 지표로 확인해야 합니다
첫째는 첫 토큰 지연 시간입니다. 모델 로딩과 프롬프트 처리, 전문가 준비 비용이 여기에 드러납니다. 둘째는 초당 생성 토큰 수입니다. 단일 요청뿐 아니라 실제 목표 동시성에서 측정해야 합니다. 셋째는 최대 VRAM과 호스트 RAM 사용량이며, 긴 컨텍스트에서 커지는 KV 캐시까지 포함해야 합니다. 넷째는 p95나 p99 지연 시간입니다. 라우팅 쏠림은 평균값보다 꼬리 구간에서 먼저 보입니다.
Dense 모델과 MoE 모델은 같은 조건에서 비교하세요
모델 카드의 활성 파라미터나 이론 FLOPs만 비교하지 말고 같은 정밀도, 같은 입력·출력 길이, 같은 배치 크기에서 측정해야 합니다. 짧은 프롬프트 한 개를 처리하는 로컬 챗봇이라면 작은 Dense 모델이 더 단순하고 빠를 수 있습니다. 반대로 충분한 메모리와 높은 동시 요청이 있는 서버에서는 MoE가 큰 모델 용량과 제한된 토큰당 연산량의 장점을 살릴 수 있습니다.
품질도 별도로 평가해야 합니다. MoE는 출력 형식 준수나 사실 정확성을 자동으로 보장하는 기술이 아닙니다. 라우팅은 계산 경로를 고를 뿐이며, 업무 데이터에 맞춘 평가 세트와 실패 분석은 여전히 필요합니다.
MoE 도입은 하드웨어 예산에서 거꾸로 시작하세요
먼저 사용할 GPU 수와 VRAM, 허용 가능한 RAM 오프로딩 범위를 정합니다. 다음으로 최대 컨텍스트와 동시 사용자 수를 넣어 KV 캐시 예산을 잡습니다. 그 안에 들어오는 후보 모델을 고른 뒤 실제 런타임으로 처리량과 꼬리 지연을 재면 됩니다. 모델 이름부터 고르고 장비를 맞추는 순서보다 시행착오가 훨씬 적습니다.
로컬 실험에서는 작은 샘플 요청으로 워밍업한 뒤, 실제 문서 길이와 예상 동시성을 재현하세요. 모니터링에는 GPU 사용률만 보지 말고 메모리 대역폭, 호스트와 장치 사이 전송량, GPU별 부하 편차를 포함하는 편이 좋습니다. 사용률이 낮은데 느리다면 연산보다 데이터 이동을 기다리고 있을 가능성이 큽니다.
결론: MoE의 가벼움은 조건부입니다
MoE는 거대한 모델을 무조건 작은 장비에서 돌리는 마법이 아닙니다. 더 정확히 말하면 전체 모델 용량을 키우면서 토큰마다 수행하는 계산을 선택적으로 줄이는 영리한 구조입니다. 계산비 절감이라는 장점과 전체 가중치 메모리, 라우팅 불균형, 장치 간 통신이라는 비용이 한 묶음으로 따라옵니다.
따라서 모델 카드에서 가장 큰 숫자와 가장 작은 숫자 중 어느 하나만 믿어서는 안 됩니다. 전체 파라미터는 저장과 메모리 계획에, 활성 파라미터는 대략적인 계산량에 참고하고, 최종 판단은 내 워크로드의 실측 지연과 처리량으로 내려야 합니다. 자동차의 엔진 출력만 보고 연비와 적재 공간까지 짐작할 수 없는 것과 같습니다.
MoE를 이해하면 최신 모델의 화려한 숫자를 훨씬 차분하게 읽을 수 있습니다. 다음 모델을 선택할 때는 “몇 B인가?”에 더해 “모든 전문가는 어디에 올라가며, 토큰은 어떤 경로로 이동하는가?”를 질문해 보세요. 그 질문이 데모와 운영 가능한 시스템을 가르는 출발점입니다.
참고 자료
이 글은 AI 도구의 도움을 받아 작성한 뒤 직접 검토·편집했습니다.