Ollama quantization: Tofauti ya q4, q8 na fp16

Mabadiliko ya quantization ya Ollama

Quantization ya Ollama huhifadhi kila uzito (weight) katika modeli kwa kutumia bits chache kuliko faili iliyotumika kuifunza. Lebo inayoishia na q4_K_M huhifadhi takriban bits nne kwa kila uzito, wakati fp16 huhifadhi kumi na sita; hivyo, saizi ya upakuaji ni robo ya ile ya awali, na mashine husoma idadi ya bytes robo moja tu ili kutoa kila token. Uzito huo huzungushwa (rounded) kwenye gridi pana badala ya kufutwa, na katika kiwango cha bits nne, modeli nyingi hutoa majibu yanayokaribia usahihi wa kiwango kamili.

Huo ndio mabadilishano yote: nafasi ndogo zaidi ya kumbukumbu na token nyingi zaidi kwa sekunde, kwa gharama ya upungufu mdogo wa usahihi. Yafuatayo yanaeleza jinsi ya kutabiri pande zote mbili kwa modeli mahususi kwenye seva mahususi, kabla ya kutumia dakika ishirini kupakua faili ambayo haitatoshea.

Ikiwa Ollama bado haijaanza kufanya kazi, anza na kusakinisha Ollama kwenye VPS. Ukurasa huu unachukulia kuwa ollama ls tayari inafanya kazi.

Jinsi ya kusoma tag ya quantization ya Ollama kama q4_K_M

Model za ndani husafirishwa kama faili za GGUF, umbizo ambalo llama.cpp hutumia kuhifadhi uzito (weights) kwenye diski. Ollama imejengwa juu ya llama.cpp, kwa hivyo tag za Ollama hubeba majina ya quantization ya llama.cpp bila kubadilishwa.

Nambari hiyo ni upana unaolengwa. q4 inamaanisha tensor nyingi za uzito zimefungashwa kwa biti nne kila moja. q8 inamaanisha nane. fp16 haijafanyiwa quantization hata kidogo: ni model katika usahihi wa floating point wa biti kumi na sita, ambao ndio usahihi ambao model nyingi huchapishwa nao.

K huashiria K-quant. Uzito hupangwa katika vizuizi vidogo, na kila kizuizi huhifadhi kiwango chake (scale) kando ya thamani zilizofungashwa. Kizuizi ambacho uzito wake wote uko karibu na 0.01 hupata kiwango sahihi (fine scale). Kizuizi chenye uzito mmoja mkubwa wa kipekee hupata kiwango kikubwa (coarse scale). Mizani hiyo ya kila kizuizi ndiyo inayofanya faili ya biti nne kuwa na matumizi, na ndiyo sababu faili ya biti nne si biti nne kamili kwa kila uzito.

Herufi ya mwisho ni mchanganyiko. S, M na L huamua ni tensor ngapi zinazopandishwa juu ya upana unaolengwa. Katika q4_K_M, tensor ambazo huathirika zaidi wakati wa kuzungushwa (rounding) huhifadhiwa kwa upana zaidi, wakati sehemu kubwa inabaki katika biti nne. Hiyo ndiyo sababu q4_K_M hutoa matokeo bora kuliko q4_0 ya zamani kwa ukubwa wa faili karibu sawa.

Iulize Ollama kile ilicho nacho kwenye diski badala ya kukisia kutoka kwa jina uliloandika:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show huchapisha architecture, parameters, quantization, context length na embedding length. Mstari wa quantization ndio ukweli kamili kwa model uliyopakua miezi iliyopita na hukumbuki tena uliyoichagua.

Bits per weight ndiyo chanzo cha ukubwa wa faili

Kila makadirio ya ukubwa huanzia kwenye namba moja: ni bits ngapi ambazo fomati hutumia kwa kila weight, kwa wastani katika faili zima. llama.cpp huchapisha takwimu zilizopimwa kwa ajili ya Llama 3.1 8B katika nyaraka zake za quantize, na takwimu hizo hufanya kazi vizuri kwa modeli yoyote ya msongamano (dense model) yenye umbo sawa.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

Jambo la kushangaza katika jedwali hilo ni safu ya pili. Q4_K_M si bits nne kwa kila weight. Inapima 4.89 bits, kwa sababu mizani ya block (block scales) na tensors zilizopandishwa hadhi (promoted tensors) zote hutumia nafasi halisi. Q8_0 inapima 8.5 bits badala ya nane, kwa sababu hiyo hiyo. Tumia namba iliyopimwa na hesabu itakuwa ndani ya asilimia chache ya ukubwa halisi wa faili:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Hiyo ndiyo faili ya 4.58 GiB Q4_K_M, iliyopatikana kutoka kwa namba mbili. Pia, kwa karibu, ndiyo kumbukumbu (memory) inayotumiwa na weights mara tu zinapopakiwa. Ollama haifungui (unpack) chochote wakati wa kupakia: weights zilizopunguzwa ubora (quantized weights) hukaa kwenye kumbukumbu katika hali ile ile iliyopakiwa na kila block hubadilishwa inapotumika.

Kile ambacho Ollama husafirisha kwa kila ukubwa wa modeli

Maktaba huchapisha tag ya q4_K_M, q8_0 na fp16 kwa familia nyingi. Familia chache mpya huvunja muundo huo na kuonekana kwenye maktaba kama tag za cloud pekee bila kitu cha kupakua kwa ukubwa wowote, jambo ambalo ndilo kikwazo unachokutana nacho unapojaribu kujaribu kuendesha GLM 5.2 kwenye VPS. Hizi ndizo ukubwa wa Qwen3 kufikia Agosti 2026, zilizosomwa kutoka kwenye orodha ya tag kwenye ukurasa wa modeli. Kila takwimu hapa chini ni nafasi ya diski kabla ya kuwa RAM, na mbili au tatu kati ya hizi kwa pamoja zitajaza root volume ndogo ya VPS, kwa hivyo ni vyema kujua mahali ambapo Ollama huhifadhi modeli inazopakua kabla ya kuanza kukusanya tag.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

Tag chaguo-msingi ni muhimu hapa. ollama pull qwen3:8b hupakua kiasi kilekile cha 5.2 GB kama ollama pull qwen3:8b-q4_K_M, kwa sababu tag isiyo na kiambishi ndiyo build ya q4_K_M. Q4_K_M si maelewano ambayo maktaba hutoa kwa kusita. Ni chaguo-msingi lililochaguliwa na upstream, kwa hivyo kulingana nalo ndiyo hatua ya kwanza ya busara kwa modeli yoyote ambayo hujaijaribu mwenyewe. Hoja hiyo hiyo ndiyo inayoongoza chaguzi za tag katika kuendesha Qwen 3 kwenye VPS.

Uwiano huu hubaki vilevile katika kila mstari. Kuhama kutoka q4_K_M kwenda q8_0 kunagharimu takriban asilimia sabini zaidi badala ya mara mbili kamili, kwa sababu embedding na output tensors hazikui kwa njia sawa na zingine. fp16 ni takriban mara tatu ya q4_K_M. Modeli ya 32B katika q4_K_M ni 20 GB ya weights, ambayo tayari imepita kile ambacho mashine ya 16 GB inaweza kuhifadhi ikiwa na context window yoyote ile. Kwa mtazamo mpana zaidi wa kile kinachofaa mashine ipi, angalia ni modeli zipi unazoweza kujiendeshea mwenyewe.

Kwa nini KV cache ni gharama ya pili inayotegemea muktadha

Weights ni gharama isiyobadilika. KV cache (key and value cache) ndiyo gharama inayobadilika. Kila token kwenye context window huhifadhi vector zake za key na value kwa kila layer, hivyo cache hukua kwa mstari mnyoofu kulingana na window unayoruhusu. Hutengewa nafasi kwa ajili ya window nzima wakati model inapopakiwa, siyo kadiri mazungumzo yanavyojaza, ndiyo maana window ndefu hukugharimu kumbukumbu hata kwenye prompt ya neno moja.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Namba hizo za model hutoka kwenye configuration ya model yenyewe: 36 layers, 8 key/value heads, na head dimension ya 128. ollama show hukupa usanifu na idadi ya parameter, na config.json ya model kwenye Hugging Face hukupa mengine yaliyobaki. Zidisha gharama kwa kila token kwa ukubwa wa window na cache itaacha kuwa kiasi kidogo kisicho na maana.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Kwenye window ya kawaida ya Ollama ya 4096 tokens, cache huongeza 0.6 GB juu ya weights. Ongeza window hadi 32k na cache pekee hufikia 4.83 GB, ambayo ni karibu kumbukumbu sawa na weights zilizofanyiwa quantization, na kiwango cha chini cha model nzima huwa 10 GB. Iite kiwango cha chini kwa sababu compute buffers na mfumo wa uendeshaji hukaa juu yake. Soma takwimu halisi kutoka kwenye safu ya SIZE ya ollama ps baada ya model kupakiwa.

Window huwekwa kwenye seva, siyo kwa kila ombi, unapoiendesha Ollama kama huduma:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Kwa usakinishaji wa systemd, iweke kwenye drop-in badala yake:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Anzisha upya kwa sudo systemctl restart ollama, kisha angalia safu ya CONTEXT ya ollama ps ili kuthibitisha window ambayo model inayofanya kazi ilipakiwa nayo. OLLAMA_KV_CACHE_TYPE hufanya quantization ya cache yenyewe: f16 ndiyo chaguo-msingi, q8_0 hutumia takriban nusu ya kumbukumbu ya f16, na q4_0 takriban robo. Ni chaguo la kimataifa, hivyo kila model kwenye seva hiyo hupata matibabu sawa. Kwenye mashine ndogo yenye window ndefu, kupunguza cache kwa nusu huokoa kumbukumbu zaidi kuliko mabadiliko mengine yoyote. Kuweka num_ctx na gharama zake inashughulikia window yenyewe kwa kina. Cache pia hupimwa mara moja kwa kila nafasi ya ombi linaloendeshwa kwa wakati mmoja badala ya mara moja kwa kila seva, hivyo kuruhusu Ollama kujibu prompt mbili kwa wakati mmoja huongeza maradufu takwimu uliyopanga, ambayo ndiyo hesabu nyuma ya kuchagua idadi ya nafasi za sambamba na kikomo cha foleni.

Nini kinafaa kwenye VPS ya 8, 16 au 32 GB

Zingatia uzito wa model, pamoja na KV cache, na nafasi ya ziada kwa ajili ya mfumo wa uendeshaji na programu nyingine zinazoendelea. Nafasi ya ziada ya 2 GB inatosha kwenye VPS ndogo.

8 GB. Model ya 4B katika q4_K_M ni 2.6 GB na inakuachia nafasi kwa ajili ya window ndefu. Model ya 8B katika q4_K_M inatosha na window ya kawaida ya 4k na nafasi ndogo sana ya ziada. Usipange kutumia 8B na window ya 32k hapa, kwa sababu kiwango cha chini cha 10 GB tayari kinazidi uwezo wa seva hiyo.

16 GB. 8B katika q4_K_M na window ya 16k au 32k inafanya kazi vizuri. 14B katika q4_K_M ni 9.3 GB ya uzito na inatosha na window ya wastani. 8B katika q8_0 ni 8.9 GB, kwa hivyo inatosha pia, na kulinganisha hizo mbili kwa kutumia prompts zako mwenyewe ndilo zoezi muhimu zaidi unaloweza kufanya kuhusu mada hii.

32 GB. 14B katika q8_0 (16 GB) na 32B katika q4_K_M (20 GB) zote zinapakika. Toleo la 32B lenye window kubwa litakaribia kikomo cha kumbukumbu, kwa hivyo fuatilia ollama ps badala ya kudhani tu.

Ni nini kinachopoteza ubora kwanza katika quantization

Hitilafu ya quantization haisambai kwa usawa katika utendaji wa modeli. Ufasaha wa lugha hudumu kwa muda mrefu zaidi, na ndiyo sababu uharibifu huu ni rahisi kupitwa na wakati: modeli iliyofanyiwa quantization vibaya bado huandika sentensi safi. Usahihi (precision) ndio hupotea kwanza. Kumbukumbu kamili ya namba ya toleo, sahihi ya API, au tarehe. Minyororo mirefu ya hoja, ambapo hitilafu ndogo katika hatua ya pili inageuka kuwa jibu lisilo sahihi katika hatua ya nane. Miundo mikali ya matokeo (strict output formats), ambapo mabano moja yasiyo sahihi hufanya wito wa zana (tool call) kufeli.

Hiyo ya mwisho ndiyo jaribio la kivitendo. Wakati modeli inatakiwa kurejesha JSON ambayo msimbo wako unachakata, uharibifu wa quantization hujitokeza kama hitilafu ya uchakataji (parse error) badala ya maandishi yaliyopungua ubora kidogo, hivyo utaiona siku hiyo hiyo. Wakala wa uandishi wa msimbo (coding agent) ndiyo toleo gumu zaidi la jaribio hilo, kwa sababu humsukuma modeli kupitia wito wa zana mmoja baada ya mwingine, kwa hivyo kuelekeza wakala kwenye seva yako ya Ollama kutafichua quantization iliyopitiliza ndani ya mchana mmoja.

Chini ya biti nne, upotevu wa ubora huwa mkubwa. Aina za q3 na biti mbili zipo kwa ajili ya watu wanaobananisha modeli kubwa kwenye maunzi madogo, na ni chaguo halisi wakati mbadala wake ni kutoiendesha modeli hiyo kabisa. Ni chaguo mbaya kama msingi (default). Kati ya q4_K_M na q8_0, pengo ni dogo kiasi kwamba jedwali la perplexity lililochapishwa halitakupa jibu la uhakika kwa mzigo wako wa kazi, kwa hivyo usijaribu kulitatua kwa njia hiyo. Endesha zote mbili dhidi ya prompts thelathini zako mwenyewe na usome matokeo.

Wakati q8_0 au fp16 inapofaa kutumia RAM

Vuta q8_0 wakati una kumbukumbu ya ziada na kazi inahitaji usahihi wa hali ya juu: uchimbaji wa data uliopangwa (structured extraction), utumiaji wa zana (tool calling), au msimbo unaopaswa kukamilisha compilation. Hapo unanunua bima, siyo mtindo (model) unaoonekana kuwa na akili zaidi.

Vuta fp16 kwa sababu mbili pekee. Aidha unajifanyia quantization ya mtindo na unahitaji faili asilia, au unapima msingi (baseline) ili uweze kujua ni kiasi gani ulichopoteza kwa kutumia build ya bit nne. Kuhudumia kutoka fp16 hutumia kumbukumbu mara tatu zaidi ya q4_K_M kwa tofauti ambayo watu wengi hawawezi kuitambua kwa macho, na kwenye seva ya CPU pekee, hii hupunguza kasi ya token kwa theluthi moja.

Kanuni kuu, ukiwa na bajeti maalum ya kumbukumbu: mtindo mkubwa ukiwa katika q4_K_M mara nyingi huushinda mtindo mdogo ukiwa katika q8_0. 9.3 GB ya uzito wa 14B dhidi ya 8.9 GB ya uzito wa 8B ni kiasi sawa cha RAM (random access memory) na mtindo mkubwa una maarifa zaidi. Jaribu hilo kwenye prompts zako mwenyewe badala ya kuamini bila ushahidi.

Uchakataji wa CPU pekee unadhibitiwa na bandwidth ya kumbukumbu

Mipango mingi ya VPS haina GPU, kwa hivyo modeli huendeshwa kwenye kumbukumbu ya mfumo kwa kutumia CPU ya seva. Uzalishaji wa tokeni basi hudhibitiwa na bandwidth ya kumbukumbu, si kwa hesabu, kwa sababu kuzalisha tokeni moja kunahitaji kusoma kila uzito (weight) mara moja. Hii huweka ukomo ambao hauhusiani na idadi ya cores ulizonunua.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

GB/s hamsini ni takriban takwimu ya kinadharia kwa mfumo wa dual channel DDR4-3200. Sehemu yako ni ndogo zaidi, kwa sababu VPS hushiriki basi hilo na kila mpangaji mwingine kwenye mashine hiyo, kwa hivyo chukulia namba hizo kama ukomo ambao hakuna anayeweza kuufikia. Umbo la grafu ndilo sehemu muhimu: kwenye CPU, kupunguza bits kwa kila uzito kwa nusu takriban huongeza kasi ya tokeni mara mbili. Quantization ndiyo njia kuu ya kuongeza kasi inayopatikana kwenye mashine isiyo na GPU. Ikiwa kasi inayobaki inakubalika inategemea modeli, na Nemotron 3.5 Lightning kwenye VPS hufanya mgawanyo huo kwa build, tag, na kiasi cha RAM maalum. Nusu nyingine ya muda wa kusubiri ni kiasi gani modeli inaamua kuandika, kwa sababu kwa tokeni kumi kwa sekunde, jibu la tokeni mia sita huchukua dakika nzima, kwa hivyo kudhibiti jibu kwa num_predict mara nyingi huokoa muda mwingi wa kusubiri kuliko hatua nyingine ya kupunguza usahihi.

Uchakataji wa prompt hufanya kazi kwa njia tofauti. Kusoma prompt ndefu hudhibitiwa na uwezo wa kompyuta (compute bound) badala ya bandwidth, kwa hivyo cores za ziada husaidia hapo wakati hazifanyi chochote kwa kasi ya uzalishaji. Mashine inayopokea prompt ya 4k haraka na kisha kuzalisha polepole inafanya kazi kawaida.

Usiamini hesabu yoyote bila uthibitisho. Pima tokeni kwa sekunde kwenye mashine yako mwenyewe ukitumia prompt ileile katika kila quantization, na acha namba zako zibatilishe hizi.

Kujifanyia quantization ya model

Ollama inaweza kutengeneza model iliyofanyiwa quantization kutoka kwenye source ya fp16 au fp32, jambo ambalo ni muhimu unapokuwa umefanya fine-tune kitu na hakuna library tag iliyopo. Elekeza Modelfile kwenye weights ambazo hazijafanyiwa quantization:

FROM /path/to/my/model/f16

Kisha jenga na uthibitishe:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize inakubali q8_0, q4_K_S na q4_K_M. Hakuna chaguo la q6_K au q5_K_M hapa, kwa hivyo kwa ajili ya hizo unafanya quantization kwa kutumia zana ya llama.cpp yenyewe na kuingiza (import) faili la GGUF lililokamilika. Njia hiyo ya kuingiza ina changamoto yake, kutokulingana kwa chat template kunakofanya model ijibu kwa maandishi yasiyo na maana, jambo ambalo kuingiza faili la GGUF kwenye Ollama linaelezea kwa kina. Mstari wa quantization kutoka ollama show ndiyo njia unayotumia kuhakikisha kuwa ujenzi umefanya kile ulichokiomba.

Mambo utakayoona wakati mambo yanapoharibika

Kila kitu kinaendeshwa kwenye CPU wakati ulitarajia GPU. Soma safu ya PROCESSOR:

ollama ps

Inachapisha 100% GPU, 100% CPU, au mgawanyo kama 48%/52% CPU/GPU. Mgawanyo unamaanisha kuwa uzito (weights) pamoja na KV cache havikutosha kwenye VRAM (video RAM, kumbukumbu iliyo kwenye kadi ya michoro), kwa hivyo sehemu ya model iliwekwa kwenye kumbukumbu ya mfumo. Kasi hushuka na kukaribia kiwango cha CPU pekee, kwa sababu kila token husubiri nusu ile ya polepole. Punguza ukubwa wa context window, fanya quantization ya cache, au pakua toleo dogo zaidi. Kuongeza cores hakutasaidia.

Model inakatishwa (killed) wakati wa kupakia. Angalia kernel na log ya huduma:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Mstari wenye Out of memory: Killed process unamaanisha kuwa jumla ya uzito, KV cache, na buffers imezidi kumbukumbu iliyopo kwenye seva. Kwenye VPS isiyo na swap iliyosanidiwa, mashine nzima inaweza kukwama kwa sekunde kadhaa kabla ya mstari huo kuonekana.

Majibu yamekuwa mabaya na hukubadilisha chochote. Matoleo mawili ya model moja yanaweza kukaa pamoja ndani ya ollama ls chini ya tag tofauti, na script inayovuta jina lisilo na suffix itafuata chochote ambacho maktaba hiyo inaelekeza kwa sasa. Endesha ollama show dhidi ya tag kamili ambayo mteja wako anaiomba na usome mstari wa quantization, badala ya kuamini jina lililo kwenye faili yako ya configuration.

FAQ

Ni quantization ipi ya Ollama ninayopaswa ku-pull?

Anza na q4_K_M. Hii ndiyo lebo chaguo-msingi inayotolewa na maktaba ya Ollama kwa mifano mingi, kwa hivyo ollama pull qwen3:8b na ollama pull qwen3:8b-q4_K_M huchota faili ileile. Hamia kwenye q8_0 pale tu unapokuwa na kumbukumbu ya ziada na kazi inayohitaji usahihi wa hali ya juu, kama vile kutumia zana (tool calling) au kutoa matokeo ya JSON yaliyopangiliwa. Bajeti ya kumbukumbu ikiwa imepangwa, mfano mkubwa zaidi ukiwa na q4_K_M mara nyingi hufanya kazi vizuri kuliko mfano mdogo ukiwa na q8_0; jaribu mchanganyiko huo kabla ya kutumia RAM nyingi kwa ajili ya usahihi wa juu.

Je, q4_K_M inamaanisha biti nne kwa kila uzito (weight)?

Hapana. Kwa kupima kwenye Llama 3.1 8B, ni 4.89 biti kwa kila uzito, kwa sababu kila kizuizi cha uzito huhifadhi kiwango chake (scale) na tensors nyeti zaidi hupewa aina pana zaidi. Q8_0 hupima 8.5 biti badala ya nane kwa sababu hiyo hiyo. Tumia takwimu iliyopimwa wakati wa kukadiria: idadi ya vigezo (parameter count) mara biti kwa kila uzito, ikigawanywa kwa nane, inatoa ukubwa wa faili katika bytes.

Mfano wa 8B unahitaji RAM kiasi gani kwenye VPS inayotumia CPU pekee?

Jumlisha uzito, KV cache, na nafasi ya ziada. Qwen3 8B katika q4_K_M ni 5.2 GB ya uzito. Katika window ya kawaida ya token 4096, cache huongeza 0.6 GB, na kufanya kiwango cha chini kuwa karibu 5.8 GB kabla ya buffers za kompyuta na mfumo wa uendeshaji. Katika window ya 32k, cache pekee ni 4.83 GB. Panga kuwa na 8 GB kwa window fupi na 16 GB ikiwa unataka window ndefu.

Kwa nini mfano wangu unafanya kazi kwa 100% ya CPU wakati seva ina GPU?

Tekeleza ollama ps na usome safu ya PROCESSOR. 100% CPU, au mgawanyo kama 48%/52% CPU/GPU, inamaanisha kuwa uzito pamoja na KV cache havikutoshea kwenye VRAM, kwa hivyo Ollama iliweka sehemu au mfano mzima kwenye kumbukumbu ya mfumo. Sababu ya kawaida ni context window kubwa kuliko uwezo wa kadi, kwa sababu cache hutengwa kwa ajili ya window nzima wakati mfano unapopakiwa. Punguza window kwa kutumia OLLAMA_CONTEXT_LENGTH, weka OLLAMA_KV_CACHE_TYPE=q8_0 ili kupunguza cache kwa nusu, au pull quantization ndogo zaidi.