VPS에서 Ollama와 llama.cpp 중 무엇을 써야 할까?

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

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

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

각 프로젝트의 실체

llama.cpp는 ggml 라이브러리를 기반으로 구축된 transformer 추론의 C 및 C++ 구현체입니다. 이 프로젝트는 GGUF 파일을 읽습니다. GGUF(GGML universal file format)는 모델을 실행하는 데 필요한 가중치, 토크나이저, 메타데이터를 담고 있는 단일 파일 컨테이너입니다. 이 프로젝트는 작업별로 별도의 바이너리를 제공합니다. llama-server은 HTTP 서버이며, llama-cli은 대화형 프롬프트이고, llama-bench은 처리량을 측정합니다. 현재 이 프로젝트는 시맨틱 버전(MAJOR.MINOR.PATCH)을 기준으로 릴리스를 배포하며, 2026년 10월 15일에 게시된 v0.7.0이 2026년 10월 27일 기준 최신 버전입니다. 빌드 번호가 매겨진 나이틀리 태그도 여전히 함께 배포되며 하루에도 여러 번 생성되는데, 2026년 10월 27일 기준 최신 버전은 b11913입니다.

Ollama는 Go 프로그램입니다. ollama serve로 시작하는 백그라운드 데몬이 모델을 로드하고 HTTP 요청에 응답하며, 명령줄 클라이언트가 해당 데몬과 통신합니다. 이 둘의 배후에는 사전 패키징된 모델을 보관하는 ollama.com 레지스트리가 있습니다. Ollama는 시맨틱 버전을 사용합니다. v0.32.5는 2026년 7월 27일에 배포되었고, v0.40.12는 2026년 10월 27일 00:07 UTC에 릴리스되었습니다. ollama pull은 GGUF를 프롬프트 템플릿 및 기본 매개변수 세트와 함께 가져온 다음, Linux의 /usr/share/ollama/.ollama/models 아래에 저장합니다. 해당 파일들은 루트 디스크에 위치하며 각각 수 기가바이트에 달하므로, 25 GB 루트 볼륨을 가진 VPS를 사용 중이라면 세 번째 다운로드로 디스크가 가득 차기 전에 pull 명령이 남기는 데이터와 모델 디렉터리를 다른 곳으로 옮기는 방법을 알아두는 것이 좋습니다.

이러한 패키징 방식이 두 프로젝트의 유일한 차이점입니다. Ollama는 양자화, 템플릿, 컨텍스트 길이를 사용자를 대신해 결정하고 기억하기 쉬운 하나의 이름을 제공합니다. 반면 llama.cpp는 이러한 선택 사항을 플래그로 노출하며, 설정하지 않은 값은 자동으로 기본값을 적용합니다.

축 1: 모델 및 양자화 제어

양자화는 모델의 원래 가중치인 16비트나 32비트보다 적은 비트로 가중치를 저장하며, 일반적인 GGUF 빌드는 가중치당 평균 약 4, 5, 8비트를 사용합니다. 정밀도는 파일 전체에서 균일하지 않습니다. llama.cpp의 양자화기 소스(2026년 10월 27일 확인)에 따르면, Q4_K_M 빌드는 대부분의 텐서를 4비트로 유지하지만, 출력 레이어와 절반 정도의 레이어에 있는 어텐션 값 및 피드포워드 다운 텐서에는 6비트 Q6_K를 할당하며, 노름(norm)과 같은 작은 텐서는 전혀 양자화하지 않습니다. 이것이 바로 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일에 확인하여 바이트에서 GiB로 변환한 Hugging Face의 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 저장소에 게시된 파일 크기입니다. 한 모델에 대해 6개의 빌드가 있으며, 가장 작은 것은 2.96 GiB이고 가장 큰 것은 7.95 GiB입니다. 일반적인 기본값인 Q4_K_M은 4.58 GiB입니다. 4 GiB VPS 환경에서는 이 단일 선택이 모델의 로드 여부를 결정합니다. 크기는 결정의 절반일 뿐입니다. 감당할 수 있는 크기라고 해서 반드시 사용할 가치가 있는 것은 아니기 때문이며, Q4, Q8 및 fp16이 답변 품질에 미치는 실제 영향을 확인해야 추가 기가바이트를 투자할 가치가 있는지 판단할 수 있습니다.

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). 설정하지 않으면 기본값이 적용되며, --fit은 기본적으로 활성화되어 장치 메모리에 맞게 설정되지 않은 인수를 조정합니다.

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을 사용하여 이 값을 높이십시오. 더 큰 윈도우가 필요한 작업이 하나뿐이라면 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으로 실시간 상태를 모니터링하십시오. 직접 측정하지 않은 추정치는 신뢰해서는 안 됩니다. 8B를 훨씬 넘어서는 모델을 고려한다면, CPU 전용 VPS에서의 27B 모델에 적용된 동일한 계산법을 통해 8 GB에서 64 GB까지 각 단계에서 실제로 수용 가능한 범위를 확인할 수 있습니다.

Ollama는 이 수치를 배가시킵니다. OLLAMA_NUM_PARALLEL의 기본값은 1이며, 모델이 필요로 하는 메모리는 이 값과 컨텍스트 길이를 곱한 만큼 확장됩니다. 두 값을 동시에 높이면 데몬은 예상보다 몇 배 더 많은 RAM을 조용히 요구하게 됩니다. 동일한 계산법이 동시 사용자 수의 상한선을 결정합니다. 각 동시 요청은 자신만의 KV 캐시 영역을 필요로 하며, 이것이 한 명에게는 원활하던 서버가 다섯 명에게는 멈추는 이유입니다.

축 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분 동안 메모리에 유지된 후 언로드됩니다. 다음 요청이 들어오면 응답하기 전에 전체 파일을 다시 로드해야 합니다. 커널이 페이지 캐시에 해당 파일을 유지하고 있다면 속도는 빠르지만, 이는 여유 RAM이 있을 때만 가능합니다. 다른 작업으로 인해 파일이 밀려나면 디스크에서 다시 읽어와야 하므로, 4.58 GiB를 다시 로드할 때 느린 저장 장치에서는 2초 걸릴 응답이 30초까지 늘어날 수 있습니다. keep-alive 값을 길게 설정하면 지연 시간을 해결할 수 있지만 RAM을 계속 점유하게 됩니다. 두 방식 모두 비용이 발생하므로 더 감당하기 쉬운 쪽을 선택하십시오. 모델을 상주시키기로 결정했다면, 유휴 시간과 재부팅 후에도 유지되도록 keep_alive 설정하기를 통해 몇 줄의 설정만으로 서버가 재시작될 때마다 수동으로 모델을 예열하는 번거로움을 피할 수 있습니다.

llama.cpp는 데몬이나 서비스 사용자를 제공하지 않으므로 직접 설정해야 합니다. 빌드한 llama.cpp 디렉터리에서 바이너리와 라이브러리를 /usr/local로 설치하고, llama 사용자를 생성한 뒤 모델 파일을 복사해 줍니다.

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

빌드 대신 릴리스 아카이브를 사용했다면, 아카이브 내부에 라이브러리가 바이너리와 함께 포함되어 있으므로 ExecStart이 llama-server을 가리키도록 설정하십시오. 그런 다음 /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으로 서비스를 활성화합니다. 이 프로세스는 실행되는 동안 모델을 계속 메모리에 유지합니다. 기본적으로 유휴 상태에서 언로드되지 않지만, --sleep-idle-seconds을 추가하면 서비스를 중단하지 않고도 자동으로 언로드 및 리로드할 수 있습니다. 유닛 파일 작성이 처음이라면 VPS에서 systemd로 직접 서비스 실행하기와 동일한 패턴을 따릅니다.

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

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

Ollama는 127.0.0.1:11434에서 연결을 수신한다. OpenAI 호환 경로는 http://localhost:11434/v1/chat/completions이며, 이와 함께 네이티브 API /api/chat도 제공한다. Anthropic 호환 경로도 문서화되어 있다. 이러한 경로 중 어느 것도 모델이 스스로 정보를 검색하도록 하지는 않는다. 따라서 애플리케이션에 모델의 학습 데이터보다 최신인 답변이 필요하다면 Ollama API, Open WebUI 또는 간단한 도구 루프를 통해 웹 검색을 연결하는 방법을 계획해야 한다.

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에서 수신 대기합니다. 별도의 설정이 없으면 기본 포트는 9931(2026년 10월 27일 확인)이므로, 애플리케이션이 8080을 기대한다면 명령줄에 --port를 유지하십시오. 이 서비스는 /v1/chat/completions, /v1/completions, /v1/embeddings를 제공하며, 자체 /completion 엔드포인트와 내장 웹 UI도 지원합니다. 또한 Ollama가 제공하지 않는 운영용 경로도 노출합니다. 준비 상태 확인을 위한 /health, 로드된 모델의 설정을 위한 /props, 각 요청 슬롯의 상태를 확인하는 /slots, 그리고 --metrics를 추가해야 활성화되는 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에서 한 자릿수 초반대의 속도를 보입니다. 프롬프트 처리가 가장 큰 병목 구간입니다. 첫 번째 출력 토큰이 나오기 전에 전체 프롬프트를 처리해야 하므로, 긴 시스템 프롬프트는 모든 요청에 대기 시간을 추가합니다. 응답 길이는 사용자가 제어할 수 있는 절반의 영역입니다. 초당 3토큰 속도에서 600토큰을 출력하는 모델은 생성에만 200초, 즉 3분이 넘게 걸리기 때문입니다. 따라서 num_predict로 출력 제한하기는 수다스러운 답변으로 인해 타임아웃이 발생하는 것을 막는 가장 저렴한 방법입니다.

CPU에서 사용 가능한 작업은 1B에서 4B 모델을 이용한 분류, 추출, 짧은 요약 또는 라우팅입니다. 응답은 수 초 내에 도착하며 메모리 요구량도 일반적인 플랜에 적합합니다. 특정 범위가 아닌 실제 사례를 보려면, GPU 없이 VPS에서 측정된 Nemotron 3.5 Lightning을 통해 정확한 태그, 실제 요구 RAM, 유지 속도를 확인할 수 있습니다. CPU에서 사용하기 어려운 작업은 읽기 속도에 맞춘 대화형 채팅, 코딩 보조, 긴 문서 작업, 또는 에이전트 루프를 통해 여러 번 연속 호출하는 작업입니다. 4초씩 걸리는 호출을 12번 반복하는 루프는 결과를 내놓기까지 1분이 소요됩니다. 코딩 보조가 목적이라면, 직접 호스팅하는 모델에 에이전트 연결하기를 통해 소형 로컬 모델이 유리한 작업과 호스팅된 API를 사용해야 하는 작업을 구분할 수 있습니다.

수치가 기대에 미치지 못할 때 선택할 수 있는 두 가지 대안이 있습니다. 동시성 문제, 즉 여러 사용자가 한 모델에 동시에 접속하는 상황이라면 엔진 선택을 바꿔야 하며, 동시 서빙을 위한 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

특정 빌드를 고정하려면 릴리스 페이지에서 미리 빌드된 tarball을 다운로드하십시오. 현재 이 프로젝트는 시맨틱 버전을 적용한 릴리스도 제공합니다. 2026년 10월 27일 기준 최신 버전은 v0.7.0이며, 해당 릴리스 페이지는 바이너리 파일로 nightly b11669를 가리킵니다. 2026년 10월 28일에는 v0.8.0이 뒤를 이었으며, 릴리스 페이지는 바이너리 파일로 nightly b11960을 가리킵니다. 아래 명령은 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일에 배포되었습니다. 스크립트를 셸로 바로 파이프하는 방식이 꺼려진다면 수동 설치 경로를 이용할 수도 있습니다.

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는 로드 전에 크기를 확인했으며, ollama run은 다음과 같은 형태의 줄을 반환했습니다.

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

현재 Ollama 소스 코드에는 해당 메시지가 더 이상 포함되어 있지 않습니다(2026년 10월 27일 확인). 이제 Ollama는 로드 작업을 llama-server로 넘기므로, 용량이 맞지 않는 모델은 러너(runner) 실패로 나타나며 다음과 같은 오류로 시작됩니다.

llama-server reported out-of-memory during startup
llama-server process has terminated

어떤 경우든 해결 방법은 동일합니다. 양자화 단계를 한 단계 낮추거나, 컨텍스트 길이를 줄이거나, 더 작은 모델을 선택하십시오.

llama.cpp가 실패하지 않고 매우 느리게 작동합니다. llama.cpp는 기본적으로 GGUF를 메모리 매핑하므로 RAM보다 큰 파일도 일단 시작은 됩니다. 그러면 커널이 토큰마다 디스크에서 가중치를 스왑(page in/out)하게 되고, 디스크 사용률이 100%에 고정되면서 생성 속도가 토큰당 수 초 단위로 떨어집니다. 메모리 매핑을 비활성화하려면 --load-mode none를 전달하십시오. 이 옵션은 --no-mmap를 대체했으며, 해당 옵션은 b10224 빌드에서 더 이상 사용되지 않는(deprecated) 것으로 명시되었고 현재 빌드에서는 나타나지 않습니다(2026년 10월 29일 확인). 커널이 개입할 때 dmesg을 확인하면 그 이유를 알 수 있습니다.

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

모델 파일이 전혀 로드되지 않습니다. 엔진보다 최신 모델 제품군을 위해 빌드된 GGUF는 알 수 없는 아키텍처를 가리키는 오류를 발생시킵니다. 여기서 <arch>은 파일 메타데이터에 저장된 이름입니다.

llama_model_load: error loading model: unknown model architecture: '<arch>'

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

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

일시 중지 후 첫 번째 응답이 매우 느립니다. 5분간 유휴 상태가 되어 언로드(unload)가 발생했고, 페이지 캐시에 남아 있지 않다면 디스크에서 모델을 다시 로드하는 중입니다. 요청 직전에 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년 10월 27일 확인). Ollama는 그 위에 모델 레지스트리, 대화 메시지를 프롬프트로 변환하는 프롬프트 템플릿, 기본 샘플링 매개변수 세트, 유휴 상태 시 모델을 메모리에서 해제하는 데몬, 그리고 HTTP API를 추가합니다. 동일한 설정에서 초당 토큰 수를 비교한다면, 이는 사실상 같은 엔진을 비교하는 것과 같습니다. 실제로 선택해야 할 것은 관리 계층입니다.

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

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

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

네, 가능합니다. 서버에 파일을 두고 첫 줄이 FROM ./your-model.gguf으로 시작하는 Modelfile를 작성하십시오. 필요한 PARAMETER 줄(예: num_ctx)을 추가한 뒤 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에 따라서도 확장된다는 점을 기억하십시오.