VPS에서 llama.cpp 서버 실행 및 systemd 설정 방법

구축할 내용

VPS에서 llama.cpp 서버를 실행한다는 것은 단일 바이너리인 llama-server을 사용하여 GGUF 모델 파일 하나를 로드하고, OpenAI 호환 API로 HTTP 요청에 응답하는 것을 의미합니다. 모든 OpenAI 클라이언트를 http://127.0.0.1:8080/v1로 지정하면 즉시 작동합니다. 설치는 전체 과정의 절반에 불과합니다.

나머지 작업은 운영에 관한 것입니다. 특정 버전을 고정하고, 포트를 localhost로 제한하며, systemd 유닛을 작성하고, 서버 메모리가 부족할 때 어떻게 대응할지 결정해야 합니다. 이 가이드에서 다루는 내용이 바로 이것입니다. 두 가지 주요 선택지 사이에서 아직 결정하지 못했다면, 먼저 Ollama와 llama.cpp 간의 장단점을 읽어보시기 바랍니다. 이 가이드는 해당 비교 문서에서 의도적으로 생략한 실무적인 방법을 다루기 때문입니다.

릴리스 태그를 선택하고 기록하십시오

llama.cpp는 거의 모든 병합마다 릴리스 태그를 지정하므로, 태그가 곧 빌드 번호가 됩니다. 2026년 8월 18일 기준으로 b10488이 가장 최신 버전입니다. 장기 지원 안정화 브랜치가 따로 존재하지 않으므로 "latest"는 계속 변하는 대상이며, 사용자가 테스트한 버전만이 유일하게 지원 가능한 버전이 됩니다. 태그를 하나 선택하여 기록해 두고, 클론 작업과 바이너리 이름, 그리고 메모에 동일한 문자열을 사용하십시오.

각 태그마다 미리 빌드된 아카이브도 함께 제공됩니다. CPU 전용 x86 VPS의 경우 llama-b10488-bin-ubuntu-x64.tar.gz를 사용하며, x86이 아닌 ARM VPS를 사용하는 경우에는 그 옆에 있는 arm64 아카이브를 선택하면 됩니다.

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10488/llama-b10488-bin-ubuntu-x64.tar.gz
tar tf llama-b10488-bin-ubuntu-x64.tar.gz | head

아카이브를 추출하기 전에 목록을 확인하여 파일이 어디에 위치하는지 파악하십시오. 해당 바이너리들은 빌드된 이미지의 C 라이브러리에 링크되어 있으므로, 구형 배포판에서는 설치되지 않은 GLIBC_ 버전을 가리키는 오류와 함께 실행에 실패할 수 있습니다. 소스에서 직접 빌드하면 소규모 VPS에서도 몇 분 정도면 충분하며 이러한 유형의 문제를 완전히 방지할 수 있으므로, 아래에서는 해당 방법을 따릅니다.

고정된 태그로 llama-server 빌드하기

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone --depth 1 --branch b10488 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2

--branch b10488을 --depth 1 클론에서 실행하면 해당 태그만 체크아웃되므로 작업 중에 빌드 결과가 달라지지 않습니다.

libssl-dev은 필수입니다. LLAMA_OPENSSL 옵션이 기본적으로 활성화되어 있어야 나중에 바이너리가 HTTPS를 통해 모델을 다운로드할 수 있기 때문입니다. 헤더가 없으면 구성 단계에서 실패합니다.

-DBUILD_SHARED_LIBS=OFF를 사용하면 독립적인 바이너리 하나가 생성됩니다. 기본 빌드 방식은 공유 라이브러리를 실행 파일 옆에 배치하므로, 실행 파일만 /usr/local/bin으로 복사하면 error while loading shared libraries: libllama.so 오류가 발생합니다.

-t llama-server은 서버 대상만 빌드합니다. 기본 빌드 방식은 다른 도구와 테스트까지 모두 컴파일하는데, 이는 2코어 VPS 환경에서 사용하지 않을 파일들을 빌드하느라 수 분을 낭비하게 만듭니다.

-j 2는 의도적인 설정입니다. 병렬 컴파일 작업마다 작업 세트를 점유하므로, 작은 사양의 플랜에서 -j $(nproc)을 실행하면 c++: fatal error: Killed signal terminated program cc1plus이 발생합니다. 이는 커널의 OOM(Out-of-Memory) 킬러가 컴파일러를 강제 종료하는 현상입니다. 작업 개수를 줄이거나 빌드를 위해 스왑 메모리를 추가하십시오.

변경을 고려해야 할 플래그가 하나 있습니다. GGML_NATIVE는 기본적으로 활성화되어 있어 컴파일러가 빌드를 수행하는 CPU에 최적화된 코드를 생성합니다. 해당 머신에서 직접 실행할 계획이라면 이 설정이 적합합니다. 만약 한 번 빌드한 바이너리를 다른 호스트로 복사해서 사용할 예정이라면 -DGGML_NATIVE=OFF을 추가하십시오. 대상 CPU가 지원하지 않는 명령어를 사용하는 바이너리는 첫 번째 추론 단계에서 Illegal instruction (core dumped) 오류와 함께 종료되기 때문입니다.

태그 이름이 포함된 경로에 설치하십시오.

./build/bin/llama-server --version
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-b10488
sudo ln -sfn /usr/local/bin/llama-server-b10488 /usr/local/bin/llama-server

--version는 빌드 번호와 커밋을 출력합니다. 이 값은 체크아웃한 태그와 일치해야 합니다. 일치하지 않는다면 다른 버전이 빌드된 것입니다. 파일명에 번호를 유지하고 심볼릭 링크를 연결해 두면, 업그레이드는 ln -sfn 한 번과 재시작 한 번으로 완료되며, 롤백 또한 이전 번호를 사용하여 동일한 명령어로 수행할 수 있습니다.

GGUF 모델 확보 및 디스크 용량 확인

GGUF는 llama.cpp가 불러오는 단일 파일 형식입니다. 하나의 파일에 가중치, 토크나이저, 메타데이터가 모두 포함되어 있어 별도의 설치 과정이 필요 없습니다. 파일 이름의 접미사는 양자화(quantisation) 수준을 나타내며, 이는 가중치가 저장되는 정밀도를 의미합니다. Q4_K_M은 4비트 혼합 방식이고, Q8_0은 8비트 방식이며, f16는 양자화되지 않은 반정밀도(half-precision) 파일입니다.

무언가를 다운로드하기 전에 서비스 계정과 모델 디렉터리를 먼저 생성하십시오.

sudo useradd --system --home /srv/llama --create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
df -h /srv

서버는 -hf을 사용하여 직접 모델을 가져올 수 있으며, 이는 빌드가 정상적으로 작동하는지 확인하는 가장 빠른 방법입니다.

sudo -u llama env LLAMA_CACHE=/srv/models /usr/local/bin/llama-server \
  -hf ggml-org/gemma-3-1b-it-GGUF:Q4_K_M --host 127.0.0.1 --port 8080

LLAMA_CACHE은 다운로드 디렉터리를 설정합니다. 이 설정을 하지 않으면 파일은 명령을 실행한 계정의 ~/.cache/llama.cpp 아래에 저장되는데, 이는 곧 홈 디렉터리를 읽기 불가능하게 만들 서비스에는 적합하지 않은 위치입니다. 캐시된 파일 이름은 일반 파일 이름이 아닌 저장소 이름을 기반으로 생성되므로, 다운로드 후에는 ls -lh /srv/models을 실행하십시오.

서비스의 경우, 유닛 파일이 안정적으로 참조할 수 있도록 직접 선택한 경로에 다운로드하십시오.

sudo -u llama curl -L --output-dir /srv/models -O \
  https://huggingface.co/ggml-org/gemma-3-1b-it-GGUF/resolve/main/gemma-3-1b-it-Q4_K_M.gguf

디스크 용량은 사용자가 가장 먼저 마주하는 제약 사항입니다. 다음은 2026년 8월 18일에 확인한 두 모델의 공개된 파일 크기입니다.

[
  {
    "label": "gemma-3-1b-it Q4_K_M",
    "size_gb": 0.81
  },
  {
    "label": "gemma-3-1b-it Q8_0",
    "size_gb": 1.07
  },
  {
    "label": "gemma-3-1b-it f16",
    "size_gb": 2.01
  },
  {
    "label": "gpt-oss-20b MXFP4",
    "size_gb": 12.11
  }
]

1B 모델의 4비트 파일 크기는 0.81 GB입니다. 동일한 모델을 양자화하지 않았을 경우 2.01 GB가 되므로, 형식 선택에 따라 용량이 두 배 이상 차이 납니다. MXFP4 형식의 20B 모델은 12.11 GB로, 많은 보급형 플랜의 디스크 용량을 초과하며, 이후 메모리로 읽어 들이는 과정도 필요합니다. 특정 모델군을 고려 중이라면 GLM에 대한 동일한 크기 산정 연습을 통해 상위 모델이 어떻게 빠르게 VPS 사양을 벗어나는지, 반면 작은 모델은 어떻게 적합한지 확인할 수 있습니다.

다운로드 전마다 df -h를 확인하십시오. 12 GB 전송 중에 루트 파일 시스템이 가득 차면 저널을 포함하여 쓰기 작업이 필요한 모든 서비스가 중단됩니다.

수동으로 한 번 실행하고 확인하기

sudo -u llama /usr/local/bin/llama-server \
  --model /srv/models/gemma-3-1b-it-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 4096 --parallel 1 --threads 2 --no-webui

두 번째 세션에서 서버가 준비되었는지 확인합니다.

curl -s http://127.0.0.1:8080/health

파일을 로드하는 동안에는 HTTP 503 오류와 함께 다음 본문이 반환됩니다.

{"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}

준비가 완료되면 본문은 {"status": "ok" }가 됩니다. 그런 다음 실제 요청을 보냅니다.

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"Say hello in five words."}]}'

choices 배열을 포함한 JSON 객체가 반환되면 서버가 정상적으로 작동하는 것입니다. model 필드는 OpenAI 클라이언트가 항상 전송하기 때문에 포함되어 있습니다. 이 서버에는 단일 모델만 로드되어 있으므로, 해당 값은 선택 용도로 사용되지 않습니다.

OpenAI 호환 API 및 해당 포트에서 제공하는 기타 기능

POST /v1/chat/completions, POST /v1/completions 및 POST /v1/embeddings은 OpenAI 호환 경로이며, GET /v1/models은 로드된 모델을 보고합니다. GET /health는 앞서 언급한 준비 상태 확인(readiness check)이며, GET /props은 서버의 현재 설정을 반환하고, GET /metrics는 --metrics 옵션으로 시작했을 때 Prometheus 카운터를 노출합니다.

기본 URL을 http://127.0.0.1:8080/v1으로 설정하고 비어 있지 않은 API 키 문자열을 전달하면 모든 OpenAI SDK를 사용할 수 있습니다. 사용자가 직접 --api-key을 설정하기 전까지는 해당 키를 검증하지 않습니다.

타인의 처리량(throughput) 수치를 자신의 계획에 그대로 적용하지 마십시오. CPU 추론 속도는 코어 수, 메모리 대역폭, 그리고 호스트를 공유하는 이웃 환경에 따라 달라지므로, 직접 장비에서 초당 토큰 수를 측정하고 그 결과를 사실로 받아들여야 합니다. 시끄러운 이웃으로부터 발생하는 스틸 타임(Steal time)은 시간대별로 변하는 생성 속도로 나타납니다.

127.0.0.1로 유지하고 앞에 프록시를 배치하십시오

--host은 기본적으로 127.0.0.1로 설정되어 있으므로, 변경하기 전까지는 외부에서 서버에 접근할 수 없습니다. 이 설정을 그대로 두십시오. llama-server에는 사용자 모델, 속도 제한(rate limit), 유용한 감사 로그(audit log)가 없으며, 유일한 내장 제어 기능인 --api-key은 문자열 하나를 비교하는 것이 전부입니다. 추론 포트를 외부에 개방하면 발견하는 누구에게나 무료 컴퓨팅 자원을 제공하는 꼴이 되며, Ollama에서 발생하는 실수와 동일한 양상을 보입니다. 자체 호스팅 모델 API 보안 설정에 기술된 내용은 여기에도 그대로 적용됩니다.

nginx에서 TLS(transport layer security)를 종료하고 루프백 포트로 프록시하십시오.

server {
    listen 443 ssl;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

스트리밍을 위해서는 proxy_buffering off가 필요합니다. 버퍼링이 켜져 있으면 nginx는 응답이 완료될 때까지 서버 전송 이벤트(SSE)를 붙잡아 두므로, 클라이언트는 아무런 반응 없이 대기하다가 응답 전체를 한꺼번에 받게 됩니다. proxy_read_timeout 600s은 긴 생성 작업에 대비하기 위한 설정입니다. 기본값인 60초는 느린 응답을 504 Gateway Time-out 오류로 만들기 때문입니다. Certbot과 Let's Encrypt를 이용한 nginx 설정을 통해 인증서를 발급받으십시오.

systemd 유닛

/etc/systemd/system/llama-server.service를 작성합니다.

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

[Service]
User=llama
Group=llama
Environment=LLAMA_ARG_MODEL=/srv/models/gemma-3-1b-it-Q4_K_M.gguf
Environment=LLAMA_ARG_HOST=127.0.0.1
Environment=LLAMA_ARG_PORT=8080
Environment=LLAMA_ARG_CTX_SIZE=4096
Environment=LLAMA_ARG_N_PARALLEL=1
Environment=LLAMA_ARG_THREADS=2
ExecStart=/usr/local/bin/llama-server --no-webui
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
MemoryHigh=3G
MemoryMax=3500M
OOMPolicy=stop
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

설정은 Environment= 라인에 위치합니다. llama-server은 대부분의 플래그에 대해 LLAMA_ARG_* 변수를 읽어오며, 명령줄 인수는 일치하는 변수를 덮어쓰기 때문입니다. 이를 통해 컨텍스트 크기를 변경할 위치를 한곳으로 통합하고, ExecStart를 한눈에 읽기 좋게 짧게 유지할 수 있습니다.

ProtectSystem=strict은 이 유닛에 대해 전체 파일 시스템을 읽기 전용으로 만듭니다. 서버는 모델을 읽기만 하므로 이는 적절한 설정입니다. 서비스가 -hf를 사용하여 직접 모델을 다운로드하게 하려면 ReadWritePaths=/srv/models을 추가하십시오. ProtectHome=yes은 /home와 /root를 숨깁니다. 이것이 모델을 /srv에 보관해야 하는 두 번째 이유입니다. ProtectHome이 켜져 있으면 기본 ~/.cache/llama.cpp 경로는 프로세스에서 전혀 보이지 않기 때문입니다.

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server
systemctl status llama-server
curl -s http://127.0.0.1:8080/health
journalctl -u llama-server -n 50 --no-pager

enable --now는 사람들이 흔히 건너뛰는 부분입니다. enable이 없으면 재부팅 후 서버가 사라집니다. 새로운 릴리스를 매일 밤 확인하는 것과 같이 서비스와 관련된 예약 작업을 수행하려면 systemd 서비스와 타이머를 사용하는 것이 올바른 방법입니다.

OOM 발생 전 대응 방안 결정하기

메모리 사용량은 두 부분으로 나뉘며, 제한 조건 하에서 각기 다르게 동작합니다. 모델 파일은 기본적으로 메모리 매핑(memory-mapped)되므로 파일 기반 페이지로 취급됩니다. 따라서 커널은 이 페이지를 삭제했다가 필요할 때 디스크에서 다시 읽어올 수 있습니다. 반면, 서버가 활성 대화마다 유지하는 토큰별 상태인 KV 캐시는 익명 메모리(anonymous memory)입니다. 이 영역은 삭제할 수 없으므로, 프로세스가 강제 종료되는 주원인이 됩니다.

이 때문에 유닛 파일의 두 가지 제한 설정은 서로 다른 역할을 수행합니다. MemoryHigh=3G은 소프트 리미트입니다. 이 값을 초과하면 커널은 cgroup에 회수 압력을 가하며, 매핑된 모델 페이지를 제거하고 다음 토큰 생성 시 디스크에서 다시 읽어옵니다. 서비스는 계속 작동하지만 속도가 느려집니다. MemoryMax=3500M는 하드 리미트입니다. 이 값을 초과하면 프로세스는 강제 종료되며, 저널 로그에 그 이유가 명확히 기록됩니다.

llama-server.service: A process of this unit has been killed by the OOM killer.

--ctx-size은 직접 설정해야 합니다. 기본값은 0인데, 이는 모델이 학습된 컨텍스트 길이를 의미합니다. 최신 롱 컨텍스트 모델은 시작 시 매우 큰 KV 캐시를 할당하므로, 이 설정 그대로라면 서비스가 요청을 하나도 처리하지 못한 채 종료될 수 있습니다. --parallel는 동일한 비용을 배수로 증가시킵니다. 각 슬롯이 개별 대화 상태를 유지하기 때문입니다. 동시성 처리가 반드시 필요한 상황이 아니라면 1로 유지하십시오.

Restart=on-failure을 설정하면 강제 종료된 서비스가 다시 시작됩니다. 만약 매번 시작할 때마다 종료된다면 systemd는 재시도를 포기하고 systemctl status은 start request repeated too quickly을 출력합니다. 이는 올바른 동작입니다. 12 GB 파일을 5초마다 다시 읽으며 재시작 루프를 도는 것은 서비스 중단보다 더 나쁜 상황이기 때문입니다. 제한 설정이나 컨텍스트 크기를 수정한 뒤, sudo systemctl reset-failed llama-server로 상태를 초기화하십시오.

요청이 처리되는 동안 systemctl show llama-server -p MemoryCurrent을 사용하여 실제 메모리 사용량을 모니터링하십시오. systemd를 이용한 프로세스 메모리 및 CPU 제한에서 이 지시어들에 대한 자세한 내용을 다룹니다.

이 작업 부하에는 스왑(swap) 사용을 피하십시오. 스왑된 모델은 모든 토큰 생성 과정을 무작위 오프셋 디스크 읽기 작업으로 변질시킵니다. 모델 파일을 메모리 매핑하는 것이 훨씬 효율적입니다. 커널이 필요한 페이지를 파일에서 직접 읽어오기 때문에 시스템에 주는 부담이 적습니다.

Ollama가 더 나은 선택인 경우

이 지점에서 선택이 필요합니다. 설정한 플래그, 고정된 빌드, 직접 선택한 파일을 사용하는 단일 프로세스를 원한다면 llama-server을 선택하십시오. 이 경우 다른 프로세스가 실행되지 않으므로 기반 환경이 예기치 않게 변경되지 않습니다.

모델 관리가 필요하다면 Ollama를 선택하십시오. 이름으로 모델을 내려받고, 여러 모델을 디스크에 보관하며, 유휴 모델을 메모리에서 해제하고, 재빌드 없이 단일 명령어로 업그레이드할 수 있습니다. 이는 직접 스크립트로 구현해야 할 번거로운 작업을 대신 처리해 줍니다. VPS에서 Ollama 실행하기는 동일한 작업을 다른 관점에서 접근하는 방식입니다. 두 방식 모두 OpenAI 호환 API를 제공하므로, 어떤 방향으로 전환하더라도 클라이언트 코드는 그대로 유지됩니다.

고정된 빌드 업그레이드

bNNNNN를 이동하려는 태그로 교체하십시오.

cd llama.cpp
git fetch --tags
git checkout bNNNNN
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-bNNNNN
sudo ln -sfn /usr/local/bin/llama-server-bNNNNN /usr/local/bin/llama-server
sudo systemctl restart llama-server

이전 바이너리가 디스크에 그대로 남아 있으므로, 롤백은 ln -sfn을 llama-server-b10488로 되돌리고 재시작하는 것만으로 가능합니다. 이동하기 전에 릴리스 노트를 읽어 보십시오. GGUF 파일은 버전이 관리되며 이전 파일도 계속 로드되지만, 플래그는 이름이 변경됩니다. --mlock와 --no-mmap은 이미 --load-mode로 대체되어 더 이상 사용되지 않으며, 제거된 플래그를 전달하는 유닛 파일은 시작 시 인식할 수 없는 인자 메시지와 함께 실패합니다.

실패 유형 및 확인되는 메시지

error while loading shared libraries: libllama.so 바이너리를 다른 곳으로 복사한 후에 발생합니다. 기본 빌드 설정은 바이너리 옆에 공유 라이브러리를 생성합니다. -DBUILD_SHARED_LIBS=OFF 옵션으로 다시 빌드하거나 build/bin 디렉터리 전체를 복사하십시오.

Illegal instruction (core dumped) 시작 시점이나 첫 번째 요청 시 발생합니다. 바이너리가 GGML_NATIVE 옵션으로 컴파일되었으나, 현재 실행 중인 CPU와 다른 아키텍처에서 빌드된 경우입니다. 해당 머신에서 다시 빌드하거나 -DGGML_NATIVE=OFF 설정으로 구성하십시오.

c++: fatal error: Killed signal terminated program cc1plus 빌드 중에 발생합니다. 메모리 사용량이 과도하여 컴파일러가 강제 종료된 경우입니다. -j 값을 낮추거나, 빌드 중에만 스왑 메모리를 추가한 뒤 다시 제거하십시오.

curl: (7) Failed to connect ... Connection refused 노트북에서 접속 시 발생합니다. 이는 정상적인 동작입니다. 서버가 VPS의 루프백 주소에서 대기 중이기 때문입니다. VPS 내부에서 테스트하거나 ssh -L 8080:127.0.0.1:8080 user@your-vps 명령으로 터널을 열어 로컬에서 http://127.0.0.1:8080 주소로 접속하십시오.

재시작 후 수 초에서 수 분간 "message":"Loading model"를 포함한 HTTP 503 오류가 발생합니다. 수 기가바이트 크기의 파일을 읽는 데 시간이 걸리기 때문입니다. systemd는 프로세스가 시작되는 즉시 유닛을 활성 상태로 보고하지만, 실제 모델은 메모리에 완전히 로드되기 전입니다.

요청이 응답 없이 대기하다 504 Gateway Time-out 오류를 반환함. 모델 처리가 완료되기 전에 프록시가 연결을 종료한 경우입니다. proxy_read_timeout 값을 높이고, 토큰이 생성되는 즉시 클라이언트로 전달되도록 proxy_buffering 설정을 끄십시오.

유닛이 반복적으로 재시작되다가 start request repeated too quickly 오류와 함께 중단됨. 시작할 때마다 프로세스가 강제 종료되는 경우입니다. journalctl -u llama-server 로그에서 OOM killer 관련 메시지를 확인한 후, --ctx-size 값을 낮추거나, --parallel 값을 낮추거나, MemoryMax 값을 높이십시오.

FAQ

VPS에서 llama.cpp의 server를 실행해야 합니까, 아니면 Ollama를 실행해야 합니까?

특정 빌드를 고정하고, 정확한 플래그를 전달하며, 아무것도 자동으로 업데이트하지 않는 단일 파일 형태의 모델을 유지하려면 llama-server을 실행하십시오. 모델 관리와 한 번의 명령어로 업그레이드하는 편의성이 필요하다면 Ollama를 실행하십시오. 모델을 이름으로 가져오고, 여러 모델을 디스크에 보관하며, 유휴 상태인 모델을 메모리에서 해제하는 작업은 직접 스크립트로 구현해야 하는 번거로운 일이기 때문입니다. 두 도구 모두 OpenAI 호환 API를 제공하므로, 나중에 도구를 변경하더라도 클라이언트 코드를 수정할 필요는 없습니다.

어떤 llama.cpp 버전을 고정해야 합니까?

직접 빌드하고 테스트를 마친 태그를 사용하십시오. llama.cpp는 거의 모든 병합마다 태그를 지정하며, 이름은 2026년 8월 18일 기준 최신 버전인 b10488와 같은 빌드 번호 형식을 따릅니다. 별도의 안정화 브랜치가 없으므로 "현재" 버전은 하루에도 여러 번 바뀝니다. --branch <tag>으로 복제하고, 해당 태그가 포함된 파일명으로 바이너리를 설치한 뒤 심볼릭 링크를 연결하십시오. 이렇게 하면 업그레이드와 롤백을 각각 한 번의 명령어로 수행할 수 있습니다.

llama-server에는 어느 정도의 RAM이 필요합니까?

GGUF 파일 크기에서 시작하여 KV 캐시를 더하십시오. KV 캐시는 --ctx-size 및 --parallel 슬롯 수에 따라 증가합니다. 공개된 수치는 실제 환경을 측정하는 것을 대신할 수 없습니다. 총 메모리 사용량은 모델, 양자화 방식, 허용하는 컨텍스트 길이에 따라 달라지기 때문입니다. 요청이 처리되는 동안 systemctl show llama-server -p MemoryCurrent을 실행하여 확인된 수치를 사용하십시오.

/health 엔드포인트가 왜 "Loading model"과 함께 503 오류를 반환합니까?

프로세스는 시작되었지만 모델 파일이 아직 메모리에 로드되지 않았기 때문에 서버가 {"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}를 반환하는 것입니다. 이는 재시작 후 발생하는 정상적인 현상이며, 파일 읽기 작업이 완료될 때까지 지속됩니다. 클라이언트나 프록시가 이 초기 503 응답을 치명적인 오류로 간주할 때만 문제가 됩니다. {"status": "ok" }이 반환될 때까지 /health를 폴링하십시오.

llama-server를 인터넷에 직접 노출해도 됩니까?

0.0.0.0에 바인딩하고 포트를 개방하지 마십시오. 이 서버에는 계정 관리, 속도 제한, 감사할 만한 요청 로그가 없으며, 유일한 내장 보안 기능인 --api-key은 단일 문자열을 비교하는 것이 전부입니다. 기본값인 127.0.0.1 바인딩을 유지하고, 앞에 TLS가 적용된 nginx를 배치하십시오. 또한 --api-key을 설정하여 프록시 설정 실수로 인해 모델이 외부인에게 무방비로 노출되는 상황을 방지하십시오.