VPS에서 Ollama와 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 라이브러리를 기반으로 구축된 transformer 추론의 C 및 C++ 구현체입니다. 이 프로젝트는 GGUF 파일을 읽습니다. GGUF(GGML universal file format)는 모델 실행에 필요한 가중치, 토크나이저, 메타데이터를 담고 있는 단일 파일 컨테이너입니다. 이 프로젝트는 작업별로 별도의 바이너리를 제공합니다. llama-server은 HTTP 서버이며, llama-cli는 대화형 프롬프트이고, llama-bench은 처리량을 측정합니다. 릴리스는 의미론적 버전 대신 빌드 번호로 태그가 지정됩니다. 현재 태그는 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 아래에 저장합니다. 해당 파일들은 루트 디스크에 위치하며 각각 수 기가바이트에 달하므로, 25 GB 루트 볼륨을 가진 VPS를 사용하는 경우 세 번째 다운로드로 디스크가 가득 차기 전에 pull 명령이 남기는 데이터와 모델 디렉터리를 다른 곳으로 옮기는 방법을 알아두는 것이 좋습니다.

이러한 패키징 방식이 두 프로젝트의 모든 차이점입니다. 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 환경에서는 이 선택 하나가 모델의 로드 성공 여부를 결정합니다. 하지만 크기가 결정의 전부는 아닙니다. 감당할 수 있는 크기라고 해서 반드시 사용할 가치가 있는 것은 아니기 때문입니다. 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)를 설정합니다. 자동으로 추측되는 값은 없습니다.

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분 동안 메모리에 유지된 후 언로드됩니다. 다음 요청이 들어오면 응답하기 전에 전체 파일을 디스크에서 다시 읽어야 하므로, 4.58 GiB를 다시 불러올 경우 느린 저장 장치에서는 2초 걸릴 응답이 30초까지 늘어납니다. keep-alive 시간을 길게 설정하면 지연 시간을 해결할 수 있지만 RAM을 영구적으로 점유하게 됩니다. 두 가지 모두 실제 비용이 발생하므로, 더 감당하기 쉬운 쪽을 선택하십시오. 모델을 계속 상주시키기로 결정했다면, 유휴 시간이나 재부팅 후에도 유지되도록 keep_alive 설정하기를 통해 몇 줄의 설정만으로 서버가 재시작될 때마다 수동으로 모델을 예열하는 번거로움을 덜 수 있습니다.

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 열은 토큰 생성 속도이며, 단위는 모두 초당 토큰 수입니다. 공유 vCPU 플랜에서 Q4_K_M 양자화된 8B 모델은 보통 tg에서 한 자릿수 초반의 속도를 보입니다. 프롬프트 처리가 가장 큰 병목 구간입니다. 첫 번째 출력 토큰이 나오기 전에 전체 프롬프트를 처리해야 하므로, 긴 시스템 프롬프트는 모든 요청마다 대기 시간을 추가합니다. 응답 길이는 사용자가 직접 제어할 수 있는 부분입니다. 초당 3토큰의 속도에서 600토큰을 출력하는 모델은 3분 동안 서버 자원을 점유하므로, num_predict로 출력 제한하기는 수다스러운 답변으로 인해 타임아웃이 발생하는 것을 막는 가장 저렴한 방법입니다.

CPU에서 사용 가능한 작업은 분류, 추출, 짧은 요약 또는 라우팅을 수행하는 1B에서 4B 크기의 모델입니다. 응답은 수 초 내에 도착하며 메모리 요구량도 일반적인 플랜에 적합합니다. 이 크기 범위에 대한 구체적인 예시는 VPS에서 측정된 Nemotron 3.5 Lightning을 참조하십시오. 정확한 태그, 실제 요구 RAM, GPU 없이 유지되는 속도를 확인할 수 있습니다. 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년 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 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에 바인딩되므로, 다른 호스트에서는 연결이 거부됩니다. API 앞단에 인증 기능이 없으므로, 방화벽이나 사설 네트워크 뒤에 포트가 위치한 경우에만 OLLAMA_HOST=0.0.0.0:11434를 systemctl edit ollama으로 설정하십시오.

일시 중지 후 첫 응답이 매우 느립니다. 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에 따라서도 증가한다는 점을 기억하십시오.