C.W.K.
Stream
Lesson 01 of 04 · published

세 paradigm, 한 결정 표

~12 min · compare, decision, tradeoffs

Level 0Scout
0 XP0/41 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

모두 합치기

이제 세 lens — dense, MoE, reasoning — 와 네 축 — backbone, training, inference, product — 가져. 조합이 무한 아닌데 list 로 기억하기 너무 많아. 이 lesson 이 master 결정 표: production 에서 실제 중요한 각 차원에서 어떤 paradigm 이 이기나?

DimensionDenseMoEReasoning-oriented
토큰당 compute최고 (모든 param active)최저 (top-K expert 만)변동, thinking depth 의존
Memory footprint= total params= ALL params (≫ active)= base model + thinking 토큰 KV
Latency (요청당)예측 가능더 낮은 compute 지만 routing 오버헤드높고 변동 (5–20× standard)
Serving 복잡도단순 — standard tensor parallelism복잡 — expert parallelism, balancing중간 — 긴 sequence, budget 제어
Fine-tuning쉬움 (mature LoRA ecosystem)어려움 (routing 이 adaptation 복잡)매우 어려움 (RL pipeline, reward model)
Local 배포최고 (llama.cpp, Ollama)도전 (거대한 total memory)OK base 들면, 그냥 더 느림
토큰당 cost (API)Size 비례FLOP 당 더 낮음, 메모리 amortizationThinking 토큰 때문에 훨씬 높음
어려운 reasoning qualityScale 에서 좋음좋음 (training 의존)어려운 문제에 탁월
단순 Q&A quality탁월 (싸고 빠름)탁월 (싸고 빠름)낭비 — 단순 질문 overthink

내재화할 큰 패턴 둘

패턴 1. Dense 와 MoE 가 backbone 축에서 경쟁 (토큰당 cost vs 메모리당 cost). Reasoning 이 직교 — 어느 쪽 위에든 layer 가능. 그래서 "MoE vs reasoning" 이 malformed comparison; 진짜 비교는 "MoE vs dense" 와 "reasoning on vs off".

패턴 2. 위 표의 각 행이 실제 production 제약에 매핑. Bottleneck 이 메모리면 MoE 가 더 나쁘게; bottleneck 이 compute 면 MoE 도움; bottleneck 이 serving simplicity 면 dense 이김; bottleneck 이 hard-task 정확도면 reasoning 도움; bottleneck 이 latency 면 reasoning 해.

External links

Exercise

실제 실행하는 LLM-using 워크로드 (chatbot, agent, coding assistant, summarizer) 가져와. 위 표의 각 행에 대해 너의 bottleneck 이 어느 쪽인지 표시. 그다음 column 따라 읽어 — 너의 bottleneck 에 가장 많은 green 가진 paradigm 이 매치. 다른 거 쓰고 있었으면 useful signal.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.