MoE vs Dense 차이: 활성 파라미터가 작아도 메모리가 필요한 이유

MoE의 전문가는 모델 안에 있는 계산 블록이에요. 학습된 라우터가 입력을 보고 사용할 블록을 고른 뒤, 선택된 블록의 결과로 계산을 이어가요. 사람이 ‘한국어 담당’이나 ‘코딩 담당’을 미리 지정한 작은 모델들의 모임으로 생각하기보다, 토큰마다 계산 경로를 고르는 구조로 이해하면 돼요.

Dense에서는 각 층의 가중치 대부분이 계산에 참여해요. MoE에서는 공유 부분과 선택된 전문가가 참여하고, 다음 토큰에는 다른 전문가가 선택될 수 있어요. 그래서 한 토큰에서 쓰지 않은 전문가도 이후 계산을 위해 실행 프로그램³이 접근할 수 있어야 해요.

B는 십억 개의 파라미터를 뜻해요. 전체 35B는 모델에 들어 있는 공유 부분과 전문가 가중치를 합친 규모예요. 활성 3B는 토큰 하나의 계산 경로에 참여하는 규모를 가리켜요. 다운로드와 메모리는 전체 숫자부터, 토큰당 계산은 활성 숫자부터 살펴보는 이유예요.

전부 4비트로 저장하는 단순한 예를 계산해볼게요. 350억×4비트÷8은 175억 바이트, 십진 단위로 17.5GB예요. 활성 3B만 계산하면 1.5GB지만, 전체 모델에는 나머지 전문가도 필요해요. 실제 Q4 파일에는 양자화⁴ 보조 값과 메타데이터, 다른 정밀도로 남긴 부분이 더해지므로 배포 파일의 실제 크기를 확인해야 해요.

전체 규모가 비슷한 Dense보다 MoE의 활성 규모가 작다면, 토큰마다 계산할 양을 줄일 수 있어요. 실행 프로그램이 선택된 전문가의 가중치를 효율적으로 가져와 계산하면 디코드⁵에서 이점이 생겨요. 모델 이름의 전체 B 숫자만으로 속도를 줄 세우기 어려운 이유예요.

실제로는 라우팅, 불규칙한 메모리 접근, 전문가별 부하와 실행 커널도 시간이 걸려요. 가중치 일부를 시스템 RAM⁶에 두는 오프로딩⁷을 사용하면 이동 시간까지 더해져요. 활성 규모가 작아서 얻은 이점을 살리려면 현재 장비의 메모리 배치와 해당 모델의 지원 경로를 함께 확인해야 해요.

예를 들어 빈 문자열에서 오류가 나는 함수를 수정해볼게요. 두 모델에 같은 코드와 오류 설명을 보내고 ‘반환 형식은 유지하고 빈 입력을 처리해줘’라고 요청해요. 일반 입력, 빈 입력, 기존 호출부를 확인하는 테스트를 실행하면 요청한 동작이 유지됐는지 알 수 있어요.

첫 답이 나올 때까지의 시간, 코드를 생성하는 속도, 테스트를 통과하기까지 추가로 수정한 횟수를 나눠 기록하세요. 답변이 빠른 모델이 여러 차례 수정해야 한다면 전체 작업은 길어질 수 있어요. 내 코드에서 필요한 결과를 얻는지와 기다리는 시간을 함께 비교하면 실제로 사용할 모델을 고르기 쉬워요.

원하는 Q4 파일을 배포 페이지에서 확인하고, 실행 프로그램과 다른 앱, KV 캐시⁸를 위한 메모리도 남겨요. 작은 질문으로 적재를 확인한 뒤 평소 사용하는 프로젝트 입력 길이로 시험하면, 실제 작업에서도 메모리가 남는지 알 수 있어요.

그 조건에서 코드 결과와 프리필⁹·디코드를 비교해요. 전체 파일이 안정적으로 들어가고 원하는 수정이 나오는 MoE라면 현재 장비에서도 좋은 후보가 돼요. 적재는 되지만 대기가 길다면 대역폭과 실행 옵션을, 적재부터 실패한다면 전체 용량과 오프로딩 지원을 다음으로 살펴보세요.