Ollama quantization: Q4, Q8 और 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 full precision के समान ही उत्तर देते हैं।

यही पूरा trade-off है: बहुत कम memory footprint और प्रति सेकंड अधिक tokens, जिसके बदले में accuracy में थोड़ी कमी आती है। नीचे यह बताया गया है कि किसी विशिष्ट box पर किसी विशिष्ट model के लिए इन दोनों पहलुओं का अनुमान कैसे लगाया जाए, ताकि आप ऐसी 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 प्रति weight पर pack किया गया है। q8 का अर्थ आठ bits है। fp16 बिल्कुल भी quantized नहीं है: यह model सोलह-bit floating point में है, जो वह 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 से अधिक पर promote किया जाए। 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 प्रत्येक मॉडल आकार के लिए वास्तव में क्या प्रदान करता है

Library अधिकांश परिवारों के लिए एक q4_K_M, एक q8_0 और एक fp16 टैग प्रकाशित करती है। कुछ नए परिवार इस पैटर्न का पालन नहीं करते हैं और library में केवल cloud टैग के रूप में दिखाई देते हैं, जिन्हें किसी भी आकार में pull नहीं किया जा सकता। यही वह बाधा है जिसका सामना आप VPS पर GLM 5.2 चलाने का प्रयास करते समय करते हैं। अगस्त 2026 तक Qwen3 के आकार नीचे दिए गए हैं, जिन्हें मॉडल पेज पर टैग सूची से पढ़ा गया है। नीचे दिए गए प्रत्येक आंकड़े का अर्थ RAM में आने से पहले disk पर लिया जाने वाला स्थान है। इनमें से दो या तीन मॉडल मिलकर एक छोटे VPS के root volume को भर सकते हैं, इसलिए टैग collect करना शुरू करने से पहले यह जानना फायदेमंद है कि Ollama डाउनलोड किए गए मॉडलों को कहाँ स्टोर करता है।

[
  {
    "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 टैग मायने रखता है। ollama pull qwen3:8b बिल्कुल वही 5.2 GB डाउनलोड करता है जो ollama pull qwen3:8b-q4_K_M करता है, क्योंकि बिना suffix वाला टैग वास्तव में q4_K_M build ही है। Q4_K_M कोई ऐसा समझौता नहीं है जिसे library अनिच्छा से प्रदान करती है। यह वह default है जिसे upstream ने चुना है, इसलिए किसी भी ऐसे मॉडल के लिए जिसे आपने स्वयं test नहीं किया है, इसका मिलान करना पहला तर्कसंगत कदम है। यही तर्क VPS पर Qwen 3 चलाने में टैग के चयन को निर्देशित करता है।

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

KV cache एक दूसरा, context पर निर्भर खर्च क्यों है

Weights एक निश्चित (fixed) खर्च हैं। KV cache (key and value cache) एक परिवर्तनशील (variable) खर्च है। 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 के लिए न्यूनतम आवश्यकता (floor) 10 GB हो जाती है। इसे 'floor' इसलिए कहा जाता है क्योंकि 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 विकल्प है, इसलिए server पर मौजूद हर model पर यही लागू होता है। Cache quantization केवल तब प्रभावी होता है जब Flash Attention enabled हो, जिसे Ollama backend द्वारा support किए जाने पर स्वचालित रूप से कर देता है, और OLLAMA_FLASH_ATTENTION=1 इसे अनिवार्य (force) कर देता है। लंबी window वाले छोटे server पर, cache को आधा करने से किसी भी अन्य बदलाव की तुलना में अधिक memory खाली होती है। num_ctx सेट करना और इसकी लागत में window के बारे में विस्तार से बताया गया है। Cache का आकार प्रति server के बजाय प्रति concurrent request slot के हिसाब से तय होता है, इसलिए Ollama को एक साथ दो prompts का उत्तर देने की अनुमति देने से आपका बजट दोगुना हो जाता है। यही वह गणित है जो parallel slot count और queue limit चुनना के पीछे काम करता है।

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

बजट वेट्स (weights), साथ ही KV cache, और ऑपरेटिंग सिस्टम व अन्य चल रहे कार्यों के लिए अतिरिक्त headroom। एक छोटे VPS पर 2 GB का headroom पर्याप्त होता है।

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

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

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

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

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

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

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

कब q8_0 या fp16 का उपयोग RAM के लिए सार्थक है

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

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

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

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

अधिकांश VPS plans में GPU नहीं होता है, इसलिए model host CPU की system memory पर चलता है। ऐसी स्थिति में generation की गति arithmetic (गणना) से नहीं, बल्कि memory bandwidth से सीमित होती है, क्योंकि एक token generate करने के लिए हर weight को एक बार पढ़ना पड़ता है। यह एक ऐसी अधिकतम सीमा (ceiling) तय करता है जिसका आपके द्वारा खरीदे गए 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 गति बढ़ाने का सबसे बड़ा जरिया है। जो गति आपको मिलती है वह स्वीकार्य है या नहीं, यह model पर निर्भर करता है, और Nemotron 3.5 Lightning on a VPS एक विशिष्ट build, tag और RAM के आंकड़ों के साथ इस विभाजन को स्पष्ट करता है। प्रतीक्षा का दूसरा हिस्सा यह है कि model कितना output लिखना चाहता है, क्योंकि 10 tokens प्रति सेकंड की गति से 600 tokens का उत्तर पूरा एक मिनट लेता है, इसलिए num_predict के साथ reply को सीमित करना अक्सर precision को और कम करने की तुलना में अधिक समय बचाता है।

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

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

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

यह तब महत्वपूर्ण होता है जब आपने किसी मॉडल को fine-tune किया हो और उसके लिए कोई library tag मौजूद न हो। इसका तरीका उस फॉर्मेट पर निर्भर करता है जिसे आप प्राप्त करना चाहते हैं, क्योंकि Ollama अब वे GGUF K-quants नहीं बनाता है जिन्हें यह पेज मापता है।

q4_K_M जैसे K-quant के लिए, Ollama द्वारा फ़ाइल को देखने से पहले ही उसे क्वांटाइज़ करें। Ollama import के दौरान GGUF मॉडल्स को क्वांटाइज़ नहीं करता है, और यह GGUF स्रोत पर --quantize करने से मना कर देता है। unquantized GGUF को llama.cpp के llama-quantize का उपयोग करके क्वांटाइज़ करें, और फिर तैयार फ़ाइल को import करें। इस import प्रक्रिया में एक समस्या यह हो सकती है कि chat template मेल न खाने के कारण मॉडल गलत उत्तर देने लगता है, जिसे Ollama में GGUF फ़ाइल import करना में विस्तार से समझाया गया है। ollama show से प्राप्त quantization लाइन का उपयोग करके आप यह सत्यापित कर सकते हैं कि import की गई फ़ाइल वही build है जिसे आप चाहते थे।

Ollama का अपना --quantize केवल safetensors imports पर काम करता है। Modelfile को उस डायरेक्टरी की ओर निर्देशित करें जिसमें unquantized safetensors weights मौजूद हैं:

FROM /path/to/safetensors/directory

फिर build करें:

ollama create --quantize int4 mymodel

Ollama v0.40.0 (2026-10-09 को जाँचा गया) के अनुसार, --quantize में int4, int8, nvfp4, mxfp4 और mxfp8 स्वीकार किए जाते हैं, जिसमें q4 और q8 को int4 और int8 के aliases के रूप में लिया जाता है। q4_K_M, q4_K_S, q8_0, q6_K और q5_K_M जैसे GGUF नामों को unsupported quantize type त्रुटि के साथ अस्वीकार कर दिया जाता है। ये प्रकार ऊपर दी गई तालिकाओं में मौजूद GGUF K-quants नहीं हैं, इसलिए इस पेज पर दिए गए bits per weight और फ़ाइल आकार के आंकड़ों को इनके लिए अनुमान न मानें।

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

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

ollama ps

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

लोड होते समय मॉडल किल (kill) हो जाता है। कर्नल और सर्विस लॉग की जाँच करें:

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

Out of memory: Killed process वाली एक लाइन का अर्थ है कि वेट्स, KV cache और बफ़र्स का कुल योग बॉक्स की मेमोरी से अधिक हो गया है। बिना स्वैप (swap) कॉन्फ़िगर किए गए VPS पर, उस लाइन के आने से पहले पूरी मशीन कई सेकंड के लिए रुक सकती है।

आपने कुछ नहीं बदला, फिर भी उत्तर खराब हो गए। एक ही मॉडल के दो बिल्ड अलग-अलग टैग के तहत ollama ls में साथ-साथ रह सकते हैं, और जो स्क्रिप्ट बिना सफिक्स (unsuffixed) वाले नाम को पुल (pull) करती है, वह उसी को फॉलो करेगी जिस पर लाइब्रेरी अभी पॉइंट कर रही है। अपने कॉन्फ़िगरेशन फ़ाइल में नाम पर भरोसा करने के बजाय, अपने क्लाइंट द्वारा अनुरोधित सटीक टैग के विरुद्ध ollama show चलाएं और quantization लाइन को पढ़ें।

FAQ

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

q4_K_M से शुरुआत करें। Ollama library अधिकांश models के लिए इसे ही default tag के रूप में ships करती है, इसलिए 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 आठ के बजाय 4.83 bits मापता है। अनुमान लगाते समय मापे गए आंकड़े का उपयोग करें: parameter count को bits प्रति weight से गुणा करें और आठ से विभाजित करें, इससे file का size bytes में प्राप्त होगा।

CPU-only VPS पर 8B model को कितनी RAM की आवश्यकता होती है?

weights, KV cache और headroom को जोड़ें। Qwen3 8B का q4_K_M संस्करण 5.2 GB weights का है। default 4096 token window पर cache 0.6 GB जोड़ता है, जिससे compute buffers और operating system से पहले कुल RAM 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 में fit नहीं हुए, इसलिए 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 करें।