Ollama·vLLM·llama.cpp 차이 — 로컬 LLM 실행 도구는 무엇을 선택해야 할까

로컬 PC나 사내 GPU 서버에서 LLM을 실행하려고 검색하면 Ollama, vLLM, llama.cpp가 거의 항상 함께 등장합니다. 셋 다 모델을 내려받아 추론하고 HTTP API로 제공할 수 있지만, 지향점은 꽤 다릅니다.

 

Ollama는 복잡한 모델 실행 과정을 제품처럼 감싸 쉽게 쓰게 만들고, vLLM은 여러 사용자의 요청을 GPU에서 높은 처리량으로 서비스하는 데 집중합니다. llama.cpp는 C/C++ 기반의 가벼운 런타임으로 다양한 CPU와 GPU에서 GGUF 모델을 세밀하게 실행하는 데 강합니다.

 

이 글에서는 단순한 속도 순위가 아니라 개인용 실험, 애플리케이션 개발, 사내 서비스, 엣지 배포라는 실제 목적에 맞춰 세 도구를 비교합니다.

한눈에 보는 결론

도구	가장 잘 맞는 상황	모델 형식과 생태계	핵심 강점	먼저 확인할 약점
Ollama	노트북·워크스테이션에서 빠르게 모델을 실행하고 앱과 연결	자체 모델 라이브러리, Modelfile, GGUF 가져오기	설치와 모델 관리가 쉬움, macOS·Windows·Linux 지원	대규모 다중 사용자 서빙의 세밀한 튜닝은 제한적
vLLM	NVIDIA·AMD GPU 서버에서 높은 동시 처리량으로 API 제공	Hugging Face 모델 중심, 다양한 양자화 방식	PagedAttention, 연속 배칭, 분산 추론, OpenAI 호환 API	설치·GPU 호환성·운영 설계가 상대적으로 복잡
llama.cpp	CPU·Apple Silicon·소형 GPU·엣지에서 가볍고 세밀하게 실행	GGUF 중심	낮은 의존성, 폭넓은 하드웨어, 양자화와 오프로딩 제어	모델 변환과 옵션 선택을 사용자가 더 이해해야 함

가장 짧게 정리하면 다음과 같습니다.

개인 개발자는 Ollama부터, GPU 기반 다중 사용자 서비스는 vLLM부터, 자원 제약 환경과 세밀한 로컬 튜닝은 llama.cpp부터 검토하면 됩니다.

그림: 세 도구의 주요 사용 목적과 실행 계층 · Ollama, vLLM, llama.cpp 공식 문서를 바탕으로 재구성

Ollama — 로컬 LLM을 애플리케이션처럼 다룬다

Ollama의 장점은 모델 파일, 채팅 템플릿, 실행 옵션, API 서버를 하나의 사용자 경험으로 묶었다는 점입니다. macOS, Windows, Linux에서 설치한 뒤 모델 이름만 지정하면 다운로드와 실행을 이어서 처리할 수 있습니다.

ollama run gemma3

로컬 서버는 기본적으로 http://localhost:11434에서 동작하며 자체 API를 제공합니다.

curl http://localhost:11434/api/chat -d '{
  "model": "gemma3",
  "messages": [{"role": "user", "content": "KV Cache를 설명해줘"}]
}'

공식 Modelfile은 기본 모델과 시스템 프롬프트, 파라미터, 템플릿, 어댑터를 함께 정의하는 청사진입니다. 팀에서 반복 사용하는 로컬 모델 설정을 파일로 관리하기 좋습니다.

FROM gemma3
PARAMETER temperature 0.2
SYSTEM 당신은 인프라 기술 문서를 설명하는 조력자다.

Ollama는 Apple GPU의 Metal 가속을 지원하며 NVIDIA, AMD ROCm, 실험적 Vulkan 지원도 공식 문서에 정리되어 있습니다. 모델을 직접 빌드하고 서버 옵션을 조합하기보다 “일단 로컬에서 대화하고 앱에 연결하고 싶다”는 요구에 가장 빠르게 답합니다.

 

다만 로컬 API는 기본적으로 인증이 필요하지 않습니다. 공식 인증 문서도 localhost:11434 로컬 접근에는 인증이 없다고 명시합니다. 따라서 0.0.0.0에 바인딩해 사내망이나 인터넷에 그대로 노출하는 방식은 피하고, 역방향 프록시·인증·방화벽을 별도로 구성해야 합니다.

vLLM — GPU를 여러 요청이 효율적으로 공유하게 한다

vLLM은 개인용 채팅 앱보다는 추론 서버 엔진에 가깝습니다. 여러 사용자가 동시에 긴 프롬프트를 보내는 환경에서는 KV Cache가 GPU 메모리를 크게 차지하고, 요청마다 길이가 달라 메모리 파편화와 유휴 시간이 발생합니다.

 

vLLM은 PagedAttention으로 KV Cache를 페이지처럼 관리하고, 도착한 요청을 연속 배칭해 GPU가 쉬는 시간을 줄입니다. 최신 공식 문서는 chunked prefill, prefix caching, speculative decoding, 다양한 양자화와 분산 병렬화를 주요 기능으로 제시합니다.

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --dtype auto \
  --api-key local-token

기본 서버는 http://localhost:8000에서 실행되며 OpenAI 호환 API를 제공합니다.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local-token",
)

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "안녕하세요"}],
)

기존 애플리케이션이 OpenAI SDK를 사용한다면 base_url을 바꿔 로컬 서버로 연결하기 쉽습니다. Chat Completions뿐 아니라 Responses, Embeddings, 음성 관련 API 등 지원 범위도 확장되고 있지만, 모든 OpenAI 옵션이 동일하게 동작한다고 가정해서는 안 됩니다. 공식 호환성 문서에서 엔드포인트별 제약을 확인해야 합니다.

 

vLLM의 장점은 동시 사용자가 늘어날 때 분명해집니다. 반대로 한 사람이 노트북에서 한 번에 한 요청만 실행한다면 설치와 운영 복잡성에 비해 이득이 크지 않을 수 있습니다.

그림: vLLM의 연속 배칭과 페이지 단위 KV Cache 관리 개념 · vLLM 공식 문서를 바탕으로 재구성

llama.cpp — 작은 런타임과 GGUF로 하드웨어 경계를 넓힌다

llama.cpp는 C/C++ 기반 추론 프로젝트입니다. CPU만 있는 시스템, Apple Silicon, 소비자용 GPU, 혼합 CPU·GPU 오프로딩과 같은 폭넓은 환경에서 모델을 실행할 수 있습니다.

 

핵심 모델 형식은 GGUF입니다. GGUF 파일에는 모델 가중치뿐 아니라 실행에 필요한 메타데이터를 함께 담을 수 있고, Q4·Q5·Q8 같은 여러 양자화 수준으로 배포됩니다. 양자화는 메모리 사용량과 속도를 줄이는 대신 정확도 손실 가능성을 받아들이는 교환입니다.

llama-cli -m model.Q4_K_M.gguf -p "Self-Attention을 설명해줘"

llama-server를 사용하면 가벼운 HTTP 서버와 기본 웹 UI, OpenAI 호환 Chat Completions 엔드포인트를 실행할 수 있습니다.

llama-server -m model.Q4_K_M.gguf --port 8080

공식 README는 병렬 디코딩, 임베딩, 재순위화, 문법 기반 구조화 출력과 speculative decoding도 제공합니다. GPU 레이어 수, 컨텍스트 크기, 배치와 스레드 같은 옵션을 세밀하게 조정할 수 있어 임베디드·엣지·데스크톱 제품에 런타임을 포함하려는 개발자에게 유리합니다.

 

반면 사용자는 모델의 GGUF 호환 여부와 양자화 종류, 메모리 예산을 이해해야 합니다. “같은 7B 모델”이라도 양자화 수준과 컨텍스트 길이, KV Cache 정밀도에 따라 필요한 메모리와 결과 품질이 달라집니다.

같은 모델인데 왜 메모리와 속도가 다를까

도구보다 먼저 모델 크기와 실행 조건을 봐야 합니다. 대략적인 가중치 메모리는 다음처럼 생각할 수 있습니다.

가중치 메모리 ≈ 파라미터 수 × 파라미터당 바이트

예를 들어 8B 모델을 FP16으로만 단순 계산하면 약 16GB의 가중치 공간이 필요합니다. 4비트 양자화는 이론적으로 약 4GB 수준까지 줄일 수 있지만 실제 실행에는 메타데이터, 연산 버퍼, KV Cache와 런타임 여유 공간이 추가됩니다.

 

특히 컨텍스트가 길어지고 동시 요청이 늘면 KV Cache가 커집니다. 개인용 단일 대화에서는 모델 가중치가 주요 부담이지만, 서버에서는 동시 사용자 수와 최대 컨텍스트가 용량 계획을 크게 바꿉니다.

비교 기준	개인용 단일 요청	다중 사용자 서버
가장 큰 관심사	설치 편의, 모델이 메모리에 들어가는가	처리량, 지연시간, KV Cache와 배칭
양자화 효과	저사양 장치에서 실행 가능성 확대	GPU당 수용 모델·요청 수 증가 가능
컨텍스트 증가 영향	한 대화의 KV Cache 증가	모든 활성 요청의 KV Cache가 합산
대표 선택	Ollama 또는 llama.cpp	vLLM 중심 검토

세 도구는 서로 완전히 독립적이지 않다

Ollama와 llama.cpp는 GGUF와 로컬 추론이라는 영역에서 연결점이 있고, vLLM도 최신 버전에서 GGUF를 포함한 여러 양자화 방식을 지원합니다. 따라서 “GGUF는 무조건 llama.cpp”, “Hugging Face 모델은 무조건 vLLM”처럼 단정하면 최신 기능을 놓칠 수 있습니다.

 

하지만 지원 여부와 운영 적합성은 다릅니다. 어떤 형식을 읽을 수 있다는 사실과 그 형식이 해당 엔진의 주력 경로라는 사실은 구분해야 합니다. 모델 아키텍처, 양자화 커널, 하드웨어 백엔드에 따라 성능과 안정성이 달라지므로 실제 후보 모델로 벤치마크해야 합니다.

목적별 선택 가이드

그림: 사용 목적과 하드웨어에 따른 Ollama·vLLM·llama.cpp 선택 흐름 · 세 프로젝트의 공식 문서를 바탕으로 재구성

개발자가 노트북에서 RAG를 시험한다면

Ollama가 가장 편합니다. 모델 설치와 교체가 단순하고 로컬 API가 즉시 열리기 때문에 LangChain, LlamaIndex, Open WebUI 같은 도구와 연결하기 쉽습니다. MacBook의 Apple Silicon에서도 Metal 가속을 활용할 수 있습니다.

사내 챗봇을 여러 명이 동시에 사용한다면

GPU 서버에서 vLLM을 먼저 검토하는 편이 좋습니다. 연속 배칭과 KV Cache 관리, OpenAI 호환 API, 메트릭과 분산 실행 기능이 서비스 운영 목적에 맞습니다. 단, 인증·TLS·요청 제한·테넌트 격리는 별도 게이트웨이에서 설계해야 합니다.

CPU 서버나 엣지 장치에 포함한다면

llama.cpp가 강합니다. 실행 파일과 라이브러리 형태로 포함할 수 있고, GGUF 양자화와 CPU·GPU 오프로딩을 세밀하게 조정할 수 있습니다.

단일 GPU에서 소수 사용자만 쓴다면

Ollama와 vLLM을 같은 모델·같은 컨텍스트·같은 동시성으로 측정해야 합니다. 설정 편의가 더 중요하면 Ollama, 요청 처리량과 운영 지표가 더 중요하면 vLLM이 유리합니다.

벤치마크할 때 놓치기 쉬운 기준

초당 토큰 수 하나로 결론을 내리면 안 됩니다.

• TTFT(Time To First Token): 첫 토큰이 나오기까지의 지연
• TPOT(Time Per Output Token): 이후 토큰 생성 간격
• 동시 요청 수가 늘 때의 총 처리량
• 긴 프롬프트의 Prefill 시간
• 최대 컨텍스트에서의 메모리 사용량
• 모델 로딩 시간과 콜드 스타트
• 양자화에 따른 답변 품질 변화
• 장애 시 재시작, 메트릭, 로그와 배포 자동화

동일한 모델 이름이라도 정밀도와 양자화 파일이 다르면 비교가 공정하지 않습니다. 입력 길이, 출력 길이, 동시성, 샘플링 파라미터를 고정하고 실제 업무 프롬프트로 측정해야 합니다.

운영 보안은 추론 엔진이 대신해주지 않는다

로컬에서 실행된다는 이유만으로 안전한 것은 아닙니다. API를 다른 호스트에 공개하면 일반적인 서비스 보안이 그대로 필요합니다.

• TLS와 인증을 적용한 API Gateway
• 사용자·애플리케이션별 Rate Limit과 사용량 한도
• 모델 파일과 캐시 디렉터리의 접근 통제
• 신뢰할 수 있는 모델 출처와 해시 검증
• 프롬프트·응답 로그의 개인정보 마스킹
• 컨테이너와 GPU 노드의 최소 권한
• 도구 호출 모델의 실행 권한 분리와 승인

특히 Ollama 로컬 API를 네트워크에 직접 노출하거나, vLLM의 API 키 하나를 여러 시스템이 공유하거나, llama-server를 인증 없이 인터넷에 연결하는 구성은 피해야 합니다.

결론

Ollama, vLLM, llama.cpp는 우열보다 역할이 다른 도구입니다.

 

Ollama는 모델을 쉽게 내려받고 실행하며 개발 도구와 연결하는 로컬 경험이 강합니다. vLLM은 GPU 서버에서 여러 요청을 효율적으로 처리하는 추론 서비스 엔진입니다. llama.cpp는 GGUF와 가벼운 C/C++ 런타임을 바탕으로 다양한 하드웨어와 제품 내장 환경에 대응합니다.

도구를 먼저 고르지 말고 사용자 수, 하드웨어, 모델 형식, 컨텍스트 길이, 운영 방식부터 정한 뒤 실제 후보 모델로 측정해야 합니다.

개인 실험에서 시작한다면 Ollama, 서비스 트래픽이 문제라면 vLLM, 자원 제약과 배포 유연성이 핵심이라면 llama.cpp가 좋은 출발점입니다.

참고 자료

• Ollama 공식 문서
• Ollama 하드웨어 지원
• Ollama Modelfile
• vLLM 공식 문서
• vLLM OpenAI 호환 서버
• llama.cpp 공식 저장소