Ollama quantization: Q4, Q8 की fp16?

Ollama quantization मध्ये काय बदलते

Ollama quantization मुळे model मधील प्रत्येक weight हा तो ज्या file मध्ये प्रशिक्षित झाला त्यापेक्षा कमी bits मध्ये साठवला जातो. q4_K_M ने संपणारा tag प्रत्येक weight साठी सुमारे चार bits ठेवतो, तर fp16 सोळा bits ठेवतो. त्यामुळे download साधारणपणे एक-चतुर्थांश आकाराचा होतो आणि प्रत्येक token तयार करण्यासाठी machine ला साधारणपणे एक-चतुर्थांश bytes वाचावे लागतात. Weights फेकून दिले जात नाहीत; त्यांना coarse grid वर round केले जाते. चार bits वापरल्यास बहुतेक models full precision प्रमाणेच जवळपास उत्तर देतात.

हा संपूर्ण तडजोडीचा मुद्दा आहे: memory footprint खूप कमी होतो आणि प्रति सेकंद अधिक tokens तयार होतात, पण accuracy मध्ये थोडी घट होते. एखाद्या विशिष्ट model साठी आणि विशिष्ट box वर या दोन्ही परिणामांचा अंदाज कसा घ्यायचा, हे पुढे सांगितले आहे. न बसणारी file download करण्यासाठी वीस मिनिटे खर्च करण्यापूर्वी हे तपासा.

Ollama अद्याप चालू नसेल, तर VPS वर Ollama install करणे येथून सुरुवात करा. या पानावर ollama ls आधीपासून कार्यरत आहे असे गृहीत धरले आहे.

q4_K_M सारखा Ollama quantization tag कसा वाचावा

Local models हे GGUF files म्हणून release केले जातात. llama.cpp डिस्कवर weights साठवण्यासाठी हाच format वापरते. Ollama हे llama.cpp वर आधारित असल्यामुळे Ollama tags मध्ये llama.cpp ची quantization names कोणताही बदल न करता वापरली जातात.

संख्या target width दर्शवते. q4 म्हणजे बहुतेक weight tensors प्रत्येकी four bits मध्ये packed केलेले असतात. q8 म्हणजे eight bits. fp16 quantized नसते: ते model sixteen bit floating point मध्ये असते. बहुतेक models ज्या precision मध्ये published केले जातात, तीच ही precision आहे.

K K-quant दर्शवते. Weights लहान blocks मध्ये गटबद्ध केले जातात. प्रत्येक block मध्ये packed values च्या शेजारी त्याचा स्वतःचा scale साठवला जातो. ज्या block मधील सर्व weights 0.01 च्या आसपास असतात, त्याला fine scale मिळतो. एखाद्या block मध्ये एक मोठा outlier असल्यास त्याला coarse scale मिळतो. हे per-block scales four-bit file वापरण्यायोग्य ठेवतात. त्यामुळेच four-bit file मध्ये प्रत्येक weight नेमका four bitsचा नसतो.

शेवटचे अक्षर mixture दर्शवते. S, M आणि L target width पेक्षा जास्त width मध्ये किती tensors ठेवायचे ते ठरवतात. q4_K_M मध्ये rounding केल्यावर सर्वाधिक परिणाम होणारे tensors जास्त width मध्ये साठवले जातात. उर्वरित बहुतेक tensors four bitsमध्ये राहतात. त्यामुळे जवळपास समान file size असूनही q4_K_M जुन्या q4_0 पेक्षा चांगले output देते.

तुम्ही टाइप केलेल्या नावावरून अंदाज लावण्याऐवजी डिस्कवर काय साठवले आहे ते Ollama कडून विचारा:

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

ollama show मध्ये architecture, parameters, quantization, context length आणि embedding length दाखवले जाते. काही महिन्यांपूर्वी pull केलेल्या आणि कोणते model निवडले होते हे आता आठवत नसलेल्या model साठी quantization line ही अंतिम प्रमाण मानावी.

Bits per weight मुळे फाइलचा आकार ठरतो

प्रत्येक आकाराचा अंदाज एका संख्येपासून सुरू होतो: संपूर्ण फाइलमध्ये सरासरीने प्रत्येक weight साठी format किती bits वापरतो. llama.cpp त्याच्या quantize documentation मध्ये Llama 3.1 8B साठी मोजलेली आकडेवारी प्रकाशित करते. समान रचनेच्या कोणत्याही dense model साठी ही आकडेवारी योग्य ठरते.

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

त्या तक्त्यातील दुसरा column आश्चर्यकारक आहे. Q4_K_M म्हणजे प्रत्येक weight साठी चार bits नाहीत. त्याचे मोजमाप 4.89 bits असे आहे, कारण block scales आणि promoted tensors यांनाही प्रत्यक्ष storage लागते. त्याच कारणामुळे Q8_0 चे मोजमाप आठऐवजी 8.5 bits असे आहे. मोजलेली संख्या वापरल्यास, ही गणना प्रत्यक्ष फाइलच्या आकारापासून काही टक्क्यांच्या मर्यादेत राहते:

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

ही 4.58 GiB ची Q4_K_M फाइल आहे. ती दोन संख्यांमधून पुन्हा मिळवली आहे. Load केल्यानंतर weights व्यापतात ते memory प्रमाणही जवळपास इतकेच असते. Ollama load करताना काहीही unpack करत नाही. Quantized weights memory मध्ये त्याच packed स्वरूपात राहतात आणि प्रत्येक block वापरताना convert केला जातो.

प्रत्येक model size साठी Ollama प्रत्यक्षात काय release करते

बहुतेक model families साठी library एक q4_K_M, एक q8_0 आणि एक fp16 tag प्रकाशित करते. हे ऑगस्ट 2026 मधील Qwen3 sizes आहेत. ही माहिती model page वरील tag list मधून घेतली आहे.

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

इथे default tag महत्त्वाचा आहे. ollama pull qwen3:8b मधून 5.2 GB इतकाच download होतो, जितका ollama pull qwen3:8b-q4_K_M मधून होतो, कारण suffix नसलेला tag म्हणजेच q4_K_M build आहे. Q4_K_M हा library अनिच्छेने देत असलेला तडजोडीचा पर्याय नाही. upstream ने तो default म्हणून निवडला आहे. त्यामुळे स्वतः तपासलेले नसलेल्या कोणत्याही model साठी त्याच्याशी जुळणे हा योग्य पहिला पर्याय आहे. VPS वर Qwen 3 चालवणे यासाठीही हाच विचार tag निवडताना लागू होतो.

हे ratios प्रत्येक row मध्ये लागू राहतात. q4_K_M वरून q8_0 कडे गेल्यास किंमत अचूक दुप्पट होत नाही; ती सुमारे सत्तर टक्क्यांनी वाढते. याचे कारण embedding आणि output tensors इतर tensors प्रमाणे scale होत नाहीत. fp16 हा q4_K_M पेक्षा साधारण तीनपट मोठा असतो. q4_K_M मधील 32B model चे weights 20 GB असतात. त्यामुळे कोणतीही context window ठेवली तरी तो 16 GB machine च्या क्षमतेपलीकडे जातो. कोणत्या machine वर कोणते model बसते याचा व्यापक आढावा घेण्यासाठी तुम्ही कोणते models self-host करू शकता हे पहा.

KV cache हा दुसरा, context वर अवलंबून असलेला खर्च का आहे

Weights हा स्थिर खर्च आहे. KV cache (key आणि value cache) हा बदलणारा खर्च आहे. Context window मधील प्रत्येक token साठी प्रत्येक layer चे key आणि value vectors cache मध्ये ठेवले जातात. त्यामुळे तुम्ही परवानगी दिलेल्या window प्रमाणे cache सरळ प्रमाणात वाढतो. Model load होताना संपूर्ण window साठी cache allocate केला जातो; conversation वाढत जाते तसे तो हळूहळू allocate केला जात नाही. म्हणून one word prompt असतानाही मोठ्या window साठी memory लागते.

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

ही model numbers model च्या स्वतःच्या configuration मधून येतात: 36 layers, 8 key/value heads आणि head dimension 128. ollama show मधून architecture आणि parameter count मिळतो. उर्वरित माहिती Hugging Face वरील model च्या config.json मधून मिळते. प्रत्येक token चा खर्च window size ने गुणल्यावर 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
  }
]

Ollama च्या default 4096 tokens window वर cache मुळे weights व्यतिरिक्त 0.6 GB memory लागते. Window 32k पर्यंत वाढवल्यास केवळ cache साठी 4.83 GB लागतात. हे quantized weights साठी लागणाऱ्या memory इतकेच जवळपास आहे. त्यामुळे संपूर्ण model साठी किमान memory 10 GB होते. याला किमान मर्यादा म्हणण्याचे कारण म्हणजे compute buffers आणि operating system यासाठी अतिरिक्त memory लागते. Model load झाल्यानंतर प्रत्यक्ष आकडा ollama ps मधील SIZE column मधून पाहा.

Ollama सेवा म्हणून चालवताना window server वर सेट केली जाते; प्रत्येक request साठी स्वतंत्रपणे नाही:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd install साठी त्याऐवजी drop-in मध्ये ती सेट करा:

sudo systemctl edit ollama

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

sudo systemctl restart ollama ने restart करा. त्यानंतर चालू model कोणत्या window सह प्रत्यक्ष load झाले आहे हे तपासण्यासाठी ollama ps मधील CONTEXT column पाहा. OLLAMA_KV_CACHE_TYPE cache स्वतः quantize करते: f16 हा default आहे, q8_0 मुळे f16 च्या तुलनेत सुमारे निम्मी memory लागते आणि q4_0 मुळे सुमारे एक चतुर्थांश memory लागते. हा global option आहे. त्यामुळे त्या server वरील प्रत्येक model वर तोच परिणाम होतो. मोठ्या window असलेल्या लहान system मध्ये cache अर्धा केल्यास इतर कोणत्याही एका बदलापेक्षा जास्त memory मोकळी होते. num_ctx सेट करणे आणि त्याचा खर्च या लेखात window चा सविस्तर आढावा दिला आहे.

8, 16 किंवा 32 GB VPS वर काय बसते

Budget weights, तसेच KV cache, operating system आणि चालू असलेल्या इतर सर्व गोष्टींसाठी headroom. छोट्या VPS साठी दोन GB headroom पुरेसा आरामदायक असतो.

8 GB. q4_K_M मधील 4B model 2.6 GB आहे आणि long window साठी जागा उरते. q4_K_M मधील 8B model default 4k window सह बसतो; मात्र slack फारच कमी उरतो. येथे 32k window सह 8B वापरण्याचे नियोजन करू नका, कारण 10 GB ची किमान आवश्यकता आधीच या VPS च्या क्षमतेपेक्षा जास्त आहे.

16 GB. q4_K_M मधील 8B model 16k किंवा 32k window सह आरामात बसतो. q4_K_M मधील 14B model चे weights 9.3 GB आहेत आणि modest window सह बसतो. q8_0 मधील 8B model 8.9 GB आहे, त्यामुळे तोदेखील बसतो. या विषयावर तुम्ही खर्च करू शकणारा सर्वात उपयुक्त एक तास म्हणजे या दोन्हींची तुमच्या स्वतःच्या prompts वर तुलना करणे.

32 GB. q8_0 मधील 14B (16 GB) आणि q4_K_M मधील 32B (20 GB) हे दोन्ही load होतात. मोठ्या window सह 32B build क्षमतेच्या मर्यादेपर्यंत पोहोचेल. त्यामुळे गृहीत धरण्याऐवजी ollama ps monitor करा.

क्वांटायझेशनमुळे प्रथम काय खराब होते

क्वांटायझेशन त्रुटी मॉडेलच्या सर्व क्षमतांवर समान परिणाम करत नाही. प्रवाहीपणा सर्वांत जास्त काळ टिकतो. त्यामुळे नुकसान लक्षात घेणे कठीण होते: अत्यंत खराब पद्धतीने quantize केलेले मॉडेलसुद्धा स्वच्छ वाक्ये लिहिते. अचूकता प्रथम कमी होते. आवृत्ती क्रमांक, API signature किंवा तारीख अचूकपणे आठवणे बिघडते. दीर्घ reasoning chain मध्ये दुसऱ्या टप्प्यातील लहान त्रुटी आठव्या टप्प्यात चुकीचे उत्तर निर्माण करू शकते. Strict output format मध्ये एक चुकीचा bracket देखील tool call अयशस्वी करू शकतो.

शेवटची बाब ही व्यावहारिक चाचणी आहे. मॉडेलने तुमचा code parse करणार असलेला JSON परत करायचा असल्यास, क्वांटायझेशनचे नुकसान अस्पष्टपणे खराब prose म्हणून नव्हे, तर parse error म्हणून दिसते. त्यामुळे ते त्याच दिवशी लक्षात येते. Coding agent ही या चाचणीची सर्वांत कठोर आवृत्ती आहे. तो मॉडेलला सलग tool call मधून चालवतो. त्यामुळे तुमच्या Ollama server कडे agent निर्देशित केल्यास अतिशय आक्रमक quantization एका दुपारमध्ये उघड होईल.

चार bits पेक्षा कमी झाल्यावर गुणवत्ता वेगाने कमी होते. q3 आणि two-bit प्रकार मोठे मॉडेल लहान hardware वर बसवू इच्छिणाऱ्या वापरकर्त्यांसाठी आहेत. मॉडेल चालवणे हाच पर्याय नसल्यास ते प्रत्यक्ष उपयोगी ठरतात. मात्र ते चांगले default नाहीत. q4_K_M आणि q8_0 यांच्यातील फरक इतका लहान आहे की प्रकाशित perplexity table तुमच्या workload साठी निर्णय देऊ शकणार नाही. त्यामुळे तो निर्णय त्या पद्धतीने घेऊ नका. तुमच्या स्वतःच्या तीस prompts वर दोन्ही प्रकार चालवा आणि output वाचा.

q8_0 किंवा fp16 साठी RAM खर्च करणे कधी योग्य ठरते

मेमरी खरोखरच अतिरिक्त उपलब्ध असेल आणि लहान चुका महत्त्वपूर्ण ठरत असतील, तेव्हा q8_0 वापरा: structured extraction, tool calling आणि compile होणे आवश्यक असलेला code. येथे तुम्ही अधिक बुद्धिमान model विकत घेत नाही; तुम्ही जोखीम कमी करण्यासाठी राखीव क्षमता वापरत आहात.

fp16 फक्त दोन कारणांसाठी वापरा. तुम्ही model स्वतः quantize करत असाल आणि source file आवश्यक असेल, किंवा baseline मोजत असाल, जेणेकरून तुमच्या four bit build ने किती गुणवत्ता गमावली हे समजू शकेल. fp16 मधून serving केल्यास q4_K_M च्या तुलनेत तीन पट मेमरी लागते, पण बहुतेक लोकांना हा फरक blind test मध्ये ओळखता येत नाही. तसेच, केवळ CPU असलेल्या मशीनवर token rate एक-तृतीयांशपर्यंत कमी होतो.

ठरावीक memory budget मध्ये अधिक उपयुक्त नियम असा आहे: q4_K_M वरील मोठे model साधारणपणे q8_0 वरील लहान model पेक्षा चांगले काम करते. 14B weights साठी 9.3 GB आणि 8B weights साठी 8.9 GB वापरले जातात. RAM (random access memory) जवळजवळ सारखीच राहते आणि मोठ्या model कडे अधिक ज्ञान असते. हे गृहीत धरू नका; स्वतःच्या prompts वर याची चाचणी घ्या.

CPU-only inference मेमरी बँडविड्थमुळे मर्यादित असते

बहुतेक VPS प्लॅनमध्ये GPU नसतो. त्यामुळे मॉडेल host CPU वरील system memory मध्ये चालते. अशा वेळी generation ही arithmetic मुळे नव्हे, तर memory bandwidth मुळे मर्यादित होते. कारण प्रत्येक token तयार करण्यासाठी प्रत्येक weight एकदा वाचावा लागतो. त्यामुळे तुम्ही किती cores घेतले आहेत याच्याशी संबंध नसलेली एक कमाल मर्यादा तयार होते.

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

Dual-channel DDR4-3200 host साठी 50 GB/s हा साधारण सैद्धांतिक आकडा आहे. तुमचा प्रत्यक्ष वाटा यापेक्षा कमी असतो. VPS मध्ये तो bus त्या मशीनवरील इतर सर्व tenants सोबत सामायिक केला जातो. त्यामुळे हे आकडे प्रत्यक्षात कोणीही गाठत नाही अशी कमाल मर्यादा म्हणून पहा. महत्त्वाचा भाग म्हणजे हा कल: CPU वर प्रत्येक weight साठी लागणारे bits अर्धे केल्यास token rate साधारणपणे दुप्पट होतो. GPU नसलेल्या मशीनवर उपलब्ध असलेला quantization हा सर्वात मोठा speed lever आहे.

Prompt processing वेगळ्या पद्धतीने कार्य करते. लांब prompt वाचणे हे bandwidth-bound नसून compute-bound असते. त्यामुळे तेथे अतिरिक्त cores मदत करतात, पण generation speed मध्ये जवळजवळ कोणतीही वाढ होत नाही. 4k prompt जलदपणे स्वीकारणारी आणि त्यानंतर हळू generation करणारी मशीन सामान्यपणेच कार्य करत असते.

कोणताही arithmetic आकडा तपासल्याशिवाय स्वीकारू नका. प्रत्येक quantization साठी समान prompt वापरून तुमच्या स्वतःच्या मशीनवर प्रति सेकंद tokens मोजा आणि या आकड्यांपेक्षा तुमच्या मोजमापांनाच प्राधान्य द्या.

स्वतः model quantize करणे

Ollama fp16 किंवा fp32 source पासून quantized model तयार करू शकते. तुम्ही एखाद्या model ला fine-tune केले असेल आणि त्यासाठी library tag उपलब्ध नसेल, तेव्हा हे उपयुक्त ठरते. Unquantized weights कडे Modelfile निर्देशित करा:

FROM /path/to/my/model/f16

त्यानंतर build करून पडताळणी करा:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize मध्ये q8_0, q4_K_S आणि q4_K_M स्वीकारले जातात. येथे q6_K किंवा q5_K_M पर्याय नाही. त्यामुळे या पर्यायांसाठी llama.cpp च्या स्वतःच्या tool ने quantize करा आणि तयार झालेली GGUF file import करा. Build ने अपेक्षित परिणाम दिला आहे का, हे पडताळण्यासाठी ollama show मधील quantization line वापरा.

काय चुकते तेव्हा तुम्हाला काय दिसेल

GPU अपेक्षित असताना सर्व प्रक्रिया CPU वर चालतात. PROCESSOR स्तंभ वाचा:

ollama ps

यात 100% GPU, 100% CPU किंवा 48%/52% CPU/GPU सारखे विभाजन दिसते. विभाजनाचा अर्थ असा की weights आणि KV cache VRAM मध्ये बसले नाहीत. VRAM म्हणजे video RAM, म्हणजे graphics card वरील memory. त्यामुळे model चा काही भाग system memory मध्ये ठेवला गेला. त्यानंतर वेग केवळ CPU वरील वेगाच्या जवळ येतो, कारण प्रत्येक token ला धीम्या भागाची प्रतीक्षा करावी लागते. Context window कमी करा, cache quantize करा किंवा लहान build वापरा. अधिक cores जोडल्याने मदत होणार नाही.

Loading दरम्यान model बंद केला जातो. Kernel आणि service log तपासा:

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

Out of memory: Killed process असलेली ओळ म्हणजे weights, KV cache आणि buffers यांचा एकूण आकार box वरील उपलब्ध memory पेक्षा जास्त झाला. Swap configure केलेला नसलेल्या VPS वर ही ओळ दिसण्यापूर्वी संपूर्ण machine काही सेकंदांसाठी प्रतिसाद देणे थांबवू शकते.

तुम्ही काहीही बदलले नसताना answers ची गुणवत्ता कमी झाली. एकाच model च्या दोन builds वेगवेगळ्या tags अंतर्गत ollama ls मध्ये एकत्र असू शकतात. Unsuffixed name वापरणारी script library सध्या ज्या build कडे निर्देश करते तेच build वापरेल. Client मागत असलेल्या अचूक tag वर ollama show चालवा आणि configuration file मधील name वर अवलंबून न राहता quantization ओळ वाचा.

FAQ

कोणते Ollama quantization डाउनलोड करावे?

q4_K_M पासून सुरुवात करा. बहुतेक मॉडेलसाठी Ollama library हा default tag म्हणून तोच release करते. त्यामुळे ollama pull qwen3:8b आणि ollama pull qwen3:8b-q4_K_M एकच file fetch करतात. Memory उपलब्ध असेल आणि task मध्ये लहान चुका गंभीर ठरत असतील, जसे tool calling किंवा structured JSON output, तेव्हाच q8_0 वापरा. Memory budget निश्चित असल्यास, q4_K_M मधील मोठे model सामान्यतः q8_0 मधील लहान model पेक्षा चांगली कामगिरी करते. त्यामुळे precision साठी RAM वापरण्यापूर्वी ही जोडी तपासा.

q4_K_M म्हणजे प्रत्येक weight साठी खरोखर चार bits का?

नाही. Llama 3.1 8B वर मोजल्यास ते प्रत्येक weight साठी 4.89 bits आहे. कारण weights च्या प्रत्येक block मध्ये त्याचा स्वतंत्र scale साठवला जातो आणि सर्वाधिक संवेदनशील tensors अधिक रुंद type मध्ये promote केले जातात. याच कारणामुळे Q8_0 चे मोजमाप आठऐवजी 8.5 bits येते. अंदाजासाठी मोजलेला आकडा वापरा: parameter count ला bits per weight ने गुणून आठने भागल्यास bytes मधील file size मिळते.

CPU-only VPS वर 8B model साठी किती RAM आवश्यक आहे?

Weights, KV cache आणि headroom यांची बेरीज करा. q4_K_M मधील Qwen3 8B साठी weights चे प्रमाण 5.2 GB आहे. Default 4096 token window वर cache मध्ये आणखी 0.6 GB जोडले जातात. त्यामुळे compute buffers आणि operating system साठीची RAM धरलेली नसताना किमान आवश्यकता जवळपास 5.8 GB असते. 32k window वर cache एकट्याचे प्रमाण 4.83 GB असते. Short window साठी 8 GB आणि long window साठी 16 GB नियोजित ठेवा.

मशीनमध्ये GPU असूनही माझे model 100% CPU वर का चालत आहे?

ollama ps चालवा आणि PROCESSOR column वाचा. 100% CPU किंवा 48%/52% CPU/GPU सारखे split म्हणजे weights आणि KV cache VRAM मध्ये बसले नाहीत. त्यामुळे Ollama ने model चा काही भाग किंवा संपूर्ण model system memory मध्ये ठेवला. याचे सामान्य कारण म्हणजे context window GPU card मध्ये मावण्यापेक्षा मोठी असणे. Model load होताना संपूर्ण window साठी cache allocate केला जातो. OLLAMA_CONTEXT_LENGTH वापरून window कमी करा, cache निम्मा करण्यासाठी OLLAMA_KV_CACHE_TYPE=q8_0 सेट करा किंवा smaller quantization fetch करा.