Ollama quantization: Q4 vs Q8 vs fp16

Ano ang binabago ng Ollama quantization

Sa Ollama quantization, iniimbak ang bawat weight sa 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 weights sa isang mas magaspang na grid; hindi sila basta inaalis. Sa apat na bits, kadalasang halos katulad pa rin ng full precision ang mga sagot ng karamihan sa mga model.

Iyan ang buong trade-off: mas maliit na memory footprint at mas maraming token bawat segundo, kapalit ng maliit na pagbaba sa accuracy. Ipinapaliwanag ng mga sumusunod kung paano mahuhulaan ang dalawang resultang 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 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 inilalabas bilang GGUF file, ang format na ginagamit ng llama.cpp para mag-store 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. Ibig sabihin ng q4, karamihan sa weight tensor ay naka-pack sa tig-apat na bit. Ibig sabihin ng q8, walo. Hindi naka-quantize ang fp16: ang model ito sa sixteen-bit floating point, ang precision na ginagamit sa pag-publish ng karamihan ng mga model.

Ang K ang nagmamarka ng K-quant. Pinapangkat ang mga weight sa maliliit na block, at nag-iimbak ang bawat block ng sarili nitong scale sa tabi ng naka-pack na values. Ang block na ang lahat ng weight ay malapit sa 0.01 ay gumagamit ng mas pinong scale. Ang block na may isang malaking outlier ay gumagamit ng mas magaspang na scale. Ang mga per-block scale na ito ang nagpapanatiling usable sa four-bit file. 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 naaapektuhan kapag ni-round off ay sine-store sa mas malawak na format, habang nananatili sa four bits ang karamihan. Kaya mas magandang output ang ginagawa ng q4_K_M kaysa sa mas lumang q4_0, kahit halos magkapareho ang file size.

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 ground truth para sa model na na-pull mo ilang buwan na ang nakalipas at hindi mo na maalala kung alin ang pinili mo.

Dito nagmumula ang laki ng file: bits per weight

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

[
  {
    "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 nakakagulat sa talahanayang iyon ay ang ikalawang column. Ang Q4_K_M ay hindi apat na bits bawat weight. Sinusukat nito ang 4.89 bits, dahil kumokonsumo rin ng aktuwal na espasyo ang block scales at promoted tensors. Ang Q8_0 ay sumusukat ng 8.5 bits sa halip na walo, sa parehong dahilan. Gamitin ang nasukat na numero, at lalapat ang kalkulasyon sa loob ng ilang porsiyento 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. Malapit na rin itong tumugma sa memory na ginagamit ng weights kapag na-load na. Walang ina-unpack ang Ollama kapag naglo-load: nananatili sa memory ang quantized weights sa parehong packed form, at kino-convert ang bawat block kapag ginagamit ito.

Ano talaga ang inilalabas ng Ollama para sa bawat laki ng modelo

Naglalathala ang library ng mga tag na q4_K_M, q8_0, at fp16 para sa karamihan ng mga family. May ilang bagong family na hindi sumusunod sa pattern na ito. Lumalabas ang mga ito sa library bilang mga cloud-only tag na walang mada-download sa anumang width. Ito ang problemang mararanasan mo kapag sinubukan mong patakbuhin ang GLM 5.2 sa isang VPS. Ito ang mga size ng Qwen3 noong August 2026, batay sa listahan ng tag sa model page. Ang bawat figure sa ibaba ay tumutukoy sa laki sa disk bago ito mapunta sa RAM. Kapag pinagsama ang dalawa o tatlo sa mga ito, mapupuno ang maliit na root volume ng VPS. Kaya mahalagang malaman muna kung saan ini-store ng Ollama ang mga model na dina-download nito bago ka magsimulang mag-ipon 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 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 kompromisong iniaalok lang ng library ang Q4_K_M. Ito ang default na pinili ng upstream. Kaya makatuwirang ito ang unang gamitin para sa anumang model na hindi mo pa personal na nasusubukan. Ito rin ang batayan ng pagpili ng 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 dagdag sa laki sa halip na eksaktong dumoble. Ito ay dahil hindi pareho ang scaling ng embedding at output tensors sa iba pang 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. Lampas na ito sa kayang i-hold ng 16 GB na machine kapag may kahit anong context window. Para sa mas malawak na gabay kung aling model ang kasya sa bawat machine, tingnan ang mga model na maaari mong i-self-host.

Bakit pangalawang gastos ang KV cache 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 key at value vector nito para sa bawat layer, kaya tuloy-tuloy na lumalaki ang cache batay sa laki ng window na pinapayagan mo. Inilalaan ito para sa buong window kapag nilo-load ang model, hindi habang napupuno ang conversation. Kaya kumokonsumo ng memory ang mahabang window kahit isang salita lang 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

Ang mga numerong iyon para sa model ay galing sa sarili nitong configuration: 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 kailangan. 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. Itaas ang window sa 32k at aabot sa 4.83 GB ang cache lamang. Halos kapantay na ito ng memory na ginagamit ng quantized weights, kaya magiging 10 GB ang minimum para sa buong model. Tinatawag itong minimum dahil ginagamit din ang natitirang memory ng compute buffers at operating system. Kunin ang aktuwal na value sa column na SIZE ng ollama ps matapos ma-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 kung anong window ang aktuwal na ginamit sa pag-load ng tumatakbong model. Kina-quantize rin ng OLLAMA_KV_CACHE_TYPE ang cache mismo: default ang f16, gumagamit ang q8_0 ng humigit-kumulang kalahati ng memory na ginagamit ng f16, at gumagamit ang q4_0 ng humigit-kumulang isang-kapat nito. Global option ito, kaya pareho ang treatment sa bawat model sa server na iyon. Magkakabisa lamang ang cache quantization kapag naka-enable ang Flash Attention. Awtomatikong ginagawa ito ng Ollama kapag sinusuportahan ng backend, at pinipilit itong i-enable ng OLLAMA_FLASH_ATTENTION=1. Sa maliit na server na may mahabang window, mas maraming memory ang mapapalaya sa paghahati sa kalahati ng cache kaysa sa anumang ibang iisang pagbabago. Detalyadong ipinapaliwanag sa Pagtatakda ng num_ctx at halaga nito ang window mismo. Itinatakda rin ang laki ng cache nang isang beses para sa bawat concurrent request slot, hindi isang beses para sa server. Kaya kung hahayaan mong sabay na sagutin ng Ollama ang dalawang prompt, dodoble ang naunang na-budget na value. Ito ang batayan ng kalkulasyon sa Pagpili ng bilang ng parallel slot at limitasyon ng queue.

Mga kasya sa isang 8, 16, o 32 GB VPS

Isama sa pagtantya ang budget weights, KV cache, headroom para sa operating system, at anumang iba pang tumatakbo. Kumportable ang 2 GB na headroom sa isang maliit na VPS.

8 GB. Ang 4B model sa q4_K_M ay 2.6 GB at may natitirang espasyo para sa mahabang context window. Kasya ang 8B model sa q4_K_M gamit ang default na 4k window, pero napakaliit ng natitirang headroom. Huwag planuhing gumamit ng 8B na may 32k window dito, dahil lampas na sa kapasidad ng server ang minimum 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 na may 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 maaari mong ilaan 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, maaabot nito ang memory ceiling. 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 kakayahan ng isang model. Pinakamatagal na nananatili ang fluency, kaya madaling hindi mapansin ang pinsala: nakagagawa pa rin ng malilinis na pangungusap ang model na hindi maayos ang quantization. Precision ang unang naaapektuhan. Kabilang dito 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. Kasama rin ang mahigpit na output format, kung saan sapat na ang isang maling bracket para mabigo ang tool call.

Ang huli ang praktikal na test. Kapag kailangang magbalik ng JSON ang model na bina-parse ng code mo, lumilitaw ang pinsala ng quantization bilang parse error sa halip na bahagyang mas mahinang prose. Dahil dito, makikita mo agad ang problema. Pinakamahigpit na bersyon ng test na ito ang coding agent, dahil sunod-sunod itong nagsasagawa ng tool call sa pamamagitan ng model. Kaya ang pagtutok ng agent sa iyong Ollama server ay makapaglalantad ng sobrang agresibong quantization sa loob ng isang hapon.

Mabilis lumalaki ang loss kapag mas mababa sa four bits. Ang q3 at two-bit types ay para sa mga kailangang magkasya ang malaking model sa maliit na hardware. Praktikal ang mga ito kapag ang alternatibo ay hindi paganahin ang model. Ngunit hindi magandang default ang mga ito. Maliit lang ang agwat ng q4_K_M at q8_0, kaya hindi ito malulutas ng published perplexity table para sa workload mo. Huwag itong subukang lutasin sa ganoong paraan. Patakbuhin ang dalawang variant gamit ang thirty sa sarili mong prompts at basahin ang output.

Kung kailan sulit ang q8_0 o fp16 sa RAM

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

Gamitin lang ang fp16 sa dalawang dahilan. Una, ikaw mismo ang nag-quantize ng model at kailangan mo ang source file. Ikalawa, sumusukat ka ng baseline para malaman kung gaano kalaki 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 pagkakaibang hindi matukoy ng karamihan nang walang paghahambing. Sa CPU-only na machine, binabawasan din 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 pareho ang RAM (random access memory), pero mas marami ang nalalaman ng mas malaking model. Subukan ito sa sarili mong prompts sa halip na basta paniwalaan.

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. Ang generation ay nakadepende sa memory bandwidth, hindi sa arithmetic, dahil kailangang basahin nang isang beses ang bawat weight para makagawa ng isang token. Nagtatakda ito ng ceiling 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 tinatayang 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 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 kalahati ng bits bawat weight ay humigit-kumulang nagdodoble sa token rate. Ang quantization ang pinakamalaking speed lever na available sa isang box na walang GPU. Kung tolerable 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, tag, at RAM figure. Ang isa pang bahagi ng paghihintay ay kung gaano karaming text ang napagpapasyahang isulat ng model. Sa rate na 10 tokens bawat segundo, ang 600-token na sagot ay umaabot ng buong minuto. Kaya ang pag-limit sa reply gamit ang num_predict ay kadalasang nakababawas ng waiting time nang higit kaysa sa isa pang pagbaba sa precision.

Iba ang pagproseso ng prompt. Compute-bound ito sa halip na bandwidth-bound, kaya nakatutulong ang dagdag na cores habang halos walang epekto sa generation speed. Normal ang isang box na mabilis mag-ingest ng 4k prompt ngunit mabagal mag-generate pagkatapos.

Huwag basta tanggapin ang alinman sa arithmetic nang walang pagsubok. Sukatin ang tokens bawat segundo sa sarili mong box gamit ang parehong prompt sa bawat quantization, at hayaang manaig ang sarili mong mga resulta.

Pag-quantize ng model nang ikaw mismo ang gumawa

Mahalaga ito kapag nag-fine-tune ka ng isang model at walang library tag para rito. Nakadepende ang proseso sa format na gusto mong maging resulta, dahil hindi na gumagawa ang Ollama ng GGUF K-quants na sinusukat sa page na ito.

Para sa K-quant gaya ng q4_K_M, i-quantize ito bago makita ng Ollama ang file. Hindi nag-quantize ang Ollama ng mga GGUF model habang ini-import ang mga ito, at tinatanggihan nito ang --quantize sa isang GGUF source. I-quantize ang unquantized GGUF gamit ang llama-quantize ng llama.cpp, saka i-import ang natapos na file. May sarili ring pitfall ang import route na ito: hindi tugmang chat template na nagiging sanhi ng pag-reply ng model ng garbage. Ipinapaliwanag ito ng pag-import ng GGUF file sa Ollama. Ang quantization line mula sa ollama show ang ginagamit upang tiyaking ang imported file ay ang build na nilayon mo.

Gumagana lamang ang sariling --quantize ng Ollama sa mga safetensors import. Ituro ang Modelfile sa directory na naglalaman ng unquantized safetensors weights:

FROM /path/to/safetensors/directory

Pagkatapos, mag-build:

ollama create --quantize int4 mymodel

Sa Ollama v0.40.0 (sinuri noong 2026-10-09), tinatanggap ng --quantize ang int4, int8, nvfp4, mxfp4 at mxfp8, at ginagamit ang q4 at q8 bilang mga alias para sa int4 at int8. Tinatanggihan ang mga GGUF name gaya ng q4_K_M, q4_K_S, q8_0, q6_K at q5_K_M na may unsupported quantize type error. Hindi ang mga ito ang GGUF K-quants sa mga talahanayan sa itaas, kaya huwag gamitin ang bits per weight at file size figures sa page na ito bilang mga prediction para sa mga ito.

Mga makikita kapag nagkaproblema

Lahat ay tumatakbo sa CPU kahit GPU ang inaasahan mo. Basahin ang column na PROCESSOR:

ollama ps

Ipinapakita nito ang 100% GPU, 100% CPU, o split gaya ng 48%/52% CPU/GPU. Ibig sabihin ng split, hindi kasya sa VRAM (video RAM, ang memory ng graphics card) ang weights kasama ang KV cache, kaya nailagay ang bahagi ng model sa system memory. Bumabagal ang processing 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 makatutulong ang pagdagdag ng cores.

Napuputol ang model habang nilo-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 2 build ng parehong model sa ollama ls gamit ang magkaibang tag, at susundan ng script na kumukuha sa unsuffixed name kung saan ito kasalukuyang itinuturo 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 ginagamit ng Ollama library para sa karamihan ng mga model, kaya parehong file ang hina-handle ng ollama pull qwen3:8b at ollama pull qwen3:8b-q4_K_M. Lumipat sa q8_0 kapag may ekstrang memory at mabigat ang epekto ng maliliit na error sa task, 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 iyon bago maglaan ng RAM para sa mas mataas na precision.

Ang q4_K_M ba ay talagang nangangahulugang 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 itinatakda sa mas malawak na type ang mga tensor na pinakasensitibo. Ang sukat ng Q8_0 ay 8.5 bits sa halip na walo sa parehong dahilan. Gamitin ang aktuwal na sinusukat na value sa pagtatantiya: ang parameter count na minultiply sa bits per 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 may 5.2 GB na weights. Sa default na 4096-token window, nagdadagdag ang cache ng 0.6 GB, kaya nasa humigit-kumulang 5.8 GB ang minimum bago isama ang compute buffers at operating system. Sa 32k window, ang cache lang ay 4.83 GB na. 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 column na PROCESSOR. Ang 100% CPU, o split gaya ng 48%/52% CPU/GPU, ay nangangahulugang hindi kasya sa VRAM ang weights kasama ang KV cache, kaya inilagay ni Ollama ang bahagi o lahat ng model sa system memory. Karaniwang sanhi nito ang context window na mas malaki kaysa sa kayang hawakan ng card, dahil inilalaan ang cache para sa buong window kapag nilo-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.