llama.cpp vs Ollama: 2026년엔 무엇을 돌려야 할까?

최대 tokens/second와 완전한 제어가 목표면 순수 llama.cpp, 한 줄 설치와 기본으로 동작하는 API 서버가 목표면 Ollama입니다. Ollama는 경쟁 엔진이 아닙니다 — llama.cpp를 추론 백엔드로 묶어 넣고, 모델 관리(ollama pull llama3.1)를 얹고, 포트 11434에서 REST API를 서빙하는 Go 서비스입니다. 그래서 진짜 질문은 “어느 엔진이 더 빠른가”가 아니라 “그 엔진의 노브를 얼마나 만지고 싶은가”입니다. Ollama는 보수적인 기본값(Q4_K_M 양자화, 절제된 컨텍스트, 얼마 전까지는 flash attention 없음)을 실어 나르기 때문에, 같은 하드웨어도 눈에 띄게 다른 숫자를 냅니다. 아래에서: 실제로 다른 점, 속도 격차의 출처, 양쪽에서 돌려본 같은 모델, 그리고 결정 표를 다룹니다.

llama.cpp와 Ollama의 차이는 무엇일까?

llama.cpp는 추론 엔진입니다: GGUF를 만든 Georgi Gerganov의 단일 C/C++ 프로젝트로, 양자화된 모델을 CPU, GPU 또는 둘의 혼합에서 돌립니다. one-shot 프롬프트용 llama-cli, OpenAI 호환 HTTP 서버인 llama-server, 그리고 엔진이 지원하는 모든 튜닝 플래그 — GPU 레이어 오프로드, KV 캐시 양자화, speculative decoding, 커스텀 샘플러 — 를 갖춥니다.

Ollama는 그 엔진 위에 얹힌 제품입니다. llama.cpp를 포크해 vendoring한 뒤 이렇게 감쌉니다:

• 자동 GGUF 가중치 분할이 붙은 모델 레지스트리(ollama pull, ollama list),
• Modelfile 시스템(프롬프트 템플릿과 파라미터를 위한 Dockerfile 같은 스펙),
• 모델을 VRAM에 따뜻하게 유지하고 자체 REST API를 노출하는 백그라운드 데몬,
• 안전한 기본값이 깔린 자동 하드웨어 감지.

실용적 귀결: Ollama에서는 모델을 관리하고, llama.cpp에서는 추론을 관리합니다. 양자화 포맷을 바꾸고, KV 캐시를 양자화하고, 컨텍스트를 기본값 너머로 올리고, 특정 레이어를 GPU에 고정하고 싶었다면 — 그건 llama.cpp 영역입니다. Ollama는 그 다이얼 대부분을 숨깁니다. 의도적으로요.

	llama.cpp	Ollama
정체	추론 엔진 (C/C++)	llama.cpp를 감싼 서비스
설치	소스 빌드 또는 패키지	한 줄 설치, 바이너리 하나
모델 실행	llama-cli -m model.gguf + 플래그	ollama run llama3.1
API	OpenAI 호환 (llama-server)	자체 REST + OpenAI 호환 엔드포인트
모델 관리	GGUF 파일을 직접 받음	레지스트리: pull/list/rm
기본값	모두 직접 선택	안전: Q4_K_M, 절제된 컨텍스트
엔진 업데이트	당일 (upstream)	upstream 릴리스보다 늦음
튜닝 깊이	전체 (KV 양자화, speculative decode, 샘플러)	제한된 passthrough
적합한 곳	성능 작업, 서버, 엣지 디바이스	시작하기, 개발 노트북

llama.cpp가 Ollama보다 빠를까?

같은 GGUF 파일, 같은 양자화, 같은 컨텍스트, 같은 llama.cpp 버전이라면 — 아니요, 노이즈 범위 안에서 서로 비슷합니다. Ollama가 곧 계산을 수행하는 llama.cpp이기 때문입니다. 보는 “Ollama가 30% 느리다” 벤치마크는 실제로는 기본값 비교입니다. 격차는 세 곳에서 옵니다:

1. 양자화 선택. Ollama 레지스트리의 기본값은 Q4_K_M입니다. 같은 모델을 llama.cpp에서 Q5_K_M이나 Q6_K로 돌리면 비슷한 속도에서 토큰당 더 나은 품질을 얻을 수 있고 — 아니면 날것의 속도를 위해 Q4_0/IQ4를 고릅니다.
2. Flash attention과 KV 캐시 양자화. --flash-attn에 -ctk q8_0 -ctv q8_0을 더하면 KV 캐시가 극적으로 줄어들어 긴 컨텍스트에서 tokens/second가 오르고, 같은 VRAM에 더 큰 컨텍스트가 들어갑니다. Ollama는 이 가운데 일부만 노출합니다.
3. 버전 지연. llama.cpp에는 커널 최적화가 매주 들어오고, Ollama는 자기 일정대로 upstream을 머지합니다. 갓 빌드한 llama.cpp는 같은 머신의 몇 달 된 Ollama 바이너리보다 측정 가능하게 빠를 수 있습니다 — Ollama가 따라잡을 때까지는.

빠른 벤치마크 명령, 엔진을 가리지 않는 — 프롬프트 평가와 생성 속도를 보고합니다:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Ollama 자체 모델 파일(~/.ollama/models/blobs/..., .gguf로 이름 변경)로 돌리면 보통 Ollama 숫자와 정확히 일치합니다 — 그리고 16k 컨텍스트에서 -ctk q8_0을 더해 역전시킵니다.

같은 모델을 양쪽에서 돌리는 방법은?

둘 다 GGUF를 먹습니다. 각각의 최소 end-to-end:

# --- Ollama 경로: 설치, pull, 서빙 ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # Q4_K_M 다운로드, VRAM 적재, 채팅 시작

# API, OpenAI 호환 스타일:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- llama.cpp 경로: 빌드, GGUF 다운로드, 서빙 ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # 또는 -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server는 OpenAI Chat Completions 스키마를 노출하므로, http://localhost:8080/v1/chat/completions로 향하는 같은 curl이 그대로 동작합니다. OpenAI API용으로 만들어진 도구 — 스크립트, 에디터, RAG 파이프라인 — 는 어느 쪽이든 향할 수 있습니다. 진짜 일을 하는 건 플래그입니다: -ngl 99는 모든 레이어를 GPU에 오프로드하고, --flash-attn과 -ctk/-ctv 짝은 Ollama 기본값이라면 거부할 8 GB 카드 안에 16k 컨텍스트를 유지합니다.

GGUF 파일 자체를 고르는 법과 양자화 라벨의 의미는 how to run GGUF models locally를 보세요.

Ollama가 더 나은 선택인 경우는?

대부분의 사람은 Ollama로 시작해야 하고, 그건 위로가 아닙니다:

• 오늘 밤 안에 동작이 목표다. 명령 한 번, 모델 pull, API 가동. llama.cpp는 백엔드 선택(CUDA/Vulkan/HIP/Metal), 빌드, 가중치 수작업 수령을 의미합니다.
• 모델을 여러 개 굴린다. 레지스트리, 자동 언로드, Modelfile이 GGUF 디렉터리 손관리를 이깁니다.
• 머신이 소박하다. Ollama 기본값이 보수적인 데는 이유가 있습니다 — 거의 항상 들어가고 돌아갑니다.
• 안정적인 API 면이 필요하다. Ollama 데몬이 모델 라이프사이클을 관리하므로 오래 도는 서비스가 신경 쓸 일이 없습니다.

벤치마킹할 때, 어떤 규모로든 서빙할 때, 폰이나 Raspberry Pi에서 돌릴 때, 작은 VRAM으로 긴 컨텍스트가 필요할 때, upstream에 머지되는 날 그 기능이 필요할 때는 순수 llama.cpp를 고르세요. 파워 유저는 흔히 둘 다 돌립니다: 일상 모델은 Ollama, 마지막 20%가 필요한 그 하나의 워크로드는 고정해둔 llama.cpp 빌드.

비교 대상이 데스크톱 GUI 앱이라면 축이 다릅니다 — Ollama vs LM Studio를 보고, 작업별 엔진 선택은 the best local LLMs for coding이 모델 쪽을 다룹니다.

그래서 뭘 써야 할까?

속도가 아니라 제어로 결정하세요. 엔진은 같고, 기본값이 다릅니다. “돌고 API를 서빙한다”가 목표면 Ollama를 설치하세요 — 어차피 만지지 않을 노브 몇 개를 잃을 뿐입니다. tokens/second, 컨텍스트 길이, 양자화 제어가 목표면 llama.cpp를 빌드하세요 — 모델 관리를 직접 하는 대가로 모든 노브를 얻습니다. 어느 쪽이든 같은 GGUF 파일을 돌리는 것이고, 나중에 갈아타는 비용은 리라이트가 아니라 오후 하나입니다.