Ollama quantization: Q4, Q8 और fp16 में क्या अंतर है?

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

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

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

अंतिम अक्षर 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 प्रत्येक मॉडल आकार के लिए वास्तव में क्या प्रदान करता है

लाइब्रेरी अधिकांश परिवारों के लिए एक q4_K_M, एक q8_0 और एक fp16 टैग प्रकाशित करती है। कुछ नए परिवार इस पैटर्न का पालन नहीं करते हैं और लाइब्रेरी में केवल क्लाउड टैग के रूप में दिखाई देते हैं, जिन्हें किसी भी आकार में पुल नहीं किया जा सकता। यही वह बाधा है जिसका सामना आप VPS पर GLM 5.2 चलाने का प्रयास करते समय करते हैं। अगस्त 2026 तक Qwen3 के आकार नीचे दिए गए हैं, जिन्हें मॉडल पेज पर टैग सूची से पढ़ा गया है। नीचे दिए गए प्रत्येक आंकड़े का अर्थ डिस्क पर उपयोग की जाने वाली जगह है, न कि RAM का। इनमें से दो या तीन मॉडल मिलकर एक छोटे VPS के root volume को भर सकते हैं, इसलिए टैग डाउनलोड करना शुरू करने से पहले यह जानना फायदेमंद है कि 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
  }
]

यहाँ डिफ़ॉल्ट टैग मायने रखता है। ollama pull qwen3:8b बिल्कुल उतने ही 5.2 GB डाउनलोड करता है जितने ollama pull qwen3:8b-q4_K_M, क्योंकि बिना सफिक्स वाला टैग वास्तव में q4_K_M बिल्ड ही है। Q4_K_M कोई ऐसा समझौता नहीं है जिसे लाइब्रेरी अनिच्छा से प्रदान करती है। यह वह डिफ़ॉल्ट है जिसे अपस्ट्रीम ने चुना है, इसलिए किसी भी ऐसे मॉडल के लिए जिसका आपने स्वयं परीक्षण नहीं किया है, इसका मिलान करना पहला तर्कसंगत कदम है। यही तर्क VPS पर Qwen 3 चलाने में टैग के चयन को निर्धारित करता है।

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

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

Weights एक निश्चित खर्च हैं। KV cache (key and value cache) एक परिवर्तनशील खर्च है। context window का प्रत्येक token हर layer के लिए अपने key और value vectors को सुरक्षित रखता है, इसलिए cache का आकार आपके द्वारा निर्धारित window के साथ सीधे अनुपात में बढ़ता है। model load होते समय ही पूरे window के लिए memory allocate कर दी जाती है, न कि conversation बढ़ने के साथ-साथ। यही कारण है कि एक शब्द के 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 एक मामूली अंतर नहीं रह जाता।

[
  {
    "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 के लिए न्यूनतम memory आवश्यकता 10 GB हो जाती है। इसे न्यूनतम सीमा इसलिए कहा जाता है क्योंकि compute buffers और operating system इसके ऊपर चलते हैं। model load होने के बाद ollama ps के SIZE column से वास्तविक आँकड़ा देखें।

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

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 size के साथ load हुआ है, ollama ps के CONTEXT column की जाँच करें। OLLAMA_KV_CACHE_TYPE स्वयं cache को quantize करता है: f16 default है, q8_0, f16 की तुलना में लगभग आधी memory का उपयोग करता है, और q4_0 लगभग एक-चौथाई। यह एक global option है, इसलिए server पर मौजूद हर model पर यही नियम लागू होता है। लंबी window वाले छोटे server पर, cache को आधा करने से किसी भी अन्य बदलाव की तुलना में अधिक memory खाली होती है। num_ctx set करना और उसका खर्च में window के बारे में विस्तार से बताया गया है। cache का आकार प्रति server के बजाय प्रति concurrent request slot के आधार पर तय होता है, इसलिए Ollama को एक साथ दो prompts का उत्तर देने की अनुमति देने से आपका बजट दोगुना हो जाता है। यही वह गणित है जो parallel slot count और queue limit चुनने के पीछे काम करता है।

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

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

8 GB. q4_K_M पर एक 4B मॉडल 2.6 GB का होता है और यह एक लंबे window के लिए जगह छोड़ता है। q4_K_M पर एक 8B मॉडल डिफॉल्ट 4k window और बहुत कम खाली जगह के साथ फिट हो जाता है। यहाँ 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 में आउटपुट देना होता है जिसे आपका कोड पार्स करता है, तो क्वांटाइजेशन का नुकसान अस्पष्ट भाषा के बजाय पार्सिंग त्रुटि के रूप में सामने आता है, इसलिए आप इसे उसी दिन देख लेते हैं। एक कोडिंग एजेंट इस परीक्षण का सबसे कठोर रूप है, क्योंकि यह मॉडल को एक के बाद एक टूल कॉल करने के लिए मजबूर करता है, इसलिए अपने 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 (रैंडम एक्सेस मेमोरी) की आवश्यकता होती है, और बड़ा मॉडल अधिक जानकारी रखता है। इसे केवल सुनी-सुनाई बातों पर मानने के बजाय अपने स्वयं के प्रॉम्प्ट्स पर टेस्ट करें।

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

पचास GB/s एक dual channel DDR4-3200 host के लिए लगभग सैद्धांतिक आंकड़ा है। आपका हिस्सा इससे कम होगा, क्योंकि एक VPS उस bus को machine पर मौजूद अन्य सभी tenants के साथ साझा करता है। इसलिए इन आंकड़ों को एक ऐसी अधिकतम सीमा मानें जिसे कोई नहीं छू पाता। यहाँ महत्वपूर्ण बात यह है कि CPU पर, bits per weight को आधा करने से token rate लगभग दोगुनी हो जाती है। बिना GPU वाले box पर quantization गति बढ़ाने का सबसे प्रभावी तरीका है। जो गति आपको प्राप्त होती है, वह model पर निर्भर करती है। Nemotron 3.5 Lightning on a VPS एक विशिष्ट build, tag और RAM के लिए इस विभाजन को स्पष्ट करता है। प्रतीक्षा का दूसरा हिस्सा यह है कि model कितना output लिखता है। दस tokens प्रति सेकंड की गति से, छह सौ tokens का उत्तर पूरा एक मिनट लेता है। इसलिए num_predict के साथ reply को cap करना अक्सर precision को और कम करने की तुलना में अधिक समय बचाता है।

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

किसी भी गणना पर आँख मूँदकर भरोसा न करें। Measure tokens per second on your own box का उपयोग करके प्रत्येक 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 फ़ाइल को इम्पोर्ट करना होगा। उस इम्पोर्ट प्रक्रिया में एक समस्या आ सकती है, जहाँ chat template के मेल न खाने के कारण मॉडल गलत उत्तर देने लगता है, जिसे Ollama में GGUF फ़ाइल इम्पोर्ट करना में विस्तार से समझाया गया है। ollama show से quantization लाइन का उपयोग करके आप यह सत्यापित कर सकते हैं कि build आपकी अपेक्षा के अनुरूप हुआ है या नहीं।

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

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

ollama ps

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

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

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

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

उत्तर खराब हो गए और आपने कुछ भी नहीं बदला। एक ही मॉडल के दो बिल्ड अलग-अलग टैग के तहत ollama ls में साथ-साथ रह सकते हैं, और जो स्क्रिप्ट बिना सफिक्स वाले नाम को पुल करती है, वह उसी को फॉलो करेगी जिस पर लाइब्रेरी अभी पॉइंट कर रही है। अपने कॉन्फ़िगरेशन फ़ाइल में नाम पर भरोसा करने के बजाय, अपने क्लाइंट द्वारा अनुरोधित सटीक टैग के विरुद्ध 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 पर्याप्त हो और task में छोटी गलतियों की गुंजाइश न हो, जैसे कि 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 को अधिक wide 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 में 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 करें।