작은 모델, 어디까지 왔나: 폐쇄망에서 쓸 small LLM 고르는 법
1B~32B 오픈웨이트 LLM의 현재 수준과 작업별 '쓸만한' 임계점, 그리고 모델 크기·양자화·하드웨어의 관계를 검증된 수치로 정리합니다.
"작은 모델은 못 쓴다"는 인식은 이미 깨졌습니다. 문제는 어떤 작업에 몇 B 모델을 어떤 하드웨어에 올릴지입니다. Gartner는 2027년까지 조직이 범용 LLM보다 소형·특화 모델을 약 3배 더 많이 쓸 것으로 전망합니다. 폐쇄망·온프레미스처럼 데이터가 밖으로 나가면 안 되는 환경이라면 이 선택이 곧 도입 가능 여부를 가릅니다.
이 글은 "최신 모델 소개"가 아니라, 자체 호스팅을 검토하는 사람을 위한 의사결정 도구를 목표로 합니다. 작업별 임계점 표 하나와, 검증 가능한 메모리 공식 하나면 대부분의 사이징 질문에 답할 수 있습니다.
수치 신뢰도에 대해: 아래 벤치마크와 메모리 수치는 가능한 한 1차 출처(HuggingFace 모델 카드, llama.cpp 공식 문서, arXiv)로 검증했습니다. 2026년에 등장한 일부 후속 모델(Gemma 4, Qwen3.5/3.6, Mistral Small 4 등)은 존재는 확인됐지만 벤치마크가 이미지로만 공개돼 수치 검증이 안 됐습니다. 그래서 본문 숫자는 검증이 끝난 Qwen3·Phi-4·Gemma 3·SmolLM3 세대를 기준으로 씁니다.
지금 어디까지 왔나
소형 모델의 절대 성능은 1~2년 전 중형 모델을 넘어섰습니다. 검증된 대표 점수만 추리면:
| 모델 | 크기 | 라이선스 | 대표 점수 |
|---|---|---|---|
| Phi-4 | 14.7B | MIT | MMLU 84.8 · MATH 80.4 · GPQA 56.1 |
| Phi-4-reasoning-plus | 14B | MIT | AIME'24 81.3 · GPQA-Diamond 68.9 · MMLU-Pro 76.0 |
| Phi-4-mini-instruct | 3.8B | MIT | GSM8K 88.6 · HumanEval 74.4 · MMLU 67.3 |
| Qwen3-32B | 32.8B | Apache 2.0 | AIME'24 79.5 · LiveCodeBench v5 62.7 · BFCL v3 66.4 |
| Qwen3-30B-A3B (MoE) | 30.5B/3.3B 활성 | Apache 2.0 | AIME'24 80.4 · BFCL v3 69.1 |
| Gemma-3-27B-IT | 27B | Gemma | MMLU-Pro 67.5 · MATH 69.0 · GPQA-Diamond 42.4 |
| SmolLM3-3B (추론) | 3B | Apache 2.0 | AIME'25 36.7 · GPQA-Diamond 41.7 |
요점은 3~4B급도 수학·코딩에서 의미 있는 점수를 내고, 14B면 한때 프런티어급이던 영역에 닿는다는 것입니다. 단, 점수 한 줄로 "쓸만하다"를 판단하면 안 됩니다. 작업마다 임계점이 다릅니다.
작업별 '쓸만한' 임계점
이 글에서 가장 중요한 표입니다. "최소 이 정도면 실무에서 쓸만하다"와 "이 아래로 가면 위험하다"를 작업별로 정리했습니다.
| 작업 | 쓸만한 최소 크기 | 품질 절벽 | 근거 |
|---|---|---|---|
| 분류·감성·라우팅 | 1B 미만 (파인튜닝 인코더 125M) | 크기보다 학습 데이터가 변수 | arXiv 2406.08660 |
| 요약 | 7~8B (정렬 잘된 4B 가능) | Vectara 환각 리더보드 | |
| RAG·근거 기반 QA | 7B (2~3B는 파인튜닝 필수) | 2~3B 미만 비추천 | Microsoft RAG 연구 |
| 함수호출(단일턴)·JSON | 7~8B | 멀티턴에서 급락 | Berkeley BFCL |
| 코딩 — 자동완성 | 7B | — | Qwen2.5-Coder 리포트 |
| 코딩 — 에이전트형(레포 단위) | 32B+ (그래도 프런티어 미만) | 14B 미만 | SWE-Dev |
| 멀티스텝 에이전트 | 신뢰할 임계점 없음 | 8B 이하 비신뢰 | MCP-Bench |
| 번역 | 9~12B (특화 모델 유리) | 7B 미만, 특히 저자원 언어 | Tower+ / Aya |
| 롱컨텍스트 | 실효 16~32K | 실효 길이 초과 | RULER |
이 표에서 끌어낼 실무 결론은 세 가지입니다.
1) 저부담 작업은 이미 7~8B에서 충분합니다. 분류·요약·단일턴 툴콜·RAG는 노트북이나 단일 GPU로 돌리는 7~8B 모델로 실무에 투입할 수 있습니다. 폐쇄망에서 "외부 API 없이도 된다"가 성립하는 영역입니다. 분류 같은 작업은 파인튜닝한 1B 미만 인코더가 제로샷 GPT-4를 이기기도 합니다.
2) 에이전트·레포 단위 코딩은 여전히 크기가 지배합니다. SWE-Dev 기준 7B는 약 23%, 32B는 약 37%로 두 배 가까이 벌어집니다. 8B 모델로 자율 멀티스텝 에이전트를 돌리려다 실패하는 게 흔한 함정입니다. 작은 모델은 좁은 스코프에 단단히 스캐폴딩해서 써야 합니다.
3) "128K 컨텍스트"를 액면 그대로 믿지 마세요. RULER 벤치마크 기준, 78B 모델의 실효 컨텍스트는 광고된 길이의 일부에 불과합니다. 예컨대 Mistral-7B는 32K를 표방하지만 실효는 약 16K이고, 128K 구간에서는 정확도가 급락합니다. "실효 1632K"를 설계 전제로 잡는 편이 안전합니다.
크기 × 양자화 × 하드웨어
자체 호스팅의 핵심 질문은 "내 하드웨어에서 뭐가 돌아가나"입니다. 답은 단순한 공식 하나에서 나옵니다.
필요 메모리 ≈ (파라미터 수 × 정밀도 바이트) + KV 캐시 + 오버헤드(10~20%)가중치만 본 표입니다. Q4_K_M는 llama.cpp 공식 기준 약 4.9 bit/weight(≈0.61 byte/param)로, 흔히 말하는 "INT4 = 0.5 byte"보다 약간 큽니다.
| 모델 | FP16 | Q8 | Q4_K_M (권장) | 현실적으로 돌아가는 곳 |
|---|---|---|---|---|
| 1~3B | 2~6GB | 1~3GB | 0.6~2GB | 노트북 CPU, 라즈베리파이 5 |
| 7~8B | ~15GB | ~8GB | ~4.6GB | 16GB 노트북·맥, 24GB GPU |
| 13~14B | ~27GB | ~14GB | ~8GB | 32GB RAM, 24GB GPU |
| 27~32B | ~60GB | ~32GB | 24GB GPU(Q4), 80GB 카드(FP16) |
검증된 사실(8.03B 모델 기준): Q4_K_M는 약 4.58GiB, Q8_0는 약 7.95GiB, F16는 약 14.96GiB입니다. 이 비율을 다른 크기에 그대로 확장하면 위 표가 됩니다.
양자화는 어디까지 줄여도 되나
arXiv 2601.14277(Llama-3.1-8B 양자화 통합 평가) 기준:
- Q4_K_M: 약 69% 압축에 MMLU 약 1점 손실. 사실상의 sweet spot.
- Q5/Q6: 코드·수학처럼 민감한 작업에는 한 단계 위로.
- Q3 이하: 품질 손실이 눈에 띄게 커짐 → 메모리가 정말 부족할 때만.
요약·분류는 Q4로 충분하지만, 코드 생성과 수학·추론은 양자화에 더 민감하다는 점을 기억하세요.
KV 캐시가 롱컨텍스트에서 가중치를 압도한다
가중치만 보면 안 됩니다. 컨텍스트가 길어지면 KV 캐시가 메모리를 잡아먹습니다.
KV 캐시 = 2 × 레이어 수 × KV 헤드 수 × head_dim × 토큰 수 × 정밀도 바이트Llama-3-8B(레이어 32, KV 헤드 8, head_dim 128, FP16) 기준 토큰당 약 128KB입니다. 즉:
- 8K 컨텍스트: 약 1.0GB
- 128K 컨텍스트: 약 16.8GB — 가중치(Q4 ~4.6GB)보다 큽니다.
그래서 최신 소형 모델이 채택한 **GQA(Grouped-Query Attention)**가 결정적입니다. KV 헤드를 줄여 캐시를 4배가량 절약합니다. KV 캐시 자체를 양자화(Q8/Q4 KV)하는 방법도 있습니다.
실측 처리량 감 잡기
| 환경 | 모델 | 처리량 |
|---|---|---|
| 라즈베리파이 5 | 3B Q4 | 2~7 tok/s |
| CPU 전용 서버 | 7B Q4 | 3~12 tok/s (메모리 대역폭 병목) |
| M4 Max (맥) | 7B Q4_0 | ~83 tok/s |
| RTX 4090 24GB | 8B Q4 |
맥의 통합 메모리는 전체 RAM을 VRAM처럼 쓸 수 있어 16GB면 7~8B, 128GB면 70B Q4까지 노려볼 수 있습니다. 단일 80GB 데이터센터 카드(A100/H100)는 32B FP16 또는 70B INT4까지 한 장에 올라갑니다.
추론 엔진 고르기
같은 모델도 엔진에 따라 적합한 시나리오가 다릅니다.
| 시나리오 | 추천 엔진 | 이유 |
|---|---|---|
| 노트북 개발 / 에어갭 단말 | llama.cpp, Ollama, LM Studio, llamafile | CPU+GPU 하이브리드, GGUF, 오프라인 기본 |
| 단일 GPU 개발·소규모 서빙 | Ollama, llama.cpp(llama-server), vLLM | OpenAI 호환 API, 가벼운 운영 |
| 멀티 GPU 프로덕션 서빙(처리량) | vLLM, SGLang | 연속 배칭, 텐서/파이프라인 병렬, paged KV |
폐쇄망·온프레미스 관점에서 짚어둘 점:
- llama.cpp 계열(Ollama·LM Studio·llamafile 포함)이 ARM64 지원 1급입니다. NEON·Apple Silicon Metal을 네이티브로 다룹니다. 단일 바이너리(
llamafile)는 에어갭 배포에 특히 강합니다. - vLLM도 0.11.2부터 Arm CPU 휠을 제공하며(Graviton3 테스트), GPU 서빙에서는 chunked prefill·continuous batching으로 prefill(연산 병목)과 decode(메모리 병목)를 분리 최적화합니다. prefill 레이턴시가 병목이라면 vLLM·SGLang의 이 기능이 직접적인 해법 후보입니다.
- TGI(Text Generation Inference)는 현재 유지보수 모드입니다. 신규 구축이라면 vLLM 또는 SGLang을 권합니다.
2026년의 큰 흐름: 효율 아키텍처와 데이터 주권
소형·효율 모델 흐름의 배경에는 두 가지 동력이 있습니다.
아키텍처 효율화. 대형 오픈웨이트 모델은 sparse attention으로 롱컨텍스트 비용을 떨어뜨리고 있습니다. DeepSeek의 DSA(Sparse Attention)가 V3.2(2025-12, MIT)에서 자리 잡았고, Z.ai의 GLM-5.2(2026-06, MIT, 약 753B/40B 활성, 1M 컨텍스트)가 DSA 기반 IndexShare로 1M 컨텍스트에서 토큰당 FLOPs를 줄였습니다. MiniMax M3는 자체 MSA(MiniMax Sparse Attention)로 1M 컨텍스트에서 토큰당 연산을 이전 세대의 약 1/20로 낮추고 prefill 9배 이상·decode 15배 이상 가속을 보고했습니다. 이들은 대형 모델이지만, sparse/linear attention 계열을 평가 후보에 넣어볼 가치가 분명합니다.
데이터 주권과 비용. 조직이 자체 호스팅을 택하는 이유는 명확합니다. ITAR·HIPAA·GDPR 같은 규제, 데이터 무유출(zero egress) 요건, 그리고 비용입니다. 오픈웨이트(특히 Apache 2.0/MIT) 가중치는 한 번 받아 망 안에서만 돌리면 되므로 데이터 잔류 문제를 근본적으로 해소합니다. Gartner는 2027년까지 엔터프라이즈 GenAI 모델의 절반 이상이 도메인 특화가 될 것으로 봅니다(2024년 약 1%).
도입 체크리스트
새 워크로드에 소형 모델을 올리기 전에 점검할 항목입니다.
- 작업 유형 확정 — 분류/요약/RAG/툴콜/코딩/에이전트 중 무엇인가 (임계점이 다름)
- 임계점 이상 크기 선택 — 위 표에서 작업별 최소 크기 충족
- 실효 컨텍스트 확인 — 광고된 길이가 아니라 실효 길이로 설계 (보통 16~32K)
- 양자화 결정 — 기본 Q4_K_M, 코드·수학은 Q5/Q6, Q3 이하는 회피
- 메모리 산정 — 가중치 + KV 캐시(컨텍스트 길이 반영) + 오버헤드
- 하드웨어 매칭 — 노트북/단일 GPU/데이터센터 카드 중 어디에 올릴지
- 추론 엔진 선택 — 에어갭/ARM64면 llama.cpp 계열, 프로덕션 서빙이면 vLLM/SGLang
- 라이선스 확인 — Apache 2.0/MIT는 안전, Llama/Gemma 라이선스는 조건 확인
작은 모델의 시대는 "크기"가 아니라 "작업에 맞는 크기"의 시대입니다. 워크로드를 정확히 정의하면, 폐쇄망 안에서 외부 API 없이 돌릴 수 있는 영역이 생각보다 넓습니다.
참고 출처
- 모델 카드·릴리스: Qwen3 Technical Report, Phi-4-mini, Gemma 3, SmolLM3
- 작업별 임계점: RULER (롱컨텍스트), Berkeley BFCL, Vectara 환각 리더보드
- 메모리·양자화: llama.cpp quantize, 양자화 품질 평가(arXiv 2601.14277)
- 효율 아키텍처: GLM-5.2, MiniMax M3, DeepSeek Sparse Attention
- 트렌드: Gartner: 소형 특화 모델 전망