ضغط GGUF: أي مستوى تستخدم؟

اختر Q4_K_M افتراضيًا؛ وارتقِ إلى Q6_K أو Q8_0 حين تملك VRAM فائضة وتحتاج آخر نسبة من الجودة. ضغط GGUF يصغّر أوزان النموذج من 16 بت إلى أقل — يخزّن Q4_K_M نحو 4.85 بت لكل وزن، فيهبط نموذج 7B من ~14 جيجابايت إلى ~4.1 جيجابايت بإرتباكية أسوأ من الأصل بأقل من 1% عادة. سؤال “أي ضغط gguf أستخدم” جوابه مستقر ممل يحجبه معظم الدراما على الإنترنت. أدناه: ما يفعله الضغط بالأوزان فعلًا، وكم تكلف كل درجة من الجودة، وكيف تحسب الحجم بنفسك، وأمر واحد لقياس الضرر على عتادك أنت بدل تصديق مقياس غريب.

ماذا يفعل ضغط GGUF فعلًا؟

يُدرَّب النموذج بنقاط عائمة بـ 16 بت (FP16 أو BF16): كل وزن من مليارات أوزانه عدد من بايتين. يضغط الضغطُ كل وزن إلى بتات أقل. والطريقة الساذجة — تقريب كل وزن إلى عدد صحيح بـ 4 بت — تدمّر القيم الصغيرة المهمة، لذا يعتمد GGUF حيلتين:

1. قياس كتلي. تُجمع الأوزان في كتل (32 عادة)، ولكل كتلة معامل قياس خاص. القيم الـ 4 بت هي انزياحات داخل تلك الكتلة، فتنجو مدى واسع من المقدارات.
2. k-quants واعية بالأهمية. حرف “K” في Q4_K_M يعني كتلًا فائقة من المعاملات، مع معاملة طبقات الانتباه وطبقات التغذية الأمامية اختلافًا عن بعضها، لأنها لا تحتمل الضغط بالتساوي.

وتسير عائلة “I” (IQ4_XS وأخواتها) أبعد بمعاجم شيفرات مستمدة من نظرية المعلومات المستعارة من ضغط الصور. الفكرة نفسها بترميز أفخم: بتات أقل لكل وزن بجودة مشابهة، ثمنًا لاستدلال أبطأ قليلًا في بعض الخلفيات.

وتوضيح يمنع معظم الالتباس: الضغط يغيّر الأوزان المخزنة فقط. المعمارية والمقطّع ومعالجة السياق لم تُلمس. ملف Q4 وملف Q8 للنموذج نفسه هما النموذج نفسه بمعطفين مختلفين.

Q4 مقابل Q8: هل الضغط الأعلى أفضل؟

نعم تقنيًا؛ لا إدراكيًا. باستخدام قياسات الإرتباكية الخاصة بـ llama.cpp على نماذج Llama مرجعًا: تهبط Q8_0 ضمن ~0.02% من FP16 — بلا فقد لأي غرض عملي. وQ6_K بالكاد يمكن تمييزها. وتربح Q4_K_M نحو 1–2% إرتباكية، وQ4_0 أكثر قليلًا، وعند Q2_K تبدأ الإجابات المتماسكة بالتفكك في النماذج الصغيرة.

قاعدتان تنطيران بهما الأرقام:

• حجم النموذج يشتري هامش ضغط. ينجو نموذج 70B من Q2/Q3 أفضل بكثير من نموذج 7B، لأن النماذج الأكبر زائدة عن الحاجة. ضغط 7B إلى Q2 بتر؛ وضغط 70B إلى Q3 خياطة.
• أرضية الجودة تتحرك مع المهمة. الدردشة تتساهل مع Q4. أما توليد الكود الدقيق والرياضيات وRAG فوق مستندات دقيقة فتكشف ضجيج الضغط أسرع. إذا ظل نموذج Q4 يكتب كودًا خاطئًا بمهارة، فاختبر النموذج نفسه عند Q6_K قبل أن تلوم النموذج.

المستوى	بت لكل وزن	الحجم مقابل FP16	فقد الجودة	استخدمه حين
Q2_K	~3.4	~21%	حاد تحت 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% إرتباكية	الافتراضي. أفضل مقايضة جودة/حجم
Q5_K_M	~5.7	~35%	~0.5%	VRAM متاحة، مهام حساسة للجودة
Q6_K	~6.6	~41%	يكاد يعدم	كود/رياضيات، ما يزال يتسع براحة
Q8_0	~8.5	~53%	لا شيء فعليًا	جولات مرجعية، قواعد ضبط دقيق
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M أكبر قليلًا من اللازم والخلفية تدعم i-quants

كم جيجابايت 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 (ينمو مع طول السياق — من بضع مئات ميغابايت إلى عدة جيجابايت)، والتنشيطات، وبافرات الحساب. الهامش العملي: نموذج “4.9 جيجابايت” يريد بطاقة 6 جيجابايت عند سياق 4k، مع flash-attention وضغط KV cache ليبقى هناك عند 16k. الأوزان هي العنوان، لا الفاتورة كلها.

أي ضغط GGUF تستخدم؟

ترتيب القرار، بلا استثناءات تستحق الحفظ:

1. احسب ميزانية السياق + KV أولًا ثم الأوزان. السياق الذي لا يتسع أسوأ من جودة لا تستطيع قياسها.
2. اعتمد Q4_K_M افتراضيًا. إنه افتراضي المجتمع لسبب — نحو 1% إرتباكية مقابل 70% من الحجم. وكل سجل، بما فيه Ollama، يشحنه خط أساس.
3. ارتقِ إلى Q6_K حين تعاقب المهمة على الضجيج: كود، رياضيات، استخراج، أي شيء تمرره إلى مسار بلا إشراف.
4. استخدم Q8_0 للمرجعية فقط — اختبارات A/B، قياس ضرر الضغط، أو قاعدة ضبط دقيق. وكأداة يومية يشتري دفئًا في حساسات VRAM لديك بالأساس.
5. انزل تحت Q4 تحت الإجبار فقط، وعلى النماذج الكبيرة وحدها. اختبره ببصمة استعلام معروفة الصعوبة قبل الاعتماد عليه.

وإذا كنت تختار الملف الذي تنزله من Hugging Face، فضّل ملف Q4_K_M.gguf واحدًا على التوزيعات المجزأة ما لم يكن الرافع يشحن الأخيرة وحدها — أجزاء متحركة أقل. وإذا كنت تختار أين تشغّله، فاختيار المحرك مسألة مستقلة: انظر llama.cpp مقابل Ollama لذلك المحور.

كيف تقيس ضرر الضغط بنفسك؟

المقاييس تختلف؛ استعلامك ثابت. ابنِ llama.cpp مرة، ونزّل مستويين من النموذج نفسه، وقِس الإرتباكية (الأقل أفضل) وtoken في الثانية:

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 (الأقل = أقرب إلى النموذج الأصلي)
./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 بأجزاء من نقطة، والملف أصغر بنحو 40%. وإذا لم تستطع مهمتك اللاحقة تمييز الفرق — ومعظم المهام لا تستطيع — فقد حصلت على جوابك دون قراءة لوحة شرف أحد.

هل يضر الضغط بالخصوصية وادعاءات العمل المحلي؟

لا — إنه حساب على الأوزان، بمعزل تمام عن الشبكة، والملف المضغوط مجرد وعاء أصغر للبارامترات نفسها. تشغيل Q4_K_M محليًا يسرّب بالضبط ما يسرّبه (أو يكتمه) تشغيل النموذج بدقة كاملة محليًا: لا شيء يغادر الجهاز. المتغير ذو الصلة بالخصوصية هو أين يجري الاستدلال لا عرض البت. وتنبيهات مصدر النموذج المعتادة تنطبق على كل درجة ضغط بالتساوي: fine-tune “غير خاضع للرقابة” من قاعدة مسروقة بصيغة Q8 ليس أأمن من الأوزان نفسها بصيغة Q4. ولجانب صيغة الملف، انظر كيف تشغّل نماذج GGUF محليًا.

فأي مستوى تختار؟

Q4_K_M، وتوقف عن قراءة المنتديات حوله. ارتقِ إلى Q6_K للعمل العطشى للدقة إن سمحت VRAM، وأبقِ Q8_0 واحدة في الجيب لمقارنات A/B، وعامل كل ما دون Q4 كحصة طوارئ للنماذج الكبيرة وحدها. والخطأ الوحيد المستحق التجنب متماثل: القلق حول Q4-مقابل-Q5 مع تجاهل طول السياق، الذي أحطّ إعدادات محلية أكثر مما أحط أي ضغط قط.