GGUF Quantization: कौन सा level चुनें?

डिफ़ॉल्ट रूप से Q4_K_M चुनें; VRAM बचता हो और quality के आख़िरी कुछ प्रतिशत चाहिए तो Q6_K या Q8_0 पर जाएँ। GGUF quantization model के weights को 16 bits से घटाकर कम bits में रखती है — Q4_K_M हर weight को लगभग 4.85 bits में सहेजता है, इसलिए 7B मॉडल ~14 GB से घटकर ~4.1 GB का हो जाता है और perplexity आम तौर पर 1% से भी कम ख़राब होती है। “कौन सी gguf quantization लें” का जवाब boring तरीक़े से स्थिर है — बस online का ज़्यादातर ड्रामा उसे ढक देता है। आगे: quantization weights के साथ असल में क्या करती है, हर level quality से कितना लेता है, साइज़ का हिसाब ख़ुद कैसे लगाएँ, और एक कमांड जो किसी अजनबी के benchmark पर भरोसा करने की जगह आपके अपने हार्डवेयर पर नुक़सान नाप दे।

GGUF quantization असल में क्या करती है?

Model 16-bit floating point (FP16 या BF16) में train होता है: उसके अरबों weights में से हर एक 2-byte की संख्या है। Quantization हर weight को कम bits में सिमेट देती है। सीधा तरीक़ा — हर weight को 4-bit integer में गोल कर देना — छोटे-पर-ज़रूरी values उड़ा देता है, इसलिए GGUF दो तरकीबें इस्तेमाल करता है:

1. Block scaling। Weights को blocks (आम तौर पर 32) में बाँटा जाता है और हर block का अपना scale factor होता है। 4-bit values उसी block के भीतर offsets होती हैं, इसलिए magnitudes की चौड़ी रेंज बच निकलती है।
2. Importance-aware k-quants। Q4_K_M का “K” scales के super-blocks कहता है, साथ ही attention और feed-forward layers को एक-दूसरे से अलग नज़र से देखना, क्योंकि दोनों compression को बराबर बर्दाश्त नहीं करते।

“I” परिवार (IQ4_XS और साथी) आगे जाता है — image compression से उधार लिए information-theoretic codebooks के साथ। वही सोच, ऊँचा encoding: हर weight पर कम bits, लगभग वही quality, क़ीमत यह कि कुछ backends पर inference हल्का धीमा हो जाता है।

एक सफ़ाई जो ज़्यादातर confusion रोक देती है: quantization सिर्फ़ stored weights बदलती है। Architecture, tokenizer और context handling अछूते रहते हैं। एक ही model की Q4 फ़ाइल और Q8 फ़ाइल एक ही model हैं — बस अलग कोट पहने हुए।

Q4 vs Q8: क्या ऊँची quantization बेहतर है?

तकनीकी तौर पर हाँ; महसूस होने की दुनिया में नहीं। llama.cpp के अपने perplexity runs को Llama मॉडलों पर reference मानें तो: Q8_0 FP16 से ~0.02% की दूरी पर रहता है — हर अमली मक़सद के लिए lossless। Q6_K पास से पास अलग नहीं। Q4_K_M लगभग 1–2% perplexity लेता है, Q4_0 थोड़ा ज़्यादा, और Q2_K वह जगह है जहाँ छोटे मॉडलों के सँभले हुए जवाब बिखरने लगते हैं।

इन आँकड़ों से निकलने वाले दो नियम:

• Model का साइज़ quantization की ज़गह ख़रीदता है। 70B model, 7B की तुलना में Q2/Q3 कहीं बेहतर झेल लेता है, क्योंकि बड़े मॉडल ज़्यादा redundant होते हैं। 7B को Q2 में ले जाना अंग-भंग है; 70B को Q3 में ले जाना सिलाई-कटाई।
• Quality की floor task के साथ हिलती है। Chat Q4 बर्दाश्त कर लेता है। सटीक code generation, math और ठीक दस्तावेज़ों पर RAG, quantization के शोर को जल्दी बेनक़ाब कर देते हैं। अगर Q4 model लगातार हल्के-फुल्के ग़लत code लिख रहा हो, तो model को दोष देने से पहले उसी model को Q6_K पर टेस्ट करें।

Level	Bits/weight	FP16 से साइज़	Quality नुक़सान	कब इस्तेमाल करें
Q2_K	~3.4	~21%	sub-13B पर गंभीर	और कोई विकल्प न बचे, सिर्फ़ बड़े मॉडल
Q3_K_M	~3.9	~25%	साफ़ दिखने लायक़	VRAM तंग, ≥14B models
Q4_K_S	~4.6	~29%	थोड़ा	Q4_K_M न समाए और यह क़रीब समा जाए
Q4_K_M	~4.85	~30%	~1% perplexity	डिफ़ॉल्ट. quality/size का सबसे अच्छा सौदा
Q5_K_M	~5.7	~35%	~0.5%	VRAM हो, quality पर निर्भर काम
Q6_K	~6.6	~41%	न के बराबर	Code/math, और आराम से समा जाए
Q8_0	~8.5	~53%	असर में कुछ नहीं	Reference runs, fine-tune base
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M से हल्का बड़ा चाहिए और backend i-quants सपोर्ट करे

हर level को कितनी VRAM चाहिए?

Table रटने की बजाय साइज़ का हिसाब ख़ुद लगाएँ — एक line का काम है:

size_GB ≈ (bits_per_weight × params) / 8
# 8B मॉडल @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8B मॉडल @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

फिर उन हिस्सों को जोड़ें जो formula छोड़ देता है: KV cache (context length के साथ बढ़ता है — कुछ सौ MB से कई GB), activations, और compute buffers। अमली margin: “4.9 GB” वाला model 4k context पर 6 GB card माँगता है, और 16k पर वहीं टिके रहने के लिए flash-attention और KV-cache quantization। Weights सुर्ख़ियाँ हैं, पूरा bill नहीं।

आपको कौन सी GGUF quantization लेनी चाहिए?

फ़ैसले का क्रम, रटने लायक़ कोई छूट नहीं:

1. पहले context + KV का budget निकालें, weights के बाद। जो context समा ही नहीं, वह उस quality से ख़राब है जिसे नाप भी नहीं सकते।
2. Default Q4_K_M रखें। यह community का default किसी वजह से है — लगभग 1% perplexity, साइज़ के 70% पर। हर registry, Ollama की समेत, इसी को baseline की तरह भेजती है।
3. Q6_K पर चढ़ें जब task शोर को सज़ा दे: code, math, extraction — हर वह चीज़ जो pipeline में बिना किसी के देखे जाती है।
4. Q8_0 सिर्फ़ reference के लिए — A/B tests, quantization के नुक़सान की नाप, या fine-tune base। रोज़मर्रा की सवारी के तौर पर यह ज़्यादातर आपके VRAM sensors में गर्मी ख़रीदता है।
5. Q4 से नीचे सिर्फ़ मजबूरी में, और सिर्फ़ बड़े मॉडलों पर। भरोसा करने से पहले किसी जानी-पहचानी कठिन prompt से टेस्ट करें।

अगर Hugging Face पर यह चुनना है कि कौन सी फ़ाइल download करें, तो sharded splits की बजाय single Q4_K_M.gguf चुनें, जब तक uploader ने वही ही डाला हो — चलने वाले हिस्से कम, परेशानी कम। और अगर चुनना है कि उसे कहाँ चलाना है, तो engine का फ़ैसला अलग axis है: उसके लिए देखें llama.cpp vs Ollama।

Quantization का नुक़सान ख़ुद कैसे नापें?

Benchmarks अलग-अलग होते हैं; आपका prompt एक ही रहता है। llama.cpp एक बार build करें, उसी model के दो levels download करें, और दोनों की perplexity (कम = बेहतर) और tokens/second नापें:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# wiki-text के टुकड़े पर perplexity (कम = original model के ज़्यादा क़रीब)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# और उसी हार्डवेयर पर स्पीड
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Q4_K_M का आँकड़ा Q8_0 से कुछ सौवें दशमलव points पीछे रहेगा और फ़ाइल ~40% छोटी होगी। अगर आपका आगे का काम फ़र्क़ बता नहीं पाता — और ज़्यादातर काम नहीं बता पाते — तो किसी का leaderboard पढ़े बिना जवाब आपके पास है।

क्या quantization privacy या local-only वाले दावों पर असर डालती है?

नहीं — यह weights पर सादा गणित है, पूरी तरह offline, और quantized फ़ाइल उन्हीं parameters का छोटा डिब्बा है। Q4_K_M लोकल चलाने से उतना ही (या उतना ही कम) बाहर जाता है जितना full-precision model लोकल चलाने से: मशीन से कुछ नहीं निकलता। Privacy से जुड़ा हिसाब inference कहाँ चलता है यह है, bit width नहीं। Model की provenance पर लागू होने वाली पुरानी सावधानियाँ हर quant level पर बराबर लागू होती हैं: चोरी किए base से बना “uncensored” fine-tune Q8 में उतना ही ख़तरनाक है जितना वही weights Q4 में। इसके फ़ाइल-format पहलू के लिए देखें how to run GGUF models locally।

कौन सा level चुनें?

Q4_K_M, और उस पर forums पढ़ना बंद करें। Precision चाहने वाले काम के लिए VRAM अनुमति दे तो Q6_K, A/B तुलना के लिए एक Q8_0 पास रखें, और Q4 से नीचे किसी भी level को बड़े मॉडलों की आपातकालीन राशन समझें। एक ग़लती जो टालने लायक़ है, वह सममित है: Q4-बनाम-Q5 पर सिर खपाना और context length को भूल जाना — जिसने अब तक जितनी local setups बिगाड़ी हैं, वह किसी quant ने नहीं कीं।