VPS에 LLM 셀프호스팅.
GPU 없음. API 키 없음. 프롬프트는 절대 건물 밖으로 나가지 않습니다.

이 절에서는 솔직한 설명이 열광적인 설명보다 훨씬 가치가 있습니다. 셀프호스팅 모델을 가장 빨리 포기하게 되는 길은, 그것이 가장 못하는 일에 써 보고는 이 아이디어 전체가 어리석었다고 결론짓는 것이기 때문입니다.

여유 있게 맞습니다. 출력이 짧고 가치가 문장력이 아니라 판단력에 있는 모든 작업입니다. 메시지를 몇 가지 범주 중 하나로 분류하기. 지원 티켓이 긴급한지 판단하기. 청구서에서 다섯 개 필드를 JSON으로 추출하기. 스레드를 세 문장으로 요약하기. 문서에 태그 달기. 제품 설명 다시 쓰기. 짧은 문자열 번역하기. 두 레코드가 같은 사람을 가리키는지 판별하기. 다른 곳으로 넘어가기 전에 문단에서 이름 지우기. 이들 모두 긴 입력을 소비하고 짧은 출력을 만드는데, 이것이 바로 CPU가 잘 다루는 비대칭입니다.

맞기는 하지만, 인내가 필요합니다. 사람이 기다리지 않는 작업. 야간 배치, 큐 워커, 그날의 문서를 훑는 야간 처리, 예약된 리포트. 답을 기다리며 막히는 것이 없다면, 채팅창에서는 견딜 수 없을 토큰 속도도 전혀 문제가 되지 않습니다 — 새벽 3시에 6분 동안 도는 작업은 그냥 실행된 작업일 뿐입니다.

맞지 않습니다. 사람들이 실제로 즐겁게 쓸 만한 대화형 어시스턴트: 이 속도로는 커서가 기어가듯 움직이고, 경험은 차라리 어시스턴트가 없는 것보다 못합니다. 장문 생성 — '2천 단어를 써줘' 같은 — 은 출력 전체가 느린 부분입니다. 대규모 저장소를 순회하는 코딩 에이전트는 컨텍스트와 품질 기준 모두 작은 모델이 감당할 수 있는 범위를 넘어섭니다. 10만 토큰급 컨텍스트가 필요한 모든 작업은 캐시만으로도 머신의 용량을 넘어섭니다. 그리고 이미지나 영상 모델은 완전히 다른 분야이며 실제로 GPU를 필요로 합니다.

작업이 그 마지막 그룹에 속한다면, 합리적인 답은 더 큰 CPU 서버를 사는 것이 아니라 하이브리드 구성입니다. 대다수 호출은 로컬 모델이 처리하고, 프런티어 수준의 추론이 필요한 소수만 호스팅형 API로 보내십시오. 이는 AI 에이전트를 24시간 구동하는 가이드가 런타임 측면에서 설명하는 것과 정확히 같은 형태입니다. 그 가이드는 모델 자체를 의도적으로 다루지 않았습니다. 이 가이드가 그 빠진 절반입니다.

먼저 서버를 강화하십시오 — 키 전용 SSH, 요청하지 않은 것은 아무것도 허용하지 않는 방화벽, 무인 보안 업데이트. 첫 시간 체크리스트는 한 시간 정도 걸리며, 이 서버는 곧 당신이 던지는 모든 질문을 품게 될 서버입니다.

그다음 러너를 설치하십시오. Ollama는 모델 레지스트리, REST API, systemd 유닛을 감싼 llama.cpp이며, 한 줄짜리 설치 스크립트가 셋 다 설정해 줍니다:

apt update && apt install -y curl
curl -fsSL https://ollama.com/install.sh | sh

systemctl status ollama --no-pager
ss -ltnp | grep 11434
# → 127.0.0.1:11434 — loopback only. Leave it that way.

그 마지막 줄은 두 번 읽을 가치가 있습니다. 기본 설정에서 서비스는 루프백 인터페이스에서 대기하며, 이는 정확히 옳은 설정입니다. 그다음 10분 안에 가장 흔히 저지르는 실수는, 다른 머신에서 접근이 안 된다는 이유로 OLLAMA_HOST를 0.0.0.0으로 설정하는 것입니다. 제대로 접근하는 방법은 4단계에서 다룹니다. 포트 11434가 인터넷에 직접 노출되는 버전은 어디에도 없습니다.

나중에 알아채기보다 지금 정해 두는 것이 나은 설정이 두 가지 있습니다. 모델은 기본적으로 /usr/share/ollama 아래에 저장되고 용량이 크므로, 여유가 있는 곳으로 지정해 두십시오. 그리고 기본값은 마지막 요청 이후 5분 동안 모델을 RAM에 상주시키는데, 이는 다른 작업도 하는 서버에서는 다소 넉넉한 설정입니다:

systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/var/lib/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

systemctl daemon-reload && systemctl restart ollama

병렬 요청과 다중 모델 로드는 둘 다 메모리 사용량을 곱으로 늘리며, 모델 하나만 담을 수 있는 크기로 맞춘 머신에는 두 번째 사본을 위한 여유 기가바이트가 없습니다. 큐를 직렬화하는 것은 이 하드웨어의 한계가 아니라, 쓰러지지 않는 유일한 설정입니다.

이 부분은 이 가이드에서 나쁜 일이 일어나는 것을 막는 대목이므로, 에둘러 말하지 않겠습니다. Ollama API에는 비밀번호도, 토큰도, 사용자 모델도, 권한 체계도 없습니다. 포트 11434로 TCP 연결을 열 수 있는 무엇이든 당신의 CPU에서 텍스트를 생성하고, 내려받은 모델 목록을 나열하고, 새 모델을 내려받고, 쓰던 모델을 지울 수 있습니다. 켤 수 있는 설정 같은 것은 없습니다. 애초에 켤 수 있는 메커니즘 자체가 없기 때문입니다.

포트 11434는 끊임없이 스캔당하는데, 이유는 뻔합니다. 열려 있는 모델 러너는 누군가 다른 사람의 공짜 연산 자원이기 때문입니다. 증상은 경고 알림이 아닙니다. 2주 동안 느리게 느껴지는 머신과, 당신이 한 일과 맞아떨어지지 않는 대역폭 그래프입니다. 서비스는 루프백에만 두고, 그 앞에 누가 호출하는지 묻는 무언가를 세워 두십시오.

이 머신 바깥에서 모델을 필요로 하는 것이 없다면, 여기서 멈추십시오 — 이미 끝났습니다. 루프백과 방화벽만으로 완전한 답이 되며, 같은 VPS에서 실행되는 에이전트, 자동화 스택, 웹 앱은 이후 내용 없이도 127.0.0.1을 통해 모델에 접근합니다. 다른 머신에 있는 무언가가 호출해야 하는 경우에만 계속 읽으십시오.

프록시, 그리고 토큰. 길고 무작위한 토큰을 생성하고, A 레코드를 이 서버로 지정한 뒤, 인증서와 출입문 모두 Caddy가 처리하게 하십시오:

openssl rand -hex 32      # → the bearer token, store it in a password manager
apt install -y caddy

/etc/caddy/Caddyfile

llm.example.com {
    @unauthorised not header Authorization "Bearer PASTE_THE_HEX_TOKEN_HERE"
    respond @unauthorised "unauthorised" 401

    reverse_proxy 127.0.0.1:11434 {
        # Generation is slow by nature — do not let the proxy give up first.
        transport http {
            read_timeout 10m
        }
    }
}

systemctl reload caddy
ufw allow 80,443/tcp
ufw status                # 11434 must appear nowhere

기본 인증 대신 베어러 토큰을 고르는 데는 작은 우아함이 있습니다. Ollama는 OpenAI 호환 API를 제공하고, 모든 OpenAI 클라이언트는 키를 정확히 그 헤더로 보내므로, 방금 생성한 토큰이 애플리케이션이 이미 다룰 줄 아는 API 키가 됩니다. 사용자 지정 헤더는 필요 없으며, 접근 권한을 회전시키는 것은 Caddyfile 한 줄과 호출자 쪽 환경 변수 하나로 끝납니다.

서버가 아닌 다른 머신에서 확인하십시오. 첫 번째 호출은 거부되어야 하고, 두 번째 호출은 응답해야 합니다:

curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
# → 401

curl -s https://llm.example.com/api/tags -H "Authorization: Bearer THE_TOKEN" | jq '.models[].name'
# → the list of models you pulled

모델을 당신이 아니라 에이전트들이 호출하게 될 경우, 노출 문제는 원격 MCP 서버 호스팅 가이드에서 더 충실히 다룹니다 — TLS, 토큰, 어디서 무엇에 접근할 수 있어야 하는지에 관한 같은 논리를, 토큰이 아니라 도구를 내주는 서비스에 적용한 내용입니다.

컨텍스트에 상한을 두십시오. 컨텍스트 길이는 메모리 사용량을 좌우하는 주요 손잡이이며, 기본값은 작은 서버가 감당하기에는 다소 넉넉합니다. 실제로 가장 긴 프롬프트가 필요로 하는 값으로 전역 설정을 해 두십시오 — 대부분의 분류·추출 작업은 4천 토큰 이내로 충분합니다 — 그리고 드물게 더 필요한 요청에서만 개별적으로 올리십시오:

Environment="OLLAMA_CONTEXT_LENGTH=4096"

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "…a long document…",
  "options": { "num_ctx": 16384 },
  "stream": false
}'

모델이 메모리에 얼마나 머물지 정하십시오. 상주 중인 모델은 즉시 호출할 수 있는 대신 여러 기가바이트를 계속 붙잡아 둡니다. 추론 전용 머신이라면 영구히 로드해 두고, 공유 머신이라면 일정 시간 후 내려가게 두십시오. 이 값은 요청 단위로도 지정할 수 있어서, 야간 배치는 실행 동안 모델을 고정해 두었다가 끝나면 해제할 수 있습니다:

OLLAMA_KEEP_ALIVE=-1     # resident until the service restarts
OLLAMA_KEEP_ALIVE=30m    # a sensible default on a shared box
OLLAMA_KEEP_ALIVE=0      # unload immediately after each request

ollama ps                # what is resident right now, and how much it holds

큐를 직렬화하십시오. 하나의 모델에 동시 요청 두 개를 보낸다고 두 배 빨라지지 않습니다. 둘은 이미 포화된 같은 메모리 경로를 두고 경쟁하며 각각 더 느려지고, Ollama가 이를 처리하려고 두 번째 사본을 로드하기로 하면 서버는 RAM이 바닥납니다. 이런 부류의 하드웨어에서는 앞에 큐를 두고 한 번에 요청 하나씩 처리하는 것이 가장 빠르면서 동시에 유일하게 안전한 설정입니다 — 그래서 2단계에서 OLLAMA_NUM_PARALLEL과 OLLAMA_MAX_LOADED_MODELS를 1로 고정해 둔 것입니다.

디스크를 지켜보십시오. 모델 네 개를 비교하면 네 개가 그대로 남고, 각각 5기가바이트씩이라 아무 경고도 없이 디스크가 조용히 채워집니다. 정리를 나중 일로 미루지 말고 비교 과정 자체에 포함시키십시오:

ollama list
du -sh /var/lib/ollama/models
ollama rm mistral:7b qwen2.5:14b

마지막으로, 재현할 수 없는 것을 백업하십시오. 모델 가중치는 재현 가능합니다 — 다시 받으면(pull) 그만입니다. 저장소에 넣을 가치가 있는 것은 설정, Caddyfile, 토큰, 3주에 걸쳐 다듬은 프롬프트, 그리고 직접 만들었다면 검색의 기반이 되는 벡터 인덱스입니다. 암호화 백업 가이드가 그 방법을 다루며, 이 서버를 위한 백업 목록은 짧지만 적어 둘 가치가 있습니다.

사람들은 모델 프라이버시를 마치 위험이 출력에 있는 것처럼 따집니다. 그렇지 않습니다. 출력은 범용적인 텍스트일 뿐이고, 다른 수천 명도 비슷한 것을 받았습니다. 정체를 드러내는 것은 입력이며 — 1년치 입력은 한 조직의 놀랍도록 완전한 초상화입니다.

요청 로그에 실제로 무엇이 담기는지 생각해 보십시오. 요약을 맡기려고 붙여 넣은 계약서. 분류를 요청한 고객 이메일, 그 안의 고객 정보까지. 진단서, 연봉 수치, 초안 작성 중이던 사직서, 공개되지 않은 저장소의 코드. 그리고 그 주변의 메타데이터: 어떤 질문을, 어떤 순서로, 몇 시에, 어느 주소에서, 몇 달에 걸쳐 했는지. “이것이 우리의 전략입니다”라고 서명하는 문서는 아무도 만들지 않지만, 그 질문들의 연쇄가 바로 그 문서입니다. 당신이, 한 번에 한 통씩, 정직하게 조립한 것입니다.

1계층 — 엔드포인트가 보관하는 것. 제대로 된 업체는 제대로 된 정책을 공개하며, 훌륭한 업체는 실제로 비즈니스 API 트래픽으로 학습하지 않습니다. 하지만 이는 보관하지 않는다는 약속과는 다릅니다. 요청은 보통 남용 감시를 위해 일정 기간 저장되고, 정해진 조건 아래 직원이 열람할 수 있으며, 법적 절차에 따라 제출될 수 있습니다 — 이는 대형 플랫폼을 운영하는 데는 정확히 옳은 방식이지만, 낯선 사람에게 이메일로 보내지 않을 텍스트를 두기에는 정확히 잘못된 곳입니다. 자신의 머신에 있는 모델은 직접 기록을 남기지 않는 한 그런 로그를 갖지 않습니다.

2계층 — 로그와 연결되는 신원. 보관 그 자체는 노출의 절반에 불과합니다. 나머지 절반은 그것이 연결되는 열쇠입니다. 계정, 회사명, 청구 주소, 카드. 그 연결이 “누군가 경쟁사 인수에 대해 물었다”를 “이 회사가, 그 화요일에 물었다”로 바꿔 놓습니다. 방정식에서 모델을 빼면 보관이 사라지고, 머신에서 신원을 빼면 그 연결이 사라집니다. 이메일 주소도 신분증도 없이, 노르딕 관할권에서, Monero로 결제해 개설한 VPS는 바로 같은 조치의 나머지 절반입니다.

3계층 — 직접 작성하는 로그. 셀프호스팅은 위험을 없애는 것이 아니라 옮길 뿐이며, 그것이 어디에 떨어지는지 명확히 알아 둘 가치가 있습니다. 당신의 애플리케이션은 아마 자체적으로 프롬프트를 기록할 것입니다. 리버스 프록시는 모든 요청 줄을 기록합니다. 두 달 전 디버깅 세션이 저널에 장황한 출력을 남겨 두었을 수도 있습니다. 모델 자체는 호출 사이에 아무것도 유지하지 않지만, 그 주변 장치는 모든 것을 유지할 수 있습니다 — 그러니 무엇을 기록할지 의도적으로 정하고, 보관 기간을 설정하고, 다른 누군가에게는 용납하지 않았을 기준으로 그 로그를 관리하십시오.

이 중 어느 것도 로컬 모델 자체를 프라이버시 보장으로 만들어 주지는 않습니다. 다만 이는 그 보장을 당신 스스로 부여할 수 있는 유일한 구조로 만들어 줍니다. 텍스트는 당신이 임대한 하드웨어에, 당신이 선택한 관할권 아래, 당신이 발급한 토큰 뒤에 머무르며, 그 밖의 무엇에도 답할 필요가 없습니다.