Ollama o llama.cpp sa VPS: Alin ang Patakbuhin?

Ollama kumpara sa 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: naglo-load ito ng model file at ginagawang tokens ang prompt. Ang Ollama naman ay model manager, background daemon, at HTTP API na tumatakbo sa ibabaw ng 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 serbisyong kumukuha ng mga model gamit ang 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, kumokonsumo ng memory na wala ka ang bawat isa sa mga setting na ito.

Ano talaga ang bawat project

Ang llama.cpp ay isang implementation sa C at C++ para sa transformer inference, at nakabatay ito sa ggml library. Nagbabasa ito ng GGUF files. 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 project 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. Tinutukoy ang releases sa pamamagitan ng build number, hindi 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 parehong bahagi ay may registry sa ollama.com na naglalaman ng mga naka-prepack na model. Gumagamit ang Ollama ng semantic versions, at ang v0.32.5 ay inilabas noong 27 July 2026. Kinukuha ng ollama pull ang isang GGUF kasama ang prompt template at set ng default parameters, pagkatapos ay ini-store ito sa /usr/share/ollama/.ollama/models sa Linux.

Iyon ang buong pagkakaiba ng packaging. Ang Ollama ang nagdedesisyon para sa iyo ng quantisation, template, at context length, at nagbibigay ito ng isang pangalan na kailangan mong tandaan. Walang anumang desisyon 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 ang model na may 8 billion parameter sa RAM ng karaniwang VPS. Madaling basahin ang GGUF naming kapag alam mo ang pattern: ang Q4_K_M ay 4-bit K-quant na may medium na laki. Kapag mas mataas ang numero, mas maraming precision ang napapanatili ngunit mas malaki ang memory na 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
  }
]

Ito ang mga na-publish na file size sa bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository sa Hugging Face, na binasa noong 2 August 2026 at kinonvert 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 VPS, ang pagpiling ito ang nagtatakda kung maglo-load man ang modelo.

Sa llama.cpp, tinutukoy mo ang file, kaya ikaw mismo ang pumipili sa row na iyon.

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 thread count, at itinatakda ng -ngl kung ilang layer ang ililipat sa GPU (0 sa CPU-only na machine). Walang huhulaan para sa iyo.

Sa Ollama, kasama sa tag na hina-hatakin mo ang quantisation, at ipinapakita ng ollama ls kung ano talaga ang nasa disk. Kapag walang build na gusto mo sa registry, mag-import ka mismo ng GGUF. 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 madalas nakalilito sa mga user. Pinipili ng Ollama ang default nito batay sa available na VRAM, at napupunta ang machine na walang GPU sa pinakamaliit na bucket: 4096 tokens. Kapag nagpadala ka rito ng dokumentong may 20,000 token, ibinabawas ang sobrang tokens bago pa man ito makita ng modelo. Dahil dito, maaaring maging kumpiyansa ngunit mali ang sagot tungkol sa file na kalahati lamang ang nabasa nito. Itaas ito gamit ang OLLAMA_CONTEXT_LENGTH sa daemon, o gamit ang PARAMETER num_ctx sa Modelfile. Wala ring default sa llama.cpp na dapat basta pagkatiwalaan. Itakda nang tahasan ang -c at alamin kung ano ang itinakda mo.

Ang memory arithmetic na hindi ipinapakita sa iyo

Hindi lang ang model file ang bumubuo sa kabuuang resource cost. 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.

Kalkulahin 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. Ang 4096-token context ay nangangailangan ng 512 MiB, at ang 32,768-token context ay nangangailangan ng 4 GiB.

Kaya 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 sapat na natitirang RAM para sa ibang gawain. Kapag itinaas mo sa 32k ang context sa parehong 8 GiB na machine, mauubos ng cache lamang ang natitirang RAM. I-monitor ito nang live gamit ang free -h habang naka-load ang model, at huwag umasa sa estimate na hindi mo sinukat.

Pinalalaki pa ito ng Ollama. Ang OLLAMA_NUM_PARALLEL ay may default na 1, at ang memory na kailangan ng model ay lumalaki batay sa bilang na iyon na minumultiply sa context length. Kapag sabay mong tinaasan ang dalawang ito, tahimik na hihingi ang daemon ng RAM na ilang beses na mas marami kaysa sa inaasahan mo.

Axis 2: ang daemon na kailangan mong patakbuhin

Ang Ollama install script ay nagsusulat ng systemd unit, gumagawa ng ollama system user, at ine-enable ang service. May lifecycle management ka nang hindi ito kailangang isulat nang manu-mano. Sa systemd dumadaan 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 CPU VPS kaysa sa ibang environment. Nananatili sa memory ang mga model nang 5 minuto bilang default, pagkatapos ay ina-unload ang mga ito. 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 nang hanggang tatlumpung segundo kapag mabagal ang storage. Inaayos ng mahabang keep-alive ang latency, pero permanenteng kumokonsumo ito ng RAM. Pareho itong may tunay na cost. Piliin kung alin ang mas kaunti ang epekto sa iyo.

Walang daemon ang llama.cpp, kaya ikaw mismo ang magsusulat 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 ina-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 units, kapareho ito ng pattern sa pagpapatakbo ng sarili mong services gamit ang systemd sa isang VPS.

Axis 3: ang API na kokontakin ng iyong app

Mas lumiit na nang husto ang pagkakaiba sa axis na ito. Parehong gumagamit ngayon ang dalawang proyekto ng OpenAI chat format, kaya gagana ang karamihan ng client library sa alinman sa mga ito matapos baguhin lamang 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"}]}'

llama-server nakikinig sa 127.0.0.1:8080 at nagsisilbi 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 kung ano ang ginagawa ng bawat request slot, at /metrics sa Prometheus format. Kung plano mong i-monitor ang serbisyong ito, malamang na ang pagkakaibang ito ang magiging batayan ng iyong pagpili.

Hindi awtomatikong nagse-set up ng authentication ang alinmang server. Pareho silang nagde-default sa loopback para sa tamang dahilan. I-access ang mga ito sa pamamagitan ng SSH tunnel o mula sa likod ng reverse proxy, at huwag kailanman buksan sa internet ang 11434 o 8080.

Ano ang makatotohanang kayang gawin ng CPU-only VPS

Mabagal magpatakbo ng maliliit na model ang CPU-only VPS. Iyan ang tapat na buod, at ang mahalagang malaman ay kung saan ang limitasyon. Magsukat muna bago magdisenyo 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 ang bilis ng pagproseso ng prompt, at ang column na tg ay ang bilis ng pag-generate ng token. Pareho itong sinusukat sa tokens per second. Sa isang shared vCPU plan, karaniwang nasa mababang single digits ang 8B model na may Q4_K_M para sa tg. Ang prompt processing ang pinakaramdam: kailangang iproseso ang buong prompt bago lumabas ang unang output token, kaya nagdaragdag ng paghihintay sa bawat request ang mahabang system prompt.

Magagamit sa CPU: 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. Hindi praktikal sa CPU: interactive chat na kasabay ng bilis ng pagbabasa, coding assistants, pagproseso ng mahahabang dokumento, o anumang may agent loop na gumagawa ng maraming call nang magkakasunod. Ang loop na gumagawa ng labindalawang call na tig-apat na segundo ay umaabot ng isang minuto bago makagawa ng output.

May dalawang opsyon kapag hindi sapat ang mga numerong ito. Kung concurrency ang problema, ibig sabihin ay maraming user ang sabay-sabay na gumagamit ng isang model, kailangang baguhin ang engine, 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 maging makabuluhan ang -ngl. Bago gawin ang alinman sa mga ito, kumuha muna ng baseline para sa mismong hardware, dahil nakaaapekto sa load time ang disk at memory bandwidth gaya ng CPU. Sulit ang isang oras para sa repeatable na VPS benchmark.

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

Parehong nagbabago linggu-linggo ang dalawang project, 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 sa isang partikular na build, gamitin sa halip 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 compile at nangangailangan ito ng mas maraming RAM kaysa sa pinakamaliliit na plan, kaya mag-build sa mas malaking server at kopyahin ang binaries kung maubusan ng resources ang maliit na server.

I-install ang Ollama gamit ang itinakdang 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 ang kailangang magdagdag ng mga ito. Sinasaklaw ng Ang buong walkthrough para 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 ang anyo:

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 ipinapaliwanag ang dahilan. Bumaba ng isang quantisation row, bawasan ang context length, o pumili ng mas maliit na model.

Hindi nagfa-fail ang llama.cpp; sobrang bagal lang nito. Bilang default, mina-memory-map 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 bumabagal ang generation sa ilang segundo bawat token habang naka-pin sa 100 percent ang disk. Ipasa ang --no-mmap para 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 ginawa ang GGUF para sa model family na mas bago kaysa sa iyong engine, nagbabalik ito ng error na naglalaman 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 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 app mo. Nagbi-bind si Ollama sa 127.0.0.1:11434, kaya nagbabalik ng connection refused kapag mula sa 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 ang API.

Napakabagal ng unang reply pagkatapos ng pause. Nangyari ang idle unload makalipas ang 5 minuto, at binabasa muli ang model mula sa disk. Ipinapakita ng ollama ps na pinatakbo kaagad bago ang request na walang naka-load, kaya nakukumpirma nito ang dahilan. Itaas ang OLLAMA_KEEP_ALIVE.

Kaya alin ang dapat mong patakbuhin?

Patakbuhin ang Ollama kapag gusto mong awtomatikong i-manage ang mga model at magkaroon ng OpenAI-shaped endpoint nang walang dagdag na configuration. Ito ang tamang default para sa unang deployment at sa mga sitwasyong madalas magbago ang model na gagamitin.

Patakbuhin ang llama.cpp nang direkta 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 tamang pagpili sa isang VPS kung halos kasya lamang ang model, dahil ang mga setting na nagpapakasya rito ay siya ring awtomatikong 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 magbago.

FAQ

Wrapper lang ba ang Ollama para sa llama.cpp?

Malapit, pero may aktuwal na ginagawa ang wrapper. Itinala 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, mga default sampling parameter, daemon na nag-u-unload ng mga idle model, at HTTP API. Kapag ikinumpara mo ang tokens per second gamit ang magkakaparehong setting, pareho lang na engine ang ikinukumpara mo sa sarili nito. Ang aktuwal mong pinipili ay ang management layer.

Alin ang mas mabilis sa CPU-only VPS?

Pareho ang engine nila, kaya kung pareho ang model file, quantisation, context size, at thread count, halos magkakalapit ang resulta. Ang mga pagkakaibang karaniwang iniuulat ay kadalasang nagmumula sa magkakaibang default, 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 published figure.

Magagamit ko ba ang sarili kong GGUF file sa Ollama?

Oo. Ilagay ang file sa server, gumawa ng Modelfile na ang unang line 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 model na kinuha mo mula sa registry. Ganito ginagamit ang quantisation na wala sa registry.

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

Isama sa budget ang file size, 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 ng RAM at kulang 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.