Ollama quantization: Q4, Q8 o fp16?

Binabago ng quantization sa Ollama

Iniimbak ng quantization sa Ollama ang bawat weight ng isang model gamit ang mas kaunting bit kaysa sa file kung saan ito sinanay. Ang tag na nagtatapos sa q4_K_M ay gumagamit ng humigit-kumulang apat na bit bawat weight, samantalang fp16 ay gumagamit ng labing-anim. Dahil dito, humigit-kumulang isang-kapat ang laki ng download, at isang-kapat lamang ng mga byte ang binabasa ng machine upang makagawa ng bawat token. Niroround ang mga weight sa isang mas maluwag na grid; hindi basta itinatapon ang mga ito. Sa apat na bit, karamihan ng mga model ay sumasagot nang halos katulad ng resulta sa full precision.

Iyan ang kabuuang trade-off: mas maliit na memory footprint at mas maraming token bawat segundo, kapalit ng maliit na bawas sa accuracy. Ipinapaliwanag sa mga sumusunod kung paano tantiyahin ang dalawang epektong ito para sa isang partikular na model sa isang partikular na machine, bago ka gumugol ng dalawampung minuto sa pag-download ng file na hindi kasya.

Kung hindi pa tumatakbo ang Ollama, magsimula sa pag-install ng Ollama sa isang VPS. Ipinapalagay ng page na ito na gumagana na ang ollama ls.

Paano basahin ang Ollama quantization tag gaya ng q4_K_M

Ang mga local model ay inilalabas bilang GGUF files, ang format na ginagamit ng llama.cpp upang mag-imbak ng weights sa disk. Nakabatay ang Ollama sa llama.cpp, kaya hindi binabago ng mga Ollama tag ang mga pangalan ng quantization ng llama.cpp.

Ang numero ang target width. Ipinapahiwatig ng q4 na karamihan sa weight tensor ay naka-pack sa tig-aapat na bit. Ipinapahiwatig ng q8 ang walo. Hindi naka-quantize ang fp16: ang model ito sa sixteen-bit floating point, ang precision kung saan karaniwang pino-publish ang mga model.

Ang K ang tanda ng K-quant. Pinapangkat ang mga weight sa maliliit na block, at nag-iimbak ang bawat block ng sarili nitong scale kasabay ng mga naka-pack na value. Ang block na ang mga weight ay nasa paligid ng 0.01 ay nakakakuha ng mas pinong scale. Ang block na may isang malaking outlier ay nakakakuha ng mas maluwag na scale. Ang mga per-block scale na ito ang dahilan kung bakit nagagamit ang four-bit file, at sila rin ang dahilan kung bakit ang four-bit file ay hindi kailanman eksaktong four bits bawat weight.

Ang huling letra ang mixture. Tinutukoy ng S, M at L kung ilang tensor ang itataas sa target width. Sa q4_K_M, ang mga tensor na pinakamalaking nawawalan ng kalidad kapag ni-round off ay iniimbak sa mas malawak na format, habang nananatili sa four bits ang karamihan. Kaya mas mahusay ang output ng q4_K_M kaysa sa mas lumang q4_0, kahit halos pareho ang laki ng file.

Tanungin ang Ollama kung ano ang nasa disk sa halip na manghula batay sa pangalang inilagay mo:

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

Ipinapakita ng ollama show ang architecture, parameters, quantization, context length at embedding length. Ang linyang quantization ang batayan para sa model na ilang buwan mo nang ni-pull at hindi mo na matandaang pinili.

Bits bawat weight ang pinagmumulan ng laki ng file

Nagsisimula ang bawat pagtantiya ng laki sa isang numero: ilang bits ang ginagamit ng format sa bawat weight, na naka-average sa buong file. Naglalathala ang llama.cpp ng mga nasukat na figure para sa Llama 3.1 8B sa dokumentasyon nito tungkol sa quantize, at maayos itong naaangkop sa anumang dense model na may katulad na estruktura.

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

Ang kapansin-pansin sa talahanayang iyon ay ang ikalawang column. Ang Q4_K_M ay hindi apat na bits bawat weight. Sinusukat ito bilang 4.89 bits, dahil kumokonsumo rin ng aktuwal na espasyo ang block scales at promoted tensors. Ang Q8_0 naman ay sumusukat ng 8.5 bits sa halip na walo, sa parehong dahilan. Gamitin ang nasukat na numero upang ang resulta ng arithmetic ay lumapit sa aktuwal na file nang ilang porsiyento lamang:

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

Iyan ang 4.58 GiB na Q4_K_M file, na nakuha mula sa dalawang numero. Halos katumbas din nito ang memory na ginagamit ng weights kapag na-load na. Walang ina-unpack ang Ollama habang naglo-load: nananatili sa memory ang quantized weights sa parehong packed form, at kino-convert ang bawat block kapag ginagamit ito.

Ano talaga ang sine-ship ng Ollama sa bawat model size

Naglalabas ang library ng q4_K_M, q8_0, at fp16 tag para sa karamihan ng mga family. May ilang mas bagong family na hindi sumusunod sa pattern na ito. Lumalabas ang mga ito sa library bilang cloud-only tag na walang mada-download sa anumang size. Ito ang limitasyong makikita kapag sinubukan mong patakbuhin ang GLM 5.2 sa isang VPS. Ito ang mga Qwen3 size noong August 2026, batay sa tag list sa model page. Ang bawat figure sa ibaba ay disk usage bago pa ito mailagay sa RAM. Kapag pinagsama ang dalawa o tatlo, mapupuno nito ang maliit na VPS root volume. Kaya mahalagang malaman muna kung saan iniimbak ng Ollama ang mga model na dina-download nito bago ka magsimulang mangolekta ng mga 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
  }
]

Mahalaga rito ang default tag. Parehong eksaktong 5.2 GB ang dina-download ng ollama pull qwen3:8b at ollama pull qwen3:8b-q4_K_M, dahil ang tag na walang suffix ay ang q4_K_M build. Hindi isang kompromiso ang Q4_K_M na napilitan lamang ialok ng library. Ito ang default na pinili ng upstream, kaya makatuwiran itong unang gamitin para sa anumang model na hindi mo pa nasusubukan mismo. Ito rin ang dahilan sa pagpili ng mga tag sa pagpapatakbo ng Qwen 3 sa isang VPS.

Pare-pareho ang mga ratio sa bawat row. Kapag lumipat mula q4_K_M patungong q8_0, humigit-kumulang 70% ang nadadagdag sa kailangan, sa halip na eksaktong dumoble. Ito ay dahil hindi pareho ang pag-scale ng embedding at output tensor kumpara sa iba pang bahagi. Tinatayang tatlong beses ang laki ng fp16 kumpara sa q4_K_M. Ang 32B model sa q4_K_M ay may 20 GB na weights. Lampas na ito sa kayang hawakan ng 16 GB machine kahit walang anumang context window. Para sa mas malawak na pagtingin kung aling model ang kasya sa bawat machine, tingnan ang mga model na maaari mong i-self-host.

Bakit ang KV cache ay hiwalay na gastos na nakadepende sa context

Fixed cost ang weights. Variable cost naman ang KV cache (key at value cache). Pinananatili ng bawat token sa context window ang mga key at value vector nito sa bawat layer, kaya tumataas nang linear ang laki ng cache kasabay ng window na itinakda mo. Inilalaan ito para sa buong window kapag naglo-load ang model, hindi habang napupuno ang conversation. Dahil dito, kumokonsumo ng memory ang mahabang window kahit isang salita lamang ang prompt.

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

Galing sa sariling configuration ng model ang mga numerong ito: 36 layers, 8 key/value heads, at head dimension na 128. Ibinibigay ng ollama show ang architecture at parameter count, habang nasa config.json ng model sa Hugging Face ang iba pang detalye. Kapag minultiply ang cost bawat token sa window size, hindi na maliit na rounding error ang cache.

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

Sa default window ng Ollama na 4096 tokens, nagdadagdag ang cache ng 0.6 GB bukod sa weights. Kapag tinaasan ang window sa 32k, umaabot nang mag-isa ang cache sa 4.83 GB. Halos kasing laki na ito ng memory ng quantized weights, kaya nagiging 10 GB ang minimum para sa buong model. Tinatawag itong minimum dahil gumagamit pa ng karagdagang memory ang compute buffers at operating system. Kunin ang aktuwal na figure sa column na SIZE ng ollama ps pagkatapos mag-load ang model.

Itinatakda ang window sa server, hindi sa bawat request, kapag pinapatakbo mo ang Ollama bilang service:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Para sa systemd install, ilagay naman ito sa drop-in:

sudo systemctl edit ollama

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

Mag-restart gamit ang sudo systemctl restart ollama, pagkatapos ay tingnan ang column na CONTEXT ng ollama ps upang makumpirma ang window na aktuwal na ginamit sa pag-load ng tumatakbong model. Kino-quantize mismo ng OLLAMA_KV_CACHE_TYPE ang cache: default ang f16, humigit-kumulang kalahati ng memory ng f16 ang ginagamit ng q8_0, at humigit-kumulang isang-kapat naman ang ginagamit ng q4_0. Global option ito, kaya pareho ang treatment sa bawat model sa server na iyon. Sa maliit na machine na may mahabang window, mas maraming memory ang nababawi sa paghahati sa kalahati ng cache kaysa sa alinmang isang pagbabago. Detalyadong tinatalakay ng Pagtatakda ng num_ctx at gastos nito ang mismong window. Isang beses ding sine-size ang cache para sa bawat concurrent request slot, hindi isang beses para sa buong server. Kaya kapag pinayagan mong sabay na sagutin ng Ollama ang dalawang prompt, dodoble ang na-budget mong figure. Ito ang arithmetic sa likod ng pagpili ng bilang ng parallel slot at limitasyon ng queue.

Ano ang kasya sa 8, 16, o 32 GB na VPS

Isama sa pagtutuos ang budget para sa weights, KV cache, at headroom para sa operating system at iba pang tumatakbo. Komportable ang 2 GB na headroom sa maliit na VPS.

8 GB. Ang 4B model sa q4_K_M ay 2.6 GB at may natitirang espasyo para sa mahabang window. Kasya ang 8B model sa q4_K_M kapag default na 4k window ang gamit, pero napakaliit ng natitirang headroom. Huwag magplano ng 8B na may 32k window dito dahil lampas na sa kapasidad ng server ang minimum na 10 GB.

16 GB. Komportable ang 8B sa q4_K_M na may 16k o 32k window. Ang 14B sa q4_K_M ay may 9.3 GB na weights at kasya sa katamtamang window. Ang 8B sa q8_0 ay 8.9 GB, kaya kasya rin ito. Ang paghahambing sa dalawang ito gamit ang sarili mong prompt ang pinakamahalagang oras na maaari mong ilaan sa paksang ito.

32 GB. Parehong naglo-load ang 14B sa q8_0 (16 GB) at 32B sa q4_K_M (20 GB). Kapag malaki ang window ng 32B build, lalapit ito sa limitasyon. Kaya subaybayan ang ollama ps sa halip na ipagpalagay na kasya ito.

Ano ang unang napipinsala ng quantization

Hindi pantay na nakaaapekto ang quantization error sa mga kakayahan ng isang model. Pinakamatagal na nananatili ang fluency. Dahil dito, madaling hindi mapansin ang pinsala: nakasusulat pa rin ng malilinis na pangungusap ang isang model na sumailalim sa sobrang agresibong quantization. Precision ang unang humihina. Kabilang dito ang eksaktong pag-alala sa version number, API signature, o petsa. Humihina rin ang mahahabang chain of reasoning, kung saan ang maliit na error sa step two ay nagiging maling sagot sa step eight. Problema rin ang strict output formats, kung saan maaaring maging sanhi ng pagkabigo ng tool call ang isang maling bracket.

Ang huling halimbawa ang praktikal na pagsubok. Kapag kailangang magbalik ng JSON ang model na bina-parse ng code mo, nagiging parse error ang pinsalang dulot ng quantization sa halip na bahagyang mas mahinang prose. Kaya makikita mo agad ang epekto sa parehong araw. Pinakamahigpit na bersyon ng pagsubok na ito ang coding agent, dahil sunod-sunod nitong pinapagana ang model sa mga tool call. Kaya ang pagturo sa isang agent sa iyong Ollama server ay maglalantad ng sobrang agresibong quantization sa loob ng isang hapon.

Mabilis lumalaki ang loss kapag mas mababa sa four bits. Para sa mga nagtitipid ng resources upang maipatupad ang malaking model sa maliit na hardware, umiiral ang q3 at two-bit types. Praktikal na opsyon ang mga ito kapag ang alternatibo ay hindi talaga patakbuhin ang model. Hindi magandang default ang mga ito. Maliit lamang ang agwat ng q4_K_M at q8_0. Hindi sapat ang published perplexity table upang matukoy kung alin ang mas angkop sa workload mo, kaya huwag iyon ang gamitin na batayan. Patakbuhin ang dalawang model gamit ang thirty sarili mong prompt at basahin ang output.

Kailan sulit gamitin ang q8_0 o fp16 sa RAM

Gamitin ang q8_0 kapag tunay na may bakanteng memory at malaki ang epekto ng maliliit na error sa gawain: structured extraction, tool calling, at code na kailangang mag-compile. Parang insurance ang binibili mo rito, hindi modelong kapansin-pansing mas matalino.

Gamitin ang fp16 sa dalawang dahilan lamang. Maaaring ikaw mismo ang nag-quantize ng model at kailangan mo ang source file, o nagsusukat ka ng baseline upang malaman kung gaano karami ang isinakripisyo ng iyong four-bit build. Ang pag-serve mula sa fp16 ay kumokonsumo ng tatlong beses na memory kumpara sa q4_K_M, para sa kaibahang hindi matukoy ng karamihan kapag blind test. Sa CPU-only box, ibinababa rin nito sa isang-katlo ang token rate.

Mas matibay na tuntunin kapag fixed ang memory budget: karaniwang mas mahusay ang mas malaking model sa q4_K_M kaysa sa mas maliit na model sa q8_0. Ang 9.3 GB ng 14B weights kumpara sa 8.9 GB ng 8B weights ay halos magkapareho ang RAM (random access memory), ngunit mas marami ang alam ng mas malaking model. Subukan ito sa sarili mong prompts sa halip na tanggapin lamang ito nang walang pagsusuri.

CPU-only inference ay limitado ng memory bandwidth

Karamihan ng VPS plan ay walang GPU, kaya tumatakbo ang model sa system memory gamit ang host CPU. Nakadepende ang generation sa memory bandwidth, hindi sa arithmetic, dahil kailangang basahin nang isang beses ang bawat weight para makagawa ng isang token. Dahil dito, may limitasyon na walang kaugnayan sa dami ng cores na binili mo.

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

Ang 50 GB/s ay humigit-kumulang na theoretical figure para sa isang dual-channel DDR4-3200 host. Mas maliit ang bahagi mo dahil pinaghahatian ng VPS ang bus na iyon ng lahat ng ibang tenant sa machine. Kaya ituring ang mga numerong iyon bilang ceiling na hindi naaabot ng sinuman. Ang mahalaga ay ang pattern: sa CPU, ang paghahati sa bits bawat weight ay karaniwang nagdodoble sa token rate. Ang quantization ang pinakamalaking speed lever na available sa machine na walang GPU. Kung katanggap-tanggap ang natitirang rate ay nakadepende sa model. Sa Nemotron 3.5 Lightning sa isang VPS, ipinapakita ang kalkulasyong iyon para sa isang partikular na build, kasama ang tag at RAM figure. Ang isa pang bahagi ng paghihintay ay kung gaano karami ang isinusulat ng model. Sa 10 tokens bawat segundo, umaabot ng isang buong minuto ang 600-token na sagot. Kaya ang pag-limit sa reply gamit ang num_predict ay madalas na mas nakababawas sa oras ng paghihintay kaysa sa isa pang pagbaba sa precision.

Iba ang kilos ng prompt processing. Compute-bound ito sa halip na bandwidth-bound, kaya nakatutulong ang dagdag na cores habang halos walang epekto sa generation speed. Normal ang isang machine na mabilis tumanggap ng 4k prompt at pagkatapos ay mabagal mag-generate.

Huwag tanggapin ang alinman sa mga kalkulasyong ito nang walang pagsusuri. Sukatin ang tokens bawat segundo sa sarili mong machine gamit ang parehong prompt sa bawat quantization, at hayaang manaig ang sarili mong mga resulta.

Pag-quantize mismo ng model

Makakagawa ang Ollama ng quantized model mula sa fp16 o fp32 source. Mahalaga ito kapag may fine-tuned kang model at walang library tag para rito. Ituro ang isang Modelfile sa unquantized weights:

FROM /path/to/my/model/f16

Pagkatapos, i-build at kumpirmahin:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

Tumatanggap ang --quantize ng q8_0, q4_K_S, at q4_K_M. Walang opsyong q6_K o q5_K_M dito. Para sa mga iyon, gamitin ang sariling tool ng llama.cpp para mag-quantize, at i-import ang natapos na GGUF file. May sariling problema ang import route na ito: maaaring hindi magkatugma ang chat template at maging hindi maintindihan ang mga reply ng model. Tinalakay ito sa pag-i-import ng GGUF file sa Ollama. Gamitin ang linyang quantization mula sa ollama show upang tiyaking ginawa ng build ang itinakda mo.

Makikita mo kapag may naging problema

CPU ang ginagamit ng lahat kahit GPU ang inaasahan mo. Basahin ang column na PROCESSOR:

ollama ps

Nagpi-print ito ng 100% GPU, 100% CPU, o split gaya ng 48%/52% CPU/GPU. Ibig sabihin ng split, hindi nagkasya sa VRAM (video RAM, ang memory sa graphics card) ang weights at KV cache, kaya may bahagi ng model na inilagay sa system memory. Bumabagal ang performance at halos kapantay na ng CPU-only rate, dahil naghihintay ang bawat token sa mas mabagal na bahagi. Bawasan ang context window, i-quantize ang cache, o gumamit ng mas maliit na build. Hindi makakatulong ang pagdagdag ng cores.

Napatay ang model habang naglo-load. Suriin ang kernel at service log:

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

Ang linyang may Out of memory: Killed process ay nangangahulugang lumampas sa memory ng machine ang kabuuang laki ng weights, KV cache, at buffers. Sa VPS na walang naka-configure na swap, maaaring mag-stall ang buong machine nang ilang segundo bago lumabas ang linyang iyon.

Lumala ang mga sagot kahit wala kang binago. Maaaring magkatabi sa ollama ls ang dalawang build ng parehong model sa ilalim ng magkaibang tag. Susunod ang script na kumukuha ng unsuffixed name sa target na kasalukuyang itinuturo ng library. Patakbuhin ang ollama show gamit ang eksaktong tag na hinihingi ng client, at basahin ang linyang quantization sa halip na umasa sa pangalan sa configuration file.

FAQ

Aling Ollama quantization ang dapat kong i-pull?

Magsimula sa q4_K_M. Ito ang default tag na ginagamit ng Ollama library para sa karamihan ng mga model, kaya ollama pull qwen3:8b at ollama pull qwen3:8b-q4_K_M ay parehong kumukuha ng iisang file. Lumipat sa q8_0 kapag may ekstrang memory at hindi katanggap-tanggap ang maliliit na error, gaya ng tool calling o structured JSON output. Kapag fixed ang memory budget, karaniwang mas mahusay ang mas malaking model sa q4_K_M kaysa sa mas maliit na model sa q8_0, kaya subukan muna ang kombinasyong iyon bago gumamit ng mas maraming RAM para sa precision.

Talaga bang nangangahulugang apat na bits bawat weight ang q4_K_M?

Hindi. Kapag sinukat sa Llama 3.1 8B, ito ay 4.89 bits bawat weight, dahil may sariling scale ang bawat block ng weights at ina-upgrade sa mas malawak na type ang mga tensor na pinakasensitibo. Ang Q8_0 ay may sukat na 8.5 bits sa halip na walo dahil sa parehong dahilan. Gamitin ang sinusukat na value sa pagtatantiya: ang parameter count na minultiply sa bits bawat weight, at hinati sa walo, ay nagbibigay ng file size sa bytes.

Gaano karaming RAM ang kailangan ng 8B model sa CPU-only VPS?

Pagsamahin ang weights, KV cache, at headroom. Ang Qwen3 8B sa q4_K_M ay may 5.2 GB na weights. Sa default na 4096-token window, nagdaragdag ang cache ng 0.6 GB, kaya humigit-kumulang 5.8 GB ang minimum bago isama ang compute buffers at operating system. Sa 32k window, 4.83 GB ang cache lamang. Maglaan ng 8 GB para sa maikling window at 16 GB kung kailangan mo ng mahabang window.

Bakit gumagamit ang model ko ng 100% CPU kahit may GPU ang server?

Patakbuhin ang ollama ps at basahin ang PROCESSOR column. Ang 100% CPU, o split na gaya ng 48%/52% CPU/GPU, ay nangangahulugang hindi kasya sa VRAM ang weights at KV cache, kaya inilagay ni Ollama ang bahagi o ang buong model sa system memory. Karaniwang sanhi nito ang context window na mas malaki kaysa sa kayang hawakan ng GPU, dahil inilalaan ang cache para sa buong window kapag naglo-load ang model. Bawasan ang window gamit ang OLLAMA_CONTEXT_LENGTH, itakda ang OLLAMA_KV_CACHE_TYPE=q8_0 para hatiin sa dalawa ang cache, o mag-pull ng mas maliit na quantization.