Paano i-host ang Ollama sa VPS nang safe

Ang iyong bubuuin

Isang single open-weight language model na tatakbo sa sarili mong server. Maaari itong gamitin sa pamamagitan ng HTTP API at, kung gusto mo, isang chat page sa iyong browser. Ang Ollama ang component na nagda-download ng model, naglo-load nito sa memory, at nagse-serve ng mga request sa http://127.0.0.1:11434. Isang command lang ang installation. Ang mahihirap na bahagi ay nasa ibang aspeto: ang pagpili ng model na kasya sa RAM ng iyong VPS, at ang pag-iwas sa hindi sinasadyang pag-publish ng unauthenticated inference server sa buong internet.

Dalawang babala muna. Mabagal ang takbo ng maliliit na model sa isang CPU-only VPS, at walang built-in authentication ang API. Detalyadong tatalakayin ang dalawang ito sa ibaba, dahil dito madalas nagkakaroon ng problema ang mga user.

Ang realidad ng sizing, sa simpleng numero

Ang memory footprint ng isang model ay halos katumbas ng file size nito, dagdag ang humigit-kumulang isang gigabyte na runtime overhead, at karagdagang memory para sa context window. Ang default models ng Ollama ay 4-bit quantized (may label na Q4), na kumakain ng halos kalahating gigabyte ng RAM para sa bawat isang bilyong parameters. Simple lang ang kalkulasyon nito, at ito ang nagtatakda ng lahat.

Ang isang 3B model gaya ng llama3.2:3b ay may ~2 GB na download size at nangangailangan ng halos 4 GB na free RAM para tumakbo. Ang isang 7B o 8B model gaya ng mistral:7b o llama3.1:8b ay ~5 GB sa disk at nangangailangan ng halos 8 GB na RAM, o 16 GB para maging komportable. Ang isang 13B o 14B model ay nangangailangan ng halos 16 GB. Ang anumang nasa 30B-to-70B range ay nangangailangan ng machine na may malaking RAM o, sa katunayan, isang GPU — sa isang CPU VPS, hindi ito magkakasya o kaya naman ay sobrang bagal ang sagot kaya hindi ito magagamit.

Pagdating naman sa bilis, ito ang bahagi na madalas maliitin ng mga tao. Ang CPU inference ay nakadepende sa memory bandwidth, hindi sa clock speed, at ang isang shared vCPU VPS ay may mababang bandwidth. Mag-expect ng single-digit hanggang low-double-digit tokens per second: ang isang 7-8B Q4 model ay maaaring makakuha ng 4 hanggang 10 tokens per second, at ang isang 3B model ay 10 hanggang 25. Ang GPU ay mas mabilis nang halos isang order of magnitude. Ang mga ito ay rough figures lamang — ang pinakatama ay sukatin ang sarili mong machine, na ipinapakita sa run step sa ibaba. Magtiwala sa iyong eval rate, hindi sa numero sa anumang artikulo, kasama na ito.

Ang praktikal na konklusyon: ang maliliit na quantized models sa CPU ay talagang kapaki-pakinabang para sa drafting, summarizing, at classification kung kaya mong tanggapin ang bilis nito. Para sa anumang mas malaki o mas mabilis, maglaan ng budget para sa isang GPU instance.

Para ihambing ang isang partikular na model sa isang partikular na machine, i-estimate ang memory footprint nito dito:

Install Ollama

May dalawang malinis na paraan. Ang official script ang pinakasimple para sa bare VPS:

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

Gagawa ito ng system user na may pangalang ollama, i-install ang binary sa /usr/local/bin/ollama, at irehistro ang isang systemd service na tinatawag na ollama.service na magsisimula pagka-boot at magba-bind sa 127.0.0.1:11434. I-confirm kung gumagana na ito:

systemctl status ollama
ollama --version

Kung gumagamit ka na ng Docker, gamitin ang container:

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

Tandaan ang 127.0.0.1: prefix sa port mapping. Iba-bind nito ang port sa localhost lamang. Ang paggamit ng -p 11434:11434 ay magpa-publish sa lahat ng interface, na siyang pagkakamaling babalaan sa security section. Pumili ng isang install method; huwag patakbuhin ang script at ang container nang sabay, dahil mag-aagawan ang dalawang process sa port.

I-pull at i-run ang iyong unang model

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

I-download ng pull ang mga model layer sa disk (mga 2 GB para sa model na ito). I-load ng run ang mga ito sa memory at ibibigay ka sa isang >>> prompt. Mag-type ng tanong. Maaaring abutin ng ilang segundo ang unang token habang nilo-load ang mga weights mula sa disk papunta sa RAM, pagkatapos ay mag-stream na ang sagot. I-type ang /bye para lumabas sa chat; patuloy na tatakbo ang Ollama sa background.

Tingnan kung ano ang naka-load at kung paano ito kasya:

ollama ps

Ang PROCESSOR column ang nagpapakita ng totoong status. Ang 100% CPU ay nangangahulugang walang GPU na ginagamit, at ito ang dahilan ng pagbagal. Sukatin ang totoong bilis gamit ang verbose flag:

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

Ang eval rate line na lalabas sa dulo ay ang iyong tokens per second sa hardware na ito. Ito ang numerong dapat mong gamitin sa pagpaplano.

Lokasyon ng mga model at laki ng disk na dapat bilhin

Ang mga model na in-install ng script at tumatakbo bilang service ay nasa home directory ng ollama user:

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

Kung gagamitin ang mga ito nang interactive gamit ang sarili mong user, nasa ~/.ollama/models ang mga ito. Sa loob ng container, nasa ollama named volume ang mga ito. Mahalaga ito dahil mabilis lumaki ang kabuuang laki ng quantized weights: ang 3B ay ~2 GB, ang 7-8B ay ~5 GB, at ang 14B ay ~9 GB. Kapag nag-pull ka ng apat na model para sa comparison, gumamit ka na agad ng 20 GB nang hindi namamalayan. I-size ang disk base sa mga model na balak mong i-keep, at i-delete ang iba gamit ang ollama rm <model>.

Patakbuhin ito bilang isang service na kontrolado mo

Naka-register na ang ollama.service sa install script, kaya magre-restart ito pagkatapos ng boot nang walang karagdagang trabaho. Ang setting na dapat baguhin ay kung gaano katagal mananatili ang model sa memory, at sa ilang setup, ang bind address — pareho itong inilalagay sa isang systemd drop-in para hindi sila ma-overwrite ng Ollama upgrade:

sudo systemctl edit ollama.service

Idagdag ito sa ilalim ng [Service] header na ipapakita ng editor:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Ang OLLAMA_KEEP_ALIVE ay kung gaano katagal mananatili ang model sa memory pagkatapos ng huling request (default ay 5 minutes). Taasan ito sa mga server na ginagamit nang buong araw para maiwasan ang pag-reload ng mga weights sa bawat pagkakataon; i-set ito sa 0 sa mga server na may limitadong resources para agad na ma-free ang RAM pagkatapos ng request. I-reload ng systemctl edit ang mga unit file para sa iyo, kaya mag-restart para ma-apply ang pagbabago:

sudo systemctl restart ollama

Ang pinakaimportanteng security point

By default, naka-bind ang Ollama sa 127.0.0.1:11434, kaya ang mga process lang sa mismong VPS ang makaka-access dito. Tama ang default na ito. Panatilihin ito.

Walang authentication ang API. Wala talaga. Walang API key, walang login, walang rate limit, at walang allow-list. Sinumang makaka-access sa port 11434 ay pwedeng mag-run ng kahit anong model na na-pull mo, mag-pull ng bago, mag-delete ng mga ito, at i-load ang CPU o GPU mo nang todo nang walang katapusan. Ang mga scanner gaya ng Shodan ay nag-i-index ng libo-libong open Ollama instances; ang isang exposed instance ay nakikita at nagagamit agad sa loob ng ilang oras.

Ito ang iisang pagkakamali na hindi dapat gawin: huwag i-set ang OLLAMA_HOST=0.0.0.0 at huwag i-open ang 11434 sa iyong firewall. Naglalathala ito ng isang unauthenticated inference server sa buong internet. Walang configuration ang makakapag-secure sa raw 11434-on-0.0.0.0, dahil walang authentication sa Ollama — sadyang wala itong feature na ito.

May tatlong ligtas na paraan para ma-access ang model mula sa ibang machine:

• Panatilihin itong local. Kung ang tanging caller ay isa pang program sa parehong VPS — isang cron script, isang bot, o isang MCP server bridging your tools to the model — iwanan ang bind sa 127.0.0.1 at hayaan ang program na iyon na tumawag sa http://127.0.0.1:11434. Walang exposed at wala nang ibang kailangan.
• I-access ito via private tunnel. Ilagay ang VPS sa isang WireGuard VPN you host yourself, i-set ang OLLAMA_HOST sa tunnel address (halimbawa 10.8.0.1, hindi 0.0.0.0), at ang mga VPN peers lang ang pwedeng kumonekta. Walang makikita ang public internet sa 11434.
• Gumamit ng authenticating reverse proxy sa harap. I-terminate ang TLS at mag-require ng password o token sa nginx, Traefik, o Caddy, pagkatapos ay i-proxy sa 127.0.0.1:11434. Mananatili ang localhost bind ng Ollama; ang proxy lang ang nakikinig sa public port. Katulad ito ng paglalagay ng a Let's Encrypt certificate on nginx sa harap ng anumang local service.

Ang reverse-proxy option ay ang mismong ibibigay sa iyo ng chat UI sa susunod, na may kasamang totoong login.

Magdagdag ng chat UI gamit ang Open WebUI, sa likod ng TLS

Ang Open WebUI ay isang self-hosted chat interface. Patakbuhin ito sa Docker at ituro sa lokal na 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

Ang --network=host flag ang mahalagang detalye sa isang Linux VPS. Inilalagay nito ang container sa network namespace ng host, kaya ang 127.0.0.1 sa loob ng container ay ang loopback ng host. Maaabot ng container ang Ollama sa 127.0.0.1:11434 kahit hindi nakikinig ang Ollama sa ibang interface. Ang bridge-network method na makikita sa ibang lugar — --add-host=host.docker.internal:host-gateway gamit ang OLLAMA_BASE_URL=http://host.docker.internal:11434 — ay hindi gagana rito: ang pangalang iyon ay tumutukoy sa Docker bridge gateway. Ang service na naka-bind sa 127.0.0.1 sa host ay hindi maabot sa bridge, kaya magpapakita lang ang Open WebUI ng error na hindi nito maabot ang Ollama.

Ang trade-off ng host networking ay pakikinggan na ng Open WebUI ang port 8080 ng host sa lahat ng interface; mawawalan ng bisa ang anumang -p mapping, at maglalabas ang Docker ng warning tungkol dito. Kaya i-close ang 8080 sa host firewall at sa provider firewall, at hayaan ang TLS reverse proxy na maging tanging public door. Sa unang pagbisita, hihilingin ng Open WebUI na gumawa ng admin account — ang account na iyon ang iyong authentication layer, kaya gumamit ng malakas na password.

Para mabuksan ang chat mula sa iyong laptop gamit ang HTTPS, maglagay ng TLS reverse proxy sa harap ng 127.0.0.1:8080. Kung nagro-route ka na ng maraming Docker apps sa machine, ang Traefik na may automatic TLS para sa maraming apps ang pinakamalinis na opsyon: isang label block lang ang kailangan para mag-issue ng certificate at i-route ang chat.example.com sa Open WebUI. Ang panuntunan mula sa security section ay applicable pa rin — ang proxy ang may hawak ng public port at login, habang ang Ollama ay mananatili sa localhost at ang sariling 8080 ng Open WebUI ay mananatiling firewalled.

Gamitin ang OpenAI-compatible endpoint mula sa iyong code

Gumagamit ang Ollama ng subset ng OpenAI chat API sa /v1, kaya gumagana ang karamihan sa mga OpenAI client library pagkatapos baguhin ang dalawang bagay: ang base URL at isang dummy key.

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)

Kailangan ng client library ang api_key pero hindi ito binabasa ng Ollama, kaya kahit anong string ay pwede. Dapat ang model ay isang pangalan na na-pull mo na; ang hindi kilalang pangalan ay magbabalik ng model "x" not found, try pulling it first. Ganito rin ang konsepto sa paggamit ng curl call:

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"}]}'

Ganito rin ikinakabit ang model sa agent at editor tooling. Kung nagdedevelop ka na sa machine na ito, maaaring gamitin ang local model para suportahan ang mga script at plugin kasabay ng Claude Code na tumatakbo sa VPS sa loob ng tmux, upang mapanatiling pribado at mura ang drafting work habang ang mabigat na reasoning ay nasa hosted model.

Failure modes, with the exact strings you will see

Ang proseso ay "Killed" mid-generation. Nag-start ka ng malaking model at nag-print ang terminal ng Killed, o nagpakita ang server log ng llama runner process has terminated: signal: killed. Pinatigil ito ng Linux OOM killer dahil mas malaki ang kailangang RAM ng model kaysa sa kapasidad ng machine. I-confirm ang sanhi gamit ang sudo dmesg | grep -i oom, kung saan makikita mo ang linya na katulad ng Out of memory: Killed process ... (ollama). Ang solusyon ay gumamit ng mas maliit o mas heavily quantized na model — llama3.2:3b sa halip na 13B — o magdagdag ng swap para ang load na lumalampas nang bahagya sa physical RAM ay matapos nang mabagal sa halip na mag-crash. Ginagawang mabagal na sagot ng swap ang instant crash; hindi nito ginagawang praktikal ang 70B model sa 4 GB.

"Error: model requires more system memory". Hindi papayagan ng Ollama na mag-start ang model at mag-print ng Error: model requires more system memory (X GiB) than is available (Y GiB). Ito ang mas maayos na bersyon ng crash sa itaas: kinalkula ng Ollama ang memory requirements at huminto na lamang sa halip na hayaan ang OOM killer na gawin ito. Ibibigay pa nito sa iyo ang dalawang numero. Pumili ng model na ang requirement ay mas mababa sa iyong free RAM (i-check gamit ang free -h), paliitin ang context length, o lumipat sa mas malaking VPS. Walang flag ang makakapagkasya sa model — ang memory ay real.

Ang unang token ay matagal, pero okay naman pagkatapos. Ang isang cold model ay walang i-print sa loob ng lima hanggang tatlumpung segundo, pagkatapos ay mag-stream na nang normal. Ang pause na iyon ay ang pag-load ng weights mula sa disk patungong RAM sa unang pagkakataon, at pinalalala ito ng mabagal na storage. Kapag loaded na, mananatiling resident ang model sa loob ng OLLAMA_KEEP_ALIVE, kaya ang pangalawang prompt ay sasagot nang instant. Taasan ang value na iyon kung nakakaabala ang mga gaps, at gamitin ang ollama ps para makita kung ang model ay kasalukuyang loaded.

Mabagal ang lahat. Sampung tokens bawat segundo o mas mababa pa, nang walang anumang error. Iyan ang normal na CPU inference. Ipinapakita ng ollama ps ang 100% CPU, na nangangahulugang walang GPU. Hindi ito bug at walang setting na makakaayos nito, dahil ang limitasyon ay memory bandwidth, hindi misconfiguration. Gumamit ng mas maliit na model, tanggapin ang bilis, o lumipat sa isang GPU instance — at sukatin ang iyong real rate gamit ang --verbose bago magdesisyon na may sira.

Connection refused from another machine. Mula sa iyong laptop, makakakuha ka ng curl: (7) Failed to connect to <ip> port 11434: Connection refused. Ito ay working as designed: ang Ollama ay naka-bind sa localhost lamang. Huwag itong "ayusin" sa pamamagitan ng pag-bind sa 0.0.0.0, na isang exposure mistake. Gamitin ang VPN o isang authenticating proxy para ma-access ang model.

Na-expose mo ang 11434 sa internet. Kung na-set mo ang OLLAMA_HOST=0.0.0.0, binuksan ang firewall, at nakakakita ka ngayon ng mga model pulls na hindi mo naman sinimulan o CPU na 100% ang load dahil sa mga unknown clients, na-detect at nagamit ka na. Ito ang pangunahing pagkakamali, hindi ito edge case. I-rebind sa 127.0.0.1 o sa VPN address, i-close ang 11434 sa firewall, at maglagay ng authentication sa harap. I-assume na ang anumang ma-access sa address na iyon habang ito ay bukas ay na-query na ng mga strangers.

Backups and upgrades

Kakaunti lang ang state na maaaring mawala. Maaaring i-download muli ang mga model, kaya ang tanging dapat i-back up ay ang data volume ng Open WebUI — ang mga account, chat history, at settings — pati na ang anumang systemd drop-in na ginawa mo. I-back up ang volume gamit ang isang throwaway container:

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

I-upgrade ang Ollama sa pamamagitan ng pag-run muli ng install script; i-upgrade ang Open WebUI gamit ang docker pull ghcr.io/open-webui/open-webui:main at pagkatapos ay i-recreate ang container. Huwag mag-pin ng kahit ano nang pangmatagalan: mabilis magbago ang model quality at ang runtime, kaya basahin ang release notes at mag-re-benchmark sa sarili mong box sa halip na magtiwala sa mga numero mula noong nakaraang quarter.

FAQ

Maaari ko bang patakbuhin ang LLM sa CPU-only VPS?

Oo, pero may mga limitasyon. Ang mga maliliit na quantized model sa 3B hanggang 8B range ay tumatakbo sa CPU. Kapaki-pakinabang ang mga ito para sa drafting, summarizing, at classification — bagaman mabagal ang takbo sa single-digit hanggang low-double-digit tokens per second sa isang shared vCPU. Ang anumang model mula 13B pataas ay sobrang bagal o hindi kakasya sa RAM. Kailangan mo ng GPU instance para sa mabilis na performance o para sa mas malalaking model.

Gaano karaming RAM ang kailangan ng bawat model?

Isang rough rule para sa default 4-bit quantized models: humigit-kumulang 0.5 GB na RAM bawat billion parameters para sa weights, plus halos 1 GB na overhead at dagdag para sa context. Kaya ang 3B model ay nangangailangan ng 4 GB free RAM, ang 7-8B model ay 8 GB, at ang 14B model ay 16 GB. I-check ang iyong headroom gamit ang free -h at mag-iwan ng space para sa operating system at iba pang proseso sa server.

Authenticated ba ang Ollama API?

Hindi. Walang built-in authentication, API key, o rate limit ang Ollama — kahit sinong makaka-access sa port 11434 ay may full control dito. Ito ang dahilan kung bakit naka-bind ang 127.0.0.1 by default at kung bakit hindi mo dapat i-expose ang 11434 sa internet sa 0.0.0.0. Gamitin ito nang local, sa pamamagitan ng private VPN, o sa isang reverse proxy na may login.

Paano ako magdadagdag ng web chat interface?

Patakbuhin ang Open WebUI sa Docker gamit ang --network=host para ma-share ang host loopback at ma-access ang native Ollama sa http://127.0.0.1:11434. Pagkatapos, maglagay ng TLS reverse proxy sa harap ng port 8080 para sa access mula sa iyong laptop. Panatilihing closed ang 8080 sa firewall para ang proxy lamang ang tanging public entry point. Ang admin account ng Open WebUI ang gagamitin para sa login, at i-set ang password nito sa unang launch.

Paano ko ito tatawagin mula sa aking sariling application?

Gamitin ang OpenAI-compatible endpoint sa http://127.0.0.1:11434/v1. I-point ang anumang OpenAI SDK sa base URL na iyon, magpasa ng kahit anong string bilang API key dahil hindi ito tinitingnan, at i-set ang model sa pangalan ng model na iyong ni-pull. Ang mga existing na OpenAI code ay karaniwang tumatakbo nang walang pagbabago maliban sa base URL at key.