Ollama quantization: Tofauti ya q4, q8 na fp16

Mabadiliko ya quantization ya Ollama

Quantization ya Ollama huhifadhi kila uzito (weight) katika modeli kwa kutumia biti chache kuliko faili iliyotumika kuifunza. Lebo inayoishia na q4_K_M huhifadhi takriban biti nne kwa kila uzito, wakati fp16 huhifadhi kumi na sita; hivyo, faili ya kupakua ni robo ya ukubwa wa kawaida na mashine husoma idadi ya baiti (bytes) iliyopungua kwa robo ili kutoa kila token. Uzito huo huzungushwa (rounded) kwenye gridi pana badala ya kufutwa, na katika kiwango cha biti nne, modeli nyingi hujibu karibu sawa na zilivyokuwa katika usahihi kamili (full precision).

Huo ndio uwiano mzima: nafasi ndogo zaidi ya kumbukumbu na token nyingi zaidi kwa sekunde, kwa gharama ya upotevu mdogo wa usahihi. Yafuatayo ni maelekezo ya 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 kuwa tensors nyingi za uzito zimefungashwa kwa biti nne kila moja. q8 inamaanisha biti 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 cha usahihi wa juu. Kizuizi kilicho na thamani moja kubwa isiyo ya kawaida hupata kiwango cha usahihi wa chini. Mizani hiyo ya kila kizuizi ndiyo inayofanya faili ya biti nne kuwa na matumizi, na ndiyo sababu faili ya biti nne haijawahi kuwa na biti nne kamili kwa kila uzito.

Herufi ya mwisho ni mchanganyiko. S, M na L huamua ni tensors ngapi zinazopandishwa daraja juu ya upana unaolengwa. Katika q4_K_M, tensors ambazo huathirika zaidi zinapozungushwa (rounded) huhifadhiwa kwa upana zaidi, wakati idadi 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 ulilochapa:

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 huanza na namba moja: ni bits ngapi ambazo fomati hutumia kwa kila weight, kwa wastani wa faili nzima. 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 dense 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 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 faili halisi:

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, ni karibu sawa na kumbukumbu (memory) inayotumiwa na weights mara tu zinapopakiwa. Ollama haifungui (unpack) chochote wakati wa kupakia: weights zilizopunguzwa ukubwa (quantized weights) hukaa kwenye kumbukumbu katika hali ile ile iliyopakiwa na kila block hubadilishwa inapotumika.

Kile ambacho Ollama husafirisha kwa kila ukubwa wa model

Maktaba huchapisha tag ya q4_K_M, q8_0 na fp16 kwa familia nyingi. Hizi ni ukubwa wa Qwen3 kufikia Agosti 2026, zilizosomwa kutoka kwenye orodha ya tag katika ukurasa wa model.

[
  {
    "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 suluhu ya shingo upande inayotolewa na maktaba. Ni chaguo-msingi lililochaguliwa na upstream, kwa hivyo kulifuata ndilo hatua ya kwanza ya busara kwa model yoyote ambayo hujaijaribu mwenyewe. Hoja hiyo hiyo ndiyo inayoongoza uchaguzi wa tag katika kuendesha Qwen 3 kwenye VPS.

Uwiano huu hubaki vilevile katika kila safu. 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 namna sawa na sehemu nyingine. fp16 ni takriban mara tatu ya q4_K_M. Model ya 32B katika q4_K_M ni 20 GB ya uzito, ambayo tayari inazidi kile ambacho mashine ya 16 GB inaweza kuhifadhi ikiwa na context window yoyote ile. Kwa mtazamo mpana zaidi wa kile kinachotoshea kwenye mashine ipi, angalia model zipi unaweza kuji-hostia.

Kwa nini KV cache ni gharama ya pili inayotegemea muktadha

Uzito (weights) ni gharama isiyobadilika. KV cache (key and value cache) ni gharama inayobadilika. Kila token katika dirisha la muktadha huhifadhi vekta zake za key na value kwa kila safu, kwa hivyo cache hukua kwa mstari mnyoofu kulingana na dirisha unaloruhusu. Hutengewa nafasi kwa dirisha zima wakati modeli inapopakiwa, si kadiri mazungumzo yanavyojaza, ndiyo maana dirisha refu 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 modeli hutoka kwenye usanidi wa modeli yenyewe: safu 36, vichwa 8 vya key/value, na ukubwa wa kichwa wa 128. ollama show hukupa usanifu na idadi ya vigezo, na config.json ya modeli kwenye Hugging Face hukupa mengine yaliyobaki. Zidisha gharama kwa kila token na ukubwa wa dirisha, 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
  }
]

Katika dirisha la kawaida la Ollama la token 4096, cache huongeza 0.6 GB juu ya uzito. Ongeza dirisha hadi 32k na cache pekee hufikia 4.83 GB, ambayo ni karibu kumbukumbu sawa na uzito uliopunguzwa (quantized weights), na kiwango cha chini cha kumbukumbu kwa modeli nzima huwa 10 GB. Iite kiwango cha chini kwa sababu bafa za kompyuta na mfumo wa uendeshaji huongezeka juu yake. Soma takwimu halisi kutoka kwenye safu ya SIZE ya ollama ps baada ya modeli kupakiwa.

Dirisha huwekwa kwenye seva, si kwa kila ombi, unapoiendesha Ollama kama huduma:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Kwa usakinishaji wa systemd, iweke kwenye faili ya 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 dirisha ambalo modeli inayofanya kazi ilipakiwa nalo. 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. Hili ni chaguo la kimataifa, kwa hivyo kila modeli kwenye seva hiyo hupata matibabu sawa. Kwenye mashine ndogo yenye dirisha refu, kupunguza cache kwa nusu huokoa kumbukumbu zaidi kuliko mabadiliko mengine yoyote. Kuweka num_ctx na gharama zake inashughulikia dirisha lenyewe kwa kina.

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. GB 2 za nafasi ya ziada ni kiasi kinachofaa kwenye VPS ndogo.

8 GB. Model ya 4B katika q4_K_M ni 2.6 GB na huacha nafasi kwa ajili ya window ndefu. Model ya 8B katika q4_K_M inatosha ikiwa 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 ikiwa na window ya 16k au 32k inafanya kazi vizuri. 14B katika q4_K_M ina uzito wa 9.3 GB na inatosha ikiwa 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 la maana 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 likiwa na window kubwa litakaribia kikomo cha kumbukumbu, kwa hivyo fuatilia ollama ps badala ya kudhani tu.

Ni nini kinachoharibika 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 migumu ya matokeo (output formats), ambapo mabano moja yasiyo sahihi hufanya wito wa zana (tool call) kufeli.

Jambo la mwisho ndilo jaribio la kivitendo. Wakati modeli inapaswa kurejesha JSON ambayo msimbo wako unaichakata, uharibifu wa quantization hujitokeza kama hitilafu ya uchakataji (parse error) badala ya maandishi yaliyopungua ubora kidogo, hivyo utaiona siku hiyo hiyo.

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 la kweli wakati njia mbadala ni kutoiendesha modeli hiyo kabisa. Hizi 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 kutatua suala hilo 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 inayohitaji usahihi wa hali ya juu: uchimbaji wa data uliopangwa, utumiaji wa zana, au msimbo unaopaswa kukusanywa (compile). Hapo unanunua bima, siyo mtindo (model) unaoonekana kuwa na akili zaidi.

Vuta fp16 kwa sababu mbili pekee. Aidha unajifanyia quantization ya mtindo huo na unahitaji faili asilia, au unapima msingi ili ujue ni kiasi gani ulichopoteza kwa kutumia toleo la bit nne. Kuhudumia kutoka fp16 hutumia kumbukumbu mara tatu zaidi ya q4_K_M kwa tofauti ambayo watu wengi hawawezi kuiona 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 zaidi ukiwa katika q4_K_M kwa kawaida huushinda mtindo mdogo zaidi 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 zaidi una maarifa mengi zaidi. Jaribu hilo kwa kutumia prompts zako mwenyewe badala ya kuamini tu 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 50 ni takriban takwimu ya kinadharia kwa mfumo wa dual channel DDR4-3200. Sehemu yako ni ndogo zaidi, kwa sababu VPS hushiriki bus hiyo na kila mpangaji mwingine kwenye mashine hiyo, kwa hivyo chukulia namba hizo kama ukomo ambao hakuna anayeweza kuufikia. Umbo la utendaji 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.

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

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

Kujifanyia quantization ya model

Ollama inaweza kutengeneza model iliyofanyiwa quantization kutoka kwa chanzo cha fp16 au fp32, jambo ambalo ni muhimu unapokuwa umefanya fine-tune kwa kitu fulani na hakuna library tag inayopatikana. 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 faili ya GGUF iliyokamilika. Mstari wa quantization kutoka ollama show ndiyo njia unayotumia kuhakikisha kuwa ujenzi umefanya kile ulichokiomba.

Mambo utakayoyaona wakati mambo hayaendi sawa

Kila kitu kinaendeshwa kwenye CPU wakati ulitegemea 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 havikutoshea kwenye VRAM (video RAM, kumbukumbu iliyo kwenye kadi ya michoro), kwa hivyo sehemu ya model iliwekwa kwenye kumbukumbu ya mfumo. Kasi hupungua na kufikia 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 kuwepo kando kando katika ollama ls chini ya tag tofauti, na hati (script) inayovuta jina lisilo na suffix itafuata chochote ambacho maktaba hiyo inaelekeza kwa sasa. Tekeleza ollama show dhidi ya tag kamili ambayo mteja wako anaiomba na usome mstari wa quantization, badala ya kuamini jina lililo kwenye faili yako ya usanidi.

FAQ

Ni quantization ipi ya Ollama ninayopaswa ku-pull?

Anza na q4_K_M. Hii ndiyo lebo ya kawaida (default tag) 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 imepungua, mfano mkubwa ukiwa na q4_K_M mara nyingi hufanya kazi vizuri zaidi kuliko mfano mdogo ukiwa na q8_0; kwa hivyo 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. Ikipimwa 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.

VPS inayotumia CPU pekee inahitaji RAM kiasi gani kwa mfano wa 8B?

Jumlisha uzito, KV cache, na nafasi ya ziada (headroom). Qwen3 8B katika q4_K_M ni 5.2 GB ya uzito. Katika dirisha la kawaida la 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 dirisha la 32k, cache pekee ni 4.83 GB. Panga kuwa na 8 GB kwa dirisha fupi na 16 GB ikiwa unataka dirisha refu.

Kwa nini mfano wangu unaendesha CPU kwa 100% wakati seva ina GPU?

Endesha 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 dirisha la muktadha (context window) kuwa kubwa kuliko uwezo wa kadi, kwa sababu cache hutengewa nafasi kwa ajili ya dirisha zima wakati mfano unapopakiwa. Punguza dirisha kwa kutumia OLLAMA_CONTEXT_LENGTH, weka OLLAMA_KV_CACHE_TYPE=q8_0 ili kupunguza cache kwa nusu, au pull quantization ndogo zaidi.