Ollama vs llama.cpp 비교: 로컬 LLM 운영, 어디까지 직접 설정할까?

Ollama vs llama.cpp 비교: 어떤 상황에 무엇을 골라야 할까?

개발자 워크스테이션이나 소규모 사내 모델 서비스를 관리한다면 Ollama를 선택하는 편이 좋습니다. 모델 관리 명령어, 이름을 붙여 재사용하는 설정, 애플리케이션 연동용 API 덕분에 모델을 내려받은 뒤 실제로 활용하기까지 필요한 작업이 줄어듭니다. 메모리 용량 산정과 접근 제어는 여전히 필요하지만, 모든 개발자의 설치 안내에 서빙 관련 세부 설정까지 담을 필요는 줄어듭니다.

추론 설정을 직접 책임져야 한다면 llama.cpp를 선택하는 편이 좋습니다. 특정 GGUF 파일을 정확히 지정하거나, 새로운 양자화 방식을 검토하거나, GPU 배치를 조정하거나, 동시 요청과 컨텍스트 할당을 튜닝해야 할 때 강점이 있습니다. 배포 구성을 명확하게 설명할 수 있는 대신, 그 설정을 직접 유지·관리해야 합니다.

현재 런타임이 워크로드의 응답 성능과 품질 목표를 충족한다면 그대로 사용합니다. 누군가 노트북 벤치마크에서 더 빨랐다고 했다는 이유만으로 Ollama에서 llama.cpp로 옮기는 것은 근거가 부족합니다. 필요한 제어 기능이나 측정으로 확인한 문제를 구체적으로 짚을 수 있을 때 전환합니다.

이 글은 2026년 10월 16일 두 프로젝트의 공식 문서를 기준으로 확인했습니다. 설치, 모델 파일 제어, API 동작, 동시 처리, 하드웨어 지원을 비교 기준으로 삼았습니다. 직접 성능을 측정한 테스트 결과는 아닙니다.

위 기능은 Ollama CLI 가이드, GGUF 가져오기 가이드, llama.cpp 서버 레퍼런스에 설명되어 있습니다. 두 프로젝트의 로컬 소프트웨어는 모두 무료이며, Ollama의 호스팅 서비스와는 구분해야 합니다. 모델 라이선스도 별도로 확인해야 합니다. Ollama 저장소, llama.cpp 저장소.

같은 계보의 엔진, 서로 다른 운영 책임

Ollama는 추론 엔진에 모델 관리와 서비스 계층을 더하고, llama.cpp는 추론 툴을 직접 제공합니다. 추론은 모델 가중치와 입력을 바탕으로 출력 토큰을 생성하는 작업입니다. 이를 운영하려면 모델을 찾고, 설정에 이름을 붙이고, 모델을 메모리에 올리고, 요청을 받고, 오래된 모델 파일을 정리하는 일도 필요합니다.

Ollama는 저장소에서 llama.cpp의 기여를 명시하고 있습니다. 그렇다고 “단순한 래퍼”라고 단정하기는 어렵습니다. 현재 소스에는 MLX 구성 요소를 비롯한 다른 백엔드 관련 구현도 포함되어 있습니다. 계보가 같다고 모든 모델이 동일한 백엔드, 리비전, 실행 경로를 사용하는 것은 아닙니다. Ollama 소스와 기여 표기.

결국 배포 안내에 내부 동작을 어디까지 명시할 것인지의 문제입니다. 개발자에게 문서화된 모델 이름과 엔드포인트만 필요하다면 Ollama의 패키징이 도움이 됩니다. 인프라 담당자가 파일 체크섬, 백엔드 빌드, 메모리 설정을 함께 관리해야 한다면 llama.cpp를 직접 설정하는 편이 구성을 명확히 드러내기 쉽습니다.

설치와 모델 관리: 일상적인 운영에는 Ollama가 유리합니다

Ollama 사용법: 반복하는 설치 과정을 하나의 구성으로 묶습니다

Ollama는 관리형 모델 라이브러리와 서비스 API를 갖춘 로컬 모델 실행 도구입니다. macOS, Windows, Linux용 다운로드를 제공하며, CLI에는 IT 담당자가 일상적으로 쓰는 pull, run, ls, rm, ps, stop 명령어가 있습니다. 모델 설정을 텍스트로 작성하는 Modelfile을 사용하면 기반 모델과 지침을 하나의 이름으로 묶을 수 있습니다. Ollama 빠른 시작, CLI 레퍼런스.

여러 사람이 함께 코딩 모델을 시범 도입한다면 승인된 모델, 설정, 엔드포인트를 한 번 문서화하면 됩니다. 애플리케이션을 연결하려는 개발자가 GPU 할당부터 배워야 할 필요는 없습니다. 이것이 llama.cpp 대신 Ollama를 선택할 가장 설득력 있는 이유입니다.

다만 패키지로 제공되는 워크플로에서 필요한 서빙 동작을 설정할 수 없을 때는 한계가 드러납니다. 상위 프로젝트인 llama.cpp의 플래그를 Ollama에도 그대로 전달할 수 있다고 가정해서는 안 됩니다. 특정 설정을 전제로 배포를 설계하기 전에 설치한 릴리스에서 지원하는지 확인합니다.

llama.cpp: 직접 제어할 수 있고, 컴파일이 필수는 아닙니다

llama.cpp는 명령줄 도구, HTTP 서버, 웹 인터페이스를 포함한 추론 툴킷입니다. 현재 README에서는 설치 프로그램, 사전 빌드 릴리스, Docker, 소스 빌드를 안내합니다. 모델 호스팅 플랫폼인 Hugging Face에서 모델을 바로 불러오는 llama cli -hf와 llama serve -hf도 문서에 나와 있습니다. 소스 컴파일은 선택지이며 시작하기 위한 필수 조건이 아닙니다. llama.cpp 설치와 빠른 시작.

llama.cpp를 직접 사용하면 모델마다 별개 프로세스를 계속 수동으로 실행해야 한다고 생각하는 것도 정확하지 않습니다. 서버 문서에는 모델 디렉터리와 설정 프리셋을 활용하는 라우터가 설명되어 있습니다. 차이는 이런 운영 방식 중 어디까지 직접 선택하고 유지할 것인가에 있습니다. 서버 라우터 문서.

이 항목의 우위는 Ollama입니다. 일반적인 설치와 모델 운영에 더 적합합니다. 명시적으로 설정을 관리하는 일이 워크플로에 도움이 될 때 llama.cpp를 선택합니다. 실제로 필요한 것이 데스크톱 모델 작업 환경이라면 Ollama와 LM Studio 비교가 더 가까운 선택지를 다룹니다.

GGUF와 양자화: 모델 파일 제어에는 llama.cpp가 유리합니다

둘 다 GGUF 모델을 실행할 수 있지만, 모델을 준비하고 선택하는 과정은 llama.cpp에서 더 직접적으로 제어할 수 있습니다. GGUF는 가중치와 메타데이터를 담는 모델 파일 형식입니다. 양자화는 가중치를 낮은 정밀도로 저장해 용량을 줄이는 방식이며, 그에 따른 품질 변화는 모델과 작업에 따라 달라집니다.

llama.cpp의 양자화 도구 문서에는 Q4_K_M, Q5_K_M, Q8_0 같은 형식과 함께 중요도 행렬 및 텐서별 제어 기능이 설명되어 있습니다. 중요도 행렬은 모델의 어느 부분에 더 높은 정밀도가 필요한지 판단하는 데 도움을 줍니다. 텐서별 제어를 사용하면 가중치 배열마다 다른 설정을 적용할 수 있습니다. 일반적으로 배포되는 모델 파일이 메모리나 품질 목표를 충족하지 못할 때 필요한 기능입니다. llama.cpp 양자화 가이드.

Ollama는 Modelfile의 FROM 줄로 준비된 GGUF를 가져올 수 있습니다. 현재 문서에는 GGUF를 가져오는 과정에서 모델이 양자화되지는 않는다고 명시되어 있으며, 먼저 llama-quantize 같은 도구를 사용하도록 안내합니다. 역할을 나누면 유용합니다. llama.cpp로 모델 파일을 준비한 뒤, Ollama를 통해 이름을 붙인 설정을 배포하는 방식입니다. Ollama 모델 가져오기 문서.

예를 들어 호환되는 단일 파일 텍스트 모델을 ./team-model.gguf에 둔 다음, 아래와 같이 원하는 컨텍스트 크기를 지정한 Ollama 설정을 만들 수 있습니다.

cat > Modelfile <<'MODEL'
FROM ./team-model.gguf
PARAMETER num_ctx 8192
MODEL
ollama create team-local -f Modelfile
ollama run team-local

파일명과 모델 이름은 원하는 대로 정하면 됩니다. 컨텍스트 설정은 예시이며 모든 워크로드에 권장하는 값은 아닙니다. 문법은 Modelfile 레퍼런스를 따릅니다.

.gguf 확장자만으로 호환성이 보장되지는 않습니다. 모델 아키텍처와 대화 템플릿도 지원해야 합니다. 대화 템플릿은 메시지를 모델이 요구하는 입력 형태로 바꾸는 규칙입니다. 멀티모달 모델에는 별도의 시각 또는 오디오 구성 요소가 필요할 수도 있습니다. llama.cpp 양자화 가이드에서는 추가 프로젝터 파일을 설명합니다. 텍스트 응답에 성공했다고 이미지 입력이나 도구 사용까지 검증된 것은 아닙니다.

직접 양자화하거나 정확한 모델 파일을 선택해야 한다면 llama.cpp가 유리합니다. 준비된 모델이 잘 작동하고 Ollama의 운영 방식이 더 편하다면 Ollama도 적합합니다. 모델 가중치는 런타임과 별개로 선택해야 하며, 2026년 추천 로컬 LLM을 참고할 수 있습니다.

서버와 API 호환성: 일반적인 연동에는 Ollama가 유리합니다

문서화된 로컬 모델 API를 사용하는 애플리케이션에는 Ollama가 더 간편한 기본 선택지이고, 서버 설정 자체를 튜닝해야 한다면 llama.cpp가 유리합니다. Ollama는 자체 API와 OpenAI 호환 경로를 제공합니다. llama.cpp 역시 OpenAI 호환 채팅 완성, 응답, 임베딩 기능을 제공합니다. 여기서 호환성이란 익숙한 요청 인터페이스를 제공한다는 뜻이지, 모든 기능이 동일하게 동작한다는 뜻은 아닙니다. Ollama API 문서, llama.cpp 서버 레퍼런스.

구체적인 제약 하나가 전환 여부를 결정할 수 있습니다. Ollama의 Responses API는 상태를 유지하지 않습니다. previous_response_id와 conversation을 지원하지 않으므로, 이 필드로 서버가 대화를 기억하는 동작에 의존하는 애플리케이션이라면 기본 URL만 바꿔서는 충분하지 않습니다. 대상 서버 문서에서 동작을 확인하고 대화 기록을 어디에 보관할지 결정해야 합니다.

컨텍스트 설정도 따로 확인할 부분입니다. Ollama의 OpenAI 호환 가이드는 로컬 모델의 컨텍스트 크기를 바꿀 때 Modelfile을 사용하도록 안내합니다. 이 설정은 출력 토큰 수 제한과 다릅니다. 답변을 더 길게 허용한다고 해서 더 긴 입력을 처리할 수 있는 것은 아닙니다.

llama.cpp를 직접 배포하면 서버에서 모델 별칭, 채팅 템플릿 설정, API 키, 선택적 메트릭 기능을 사용할 수 있습니다. 사내 어시스턴트의 모델 파일을 교체하면서 API에 노출되는 이름은 유지해야 할 때 유용합니다. 그만큼 업그레이드할 때 검토하고 보존해야 할 설정도 많아집니다.

동시 처리: 세밀한 서빙 제어에는 llama.cpp가 유리합니다

Ollama도 동시에 들어오는 요청을 처리할 수 있으며, llama.cpp는 스케줄링과 메모리 설정을 더 직접적으로 노출합니다. 여러 모델을 동시에 로딩하는 것과 여러 요청을 동시에 처리하는 것은 다른 작업입니다. 코딩 모델과 임베딩 모델을 함께 메모리에 올릴 때의 메모리 사용 방식은, 로딩된 모델 하나를 여러 대화가 공유할 때와 다릅니다.

Ollama 문서에는 OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS, OLLAMA_MAX_QUEUE가 설명되어 있습니다. 모델당 병렬 요청 수의 기본값은 1이며, 병렬 처리 가능 여부는 가용 메모리에 따라 달라집니다. 대기열 한도를 높이면 더 많은 작업이 기다릴 수 있을 뿐, 추론 처리 용량이 늘어나지는 않습니다. Ollama 동시 처리 문서.

llama.cpp는 병렬 디코딩, 연속 배칭, 서버 슬롯을 문서화하고 있습니다. 연속 배칭을 사용하면 실행 중인 요청이 끝날 때 새 작업을 받아들일 수 있습니다. 슬롯은 처리 중인 요청이 차지하는 자리입니다. GPU 배치와 캐시 설정 외에도 --parallel, --kv-unified-per-slot 같은 제어 옵션을 제공합니다. llama.cpp 서버 제어 옵션.

병렬 요청을 늘리기 전에 컨텍스트 용량부터 계산합니다

시범 운영을 위한 예를 들면, 동시 요청 4개 × 요청당 컨텍스트 8,192토큰 = 32,768개 토큰 위치입니다. 이는 컨텍스트 용량이지 RAM 사용량이 아닙니다. 모델의 어텐션 상태를 저장하는 KV 캐시는 가중치와 그 밖의 작업용 할당 영역과 함께 메모리를 차지합니다. 실제 바이트 단위 사용량은 아키텍처와 캐시 정밀도에 따라 달라집니다.

앞선 예시의 호환 가능한 team-model.gguf를 사용한다면, 현재 llama.cpp 설치 환경에서는 다음과 같이 이 구성을 직접 지정할 수 있습니다.

llama serve -m ./team-model.gguf \
  --alias team-local \
  --host 127.0.0.1 --port 8080 \
  --parallel 4 \
  --kv-unified-per-slot 8192

이 값은 시범 운영을 위해 정한 설정이며, 벤치마크 결과나 프로젝트 기본값이 아닙니다. 서버 문서에 따르면 --ctx-size를 명시하지 않았을 때 공유 KV 풀의 크기는 슬롯 수에 슬롯당 한도를 곱해 정합니다. 접근 제어를 준비할 때까지는 루프백 주소에서만 시범 운영합니다.

Ollama에서는 서비스 환경에서 병렬 처리와 컨텍스트를 설정한 뒤, ollama ps로 실제 적용된 컨텍스트와 CPU/GPU 배치를 확인합니다. 별도의 컨텍스트 문서에서 하드웨어별 기본값을 설명하므로, 실제로 사용하는 할당량을 기록해야 합니다. Ollama 컨텍스트 설정.

속도는 워크로드에 따라 비교해야 합니다

프로젝트 이름만으로 모든 지연 시간·처리량 테스트에서 어느 쪽이 이긴다고 말할 수는 없습니다. 비교하기 전에 가중치, 양자화, 템플릿, 컨텍스트, 백엔드, 하드웨어 조건을 맞춰야 합니다. 그다음 대기 시간, 첫 토큰이 나올 때까지 걸리는 시간, 생성 속도, 부하가 걸린 상태에서 완료되는 요청 수를 구분해 봅니다.

사내 지원 어시스턴트가 단독 요청에 빠르게 답했다고 해서 직원들이 함께 사용할 수 있다고 입증되는 것은 아닙니다. 실제 사용을 대표하는 짧은 질문과 긴 문서 요청을 재현하고, 콜드 스타트는 별도로 포함해 측정하며, 런타임 버전과 날짜를 기록합니다. 공개된 속도 차이도 측정자, 날짜, 하드웨어, 모델, 워크로드가 명시되어 있을 때만 판단 근거로 삼습니다.

동시 처리를 목적에 맞게 튜닝해야 한다면 llama.cpp가 유리합니다. Ollama의 설정으로 서비스 목표를 충족하고, 추가 제어 기능보다 운영의 간편함이 더 중요하다면 Ollama를 유지합니다.

Apple Silicon과 Ollama GPU 지원: 하드웨어에 맞는 백엔드를 선택합니다

일반적인 워크스테이션 배포에는 Ollama가, 특수한 백엔드 제어에는 llama.cpp가 유리합니다. 둘 다 Apple GPU 가속을 지원합니다. Ollama는 Metal 지원을 문서에 명시하고 있으며, llama.cpp는 Metal, Accelerate, ARM 최적화를 활용해 Apple Silicon을 주요 지원 플랫폼으로 다룹니다. Ollama 하드웨어 지원, llama.cpp 지원 하드웨어.

Mac에서는 네이티브 애플리케이션이나 네이티브 바이너리로 시작합니다. Ollama 문서에 따르면 macOS의 Docker Desktop은 GPU 가속을 제공하지 않습니다. 따라서 잘 작동하던 네이티브 구성을 컨테이너로 옮기면, 같다고 생각했던 비교 대상의 실행 경로가 달라질 수 있습니다. Ollama의 Docker GPU 관련 주의 사항.

그 밖의 워크스테이션에 대해 Ollama는 NVIDIA 지원, ROCm을 통한 AMD 지원, 해당 백엔드 설치 시 Vulkan 지원을 안내합니다. llama.cpp는 NVIDIA용 CUDA, AMD용 HIP, Vulkan, SYCL 실행 경로를 제공하며 백엔드 선택을 위한 빌드 지침도 있습니다. 제조사 이름만 보고 지원을 확신하지 말고 운영체제, GPU, 드라이버의 정확한 조합을 확인합니다. Ollama GPU 가이드, llama.cpp 빌드 가이드.

실무에서 가장 먼저 확인할 것은 가중치의 배치입니다. GPU에 있는지, CPU에 있는지, 양쪽에 나뉘어 있는지 살펴봅니다. 모델과 컨텍스트의 조합이 할당한 메모리를 넘는다면 설정 옵션이 많아도 해결되지 않습니다. 메모리에 맞는 구성을 먼저 고른 다음, 응답 품질을 받아들일 수 있는지 판단합니다.

Muse Spark Open은 선택 기준을 어떻게 바꿀까?

Meta가 llama.cpp를 명시했다는 것은 검토할 수 있는 엔진 경로가 공식적으로 제시되었다는 뜻이며, 그 자체가 Ollama를 교체할 이유는 아닙니다. Meta는 2026년 10월 15일 Muse Spark Open 발표에서 지원 추론 엔진 중 하나로 llama.cpp를 열거했습니다. 다른 런타임에도 동등한 지원이 이미 갖춰졌다고 가정하지 않고 새 모델을 평가하려 할 때, llama.cpp를 직접 사용하는 방안을 검토할 근거가 됩니다. Meta 발표.

하드웨어 조건도 함께 봐야 합니다. Meta는 총 파라미터 816B, 활성 파라미터 42B라고 설명하며, 데스크톱 예시에서는 Apple M5 Ultra Mac Studio 두 대와 MLX를 사용합니다. 이 예시는 llama.cpp 벤치마크가 아닙니다. 활성 파라미터 수만 보고 전체 모델에 필요한 메모리 확인을 대신해서도 안 됩니다. Meta의 하드웨어 및 모델 설명.

실제 배포에서는 정확한 빌드, 모델 파일, 양자화, 템플릿, 필요한 입력 유형을 함께 검증합니다. 출시 발표에 엔진 지원이 명시되었다고 해서 설치한 Ollama 릴리스에서도 지원하거나, 일반 개발자 노트북에 모델을 올릴 수 있다는 뜻은 아닙니다. 인프라 담당자에게 새로운 평가 경로가 생겼다는 점이 실질적인 의미이며, 워크스테이션 배포는 별도로 검증해야 합니다.

Ollama에서 llama.cpp로 전환할 때는 설정도 함께 옮깁니다

마이그레이션의 핵심은 가중치를 복사하는 데 그치지 않고 기존 동작을 유지하는 것입니다. 애플리케이션의 대화 기록, 검색 인덱스, 요청 처리는 두 런타임 바깥에 있을 수 있습니다. 모델 서비스를 교체할 때도 이 경계를 명확히 유지합니다.

현재 서비스가 잘 작동하고 추가 제어 기능을 필요로 하는 사람도 없다면 전환하지 않습니다. llama.cpp로 GGUF를 준비하고 Ollama로 계속 서빙하는 방법도 있습니다. 두 프로젝트가 같은 워크플로에서 서로 다른 역할을 맡을 수 있습니다.

Ollama vs llama.cpp vs vLLM: 로컬 LLM을 워크스테이션 밖으로 확장해야 할 때는?

지속적으로 유입되는 공유 트래픽이나 분산 추론이 핵심 요구 사항이 되면 vLLM을 검토합니다. vLLM은 문서에서 연속 배칭, 캐시 관리, 분산 실행 옵션을 강조하는 서빙 엔진입니다. 전용 가속기 자원을 기반으로 서비스를 운영한다면 이런 기능을 평가할 만합니다. vLLM 문서.

연속 배칭만으로 선택지를 나눌 수는 없습니다. llama.cpp도 지원하기 때문입니다. 직원 수가 특정 기준을 넘으면 반드시 전환해야 한다는 보편적인 규칙도 없습니다. 짧은 요청이 가끔 들어오는 서비스와, 더 적은 인원이 긴 코딩 작업을 계속 보내는 서비스는 서로 다른 워크로드입니다.

판단 기준은 측정할 수 있어야 합니다. 실제 사용을 대표하는 최대 수요에서 현재 구성이 응답 목표를 충족하지 못하고, 부족한 제어 기능이나 배포 역량을 vLLM이 제공한다면 평가를 진행합니다. 현재 구성이 목표를 충족한다면 유지합니다. 이 서빙 선택은 별도의 Ollama와 vLLM 비교에서 자세히 다룹니다.

다음 업무를 시작할 때 할 일은 구체적입니다. 로컬 워크플로 하나를 고르고 모델과 컨텍스트를 고정한 뒤, 예상 동시 요청량을 정해 접근 범위를 넓히기 전에 재현해 봅니다. 그 결과로 다른 런타임이 필요한지, 아니면 설정을 개선하면 되는지 판단합니다.

자주 묻는 질문

AI 비즈니스 워크플로 점검 체크리스트로 로컬에서 운영할 가치가 있는 첫 비공개 워크플로를 고르고, 이후의 툴 변화를 받아보려면 뉴스레터를 구독합니다.