Season 4 Ep 7 — 로컬 LLM은 "마이너"가 아니라 2025년 AI 스택의 절반이다. 외부 API가 못 하는 걸 해낼 때만 가치가 있다는 걸 먼저 이해하자.
- Prologue — "왜 로컬인가"라는 질문에 대한 2025년의 답
- 1장 · 언제 로컬인가
- 2장 · 모델 지형 2025
- 3장 · 양자화 — 메모리와 속도의 연금술
- 4장 · 서빙 엔진 — vLLM, TGI, SGLang, llama.cpp, Ollama
- 5장 · 하드웨어
- 6장 · 속도·지연 감각 (2025년 기준)
- 7장 · 비용·전력 계산
- 8장 · 프라이버시 중심 제품 설계
- 9장 · 한국어 로컬 LLM 실전
- 10장 · 실전 셋업 예 — 개인 개발자
- 11장 · 학습·Fine-tune (Ep 4 연결)
- 12장 · 안전·보안 고려
- 13장 · 안티패턴 10선
- 14장 · 체크리스트 — 로컬 LLM 배포 전 12가지
- 15장 · 다음 글 예고 — Season 4 Ep 8: "멀티모달 — Vision, Audio, 문서 이해"
Prologue — "왜 로컬인가"라는 질문에 대한 2025년의 답
2023년엔 로컬 LLM이 "가난한 자의 대안"이었다. 2024년엔 "프라이버시 오타쿠의 장난감". 2025년엔 제품의 정당한 선택지가 됐다.
이유:
- 모델 품질: 7B–14B 오픈 모델이 2022년 GPT-3.5를 아득히 넘어섬. 70B는 2024년 초 GPT-4 수준
- 하드웨어: 소비자 GPU(4090/5090)로 30B–70B QLoRA/Inference 가능. Apple M3/M4 Ultra로 100B+도 가능(느리게)
- 엔진: vLLM·TGI·SGLang으로 서빙 TPS가 수십 배 개선
- 양자화: INT4로 품질 손실 2–5% 수준, 메모리 4배 절감
- 규제·데이터주권: 금융·의료·공공·유럽 등 외부 API 금지 환경
하지만 모든 문제에 로컬이 답이 아니다. 이 글은 "언제 로컬이 말 되고, 언제 외부 API가 맞는지" 경계선도 같이 긋는다.
1장 · 언제 로컬인가
1.1 로컬이 말 되는 경우
- 데이터 외부 전송 금지 (규제·계약상)
- 극도의 저지연 요구 (100ms 미만, 동일 지역 내)
- 대량·반복적 요청 (월 수억, 외부 API 비용 압도)
- 특정 모델에 고도로 튜닝 (Fine-tune 어댑터를 우리만 소유)
- 네트워크 없는 환경 (엣지, 선박, 오프라인 디바이스)
1.2 외부 API가 맞는 경우
- 일반적 지능 필요, 태스크 다양
- 트래픽이 적거나 burst 많음
- 모델 품질이 최우선 (GPT-5 수준 요구)
- 팀이 인프라 운영에 투자할 여력 없음
- 빠르게 실험·피벗 중
1.3 하이브리드가 정답인 경우
많은 2025년 제품은 둘 다 쓴다.
- 일상 쿼리 90%는 작은 로컬 모델로 처리 → 비용·지연 최적
- 복잡 10%는 큰 외부 API로 에스컬레이션 → 품질 보장
- 민감 데이터 포함 요청은 반드시 로컬 경로
"라우터"가 로컬/외부를 결정한다. 이 라우터 자체는 작은 분류 모델(LoRA 파인튜닝)이 될 수 있다.
2장 · 모델 지형 2025
2.1 오픈 기반 모델(Base/Chat)
| 모델 | 크기 | 강점 | 라이선스 |
|---|---|---|---|
| Llama 3.1 / 3.2 / 3.3 | 1B–405B | 광범위, 생태계 최강 | Llama 라이선스 |
| Qwen 2.5 / Qwen 3 | 0.5B–72B | 다국어·코드·한국어 우수 | Apache 2.0 (일부) |
| Mistral / Mixtral / Ministral | 3B–8x22B | 효율적 아키텍처 | Apache / EU 상업 |
| Gemma 2 / 3 | 2B–27B | Google, 안전성 튜닝 강함 | Gemma 라이선스 |
| Phi 3 / 3.5 | 3.8B–14B | 작은데 상대적으로 강함 | MIT |
| DeepSeek V2.5 / V3 | 16B–671B MoE | 가성비 높음, 추론 강함 | DeepSeek 라이선스 |
| Yi / Yi-VL | 6B–34B | 멀티모달 포함 | Yi 라이선스 |
| Command R / R+ | 35B / 104B | RAG·툴 사용 특화 | Cohere 비상업 |
| Solar (Upstage) | 10.7B 등 | 한국어 특화 | Apache 2.0 |
| EXAONE (LG) | 7.8B 등 | 한국어 고품질 | 연구+일부 상업 |
2.2 선택 기준
- 한국어 우선: Solar, Qwen, EXAONE
- 영어·코딩: Qwen-Coder, DeepSeek-Coder, Llama
- 다국어 균형: Qwen, Llama 3.3
- 작고 빠르게: Phi 3.5 mini, Llama 3.2 3B, Qwen 2.5 3B
- RAG·툴 사용: Command R, Qwen
- 상업 자유도: Apache 계열(Qwen 일부, Solar)
2.3 코드·멀티모달 특화
- 코드: DeepSeek-Coder, Qwen2.5-Coder, CodeLlama, StarCoder2
- Vision: Qwen2-VL, Llama 3.2-Vision, Pixtral, Molmo, InternVL
- Audio: Whisper (STT), Bark/VITS/F5-TTS 등
3장 · 양자화 — 메모리와 속도의 연금술
3.1 왜 양자화
- 16-bit(bf16) 7B 모델: 14GB VRAM
- 8-bit: 7GB
- 4-bit: 3.5GB → 소비자 GPU에서 돌아간다!
3.2 주요 기법
- GPTQ: 4-bit, 품질 준수, 서버 배포 흔함
- AWQ: 4-bit, 활성값 기반, 많은 엔진 지원
- EXL2 / ExLlamaV2: 2–6 bit 유연, Consumer GPU 최적
- bitsandbytes (NF4): QLoRA 학습에 표준
- GGUF (llama.cpp): CPU·Metal·CUDA 모두 지원, Apple Silicon 생태계 표준
- SmoothQuant, SpinQuant: 활성값 분포 개선 기법
3.3 실전 선택
| 환경 | 추천 포맷 |
|---|---|
| vLLM/TGI 서버 | AWQ 또는 GPTQ 4-bit |
| llama.cpp/Ollama | Q4_K_M, Q5_K_M, Q6_K |
| Apple Silicon | GGUF (Metal 가속) |
| Consumer GPU 극한 | EXL2 4.0–6.0 bpw |
| Fine-tune 중 | bitsandbytes 4-bit |
3.4 품질 손실 상식
- 4-bit(Q4_K_M 등): 평균 2–5% 품질 손실 (태스크에 따라)
- 3-bit: 5–15% 손실. 리스크 있음
- 2-bit: 상당한 손실. 특수 목적만
- 한국어·코드·수학은 일반적으로 손실이 더 큼 → 최소 4-bit 권장
3.5 KV cache 양자화
- 생성 지연 대부분은 KV cache. FP8/INT8로 줄이면 배치 크기 ↑
- vLLM, SGLang에서 실험·프로덕션 지원
4장 · 서빙 엔진 — vLLM, TGI, SGLang, llama.cpp, Ollama
4.1 vLLM
- UC Berkeley 출신 오픈소스 서버
- PagedAttention으로 KV cache 효율 극대화
- 2025년 사실상 서버 표준
- LoRA 멀티 어댑터 핫스왑, 스펙큘레이티브 디코딩 지원
- Speculative decoding, chunked prefill 등 최신 기법 빠르게 흡수
4.2 TGI (Text Generation Inference)
- Hugging Face 공식
- 안정성·통합이 강점
- vLLM 대비 기능 추격 느린 편
4.3 SGLang
- 최근 주목받는 고성능 서버
- 복합 요청(여러 LLM 호출 조합)·라우팅 최적화 강점
- RadixAttention 등 특유의 최적화
4.4 llama.cpp
- C++ 기반, CPU·GPU(CUDA/Metal/ROCm) 모두 지원
- GGUF 포맷 생태계 중심
- Apple Silicon에서 Metal 가속으로 탁월
4.5 Ollama
- llama.cpp 래핑 + 사용성 대폭 개선
ollama run qwen2.5한 줄로 실행- 개인 개발자·프로토타이핑 최강의 UX
- OpenAI 호환 API 제공
4.6 LMDeploy (InternLM 쪽)
- TurboMind 엔진, 중국계 모델 친화
- TensorRT-LLM과 경쟁
4.7 TensorRT-LLM
- NVIDIA 공식, 극한 TPS
- 설정·튜닝 복잡도 큼, 프로덕션 대규모 서빙용
4.8 선택 가이드
| 상황 | 추천 |
|---|---|
| 프로토타입·개인 사용 | Ollama |
| 사내 서버, 쉽게 시작 | vLLM |
| 극한 성능·대규모 | TensorRT-LLM / SGLang |
| 복합 LLM 파이프라인 | SGLang |
| Apple Silicon | llama.cpp / Ollama / MLX |
| CPU-only 엣지 | llama.cpp |
5장 · 하드웨어
5.1 NVIDIA 소비자 GPU
| 카드 | VRAM | 적정 모델 (4-bit) | 메모 |
|---|---|---|---|
| RTX 4090 | 24GB | 13B 쾌적, 34B 가능 | 가성비 여전히 좋음 |
| RTX 5090 | 32GB | 34B 쾌적, 70B 가능 | Blackwell 세대 |
| RTX 6000 Ada | 48GB | 70B 쾌적 | 워크스테이션용 |
| RTX 5000/6000 (Blackwell) | 다양 | 프로 워크스테이션 | 2025 출시 |
5.2 데이터센터 GPU
- H100 80GB / H200 141GB: 70B–405B 서빙
- B100 / B200: H100 후속, 2025년 본격 전개
- GB200 (Grace Blackwell): 멀티 노드 학습·초대형 서빙
5.3 AMD·Intel
- MI300X: 192GB HBM, 70B 단일 GPU 가능 — ROCm 생태계 성숙 중
- Intel Gaudi 3: 학습/추론 경쟁자
- 일반 팀엔 아직 NVIDIA가 호환성 우위
5.4 Apple Silicon
- M3 Max / M4 Max (128GB): 70B 4-bit 추론 가능 (느리지만 실용적)
- M3 Ultra / M4 Ultra (192–256GB): 100B+ 모델도 가능
- 공유 메모리(UMA) 덕분에 VRAM 개념 없이 큰 모델 적재
- llama.cpp + MLX 기반 생태계 급성장
5.5 엣지·모바일
- iPhone 15/16 Pro (A17/A18): 3B–7B 모델 온디바이스 추론 (MLX)
- Snapdragon 8 Gen 3/4, 8 Elite: 3B–13B
- Jetson Orin / Thor: 로봇·차량용
5.6 실전 권장
- 개인 개발자: M3/M4 Max 64GB+ 또는 RTX 4090
- 팀(0–100 QPS): H100 1–2장 또는 L40S
- 중형 서비스: H100/H200 4–8장
- 대형: 전용 클러스터
6장 · 속도·지연 감각 (2025년 기준)
6.1 토큰/초 감각
| 세팅 | 단일 스트림 TPS |
|---|---|
| 7B Q4, RTX 4090 | 60–100 |
| 13B Q4, RTX 4090 | 30–50 |
| 70B Q4, 4090 x2 or H100 1 | 15–30 |
| 7B Q4, M3 Max 36GB | 30–60 |
| 70B Q4, M3 Ultra 192GB | 8–15 |
6.2 배치 시 처리량
- vLLM + H100 + 7B Q8: 동시 스트림 수십 개 처리, 합산 수천 TPS
- Paged KV cache + Continuous batching 덕분
6.3 TTFT (First Token)
- 짧은 프롬프트: 수십 ms
- 긴 프롬프트(4K–8K): 수백 ms (프리필 선형)
- 32K 이상: 수 초 가능 → 캐시 필요
6.4 벤치마크 팁
- 같은 모델이라도 양자화·엔진·드라이버로 TPS가 2–3배 차이
- 본인 프롬프트 분포로 직접 측정이 유일한 진실
7장 · 비용·전력 계산
7.1 자체 호스팅 고정비
- GPU 감가상각, 전력, 냉방, 네트워크
- H100 1장: 월 감가+전력 합산 1.2–2.5/h
7.2 외부 API 대비 손익분기
- 월 1–3천만 호출 이상, 단일 모델 집중 → 자체 유리
- 그 미만: 외부 API가 편하고 쌀 가능성 높음
7.3 전력
- H100: 약 700W, 24/7 운영 시 월 500 kWh
- 한국 산업용 전기 요금 기준 상당한 비용
- 그린 데이터센터 선택 시 탄소 보고에 유리
7.4 총소유비용(TCO) 항목
- 하드웨어 CapEx
- 전기·냉방·공간
- 인력(MLOps, SRE)
- 모델 업그레이드·재학습
- 장애 대응·가용성 구성
8장 · 프라이버시 중심 제품 설계
8.1 장점
- 사용자 데이터가 장비 밖으로 안 나감
- 규제 (GDPR, HIPAA, 개인정보보호법) 대응 쉬움
- 네트워크 끊겨도 작동
8.2 패턴 3가지
(a) On-prem 서버형
- 사내 서버에 로컬 LLM + RAG
- 엔터프라이즈 지식 챗봇, 문서 처리
(b) On-device (브라우저/모바일)
- WebGPU(Chrome/Edge) 기반: Transformers.js, web-llm
- 모바일: MLX(iOS), QNN(Android)
- 완전 오프라인·비용 0
(c) Hybrid
- 민감 부분만 로컬, 나머지는 API
- 라우터가 요청 내용·태그로 결정
8.3 UX 설계
- "이 요청은 로컬에서 처리됩니다" 표시로 신뢰 확보
- 응답 지연이 상대적으로 크면 스트리밍 UI 필수
9장 · 한국어 로컬 LLM 실전
9.1 후보
- Solar 10.7B (Upstage): 한국어 일반 대화·요약 강력
- Qwen2.5 7B/14B: 다국어 포함 한국어 상위권
- EXAONE 3.0/3.5 7.8B: LG 한국어 특화 오픈
- Llama 3.1 8B 한글 Fine-tune 버전: 커뮤니티 다수 공개
9.2 전처리·토크나이저
- Llama 3.x는 한국어 토큰 효율이 Solar·Qwen 대비 낮음(토큰 소비 많음)
- 토큰/초 감각이 한국어 우세 모델에서 체감 빠름
9.3 사내 문서 기반 RAG + 로컬
- pgvector + Solar 10.7B + vLLM → 월 수만 쿼리 충분
- 임베딩은 Upstage solar-embedding 또는 BGE-m3
- 인증·권한은 Postgres RLS
9.4 주요 사용 사례
- 법률·회계·공공 문서 처리 (외부 금지)
- 사내 슬랙 Q&A 봇
- 코드 어시스턴트(사내 코드 유출 방지)
- 개인 비서(개인 데이터 보호)
10장 · 실전 셋업 예 — 개인 개발자
10.1 M3/M4 Max MacBook 세팅
# Ollama 설치
curl -fsSL https://ollama.com/install.sh | sh
# 한국어·영어 모델
ollama pull qwen2.5:14b
ollama pull solar:10.7b
# OpenAI 호환 API 서버로 노출 (Ollama가 자동)
# http://localhost:11434/v1/chat/completions
10.2 RTX 4090 Linux 워크스테이션
# vLLM 설치
pip install vllm
# 서빙 (Qwen2.5 14B AWQ)
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
--gpu-memory-utilization 0.9 \
--max-model-len 8192
10.3 Docker/K8s 배포
- NVIDIA Container Toolkit + vllm/vllm-openai 이미지
- Helm 차트로 복제·오토스케일
- 모델 가중치는 S3/로컬 볼륨 → readiness probe에서 로드 확인
10.4 프론트엔드
- LibreChat, Open WebUI, Anythingllm, LobeChat 등 오픈 UI
- 또는 자체 Next.js/React에 스트리밍 SSE 붙임
11장 · 학습·Fine-tune (Ep 4 연결)
- 소비자 GPU로 QLoRA: 7B(12GB), 13B(16–20GB), 34B(24–32GB)
- 프레임워크: Axolotl, Unsloth, LLaMA-Factory, TRL
- 학습 후 GGUF/AWQ/GPTQ로 양자화해 배포
- 어댑터 핫스왑: vLLM
enable_lora로 여러 태스크 동시 서빙
12장 · 안전·보안 고려
12.1 On-prem도 사고 난다
- 모델 자체의 환각·편향은 여전
- 악성 프롬프트 인젝션도 그대로
- 로컬이라고 안전한 게 아님 — 거버넌스 동일 적용
12.2 체인 공급 위험
- Hugging Face 모델 무결성 확인 (서명, 파일 해시)
- 공식 발표 계정인지 확인(이름 유사 계정 사칭)
12.3 격리
- 모델 서버는 별도 서브넷, 최소 egress
- 사내 데이터만 RAG로 연결, 인터넷 접근 차단(on-prem 원칙일 때)
13장 · 안티패턴 10선
13.1 외부 API로 충분한데 로컬 강행
운영 비용·인력 낭비. 월 호출·보안 요구를 냉정히 계산.
13.2 2-bit 양자화 프로덕션
품질 리스크 큼. 최소 4-bit.
13.3 엔진 튜닝 없이 "느리다" 불평
--gpu-memory-utilization, batch 크기, max_model_len, prefix caching 등 미튜닝.
13.4 Apple Silicon에 vLLM 억지
Metal 지원 약함. llama.cpp/Ollama/MLX가 맞음.
13.5 양자화 품질 검증 없이 배포
4-bit도 태스크별로 편차 있음. 평가셋으로 회귀 체크.
13.6 동시 요청 처리 고려 없이 설계
단일 스트림만 빨라도 생산성 한계. 배치·파라렐 필수.
13.7 로컬 모델 업데이트 없음
오픈 모델도 월 단위로 좋아진다. 분기 1회 재평가.
13.8 보안 정책이 "외부 아님=안전"
격리·감사·접근제어 동일 요구.
13.9 라이선스 미확인
상업 배포 시 Llama, Gemma, Command R 조건 체크.
13.10 하드웨어 먼저 사고 소프트웨어 나중
요구 태스크·모델 정한 뒤 하드웨어 선택이 순서.
14장 · 체크리스트 — 로컬 LLM 배포 전 12가지
- 로컬이 정말 필요한 이유(규제·비용·지연)가 명문화
- 모델 후보 3개 이상 본인 평가셋으로 비교
- 양자화 포맷 결정 + 품질 회귀 측정
- 엔진 결정(vLLM/Ollama/llama.cpp)
- 하드웨어 TCO 계산 (외부 API 대비)
- 모니터링(TPS/TTFT/VRAM/에러/비용) 대시보드
- 배포 자동화(CI, 이미지 빌드, 모델 버전)
- 모델 가중치 무결성·출처 확인
- 보안 경계(서브넷·egress·감사)
- 장애 시 폴백(외부 API or 이전 모델)
- 사용자 데이터 보유·삭제 정책
- 분기 1회 모델 업그레이드 검토
15장 · 다음 글 예고 — Season 4 Ep 8: "멀티모달 — Vision, Audio, 문서 이해"
텍스트만 다루던 LLM이 이미지·오디오·동영상·문서를 자연스럽게 처리하기 시작한 2025년.
- Vision 모델: GPT-4o/Claude 3.5/Gemini/Qwen2-VL/Pixtral
- 문서 이해(Document AI): 텍스트+레이아웃+표+차트
- OCR의 현대화: 전통 파이프라인 vs VLM 직접 처리
- 실전 케이스: 영수증/계약서/의료기록/건축도면
- 비디오 이해: 프레임 샘플링 + 연속성
- 3D·로봇
- Audio: Whisper, STT 이후 TTS·음성 합성
- 한국어 문서 이해의 특수성(세로쓰기, 한자 혼용)
- 멀티모달 RAG
- 비용·지연·품질 트레이드오프
텍스트가 전부였던 시대의 종말. Ep 8에서 멀티모달 실전을 정리한다.
다음 글에서 만나자.
요약: 2025년의 로컬 LLM은 "장난감"이 아니라 제품의 정당한 선택지. 언제 로컬이 맞는지(규제·비용·지연·데이터 주권)를 먼저 정하고, 모델(Llama/Qwen/Solar/Mistral/EXAONE)·양자화(AWQ/GPTQ/EXL2/GGUF)·엔진(vLLM/Ollama/llama.cpp)·하드웨어(4090/5090/H100/Apple Silicon)를 팀 규모와 태스크에 맞게 조합한다. 하이브리드(로컬 90% + 외부 10%)가 많은 제품의 현실적 해답. "외부 API 없이 못 산다"는 시대는 끝났고, "로컬로 다 된다"는 시대도 아직 안 왔다.
현재 단락 (1/231)
2023년엔 로컬 LLM이 "가난한 자의 대안"이었다. 2024년엔 "프라이버시 오타쿠의 장난감". 2025년엔 **제품의 정당한 선택지**가 됐다.