Dense가 여전히 옳은 선택일 때

2026년에도 MoE보다 Dense를 고를 이유

1. 로컬 추론

llama.cpp, Ollama, MLX를 비롯한 로컬 서빙 도구는 Dense 지원이 가장 성숙해. Q4_K_M, Q5_K_M, AWQ 같은 양자화도 Dense에서 예측하기 쉽지. 맥북 프로나 24GB 소비자용 GPU 한 장에서 돌리는 게 목표라면 Dense부터 보는 편이 좋아.

2. 미세 조정

LoRA, QLoRA, 전체 미세 조정은 Dense에서 다루기 쉽고 PEFT, Unsloth, Axolotl 생태계도 탄탄해. MoE도 미세 조정할 수 있지만 전문가 쏠림, 용량 한계, 균형 손실과 과제 손실의 충돌 같은 라우팅 문제가 따라와.

3. 예측 가능한 서빙 비용

Dense는 토큰마다 같은 양의 파라미터를 써. 그래서 토큰 수에 토큰당 비용을 곱하면 예산의 기본 모양이 나와. MoE는 배치 크기, 전문가별 부하 쏠림, 꼬리 지연 시간 때문에 용량 계획이 더 복잡해질 수 있어.

4. 약 30B보다 작은 규모

작은 모델에서는 라우터, 부하 균형, 전문가 병렬화에 드는 고정비가 MoE의 절감분을 먹어. 대체로 30B 아래에서는 Dense가 FLOP당 품질에서 강하고, 100B를 넘는 규모에서는 MoE의 장점이 커져. 그 사이가 설계 선택이 재미있어지는 구간이야.

5. 디버깅과 해석

어텐션 시각화, 활성 조향, 희소 오토인코더 분석 같은 해석 도구는 Dense 아키텍처를 기준으로 발전해 왔어. 연구나 정렬 작업을 하거나 “왜 이런 답을 냈지?”를 파고들어야 한다면 Dense 생태계가 더 편해.

둘은 시대가 아니라 용도가 달라

MoE는 감당할 만한 연산량으로 프런티어급 용량에 오르는 길이야. Dense는 그보다 작은 규모에서 서빙, 미세 조정, 디버깅, 로컬 실행을 편하게 만드는 길이고. 한쪽이 미래고 다른 쪽이 과거인 관계가 아니야. 서로 다른 일을 맡는 도구라서 둘 다 오래 남을 거야.

Code

빠른 결정: Dense인가 MoE인가?·python

def pick_backbone(scale_B, *, fine_tune=False, local=False):
    if scale_B < 30:
        return "dense"
    if local or fine_tune:
        return "dense (consider quantization for memory)"
    if scale_B >= 100:
        return "MoE (frontier capacity at manageable serving cost)"
    return "either — depends on your serving stack and ecosystem"

Exercise

최근에 만들거나 운영한 LLM 프로젝트를 하나 떠올려. Dense와 MoE 가운데 무엇을 고를지 명시적으로 판단했는지 돌아봐. 그렇지 않았다면 허용 가능한 지연 시간, 규모, 미세 조정 필요, 배포 환경을 적고 어느 백본이 더 잘 맞는지 한 단락으로 정리해.