Ollama quantization: Q4, Q8 o fp16?

Mga binabago ng Ollama quantization

Sa Ollama quantization, ini-store ang bawat weight ng isang model gamit ang mas kaunting bits kaysa sa file kung saan ito sinanay. Ang tag na nagtatapos sa q4_K_M ay gumagamit ng humigit-kumulang apat na bits bawat weight, samantalang ang fp16 ay gumagamit ng labing-anim. Dahil dito, humigit-kumulang isang-kapat ang laki ng download, at isang-kapat din ng mga byte ang kailangang basahin ng machine upang makagawa ng bawat token. Ni-round ang mga weight sa isang mas magaspang na grid; hindi sila basta itinatapon. Sa apat na bits, karamihan ng mga model ay sumasagot nang halos katulad ng output nila sa full precision.

Iyon ang buong trade-off: mas maliit nang malaki ang memory footprint at mas maraming token kada segundo, kapalit ng maliit na pagkawala sa accuracy. Ang susunod na bahagi ay nagpapaliwanag kung paano tantiyahin ang dalawang epektong ito para sa isang partikular na model sa isang partikular na box, bago ka gumugol ng dalawampung minuto sa pag-download ng file na hindi naman magkakasya.

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 nire-release bilang GGUF file, ang format na ginagamit ng llama.cpp para i-store ang weights sa disk. Nakabatay ang Ollama sa llama.cpp, kaya pareho pa rin ang quantization name ng llama.cpp sa mga Ollama tag.

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

Ang K ang nagmamarka sa isang K-quant. Pinapangkat ang mga weight sa maliliit na block, at bawat block ay nag-i-store ng sarili nitong scale kasama ng mga naka-pack na value. Ang block na ang mga weight ay nasa paligid ng 0.01 ay gumagamit ng mas pinong scale. Ang block na may isang malaking outlier ay gumagamit 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 ipo-promote lampas sa target width. Sa q4_K_M, ang mga tensor na pinakamasamang naaapektuhan kapag ni-round off ay ini-store sa mas malawak na format, habang nananatili sa four bits ang karamihan. Kaya mas maganda ang output ng q4_K_M kaysa sa mas lumang q4_0 sa halos kaparehong file size.

Tanungin ang Ollama kung ano ang aktuwal na naka-store sa disk sa halip na manghula batay sa pangalang inilagay mo:

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

Ipi-print ng ollama show ang architecture, parameters, quantization, context length at embedding length. Ang linyang quantization ang ground truth para sa model na hinila mo ilang buwan na ang nakalipas at hindi mo na matandaang pinili mo.

Bits per weight ang pinagmumulan ng file size

Nagsisimula ang bawat pagtatantiya ng size sa isang numero: ilang bits ang ginagamit ng format para sa bawat weight, na naka-average sa buong file. Naglalathala ang llama.cpp ng mga nasukat na value para sa Llama 3.1 8B sa quantize documentation nito, at maaasahan ang mga ito para sa anumang dense model na may katulad na structure.

[
  {
    "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 table na 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 space ang block scales at promoted tensors. Ang Q8_0 ay sumusukat ng 8.5 bits sa halip na walo, dahil sa parehong dahilan. Gamitin ang nasukat na numero, at lalapit sa loob ng ilang porsiyento ang arithmetic sa aktuwal na file:

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 ganoon din ang memory na ginagamit ng weights kapag na-load na ang mga ito. Walang ina-unpack ang Ollama kapag naglo-load: nananatili sa memory ang quantized weights sa parehong packed form, at kino-convert ang bawat block habang ginagamit ito.

Ano talaga ang inilalabas ng Ollama para sa bawat model size

Naglalabas ang library ng tag na q4_K_M, q8_0, at fp16 para sa karamihan ng mga family. Ito ang mga Qwen3 size noong August 2026, batay sa tag list sa model page.

[
  {
    "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 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 mismo. Ang Q4_K_M ay hindi kompromisong iniaalok lamang ng library. Ito ang default na pinili ng upstream, kaya makatuwirang ito ang unang gamitin sa anumang model na hindi mo pa nasusubukan. 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 patungo sa q8_0, humigit-kumulang 70 porsiyento ang dagdag sa laki sa halip na eksaktong doble, dahil hindi pareho ang scaling ng embedding at output tensors sa natitirang bahagi. Humigit-kumulang tatlong beses ang laki ng fp16 kumpara sa q4_K_M. Ang 32B model sa q4_K_M ay may 20 GB na weights, kaya lampas na ito sa kayang ilaman ng 16 GB na machine kahit walang anumang context window. Para sa mas malawak na paliwanag kung aling mga model ang kasya sa bawat machine, tingnan ang kung aling mga model ang maaari mong i-self-host.

Bakit ang KV cache ay isang pangalawang gastusing 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 key at value vector nito para sa bawat layer, kaya lumalaki nang tuwiran ang cache kasabay ng window na pinapayagan mo. Inilalaan ito para sa buong window kapag naglo-load ang model, hindi habang napupuno ang conversation. Kaya 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

Nagmula ang mga numerong iyon sa sariling configuration ng model: 36 layers, 8 key/value heads, at head dimension na 128. Ibinibigay ng ollama show ang architecture at parameter count, at makikita sa config.json ng model sa Hugging Face ang iba pang detalye. I-multiply ang cost bawat token sa laki ng window, at 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, nagdaragdag 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 kasinglaki na ito ng memory ng quantized weights, at nagiging 10 GB ang minimum para sa buong model. Tinatawag itong minimum dahil kumokonsumo pa ng memory ang compute buffers at operating system. Basahin ang aktuwal na value sa column na SIZE ng ollama ps pagkatapos mag-load ang model.

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

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Para sa systemd install, ilagay ito sa isang 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 tingnan ang column na CONTEXT ng ollama ps upang makumpirma ang window na aktuwal na ginamit sa pag-load ng tumatakbong model. Kina-quantize rin ng OLLAMA_KV_CACHE_TYPE ang cache mismo: 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 server na may mahabang window, mas maraming memory ang napapalaya ng paghahati sa kalahati ng cache kaysa sa anumang ibang iisang pagbabago. Mas detalyadong tinatalakay sa Pagtatakda ng num_ctx at gastos nito ang mismong window.

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

Isama sa budget ang weights, KV cache, headroom para sa operating system, at anumang iba pang tumatakbo. Kumportable 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 gamit ang default na 4k window, pero napakaliit ng slack. Huwag planuhing gumamit ng 8B na may 32k window dito, dahil lampas na sa kapasidad ng machine ang floor na 10 GB.

16 GB. Kumportable 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 pinakamainam na oras na ilaan mo para 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, malalapit ito sa limitasyon. Kaya i-monitor ang ollama ps sa halip na basta ipagpalagay na kasya ito.

Ano ang unang nade-degrade sa quantization

Hindi pantay ang pagkalat ng quantization error sa mga ginagawa ng isang model. Pinakamatagal na nananatili ang fluency, kaya madaling hindi mapansin ang pinsala: nakapagsusulat pa rin ng malilinis na pangungusap ang isang model na hindi maayos ang quantization. Precision ang unang naaapektuhan. Kasama rito ang eksaktong pag-alala sa version number, API signature, o petsa. Naaapektuhan din ang mahahabang chain of reasoning, kung saan ang maliit na error sa step two ay nagiging maling sagot sa step eight. Problema rin ang mahigpit na output format, kung saan sapat ang isang maling bracket para mag-fail ang tool call.

Ang huli ang praktikal na test. Kapag kailangang magbalik ng JSON ang model na bina-parse ng code mo, lumalabas ang quantization damage bilang parse error sa halip na bahagyang mas mahinang prose. Kaya makikita mo ito sa parehong araw.

Kapag mas mababa sa four bits, mabilis lumalaki ang loss. Ang q3 at two-bit types ay para sa mga nagtatangkang magpatakbo ng malaking model sa maliit na hardware. Praktikal ang mga ito kapag ang alternatibo ay hindi patakbuhin ang model. Ngunit hindi magandang default ang mga ito. Maliit lang ang agwat ng q4_K_M at q8_0, at hindi ito malulutas ng published perplexity table para sa workload mo. Kaya huwag mong subukang magpasya gamit lamang iyon. Patakbuhin ang dalawang variant gamit ang thirty sarili mong prompt, saka suriin ang output.

Kung kailan sulit ang q8_0 o fp16 sa RAM

Gamitin ang q8_0 kapag talagang may ekstrang memory at mabigat ang epekto ng maliliit na error sa task: structured extraction, tool calling, at code na kailangang mag-compile. Insurance ang binibili mo rito, hindi model na kapansin-pansing mas matalino.

Dalawang dahilan lamang ang sapat para gamitin ang fp16. Una, kung ikaw mismo ang nag-quantize ng model at kailangan mo ang source file. Ikalawa, kung sumusukat ka ng baseline para malaman kung gaano kalaki ang isinakripisyo ng iyong four-bit build. Ang pag-serve gamit ang fp16 ay kumokonsumo ng tatlong beses na memory kumpara sa q4_K_M, para sa pagkakaibang hindi matukoy ng karamihan nang walang paghahambing. 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 na nasa q4_K_M kaysa sa mas maliit na model na nasa q8_0. Ang 9.3 GB na weights ng 14B kumpara sa 8.9 GB na weights ng 8B ay halos magkapareho ang RAM (random access memory), pero mas marami ang alam ng mas malaking model. Subukan ito gamit ang sarili mong prompts sa halip na basta paniwalaan.

Limitado ang CPU-only inference ng memory bandwidth

Karamihan sa VPS plan ay walang GPU, kaya tumatakbo ang model sa system memory gamit ang host CPU. Dahil dito, nakadepende ang generation sa memory bandwidth, hindi sa arithmetic. Kailangan kasing basahin nang isang beses ang bawat weight para makagawa ng isang token. Nagtatakda ito ng limitasyon na walang kinalaman sa dami ng core 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

Humigit-kumulang 50 GB/s ang theoretical figure para sa dual-channel DDR4-3200 host. Mas maliit ang bahagi mo dahil pinaghahatian ng VPS ang bus na iyon ng lahat ng tenant sa machine. Kaya ituring ang mga numerong iyon bilang ceiling na walang nakaaabot. Ang mahalagang pattern ay ito: sa CPU, ang paghahati sa bits per weight nang kalahati ay karaniwang nagdodoble sa token rate. Ang quantization ang pinakamalaking speed lever sa machine na walang GPU.

Iba ang prompt processing. Compute-bound ito sa halip na bandwidth-bound kapag nagbabasa ng mahabang prompt. Kaya nakatutulong doon ang dagdag na core, pero halos walang epekto sa generation speed. Normal ang pag-uugali ng machine na mabilis mag-ingest ng 4k prompt at mabagal pagkatapos sa generation.

Huwag basta tanggapin ang anumang arithmetic nang hindi sinusuri. Sukatin ang tokens per second sa sarili mong machine gamit ang parehong prompt sa bawat quantization, at hayaan mong manaig ang sarili mong mga numero sa mga ito.

Pag-quantize ng model nang sarili mo

Maaaring bumuo ang Ollama ng quantized model mula sa fp16 o fp32 source. Mahalaga ito kapag nag-fine-tune ka ng model at walang available na library tag. Ituro ang isang Modelfile sa unquantized weights:

FROM /path/to/my/model/f16

Pagkatapos, buuin 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 q6_K o q5_K_M na option dito. Para sa mga iyon, gamitin ang sariling tool ng llama.cpp para mag-quantize, pagkatapos ay i-import ang natapos na GGUF file. Ang linyang quantization mula sa ollama show ang ginagamit upang i-verify kung naisagawa ng build ang itinakda mo.

Mga makikita kapag nagkaproblema

Sa CPU tumatakbo ang 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 ang weights at KV cache (video RAM, ang memory ng graphics card), kaya inilagay sa system memory ang bahagi ng model. Bumabagal ang takbo at lumalapit sa CPU-only rate dahil naghihintay ang bawat token sa 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 naglalaman ng Out of memory: Killed process ay nangangahulugang lumampas sa memory ng machine ang pinagsamang laki ng weights, KV cache, at buffers. Sa VPS na walang naka-configure na swap, maaaring tumigil o bumagal nang husto ang buong machine nang ilang segundo bago lumitaw ang linyang iyon.

Lumala ang mga sagot kahit wala kang binago. Maaaring magkatabi ang dalawang build ng parehong model sa ollama ls gamit ang magkakaibang tags, at susundan ng script na kumukuha sa unsuffixed name ang kasalukuyang itinuturo rito ng library. Patakbuhin ang ollama show gamit ang eksaktong tag na hinihingi ng client mo 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 inilalabas ng Ollama library para sa karamihan ng mga model, kaya ollama pull qwen3:8b at ollama pull qwen3:8b-q4_K_M ang kumukuha sa parehong file. Lumipat lamang sa q8_0 kapag may ekstrang memory at sensitibo ang task sa 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 pairing na ito bago maglaan ng mas maraming RAM para sa precision.

Ang ibig bang sabihin talaga ng q4_K_M ay apat na bits bawat weight?

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 tinaasan ang type ng mga tensor na pinakasensitibo. Ang Q8_0 ay sumusukat ng 8.5 bits sa halip na walong bits sa parehong dahilan. Gamitin ang measured figure sa pag-estimate: parameter count na minultiply sa bits bawat weight, saka hinati sa walo, ang nagbibigay ng file size sa bytes.

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

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

Bakit 100% CPU ang gamit ng model ko kahit may GPU ang machine?

Patakbuhin ang ollama ps at basahin ang PROCESSOR column. Ang 100% CPU, o split gaya ng 48%/52% CPU/GPU, ay nangangahulugang hindi nagkasya sa VRAM ang weights at KV cache, kaya inilagay ng Ollama ang bahagi o buong model sa system memory. Karaniwang sanhi nito ang context window na mas malaki kaysa sa kayang i-hold ng card, 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 upang hatiin sa dalawa ang cache, o mag-pull ng mas maliit na quantization.