VPS에서 Ollama로 LLM 직접 호스팅하는 방법

구축할 시스템

직접 소유한 서버에서 실행되는 단일 오픈 웨이트 언어 모델을 HTTP API를 통해 응답받고, 필요하다면 브라우저의 채팅 페이지를 통해 이용하는 환경입니다. Ollama는 모델을 다운로드하고 메모리에 로드하며 http://127.0.0.1:11434에서 요청을 처리하는 역할을 합니다. 설치는 명령어 한 줄로 완료됩니다. 어려운 부분은 다른 곳에 있습니다. VPS의 RAM 용량에 맞는 모델을 선택하는 것과, 인증되지 않은 추론 서버를 인터넷 전체에 실수로 공개하지 않는 것이 중요합니다.

먼저 두 가지 주의 사항을 알려드립니다. CPU 전용 VPS는 작은 모델도 느리게 실행하며, API에는 기본 제공되는 인증 기능이 전혀 없습니다. 두 가지 모두 아래에서 자세히 다룹니다. 이 부분에서 문제가 자주 발생하기 때문입니다.

모델 크기 산정의 현실적인 수치

모델의 메모리 점유율은 대략 파일 크기에 런타임 오버헤드 약 1GB를 더하고, 여기에 컨텍스트 윈도우를 위한 추가 메모리를 합산한 값입니다. llama3.2:3b, llama3.1:8b, mistral:7b을 포함한 대부분의 인기 있는 Ollama 모델의 기본 태그는 4비트 양자화(Q4_K_M)가 적용되어 있으며, 이는 파라미터 10억 개당 약 0.5GB의 RAM을 사용합니다. 모든 기본 모델이 Q4인 것은 아닙니다. smollm2:135m과 같은 아주 작은 모델은 16비트로 제공되므로, 계산하기 전에 모델 라이브러리 페이지에서 양자화 정보를 확인하십시오. 산술 계산은 간단하며, 이 계산이 모든 것을 결정합니다. 마지막 항목은 사용자가 직접 설정하는 값입니다. Ollama의 작은 기본값을 넘어 num_ctx를 높이면 더 긴 프롬프트를 입력할 수 있는 공간이 확보되지만 RAM 내 KV 캐시가 커지므로, 모델이 적합한지 판단하기 전에 컨텍스트 길이를 먼저 결정하십시오.

llama3.2:3b와 같은 3B 모델은 다운로드 크기가 약 2GB이며 실행을 위해 약 4GB의 여유 RAM이 필요합니다. mistral:7b 또는 llama3.1:8b와 같은 7B 또는 8B 모델은 디스크에서 약 5GB를 차지하며 약 8GB의 RAM을 요구하고, 16GB 정도면 원활하게 작동합니다. 13B 또는 14B 모델은 대략 16GB의 RAM이 필요합니다. 30B에서 70B 범위의 모델은 대용량 RAM을 갖춘 서버나 현실적으로 GPU가 필요합니다. CPU 기반 VPS에서는 모델이 메모리에 올라가지 않거나, 응답 속도가 너무 느려 사용할 수 없습니다.

다음은 사람들이 과소평가하는 속도 문제입니다. CPU 추론은 클럭 속도가 아닌 메모리 대역폭에 의해 제한되며, 공유 vCPU VPS는 대역폭이 낮습니다. 초당 한 자릿수에서 낮은 두 자릿수의 토큰 처리 속도를 예상하십시오. 7-8B Q4 모델은 초당 4~10개의 토큰을, 3B 모델은 10~25개의 토큰을 처리할 수 있습니다. GPU는 이보다 약 10배 정도 빠릅니다. 이 수치들은 의도적으로 대략적인 값으로 제시되었습니다. 가장 정직한 방법은 아래의 실행 단계에서 설명하는 것처럼 직접 서버에서 측정하는 것입니다. 이 글을 포함한 어떤 문서의 수치보다 본인의 eval rate를 신뢰하십시오.

실질적인 결론은 다음과 같습니다. CPU에서 작은 양자화 모델을 사용하는 것은 속도를 감수할 수 있다면 초안 작성, 요약, 분류 작업에 충분히 유용합니다. 더 크거나 빠른 모델이 필요하다면 GPU 인스턴스 비용을 예산에 반영하십시오. 특정 모델에 대해 이러한 계산 과정을 처음부터 끝까지 확인하고 싶다면, VPS에서 Nemotron 3.5 Lightning 실행하기를 참조하십시오. 어떤 태그를 가져와야 하는지, 실제 필요한 RAM은 얼마인지, CPU만으로 충분한지 확인할 수 있습니다.

특정 모델과 특정 서버의 사양을 비교하려면, 여기에서 메모리 점유율을 추정하십시오.

Ollama 설치

깔끔한 방법은 두 가지가 있습니다. 베어메탈 VPS에서는 공식 스크립트를 사용하는 것이 가장 간단합니다.

curl -fsSL https://ollama.com/install.sh | sh

curl -fsSL https://ollama.com/install.sh | sh

이 스크립트는 ollama이라는 시스템 사용자를 생성하고, /usr/local/bin/ollama 경로에 바이너리를 설치하며, 부팅 시 자동으로 시작되어 127.0.0.1:11434 포트에 바인딩되는 ollama.service라는 이름의 systemd 서비스를 등록합니다. 서비스가 정상적으로 실행 중인지 확인하십시오.

systemctl status ollama
ollama --version

systemctl status ollama.service

이미 Docker를 사용 중이라면 컨테이너를 대신 사용하십시오.

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

docker run -d -v ollama:/root/.ollama -p 127.0.0.1::11434 --name ollama ollama/ollama

포트 매핑 앞에 붙은 127.0.0.1: 접두사에 유의하십시오. 이 설정은 포트를 localhost에만 바인딩합니다. 대신 -p 11434:11434를 입력하면 모든 인터페이스에 포트가 공개되는데, 이는 보안 섹션에서 경고하는 실수입니다. 설치 방법 중 하나만 선택하십시오. 스크립트와 컨테이너를 동시에 실행하면 두 프로세스가 포트를 점유하려고 충돌하므로 주의해야 합니다.

첫 번째 모델 가져오기 및 실행

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull은(는) 모델 레이어를 디스크로 다운로드합니다(이 모델의 경우 약 2 GB). run은(는) 해당 레이어를 메모리에 로드하고 >>> 프롬프트를 표시합니다. 질문을 입력하십시오. 가중치가 디스크에서 RAM으로 로드되는 동안 첫 번째 토큰이 생성되기까지 몇 초가 걸릴 수 있으며, 이후 답변이 스트리밍됩니다. 채팅을 종료하려면 /bye를 입력하십시오. Ollama는 백그라운드에서 계속 실행됩니다.

로드된 항목과 메모리 점유 상태를 확인하십시오:

ollama ps

PROCESSOR 열이 실제 상태를 나타냅니다. 100% CPU은(는) GPU가 사용되지 않음을 의미하며, 이것이 속도 저하의 원인입니다. verbose 플래그를 사용하여 실제 속도를 측정하십시오:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

마지막에 출력되는 eval rate 줄은 현재 하드웨어에서의 초당 토큰 처리량입니다. 이 수치를 기준으로 계획을 세우십시오.

모델 저장 위치 및 디스크 용량 산정

스크립트로 설치되어 서비스로 실행되는 모델은 ollama 사용자의 홈 디렉터리에 저장됩니다.

sudo du -sh /usr/share/ollama/.ollama/models

사용자 계정으로 직접 실행할 경우 모델은 ~/.ollama/models에 위치합니다. 컨테이너 환경에서는 ollama라는 이름의 볼륨에 저장됩니다. 양자화된 가중치 파일은 용량이 빠르게 증가하므로 주의해야 합니다. 3B 모델은 약 2 GB, 7-8B 모델은 약 5 GB, 14B 모델은 약 9 GB를 차지합니다. 모델 4개를 내려받아 비교하다 보면 어느새 20 GB를 사용하게 됩니다. 유지할 모델의 크기를 고려하여 디스크 용량을 산정하고, 필요 없는 모델은 ollama rm <model> 명령어로 삭제하십시오. 만약 동일한 VPS에서 사진 라이브러리를 관리하는 PhotoPrism이나 Immich와 같이 디스크를 많이 사용하는 서비스를 이미 운영 중이라면, 해당 용량을 전체 가용 공간에서 먼저 제외한 뒤 남은 공간을 실제 모델용 예산으로 계산해야 합니다.

제어 가능한 서비스로 실행하기

설치 스크립트가 이미 ollama.service을(를) 등록했으므로, 별도의 작업 없이도 부팅 시 자동으로 다시 시작됩니다. 변경할 가치가 있는 설정은 모델이 메모리에 상주하는 시간이며, 일부 환경에서는 바인딩 주소도 설정해야 합니다. 두 설정 모두 systemd 드롭인 파일에 작성하여 Ollama 업그레이드 시 설정이 덮어쓰이지 않도록 합니다.

sudo systemctl edit ollama.service

편집기에 표시되는 [Service] 헤더 아래에 다음 내용을 추가합니다.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE은(는) 마지막 요청 이후 모델이 메모리에 유지되는 시간(기본값 5분)입니다. 하루 종일 쿼리를 수행하는 서버라면 매번 가중치를 다시 불러오지 않도록 이 값을 높이십시오. 리소스가 부족한 서버라면 요청이 끝나는 즉시 RAM을 확보할 수 있도록 0로 설정하십시오. 고정된 시간 동안이 아니라 모델을 계속 상주시키고 싶다면, Ollama 모델을 계속 로드된 상태로 유지하기에서 요청별 keep_alive 필드와 재부팅 후 첫 번째 느린 요청 대신 가중치를 미리 로드하는 방법을 다룹니다. systemctl edit은(는) 유닛 파일을 다시 불러오므로, 변경 사항을 적용하려면 서비스를 다시 시작하십시오.

sudo systemctl restart ollama

가장 중요한 보안 사항

기본적으로 Ollama는 127.0.0.1:11434에 바인딩되므로 VPS 내부의 프로세스만 접근할 수 있습니다. 이 기본 설정은 올바르며, 그대로 유지해야 합니다.

이 API에는 인증 기능이 없습니다. 전혀 없습니다. API 키도, 로그인도, 속도 제한도 없습니다. 유일하게 존재하는 허용 목록인 OLLAMA_ORIGINS은 어떤 브라우저 출처가 API를 호출할 수 있는지(CORS)만 제어할 뿐, 다른 기기에서 실행되는 curl이나 스크립트의 접근을 막지는 못합니다. 포트 11434에 접근할 수 있는 사람은 누구나 사용자가 내려받은 모델을 실행하거나, 새로운 모델을 내려받거나, 삭제할 수 있으며, CPU나 GPU를 무기한 최대 부하 상태로 만들 수 있습니다. Shodan과 같은 스캐너는 수천 개의 열린 Ollama 인스턴스를 색인화하며, 노출된 인스턴스는 몇 시간 내에 발견되어 악용됩니다.

따라서 절대 하지 말아야 할 단 하나의 실수는 OLLAMA_HOST=0.0.0.0를 설정하고 방화벽에서 11434 포트를 여는 것입니다. 이는 인증되지 않은 추론 서버를 전 세계 인터넷에 공개하는 행위입니다. Ollama의 문서화된 설정 중 로컬 API에 인증을 추가하는 기능은 없으며, 출처 허용 목록은 로그인이 아니기 때문에 0.0.0.0에서 11434 포트를 직접 노출하는 것은 어떤 설정을 하더라도 안전하지 않습니다. 이는 특정 서비스에 대한 규칙일 뿐, 포트를 절대 열지 말라는 의미는 아닙니다. 원격 데스크톱을 위한 자체 호스팅 RustDesk 릴레이는 제 기능을 수행하기 위해 공개 트래픽을 허용해야 하지만, 자체적인 키 기반 인증과 문서화된 짧은 포트 목록을 갖추고 있습니다. Ollama에는 이러한 기능이 전혀 없습니다.

서버 외부에서 모델에 접근하는 안전한 방법은 세 가지입니다.

• 로컬 환경 유지: 호출자가 동일한 VPS 내의 다른 프로그램, cron 스크립트, 봇, 또는 도구와 모델을 연결하는 MCP 서버뿐이라면, 바인딩을 127.0.0.1으로 유지하고 해당 프로그램이 http://127.0.0.1:11434을 호출하게 하십시오. 아무것도 노출되지 않으며 추가적인 조치도 필요 없습니다.
• 사설 터널을 통한 접근: VPS를 직접 호스팅하는 WireGuard VPN에 연결하고, OLLAMA_HOST을 터널 주소(예: 0.0.0.0이 아닌 10.8.0.1)로 설정하십시오. 그러면 VPN 피어만 연결할 수 있습니다. 공개 인터넷에서는 11434 포트가 보이지 않습니다.
• 인증 기능을 갖춘 리버스 프록시 사용: nginx, Traefik 또는 Caddy에서 TLS를 종료하고 비밀번호나 토큰을 요구하도록 설정한 뒤, 127.0.0.1:11434로 프록시하십시오. Ollama는 localhost 바인딩을 유지하며, 공개 포트에서 대기하는 것은 프록시뿐입니다. 이는 로컬 서비스 앞에 Let's Encrypt 인증서를 적용한 nginx를 두는 것과 동일한 구조입니다.

리버스 프록시 옵션은 다음 단계에서 다룰 채팅 UI가 제공하는 방식이며, 실제 로그인 기능이 포함되어 있습니다.

TLS를 적용한 Open WebUI 채팅 인터페이스 추가

Open WebUI는 자체 호스팅이 가능한 채팅 인터페이스입니다. Docker에서 실행하고 로컬 Ollama를 가리키도록 설정하십시오:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Linux VPS 환경에서는 --network=host 플래그가 핵심입니다. 이 플래그는 컨테이너를 호스트의 네트워크 네임스페이스에 배치하므로, 컨테이너 내부의 127.0.0.1은 호스트 자신의 루프백이 됩니다. 따라서 Ollama가 다른 인터페이스에서 대기 중이지 않아도 컨테이너는 127.0.0.1:11434를 통해 Ollama에 접근할 수 있습니다. 다른 곳에서 볼 수 있는 --add-host=host.docker.internal:host-gateway와 OLLAMA_BASE_URL=http://host.docker.internal:11434을 사용하는 브리지 네트워크 방식은 여기에서 작동하지 않습니다. 해당 이름은 Docker 브리지 게이트웨이로 해석되는데, 호스트의 127.0.0.1에 바인딩된 서비스는 브리지를 통해 접근할 수 없기 때문입니다. 결과적으로 Open WebUI는 Ollama에 연결할 수 없다는 메시지만 출력하게 됩니다.

호스트 네트워크 모드의 단점은 Open WebUI가 이제 모든 인터페이스의 호스트 포트 8080에서 대기하게 된다는 점입니다. 모든 -p 매핑은 무시되며, Docker는 이에 대한 경고를 출력합니다. 따라서 호스트와 제공업체의 방화벽에서 8080 포트를 닫고, TLS 리버스 프록시만 유일한 외부 통로가 되도록 설정하십시오. 첫 접속 시 Open WebUI는 관리자 계정 생성을 요청합니다. 이 계정이 인증 계층 역할을 하므로 강력한 암호를 선택하십시오.

노트북에서 HTTPS를 통해 채팅에 접속하려면 127.0.0.1:8080 앞에 TLS 리버스 프록시를 배치하십시오. 이미 서버에서 여러 Docker 애플리케이션을 운영 중이라면 여러 앱에 걸쳐 자동 TLS를 지원하는 Traefik 설정이 가장 깔끔합니다. 단 하나의 라벨 블록으로 인증서를 발급하고 chat.example.com를 Open WebUI로 라우팅할 수 있습니다. 이러한 앱별 라벨 라우팅 방식은 상태 대시보드나 90년대 비디오 대여점처럼 Jellyfin 라이브러리를 보여주는 Halcyon과 같이 재미있는 서비스 등, 서버의 모든 브라우저 기반 프론트엔드에 동일하게 적용할 수 있습니다. 각 서비스는 고유한 호스트 이름을 가지며 개별 로그인 뒤에 위치합니다. 보안 섹션에서 언급한 규칙은 여전히 유효합니다. 프록시가 공용 포트와 로그인을 관리하고, Ollama는 localhost에 머물며, Open WebUI의 자체 8080은 방화벽으로 보호되어야 합니다.

코드에서 OpenAI 호환 엔드포인트 사용하기

Ollama는 /v1에서 OpenAI 채팅 API의 일부를 지원하므로, 기본 URL과 임의의 키 두 가지만 변경하면 대부분의 OpenAI 클라이언트 라이브러리를 그대로 사용할 수 있습니다.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

api_key는 클라이언트 라이브러리에서 요구하지만 Ollama는 이를 무시하므로 어떤 문자열을 입력해도 상관없습니다. model은 이미 pull을 완료한 모델 이름이어야 합니다. 존재하지 않는 이름을 입력하면 model 'x' not found과 함께 404 오류가 반환됩니다. 일반적인 curl 호출도 같은 원리로 작동합니다.

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

이 방식을 통해 모델을 에이전트 및 에디터 도구에 연결할 수 있습니다. 이미 해당 서버에서 개발 중이라면, 로컬 모델을 사용하여 스크립트나 플러그인을 구동할 수 있습니다. tmux 내부의 VPS에서 실행되는 Claude Code와 함께 사용하면, 복잡한 추론은 호스팅된 모델에 맡기고 간단한 초안 작성 작업은 비용이 들지 않는 비공개 로컬 모델로 처리하여 효율을 높일 수 있습니다.

실패 유형 및 확인 가능한 정확한 문자열

프로세스가 생성 도중 "Killed"되는 경우. 대규모 모델을 시작할 때 터미널에 Killed가 출력되거나, 서버 로그(journalctl -u ollama)에 llama-server process has terminated로 시작하는 줄이 나타납니다. 이는 2026년 10월 21일에 확인한 Ollama 0.40.7 버전의 문구이며, 이전 릴리스에서는 llama runner process has terminated: signal: killed라고 표시되었습니다. 모델이 시스템의 물리적 RAM보다 더 많은 메모리를 요구하여 Linux OOM killer가 프로세스를 중단시킨 것입니다. sudo dmesg | grep -i oom를 통해 원인을 확인하면 Out of memory: Killed process ...와 같은 줄을 볼 수 있습니다. 해결 방법은 더 작거나 더 많이 양자화된 모델을 사용하는 것(13B 대신 llama3.2:3b 사용), 또는 물리적 RAM을 약간 초과하는 부하가 즉시 종료되지 않고 느리게나마 유지되도록 스왑(swap)을 추가하는 것입니다. 스왑은 즉각적인 충돌을 느린 응답으로 바꿀 뿐이며, 4 GB RAM에서 70B 모델을 실용적으로 사용할 수 있게 만들지는 못합니다. 터미널을 보고 있지 않으면 종료 사실을 알 수 없으므로, 외부에서 쿼리하는 서버라면 OnFailure= 유닛을 ollama.service에 연결하여 직접 호스팅하는 ntfy 서버로 푸시 알림을 보내도록 설정하십시오. 그러면 다음 요청 시점에 종료 사실을 발견하는 대신 즉시 알 수 있습니다.

Ollama가 모델 로드를 거부하는 경우. 요청이 충돌하지 않고 즉시 오류와 함께 실패하며, 서버 로그에 model is too large for system memory가 기록됩니다(2026년 10월 21일 확인된 Ollama 0.40.7 기준). 이전 릴리스에서는 프롬프트에 Error: model requires more system memory (X GiB) than is available (Y GiB)이 출력되었습니다. 이는 앞서 언급한 충돌의 정중한 버전으로, Ollama가 연산을 수행한 뒤 OOM killer가 개입하기 전에 스스로 중단한 것입니다. 사용 가능한 RAM(free -h로 확인)보다 요구 사항이 적은 모델을 선택하거나, 컨텍스트 길이를 줄이거나, 더 큰 VPS로 이동하십시오. 메모리는 물리적인 자원이므로 모델을 강제로 맞추는 플래그는 없습니다.

첫 번째 토큰이 매우 느리게 생성된 후 정상화되는 경우. 모델이 처음 로드될 때 5초에서 30초 동안 아무것도 출력하지 않다가 이후 정상적으로 스트리밍됩니다. 이 지연은 가중치가 디스크에서 RAM으로 처음 로드되는 과정이며, 저장 장치가 느리면 더 심해집니다. 일단 로드되면 모델은 OLLAMA_KEEP_ALIVE 동안 상주하므로 두 번째 프롬프트는 즉시 응답합니다. 첫 로드 시간이 호출 경로상의 타임아웃보다 길어지면 느린 응답 대신 오류가 발생하며, 어떤 계층에서 context deadline exceeded를 보고했는지 파악하면 클라이언트, 프록시, 또는 로드 자체 중 어디에서 인내심이 바닥났는지 알 수 있습니다. 지연이 불편하다면 해당 값을 높이고, ollama ps을 사용하여 모델이 현재 로드되어 있는지 확인하십시오.

전반적으로 속도가 느린 경우. 오류 없이 초당 10 토큰 이하로 생성됩니다. 이는 CPU 추론이 본래 수행하는 방식입니다. ollama ps를 실행하면 100% CPU가 표시되는데, 이는 GPU가 없음을 의미합니다. 이는 버그가 아니며, 주된 제한 요소가 메모리 대역폭이기 때문에 설정을 변경한다고 CPU가 GPU가 되지는 않습니다. 다만 VM 환경에서는 한 가지 설정을 테스트해 볼 가치가 있습니다. Ollama는 감지된 물리적 코어 수를 기반으로 스레드 수를 선택하는데, 하이퍼바이저가 이를 잘못 보고할 수 있습니다. ollama run --verbose 세션에서 /set parameter num_thread 4(또는 vCPU 개수)을 시도하고 동일한 프롬프트를 다시 실행하여 가장 좋은 eval rate 값을 보이는 설정을 유지하십시오. 그 외에는 더 작은 모델을 사용하거나, 속도를 감수하거나, GPU 인스턴스로 이동하십시오. 무언가 고장 났다고 판단하기 전에 --verbose로 실제 속도를 측정하십시오. 응답 속도가 아니라 응답 길이 때문에 대기가 발생하는 것이라면, num_predict로 응답을 제한하여 장황한 모델이 읽지 않을 토큰을 생성하며 시간을 낭비하지 않도록 하십시오.

다른 기기에서 연결이 거부되는 경우. 노트북에서 현재 curl(2026년 10월 21일 확인된 8.23.0 버전)을 실행하면 curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server이 출력되고, Ubuntu 24.04에 포함된 curl 8.5.0은 curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server을 출력합니다. "Connection refused"라는 문구는 -v를 추가했을 때만 connect to <ip> port 11434 from ... failed: Connection refused이라는 줄로 나타납니다. 이는 의도된 동작으로, Ollama는 localhost에만 바인딩됩니다. 이를 해결하기 위해 0.0.0.0에 바인딩하지 마십시오. 이는 앞서 언급한 노출 실수와 정확히 일치합니다. VPN을 통하거나 인증 프록시를 거쳐 모델에 접근하십시오.

11434 포트를 인터넷에 노출한 경우. 만약 OLLAMA_HOST=0.0.0.0를 설정하고 방화벽을 열어 두어, 시작하지 않은 모델 풀(pull)이 발생하거나 알 수 없는 클라이언트에 의해 CPU 점유율이 100%에 도달한다면, 외부 공격자에게 발견되어 악용되고 있는 것입니다. 이는 가장 눈에 띄는 실수이며, 예외적인 상황이 아닙니다. 127.0.0.1 또는 VPN 주소로 다시 바인딩하고, 방화벽에서 11434 포트를 닫은 뒤, 앞에 인증을 추가하십시오. 해당 주소가 열려 있는 동안 접근 가능했던 모든 것은 외부인이 쿼리했을 가능성이 있다고 가정해야 합니다.

백업 및 업그레이드

손실될 상태 정보는 거의 없습니다. 모델은 다시 다운로드할 수 있으므로, 백업할 가치가 있는 것은 Open WebUI의 데이터 볼륨, 계정, 대화 기록, 설정, 그리고 작성한 systemd 드롭인 파일뿐입니다. 일회용 컨테이너를 사용하여 볼륨을 백업하십시오:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

설치 스크립트를 다시 실행하여 Ollama를 업그레이드하고, docker pull ghcr.io/open-webui/open-webui:main를 실행한 뒤 컨테이너를 다시 생성하여 Open WebUI를 업그레이드하십시오. 0.40 버전 라인에 대한 디스크 관련 참고 사항입니다: Ollama 0.40.2는 이전 버전에서 내려받은 모델을 백그라운드에서 업그레이드하기 시작했으며, 원본을 백업으로 유지합니다. 따라서 삭제하기 전까지는 추가 디스크 공간을 차지합니다. 0.40.3(2026년 10월 11일) 버전에서는 해당 백그라운드 업그레이드가 일시 중지되었습니다. 업그레이드 후 df -h을 확인하고, 해당 백업을 삭제하는 명령은 릴리스 노트를 참조하십시오. 모델 품질과 런타임 모두 빠르게 변화하므로 장기적으로 버전을 고정하지 마십시오. 지난 분기의 수치를 신뢰하기보다는 릴리스 노트를 읽고 자신의 장비에서 직접 벤치마크를 수행하십시오.

FAQ

CPU 전용 VPS에서 LLM을 실행할 수 있습니까?

네, 제한적이지만 가능합니다. 3B에서 8B 범위의 작은 양자화 모델은 CPU에서 실행할 수 있으며 초안 작성, 요약, 분류 작업에 충분히 유용합니다. 다만 공유 vCPU 환경에서는 초당 한 자릿수에서 낮은 두 자릿수 정도의 토큰 속도로 매우 느리게 동작합니다. 13B 이상의 모델은 속도가 매우 느리거나 RAM 용량 부족으로 실행되지 않을 수 있습니다. 실질적인 속도나 더 큰 모델을 사용하려면 GPU 인스턴스가 필요합니다.

모델마다 RAM이 얼마나 필요합니까?

가장 대중적인 4-bit (Q4) 양자화 모델을 기준으로 대략적인 규칙은 다음과 같습니다. 가중치(weights)를 위해 파라미터 10억 개당 약 0.5 GB의 RAM이 필요하며, 여기에 오버헤드 약 1 GB와 컨텍스트를 위한 추가 메모리가 필요합니다. 따라서 3B 모델은 약 4 GB, 7-8B 모델은 약 8 GB, 14B 모델은 약 16 GB의 여유 RAM이 필요합니다. free -h 명령으로 가용 메모리를 확인하고 운영체제 및 기타 프로세스를 위한 여유 공간을 확보하십시오.

Ollama API는 인증을 지원합니까?

아니요. Ollama는 내장 인증, API 키, 속도 제한 기능을 제공하지 않으므로 포트 11434에 접근할 수 있는 사람은 누구나 제어권을 가집니다. Ollama의 OLLAMA_ORIGINS 설정은 호출 가능한 브라우저 출처만 제한할 뿐, 연결 주체를 제한하지는 않습니다. 바로 이러한 이유로 기본적으로 127.0.0.1에 바인딩되며, 11434 포트를 0.0.0.0을 통해 인터넷에 직접 노출해서는 안 됩니다. 로컬에서 접근하거나, 사설 VPN을 통하거나, 인증 기능을 추가한 리버스 프록시를 거쳐야 합니다.

웹 채팅 인터페이스는 어떻게 추가합니까?

--network=host 옵션을 사용하여 Docker에서 Open WebUI를 실행하십시오. 이렇게 하면 호스트의 루프백을 공유하여 http://127.0.0.1:11434에서 로컬 Ollama에 접근할 수 있습니다. 그 후 포트 8080 앞에 TLS 리버스 프록시를 배치하여 외부에서 접속하십시오. 방화벽에서 8080 포트는 닫아두어 프록시만 유일한 외부 통로가 되도록 설정해야 합니다. Open WebUI 자체 관리자 계정으로 로그인을 처리하며, 최초 실행 시 비밀번호를 설정하게 됩니다.

제 애플리케이션에서 어떻게 호출합니까?

http://127.0.0.1:11434/v1에 있는 OpenAI 호환 엔드포인트를 사용하십시오. OpenAI SDK의 기본 URL을 해당 주소로 지정하고, API 키는 무시되므로 아무 문자열이나 입력하십시오. 그런 다음 model을 이미 다운로드한 모델 이름으로 설정하십시오. 기존 OpenAI 코드는 기본 URL과 키만 변경하면 대부분 그대로 작동합니다.