Jinsi ya kuweka Ollama kwenye VPS salama

Unachojenga

Mfumo wa lugha (language model) wenye uzani wa wazi (open-weight) unaojiendesha kwenye seva yako. Utatumia HTTP API na, ukipenda, ukurasa wa chat kwenye kivinjari (browser) chako. Ollama ndiyo sehemu inayopakua modeli, kuipakia kwenye kumbukumbu (memory), na kutoa huduma kwenye http://127.0.0.1:11434. Usakinishaji unahitaji amri moja tu. Changamoto kubwa zipo kwingine: kuchagua modeli ambayo VPS yako inaweza kuweka kwenye RAM, na kuepuka kuweka seva ya inference bila ulinzi kwenye mtandao mzima.

Tahadhari mbili muhimu kwanza. VPS inayotumia CPU pekee itafanya kazi ya modeli ndogo kwa mwendo wa polepole, na API haina mfumo wa ulinzi (authentication) wa ndani. Mambo haya yote yamefafanuliwa hapa chini, kwa sababu ndipo watu hupata matatizo.

Ukweli kuhusu ukubwa wa mfumo, kwa namba rahisi

Ukubwa wa kumbukumbu wa modeli ni takriban saizi ya faili yake, ditambah takriban gigabaiti 1 ya mzigo wa wakati wa utendaji (runtime overhead), na kiasi kingine kwa ajili ya dirisha la muktadha (context window). Modeli za Ollama kwa kawaida ni za 4-bit quantized (zilizowekwa alama kama Q4), ambazo hutumia takriban nusu gigabaiti ya RAM kwa kila bilioni ya vigezo (parameters). Kwa hivyo hesabu ni rahisi, na ndiyo huamua kila kitu.

Model ya 3B kama llama3.2:3b ni karibu GB 2 ya pakua na inahitaji takriban GB 4 ya RAM iliyo wazi ili kufanya kazi. Model ya 7B au 8B kama mistral:7b au llama3.1:8b ni takriban GB 5 kwenye diski na inahitaji takriban GB 8 ya RAM, au GB 16 ili iwe na nafasi ya kutosha. Model ya 13B au 14B inahitaji takriban GB 16. Chochote katika kiwango cha 30B-hadi-70B kinahitaji mashine yenye RAM kubwa au, kwa uhalisia, GPU — kwenye CPU VPS, ama haitatoshea au itajibu kwa kasi ndogo sana kiasi kwamba haitafaa kutumika.

Sasa kuhusu kasi, kwa sababu huu ni upande ambao watu hukipuuza. Utendaji wa CPU unategemea bandwidth ya kumbukumbu (memory bandwidth), siyo kasi ya saa (clock speed), na vCPU VPS inayoshirikishwa ina bandwidth ndogo. Tarajia token moja hadi kumi na nane kwa sekunde: model ya 7-8B Q4 inaweza kufanya kazi kwa token 4 hadi 10 kwa sekunde, na model ya 3B inaweza kufanya token 10 hadi 25. GPU ni haraka zaidi kwa kiasi cha mara kumi zaidi. Hizi ni takwimu za jumla kwa makusudi — njia ya uhakika ni kupima mashine yako mwenyewe, ambayo hatua ya kuendesha hapa chini inaonyesha jinsi ya kufanya. Amini eval rate yako, siyo namba iliyo kwenye makala yoyote, ikiwemo hii.

Hitimisho la kivitendo: modeli ndogo za quantized kwenye CPU ni muhimu kwa ajili ya kuandika rasimu, kufupisha, na uainishaji (classification) ikiwa unaweza kukubali kasi hiyo. Kwa kitu chochote kikubwa zaidi au cha haraka zaidi, panga bajeti kwa ajili ya instance ya GPU.

Ili kulinganisha modeli mahususi na mashine mahususi, tambua ukubwa wa kumbukumbu hapa:

Sakinisha Ollama

Kuna njia mbili safi. Script rasmi ndiyo rahisi zaidi kwenye VPS tupu:

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

Hii inatengeneza mtumiaji wa mfumo anayeitwa ollama, inasakinisha binary kwenye /usr/local/bin/ollama, na kusajili huduma ya systemd inayoitwa ollama.service ambayo huanza wakati wa kuwaka na kuunganisha 127.0.0.1:11434. Hakikisha imewaka:

systemctl status ollama
ollama --version

Kama tayari unatumia Docker, tumia container badala yake:

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

Zingatia kiambishi cha 127.0.0.1: kwenye ramani ya port. Hii inaunganisha port kwenye localhost pekee. Kuandika -p 11434:11434 badala yake kunaitangaza kwenye kila interface, ambayo ni kosa ambalo sehemu ya usalama inaonya. Chagua njia moja ya usakinishaji; usirun script na container kwa wakati mmoja, yokati ni kwamba michakato miwili itagombana kwa port.

Pakua na uendeshe modeli yako ya kwanza

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

pull hupakua tabaka za modeli kwenye diski (takriban GB 2 kwa hii). run huzipakia kwenye kumbukumbu na kukupeleka kwenye prompt ya >>>. Andika swali. Token ya kwanza inaweza kuchukua sekunde kadhaa wakati uzani (weights) unapakuliwa kutoka kwenye diski kwenda kwenye RAM, kisha jibu litaanza kutiririka. Andika /bye ili kuacha mazungumzo; Ollama itaendelea kuendesha nyuma ya pazia.

Angalia kile kilichopakia na jinsi kinavyokaa:

ollama ps

Safu ya PROCESSOR inaonyesha ukweli. 100% CPU inamaanisha hakuna GPU inayotumika, na hapo ndipo kasi ndogo inapotokea. Pima kasi halisi kwa kutumia flag ya verbose:

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

Safu ya eval rate inayochapishwa mwishoni ni token zako kwa sekunde kwenye hardware hii. Hiyo ndiyo namba ya kuzingatia wakati wa kupanga.

Mahali mifano ilipo, na kiasi cha diski cha kununua

Ikiwa imewekwa na script na inafanya kazi kama service, mifano hukaa kwenye home directory ya mtumiaji ollama:

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

Ikiwa unaitumia kiingilizi (interactively) kama mtumiaji wako, hukaa kwenye ~/.ollama/models. Ndani ya container, hukaa kwenye named volume ya ollama. Hii ni muhimu kwa sababu uzito wa quantized (quantized weights) huongezeka haraka: 3B ni ~2 GB, 7-8B ni ~5 GB, 14B ni ~9 GB. Ukipakua mifano minne ili kuilinganisha, utakuwa umetumia 20 GB bila kugundua. Panga ukubwa wa diski kulingana na mifano unayokusudia kuhifadhi, na ufute nyingine kwa kutumia ollama rm <model>.

Irun kama huduma unayodhibiti

Script ya ufungaji tayari imesharatibu ollama.service, hivyo inajiuwasha wakati wa kuwaka bila hatua nyingine. Mpangilio unaofaa kubadilishwa ni muda ambao model inakaa kwenye kumbukumbu, na kwenye mifumo fulani, anwani ya bind — vyote hupatikana kwenye systemd drop-in ili sasisho la Ollama lisifute mipangilio hiyo:

sudo systemctl edit ollama.service

Ongeza sehemu hii chini ya kichwa cha habari cha [Service] kinachoonyeshwa na mhariri:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE ni muda ambao model inakaa kwenye kumbukumbu baada ya ombi la mwisho (kiwango cha kawaida ni dakika 5). Ongeza muda huu kwenye seva inayotumika muda wote ili kuepuka kupakia upya uzani (weights) kila wakati; weka 0 kwenye seva yenye rasilimali chache ili kuachia RAM mara tu ombi linapokamilika. systemctl edit inapakia upya faili za unit kwa ajili yako, hivyo anza upya ili kutumia mabadiliko:

sudo systemctl restart ollama

Kipengele cha usalama cha muhimu zaidi

Kwa kawaida Ollama huunganishwa kwenye 127.0.0.1:11434, hivyo ni michakato iliyo kwenye VPS pekee inayoweza kuifikia. Mpangilio huo wa kawaida ni sahihi. Uendelee nao.

API haina uthibitisho wa utambulisho. Hakuna. Hakuna API key, hakuna login, hakuna kikomo cha matumizi (rate limit), na hakuna orodha ya kuruhusiwa (allow-list). Mtu yeyote anayeweza kufikia port 11434 anaweza kuendesha modeli yoyote uliyopakua, kupakua nyingine mpya, kuzifuta, na kuweka CPU au GPU yako katika mzigo mkubwa bila kikomo. Skana kama Shodan huorodhesha mifumo ya Ollama iliyo wazi kwa maelfu, na mfumo ulio wazi hupatikana na kutumiwa vibaya ndani ya saa chache.

Hivyo hapa kuna kosa moja usilofanye kamwe: usiset OLLAMA_HOST=0.0.0.0 na kufungua 11434 kwenye firewall yako. Hiyo huweka seva ya inference isiyo na uthibitisho kwenye mtandao mzima wa internet. Hakuna mpangilio wowote unaoweza kufanya 11434 kwenye 0.0.0.0 kuwa salama, kwa sababu hakuna kitu ndani ya Ollama cha kupangilia — uthibitisho wa utambulisho haupo kabisa.

Kuna njia tatu salama za kuifikia modeli kutoka sehemu nyingine nje ya mashine hiyo:

• Iache iwe ya ndani (local). Ikiwa msemaji pekee ni programu nyingine kwenye VPS hiyo hiyo — script ya cron, bot, au server ya MCP inayounganisha zana zako na modeli — acha muunganisho (bind) uwe 127.0.0.1 na uweke programu hiyo iite http://127.0.0.1:11434. Hakuna kitu kinachowaziwa na hakuna kingine kinachohitajika.
• Iifikie kupitia njia ya siri (private tunnel). Iweke VPS kwenye WireGuard VPN unayojiwekea mwenyewe, weka OLLAMA_HOST kwenye anwani ya njia hiyo (kwa mfano 10.8.0.1, siyo 0.0.0.0), na ni watumiaji wa VPN pekee wanaoweza kuunganishwa. Internet ya umma bado haitaona kitu kwenye 11434.
• Weka reverse proxy yenye uthibitisho mbele yake. Malizia TLS na uweke hitaji la nywila au token kwenye nginx, Traefik, au Caddy, kisha tumia proxy kwenda 127.0.0.1:11434. Ollama inaendelea na muunganisho wake wa localhost; proxy ndiyo kitu pekee kinachosikiliza kwenye port ya umma. Hii ni sawa na kuweka cheti cha Let's Encrypt kwenye nginx mbele ya huduma yoyote ya ndani.

Chaguo la reverse-proxy ndilo hasa unachopewa kwenye chat UI inayofuata, ikiwa na login halisi iliyoambatishwa.

Ongeza chat UI kwa kutumia Open WebUI, nyuma ya TLS

Open WebUI ni interface ya chat inayojihosti. Iendeshe kwenye Docker na iunganishe na Ollama ya ndani:

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

Flag ya --network=host ni muhimu kwenye Linux VPS. Inaweka container kwenye network namespace ya host, hivyo 127.0.0.1 ndani ya container ni loopback ya host, na container inaweza kufikia Ollama kwenye 127.0.0.1:11434 bila Ollama kusikiliza kwenye interface nyingine yoyote. Mbinu ya bridge-network utayoiona kwingine — --add-host=host.docker.internal:host-gateway pamoja na OLLAMA_BASE_URL=http://host.docker.internal:11434 — haifanyi kazi hapa: jina hilo linatafsiriwa kama Docker bridge gateway, na huduma iliyofungwa kwenye 127.0.0.1 kwenye host haiwezi kufikiwa kupitia bridge, hivyo Open WebUI itashindwa kuunganishwa na Ollama.

Hasara ya kutumia host networking ni kwamba Open WebUI sasa itasikiliza kwenye port 8080 ya host kwenye kila interface; mapping yoyote ya -p itakataliwa, na Docker itatoa onyo kuhusu hilo. Kwa hivyo funga 8080 kwenye firewall ya host na ya mtoa huduma, na uache TLS reverse proxy iwe mlango pekee wa umma. Wakati wa ziara ya kwanza, Open WebUI itakuomba utengeneze akaunti ya admin — akaunti hiyo ndiyo tabaka lako la uthibitisho, hivyo chagua password imara.

Ili kufungua chat kutoka kwenye laptop yako kupitia HTTPS, weka TLS reverse proxy mbele ya 127.0.0.1:8080. Kama tayari unatumia njia ya kuelekeza (route) programu nyingi za Docker kwenye mashine hiyo, Traefik yenye TLS ya kiotomatiki kwa programu nyingi ndiyo inayofaa zaidi: block moja ya label hutayarisha cheti na kuelekeza chat.example.com kwenda Open WebUI. Kanuni kutoka sehemu ya usalama bado inatumika — proxy inamiliki port ya umma na login, wakati Ollama inabaki kwenye localhost na 8080 ya Open WebUI inabaki ikiwa imefungwa na firewall.

Tumia endpoint inayofanana na OpenAI kutoka kwenye kodi yako

Ollama hutumia sehemu ya OpenAI chat API kwenye /v1, hivyo maktaba nyingi za OpenAI hufanya kazi baada ya kubadilisha vitu viwili: base URL na key isiyo na matumizi.

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 inahitajika na maktaba ya client lakini Ollama haiiangali, hivyo maandishi yoyote yanafanya kazi. model lazima iwe jina ambalo tayari umelivuta; jina lisilojulikana hutoa model "x" not found, try pulling it first. Kutumia curl ni sawa na hiyo hiyo:

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

Hii ndiyo njia ya kuunganisha model kwenye zana za agent na editor. Kama tayari unafanya kazi kwenye mashine hiyo, model ya ndani inaweza kusaidia scripts na plugins pamoja na Claude Code inayojiendesha kwenye VPS ndani ya tmux, ikitenganisha kazi za ndani na za faragha na API ya kulipia huku ukiacha kazi nzito za kufikiri kwa model iliyohifadhiwa.

Njia za kushindwa, pamoja na maandishi halisi utakayoyaona

Mchakato unauawa ("Killed") katikati ya kutengeneza. Unaanza kutumia modeli kubwa na terminal inaonyesha Killed, au log ya seva inaonyesha llama runner process has terminated: signal: killed. Linux OOM killer imesitisha mchakato kwa sababu modeli inahitaji RAM zaidi ya inayopatikana kwenye mashine. Thibitisha chanzo kwa kutumia sudo dmesg | grep -i oom, ambapo utaona mstari kama Out of memory: Killed process ... (ollama). Suluhisho ni kutumia modeli ndogo zaidi au iliyofanyiwa quantization kubwa zaidi — llama3.2:3b badala ya 13B — au kuongeza swap ili mzigo unaozidi RAM ya kawaida uweze kuendelea kwa mwendo wa polepole badala ya kufeli. Swap inabadilisha mwisho wa ghafla kuwa jibu la polepole; haifanyi modeli ya 70B iwe inayofanyika kazi kwenye RAM ya 4 GB.

"Error: model requires more system memory". Ollama inakataa kuanza modeli na inaonyesha Error: model requires more system memory (X GiB) than is available (Y GiB). Hii ni njia ya staha ya hitilafu iliyotajwa hapo juu: Ollama imefanya hesabu na kusitisha mchakato badala ya kuruhusu OOM killer ifanye hivyo. Inakupa namba mbili hata. Chagua modeli ambayo mahitaji yake ni chini ya RAM yako iliyo wazi (hakiki kwa free -h), punguza urefu wa context, au hamia kwenye VPS kubwa zaidi. Hakuna flag inayoweza kufanya modeli ifanane na uwezo wa kumbukumbu — kumbukumbu ni halisi.

Token ya kwanza inachukua muda mrefu, kisha inakuwa sawa. Model mpya (cold model) haitoi maandishi yoyote kwa sekunde 5 hadi 30, kisha inaanza kutuma data kawaida. Kusimama huko ni kwa sababu ya uzito (weights) kupakia kutoka kwenye diski kwenda kwenye RAM kwa mara ya kwanza, na hifadhi ya kasi ndogo inafanya hali hiyo kuwa mbaya zaidi. Baada ya kupakiwa, modeli inabaki kwenye kumbukumbu kwa muda wa OLLAMA_KEEP_ALIVE, hivyo swali la pili linajibu papo hapo. Ongeza thamani hiyo ikiwa mivurugiko hiyo inakukera, na tumia ollama ps kuona kama modeli imepakiwa kwa sasa.

Kila kitu ni cha polepole tu. Token kumi kwa sekunde au chini zaidi, bila hitilafu yoyote. Hiyo ni CPU inference inayofanya kazi yake ya kawaida. ollama ps inaonyesha 100% CPU, ikimaanisha hakuna GPU. Hii siyo hitilafu na hakuna mipangilio inayoweza kuifanyia marekebisho, kwa sababu kikomo ni bandwidth ya kumbukumbu, siyo upungufu wa mipangilio. Tumia modeli ndogo, kubali kasi hiyo, au hamia kwenye instance ya GPU — na upime kasi yako halisi kwa --verbose kabla ya kuamua kuwa kuna kitu kilichoharibika.

Connection refused kutoka mashine nyingine. Kutoka kwenye laptop yako unapata curl: (7) Failed to connect to <ip> port 11434: Connection refused. Hii inafanya kazi kama ilivyokusudiwa: Ollama inafungua localhost pekee. Usi "irekebishe" kwa kufungua 0.0.0.0, ambayo ni kosa la usalama lililotajwa hapo juu. Badala yake, fikia modeli kupitia VPN au kupitia proxy inayotoa uthibitisho (authenticating proxy).

Umeifichua 11434 kwenye mtandao. Ikiwa uliweka OLLAMA_HOST=0.0.0.0, ukafungua firewall, na sasa unaona modeli zinazovutwa ambazo hukuanza kuzitumia au CPU imefika 100% kwa sababu ya wateja wasiojulikana, basi umegundulika na kutumiwa. Hili ni kosa kuu, siyo tatizo la nadra. Rebind kwenye 127.0.0.1 au anwani ya VPN, funga 11434 kwenye firewall, na weka uthibitisho (authentication) mbele. Chukulia kuwa kitu chochote kinachofikiwa kwenye anwani hiyo wakati ilikuwa wazi kiliulizwa na watu wasiojulikana.

Backups and upgrades

Hakuna data nyingi za kupoteza. Mifano (models) inaweza kupakuliwa tena, hivyo vitu pekee vya kuhifadhi ni volume ya data ya Open WebUI — akaunti, historia ya mazungumzo, mipangilio — na faili yoyote ya systemd drop-in uliyoiunda. Nakili volume kwa kutumia container ya muda:

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

Sasisha Ollama kwa kuendesha tena script ya uinstal; sasisha Open WebUI kwa kutumia docker pull ghcr.io/open-webui/open-webui:main kisha uunde upya container. Usifunge (pin) toleo lolote kwa muda mrefu: ubora wa model na mazingira ya utendaji (runtime) hubadilika haraka, hivyo soma maelezo ya toleo (release notes) na ufanye majaribio mapya (re-benchmark) kwenye mashine yako badala ya kuamini takwimu za robo mwaka iliyopita.

FAQ

Je, ninaweza kuendesha LLM kwenye VPS inayotumia CPU pekee?

Ndiyo, lakini kuna mipaka. Mifano midogo iliyofanyiwa quantization (3B hadi 8B) inaweza kuendeshwa kwenye CPU. Mifano hii ni muhimu kwa kuandika rasimu, kufupisha maandishi, na uainishaji — ingawa ni ya polepole, ikitoa tokens chache kwa sekunde kwenye vCPU ya pamoja. Mifano kuanzia 13B juu ni ya polepole sana au haitatosha kwenye RAM. Kwa kasi kubwa au mifano mikubwa, unahitaji instance yenye GPU.

Je, kila modeli inahitaji RAM kiasi gani?

Sheria ya jumla kwa modeli za 4-bit quantized: takriban 0.5 GB ya RAM kwa kila bilioni ya parameters kwa ajili ya weights, pamoja na takriban 1 GB ya overhead na kiasi kidogo zaidi kwa context. Kwa hivyo, modeli ya 3B inahitaji takriban 4 GB, modeli ya 7-8B inahitaji takriban 8 GB, na modeli ya 14B inahitaji takriban 16 GB. Angalia nafasi yako iliyobaki kwa kutumia free -h na aache nafasi kwa ajili ya mfumo wa uendeshaji (OS) na programu nyingine.

Je, Ollama API ina ulinzi wa utambulisho (authentication)?

Hapana. Ollama haina utambulisho wa ndani, API key, au kikomo cha matumizi (rate limit) — mtu yeyote anayeweza kufikia port 11434 anao udhibiti kamili. Hii ndiyo sababu inafunga 127.0.0.1 kwa kimawazo (default) na kwa nini usifungue port 11403 kwenye 0.0.0.0 kwa mtandao wa nje. Isumbue (reach) ndani ya mashine, kupitia VPN ya ndani, au kupitia reverse proxy inayoongeza utambulisho.

Je, nawezaje kuongeza interface ya chat ya wavuti?

Endesha Open WebUI kwenye Docker ukitumia --network=host ili ishiriki loopback ya host na ifikie Ollama asilia kwenye http://127.0.0.1:11434. Kisha weka TLS reverse proxy mbele ya port 8080 kwa ajili ya ufikiaji kutoka kwenye laptop yako. Weka 8080 ikiwa imefungwa kwenye firewall ili proxy iwe njia pekee ya nje. Akaunti ya admin ya Open WebUI ndiyo inayotoa utambulisho, na unaweka nywila yako wakati wa kuanza kwa mara ya kwanza.

Je, nawezaje kuitumia kutoka kwenye programu yangu?

Tumia endpoint inayozingatia OpenAI kwenye http://127.0.0.1:11434/v1. Elekeza OpenAI SDK yoyote kwenye URL hiyo, tumia maandishi yoyote kama API key kwa sababu haitumiwi, na uweke model kuwa jina la modeli uliyopakua. Code za OpenAI zilizopo kwa kawaida zinafanya kazi bila kubadilishwa, isipokuwa kwa kubadilisha base URL na key.