로컬 LLM 시대 완전 가이드: Llama, Qwen, Mistral, vLLM, 양자화, Apple Silicon (2025)

Season 4 Ep 7 — 로컬 LLM은 "마이너"가 아니라 2025년 AI 스택의 절반이다. 외부 API가 못 하는 걸 해낼 때만 가치가 있다는 걸 먼저 이해하자.

• Prologue — "왜 로컬인가"라는 질문에 대한 2025년의 답
• 1장 · 언제 로컬인가
  • 1.1 로컬이 말 되는 경우
  • 1.2 외부 API가 맞는 경우
  • 1.3 하이브리드가 정답인 경우
• 2장 · 모델 지형 2025
  • 2.1 오픈 기반 모델(Base/Chat)
  • 2.2 선택 기준
  • 2.3 코드·멀티모달 특화
• 3장 · 양자화 — 메모리와 속도의 연금술
  • 3.1 왜 양자화
  • 3.2 주요 기법
  • 3.3 실전 선택
  • 3.4 품질 손실 상식
  • 3.5 KV cache 양자화
• 4장 · 서빙 엔진 — vLLM, TGI, SGLang, llama.cpp, Ollama
  • 4.1 vLLM
  • 4.2 TGI (Text Generation Inference)
  • 4.3 SGLang
  • 4.4 llama.cpp
  • 4.5 Ollama
  • 4.6 LMDeploy (InternLM 쪽)
  • 4.7 TensorRT-LLM
  • 4.8 선택 가이드
• 5장 · 하드웨어
  • 5.1 NVIDIA 소비자 GPU
  • 5.2 데이터센터 GPU
  • 5.3 AMD·Intel
  • 5.4 Apple Silicon
  • 5.5 엣지·모바일
  • 5.6 실전 권장
• 6장 · 속도·지연 감각 (2025년 기준)
  • 6.1 토큰/초 감각
  • 6.2 배치 시 처리량
  • 6.3 TTFT (First Token)
  • 6.4 벤치마크 팁
• 7장 · 비용·전력 계산
  • 7.1 자체 호스팅 고정비
  • 7.2 외부 API 대비 손익분기
  • 7.3 전력
  • 7.4 총소유비용(TCO) 항목
• 8장 · 프라이버시 중심 제품 설계
  • 8.1 장점
  • 8.2 패턴 3가지
  • 8.3 UX 설계
• 9장 · 한국어 로컬 LLM 실전
  • 9.1 후보
  • 9.2 전처리·토크나이저
  • 9.3 사내 문서 기반 RAG + 로컬
  • 9.4 주요 사용 사례
• 10장 · 실전 셋업 예 — 개인 개발자
  • 10.1 M3/M4 Max MacBook 세팅
  • 10.2 RTX 4090 Linux 워크스테이션
  • 10.3 Docker/K8s 배포
  • 10.4 프론트엔드
• 11장 · 학습·Fine-tune (Ep 4 연결)
• 12장 · 안전·보안 고려
  • 12.1 On-prem도 사고 난다
  • 12.2 체인 공급 위험
  • 12.3 격리
• 13장 · 안티패턴 10선
  • 13.1 외부 API로 충분한데 로컬 강행
  • 13.2 2-bit 양자화 프로덕션
  • 13.3 엔진 튜닝 없이 "느리다" 불평
  • 13.4 Apple Silicon에 vLLM 억지
  • 13.5 양자화 품질 검증 없이 배포
  • 13.6 동시 요청 처리 고려 없이 설계
  • 13.7 로컬 모델 업데이트 없음
  • 13.8 보안 정책이 "외부 아님=안전"
  • 13.9 라이선스 미확인
  • 13.10 하드웨어 먼저 사고 소프트웨어 나중
• 14장 · 체크리스트 — 로컬 LLM 배포 전 12가지
• 15장 · 다음 글 예고 — Season 4 Ep 8: "멀티모달 — Vision, Audio, 문서 이해"

Prologue — "왜 로컬인가"라는 질문에 대한 2025년의 답

2023년엔 로컬 LLM이 "가난한 자의 대안"이었다. 2024년엔 "프라이버시 오타쿠의 장난감". 2025년엔 제품의 정당한 선택지가 됐다.

이유:

1. 모델 품질: 7B–14B 오픈 모델이 2022년 GPT-3.5를 아득히 넘어섬. 70B는 2024년 초 GPT-4 수준
2. 하드웨어: 소비자 GPU(4090/5090)로 30B–70B QLoRA/Inference 가능. Apple M3/M4 Ultra로 100B+도 가능(느리게)
3. 엔진: vLLM·TGI·SGLang으로 서빙 TPS가 수십 배 개선
4. 양자화: INT4로 품질 손실 2–5% 수준, 메모리 4배 절감
5. 규제·데이터주권: 금융·의료·공공·유럽 등 외부 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)

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 실전 선택

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 선택 가이드

5장 · 하드웨어

5.1 NVIDIA 소비자 GPU

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 토큰/초 감각

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장: 월 감가+전력 합산 $800–2000 (자체 소유) / 클라우드 스팟$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 없이 못 산다"는 시대는 끝났고, "로컬로 다 된다"는 시대도 아직 안 왔다.