GGUF quantization: কোন level ব্যবহার করবেন?

ডিফল্টে নিন Q4_K_M; VRAM বাড়তি থাকলে আর শেষ কয়েক শতাংশ কোয়ালিটি দরকার হলে যান Q6_K বা Q8_0-তে। GGUF quantization মডেলের weight-গুলোকে 16 bit থেকে কমিয়ে রাখে — Q4_K_M প্রতি weight-এ মোটামুটি 4.85 bit রাখে, তাই একটি 7B মডেল ~14 GB থেকে নেমে আসে ~4.1 GB-এ, আর perplexity সাধারণত আসলের চেয়ে ১%-এরও কম খারাপ হয়। “কোন gguf quantization নেব” প্রশ্নের উত্তরটি এতটাই স্থির যে বিরক্তিকর — অনলাইনের বেশিরভাগ হইচই সেটাই ঢেকে রাখে। নিচে: quantization weight-কে আসলে কী করে, প্রতি level-এ কোয়ালিটির খরচ কত, সাইজের হিসাব নিজে কীভাবে করবেন, আর নিজের হার্ডওয়্যারে ক্ষতিটা মাপার একটি কমান্ড — অচেনা কারো বেঞ্চমার্কে বিশ্বাস না করে।

GGUF quantization আসলে কী করে?

মডেল ট্রেন হয় 16-bit floating point-এ (FP16 বা BF16): তার বিলিয়ন খানেক weight-এর প্রতিটিই 2-byte-এর সংখ্যা। Quantization প্রতিটি weight-কে কম bit-এ চেপে রাখে। সহজ পথ — প্রতিটি weight-কে 4-bit integer-এ ঘুরিয়ে লেখা — ছোট কিন্তু জরুরি মানগুলো ধ্বংস করে দেয়, তাই GGUF দুটি কৌশল ব্যবহার করে:

1. Block scaling। Weight-গুলো block-এ ভাগ হয় (সাধারণত ৩২টি), প্রতিটি block পায় নিজের scale factor। 4-bit মানগুলো ওই block-এর ভেতরের offset, তাই মানের বিস্তৃত পাল্লাটাই বেঁচে থাকে।
2. Importance-aware k-quants। Q4_K_M-এর “K” মানে scale-গুলোর super-block, সঙ্গে attention আর feed-forward layer-কে আলাদা করে আচরণ — কারণ দুটি compression সমান সহ্য করে না।

“I” পরিবার (IQ4_XS আর তার সাথীরা) আরও এক ধাপ এগোয় — image compression থেকে ধার করা information-theoretic codebook নিয়ে। একই ভাবনা, চমকে রাখা encoding: প্রতি weight-এ কম bit, একই রকম কোয়ালিটিতে; খরচ হলো কিছু backend-এ inference একটু ধীর।

বেশিরভাগ confusion আটকানোর একটি পরিষ্কারকথা: quantization বদলায় শুধু সংরক্ষিত weight-গুলো। Architecture, tokenizer, context handling — কিছুই স্পর্শ হয় না। একই মডেলের Q4 ফাইল আর Q8 ফাইল একই মডেল, ভিন্ন কোট পরা অবস্থায়।

Q4 বনাম Q8: বেশি quantization কি ভালো?

কারিগরিভাবে হ্যাঁ; অনুভবে না। llama.cpp-র নিজস্ব perplexity run-গুলো Llama মডেলে রেফারেন্স ধরলে: Q8_0 FP16-এর ~0.02%-এর ভেতরে থাকে — ব্যবহারিক যেকোনো উদ্দেশ্যে lossless। Q6_K প্রায় আলাদাই করা যায় না। Q4_K_M-এ perplexity বাড়ে মোটামুটি ১–২%, Q4_0-তে একটু বেশি, আর ছোট মডেলে Q2_K থেকেই সুসংগত উত্তর ভাঙতে শুরু করে।

সংখ্যাগুলো থেকে দুটি নিয়ম:

• মডেল বড় হলে quantization-এর জায়গাও বেশি। 70B মডেল Q2/Q3 অনেক ভালোভাবে সইতে পারে 7B-এর চেয়ে, কারণ বড় মডেলে অতিরিক্ততা বেশি। 7B-কে Q2-তে নেওয়া অঙ্গচ্ছেদ; 70B-কে Q3-তে নেওয়া দর্জির কাজ।
• কোয়ালিটির ফ্লোর বদলায় কাজের সঙ্গে। Chat Q4 সহ্য করে। নিখুঁত code generation, math, আর সূক্ষ্ম ডকুমেন্টের RAG quantization noise তাড়াতাড়ি ধরিয়ে দেয়। Q4 মডেল বারবার সূক্ষ্মভাবে ভুল কোড লিখলে মডেলকে দোষ দেওয়ার আগে একই মডেল Q6_K-তে টেস্ট করুন।

Level	Bit/weight	FP16-এর তুলনায় সাইজ	কোয়ালিটি হানি	কখন ব্যবহার করবেন
Q2_K	~3.4	~21%	Sub-13B-এ মারাত্মক	অন্য কিছুই আঁটে না, শুধু বড় মডেল
Q3_K_M	~3.9	~25%	লক্ষণীয়	VRAM কম, ≥14B মডেল
Q4_K_S	~4.6	~29%	কম	Q4_K_M আঁটছে না, পার্থক্য সামান্য
Q4_K_M	~4.85	~30%	~1% perplexity	ডিফল্ট। কোয়ালিটি/সাইজের সেরা ভারসাম্য
Q5_K_M	~5.7	~35%	~0.5%	VRAM আছে, কোয়ালিটি-সংবেদনশীল কাজ
Q6_K	~6.6	~41%	প্রায় শূন্য	Code/math, তখনও আরামে আঁটে
Q8_0	~8.5	~53%	বাস্তবে নেই	Reference run, fine-tune base
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M সামান্য বড়, backend i-quant সমর্থন করে

প্রতি level-এ কত VRAM লাগে?

টেবিল মুখস্থ করার বদলে সাইজের হিসাব নিজেই করুন — এক লাইন:

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

তারপর যোগ করুন সূত্রের বাইরের অংশগুলো: KV cache (context length-এর সঙ্গে বাড়ে — কয়েকশ MB থেকে একাধিক GB), activation, আর compute buffer। বাস্তব মার্জিন: “4.9 GB” মডেল 4k context-এ 6 GB কার্ড চায়, আর 16k-তে সেখানে টিকে থাকতে চায় flash-attention আর KV-cache quantization। Weight-ই শিরোনাম, পুরো বিল নয়।

কোন GGUF quantization নেবেন?

সিদ্ধান্তের ক্রম, মুখস্থ করার মতো কোনো ব্যতিক্রম নেই:

1. আগে context + KV বাজেট হিসাব করুন, তারপর weight। যে context ধরতে পারছেন না সেটিই বেশি ক্ষতিকর, সেই কোয়ালিটির চেয়ে যা আপনি মাপতেই পারবেন না।
2. ডিফল্ট করুন Q4_K_M। কমিউনিটির ডিফল্ট এটি কারণ ছাড়া নয় — সাইজের ৭০%-এ perplexity বাড়ে মাত্র ~১%। Ollama সহ প্রতিটি registry এটিই baseline হিসেবে দেয়।
3. Q6_K-তে উঠুন যখন কাজটি noise ক্ষমা করে না: code, math, extraction, pipeline-এ নিঃশব্দে খাইয়ে দেওয়া যেকোনো কিছু।
4. Q8_0 রাখুন শুধু reference-এর জন্য — A/B টেস্ট, quantization-এর ক্ষতি মাপা, বা fine-tune base। দৈনন্দিন চালানোর জন্য এটি কেনে শুধু আপনার VRAM sensor-এর একটু বাড়তি তাপ।
5. Q4-এর নিচে যান শুধু বাধ্য হয়ে, আর তাও শুধু বড় মডেলে। বিশ্বাস করার আগে জানা-কঠিন একটি prompt দিয়ে টেস্ট করুন।

Hugging Face-এ কোন ফাইল নামাবেন বাছাই করলে sharded split-এর বদলে একটাই Q4_K_M.gguf নিন — যদি না uploader শুধু split-ই দেয়; যন্ত্রাংশ কম, ঝামেলা কম। আর কোথায় চালাবেন ভাবলে, engine-এর প্রশ্নটি আলাদা: সেই অক্ষের জন্য দেখুন llama.cpp vs Ollama।

Quantization-এর ক্ষতি নিজে কীভাবে মাপবেন?

বেঞ্চমার্ক আলাদা হয়; আপনার prompt একই থাকে। llama.cpp একবার বিল্ড করুন, একই মডেলের দুটি level নামান, আর মাপুন 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 (কম = আসল মডেলের কাছাকাছি)
./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

# আর একই হার্ডওয়্যারে speed
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Q4_K_M-এর সংখ্যাটি Q8_0-এর চেয়ে সামান্যই খারাপ হবে — দশমিকের পর দু-এক ঘর — আর ফাইল ছোট হবে ~40%। আপনার downstream কাজ পার্থক্যটা বুঝতে না পারলে — আর বেশিরভাগ কাজ পারে না — উত্তর হাতেই আছে, কারো leaderboard পড়ার দরকার নেই।

Quantization কি privacy বা local-only দাবির ক্ষতি করে?

না — এটি weight-এর ওপর সাধারণ গণিত, পুরোটাই অফলাইনে, আর quantized ফাইল একই parameter-এর ছোট পাত্র মাত্র। লোকালে Q4_K_M চালালে লিক হয় ঠিক ততটাই (বা ততটাই কম) যতটা হয় full-precision মডেল লোকালে চালালে: মেশিন থেকে কিছুই বেরোয় না। Privacy-র প্রাসঙ্গিক চলক হলো inference কোথায় চলে, bit-এর মাপ নয়। Model provenance নিয়ে চেনা সতর্কতাগুলো প্রতিটি quant level-এই সমানভাবে খাটে: চুরি হওয়া base-এর Q8-এ “uncensored” fine-tune একই weight-এর Q4-এর চেয়ে নিরাপদ নয়। ফাইল-ফরম্যাটের দিকটির জন্য দেখুন how to run GGUF models locally।

কোন level বেছে নেবেন?

Q4_K_M, আর এ নিয়ে ফোরাম পড়া বন্ধ করুন। Precision-খুদে কাজের জন্য VRAM সাইতে Q6_K-তে উঠুন, A/B তুলনার জন্য একটি Q8_0 কাছে রাখুন, আর Q4-এর নিচের যেকোনো কিছুকে ধরুন শুধু বড় মডেলের জরুরি রেশন। এড়ানোর মতো একমাত্র ভুলটি দুই দিকেই: context length উপেক্ষা করে Q4-বনাম-Q5 নিয়ে দুশ্চিন্তা — context length যত local setup ভেঙেছে, যেকোনো quant-এর চেয়ে বেশি।