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는 양자화되지 않은 반정밀도 파일입니다.

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

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을 실행하여 캐시된 파일 이름을 확인하십시오. 캐시된 파일 이름은 일반 파일 이름이 아닌 저장소 이름을 기반으로 생성되기 때문입니다.

서비스를 운영할 때는 선택한 경로에 모델을 다운로드하여 unit 파일이 안정적인 경로를 참조할 수 있도록 하십시오.

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가 되므로, 형식 선택에 따라 용량이 2배 이상 차이 납니다. MXFP4 형식의 20B 모델은 12.11 GB이며, 이는 많은 보급형 플랜의 디스크 용량을 초과할 뿐만 아니라 메모리로 로드하는 과정도 필요합니다.

다운로드 전마다 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는 앞서 언급한 준비 상태 확인용 경로이고, GET /props은 서버의 현재 설정을 반환하며, GET /metrics는 --metrics 옵션으로 시작했을 때 Prometheus 카운터를 노출합니다.

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

타인의 처리량 수치를 자신의 계획에 그대로 적용해서는 안 됩니다. CPU 추론 속도는 코어 수, 메모리 대역폭, 그리고 호스트를 공유하는 이웃 환경에 따라 달라지므로, 본인의 장비에서 초당 토큰 수를 직접 측정하고 그 결과를 기준으로 삼아야 합니다. 노이즈 이웃으로 인한 스틸 타임(Steal time)은 시간대별로 변하는 생성 속도로 나타납니다.

Keep it on 127.0.0.1 and put a proxy in front

--host already defaults to 127.0.0.1, so the server is unreachable from outside until you change it. Leave it alone. There is no user model, no rate limit and no useful audit log in llama-server, and the single built-in control is --api-key, which compares one string. An open inference port is free compute for whoever finds it, and the same mistake made with Ollama has the same shape: locking down a self-hosted model API applies here line for line.

Terminate TLS (transport layer security) in nginx and proxy to the loopback port.

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 is required for streaming. With buffering on, nginx holds the server-sent events (SSE) until the response finishes, so the client waits in silence and then receives the whole answer at once. proxy_read_timeout 600s covers long generations, because the default of 60 seconds turns a slow answer into 504 Gateway Time-out. Get the certificate with Certbot and Let's Encrypt on 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를 선택하십시오. 모델을 이름으로 가져오고(pull), 여러 모델을 디스크에 보관하며, 유휴 상태인 모델을 메모리에서 해제하고, 재빌드 없이 단일 명령어로 업그레이드할 수 있습니다. 이는 직접 스크립트로 구현해야 할 번거로운 작업을 대신해 줍니다. 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 서버와 Ollama 중 무엇을 실행해야 합니까?

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

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

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

llama-server에는 RAM이 얼마나 필요합니까?

GGUF 파일 크기에서 시작하여 --ctx-size 및 --parallel 슬롯 수에 따라 증가하는 KV 캐시를 더하십시오. 공개된 수치는 사용자의 환경을 측정하는 것을 대신할 수 없습니다. 총 메모리 사용량은 모델, 양자화 방식, 허용하는 컨텍스트 길이에 따라 달라지기 때문입니다. 요청이 처리되는 동안 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에 바인딩하고 포트를 개방하지 마십시오. 이 서버에는 계정 관리 기능, 속도 제한(rate limiting), 감사할 가치가 있는 요청 로그가 없으며, 내장된 유일한 검사 기능은 단일 문자열을 비교하는 --api-key뿐입니다. 기본값인 127.0.0.1 바인딩을 유지하고, 앞에 TLS가 적용된 nginx를 배치하십시오. 또한 --api-key을 설정하여 프록시 설정 실수로 인해 모델이 모든 사람에게 공개되는 상황을 방지하십시오.