로컬 LLM 실전 배포 가이드: 클라우드 없이 내 하드웨어에서 AI 돌리기
로컬 LLM 실전 배포 가이드: 클라우드 없이 내 하드웨어에서 AI 돌리기
GPT-4o API 호출 한 번에 몇 원이 나가는지 계산해 본 적 있는가? 하루에 수천 번 호출하는 서비스라면 월간 API 비용만 수십만 원에서 수백만 원까지 가볍게 넘어간다. 그리고 데이터가 OpenAI 서버를 거친다는 건, 의료 기록이나 법무 문서 같은 민감 정보를 다루는 팀에는 선택지가 아니다.
2026년, 로컬 LLM 추론은 취미용 실험을 넘어 실제 프로덕션 선택지가 됐다. 이 글에서는 어떤 하드웨어가 필요한지, 양자화(quantization)가 뭘 줄이고 뭘 잃는지, Ollama로 5분 안에 모델을 띄우는 법부터 프로덕션급 서빙까지, 숫자와 코드로 구체적으로 정리한다.
왜 2026년에 로컬 LLM인가
세 가지 실제 이유가 있다.
비용 교차점. 자체 하드웨어를 소유한 상태에서 월 약 5천만 토큰 이상을 처리할 때, 로컬 배포가 API 단가를 역전한다. 그 이하면 클라우드 추론이 더 싸다. 단순히 “멋있어서” 로컬을 고르면 투자 대비 효율이 떨어진다.
데이터 주권. 금융권, 의료, 법무 등 규제 산업에서는 데이터가 외부 서버를 거치는 것 자체가 컴플라이언스 위반이다. 이 경우 비용과 무관하게 로컬 배포가 필수다.
오프라인·엣지 환경. 인터넷 연결이 불안정하거나 불가능한 환경(선박, 공장, 군사 시설)에서는 로컬이 유일한 선택지다. 레이턴시도 클라우드 왕복 시간(수십~수백 ms) 없이 sub-50ms로 떨어뜨릴 수 있다.
핵심은 이것이다: 로컬 LLM을 “멋있으니까” 쓰지 마라. 데이터 주권 요구사항이 있거나, 초대용량 반복 작업이 있거나, 오프라인 환경이거나, 이 셋 중 하나가 있을 때 선택하라.
하드웨어 선택: 메모리 대역폭이 전부다
LLM 추론의 병목은 연산량(FLOPS)이 아니라 메모리 대역폭이다. 토큰 하나를 생성할 때마다 전체 모델 파라미터를 메모리에서 읽어야 하기 때문이다. 따라서 “GPU가 빠르다”보다 “메모리가 빠르고 크다”가 핵심 기준이다.
주요 하드웨어의 실제 벤치마크를 보자. Q4_K_M 양자화 기준, llama.cpp로 측정한 토큰 생성 속도다.
| GPU/칩 | VRAM/메모리 | 대역폭 | 7B 모델 | 70B 모델 |
|---|---|---|---|---|
| NVIDIA RTX 4090 | 24 GB | 1,008 GB/s | ~135 tok/s | 18 tok/s (Q2_K) |
| NVIDIA RTX 3090 | 24 GB | 936 GB/s | ~95 tok/s | 10 tok/s (Q2_K) |
| Apple M4 Pro Mac Mini | 48 GB | 273 GB/s | ~45 tok/s | 5 tok/s |
| Apple M3 Max | 64 GB | 400 GB/s | ~40 tok/s | 5 tok/s |
| NVIDIA RTX 4060 Ti | 16 GB | 288 GB/s | ~55 tok/s | OOM |
| CPU only (DDR5) | 32 GB | ~80 GB/s | 6-10 tok/s | <1 tok/s |
참고: 40 tok/s 이상이면 체감상 즉각적이다(읽는 속도보다 빠름). 20-40 tok/s는 쾌적. 10-20 tok/s는 쓸 만함. 10 tok/s 미만은 대화형으로는 고통스럽고 배치 처리용이다.
실전 추천:
- 예산 200만 원대: 중고 RTX 3090 24GB. 7B~13B 모델을 쾌적하게 돌린다. 70B는 Q2_K 양자화로 겨우 돌아가지만 품질 손실이 크다.
- 예산 400만 원대: Mac Mini M4 Pro 48GB. 14B 모델까지 쾌적, 70B 모델도 로딩 가능하다. 전력 소모가 GPU 서버의 10분의 1 수준이다.
- 예산 700만 원 이상: RTX 4090 또는 Mac Studio M3 Ultra(최대 512GB 통합 메모리, ~819 GB/s 대역폭). 70B 모델을 실전급 속도로 돌릴 수 있다.
양자화: 품질과 속도의 트레이드오프
원래 모델은 16비트 부동소수점(FP16)으로 저장된다. 7B 모델이면 14GB, 70B 모델이면 140GB가 필요하다. 현실적인 하드웨어에서 돌리려면 양자화(quantization)로 모델 크기를 줄여야 한다.
GGUF 포맷의 주요 양자화 등급을 정리한다.
| 등급 | 7B 모델 크기 | 70B 모델 크기 | 품질 손실 | 추천 용도 |
|---|---|---|---|---|
| F16 (원본) | ~14 GB | ~140 GB | 없음 | 연구/정밀 작업 |
| Q8_0 | ~7.7 GB | ~77 GB | 거의 없음 | VRAM 여유가 충분할 때 |
| Q5_K_M | ~5.3 GB | ~53 GB | 미미 | 정밀도가 중요한 작업 |
| Q4_K_M | ~4.4 GB | ~44 GB | 약간 | 대부분의 실전 용도 |
| Q2_K | ~2.8 GB | ~28 GB | 상당함 | VRAM이 모자랄 때的最后 수단 |
핵심 인사이트: Q4_K_M이 대부분의 사용자에게 최적의 균형점이다. 품질 손실은 인지하기 어려울 정도지만, 모델 크기는 FP16 대비 약 70% 감소한다. VRAM이 충분하다면 Q5_K_M 또는 Q8_0으로 올리면 좋지만, 체감 차이는 미미하다.
주의할 점: Q2_K는 모델이 돌아가긴 하지만, 복잡한 추론이나 코드 생성에서 품질 저하가 뚜렷하게 나타난다. 24GB GPU에서 70B를 돌리려다 Q2_K를 쓰느니, 차라리 13B를 Q4_K_M으로 돌리는 게 낫다.
5분 안에 시작하기: Ollama 실전 세팅
Ollama는 현재 로컬 LLM 실행의 사실상 표준이다. 설치부터 모델 실행까지 터미널 명령 몇 개면 끝난다.
설치 (macOS / Linux):
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh
# 설치 확인
ollama --version
모델 실행:
# 7B 모델 (대부분의 랩탑에서 동작)
ollama run qwen2.5:7b
# 14B 모델 (16GB+ VRAM 권장)
ollama run qwen2.5:14b
# 72B 모델 (48GB+ 메모리 필요)
ollama run qwen2.5:72b
첫 실행 시 자동으로 모델을 다운로드한다. Q4_K_M 양자화 버전이 기본으로 내려받아진다.
Apple Silicon에서 MLX 백엔드 활성화 (2026년 3월 추가):
Ollama 0.19부터 Apple Silicon에서 MLX 백엔드를 사용할 수 있다. 기존 Metal 백엔드 대비 약 2배 빠른 추론 속도를 보여준다.
# MLX 백엔드 활성화
OLLAMA_MLX=1 ollama serve
# 확인: 실행 시 로그에 "using MLX"가 표시되는지 확인
# Mac Studio M2 Ultra 64GB에서 Q4_K_M 기준
# Metal: ~22 tok/s (7B) → MLX: ~40+ tok/s (7B) 로 향상 보고됨
API 서버로 사용하기
Ollama는 실행 시 자동으로 로컬 API 서버를 시작한다. OpenAI 호환 엔드포인트를 제공하므로 기존 코드를 최소한으로 수정해서 연동할 수 있다.
# Ollama 서버 시작 (백그라운드)
ollama serve &
# API 호출 테스트
curl http://localhost:11434/api/chat -d '{
"model": "qwen2.5:7b",
"messages": [
{"role": "user", "content": "Python으로 피보나치 수열을 작성해줘"}
],
"stream": false
}'
Python에서 OpenAI SDK로 연동:
from openai import OpenAI
# Ollama 서버를 가리키도록 base_url 변경
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama" # Ollama는 API key가 필요 없지만 필드는 채워야 함
)
response = client.chat.completions.create(
model="qwen2.5:7b",
messages=[
{"role": "system", "content": "한국어로 답변해."},
{"role": "user", "content": "RAG 파이프라인의 기본 구조를 설명해줘"}
],
temperature=0.7,
max_tokens=1000
)
print(response.choices[0].message.content)
이 코드는 OpenAI API를 호출하던 기존 애플리케이션에서 base_url과 api_key만 바꾸면 로컬 모델로 전환된다는 걸 보여준다. 프롬프트 엔지니어링이나 함수 호출 스키마도 그대로 동작한다.
프로덕션 배포 시 고려사항
로컬 LLM을 실제 서비스에 적용할 때 겪게 되는 현실적인 문제들이다.
1. 모델 선택 계층
2026년 3월 기준, 용도별 추천 모델 계층이 정리되어 있다.
- 70B 급 (범용 고성능): Llama 3.3 70B, Qwen2.5 72B. GPT-4o의 약 85% 수준 품질. 2× A100 80GB 또는 Mac Studio M4 Ultra급 필요.
- 32B 급 (코드 특화): Qwen2.5-Coder 32B. 코딩 벤치마크에서 구형 GPT-4를 역전. 2× RTX 4090이면 충분.
- 7B~14B 급 (엣지/저지연): Mistral 7B, Qwen2.5 14B. 분류, 요약, 라우팅에 적합. 단일 소비자 GPU로 동작.
- 3.8B 급 (초경량): Phi-4 Mini. 문서 분류, 구조화된 추출. 랩탑 GPU에서 동작.
2. 로드밸런싱과 배치
단일 GPU에서 동시 요청이 몰리면 처리량이 급감한다. 프로덕션에서는 vLLM이나 LocalAI 같은 서빙 프레임워크를 사용해 continuous batching을 활성화해야 한다.
# vLLM으로 Qwen2.5 7B 서빙 (CUDA GPU 필요)
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--quantization awq \
--max-model-len 4096 \
--gpu-memory-utilization 0.9 \
--port 8000
vLLM은 continuous batching과 PagedAttention을 통해 GPU 메모리를 효율적으로 관리하며, 단순 Ollama 서빙보다 동시 요청 처리량이 3~5배 높다.
3. 비용 현실 점검
하드웨어 구매 비용 외에도 전력과 유지보수 비용이 있다. RTX 4090 서버를 24시간 가동하면 월 전기료만 10~15만 원 가량 발생한다. 반면 Mac Mini M4 Pro는 전력 소모가 30W 수준이라 월 2~3만 원이다. 자체 하드웨어 기준 월 5천만 토큰 이상 처리할 때 API 비용을 역전한다는 점을 다시 강조한다.
실전: 언제 로컬을 쓰고 언제 클라우드를 쓸까
간단한 의사결정 흐름이다.
- 민감 데이터를 다루는가? → 로컬. 선택지가 없다.
- 오프라인 환경인가? → 로컬. 당연하다.
- 월 5천만 토큰 이상인가? → 자체 하드웨어 보유 시 로컬이 더 싸다.
- 위 중 해당사항이 없다면? → 클라우드 API가 더 간단하고 싸다.
혼합 전략도 유효하다. 민감한 데이터 전처리와 분류는 로컬 7B 모델로 처리하고, 복잡한 생성 작업은 클라우드 API로 넘기는 식이다. 앞서 보여준 OpenAI SDK 코드에서 base_url만 조건부로 바꾸면 된다.
핵심 요약
- 로컬 LLM은 데이터 주권, 초대용량 반복 작업, 오프라인 환경에 진정한 가치가 있다. 비용 절감만으로 접근하면 투자 대비 효율이 떨어질 수 있다.
- 하드웨어 선택에서 메모리 대역폭이 핵심이다. FLOPS가 아니라 GB/s를 먼저 보라.
- Q4_K_M 양자화가 대부분의 실전 용도에서 최적의 균형점이다.
- Ollama로 5분 안에 로컬 LLM을 실행할 수 있고, OpenAI 호환 API를 제공하므로 기존 코드 전환이 쉽다.
- 프로덕션급 동시 처리에는 vLLM의 continuous batching이 필요하다.
- 혼합 전략(로컬 + 클라우드)이 대부분의 팀에 현실적인 최적해다.
당장 시도해볼 첫 걸음: brew install ollama && ollama run qwen2.5:7b를 실행해 보라. 5분 안에 여러분의 기기에서 AI가 돌아가는 걸 확인할 수 있다.