Ollama·LM Studio ― 로컬에서 LLM 돌리는 기술 스택

“API를 호출하는 것”과 “모델을 돌리는 것”은 완전히 다른 문제입니다.

API를 부를 때 당신은 토큰당 과금, 레이턴시, 하이퍼파라미터만 생각하면 됩니다. 모델 자체는 “저 어딘가의 H100 위에서 누군가가 잘 돌리고 있겠지” 상태예요.

그런데 같은 모델을 자기 맥북이나 RTX 3090에서 돌리는 순간, 관점이 바뀝니다.

• GGUF가 뭔지
• Q4_K_M이 왜 스윗스팟이라는지
• 컨텍스트 늘리면 왜 VRAM이 터지는지
• 추론 엔진마다 속도가 왜 다른지

이런 것들을 안 보고 넘어갈 수가 없어요. 로컬 LLM은 모델이 아니라 스택이거든요.

이 글은 “5분이면 Ollama 설치 끝”류의 튜토리얼이 아닙니다. 설치는 README 한 번 읽으면 끝납니다. 대신 왜 그렇게 동작하는지, 그리고 어떤 선택지가 있는지를 엔지니어 눈높이로 봅니다.

순서:

1. Ollama vs LM Studio — 핵심 비교
2. GGUF 양자화 메커니즘 — 비트 vs 품질
3. 2026 인기 모델 메모리 요구치
4. KV cache 함정 — 컨텍스트 늘리면 VRAM 폭증
5. OpenAI 호환 API의 의미
6. 기타 런타임 6종 (llama.cpp · vLLM · mlx-lm · koboldcpp · TGI · LocalAI)
7. 언제 Ollama / LM Studio / vLLM
8. FAQ

---

1. Ollama vs LM Studio — 핵심 비교

2026년 로컬 LLM은 3강 체제입니다.

• Ollama: CLI + REST API, 스크립팅 중심, 개발자용 de facto
• LM Studio: GUI + CLI + REST, Apple Silicon에서 MLX로 가장 빠름
• vLLM: 프로덕션 서버, PagedAttention + Continuous Batching, 동시 요청 처리

일단 개발자 워크스테이션 용도로 쓰이는 두 개(Ollama · LM Studio)부터 잘라봅니다.

몇 가지 짚고 가야 하는 포인트.

Ollama의 최신 상태

Ollama는 2026-03에 v0.6.2가 나오면서 Llama 4 Scout 8B, Gemma 4 MLX, Flash Attention v2.7, M4 Metal 3 최적화가 들어갔습니다. rc로는 v0.21.1-rc0(2026-04-21)이 돌고 있어요. 매 마이너 릴리스마다 백엔드(llama.cpp 기반)와 Apple Silicon 최적화가 갱신되는 페이스입니다.

가장 중요한 점: Ollama는 OpenAI 호환 API를 기본으로 노출합니다. 설치하자마자 http://localhost:11434/v1/chat/completions가 열려 있어요. 이게 스택 전체 의미를 뒤집어 놓는데, 뒤에서 따로 봅니다.

LM Studio의 Apple Silicon 우위

LM Studio가 Mac에서 빠른 이유는 MLX 백엔드를 기본 채용했기 때문입니다. MLX는 Apple이 2023년에 공개한 Apple Silicon 네이티브 ML 프레임워크예요. M3 Ultra에서 Gemma 3 1B 기준, LM Studio가 237 tok/s, Ollama가 149 tok/s라는 실측 보고가 있습니다(소스에 링크). 같은 하드웨어에서 ~1.5배.

그리고 2026-02에 들어온 LM Link 기능 — Tailscale 기반 리모트 접속이 기본으로 붙었습니다. 데스크톱에서 서버 돌리고, 노트북에서 호출하는 구성이 설정 거의 없이 됩니다.

결정 기준

읽는 입장에서 고민이 생기는 지점이 “어느 걸 쓸까”인데, 한 줄로 요약하면:

• 스크립트·백엔드에 꽂을 거면 Ollama (CLI·REST·OpenAI 호환이 기본)
• Mac에서 모델 여러 개 실험할 거면 LM Studio (MLX 속도 + GUI)
• 프로덕션 동시 요청이면 vLLM (7절에서 별도로)

---

2. GGUF 양자화 메커니즘 ― 비트 vs 품질

로컬 LLM을 깊게 이해하려면 GGUF를 피할 수 없습니다.

GGUF는 llama.cpp 프로젝트가 만든 모델 포맷이고, Ollama·LM Studio·koboldcpp·LocalAI 전부 내부에서 llama.cpp를 씁니다. 그래서 사실상 로컬 LLM의 표준 포맷이에요.

GGUF 자체보다 더 중요한 건 양자화(quantization) 입니다.

양자화가 뭘 하는 건가

원래 Llama 3.3 70B 같은 모델은 FP16(16비트 부동소수점)으로 훈련됩니다. 파라미터 700억 개 × 2바이트 = 약 140GB. 맥북은커녕 RTX 6000 Ada 48GB 한 장에도 안 들어갑니다.

양자화는 이 파라미터 하나하나를 더 적은 비트로 표현하는 기법입니다. FP16의 2바이트를 4비트로 줄이면, 크기가 1/4로 줄어요. 품질은 어느 정도 떨어지지만, 중요한 건 품질 저하가 크기 저하보다 훨씬 느리다는 점입니다.

비트별 trade-off (13B 모델 기준)

주목할 숫자 두 개:

• Q4_K_M = FP16 대비 크기 -70%, 속도 +87%, 품질 95%
• Q5_K_M은 크기가 살짝 크지만 품질 97%

왜 4비트가 “대중 스윗스팟”이냐면, 그 아래(Q3)부터 품질 하락이 선형이 아니라 가속됩니다. Q3_K_M에서 품질 90%, Q2에서는 85% 아래로 떨어지는 경우가 흔해요. 반대로 4비트→5비트→6비트→8비트로 올라가도 품질 개선이 점점 둔화됩니다. “가성비”라는 말이 정확히 맞는 구간이에요.

K_M이 뭔가

Q4_K_M의 “K”는 K-quants라는 양자화 방식, “M”은 medium precision을 뜻합니다. 같은 Q4여도 Q4_0, Q4_K_S, Q4_K_M이 있고, 뒤로 갈수록 메타데이터를 더 정교하게 넣어서 품질이 올라갑니다. 실무에서는 Q4_K_M을 기본으로 잡고, 메모리가 남으면 Q5_K_M, 부족하면 Q3_K_M으로 내립니다.

(해석) 왜 4비트에서 품질이 95%나 유지되나

공식 근거는 아니지만 업계 통설은 이렇습니다. LLM 파라미터는 “정확한 값”보다 “상대적 배치”가 중요합니다. 인접 파라미터 간 비율이 맞으면, 값 자체가 2%씩 틀려도 출력 품질이 거의 안 변합니다. 양자화는 이 성질을 이용해서 값을 근사치로 구겨 넣는 거예요. (업계 해석 · 공식 정량 설명은 아님)

---

3. 2026 인기 모델 메모리 요구치

양자화 원리보다 실무에선 “내 하드웨어에서 뭐가 돌아가냐”가 더 급합니다.

몇 가지 현실 체크

70B는 로컬의 최전선. Q4_K_M 기준 39GB. RTX 6000 Ada(48GB) 한 장이나 2×3090(각 24GB → 총 48GB, 텐서 병렬)이면 돌아갑니다. Mac은 M3 Max 64GB 이상. Q8_0까지 가면 74GB라 H100 80GB 한 장 또는 M3 Ultra 128GB가 필요해요.

32B가 데스크톱 스윗스팟. Qwen 2.5 32B Q4_K_M이 ~20GB. 일반인이 살 수 있는 가장 큰 GPU인 RTX 4090(24GB)에 깔끔하게 들어갑니다. Q5_K_M은 24GB를 꽉 채우는 수준이라 OS까지 고려하면 RTX 5090(32GB)이 안전.

8B가 노트북 데일리. Q4_K_M 6GB. M2/M3 16GB Mac에서 OS·브라우저 돌리고도 여유. 속도도 충분히 빠릅니다. “개인 AI 도우미” 용도로 현실적인 라인이에요.

DeepSeek V3 671B는 로컬 밖. Mixture of Experts라 전체 파라미터 671B지만 활성화는 37B라고 하긴 합니다. 그래도 weight 전체를 로드해야 하므로 Q4여도 ~400GB. 개인이 로컬로 돌리는 모델이 아니에요. (fireworks · together 같은 서빙 서비스 통하는 게 현실)

---

4. KV cache 함정 ― 컨텍스트 늘리면 VRAM 폭증

여기부터가 “튜토리얼에 안 나오는” 부분입니다.

방금 표는 모델 weight만 계산한 수치예요. 실제로 로컬에서 돌릴 때는 KV cache가 따로 VRAM을 먹습니다. 이걸 모르면 “어? 70B가 들어간다고 했는데 왜 터지지” 상황이 생겨요.

KV cache가 뭔가

Transformer가 토큰을 하나씩 생성할 때, 이전 토큰들의 Key와 Value 벡터를 계속 다시 쓸 수 있게 메모리에 쌓아둡니다. 이게 KV cache예요. 없으면 토큰 하나 생성할 때마다 앞에 있는 모든 토큰의 attention을 다시 계산해야 해서 속도가 제곱으로 느려집니다.

그래서 캐싱하는 건데, 이게 컨텍스트 길이에 정비례합니다.

수학

대충 수식 하나 — KV cache VRAM은

KV_cache = 2 × num_layers × hidden_size × context_length × batch × bytes_per_value

Llama 3.3 70B 기준으로 (80 layers × 8192 hidden × FP16):

• 2K 컨텍스트 → 약 1.6 GB
• 32K 컨텍스트 → 약 26 GB
• 128K 컨텍스트 → 약 42 GB+ 추가

여기서 중요한 건, 128K 쓰고 싶으면 39GB(weight) + 42GB(KV) = 81GB가 필요하다는 점입니다. RTX 6000 Ada 48GB 한 장으로 70B Q4_K_M을 “돌릴 수 있다”는 건 짧은 컨텍스트 한정이에요.

실무 대처

1. 짧게 쓰기 — 대부분 작업은 8K~32K면 충분. 128K는 실제로 드물게 필요함
2. KV cache 양자화 — llama.cpp/Ollama는 KV cache도 4비트/8비트로 양자화 가능. Flash Attention v2.7(Ollama v0.6.2 기본 적용)과 함께 쓰면 효과가 큼
3. Grouped Query Attention (GQA) — Llama 3 이후 모델은 이 구조로 이미 KV cache가 원래의 1/8로 줄어듦. 그래도 긴 컨텍스트에선 여전히 큼
4. 배치 크기 1 — 로컬 단일 사용은 이미 batch=1이라 이건 기본

결론: 긴 컨텍스트 쓸 예정이면 모델 weight 메모리 외에 KV cache VRAM을 별도로 계산해서 마진을 둬야 합니다. 이게 로컬 LLM을 처음 돌릴 때 가장 자주 밟는 지뢰예요.

---

5. OpenAI 호환 API의 의미

이 절이 이 글에서 아마 가장 실무적인 부분입니다.

Ollama는 기본으로 OpenAI 호환 엔드포인트를 엽니다. 이게 실제로 뭘 의미하냐면 ―

from openai import OpenAI

# OpenAI 클라우드
client = OpenAI(api_key="sk-...")
client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "hello"}]
)

# Ollama 로컬 (base_url만 교체)
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # 아무 문자열이나 OK
)
client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "hello"}]
)

기존 OpenAI SDK 코드에서 base_url과 model 두 줄만 바꾸면 로컬로 옮겨집니다. 그게 전부예요.

이게 왜 중요하냐면 ―

1) 기존 코드 자산이 안 죽는다

회사 안에서 이미 OpenAI SDK로 짜둔 에이전트·RAG 파이프라인이 있다면, base_url 하나만 바꿔서 로컬 모드로 돌릴 수 있습니다. 프레임워크 마이그레이션이 필요 없어요. LangChain·LlamaIndex·Haystack 같은 주요 프레임워크도 전부 OpenAI 호환을 1급 시민으로 취급합니다.

2) 비용이 0으로 떨어진다

API 호출이 많은 워크로드 — 이를테면 “1만 개 문서를 LLM으로 분류”, “실험용 프롬프트 스위핑” — 를 로컬로 밀면 토큰당 과금이 그냥 사라집니다. 전기세와 하드웨어 감가만 남아요.

3) Privacy

민감한 데이터를 외부 API에 보낼 수 없는 도메인 — 의료·법률·사내 데이터 — 에서 로컬 LLM이 유일한 선택지가 되는 경우가 많습니다. OpenAI 호환이라 기존 워크플로우를 그대로 가져올 수 있다는 게 여기서 결정적이에요.

4) 오프라인

비행기 안, 해외 출장 낯선 네트워크, 회사 방화벽. 인터넷이 불안정한 상황에서도 같은 코드가 돕니다.

주의 ― 호환성은 “대부분”이지 “100%”가 아닙니다

• Tool use(function calling) 포맷은 모델별로 차이가 있음 (최근 모델은 대부분 호환)
• Structured outputs (JSON schema 강제) 지원이 모델마다 다름
• Streaming 포맷은 일치
• Vision(이미지 입력)은 모델이 지원해야 함

대부분의 실무 코드는 그대로 돕니다. 엣지 케이스는 모델 docs 확인.

---

6. 기타 런타임 6종 — 언제 뭘 고르나

Ollama·LM Studio 외에도 로컬·서버 LLM 스택에는 알아야 할 도구가 몇 개 더 있습니다. 용도가 전부 달라요.

llama.cpp

모든 도구의 기반. Ollama·LM Studio·koboldcpp·LocalAI 전부 내부에서 llama.cpp를 씁니다. llama-server 실행 파일을 직접 돌리면 :8080/v1에 OpenAI 호환 API가 열립니다. 세밀 제어가 필요하거나(커스텀 샘플링·로그확률 접근), 의존성을 최소로 가져가고 싶을 때 써요. C++ 단일 바이너리입니다.

vLLM

프로덕션 서버용. UC Berkeley가 만든 고성능 서빙 엔진. 핵심은 두 가지.

• PagedAttention: OS 가상메모리처럼 KV cache를 페이지 단위로 관리. 메모리 단편화 해결
• Continuous Batching: 요청들을 동적으로 배칭. 동시에 수백 요청 처리 가능

Ollama는 “한 번에 한 요청 잘 돌리는” 설계입니다. vLLM은 N명이 동시에 치는 사내 서비스용이에요. :8000/v1 OpenAI 호환. 팀 단위 셀프호스팅이면 vLLM.

mlx-lm (Apple MLX)

Apple Silicon 네이티브 프레임워크. LM Studio가 기본 채용한 그 백엔드를 직접 쓰는 형태예요. Python에서 pip install mlx-lm으로 설치. Hugging Face의 MLX 변환 모델을 직접 로드합니다. Mac에서 가장 빠른 경로이긴 한데, 개발자 대상 툴이라 GUI가 없어요. 세팅 자유도가 높음.

koboldcpp

llama.cpp 포크인데 단일 실행파일로 배포됩니다. 특이점은 API 3개를 동시에 노출 — KoboldAI · OpenAI · Ollama 호환. 내장 웹 UI도 있어서 GUI도 없고 CLI도 복잡한 게 싫을 때 쓰는 합의안 포지션이에요.

TGI (Text Generation Inference)

HuggingFace가 만든 프로덕션 서빙. Docker 중심 배포, HF 생태계와 딱 맞물립니다. vLLM과 포지션이 겹치는데, “HF 허브 + Docker + K8s” 스택이면 TGI가 자연스러워요.

LocalAI

멀티백엔드 어댑터. GGUF·MLX·Diffusion·Whisper까지 한 프로세스에서 처리합니다. 2026-01부터 Anthropic API 호환이 추가되면서, Claude SDK로 짠 코드를 로컬로 옮기는 유일한 경로가 됐어요. (Ollama는 OpenAI 호환만 제공)

한 문장 정리

• llama.cpp: 모든 걸 C++로 통제
• vLLM: 프로덕션 동시 요청
• mlx-lm: Mac에서 직접 MLX
• koboldcpp: 단일파일 + 3중 호환
• TGI: HF + Docker 생태계
• LocalAI: OpenAI + Anthropic 둘 다 호환

---

7. 언제 Ollama / LM Studio / vLLM

요약 결정 트리.

개인 개발자, 맥북 하나

→ LM Studio 시작 (GUI로 모델 여러 개 다운받아 놓고, MLX 속도 덕 봄)
→ 스크립트화 단계 되면 Ollama 추가 (REST + OpenAI 호환)

리눅스 워크스테이션 + RTX 3090/4090

→ Ollama 메인 (CLI·REST가 자연스러움)
→ 커스텀 샘플링·고급 옵션이 필요하면 llama.cpp 직접

사내 팀이 같이 쓰는 셀프호스트

→ vLLM (Continuous Batching이 핵심). Ollama는 동시 요청에 불리.
→ Docker/K8s 환경이면 TGI도 선택지

Mac에서 최대 속도를 뽑아야 함

→ mlx-lm 직접 (LM Studio가 같은 백엔드를 쓰지만, Python 제어가 필요할 때)

Claude SDK 코드가 이미 있음

→ LocalAI (Anthropic API 호환 레이어)

RAG/에이전트 프레임워크에 꽂을 거면

→ Ollama (OpenAI 호환이 LangChain·LlamaIndex 기본 어댑터와 가장 매끄럽게 붙음)

---

8. FAQ

Q1. Ollama와 LM Studio를 같이 설치해도 되나요?

됩니다. 포트가 다릅니다 — Ollama는 :11434, LM Studio는 :1234. 모델 파일도 별도 디렉터리에 저장돼서 충돌 없어요. 실제로 LM Studio로 모델 실험 → Ollama로 스크립트 배포는 흔한 조합입니다. 다만 GGUF 파일을 두 번 받게 되니 디스크 용량은 주의.

Q2. RTX 4090(24GB)에서 돌릴 수 있는 가장 큰 모델은?

Qwen 2.5 32B Q4_K_M(~20GB)이 안전한 상한. Q5_K_M(24GB)은 컨텍스트 짧게만 돌아갑니다. 70B는 Q3_K_S(~28GB)도 들어가다 말아서 현실적이지 않아요. 32B급이 RTX 4090의 스윗스팟입니다. KV cache까지 쓰려면 컨텍스트 8K~16K로 잡으세요.

Q3. Ollama가 LM Studio보다 느린 이유는?

Apple Silicon 한정. LM Studio는 Apple MLX 백엔드를 기본 채용해서 M-시리즈 칩의 ANE·Metal을 더 깊게 씁니다. Ollama는 llama.cpp(Metal 백엔드) 기반이에요. M3 Ultra + Gemma 3 1B 기준으로 LM Studio 237 tok/s vs Ollama 149 tok/s 보고가 있습니다. 리눅스·NVIDIA 환경에선 두 도구 모두 llama.cpp(CUDA)에 가깝게 붙어서 차이가 거의 없어요.

Q4. 프로덕션에서 Ollama를 그대로 쓰면 안 되나요?

개인 1인 사용이면 문제없습니다. 그런데 팀 5명 이상이 동시에 치기 시작하면 Ollama의 요청 큐가 직렬이라 금방 막혀요. 이때 vLLM으로 옮기거나, Ollama 인스턴스 여러 개를 로드밸런서 뒤에 붙이는 패턴을 씁니다. “개인 vs 동시 요청”이 분기점이에요.

Q5. 클라우드 API를 아예 안 써도 되나요?

현실적으로 아닙니다. 로컬이 이기는 영역(라우팅·분류·대량 배치·민감 데이터)이 있고, 클라우드가 이기는 영역(최고 품질 추론·긴 컨텍스트·멀티모달·복잡한 에이전트)이 있어요. 2026년 실무 기본은 에이전트 내부에서 로컬 + 클라우드를 섞는 것입니다. OpenAI 호환 덕분에 같은 코드 안에서 base_url만 조건부로 바꾸면 돼요.

---

9. 마무리 ― P 시리즈 완결

P 시리즈는 여기서 마무리입니다.

• P1: Claude 패밀리 업그레이드
• P2: API 호출 메커니즘
• P3: 오픈 vs 클라우드 LLM
• P4: 클로즈드 4사 기술 전략
• P5: 오픈소스 3강 (Llama·Qwen·DeepSeek)
• P6: 로컬 스택 (Ollama·LM Studio) ← 여기

클라우드 API에서 시작해서, 오픈소스의 의미를 거쳐, 자기 기기에서 돌리는 지점까지 내려온 셈입니다. 이제 남은 건 하나 — 뭘 돌리느냐보다, 어떻게 조합하느냐. 이 축이 다음 시리즈의 테마입니다.

읽어주셔서 감사합니다.

---

소스 리스트

• Ollama GitHub: https://github.com/ollama/ollama
• Ollama Releases: https://github.com/ollama/ollama/releases
• Ollama 라이브러리: https://ollama.com/library?sort=newest
• Ollama Blog: https://ollama.com/blog
• Ollama OpenAI 호환 문서: https://docs.ollama.com/api/openai-compatibility
• LM Studio: https://lmstudio.ai/
• LM Studio GitHub: https://github.com/lmstudio-ai
• llama.cpp quantization 논의: https://github.com/ggml-org/llama.cpp/discussions/2094
• Qwen 2.5 Coder 32B Model Card: https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct
• KV cache 관련 논문: https://arxiv.org/html/2601.14277v1

---

뉴스레터 CTA

이렇게 “설치 튜토리얼이 아닌, 구조로 쪼개는” 글을 매주 월요일 아침 메일로 보냅니다. 받아보고 싶으면 뉴스레터 회원가입(무료·30초)에서 신청하세요.