Use case 를 paradigm 에 매핑
아래는 작동하는 지도. 절대 법은 아니야 — 근데 각 행이 specific 한 이유로 deviate 안 하면 default 여야 하는 강한 prior 반영.
| Use Case | Best paradigm | Why |
|---|---|---|
| 대화 chatbot | Dense (또는 MoE) standard | 예측 가능 cost, 빠른 응답, 대화에 충분 |
| 코딩 autocomplete | Small dense, standard | Latency-critical; reasoning 면 IDE freeze 처럼 느낌 |
| 코딩 디버깅 assistant | 어려운 거 reasoning, autocomplete dense | 어려운 디버깅 extended thinking 혜택; trivial completion 안 함 |
| Multi-step agent workflow | MoE 또는 small dense, standard | 많은 호출 × 호출당 latency = reasoning 으로 나쁨; cost 도 누적 |
| Long-context retrieval | Dense 또는 MoE, standard | Retrieval 이 빠른 패턴 매칭, deep reasoning 아님 |
| Local on-device inference | Small dense + quantization | 최고 ecosystem 지원, 예측 가능 메모리, 하드웨어 budget fit |
| Research/analysis (one-shot) | Reasoning | Multi-step 분석이 extended thinking 혜택 |
| Creative writing | Standard (어떤 backbone) | Reasoning 이 종종 creative output 더 mechanical, 더 좋게 안 함 |
| 수학 word problem / 증명 | Reasoning | Reasoning paradigm 이 가장 깨끗하게 빛나는 곳 |
| Cost-sensitive production API | MoE standard 또는 small dense | MoE 가 capability/FLOP, small dense 가 예측 가능성 |
| Frontier-capacity research | 어려우면 MoE + reasoning | 최대 capability, cost 받아들임 |
표 너머 reasoning
새 use case 마다 세 질문 물어:
- 많은 호출 chain (agentic) 인가, 단일 어려운 호출 (analytic) 인가? 많은 호출 → reasoning 피해. 단일 어려운 호출 → reasoning 고려.
- Bottleneck 이 latency, cost, quality? Latency → fast dense. Cost → small dense 또는 MoE. 어려운 문제의 Quality → reasoning.
- Local 또는 managed API? Locally → small dense. Managed → 어떤 거든.
Default
다른 거 쓸 specific 이유 articulate 못 하면: medium dense (Llama 3.3 70B class) standard inference mode, managed API. 2026 의 productive default.