메모리와 모델
35B MoE가 더 작은 밀집 모델보다 빠를 수 있는 이유
모델 이름의 숫자가 커지면 더 느릴 것 같습니다. 그런데 35B 모델이 27B 모델보다 빠르게 답하는 경우가 있습니다. 큰 숫자를 잘못 읽은 걸까요? 사실 두 숫자는 저장할 모델의 크기를 말할 뿐, 토큰 하나를 만들 때 모두 같은 양을 계산한다는 뜻은 아닙니다.
우선 두 모델의 일을 같게 맞춥니다
35B와 27B의 속도만 놓고 비교하기 전에 질문과 답변 길이, 양자화와 실행 프로그램을 맞춰야 합니다. 서로 다른 작업에서 나온 숫자라면 구조 차이를 보기 어렵습니다. 여기서는 같은 장비에서 같은 종류의 요청을 보낸 상황을 생각해보겠습니다.
밀집형인 Dense 모델은 새 토큰을 만들 때 대부분의 가중치를 사용합니다. 모델이 커질수록 읽어야 할 가중치도 늘어나는 경향이 있습니다. 그래서 더 큰 Dense 모델이 느릴 것이라는 예상은 출발점으로 이해할 만합니다.
MoE는 전체를 보관하고 일부를 선택합니다
MoE에는 여러 전문가 블록이 있습니다. 각 토큰에서 라우터가 일부를 선택해 계산합니다. 모든 전문가가 매번 함께 일하는 구조는 아니므로, 전체 파라미터가 커도 한 토큰에서 사용하는 부분은 작을 수 있습니다.
예를 들어 전체 35B에 활성 약 3B라고 표시된 모델은 보관할 규모와 토큰당 계산 규모를 따로 읽어야 합니다. 이 숫자는 설명을 위한 구조 예이지 3B 밀집 모델과 같은 속도나 품질을 약속하는 식은 아닙니다. 공유 층과 라우팅 비용도 남아 있습니다.
계산이 줄면 왜 답변이 빨라질까요?
한 사람이 답변을 받을 때는 GPU의 계산 능력만큼 메모리에서 가중치를 가져오는 속도가 중요할 수 있습니다. 선택된 가중치만 읽고 계산하는 경로가 효율적이라면, 더 작은 Dense 모델보다 적은 일을 하며 다음 토큰을 만들 수 있습니다.
하지만 실행 프로그램의 MoE 처리가 비효율적이면 이 이점을 충분히 얻지 못합니다. 전문가를 고르고 흩어진 메모리에 접근하는 비용도 있습니다. 모델 구조를 알면 빠를 가능성은 설명할 수 있지만, 실제 tok/s까지 구조만으로 확정할 수는 없습니다.
빠른 모델이 작은 메모리에 들어가는 것은 아닙니다
여기서 가장 아쉬운 오해가 생깁니다. 활성 부분만 보고 작은 GPU를 샀는데 모델 파일이 들어가지 않는 경우입니다. 다음 토큰이 어떤 전문가를 선택할지 모르므로 전체 가중치는 접근 가능한 메모리나 저장장치에 있어야 합니다.
일부를 RAM이나 SSD에 두는 경로가 있더라도 필요한 부분을 가져오는 지연이 생깁니다. 계산량을 줄여 얻은 이득보다 전송 시간이 커질 수도 있습니다. 모델을 올릴 수 있다는 확인을 먼저 하고, 그 안에서 속도를 비교해야 합니다.
더 큰 모델을 쓸 이유도 작업에서 찾습니다
MoE가 빠르다고 해서 답변의 정확도까지 자동으로 앞서는 것은 아닙니다. 내가 시킨 코드 수정이나 문서 요약에서 어느 모델의 결과가 더 쓸 만한지 확인해야 합니다. 잘못된 답을 빠르게 받으면 검토 시간은 오히려 늘 수 있습니다.
35B라는 숫자에 부담을 느꼈다면 실제 파일 크기와 활성 규모를 나누어 보세요. 반대로 활성 3B만 보고 가볍다고 생각했다면 전체 적재량을 다시 보세요. 이름이 주는 인상 대신 메모리·속도·작업 결과 세 가지가 맞는 모델을 남기는 것이 목적입니다.