Ollama o llama.cpp sa VPS: Alin ang Dapat Gamitin?

Ollama kumpara sa llama.cpp: aling layer ang gusto mong patakbuhin?

Hindi magkatunggali ang Ollama at llama.cpp sa paraang ipinahihiwatig ng tanong. Ang llama.cpp ang inference engine: naglo-load ito ng model file at ginagawang tokens ang prompt. Ang Ollama naman ay model manager, background daemon, at HTTP API na nakapatong sa engine na iyon. Inililista pa rin ng README ng Ollama ang llama.cpp bilang inference backend nito (sinuri noong 2 August 2026). Kaya ang tunay na tanong ay kung aling layer ang gusto mong patakbuhin sa iyong VPS, hindi kung alin ang mas mabilis.

Patakbuhin ang Ollama kung gusto mo ng service na kumukuha ng mga model batay sa pangalan at patuloy na gumagana nang hindi kailangang bantayan. Direktang patakbuhin ang llama.cpp kapag maliit ang box at kailangan mong piliin ang eksaktong model file, eksaktong context size, at eksaktong thread count, dahil sa maliit na VPS, memory ang kumukonsumo sa bawat isa sa mga setting na iyon—memory na wala ka.

Ano talaga ang bawat proyekto

Ang llama.cpp ay isang C at C++ implementation ng transformer inference na binuo sa ggml library. Nagbabasa ito ng mga GGUF file. Ang GGUF (GGML universal file format) ay isang single-file container na naglalaman ng weights, tokeniser, at metadata na kailangan ng engine para patakbuhin ang model. May magkakahiwalay na binary ang proyekto para sa magkakaibang gawain. Ang llama-server ay isang HTTP server, ang llama-cli ay isang interactive prompt, at sinusukat ng llama-bench ang throughput. Tinutukoy ang releases batay sa build number, hindi sa semantic version. Ang kasalukuyang tag ay b10224, na inilabas noong 2 August 2026, at may bagong tag sa karamihan ng mga araw ng trabaho.

Ang Ollama ay isang Go program. Isang background daemon, na sinisimulan gamit ang ollama serve, ang naglo-load ng mga model at sumasagot sa HTTP requests, habang isang command line client ang kumokonekta sa daemon na iyon. Sa likod ng dalawang ito ay isang registry sa ollama.com na naglalaman ng mga prepacked model. Gumagamit ang Ollama ng semantic versions, at inilabas ang v0.32.5 noong 27 July 2026. Kinukuha ng ollama pull ang isang GGUF kasama ang prompt template at set ng mga default parameter, pagkatapos ay iniimbak ito sa /usr/share/ollama/.ollama/models sa Linux. Nasa root disk ang mga file na ito at umaabot sa ilang gigabyte bawat isa. Kaya sa isang VPS na may 25 GB root volume, mahalagang malaman kung ano ang iniiwan ng pull at kung paano ilipat sa ibang lokasyon ang model directory bago mapuno ng ikatlong download ang disk.

Iyan ang buong pagkakaiba ng packaging. Si Ollama ang nagpapasya para sa iyo sa quantisation, template, at context length, at binibigyan ka nito ng isang pangalan na kailangang tandaan. Walang ipinapasya ang llama.cpp at binibigyan ka nito ng mga flag.

Axis 1: kontrol sa modelo at quantisation

Pinapaliit ng quantisation ang bawat weight mula 16 o 32 bits tungo sa 4, 5, o 8 bits. Dahil dito, kasya sa RAM ng karaniwang VPS ang modelong may 8 bilyong parameter. Madaling basahin ang GGUF naming kapag alam mo ang pattern: ang Q4_K_M ay 4-bit K-quant na medium ang laki. Kapag mas mataas ang numero, mas maraming precision ang napapanatili at mas maraming memory ang ginagamit.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Iyan ang mga na-publish na laki ng file sa bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository sa Hugging Face, na binasa noong 2 August 2026 at kino-convert mula bytes tungo sa GiB. May 6 build ng isang modelo, at ang pinakamaliit ay 2.96 GiB kumpara sa 7.95 GiB para sa pinakamalaki. Ang karaniwang default na Q4_K_M ay 4.58 GiB. Sa 4 GiB na VPS, ang pagpiling ito lamang ang magpapasya kung maglo-load ang modelo. Kalahati lamang ng desisyong iyon ang laki, dahil ang row na kaya ng iyong resources ay hindi awtomatikong row na sulit gamitin, at ipinapakita ng aktuwal na gastos ng Q4, Q8, at fp16 sa kalidad ng sagot kung may mapapansin kang pakinabang sa dagdag na gigabytes.

Sa llama.cpp, tinutukoy mo ang file, kaya ikaw mismo ang pumipili ng row.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

Ang -c ay ang context size sa tokens, ang -t ay ang bilang ng threads, at tinutukoy ng -ngl kung ilang layer ang ililipat sa GPU (0 sa CPU-only na machine). Walang awtomatikong hinuhulaan para sa iyo.

Sa Ollama, kasama ang quantisation sa tag na iyong dina-download, at ipinapakita ng ollama ls kung ano talaga ang nasa disk. Kapag walang build na kailangan mo sa registry, mag-import ng GGUF nang mag-isa. Gumawa ng Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Pagkatapos, i-build ito at suriin ang resulta:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Ang context length ang setting na kadalasang nagdudulot ng problema. Pinipili ng Ollama ang default batay sa available na VRAM, at ang machine na walang GPU ay napupunta sa pinakamaliit na bucket: 4096 tokens. Kapag nagpadala ka rito ng dokumentong may 20,000 token, itinatapon ang sobrang tokens bago pa man ito makita ng modelo, kaya maaaring maging kumpiyansa ngunit mali ang sagot tungkol sa file na bahagya lamang nitong nabasa. Itaas ito gamit ang OLLAMA_CONTEXT_LENGTH sa daemon, o gamit ang PARAMETER num_ctx sa isang Modelfile. Kung isang job lamang ang nangangailangan ng mas malaking window, maaaring itakda ang num_ctx sa bawat request sa halip na sa buong server, kaya hindi napupunta ang dagdag na cache sa iba pang gawain ng daemon. Wala ring default sa llama.cpp na dapat basta pagkatiwalaan. Itakda nang tahasan ang -c at alamin kung ano ang iyong itinakda.

Ang memory arithmetic na hindi ipinapakita sa iyo

Hindi lamang ang model file ang buong resource cost. Ang KV cache (key/value cache) ay naglalaman ng isang entry bawat layer para sa bawat token ng context, at lumalaki ito habang humahaba ang conversation.

Kuwentahin natin ito para sa Llama 3.1 8B. May 32 layer, 8 key/value head, at head dimension na 128 ang model. Ang bawat token ay nag-iimbak ng key at value na tig-2 byte sa f16, kaya 2 x 8 x 128 x 2 = 4096 byte bawat layer. Sa 32 layer, katumbas ito ng 128 KiB bawat token. Kaya ang 4096 token na context ay kumokonsumo ng 512 MiB, at ang 32,768 token na context ay kumokonsumo ng 4 GiB.

Kaya ang Q4_K_M 8B model sa 4k context ay nangangailangan ng humigit-kumulang 4.58 GiB para sa weights, dagdag ang humigit-kumulang 0.5 GiB para sa cache at ang runtime mismo. Hindi ito kasya sa 4 GiB na RAM. Kasya ito sa 8 GiB, na may natitirang puwang para sa iba pang gawain. Kung itataas mo ang context sa 32k sa parehong 8 GiB na machine, uubusin ng cache lamang ang headroom. I-monitor ito habang tumatakbo gamit ang free -h habang naka-load ang model, at huwag magtiwala sa estimate na hindi mo sinukat. Kung nagso-size ka para sa model na higit na malaki sa 8B, ipinapakita ng parehong arithmetic sa isang 27B model sa CPU-only VPS kung ano talaga ang kayang hawakan ng bawat tier mula 8 hanggang 64 GB.

Pinapalala ito ng Ollama. Naka-default sa 1 ang OLLAMA_NUM_PARALLEL, at ang memory na kailangan ng isang model ay lumalaki ayon sa bilang na iyon na minultiply sa context length. Kapag sabay mong tinaasan ang dalawang ito, tahimik na hihingi ang daemon ng ilang ulit ng RAM na inaasahan mo. Itinatakda rin ng parehong arithmetic ang limitasyon mo sa sabay-sabay na users, dahil kailangan ng bawat concurrent request ng sariling bahagi ng KV cache. Ito ang dahilan kung bakit ang server na maayos para sa isang tao ay bumabagal kapag lima na ang gumagamit.

Axis 2: ang daemon na kailangan mong patakbuhin

Gumagawa ang Ollama install script ng systemd unit, lumilikha ng ollama system user, at ine-enable ang service. Nakakakuha ka ng lifecycle management nang hindi kailangang isulat ang alinman dito. Sa systemd ginagawa ang configuration:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

Mas mahalaga ang OLLAMA_KEEP_ALIVE sa isang CPU VPS kaysa sa ibang environment. Bilang default, nananatili sa memory ang mga model nang 5 minuto at pagkatapos ay ina-unload. Kailangang basahin ng susunod na request ang buong file mula sa disk bago ito makasagot, kaya ang 4.58 GiB reload ay maaaring magpahaba sa dalawang segundong reply hanggang tatlumpung segundo kapag mabagal ang storage. Inaayos ng mahabang keep-alive ang latency, pero permanenteng kumokonsumo ito ng RAM. Pareho itong tunay na gastos. Piliin kung alin ang mas kaunti ang epekto. Kung gusto mong manatiling resident ang model, ilang linya lang ang kailangan sa pag-set ng keep_alive para manatili ito sa idle periods at pagkatapos ng mga reboot, at hindi mo na kailangang manual na i-warm up ang model sa tuwing magre-restart ang server.

Walang daemon ang llama.cpp, kaya ikaw mismo ang gagawa ng unit bilang /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

I-enable ito gamit ang sudo systemctl enable --now llama-server. Hawak ng process ang model sa buong lifetime nito. Walang nag-u-unload kapag idle, kaya walang hindi inaasahang reload at walang paraan para mabawi ang memory maliban sa paghinto ng service. Kung bago sa iyo ang paggawa ng units, pareho ito ng pattern ng pagpapatakbo ng sarili mong services gamit ang systemd sa isang VPS.

Axis 3: ang API na gagamitin ng iyong app

Malaki na ang ipinayat ng axis na ito. Parehong gumagamit ngayon ang dalawang proyekto ng OpenAI chat format, kaya karaniwang gumagana ang karamihan ng client library sa alinman sa mga ito matapos palitan ang base URL.

Nakikinig ang Ollama sa 127.0.0.1:11434. Ang OpenAI-compatible route nito ay http://localhost:11434/v1/chat/completions, at mayroon din itong native API sa /api/chat. May dokumentado rin itong Anthropic-compatible route.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

Nakikinig ang llama-server sa 127.0.0.1:8080 at naghahatid ng /v1/chat/completions, /v1/completions, at /v1/embeddings, kasama ang sarili nitong /completion endpoint at built-in web UI. Naglalantad din ito ng mga operational route na wala sa Ollama: /health para sa readiness probe, /props para sa settings ng naka-load na model, /slots para makita ang ginagawa ng bawat request slot, at /metrics sa Prometheus format. Kung plano mong i-monitor ang service na ito, malamang na ang pagkakaibang ito ang magiging batayan ng iyong desisyon.

Wala sa dalawang server ang awtomatikong nag-e-enable ng authentication para sa iyo. Pareho silang nagde-default sa loopback, at may mabuting dahilan ito. I-access sila sa pamamagitan ng SSH tunnel o sa likod ng reverse proxy, at huwag kailanman buksan sa internet ang 11434 o 8080.

Ano ang makatwirang magagawa ng CPU-only VPS

Mabagal magpatakbo ng maliliit na modelo ang CPU-only VPS. Iyan ang tapat na buod. Ang mahalagang bahagi ay malaman kung nasaan ang limitasyon. Magsukat muna bago magdisenyo ng anumang nakabatay rito:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

Ang column na pp ay ang bilis ng pagproseso ng prompt, at ang column na tg ay ang bilis ng pagbuo ng token. Pareho itong sinusukat sa tokens per second. Sa isang shared vCPU plan, karaniwang nasa mababang single digits ang tg ng 8B model na nasa Q4_K_M. Ang prompt processing ang pinakaramdam na bottleneck. Pinoproseso muna ang buong prompt bago lumabas ang unang output token. Kaya bawat request ay may dagdag na paghihintay kapag mahaba ang system prompt. Ang haba ng reply ang bahagi ng latency na makokontrol mo. Sa bilis na tatlong tokens kada segundo, tatlong minuto ginagamit ng isang modelong paulit-ulit at umabot sa 600 tokens. Kaya ang paglilimita sa output gamit ang num_predict ang pinakamurang paraan para hindi maging timeout ang isang sobrang mahabang sagot.

Magagamit sa CPU ang 1B hanggang 4B model para sa classification, extraction, maiikling summary, o routing. Lumalabas ang mga reply sa loob ng ilang segundo, at kasya ang memory requirement sa karaniwang plan. Para sa aktuwal na halimbawa sa ganitong laki sa halip na size range, ipinapakita ng Nemotron 3.5 Lightning na na-pull at nasukat sa isang VPS ang eksaktong tag, ang aktuwal na RAM requirement nito, at ang bilis na napapanatili nito nang walang GPU. Hindi praktikal sa CPU ang interactive chat na kasabay ng bilis ng pagbabasa, coding assistants, pagproseso ng mahahabang dokumento, o anumang agent loop na maraming magkakasunod na call. Ang loop na gumagawa ng labindalawang call na tig-apat na segundo ay tumatagal ng isang minuto bago makagawa ng output. Kung coding assistant talaga ang kailangan, ipinapaliwanag ng pagkonekta ng agent sa modelong ikaw mismo ang nagho-host kung aling mga task ang tunay na mahusay gawin ng maliit na lokal na model at alin ang dapat manatili sa hosted API.

May dalawang opsyon kapag hindi sapat ang mga resulta. Kung concurrency ang problema, ibig sabihin ay maraming user ang sabay-sabay na gumagamit ng isang model, nagbabago ang engine choice. Saklaw ito ng paghahambing ng Ollama at vLLM para sa concurrent serving. Kung raw speed ang problema, ang sagot ay isang VPS na may nakakabit na GPU, kung saan may kabuluhan na ang -ngl. Bago gawin ang alinman sa mga ito, kumuha muna ng baseline para sa hardware mismo. Nakaaapekto sa load time ang disk at memory bandwidth nang halos kasinglaki ng epekto ng CPU. Sulit ang isang oras para sa paulit-ulit at nasusukat na VPS benchmark.

Mag-install ng llama.cpp na naka-pin sa isang build

Parehong lingguhang naglalabas ng mga update ang dalawang project, kaya itala ang bersiyong dineploy mo. Ini-install ng upstream one-liner ang kasalukuyang build:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Para mag-pin ng partikular na build, kunin na lang ang prebuilt tarball mula sa releases page. Ang build b10224 ang kasalukuyang tag noong 2 August 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

O i-build ang parehong tag mula sa source:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev ang dokumentadong dependency para sa HTTPS features. Ilang minuto ang compile at nangangailangan ito ng mas maraming RAM kaysa sa iniaalok ng pinakamaliliit na plan, kaya mag-build sa mas malaking machine at kopyahin ang mga binary kung maubusan ng resources ang maliit na machine.

Mag-install ng Ollama gamit ang naka-pin na version

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Binabasa ng script ang OLLAMA_VERSION, kaya maaari mong gamitin ang isang release na alam mong stable sa halip na tanggapin ang anumang inilabas ngayong umaga. Na-publish ang v0.32.5 noong 27 July 2026. May manual na paraan din kung ayaw mong mag-pipe ng script papunta sa shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Hindi gumagawa ang manual na paraan ng systemd unit o service user, kaya ikaw ang kailangang magdagdag ng mga ito. Sinasaklaw ng buong walkthrough sa Ollama sa isang VPS ang pag-set up ng service na ito nang sunod-sunod.

Mga failure mode at mga string na makikita mo

Tumangging i-load ni Ollama ang model. Nagbabalik ang ollama run ng linyang ganito:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Sinusuri ni Ollama ang size bago mag-load, kaya mabilis itong nagfa-fail at ipinapakita ang dahilan. Lumipat sa kasunod na quantisation row, bawasan ang context length, o pumili ng mas maliit na model.

Hindi nagfa-fail ang llama.cpp; napakabagal lang nito. Bilang default, memory-mapped ng llama.cpp ang GGUF, kaya nagsisimula pa rin ang file kahit mas malaki ito sa RAM. Pagkatapos, paulit-ulit na nagpa-page in at out ang kernel ng weights mula sa disk sa bawat token, kaya umaabot sa ilang segundo bawat token ang generation habang 100 percent ang paggamit ng disk. I-pass ang --no-mmap upang pilitin ang aktuwal na allocation. Sa ganitong paraan, agad itong magfa-fail sa halip na unti-unting bumagal. Kapag kumilos ang kernel, ipinapakita ng dmesg ang dahilan:

Out of memory: Killed process 1234 (llama-server)

Hindi talaga naglo-load ang model file. Kapag ang GGUF ay ginawa para sa model family na mas bago kaysa sa engine mo, nagbabalik ito ng error na nagsasaad ng architecture na hindi nito kilala:

error loading model architecture: unknown model architecture: 'qwen3next'

Ang solusyon ay mag-upgrade ng engine, hindi gumamit ng ibang file. Ito ang kapalit ng pag-pin, at ito ang dahilan kung bakit dapat mong itala ang build number. Kailangan mong malaman kung anong bersyon ang iyong ina-upgrade.

Sumasagot ang API locally pero hindi mula sa app mo. Nagba-bind si Ollama sa 127.0.0.1:11434, kaya connection refused ang matatanggap ng ibang host. I-set ang OLLAMA_HOST=0.0.0.0:11434 sa pamamagitan ng systemctl edit ollama kapag nasa likod lamang ng firewall o private network ang port, dahil walang authentication ang API.

Napakabagal ng unang reply pagkatapos ng pause. Naganap ang idle unload makalipas ang 5 minute, kaya binabasa muli mula sa disk ang model. Ipinapakita ng ollama ps na patakbuhin kaagad bago ang request na walang naka-load, na nagpapatunay nito. Itaas ang OLLAMA_KEEP_ALIVE.

Kaya alin ang dapat mong patakbuhin?

Patakbuhin ang Ollama kapag gusto mong ito na ang mag-manage ng mga model para sa iyo at magbigay ng OpenAI-shaped endpoint nang walang dagdag na configuration. Ito ang tamang default para sa unang deployment at para sa mga sitwasyong madalas magbago ang model na ginagamit.

Patakbuhin nang direkta ang llama.cpp kapag sapat na limitado ang memory kaya kailangan mong ikaw mismo ang pumili ng quantisation row, kapag kailangan mo ang /health, /slots at /metrics para sa monitoring, o kapag kailangan mo ng flag na hindi inilalantad ng Ollama. Ito ang praktikal na pagpili sa isang VPS kung halos kasya lamang ang model, dahil ang mga setting na nagpapakasya rito ay siya ring mga setting na pinipili ng Ollama para sa iyo.

Normal lang na patakbuhin ang dalawa. Gamitin ang Ollama para sa mga eksperimento at ang llama.cpp para sa iisang model na inilagay mo sa production at ayaw mong awtomatikong mapalitan.

FAQ

Ang Ollama ba ay wrapper lamang para sa llama.cpp?

Malapit, pero may aktuwal na ginagawa ang wrapper. Inililista ng README ng Ollama ang llama.cpp bilang inference backend nito (sinuri noong 2 August 2026). Bukod dito, nagdaragdag ang Ollama ng model registry, prompt template na nagko-convert ng chat messages sa prompt, set ng mga default sampling parameter, daemon na nag-a-unload kapag idle, at HTTP API. Kapag ikinumpara mo ang tokens per second gamit ang magkakaparehong setting, ikinukumpara mo ang parehong engine sa sarili nito. Ang aktuwal mong pinipili ay ang management layer.

Alin ang mas mabilis sa CPU-only VPS?

Pareho silang gumagamit ng iisang engine, kaya kapag pareho ang model file, quantisation, context size, at thread count, magkalapit ang resulta. Karaniwang nagmumula sa magkaibang default ang mga pagkakaibang iniuulat ng mga user, lalo na sa context length at thread count, hindi sa engine. Sukatin ito gamit ang llama-bench -m <file> -p 512 -n 128 at ihambing ang column na tg sa sarili mong server bago maniwala sa anumang published figure.

Maaari ko bang gamitin ang sarili kong GGUF file sa Ollama?

Oo. Ilagay ang file sa server, gumawa ng Modelfile na ang unang linya ay FROM ./your-model.gguf, idagdag ang anumang PARAMETER line na kailangan mo gaya ng num_ctx, at pagkatapos ay patakbuhin ang ollama create your-name -f ./Modelfile. Ililista ito ng ollama ls kasama ng anumang na-pull mo mula sa registry. Ganito gamitin ang quantisation na wala sa registry.

Gaano karaming RAM ang kailangan ko para sa 8B model?

Ilaan ang laki ng file, kasama ang KV cache at runtime. Ang Q4_K_M build ng Llama 3.1 8B ay humigit-kumulang 4.58 GiB sa disk, at nagdaragdag ang 4096 token context ng tinatayang 512 MiB na cache. Kaya komportable ang 8 GiB na RAM, ngunit hindi sapat ang 4 GiB. Lumalaki ang cache kasabay ng context: ang parehong model sa 32,768 token context ay nangangailangan ng humigit-kumulang 4 GiB na cache nang mag-isa. Sa Ollama, tandaan na lumalaki rin ang requirement kasabay ng OLLAMA_NUM_PARALLEL.