VPS에서 Ollama vs llama.cpp 선택 가이드

Ollama와 llama.cpp: 어떤 계층을 실행해야 하는가?

Ollama와 llama.cpp는 질문이 암시하는 것처럼 경쟁 관계가 아닙니다. llama.cpp는 추론 엔진으로, 모델 파일을 불러와 프롬프트를 토큰으로 변환하는 역할을 합니다. Ollama는 그 엔진 위에서 동작하는 모델 관리자이자 백그라운드 데몬, 그리고 HTTP API입니다. Ollama의 README는 여전히 llama.cpp를 추론 백엔드로 명시하고 있습니다(2026년 8월 2일 확인). 따라서 진짜 질문은 어느 것이 더 빠른가가 아니라, VPS에서 어떤 계층을 운영할 것인가입니다.

이름으로 모델을 가져오고 별도의 관리 없이 계속 작동하는 서비스가 필요하다면 Ollama를 실행하십시오. 서버 사양이 낮아 정확한 모델 파일, 컨텍스트 크기, 스레드 수를 직접 지정해야 한다면 llama.cpp를 직접 실행하십시오. 소규모 VPS에서는 이러한 설정 하나하나가 가용 메모리에 직접적인 영향을 미치기 때문입니다.

각 프로젝트의 실체

llama.cpp는 ggml 라이브러리를 기반으로 구축된 트랜스포머 추론용 C 및 C++ 구현체입니다. 이 프로젝트는 GGUF 파일을 읽습니다. GGUF(GGML universal file format)는 모델 실행에 필요한 가중치, 토크나이저, 메타데이터를 담고 있는 단일 파일 컨테이너입니다. 이 프로젝트는 작업별로 별도의 바이너리를 제공합니다. llama-server은 HTTP 서버이며, llama-cli는 대화형 프롬프트이고, llama-bench은 처리량을 측정합니다. 릴리스는 의미론적 버전(semantic version) 대신 빌드 번호로 태그가 지정됩니다. 현재 태그는 2026년 8월 2일에 게시된 b10224이며, 거의 매 영업일마다 새로운 태그가 나옵니다.

Ollama는 Go 프로그램입니다. ollama serve로 시작하는 백그라운드 데몬이 모델을 로드하고 HTTP 요청에 응답하며, 명령줄 클라이언트가 해당 데몬과 통신합니다. 두 구성 요소의 배후에는 사전 패키징된 모델을 보관하는 ollama.com 레지스트리가 있습니다. Ollama는 의미론적 버전을 사용하며, v0.32.5가 2026년 7월 27일에 릴리스되었습니다. ollama pull는 프롬프트 템플릿 및 기본 매개변수 세트와 함께 GGUF를 가져온 다음, Linux의 /usr/share/ollama/.ollama/models 아래에 저장합니다.

이러한 패키징 방식이 두 프로젝트의 모든 차이점입니다. Ollama는 양자화, 템플릿, 컨텍스트 길이를 사용자를 대신해 결정하며 기억해야 할 이름 하나만 제공합니다. 반면 llama.cpp는 아무것도 결정하지 않으며 사용자에게 플래그를 제공합니다.

축 1: 모델 및 양자화 제어

양자화는 각 가중치를 16비트나 32비트에서 4, 5, 8비트로 축소합니다. 이것이 80억 개의 파라미터를 가진 모델을 일반적인 VPS의 RAM에 올릴 수 있게 만드는 원리입니다. GGUF 명명 규칙은 패턴을 알면 읽기 쉽습니다. Q4_K_M은 4비트 K-양자화, 중간 크기를 의미합니다. 숫자가 높을수록 정밀도는 유지되지만 더 많은 메모리가 필요합니다.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

위 수치는 2026년 8월 2일 기준으로 Hugging Face의 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 저장소에 게시된 파일 크기를 바이트에서 GiB로 변환한 것입니다. 6개의 모델 빌드 중 가장 작은 것은 2.96 GiB이며, 가장 큰 것은 7.95 GiB입니다. 일반적인 기본값인 Q4_K_M은 4.58 GiB입니다. 4 GiB VPS 환경에서는 이 선택 하나가 모델의 로드 여부를 결정합니다.

llama.cpp에서는 파일명을 직접 지정하므로 사용자가 해당 행을 직접 선택하게 됩니다.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c는 토큰 단위의 컨텍스트 크기이며, -t은 스레드 수, -ngl은 GPU로 보낼 레이어의 개수(CPU 전용 장비라면 0)를 설정합니다. 자동으로 추측되는 값은 없습니다.

Ollama의 경우 양자화는 가져오는 태그에 포함되어 있으며, ollama ls을 통해 디스크에 실제로 저장된 내용을 확인할 수 있습니다. 레지스트리에 원하는 빌드가 없다면 직접 GGUF를 가져오십시오. Modelfile를 작성합니다:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

그다음 빌드하고 결과를 확인합니다:

ollama create llama31-q4 -f ./Modelfile
ollama ls

컨텍스트 길이는 사용자들이 흔히 놓치는 설정입니다. Ollama는 가용한 VRAM을 기준으로 기본값을 선택하는데, GPU가 없는 장비는 가장 작은 단위인 4096 토큰으로 설정됩니다. 20,000 토큰 분량의 문서를 보내면 모델이 확인하기도 전에 초과된 토큰이 삭제되므로, 절반만 읽은 파일에 대해 모델이 잘못된 답변을 자신 있게 내놓게 됩니다. 데몬에서 OLLAMA_CONTEXT_LENGTH을 사용하거나 Modelfile에서 PARAMETER num_ctx을 사용하여 이 값을 높이십시오. llama.cpp 역시 신뢰할 만한 기본값이 없으므로, -c를 명시적으로 설정하고 자신이 무엇을 설정했는지 파악해야 합니다.

아무도 알려주지 않는 메모리 계산법

모델 파일이 비용의 전부는 아닙니다. KV 캐시(key/value cache)는 컨텍스트의 토큰당 레이어별로 하나의 항목을 유지하며, 대화가 길어질수록 커집니다.

Llama 3.1 8B 모델로 계산해 보겠습니다. 이 모델은 32개의 레이어, 8개의 key/value 헤드, 128의 헤드 차원을 가집니다. 각 토큰은 f16 형식으로 키와 값을 각각 2바이트씩 저장하므로, 레이어당 2 x 8 x 128 x 2 = 4096바이트가 필요합니다. 32개 레이어를 합치면 토큰당 128 KiB입니다. 따라서 4096 토큰 컨텍스트는 512 MiB를, 32,768 토큰 컨텍스트는 4 GiB를 차지합니다.

결과적으로 4k 컨텍스트의 Q4_K_M 8B 모델은 가중치에 약 4.58 GiB, 캐시에 약 0.5 GiB, 그리고 런타임 자체의 메모리가 필요합니다. 4 GiB RAM에는 들어가지 않습니다. 8 GiB RAM이라면 여유 있게 수용할 수 있습니다. 동일한 8 GiB 장비에서 컨텍스트를 32k로 올리면 캐시만으로도 여유 공간이 모두 소진됩니다. 모델이 로드되는 동안 free -h으로 실시간 상태를 확인하십시오. 직접 측정하지 않은 추정치는 신뢰해서는 안 됩니다.

Ollama는 이 수치를 배가시킵니다. OLLAMA_NUM_PARALLEL의 기본값은 1이며, 모델이 필요로 하는 메모리는 이 값과 컨텍스트 길이를 곱한 만큼 확장됩니다. 두 값을 동시에 높이면 데몬은 예상보다 몇 배 더 많은 RAM을 조용히 요구하게 됩니다.

축 2: 운영해야 할 데몬

Ollama 설치 스크립트는 systemd 유닛을 작성하고, ollama 시스템 사용자를 생성하며, 서비스를 활성화합니다. 사용자는 별도의 작업 없이도 생명 주기 관리를 수행할 수 있습니다. 설정은 systemd를 통해 이루어집니다:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE 설정은 다른 곳보다 CPU 기반 VPS에서 더 중요합니다. 모델은 기본적으로 5분 동안 메모리에 유지된 뒤 언로드됩니다. 다음 요청이 들어오면 응답하기 전에 전체 파일을 디스크에서 다시 읽어야 하므로, 4.58 GiB를 다시 불러올 경우 느린 저장 장치에서는 2초 걸릴 응답이 30초까지 늘어납니다. keep-alive 시간을 길게 설정하면 지연 시간을 해결할 수 있지만, RAM을 영구적으로 점유하게 됩니다. 두 방식 모두 비용이 발생하므로, 더 감당하기 쉬운 쪽을 선택하십시오.

llama.cpp는 별도의 데몬을 제공하지 않으므로, /etc/systemd/system/llama-server.service와 같이 직접 유닛 파일을 작성해야 합니다:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now llama-server 명령으로 서비스를 활성화하십시오. 이 프로세스는 실행되는 동안 모델을 메모리에 계속 유지합니다. 유휴 상태가 되어도 모델이 언로드되지 않으므로, 다시 불러오는 지연 시간이 발생하지 않으며 서비스를 중지하기 전까지는 메모리를 반환하지 않습니다. 유닛 파일 작성이 생소하다면, VPS에서 systemd로 직접 서비스 운영하기에 설명된 패턴과 동일합니다.

축 3: 애플리케이션이 통신할 API

이 축은 범위가 크게 좁혀졌습니다. 두 프로젝트 모두 이제 OpenAI 채팅 형식을 지원하므로, 대부분의 클라이언트 라이브러리는 기본 URL만 변경하면 어느 쪽에서든 작동합니다.

Ollama는 127.0.0.1:11434에서 대기합니다. OpenAI 호환 경로는 http://localhost:11434/v1/chat/completions이며, 이와 별도로 /api/chat에서 고유 API를 유지합니다. Anthropic 호환 경로 또한 문서화되어 있습니다.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server는 127.0.0.1:8080에서 대기하며 /v1/chat/completions, /v1/completions, /v1/embeddings를 제공할 뿐만 아니라, 자체 /completion 엔드포인트와 내장 웹 UI를 제공합니다. 또한 Ollama가 제공하지 않는 운영용 경로도 노출합니다. 준비 상태 확인을 위한 /health, 로드된 모델의 설정을 위한 /props, 각 요청 슬롯의 상태를 확인하는 /slots, 그리고 Prometheus 형식의 /metrics이 있습니다. 이 서비스를 모니터링할 계획이라면, 이러한 차이점이 선택의 결정적인 기준이 될 것입니다.

두 서버 모두 기본적으로 인증 기능을 활성화하지 않습니다. 보안상의 이유로 두 서버 모두 기본적으로 루프백 주소에서만 대기합니다. SSH 터널을 통하거나 리버스 프록시 뒤에서 접근해야 하며, 11434나 8080 포트를 인터넷에 직접 노출해서는 안 됩니다.

CPU 전용 VPS의 현실적인 성능

CPU 전용 VPS는 소형 모델을 느리게 실행합니다. 이것이 솔직한 요약이며, 중요한 것은 그 한계점을 파악하는 것입니다. 설계를 시작하기 전에 먼저 측정하십시오.

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp 열은 프롬프트 처리 속도이며, tg 열은 토큰 생성 속도입니다. 단위는 모두 초당 토큰 수(tokens per second)입니다. 공유 vCPU 플랜에서 Q4_K_M 양자화된 8B 모델은 보통 tg에서 한 자릿수 초반의 성능을 보입니다. 프롬프트 처리가 가장 큰 병목 구간입니다. 첫 번째 출력 토큰이 나오기 전에 전체 프롬프트를 처리해야 하므로, 긴 시스템 프롬프트는 모든 요청마다 대기 시간을 추가합니다.

CPU에서 사용 가능한 작업: 분류, 추출, 짧은 요약 또는 라우팅을 수행하는 1B에서 4B 크기의 모델입니다. 응답은 수 초 내에 도착하며 메모리 요구량도 일반적인 플랜에 적합합니다. CPU에서 사용하기 어려운 작업: 읽기 속도 수준의 대화형 챗봇, 코딩 보조 도구, 긴 문서 작업, 또는 에이전트 루프를 통해 여러 번 연속 호출하는 작업입니다. 한 번에 4초씩 걸리는 호출을 12번 반복하는 루프는 결과물을 내놓기까지 1분이 소요됩니다.

수치가 기대에 미치지 못할 때 선택할 수 있는 두 가지 대안이 있습니다. 동시성 문제, 즉 여러 사용자가 한 모델에 동시에 접속하는 것이 문제라면 엔진 선택을 바꿔야 하며, 동시 서빙을 위한 Ollama와 vLLM 비교 문서에서 관련 내용을 다룹니다. 순수 속도가 문제라면 GPU가 탑재된 VPS를 사용하는 것이 답이며, 이 경우 -ngl가 의미를 갖게 됩니다. 어느 쪽을 선택하든 먼저 하드웨어 자체의 기준 성능을 측정하십시오. 디스크와 메모리 대역폭도 CPU만큼이나 로딩 시간에 큰 영향을 미치기 때문입니다. 반복 가능한 VPS 벤치마크를 수행하는 데 투자하는 1시간은 가치가 있습니다.

llama.cpp 설치 및 특정 빌드 버전 고정

두 프로젝트 모두 매주 업데이트되므로 배포한 버전을 기록해 두어야 합니다. 업스트림에서 제공하는 한 줄짜리 설치 명령은 현재 빌드를 설치합니다.

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

특정 빌드를 고정하려면 releases 페이지에서 미리 빌드된 tarball을 다운로드하십시오. 2026년 8월 2일 기준으로 b10224 빌드가 현재 태그입니다.

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

또는 소스 코드에서 동일한 태그를 직접 빌드할 수 있습니다.

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev은 HTTPS 기능을 위해 문서화된 필수 의존성입니다. 컴파일에는 수 분이 소요되며 가장 작은 사양의 플랜보다 더 많은 RAM을 요구합니다. 소형 서버에서 메모리가 부족하다면 더 큰 사양의 서버에서 빌드한 뒤 바이너리 파일을 복사하십시오.

Ollama 설치 및 특정 버전 고정

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

이 스크립트는 OLLAMA_VERSION을 읽어 들입니다. 따라서 오늘 새로 배포된 버전을 무조건 설치하는 대신, 검증된 특정 릴리스를 유지할 수 있습니다. v0.32.5 버전은 2026년 7월 27일에 배포되었습니다. 스크립트를 셸로 바로 전달하는 방식(pipe)을 선호하지 않는 경우를 위해 수동 설치 경로도 제공합니다.

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

수동 설치 방식은 systemd 유닛이나 서비스 사용자를 자동으로 생성하지 않으므로 직접 추가해야 합니다. VPS에서 Ollama 전체 설치 가이드에서 해당 서비스 설정 단계를 상세히 다룹니다.

실패 유형 및 표시되는 문자열

Ollama가 모델 로드를 거부합니다. ollama run은 다음과 같은 형태의 줄을 반환합니다.

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama는 로드 전에 크기를 확인하므로, 실패 원인을 즉시 알 수 있습니다. 양자화 단계를 한 단계 낮추거나, 컨텍스트 길이를 줄이거나, 더 작은 모델을 선택하십시오.

llama.cpp가 실패하지 않고 매우 느리게 작동합니다. llama.cpp는 기본적으로 GGUF를 메모리 매핑하므로 RAM보다 큰 파일도 실행은 시작됩니다. 그러면 커널이 토큰마다 디스크에서 가중치를 페이징하게 되어, 디스크 사용률이 100%에 도달하고 토큰당 생성 시간이 수 초 단위로 느려집니다. --no-mmap를 전달하여 실제 할당을 강제하면 성능 저하 대신 즉시 실패하게 만들 수 있습니다. 커널이 개입하면 dmesg에서 그 이유를 확인할 수 있습니다.

Out of memory: Killed process 1234 (llama-server)

모델 파일이 전혀 로드되지 않습니다. 엔진보다 최신 모델 제품군을 위해 빌드된 GGUF는 알 수 없는 아키텍처 이름을 명시하며 오류를 발생시킵니다.

error loading model architecture: unknown model architecture: 'qwen3next'

해결책은 다른 파일이 아닌 엔진 업그레이드입니다. 이것이 버전을 고정했을 때 치러야 할 대가이며, 빌드 번호를 기록해 두어야 하는 이유입니다. 어떤 버전에서 업그레이드하는지 파악하고 있어야 합니다.

API가 로컬에서는 응답하지만 앱에서는 응답하지 않습니다. Ollama는 127.0.0.1:11434에 바인딩되므로 다른 호스트에서는 연결이 거부됩니다. OLLAMA_HOST=0.0.0.0:11434를 통해 systemctl edit ollama을 설정하는 것은 포트가 방화벽이나 사설 네트워크 뒤에 있을 때만 수행하십시오. API 앞단에는 인증 기능이 없기 때문입니다.

일시 중지 후 첫 번째 응답이 매우 느립니다. 5분간 유휴 상태가 되어 언로드되었고 모델을 디스크에서 다시 읽어오는 중입니다. 요청 직전에 ollama ps를 실행하여 로드된 항목이 없음을 확인하십시오. OLLAMA_KEEP_ALIVE 값을 높이십시오.

그렇다면 무엇을 실행해야 할까요?

모델 관리와 OpenAI 형태의 엔드포인트를 별도의 작업 없이 사용하고 싶다면 Ollama를 실행하십시오. 첫 배포나 모델 선택이 자주 변경되는 환경에 적합한 기본 선택지입니다.

메모리가 부족하여 직접 양자화(quantisation) 수준을 선택해야 하거나, 모니터링을 위해 /health, /slots, /metrics이 필요하거나, Ollama가 제공하지 않는 플래그가 필요한 경우에는 llama.cpp를 직접 실행하십시오. 모델이 간신히 들어가는 VPS 환경에서는 llama.cpp가 정직한 선택입니다. 모델을 구동하기 위한 설정값을 Ollama가 대신 선택해 주는 대신, 사용자가 직접 세밀하게 조정할 수 있기 때문입니다.

두 가지를 모두 실행하는 것은 일반적인 방식입니다. 실험용으로는 Ollama를 사용하고, 운영 환경에 배포하여 변경할 일이 없는 단일 모델에는 llama.cpp를 사용하십시오.

FAQ

Ollama는 단순히 llama.cpp를 감싼 래퍼인가요?

비슷하지만, 해당 래퍼는 실질적인 기능을 수행합니다. Ollama의 README는 llama.cpp를 추론 백엔드로 명시하고 있습니다(2026년 8월 2일 확인). Ollama는 그 위에 모델 레지스트리, 대화 메시지를 프롬프트로 변환하는 프롬프트 템플릿, 기본 샘플링 파라미터 세트, 유휴 상태 시 모델을 메모리에서 해제하는 데몬, 그리고 HTTP API를 추가합니다. 동일한 설정에서 초당 토큰 수를 비교한다면, 사실상 같은 엔진을 비교하는 셈입니다. 실제로 선택해야 할 것은 관리 계층입니다.

CPU 전용 VPS에서는 무엇이 더 빠른가요?

두 도구 모두 같은 엔진을 공유하므로, 동일한 모델 파일, 양자화, 컨텍스트 크기, 스레드 수를 사용하면 성능은 비슷합니다. 사용자들이 보고하는 차이는 보통 엔진 자체의 차이가 아니라 컨텍스트 길이와 스레드 수 같은 기본 설정의 차이에서 비롯됩니다. 공개된 수치를 맹신하기 전에 llama-bench -m <file> -p 512 -n 128를 사용하여 직접 측정하고, 자신의 서버에서 tg 열을 비교해 보십시오.

Ollama에서 직접 만든 GGUF 파일을 사용할 수 있나요?

네, 가능합니다. 파일을 서버에 올린 뒤, 첫 줄이 FROM ./your-model.gguf로 시작하는 Modelfile 파일을 작성하십시오. 필요에 따라 num_ctx와 같은 PARAMETER 라인을 추가한 다음, ollama create your-name -f ./Modelfile를 실행하면 됩니다. ollama ls을 실행하면 레지스트리에서 내려받은 모델들과 함께 해당 모델이 목록에 나타납니다. 레지스트리에 없는 양자화 버전을 사용하려면 이 방법을 사용하십시오.

8B 모델을 구동하려면 RAM이 얼마나 필요한가요?

파일 크기, KV 캐시, 런타임 메모리를 모두 고려해야 합니다. Llama 3.1 8B의 Q4_K_M 빌드는 디스크상에서 약 4.58 GiB를 차지하며, 4096 토큰 컨텍스트는 약 512 MiB의 캐시를 추가로 요구합니다. 따라서 8 GiB RAM이면 충분하지만 4 GiB로는 부족합니다. 캐시 크기는 컨텍스트에 비례하여 증가하므로, 동일한 모델이라도 32,768 토큰 컨텍스트에서는 캐시만으로 약 4 GiB가 필요합니다. Ollama를 사용할 때는 요구 사항이 OLLAMA_NUM_PARALLEL에 따라서도 증가한다는 점을 기억하십시오.