Ollama dhidi ya llama.cpp: Ipi bora kwa VPS yako?

Ollama dhidi ya llama.cpp: ni safu ipi unataka kuendesha?

Ollama na llama.cpp si washindani kwa namna swali hili linavyodokeza. llama.cpp ni injini ya inference: hupakia faili ya model na kubadilisha prompt kuwa tokens. Ollama ni kidhibiti cha model, daemon ya nyuma (background daemon) na HTTP API inayokaa juu ya injini hiyo. README ya Ollama bado inataja llama.cpp kama backend yake ya inference (iliyothibitishwa tarehe 2 Agosti 2026). Kwa hivyo, swali la msingi ni ni safu ipi unataka kutumia kwenye VPS yako, siyo ipi iliyo na kasi zaidi.

Endesha Ollama pale unapotaka huduma inayopakua models kwa jina na kuendelea kufanya kazi bila kuhitaji uangalizi. Endesha llama.cpp moja kwa moja pale seva inapokuwa ndogo na unahitaji kuchagua faili kamili ya model, ukubwa kamili wa context, na idadi kamili ya threads, kwa sababu kwenye VPS ndogo kila moja ya mipangilio hiyo hutumia kumbukumbu (memory) ambayo huna.

Ufafanuzi wa kila mradi

llama.cpp ni utekelezaji wa C na C++ wa transformer inference iliyojengwa juu ya maktaba ya ggml. Inasoma faili za GGUF. GGUF (GGML universal file format) ni kontena la faili moja linaloshikilia weights, tokeniser na metadata ambayo injini inahitaji ili kuendesha modeli. Mradi huu hutoa binaries tofauti kwa kazi tofauti. llama-server ni seva ya HTTP, llama-cli ni prompt ya mwingiliano, na llama-bench hupima throughput. Releases hutambulishwa kwa nambari ya build badala ya semantic version. Tag ya sasa ni b10224, iliyochapishwa tarehe 2 Agosti 2026, na tag mpya hutolewa karibu kila siku ya kazi.

Ollama ni programu ya Go. Daemon ya usuli, inayozinduliwa kwa ollama serve, hupakia modeli na kujibu maombi ya HTTP, na mteja wa mstari wa amri (command line client) huwasiliana na daemon hiyo. Nyuma ya yote haya kuna sajili (registry) katika ollama.com inayoshikilia modeli zilizopakiwa awali. Ollama hutumia semantic versions, na v0.32.5 ilitolewa tarehe 27 Julai 2026. ollama pull huchota GGUF pamoja na prompt template na seti ya vigezo chaguo-msingi, kisha huihifadhi chini ya /usr/share/ollama/.ollama/models kwenye Linux.

Ufungaji huo ndio tofauti nzima. Ollama huamua quantisation, template na urefu wa muktadha (context length) kwa ajili yako, na kukupa jina moja la kukumbuka. llama.cpp haiamui chochote na inakupa flags.

Mhimili 1: udhibiti wa modeli na quantisation

Quantisation hupunguza uzito (weight) wa kila kigezo kutoka biti 16 au 32 hadi biti 4, 5 au 8. Hii ndiyo inayowezesha modeli yenye vigezo bilioni 8 kutoshea kwenye RAM ya VPS ya kawaida. Uteuzi wa majina ya GGUF unasomeka ukishajua muundo wake: Q4_K_M inamaanisha 4-bit K-quant, ukubwa wa wastani. Namba kubwa zaidi huhifadhi usahihi zaidi na hutumia kumbukumbu nyingi zaidi.

[
  {
    "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
  }
]

Hizo ni saizi za faili zilizochapishwa katika hazina ya bartowski/Meta-Llama-3.1-8B-Instruct-GGUF kwenye Hugging Face, zilizosomwa tarehe 2 Agosti 2026 na kubadilishwa kutoka bytes kwenda GiB. 6 ni matoleo ya modeli moja, na dogo zaidi ni 2.96 GiB dhidi ya 7.95 GiB kwa kubwa zaidi. Chaguo la kawaida, Q4_K_M, ni 4.58 GiB. Kwenye VPS ya 4 GiB, chaguo hilo moja huamua kama modeli itapakia au la.

Ukiwa na llama.cpp unataja faili mwenyewe, kwa hivyo unachagua safu hiyo wewe mwenyewe.

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

-c ni ukubwa wa muktadha (context size) katika tokens, -t ni idadi ya threads, na -ngl huweka ni tabaka (layers) ngapi zinahamishiwa kwenye GPU (0 kwa seva ya CPU pekee). Hakuna kinachokisiwa kwa ajili yako.

Ukiwa na Ollama, quantisation huambatana na tag unayovuta, na ollama ls huonyesha kile ulichonacho kwenye diski. Wakati registry haina toleo unalotaka, ingiza GGUF mwenyewe. Andika Modelfile:

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

Kisha ijenge na uhakiki matokeo:

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

Urefu wa muktadha (context length) ni mpangilio unaowatatiza watu wengi. Ollama huchagua chaguo-msingi kutoka kwenye VRAM inayopatikana, na seva isiyo na GPU huangukia kwenye kundi dogo zaidi: tokens 4096. Ukipitisha hati yenye tokens 20,000, tokens za ziada hupotezwa kabla modeli haijaziona, hivyo jibu litakuwa la uongo kwa sababu imesoma nusu tu ya faili. Iongeze kwa OLLAMA_CONTEXT_LENGTH kwenye daemon, au kwa PARAMETER num_ctx kwenye Modelfile. llama.cpp haina chaguo-msingi la kuaminika pia. Weka -c kwa uwazi na ujue kile ulichoweka.

Hesabu ya kumbukumbu ambayo hakuna anayekuonyesha

Faili la model si gharama yote. KV cache (key/value cache) huhifadhi ingizo moja kwa kila layer kwa kila token ya context, na hukua kadiri mazungumzo yanavyokua.

Fanya hesabu kwa Llama 3.1 8B. Model hii ina 32 layers, 8 key/value heads, na head dimension ya 128. Kila token huhifadhi key na value kwa baiti 2 kila moja katika f16, hivyo 2 x 8 x 128 x 2 = 4096 baiti kwa kila layer. Katika 32 layers, hiyo ni 128 KiB kwa kila token. Kwa hivyo, context ya 4096 token inagharimu 512 MiB, na context ya 32,768 token inagharimu 4 GiB.

Kwa hiyo, model ya Q4_K_M 8B yenye context ya 4k inahitaji takriban 4.58 GiB kwa ajili ya uzito (weights), pamoja na takriban 0.5 GiB ya cache, na runtime yenyewe. Haitoshei kwenye 4 GiB ya RAM. Inatoshea kwenye 8 GiB ikiwa na nafasi ya kufanyia kazi. Ukiongeza context hadi 32k kwenye mashine hiyo hiyo ya 8 GiB, cache pekee itamaliza nafasi iliyobaki. Ifuatilie moja kwa moja ukitumia free -h wakati model inapakizwa, na usiamini makadirio ambayo hujayapima mwenyewe.

Ollama huzidisha hili. OLLAMA_NUM_PARALLEL huwa na thamani ya msingi ya 1, na kumbukumbu inayohitajika na model huongezeka kulingana na namba hiyo mara urefu wa context. Ukiongeza vyote kwa wakati mmoja, daemon huomba kimyakimya RAM mara kadhaa zaidi ya ile uliyotarajia.

Mhimili wa 2: daemon unayopaswa kuiendesha

Script ya usakinishaji wa Ollama huandika unit ya systemd, hutengeneza mtumiaji wa mfumo wa ollama, na kuwezesha huduma hiyo. Unapata usimamizi wa mzunguko wa maisha (lifecycle management) bila kuandika chochote. Usanidi hufanyika kupitia systemd:

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

OLLAMA_KEEP_ALIVE ni muhimu zaidi kwenye CPU VPS kuliko mahali pengine popote. Modeli huhifadhiwa kwenye kumbukumbu kwa dakika 5 kwa chaguo-msingi kisha huondolewa. Ombi linalofuata lazima lisome faili zima kutoka kwenye diski kabla ya kuweza kujibu, kwa hivyo upakiaji upya wa 4.58 GiB hubadilisha jibu la sekunde mbili kuwa la sekunde thelathini kwenye hifadhi ya polepole. Keep-alive ya muda mrefu hutatua latency na hutumia RAM kabisa. Zote mbili ni gharama halisi. Chagua ile inayoumiza kidogo.

llama.cpp haikupi daemon, kwa hivyo unaandika unit mwenyewe kama /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

Iwezeshe kwa sudo systemctl enable --now llama-server. Mchakato huo kisha hushikilia modeli kwa muda wake wote wa maisha. Hakuna kinachoondolewa wakati wa kutofanya kazi, kumaanisha hakuna mshangao wa kupakia upya na hakuna njia ya kurejesha kumbukumbu isipokuwa kusimamisha huduma. Ikiwa kuandika units ni jambo geni kwako, ni muundo uleule kama kuendesha huduma zako mwenyewe chini ya systemd kwenye VPS.

Axis 3: API ambayo programu yako itawasiliana nayo

Axis hii imepungua sana. Miradi yote miwili sasa inatumia muundo wa chat wa OpenAI, kwa hivyo maktaba nyingi za wateja hufanya kazi na yoyote kati yao baada ya kubadilisha tu base URL.

Ollama husikiliza kwenye 127.0.0.1:11434. Njia yake inayooana na OpenAI ni http://localhost:11434/v1/chat/completions, na inabaki na API asilia kwenye /api/chat kando yake. Njia inayooana na Anthropic pia imeelezewa kwenye nyaraka.

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 husikiliza kwenye 127.0.0.1:8080 na kuhudumia /v1/chat/completions, /v1/completions na /v1/embeddings, pamoja na endpoint yake yenyewe ya /completion na UI ya wavuti iliyojengewa ndani. Pia hufichua njia za kiutendaji ambazo Ollama haina: /health kwa ajili ya uchunguzi wa utayari (readiness probe), /props kwa ajili ya mipangilio ya modeli iliyopakiwa, /slots kwa ajili ya kile ambacho kila nafasi ya ombi inafanya, na /metrics katika muundo wa Prometheus. Ikiwa unapanga kufuatilia huduma hii, tofauti hiyo ndiyo inayoweza kuamua chaguo lako.

Hakuna seva kati ya hizi mbili inayowasha uthibitishaji (authentication) kwa ajili yako. Zote mbili kwa chaguomsingi hutumia loopback kwa sababu nzuri. Zifikie kupitia SSH tunnel au ukiwa nyuma ya reverse proxy, na usiwahi kufungua 11434 au 8080 kwenye Internet.

Uwezo halisi wa VPS inayotumia CPU pekee

VPS inayotumia CPU pekee huendesha mifano midogo ya AI kwa kasi ndogo. Huo ndio muhtasari wa kweli, na sehemu ya maana ni kujua mipaka yake iko wapi. Pima utendaji kabla ya kubuni mfumo wowote unaoitegemea:

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

Safu ya pp ni kasi ya kuchakata prompt na safu ya tg ni kasi ya kuzalisha token, zote zikiwa katika token kwa sekunde. Kwenye mpango wa vCPU iliyoshirikiwa, mfano wa 8B katika Q4_K_M kwa kawaida hutoa matokeo ya tarakimu moja ya chini kwa tg. Kuchakata prompt ndiko kunakochukua muda mrefu: prompt nzima huchakatwa kabla ya token ya kwanza ya matokeo kuonekana, hivyo prompt ndefu ya mfumo huongeza muda wa kusubiri kwa kila ombi.

Inayofaa kwenye CPU: mfano wa 1B hadi 4B kwa ajili ya uainishaji, uchimbaji wa data, muhtasari mfupi au uelekezaji wa maombi. Majibu hufika ndani ya sekunde chache na kumbukumbu inatosheleza mpango wa kawaida. Isiyofaa kwenye CPU: mazungumzo ya moja kwa moja kwa kasi ya kusoma, visaidizi vya uandishi wa code, kazi za nyaraka ndefu, au chochote chenye kitanzi cha wakala (agent loop) kinachofanya maombi mengi mfululizo. Kitanzi kinachofanya maombi kumi na mbili kwa sekunde nne kila moja huchukua dakika nzima kabla ya kutoa matokeo yoyote.

Kuna njia mbili za kutoka ikiwa namba hizi hazikidhi mahitaji. Ikiwa tatizo ni concurrency, yaani watumiaji wengi wanaotumia mfano mmoja kwa wakati mmoja, chaguo la injini hubadilika, na ulinganisho wa Ollama dhidi ya vLLM kwa ajili ya huduma ya wakati mmoja unashughulikia eneo hilo. Ikiwa tatizo ni kasi ghafi, jibu ni VPS yenye GPU iliyounganishwa, ambapo -ngl huanza kuwa na maana. Kabla ya yote, pata msingi wa utendaji wa vifaa vyenyewe, kwa sababu bandwidth ya diski na kumbukumbu huathiri muda wa kupakia (load time) kama vile CPU inavyofanya. Benchmark ya VPS inayoweza kurudiwa inastahili saa moja ya muda wako.

Sakinisha llama.cpp, kwa kutumia toleo maalum (pinned)

Miradi yote miwili inabadilika kila wiki, kwa hivyo rekodi toleo uliloliweka. Amri ya mstari mmoja kutoka kwa msanidi inasakinisha toleo la sasa:

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

Ili kutumia toleo maalum, chukua tarball iliyojengwa tayari kutoka kwenye ukurasa wa releases badala yake. Build b10224 ndiyo tag ya sasa kufikia tarehe 2 Agosti 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'

Au jenga tag hiyo hiyo kutoka kwenye source code:

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 ndiyo dependency iliyoainishwa kwa ajili ya vipengele vya HTTPS. Ujenzi (compile) huchukua dakika kadhaa na huhitaji RAM nyingi kuliko ile inayopatikana kwenye mipango midogo ya seva, kwa hivyo jenga kwenye seva kubwa kisha nakili binaries ikiwa seva ndogo itashindwa kukamilisha kazi kwa sababu ya ukosefu wa kumbukumbu.

Sakinisha Ollama, ukiwa umefunga toleo mahususi

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

Hati hii inasoma OLLAMA_VERSION, kwa hivyo unaweza kuhifadhi toleo linalofanya kazi vizuri badala ya kuchukua toleo lolote lililotolewa leo asubuhi. v0.32.5 ilichapishwa tarehe 27 Julai 2026. Kuna njia ya mwongozo pia ikiwa hutaki kuingiza hati moja kwa moja kwenye 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

Njia ya mwongozo haitengenezi unit ya systemd wala mtumiaji wa huduma, kwa hivyo utaongeza hayo wewe mwenyewe. Mwongozo kamili wa Ollama kwenye VPS unaelezea hatua hizo za usanidi wa huduma kwa kina.

Njia za kufeli, na ujumbe utakaouona

Ollama inakataa kupakia modeli. ollama run inarejesha mstari wa namna hii:

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

Ollama hukagua ukubwa kabla ya kupakia, hivyo inafeli haraka na kueleza sababu. Punguza kiwango cha quantisation, punguza urefu wa context, au chagua modeli ndogo zaidi.

llama.cpp haifeli, inafanya kazi polepole sana. llama.cpp hutumia memory-mapping kwa faili za GGUF kwa chaguo-msingi, hivyo faili kubwa kuliko RAM bado huanza. Kernel kisha hupakia na kutoa weights kutoka kwenye diski kwa kila token, na kasi ya uzalishaji hushuka hadi sekunde kadhaa kwa kila token huku diski ikiwa na matumizi ya asilimia 100. Pitisha --no-mmap ili kulazimisha allocation halisi ili ifeli mara moja badala ya kupunguza utendaji. Kernel inapoingilia kati, dmesg huonyesha sababu:

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

Faili ya modeli haipakii kabisa. GGUF iliyojengwa kwa ajili ya familia ya modeli mpya zaidi kuliko engine yako hutoa kosa linalotaja usanifu (architecture) ambao haujui:

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

Suluhisho ni kuboresha (upgrade) engine, si kutafuta faili tofauti. Hii ndiyo gharama ya kufunga toleo (pinning), na ndiyo sababu unapaswa kuandika namba ya build. Unahitaji kujua toleo unalotoka wakati wa kuboresha.

API inajibu ndani ya seva lakini si kutoka kwenye app yako. Ollama hufunga 127.0.0.1:11434, hivyo host nyingine hupata ujumbe wa connection refused. Weka OLLAMA_HOST=0.0.0.0:11434 kupitia systemctl edit ollama pale tu ambapo port iko nyuma ya firewall au mtandao wa ndani (private network), kwa sababu API haina uthibitishaji (authentication) mbele yake.

Jibu la kwanza baada ya muda wa kusubiri ni polepole sana. Unload ya modeli baada ya dakika 5 za kutotumika imetokea na modeli inasomwa kutoka kwenye diski tena. ollama ps inayotekelezwa kabla ya ombi haionyeshi kitu chochote kilichopakiwa, jambo linalothibitisha hili. Ongeza thamani ya OLLAMA_KEEP_ALIVE.

Ni ipi unapaswa kuiendesha?

Endesha Ollama pale unapotaka mifano (models) idhibitiwe kwa ajili yako na uwe na endpoint yenye muundo wa OpenAI bila kufanya kazi ya ziada. Hili ndilo chaguo chaguo-msingi sahihi kwa deployment ya kwanza, na kwa jambo lolote ambapo chaguo la model litaendelea kubadilika.

Endesha llama.cpp moja kwa moja pale kumbukumbu (memory) inapokuwa finyu kiasi kwamba unahitaji kuchagua safu ya quantisation wewe mwenyewe, pale unapotaka /health, /slots na /metrics kwa ajili ya ufuatiliaji, au pale unapohitaji flag ambayo Ollama haitoi. Hili ni chaguo la kweli kwenye VPS ambapo model inatoshea kwa shida, kwa sababu mipangilio inayofanya itoshee ndiyo ile ile ambayo Ollama huchagua kwa niaba yako.

Kuendesha zote mbili ni jambo la kawaida. Ollama kwa ajili ya majaribio, llama.cpp kwa ajili ya model moja unayoiweka kwenye production na hutaki kuona ikibadilika.

FAQ

Je, Ollama ni wrapper tu ya llama.cpp?

Karibu hivyo, lakini wrapper hiyo inafanya kazi muhimu. README ya Ollama inataja llama.cpp kama backend yake ya inference (iliyokaguliwa tarehe 2 Agosti 2026). Juu yake, Ollama inaongeza sajili ya model, template ya prompt inayobadilisha ujumbe wa chat kuwa prompt, seti ya vigezo vya kawaida vya sampling, daemon inayopakua model zisizotumika, na HTTP API. Unapolinganisha tokens kwa sekunde kwa mipangilio inayofanana, unalinganisha injini ileile na yenyewe. Unachochagua kwa hakika ni safu ya usimamizi.

Ni ipi inayofanya kazi haraka kwenye VPS ya CPU pekee?

Zinatumia injini moja, kwa hivyo kwa faili ya model, quantisation, ukubwa wa context, na idadi ya threads inayofanana, utendaji wake unakaribiana. Tofauti ambazo watu huripoti mara nyingi hutokana na mipangilio tofauti ya awali, hasa urefu wa context na idadi ya threads, badala ya injini yenyewe. Pima utendaji kwa llama-bench -m <file> -p 512 -n 128 na ulinganishe safu ya tg kwenye seva yako mwenyewe kabla ya kuamini takwimu zozote zilizochapishwa.

Je, ninaweza kutumia faili yangu ya GGUF na Ollama?

Ndiyo. Weka faili hiyo kwenye seva, andika Modelfile ambayo mstari wake wa kwanza ni FROM ./your-model.gguf, ongeza mistari yoyote ya PARAMETER unayohitaji kama vile num_ctx, kisha endesha ollama create your-name -f ./Modelfile. ollama ls itaorodhesha faili hiyo pamoja na chochote ulichopakua kutoka kwenye sajili. Hivi ndivyo unavyoweza kutumia quantisation ambayo haipo kwenye sajili.

Ninahitaji RAM kiasi gani kwa model ya 8B?

Panga bajeti ya ukubwa wa faili, pamoja na KV cache, na runtime. Toleo la Q4_K_M la Llama 3.1 8B ni takriban 4.58 GiB kwenye diski, na context ya tokens 4096 inaongeza takriban 512 MiB ya cache, kwa hivyo 8 GiB ya RAM inatosha vizuri na 4 GiB haitoshi. Cache huongezeka kulingana na context: model ileile yenye context ya tokens 32,768 inahitaji takriban 4 GiB ya cache pekee. Ukiwa na Ollama, kumbuka kuwa mahitaji pia huongezeka kulingana na OLLAMA_NUM_PARALLEL.