Ollama vs llama.cpp sa VPS: Alin ang Dapat Patakbuhin?

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

Hindi magkalaban ang Ollama at llama.cpp sa paraang ipinahihiwatig ng tanong. Ang llama.cpp ang inference engine: nilo-load nito ang 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 i-operate sa iyong VPS, hindi kung alin ang mas mabilis.

Patakbuhin ang Ollama kung gusto mo ng service na kumukuha ng mga model ayon sa pangalan at patuloy na gumagana nang hindi kailangang bantayan. Patakbuhin naman nang direkta 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, kumokonsumo ng memory ang bawat setting na iyon na maaaring wala ka.

Ano talaga ang bawat proyekto

Ang llama.cpp ay isang C at C++ implementation ng transformer inference na nakabatay 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 upang 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 ang llama-bench ay sumusukat sa throughput. Tinatag ang mga release batay sa build number, hindi sa semantic version. Ang kasalukuyang tag ay b10224, na inilathala noong 2 August 2026, at may bagong tag sa karamihan ng mga araw ng trabaho.

Ang Ollama ay isang Go program. Ang background daemon, na sinisimulan gamit ang ollama serve, ay naglo-load ng mga model at sumasagot sa mga HTTP request, habang ang command line client ay kumokonekta sa daemon na iyon. Sa likod ng dalawang ito ay may registry sa ollama.com na naglalaman ng mga naka-prepack na 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 default parameters, pagkatapos ay iniimbak ito sa /usr/share/ollama/.ollama/models sa Linux.

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

Axis 1: kontrol sa model at quantisation

Pinapaliit ng quantisation ang bawat weight mula 16 o 32 bits hanggang 4, 5, o 8 bits. Dahil dito, kasya ang model na may 8 billion parameters sa RAM ng ordinaryong VPS. 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 kailangan.

[
  {
    "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 file size sa repositoryong bartowski/Meta-Llama-3.1-8B-Instruct-GGUF sa Hugging Face, na binasa noong 2 August 2026 at kino-convert mula bytes tungo sa GiB. May 6 build ng isang model, 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 ang nagdedesisyon kung maglo-load ba ang model.

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 huhulaan para sa iyo.

Sa Ollama, kasama ng tag na pini-pull mo ang quantisation, at ipinapakita ng ollama ls kung ano talaga ang nasa disk. Kapag wala sa registry ang build na kailangan mo, ikaw mismo ang mag-import ng GGUF. Sumulat 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 madalas nakakalito. Pinipili ng Ollama ang default nito 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, inaalis ang mga sobrang token bago pa man ito makita ng model. Dahil dito, maaaring maging kumpiyansa ngunit mali ang sagot tungkol sa file na kalahati lamang nitong nabasa. Itaas ito gamit ang OLLAMA_CONTEXT_LENGTH sa daemon, o gamit ang PARAMETER num_ctx sa Modelfile. Wala ring default na maaasahan sa llama.cpp. Itakda nang tahasan ang -c at tiyaking alam mo kung ano ang itinakda mo.

Ang arithmetic ng memory na madalas hindi ipinapakita

Hindi lamang ang model file ang kumokonsumo ng resources. Ang KV cache (key/value cache) ay naglalaman ng isang entry para sa bawat layer at bawat context token. Lumalaki ito habang humahaba ang conversation.

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

Dahil dito, ang Q4_K_M 8B model na may 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 espasyo para sa iba pang gawain. Kung itataas mo sa 32k ang context sa parehong 8 GiB na machine, mauubos ng cache lamang ang headroom. I-monitor ito habang tumatakbo gamit ang free -h kapag loaded ang model, at huwag magtiwala sa estimate na hindi mo sinukat. Kung nagse-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 kasya sa bawat tier mula 8 hanggang 64 GB.

Pinaparami pa ito ng Ollama. Ang OLLAMA_NUM_PARALLEL ay may default na 1, at ang memory na kailangan ng isang model ay lumalaki ayon sa bilang na iyon na minumultiply sa context length. Kapag sabay mong itinaas ang dalawa, tahimik na hihingi ang daemon ng ilang ulit ng RAM na inaasahan mo. Ang parehong arithmetic ang nagtatakda ng limitasyon sa sabay-sabay na users, dahil kailangan ng bawat concurrent request ng sarili nitong bahagi ng KV cache. Ito ang dahilan kung bakit maayos ang takbo ng server para sa isang tao pero bumabagal kapag lima na.

Axis 2: ang daemon na kailangan mong i-operate

Gumagawa ang Ollama install script ng systemd unit, lumilikha ng ollama system user, at ini-enable ang service. May lifecycle management ka nang hindi kailangang isulat ang alinman dito. Dumadaan sa systemd 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. Nananatili sa memory ang mga model nang 5 minuto bilang default at pagkatapos ay dini-unload. Kailangang basahin muli 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 at maging tatlumpung segundo sa mabagal na storage. Inaayos ng mahabang keep-alive ang latency, pero permanenteng ginagamit nito ang RAM. Parehong may tunay na cost ang mga ito. Piliin ang opsyong mas kaunti ang epekto sa iyo.

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 biglaang reload at walang paraan para mabawi ang memory maliban sa paghinto ng service. Kung bago sa iyo ang pagsusulat ng mga unit, kapareho ito ng pattern sa pagpapatakbo ng sarili mong mga service gamit ang systemd sa isang VPS.

Axis 3: ang API na kokontakin ng app mo

Mas lumiit na nang malaki ang pagkakaiba sa axis na ito. Parehong gumagamit ngayon ang dalawang project ng OpenAI chat format, kaya gumagana ang karamihan ng client library sa alinman sa mga ito pagkatapos lang 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 nagsisilbi ng /v1/chat/completions, /v1/completions, at /v1/embeddings, pati ng sarili nitong /completion endpoint at built-in web UI. Naglalantad din ito ng operational routes na wala sa Ollama: /health para sa readiness probe, /props para sa settings ng naka-load na model, /slots para makita kung ano ang ginagawa ng bawat request slot, at /metrics sa Prometheus format. Kung plano mong i-monitor ang service na ito, malamang na ang pagkakaibang iyon ang magpapasya sa pipiliin mo.

Walang server na awtomatikong nag-e-enable ng authentication para sa iyo. Pareho silang naka-default sa loopback, at may mabuting dahilan ito. I-access ang mga ito sa pamamagitan ng SSH tunnel o mula sa likod ng reverse proxy, at huwag na huwag buksan sa internet ang 11434 o 8080.

Ano ang makatotohanang magagawa ng CPU-only VPS

Mabagal magpatakbo ng maliliit na model ang CPU-only VPS. Iyan ang tapat na buod. Ang mahalagang malaman ay kung saan ang limitasyon. Magsukat muna bago magdisenyo ng anuman batay rito:

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

Ang column na pp ay bilis ng pagproseso ng prompt, at ang column na tg ay bilis ng pagbuo ng token. Pareho itong sinusukat sa tokens per second. Sa isang shared vCPU plan, ang 8B model sa Q4_K_M ay karaniwang nasa mababang single digits para sa tg. Ang pagproseso ng prompt ang pinakamabigat na bahagi: kailangang iproseso ang buong prompt bago lumabas ang unang output token, kaya ang mahabang system prompt ay nagdaragdag ng paghihintay sa bawat request.

Magagamit sa CPU: isang 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 isang karaniwang plan. Hindi praktikal sa CPU: interactive chat sa bilis ng pagbabasa, coding assistant, pagproseso ng mahahabang dokumento, o anumang agent loop na sunod-sunod na gumagawa ng maraming call. Ang loop na gumagawa ng labindalawang call na tig-apat na segundo ay aabutin ng isang minuto bago makagawa ng anuman. Kung coding assistant pa rin ang plano, ipinapakita ng pagpapatakbo ng agent gamit ang model na ikaw mismo ang nagho-host kung aling mga task ang tunay na mahusay gawin ng maliit na local model at kung alin ang kailangang manatili sa hosted API.

May dalawang opsyon kapag hindi gumagana ang mga numero. Kung concurrency ang problema—maraming user ang sabay-sabay na gumagamit ng iisang model—magbabago ang engine na dapat gamitin, at tinatalakay ito sa 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 nagsisimulang magkaroon ng saysay ang -ngl. Bago gawin ang alinman dito, kumuha muna ng baseline para sa hardware mismo, dahil nakaaapekto ang disk at memory bandwidth sa load time gaya ng CPU. Makabuluhan ang isang oras para sa repeatable na VPS benchmark.

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

Parehong naglalabas ng bagong version ang dalawang project bawat linggo, kaya itala ang version na 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, sa halip ay kunin 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)

Ang libssl-dev ang documented dependency para sa HTTPS features. Tumatagal nang ilang minuto ang compilation at nangangailangan ito ng mas maraming RAM kaysa sa pinakamaliliit na plan, kaya mag-build sa mas malaking machine at kopyahin ang mga binary kung maubusan ng resources ang maliit na server.

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 panatilihin ang isang subok nang release sa halip na awtomatikong gamitin ang 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 ginagawa ng manual na paraan ang systemd unit o ang service user, kaya ikaw mismo ang kailangang magdagdag ng mga ito. Saklaw ng buong walkthrough ng Ollama sa isang VPS ang pagse-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 laki bago mag-load, kaya mabilis itong nagfa-fail at ipinapakita ang dahilan. Bumaba ng isang quantisation row, bawasan ang context length, o pumili ng mas maliit na model.

Hindi nagfa-fail ang llama.cpp; mabagal itong tumakbo. Bilang default, gumagamit ang llama.cpp ng memory mapping para sa GGUF, kaya nagsisimula pa rin ang file kahit mas malaki ito kaysa sa RAM. Pagkatapos, paulit-ulit na nagpa-page ang kernel ng weights papunta at pabalik mula sa disk sa bawat token. Bumabagal ang generation sa ilang segundo bawat token, habang naka-pin sa 100 percent ang disk. Ipass 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 iyong engine, magbibigay ito ng error na nagbabanggit sa architecture na hindi nito kilala:

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

Engine upgrade ang solusyon, hindi ibang file. Ito ang kapalit ng pag-pin ng version, at ito ang dahilan kung bakit dapat mong itala ang build number. Kailangan mong malaman kung anong version ang iyong ina-upgrade.

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

Napakabagal ng unang reply matapos ang pause. Naganap ang idle unload makalipas ang 5 minuto, kaya binabasa muli ang model mula sa disk. Ang ollama ps na patatakbuhin kaagad bago ang request ay walang ipinapakitang naka-load, na nagpapatunay nito. Itaas ang OLLAMA_KEEP_ALIVE.

Alin ang dapat mong gamitin?

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

Direktang gamitin ang llama.cpp kapag sapat na kasikip ang memory na 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 tamang pagpili sa isang VPS kung halos kasya lamang ang model, dahil ang mga setting na nagpapakasya rito ay siya ring mga setting na awtomatikong pinipili ng Ollama para sa iyo.

Normal lang na gamitin ang dalawa. Ollama para sa mga eksperimento, at llama.cpp para sa isang model na inilagay mo sa production at ayaw mong awtomatikong magbago.

FAQ

Isa ba talagang wrapper lang ang Ollama 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 tungo sa prompt, mga default sampling parameter, daemon na nag-u-unload kapag idle, at HTTP API. Kapag ikinumpara mo ang tokens per second gamit ang magkakaparehong setting, ang ikinukumpara mo ay ang parehong engine sa sarili nito. Ang aktuwal na pinipili mo ay ang management layer.

Alin ang mas mabilis sa CPU-only VPS?

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

Magagamit ko ba 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, saka patakbuhin ang ollama create your-name -f ./Modelfile. Ililista ito ng ollama ls katabi ng anumang na-pull mo mula sa registry. Ito ang paraan para gumamit ng quantisation na wala sa registry.

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

I-budget ang laki ng file, KV cache, at runtime. Ang Q4_K_M build ng Llama 3.1 8B ay humigit-kumulang 4.58 GiB sa disk, at ang 4096 token context ay nagdaragdag ng tinatayang 512 MiB na cache, kaya sapat ang 8 GiB na RAM at 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 nakadepende rin ang requirement sa OLLAMA_NUM_PARALLEL.