2026년에 MoE 대신 dense 고를 다섯 강한 이유
1. Local inference
llama.cpp, Ollama, MLX, 그리고 대부분 local serving stack 이 여전히 dense-first. Quantization (Q4_K_M, Q5_K_M, AWQ) 는 dense 에서 mature, 많은 MoE 모델에서 immature 또는 quirky. Target 이 "MacBook Pro 에서 도는" 또는 "single 24GB consumer card 에서 도는" 이면 dense 가 거의 항상 정답.
2. Fine-tuning
LoRA, QLoRA, full fine-tuning 다 dense 에서 straightforward. PEFT, Unsloth, Axolotl 다 dense-first ecosystem. MoE fine-tuning 은 가능하지만 routing 관련 sharp edge (adaptation 중 expert collapse, capacity issue, balancing loss 가 task loss 와 간섭) 가득.
3. 예측 가능한 서빙 cost
Dense 는 토큰당 균일 cost 줘. Capacity planning 이 그냥 곱셈: token × per-token cost = budget. MoE 는 더 variable 한 서빙 행동 (batch-size 민감성, expert 부하 skew, longer tail latency) 으로 capacity planning 복잡해져.
4. ~30B 파라미터 미만
MoE 의 fixed cost (router 파라미터, load-balancing 로직, expert-parallelism 배관) 가 작은 scale 에서 효율 gain 먹어. ~30B-class total 미만에서 dense 가 일반적으로 quality-per-FLOP 에서 MoE 이김. ~100B-class 이상에서 MoE 가 앞서. 교차 영역이 흥미로운 design space.
5. Debuggability and interpretability
대부분 interpretability 도구 (attention 시각화, activation steering, sparse autoencoder analysis) 가 dense architecture 가정. Research, alignment 작업, "왜 모델이 그랬어?" 디버깅 어떤 종류든 한다면 dense ecosystem 이 훨씬 발전.
정직한 요약
MoE 는 frontier capacity 에 affordable 하게 오르는 길. Dense 는 frontier 미만에서 serveable, fine-tunable, debuggable, locally-runnable 모델 ship 하는 길. 경쟁자가 아니라 — 다른 일을 위한 도구. "MoE 가 미래, dense 가 과거" 다루는 게 실수. 5년 후에도 둘 다 여전히 중요할 거.