Ollama vs 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 ndiyo injini ya inference: hupakia faili ya model na kubadilisha prompt kuwa tokens. Ollama ni kidhibiti cha model, daemon ya usuli 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 inayofanya kazi kwa kasi zaidi.

Endesha Ollama pale unapotaka huduma inayopakua models kwa jina na kuendelea kufanya kazi bila kuhitaji usimamizi. 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 inagharimu kumbukumbu 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 linalohifadhi uzito (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 huwekewa tag 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 nyuma, 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 hayo kuna registry katika ollama.com inayohifadhi 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. Faili hizo hukaa kwenye root disk na kufikia gigabytes kadhaa kila moja, kwa hivyo kwenye VPS yenye 25 GB ya root volume ni vyema kujua kile ambacho pull huacha nyuma na jinsi ya kuhamisha saraka ya modeli kwenda kwingine kabla ya download ya tatu kuijaza.

Ufungashaji 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 inayofanya modeli yenye vigezo bilioni 8 kutoshea kwenye RAM ya VPS ya kawaida. Uteuzi wa majina ya GGUF unasomeka vizuri ukishajua muundo wake: Q4_K_M inamaanisha 4-bit K-quant, saizi ya wastani. Namba ya juu 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 kwenye hazina ya bartowski/Meta-Llama-3.1-8B-Instruct-GGUF katika Hugging Face, zilizosomwa tarehe 2 Agosti 2026 na kubadilishwa kutoka bytes hadi GiB. Kuna 6 za modeli moja, na ndogo zaidi ni 2.96 GiB ikilinganishwa na 7.95 GiB kwa ile 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. Saizi ni nusu tu ya uamuzi huo, kwa sababu safu unayoweza kumudu si lazima iwe safu inayofaa kutumika, na gharama halisi ya Q4, Q8 na fp16 katika ubora wa majibu ndiyo inayokuambia kama gigabytes za ziada zitaleta tofauti unayoweza kuiona.

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 saizi ya muktadha (context size) katika tokens, -t ni idadi ya threads, na -ngl huweka ni tabaka (layers) ngapi zinahamishiwa kwenye GPU (0 kwenye 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 sajili 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 unaowachanganya watu wengi. Ollama huchagua chaguo-msingi kutoka VRAM inayopatikana, na seva isiyo na GPU huangukia kwenye kundi dogo zaidi: tokens 4096. Tuma hati ya tokens 20,000 na tokens za ziada zitakataliwa kabla modeli haijaziona, kwa hivyo jibu litakuwa la uongo kwa ujasiri kuhusu faili iliyosoma nusu tu. Iongeze kwa OLLAMA_CONTEXT_LENGTH kwenye daemon, au kwa PARAMETER num_ctx kwenye Modelfile. Ikiwa kazi moja tu ndiyo inayohitaji dirisha kubwa zaidi, num_ctx inaweza kuwekwa kwa kila ombi badala ya seva nzima, jambo linalozuia cache ya ziada kutumika kwenye kila kitu kingine kinachoulizwa na daemon. llama.cpp haina chaguo-msingi linaloaminika pia. Weka -c wazi na ujue ulichoweka.

Hesabu ya kumbukumbu ambayo hakuna anayekuonyesha

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

Fanya hesabu kwa Llama 3.1 8B. Model hii ina layers 32, heads 8 za key/value, na dimension ya head 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 layers 32, hiyo ni 128 KiB kwa kila token. Kwa hivyo, context ya token 4096 inagharimu 512 MiB, na context ya token 32,768 inagharimu 4 GiB.

Kwa hiyo, model ya Q4_K_M 8B yenye context ya 4k inahitaji takriban 4.58 GiB kwa ajili ya 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. Iangalie moja kwa moja ukitumia free -h wakati model inapakizwa, na usiamini makadirio ambayo hukuyapima mwenyewe. Ikiwa unapanga ukubwa kwa ajili ya kitu kikubwa zaidi ya 8B, hesabu hiyo hiyo iliyofafanuliwa kwa model ya 27B kwenye VPS ya CPU pekee inaonyesha kile kila ngazi kuanzia 8 hadi 64 GB kinachoweza kuhifadhi.

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 nyingi zaidi ya ile uliyotarajia. Hesabu hiyo hiyo huweka ukomo wako kwa watumiaji wa wakati mmoja, kwa sababu kila ombi la wakati mmoja linahitaji sehemu yake ya KV cache, jambo ambalo ndilo kwa nini seva inayoonekana kufanya kazi vizuri kwa mtu mmoja hukwama kwa watumiaji watano.

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 ndefu hutatua latency na hutumia RAM kudumu. Gharama zote mbili ni halisi. Chagua ile inayoumiza kidogo. Ukiamua kuwa modeli inapaswa kubaki kwenye kumbukumbu, kuweka keep_alive ili iweze kustahimili vipindi vya kutofanya kazi na reboot huchukua mistari michache na kukuokoa muda wa kupasha modeli moto kwa mikono kila wakati seva inapowaka upya.

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 kuishi. 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 wa kuendesha huduma zako mwenyewe chini ya systemd kwenye VPS.

Mhimili wa 3: API ambayo programu yako itawasiliana nayo

Mhimili huu umepungua sana. Miradi yote miwili sasa inatumia muundo wa mazungumzo wa OpenAI, kwa hivyo maktaba nyingi za wateja hufanya kazi na yoyote kati yao baada ya kubadilisha URL ya msingi pekee.

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 ya /completion na kiolesura cha wavuti kilichojengewa ndani. Pia inatoa njia za kiutendaji ambazo Ollama haitoi: /health kwa ajili ya uchunguzi wa utayari (readiness probe), /props kwa ajili ya mipangilio ya modeli iliyopakiwa, /slots kwa ajili ya kuona kile kila nafasi ya ombi inachofanya, na /metrics katika muundo wa Prometheus. Ikiwa unapanga kufuatilia huduma hii, tofauti hiyo ndiyo inayoweza kuamua chaguo lako.

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

Mambo ambayo VPS ya CPU pekee inaweza kufanya kwa uhalisia

VPS ya CPU pekee huendesha model ndogo kwa kasi ndogo. Huo ndio muhtasari wa kweli, na sehemu ya maana ni kujua mpaka wa uwezo wake. Pima utendaji kabla ya kubuni chochote:

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, model ya 8B katika Q4_K_M kwa kawaida hutoa matokeo ya tarakimu moja ya chini kwa tg. Uchakataji wa prompt ndio sehemu inayochukua muda: prompt nzima huchakatwa kabla ya token ya kwanza ya matokeo kuonekana, kwa hivyo prompt ndefu ya mfumo huongeza muda wa kusubiri kwa kila ombi. Urefu wa jibu ni nusu ya gharama unayoweza kuidhibiti, kwa sababu kwa kasi ya token tatu kwa sekunde, model inayotoa majibu marefu ya token 600 itashikilia seva kwa dakika tatu, hivyo kudhibiti matokeo kwa num_predict ndiyo njia rahisi zaidi ya kuzuia jibu refu lisilete timeout.

Inayofaa kwenye CPU: model ya 1B hadi 4B inayofanya classification, extraction, muhtasari mfupi au routing. Majibu hufika ndani ya sekunde na kumbukumbu inatosha kwenye mpango wa kawaida. Kwa mfano wa kazi katika ukubwa huo badala ya masafa, Nemotron 3.5 Lightning iliyopakuliwa na kupimwa kwenye VPS inatoa tag kamili, RAM inayohitajika, na kasi inayopatikana bila GPU. Isiyofaa kwenye CPU: chat ya mwingiliano kwa kasi ya kusoma, wasaidizi wa coding, kazi za hati ndefu, au chochote chenye agent loop inayofanya wito mwingi mfululizo. Loop inayofanya wito kumi na mbili kwa sekunde nne kila mmoja huchukua dakika moja kabla ya kutoa matokeo yoyote. Ikiwa msaidizi wa coding ndiyo alikuwa lengo, kuelekeza agent kwenye model unayojiendeshea kunaainisha kazi ambazo model ndogo ya ndani inaweza kufanya na zile zinazopaswa kubaki kwenye API ya nje.

Kuna njia mbili za kutoka wakati namba hazikidhi mahitaji. Ikiwa tatizo ni concurrency, watumiaji wengi wakitumia model moja kwa wakati mmoja, chaguo la engine hubadilika, na ulinganisho wa Ollama dhidi ya vLLM kwa ajili ya concurrent serving unashughulikia hilo. Ikiwa tatizo ni kasi ya msingi, jibu ni VPS yenye GPU iliyounganishwa, ambapo -ngl huanza kuwa na maana. Kabla ya yoyote hayo, pata baseline ya hardware yenyewe, kwa sababu bandwidth ya disk na memory huathiri muda wa kupakia kama ilivyo kwa CPU. Benchmark ya VPS inayoweza kurudiwa inastahili saa moja ya kazi.

Sakinisha llama.cpp, ukiwa umefunga toleo mahususi

Miradi yote miwili hubadilika kila wiki, kwa hivyo rekodi toleo uliloliweka. Amri ya mstari mmoja kutoka kwa chanzo asilia husakinisha toleo la sasa:

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

Ili kufunga toleo mahususi, chukua tarball iliyojengwa awali 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 huu huchukua dakika kadhaa na huhitaji RAM nyingi zaidi kuliko zile zinazopatikana kwenye mipango midogo ya seva, kwa hivyo jenga kwenye mashine kubwa zaidi kisha unakili binaries ikiwa ile ndogo itakwama kwa kukosa kumbukumbu.

Sakinisha Ollama, ukiwa umefunga toleo maalum

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 (service user), 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 model. 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, kwa hivyo inafeli haraka na kueleza sababu. Punguza kiwango cha quantisation, punguza urefu wa context, au chagua model ndogo zaidi.

llama.cpp haifeli, inafanya kazi polepole sana. llama.cpp hufanya memory-map ya GGUF kwa chaguo-msingi, kwa hivyo faili kubwa kuliko RAM bado huanza. Kernel kisha hupakia na kutoa uzito (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 kushuka utendaji. Kernel inapoingilia kati, dmesg huonyesha sababu:

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

Faili ya model haipakii kabisa. GGUF iliyojengwa kwa ajili ya familia ya model 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 kutumia 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 programu yako. Ollama hufungwa kwenye 127.0.0.1:11434, kwa 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 kibinafsi, kwa sababu API haina uthibitishaji (authentication) mbele yake.

Jibu la kwanza baada ya muda wa kusubiri ni polepole sana. Unload ya muda wa dakika 5 ya kutofanya kazi imetokea na model inasomwa kutoka kwenye diski tena. ollama ps inayoendeshwa kabla ya ombi haionyeshi chochote kilichopakiwa, jambo linalothibitisha hilo. Ongeza 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 chochote ambapo chaguo la model litaendelea kubadilika.

Endesha llama.cpp moja kwa moja pale kumbukumbu (memory) inapokuwa finyu kiasi kwamba unahitaji kuchagua safu ya quantisation 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 (iliangaliwa tarehe 2 Agosti 2026). Juu yake, Ollama inaongeza sajili ya modeli, template ya prompt inayobadilisha ujumbe wa chat kuwa prompt, seti ya vigezo vya kawaida vya sampling, daemon inayopakua modeli zisizotumika, na HTTP API. Unapolinganisha tokens kwa sekunde kwenye mipangilio inayofanana, unalinganisha injini ileile na yenyewe. Unachochagua kwa kweli ni safu ya usimamizi.

Ni ipi inayokwenda kasi zaidi kwenye VPS ya CPU pekee?

Zinatumia injini moja, kwa hivyo kwenye faili ya modeli, 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. Ipime kwa kutumia 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 itaiorodhesha pamoja na chochote ulichopakua kutoka kwenye sajili. Hivi ndivyo unavyotumia quantisation ambayo haipo kwenye sajili.

Ninahitaji RAM kiasi gani kwa modeli 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: modeli ileile kwenye 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.