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

구축할 시스템

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

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

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

모델의 메모리 점유율은 대략 파일 크기에 런타임 오버헤드 약 1 GB를 더하고, 컨텍스트 윈도우를 위한 추가 메모리를 합산하여 결정됩니다. Ollama의 기본 모델은 4비트 양자화(Q4)가 적용되어 있으며, 이는 파라미터 10억 개당 약 0.5 GB의 RAM을 소모합니다. 따라서 산술은 간단하며, 이 수치가 모든 것을 결정합니다.

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

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

실질적인 결론은 다음과 같습니다. CPU에서 구동하는 소형 양자화 모델은 속도를 감수할 수 있다면 초안 작성, 요약, 분류 작업에 충분히 유용합니다. 더 크거나 빠른 모델이 필요하다면 GPU 인스턴스 비용을 예산에 반영해야 합니다.

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

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을(를) 등록했으므로, 별도의 작업 없이도 부팅 시 자동으로 다시 시작됩니다. 변경할 가치가 있는 설정은 모델이 메모리에 상주하는 시간과 일부 환경에서의 바인딩 주소입니다. Ollama 업그레이드 시 설정이 덮어씌워지지 않도록 두 설정 모두 systemd 드롭인(drop-in) 파일에 작성합니다.

sudo systemctl edit ollama.service

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

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE은(는) 마지막 요청 이후 모델이 메모리에 유지되는 시간(기본값 5분)을 결정합니다. 하루 종일 쿼리를 수행하는 서버라면 매번 가중치를 다시 불러오지 않도록 이 값을 높이십시오. 메모리가 부족한 환경이라면 요청이 끝나는 즉시 RAM을 확보할 수 있도록 0으로 설정하십시오. systemctl edit은(는) 유닛 파일을 자동으로 다시 불러오므로, 변경 사항을 적용하려면 서비스를 재시작하십시오.

sudo systemctl restart ollama

가장 중요한 보안 사항

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

이 API에는 인증 기능이 없습니다. 전혀 없습니다. API 키, 로그인, 속도 제한, 허용 목록이 존재하지 않습니다. 포트 11434에 접근할 수 있는 사람은 누구나 사용자가 내려받은 모델을 실행하거나, 새 모델을 내려받고, 삭제할 수 있으며, CPU나 GPU를 무기한 최대 부하 상태로 만들 수 있습니다. Shodan과 같은 스캐너는 수천 개의 열린 Ollama 인스턴스를 색인화하며, 노출된 인스턴스는 발견된 지 몇 시간 내에 악용됩니다.

따라서 절대 해서는 안 되는 실수는 다음과 같다. OLLAMA_HOST=0.0.0.0를 설정한 뒤 방화벽에서 11434를 열지 않는다. 그러면 인증되지 않은 추론 서버가 전체 인터넷에 공개된다. `0.0.0.0`에서 11434를 그대로 노출하는 방식은 어떤 설정으로도 안전하게 만들 수 없다. Ollama에는 설정할 인증 기능 자체가 없기 때문이다. 이는 이 특정 서비스에 적용되는 규칙이지, 포트를 절대 열지 말라는 뜻은 아니다. 원격 데스크톱용 자체 호스팅 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 바인딩을 유지하며, 공용 포트에서는 프록시만 대기 상태가 됩니다. 이는 모든 로컬 서비스 앞에 nginx용 Let's Encrypt 인증서를 배치하는 것과 동일한 구조입니다.

리버스 프록시 옵션은 다음에 이어질 채팅 UI에서 실제 로그인 기능과 함께 제공되는 방식입니다.

Open WebUI를 사용하여 TLS 기반 채팅 UI 추가하기

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로 라우팅할 수 있습니다. 보안 섹션의 규칙은 여전히 유효합니다. 프록시가 공개 포트와 로그인을 담당하고, 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, try pulling it first 오류가 반환됩니다. 일반적인 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이 출력되거나 서버 로그에 llama runner process has terminated: signal: killed이 표시된다. 모델에 시스템의 실제 RAM보다 많은 메모리가 필요했기 때문에 Linux OOM killer가 프로세스를 종료한 것이다. sudo dmesg | grep -i oom로 원인을 확인하면 Out of memory: Killed process ... (ollama)과 같은 줄이 표시된다. 해결 방법은 더 작은 모델이나 더 강하게 양자화한 모델을 사용하는 것이다. 13B 대신 llama3.2:3b를 사용하거나, swap을 추가할 수도 있다. 그러면 물리 RAM을 약간 초과하는 작업이 즉시 종료되지 않고 느리게 완료될 수 있다. swap은 즉시 발생하는 충돌을 느린 응답으로 바꿀 뿐이다. 4 GB에서 70B 모델을 실용적으로 사용할 수 있게 하지는 않는다. 터미널을 직접 확인하지 않는 한 프로세스 종료는 조용히 발생한다. 따라서 다른 위치에서 조회하는 서버라면 ollama.service에 알림을 게시하는 OnFailure= unit을 연결해야 한다. 그러면 푸시 알림을 보낼 수 있도록 직접 운영하는 ntfy 서버가 프로세스가 종료되는 즉시 알려 주므로 다음 요청을 보낼 때까지 문제를 알아차리지 못하는 상황을 피할 수 있다.

"Error: model requires more system memory". Ollama가 모델 실행을 거부하고 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 동안 메모리에 상주하므로 두 번째 프롬프트에는 즉시 응답합니다. 첫 로드가 호출 경로의 어느 지점에서든 설정된 timeout을 초과하면 느린 응답 대신 오류가 발생합니다. context deadline exceeded를 보고한 계층 확인을 통해 client, proxy, load 자체 중 어느 항목에서 대기 시간이 초과되었는지 확인할 수 있습니다. 지연이 불편하면 해당 값을 높이고, ollama ps을 사용해 현재 모델이 로드되어 있는지 확인합니다.

전반적으로 속도가 매우 느림. 오류 없이 초당 10 토큰 이하로 출력됩니다. 이는 CPU 추론이 본래 수행하는 방식 그대로 작동하는 것입니다. ollama ps을 실행했을 때 100% CPU이 표시된다면 GPU가 없다는 뜻입니다. 이는 버그가 아니며 설정으로 해결할 수 없습니다. 메모리 대역폭이 물리적 한계이기 때문입니다. 더 작은 모델을 사용하거나, 현재 속도를 수용하거나, GPU 인스턴스로 이전하십시오. 무언가 고장 났다고 판단하기 전에 --verbose을 사용하여 실제 처리 속도를 측정하십시오.

다른 기기에서 연결 거부됨. 노트북에서 접속을 시도하면 curl: (7) Failed to connect to <ip> port 11434: Connection refused 오류가 발생합니다. 이는 의도된 설계입니다. Ollama는 기본적으로 localhost에만 바인딩됩니다. 이를 해결하기 위해 0.0.0.0으로 바인딩하지 마십시오. 이는 앞서 언급한 보안 노출 실수를 범하는 것입니다. VPN을 통하거나 인증된 프록시를 거쳐 모델에 접근하십시오.

11434 포트를 인터넷에 노출함. 만약 OLLAMA_HOST=0.0.0.0을 설정하고 방화벽을 열어둔 상태에서, 본인이 시작하지 않은 모델이 다운로드되거나 알 수 없는 클라이언트에 의해 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를 업그레이드하려면 설치 스크립트를 다시 실행하십시오. Open WebUI를 업그레이드하려면 docker pull ghcr.io/open-webui/open-webui:main을 실행한 뒤 컨테이너를 다시 생성하십시오. 장기적으로 버전을 고정하지 마십시오. 모델 품질과 런타임 모두 빠르게 변화하므로, 지난 분기의 수치를 신뢰하기보다는 릴리스 노트를 읽고 자신의 서버에서 직접 벤치마크를 수행하십시오.

FAQ

CPU만 있는 VPS에서 LLM을 실행할 수 있습니까?

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

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

기본 4비트 양자화 모델을 기준으로 한 대략적인 규칙은 다음과 같습니다. 가중치(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가 기본적으로 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과 키만 변경하면 대부분 그대로 실행됩니다.