Ollama quantization: q4_K_M, q8_0 और fp16 में अंतर

Ollama quantization में क्या बदलाव आते हैं

Ollama quantization में मॉडल के प्रत्येक weight को उसके मूल training file की तुलना में कम bits में store किया जाता है। q4_K_M पर समाप्त होने वाला tag प्रति weight लगभग चार bits रखता है, जबकि fp16 सोलह bits रखता है। इसलिए, download का आकार लगभग एक-चौथाई हो जाता है और प्रत्येक token उत्पन्न करने के लिए मशीन को एक-चौथाई bytes ही पढ़ने पड़ते हैं। Weights को एक मोटे grid पर round किया जाता है, उन्हें हटाया नहीं जाता है, और चार bits पर अधिकांश models पूर्ण precision के समान ही उत्तर देते हैं।

यही पूरा trade-off है: बहुत कम memory footprint और प्रति सेकंड अधिक tokens, जिसके बदले में सटीकता (accuracy) में थोड़ी कमी आती है। नीचे यह बताया गया है कि किसी विशिष्ट मशीन पर किसी विशिष्ट मॉडल के लिए इन दोनों पहलुओं का अनुमान कैसे लगाया जाए, ताकि आप ऐसी file को download करने में बीस मिनट बर्बाद न करें जो आपकी मशीन में fit ही न हो।

यदि Ollama अभी तक चल नहीं रहा है, तो VPS पर Ollama install करने से शुरुआत करें। यह पृष्ठ मानता है कि ollama ls पहले से ही काम कर रहा है।

Ollama quantization tag जैसे q4_K_M को कैसे समझें

Local models GGUF files के रूप में आते हैं, जो वह format है जिसका उपयोग llama.cpp weights को disk पर store करने के लिए करता है। Ollama, llama.cpp पर आधारित है, इसलिए Ollama tags में llama.cpp के quantization names बिना किसी बदलाव के उपयोग किए जाते हैं।

यह संख्या target width है। q4 का अर्थ है कि अधिकांश weight tensors को चार bits में pack किया गया है। q8 का अर्थ आठ है। fp16 को बिल्कुल भी quantize नहीं किया गया है: यह sixteen bit floating point पर model है, जो वह precision है जिसमें अधिकांश models publish किए जाते हैं।

K एक K-quant को दर्शाता है। Weights को छोटे blocks में group किया जाता है, और प्रत्येक block packed values के साथ अपना scale store करता है। एक block जिसके सभी weights 0.01 के करीब होते हैं, उसे fine scale मिलता है। एक block जिसमें एक बड़ा outlier होता है, उसे coarse scale मिलता है। ये per-block scales ही हैं जो चार bit वाली file को usable बनाए रखते हैं, और यही कारण है कि चार bit वाली file कभी भी प्रति weight सटीक चार bits की नहीं होती।

अंतिम अक्षर mixture है। S, M और L यह तय करते हैं कि कितने tensors को target width से ऊपर रखा जाए। q4_K_M में, जिन tensors को round करने पर सबसे अधिक नुकसान होता है, उन्हें अधिक width के साथ store किया जाता है, जबकि बाकी हिस्सा चार bits पर रहता है। यही कारण है कि q4_K_M लगभग समान file size पर पुराने q4_0 की तुलना में बेहतर output देता है।

जो नाम आपने type किया है उससे अनुमान लगाने के बजाय Ollama से पूछें कि disk पर क्या है:

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

ollama show, architecture, parameters, quantization, context length और embedding length को print करता है। quantization line उस model के लिए ground truth है जिसे आपने महीनों पहले pull किया था और अब याद नहीं है कि आपने क्या चुना था।

Bits per weight ही फाइल साइज का मुख्य आधार है

हर साइज का अनुमान एक संख्या से शुरू होता है: फॉर्मेट प्रति weight कितने 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
  }
]

उस टेबल में आश्चर्य की बात दूसरा कॉलम है। Q4_K_M का मतलब प्रति weight चार bits नहीं है। यह 4.89 bits मापता है, क्योंकि block scales और promoted tensors दोनों वास्तविक space लेते हैं। इसी कारण से 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 फाइल है, जिसे दो संख्याओं से प्राप्त किया गया है। यह लगभग उतनी ही मेमोरी है जितनी weights लोड होने के बाद घेरते हैं। Ollama लोड होने पर किसी भी चीज़ को unpack नहीं करता है: quantized weights मेमोरी में उसी packed रूप में रहते हैं और प्रत्येक block का उपयोग करते समय उसे convert किया जाता है।

Ollama प्रत्येक model size के लिए क्या प्रदान करता है

Library अधिकांश परिवारों के लिए एक q4_K_M, एक q8_0 और एक fp16 tag प्रकाशित करती है। ये अगस्त 2026 तक Qwen3 के आकार हैं, जिन्हें 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 डाउनलोड करता है जो ollama pull qwen3:8b-q4_K_M करता है, क्योंकि बिना suffix वाला tag वास्तव में q4_K_M build ही है। Q4_K_M कोई ऐसा समझौता नहीं है जिसे library अनिच्छा से प्रदान करती है। यह वह default है जिसे upstream ने चुना है, इसलिए किसी भी ऐसे model के लिए जिसे आपने स्वयं test नहीं किया है, इसका मिलान करना सबसे उचित पहला कदम है। यही तर्क VPS पर Qwen 3 चलाना में tag के विकल्पों को निर्धारित करता है।

ये अनुपात हर row में समान रहते हैं। q4_K_M से q8_0 पर जाने में लगभग सत्तर प्रतिशत अधिक लागत आती है, न कि बिल्कुल दोगुना, क्योंकि embedding और output tensors बाकी हिस्सों की तरह scale नहीं होते हैं। fp16 का आकार q4_K_M से लगभग तीन गुना होता है। q4_K_M पर 32B model का वजन 20 GB है, जो पहले से ही उस क्षमता से अधिक है जिसे 16 GB वाला box किसी भी context window के साथ संभाल सकता है। यह देखने के लिए कि कौन सा model किस machine पर फिट बैठता है, आप किन models को self-host कर सकते हैं देखें।

KV cache एक दूसरी, context पर निर्भर लागत क्यों है

Weights एक निश्चित लागत हैं। KV cache (key and value cache) एक परिवर्तनशील लागत है। context window में प्रत्येक token अपनी हर layer के लिए key और value vectors को सुरक्षित रखता है, इसलिए cache आपके द्वारा अनुमति दी गई window के साथ सीधे अनुपात में बढ़ता है। यह model load होते समय पूरी window के लिए allocate किया जाता है, न कि बातचीत बढ़ने के साथ-साथ, यही कारण है कि एक शब्द के 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, और 128 का head dimension। ollama show आपको architecture और parameter count देता है, और Hugging Face पर model का config.json आपको बाकी जानकारी देता है। प्रति token लागत को window size से गुणा करें और cache एक मामूली त्रुटि (rounding error) नहीं रह जाता।

[
  {
    "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 की 4096 tokens की default window पर, cache weights के ऊपर 0.6 GB जोड़ता है। window को 32k तक बढ़ाएं और केवल cache ही 4.83 GB तक पहुँच जाता है, जो कि quantized weights के लगभग बराबर memory है, और पूरे model के लिए न्यूनतम आवश्यकता 10 GB हो जाती है। इसे न्यूनतम आवश्यकता इसलिए कहते हैं क्योंकि compute buffers और operating system इसके ऊपर काम करते हैं। model load होने के बाद ollama ps के SIZE column से वास्तविक आंकड़ा देखें।

जब आप Ollama को service के रूप में चलाते हैं, तो window server पर set की जाती है, न कि प्रति request:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd install के लिए, इसे एक drop-in file में रखें:

sudo systemctl edit ollama

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

sudo systemctl restart ollama के साथ restart करें, फिर यह पुष्टि करने के लिए कि running model वास्तव में किस window के साथ load हुआ है, ollama ps के CONTEXT column की जाँच करें। OLLAMA_KV_CACHE_TYPE स्वयं cache को quantize करता है: f16 default है, q8_0, f16 की तुलना में लगभग आधी memory का उपयोग करता है, और q4_0 लगभग एक चौथाई का। यह एक global option है, इसलिए उस server पर मौजूद हर model को एक जैसा ही treatment मिलता है। लंबी window वाले छोटे box पर, cache को आधा करने से किसी भी अन्य बदलाव की तुलना में अधिक memory खाली होती है। num_ctx सेट करना और इसकी लागत में window के बारे में विस्तार से बताया गया है।

8 GB, 16 GB या 32 GB VPS पर क्या फिट होता है

इसमें मॉडल के weights, KV cache, और ऑपरेटिंग सिस्टम व अन्य चल रहे कार्यों के लिए आवश्यक headroom शामिल है। एक छोटे VPS पर 2 GB का headroom पर्याप्त रहता है।

8 GB. q4_K_M पर 4B मॉडल 2.6 GB का होता है और यह लंबे context window के लिए जगह छोड़ता है। q4_K_M पर 8B मॉडल डिफॉल्ट 4k window के साथ फिट हो जाता है, लेकिन इसमें बहुत कम खाली जगह बचती है। यहाँ 32k window के साथ 8B मॉडल चलाने की योजना न बनाएं, क्योंकि 10 GB का न्यूनतम RAM उपयोग पहले ही क्षमता से अधिक हो जाता है।

16 GB. 16k या 32k window के साथ q4_K_M पर 8B मॉडल आसानी से चलता है। q4_K_M पर 14B मॉडल के weights 9.3 GB के होते हैं और यह एक सीमित window के साथ फिट हो जाता है। q8_0 पर 8B मॉडल 8.9 GB का है, इसलिए यह भी फिट हो जाता है। अपने स्वयं के prompts पर इन दोनों की तुलना करना इस विषय पर बिताया गया सबसे उपयोगी समय होगा।

32 GB. q8_0 पर 14B (16 GB) और q4_K_M पर 32B (20 GB) दोनों मॉडल लोड हो जाते हैं। बड़े window के साथ 32B बिल्ड मेमोरी की ऊपरी सीमा तक पहुँच जाएगा, इसलिए अनुमान लगाने के बजाय ollama ps पर नजर रखें।

क्वांटाइजेशन में सबसे पहले क्या खराब होता है

क्वांटाइजेशन की त्रुटि मॉडल के सभी कार्यों पर समान रूप से नहीं फैलती है। प्रवाह (fluency) सबसे लंबे समय तक बनी रहती है, और यही कारण है कि नुकसान को पहचानना आसान नहीं होता: एक खराब तरीके से क्वांटाइज किया गया मॉडल भी साफ-सुथरे वाक्य लिख सकता है। सबसे पहले सटीकता (precision) प्रभावित होती है। जैसे किसी वर्जन नंबर, API सिग्नेचर या तारीख को सटीक रूप से याद रखना। तर्क की लंबी कड़ियाँ, जहाँ दूसरे चरण की एक छोटी सी गलती आठवें चरण में गलत उत्तर बन जाती है। सख्त आउटपुट फॉर्मेट, जहाँ एक गलत ब्रैकेट के कारण टूल कॉल विफल हो जाता है।

अंतिम वाला बिंदु एक व्यावहारिक परीक्षण है। जब मॉडल को JSON लौटाना होता है जिसे आपका कोड पार्स करता है, तो क्वांटाइजेशन की क्षति अस्पष्ट गद्य के बजाय पार्स एरर के रूप में सामने आती है, इसलिए आप इसे उसी दिन देख लेते हैं। एक कोडिंग एजेंट इस परीक्षण का सबसे कठोर रूप है, क्योंकि यह मॉडल को एक के बाद एक टूल कॉल करने के लिए मजबूर करता है, इसलिए अपने Ollama सर्वर पर एक एजेंट को पॉइंट करना एक दोपहर के भीतर ही अत्यधिक आक्रामक क्वांटाइजेशन की पोल खोल देगा।

चार बिट्स से नीचे नुकसान काफी बढ़ जाता है। q3 और दो-बिट प्रकार उन लोगों के लिए मौजूद हैं जो एक बड़े मॉडल को छोटे हार्डवेयर पर फिट करने की कोशिश कर रहे हैं, और जब विकल्प मॉडल को बिल्कुल न चला पाना हो, तो ये एक वास्तविक विकल्प हैं। ये डिफ़ॉल्ट के रूप में खराब विकल्प हैं। q4_K_M और q8_0 के बीच का अंतर इतना कम है कि एक प्रकाशित परप्लेक्सिटी टेबल आपके वर्कलोड के लिए इसे तय नहीं कर पाएगी, इसलिए उस तरीके से इसे तय करने की कोशिश न करें। अपने खुद के तीस प्रॉम्प्ट्स पर दोनों को चलाकर देखें और आउटपुट पढ़ें।

कब q8_0 या fp16 का उपयोग RAM के लिए उचित है

जब मेमोरी वास्तव में अतिरिक्त हो और कार्य में छोटी त्रुटियां भी भारी पड़ें, तब q8_0 का उपयोग करें: जैसे स्ट्रक्चर्ड एक्सट्रैक्शन, टूल कॉलिंग, या ऐसा कोड जिसे कंपाइल होना आवश्यक है। यहाँ आप एक बीमा खरीद रहे हैं, न कि कोई स्पष्ट रूप से अधिक स्मार्ट मॉडल।

fp16 को केवल दो कारणों से उपयोग करें। या तो आप स्वयं मॉडल को क्वांटाइज़ कर रहे हैं और आपको सोर्स फ़ाइल की आवश्यकता है, या आप एक बेसलाइन माप रहे हैं ताकि आप यह जान सकें कि आपके चार-बिट बिल्ड ने कितनी सटीकता खोई है। fp16 से सर्विंग करने पर q4_K_M की तुलना में तीन गुना अधिक मेमोरी खर्च होती है, जबकि इसका अंतर अधिकांश लोग बिना देखे नहीं पहचान सकते। केवल CPU वाले बॉक्स पर, यह आपके टोकन रेट को भी एक-तिहाई कर देता है।

एक निश्चित मेमोरी बजट पर, अधिक मजबूत नियम यह है: q4_K_M पर एक बड़ा मॉडल आमतौर पर q8_0 पर एक छोटे मॉडल से बेहतर प्रदर्शन करता है। 14B वेट का 9.3 GB और 8B वेट का 8.9 GB लगभग समान RAM (रैंडम एक्सेस मेमोरी) लेते हैं, और बड़ा मॉडल अधिक जानकारी रखता है। इसे केवल विश्वास के आधार पर न लें, बल्कि अपने स्वयं के प्रॉम्प्ट्स पर इसका परीक्षण करें।

CPU only inference की गति memory bandwidth द्वारा सीमित होती है

अधिकांश VPS plans में GPU नहीं होता है, इसलिए model host CPU की system memory पर चलता है। ऐसी स्थिति में generation की गति arithmetic के बजाय memory bandwidth द्वारा सीमित होती है, क्योंकि एक token generate करने के लिए हर weight को एक बार पढ़ना आवश्यक होता है। यह एक ऐसी सीमा तय करता है जिसका आपके द्वारा खरीदे गए CPU 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

50 GB/s एक dual channel DDR4-3200 host के लिए लगभग सैद्धांतिक आंकड़ा है। आपका हिस्सा इससे कम होगा, क्योंकि एक VPS उस bus को machine पर मौजूद अन्य सभी tenants के साथ साझा करता है, इसलिए इन आंकड़ों को एक ऐसी अधिकतम सीमा मानें जिसे कोई नहीं छू पाता। यहाँ महत्वपूर्ण बात यह है कि CPU पर, weight के bits को आधा करने से token rate लगभग दोगुना हो जाता है। बिना GPU वाले box पर quantization गति बढ़ाने का सबसे बड़ा साधन है।

Prompt processing अलग तरह से काम करती है। एक लंबे prompt को पढ़ना bandwidth के बजाय compute bound होता है, इसलिए generation speed पर लगभग कोई प्रभाव डाले बिना, अतिरिक्त cores यहाँ मदद करते हैं। यदि कोई box 4k prompt को तेजी से ingest करता है और फिर धीरे-धीरे generate करता है, तो यह सामान्य व्यवहार है।

किसी भी गणना पर आँख बंद करके भरोसा न करें। अपने स्वयं के box पर tokens per second मापें और प्रत्येक quantization के लिए एक ही prompt का उपयोग करें, और अपने आंकड़ों को ही अंतिम मानें।

स्वयं मॉडल को क्वांटाइज़ करना

Ollama fp16 या fp32 स्रोत से एक क्वांटाइज़्ड मॉडल बना सकता है। यह तब महत्वपूर्ण होता है जब आपने किसी मॉडल को fine-tune किया हो और उसके लिए कोई library tag मौजूद न हो। Modelfile को unquantized weights की ओर निर्देशित करें:

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 के अपने टूल का उपयोग करके क्वांटाइज़ करें और तैयार GGUF फ़ाइल को इम्पोर्ट करें। ollama show से quantization लाइन यह सत्यापित करने का तरीका है कि build ने आपके निर्देशानुसार कार्य किया है या नहीं।

जब चीजें गलत हो जाएं तो आप क्या देखेंगे

जब आप GPU की अपेक्षा करते हैं, तब सब कुछ CPU पर चलता है। PROCESSOR कॉलम को पढ़ें:

ollama ps

यह 100% GPU, 100% CPU, या 48%/52% CPU/GPU जैसा विभाजन प्रिंट करता है। विभाजन का अर्थ है कि weights और KV cache VRAM (ग्राफिक्स कार्ड की मेमोरी) में फिट नहीं हुए, इसलिए मॉडल का कुछ हिस्सा सिस्टम मेमोरी में रखा गया। इसके बाद गति केवल CPU की दर के करीब गिर जाती है, क्योंकि प्रत्येक token धीमी गति वाले हिस्से की प्रतीक्षा करता है। context window को कम करें, cache को quantize करें, या छोटा build लें। अधिक cores जोड़ने से मदद नहीं मिलेगी।

लोड होते समय मॉडल kill हो जाता है। 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 का कुल योग बॉक्स की मेमोरी से अधिक हो गया है। बिना swap कॉन्फ़िगर किए गए VPS पर, उस पंक्ति के दिखाई देने से पहले पूरी मशीन कई सेकंड के लिए रुक सकती है।

उत्तर खराब हो गए और आपने कुछ भी नहीं बदला। एक ही मॉडल के दो build ollama ls में अलग-अलग tags के तहत साथ-साथ रह सकते हैं, और जो script बिना suffix वाले नाम को pull करती है, वह उसी का अनुसरण करेगी जिस पर library अब इंगित करती है। अपने configuration file में नाम पर भरोसा करने के बजाय, अपने client द्वारा अनुरोधित सटीक tag के विरुद्ध ollama show चलाएं और quantization पंक्ति को पढ़ें।

FAQ

मुझे कौन सा Ollama quantization pull करना चाहिए?

q4_K_M से शुरुआत करें। Ollama library अधिकांश models के लिए इसे ही default tag के रूप में ship करती है, इसलिए ollama pull qwen3:8b और ollama pull qwen3:8b-q4_K_M दोनों एक ही file fetch करते हैं। q8_0 पर तभी जाएँ जब memory खाली हो और कार्य में छोटी त्रुटियों की गुंजाइश न हो, जैसे कि tool calling या structured JSON output। जब memory budget सीमित हो, तो q4_K_M पर एक बड़ा model आमतौर पर q8_0 पर एक छोटे model से बेहतर प्रदर्शन करता है, इसलिए precision पर RAM खर्च करने से पहले उस pairing का परीक्षण करें।

क्या q4_K_M का वास्तव में मतलब प्रति weight चार bits है?

नहीं। Llama 3.1 8B पर मापे जाने पर यह 4.89 bits प्रति weight है, क्योंकि weights का प्रत्येक block अपना scale store करता है और सबसे संवेदनशील tensors को व्यापक type में प्रमोट किया जाता है। इसी कारण से Q8_0 आठ के बजाय 8.5 bits मापता है। अनुमान लगाते समय मापे गए आंकड़े का उपयोग करें: parameter count को bits प्रति weight से गुणा करें और आठ से विभाजित करें, इससे file का size bytes में प्राप्त होगा।

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 से पहले न्यूनतम आवश्यकता 5.8 GB के करीब होती है। 32k window पर केवल cache ही 4.83 GB का होता है। छोटे window के लिए 8 GB और यदि आप लंबा window चाहते हैं तो 16 GB की योजना बनाएँ।

GPU होने के बावजूद मेरा model 100% CPU पर क्यों चल रहा है?

ollama ps चलाएँ और PROCESSOR column को देखें। 100% CPU, या 48%/52% CPU/GPU जैसा split, यह दर्शाता है कि weights और KV cache VRAM में फिट नहीं हुए, इसलिए Ollama ने model के कुछ या पूरे हिस्से को system memory में डाल दिया है। इसका सामान्य कारण card की क्षमता से बड़ा context window है, क्योंकि model load होते ही पूरे window के लिए cache allocate हो जाता है। OLLAMA_CONTEXT_LENGTH के साथ window को कम करें, cache को आधा करने के लिए OLLAMA_KV_CACHE_TYPE=q8_0 set करें, या छोटा quantization pull करें।