شرح تكميم ⁨LLM⁩: ⁨Q4⁩_⁨K⁩_⁨M⁩ مقابل ⁨Q4⁩_⁨0⁩ مقابل ⁨Q8⁩_⁨0⁩ (⁨2026⁩)

يحوّل التكميم أوزان النموذج من 16 بت (FP16) إلى أعداد صحيحة بـ 4 أو 8 بت، مقلِّصاً RAM بنسبة 50–75% بفقدان جودة 1–3% فقط في Q4_K_M. يخزّن نموذج اللغة الكبير معرفته المكتسبة كمليارات الأوزان الرقمية. افتراضياً، تُخزَّن هذه كأعداد عشرية بـ 16 بت (FP16) — بايتان لكل وزن. نموذج 7B يملك 7 مليارات وزن، لذا حجم ملف FP16 نحو 14 GB.

يستبدل التكميم هذه الأعداد العشرية بـ 16 بت بأعداد صحيحة أقل دقة. مع التكميم بـ 4 بت، يستخدم كل وزن 0.5 بايت بدلاً من 2 — مقلِّصاً الذاكرة إلى ~3.5 GB للأوزان وحدها. مع عبء البيانات الوصفية، نموذج 7B مكمَّم بصيغة Q4_K_M نحو 4.5 GB.

يهم هذا للاستدلال المحلي لأن العتاد الاستهلاكي يملك RAM محدودة. دون تكميم، يتطلب نموذج 7B 16 GB من RAM للتشغيل. مع تكميم Q4_K_M، يعمل نفس النموذج بـ 6 GB من RAM، مما يجعله متاحاً على معظم أجهزة اللابتوب الحديثة.

Q4_K_M هي صيغة تكميم GGUF بـ 4 بت تُستخدم في llama.cpp وOllama. الحرف "K" يعني أنها تستخدم K-quants (دقة مختلطة)، و"M" = متوسط — توازن بين حجم النموذج والسرعة وفقدان الجودة. تخزّن Q4_K_M معظم الأوزان بـ 4 بت لكنها تستخدم 6 بت للطبقات الأكثر حساسية، مما يمنحها نسبة جودة/حجم أفضل من Q4_0 الخالص بـ 4 بت.

Q4_K_M بـ 4 بت هي التوصية القياسية — نحو 4.5 GB من RAM لنموذج 7B بفقدان جودة 1–3% فقط مقابل FP16. تتبع أسماء التكميم نمطاً: Q{بتات}_{نسخة}. عدد البتات هو دقة الأوزان؛ والنسخة تؤثر على كيفية تطبيق التكميم:

استخدم هذه الحاسبة لحساب متطلبات VRAM الدقيقة لأي مجموعة نموذج، وتكميم، وسياق، وحجم دفعة. اختر تكوينك وتحقق من وحدات GPU المتوافقة.

Q8_0 هي صيغة تكميم GGUF بـ 8 بت تكاد تكون عديمة الفقدان — أقل من 0.5% تدهور في الجودة مقارنةً بـ FP16 — بنحو نصف حجم الملف. يُخزَّن كل وزن في 8 بت بالإضافة إلى مقياس صغير لكل كتلة، لذا يبلغ حجم نموذج 7B نحو 7.7 GB بدلاً من ~14 GB بصيغة FP16. على عكس K-Quants (Q4_K_M وQ5_K_M)، تستخدم Q8_0 دقة موحدة بـ 8 بت لكل وزن — لا يوجد متغير "K" بدقة مختلطة لأن 8 بت تحفظ بالفعل تقريباً كل المعلومات.

اختر Q4_K_M بدلاً من Q4_0. كلاهما يبلغ متوسطه 4 بت لكل وزن، لكن Q4_K_M هي K-Quant تخزّن الطبقات الأكثر حساسية بـ 6 بت، مستعيدةً 5-8% من الجودة بنفس البصمة البالغة ~4.5 GB لنموذج 7B. Q4_0 هي صيغة 4 بت الموحدة الأصلية من llama.cpp المبكر وتوجد اليوم فقط للتوافق القديم. لا يوجد سبب يتعلق بالحجم أو السرعة لاختيار Q4_0 عند توفر Q4_K_M.

‏Q4_K_M هو الكمّ القياسي بأربع بتات في llama.cpp. أما Q4_K_XL فليس نوعًا قياسيًا، بل صيغة GGUF من نوع "Dynamic" من Unsloth تحافظ على أساس أربع بتات لكنها ترفع دقة أكثر الطبقات حساسية (التضمين والانتباه والمخرجات). يقع حجم الملف والجودة بين Q4_K_M وQ5_K_M — وهو المبدأ نفسه الذي يطبقه Q8_K_XL على Q8_0، لكن على أساس أربع بتات.

تختلف أحجام ملفات Q4_K_XL بحسب النموذج وبحسب عدد الطبقات التي ترفعها Unsloth، لذا تحقق من الحجم المعروض في LM Studio أو على Hugging Face قبل التنزيل بدل الاعتماد على رقم ثابت. القاعدة العملية: إذا كان Q5_K_M يتّسع في ذاكرة VRAM لديك فاختره، لأنه صيغة قياسية بدعم أوسع من الأدوات. أما Q4_K_XL فهو الخطوة الوسطى حين يتّسع Q4_K_M ولا يتّسع Q5_K_M إلا بفارق ضئيل.

Q4_K_M وQ4_K_S كلاهما K-Quant بـ 4 بت؛ يكمن الفرق في عدد الطبقات التي تبقى بدقة أعلى. تحافظ Q4_K_M (متوسط) على مزيد من الطبقات الحساسة بـ 6 بت، بينما تدفع Q4_K_S (صغير) مزيداً من الأوزان إلى 4 بت لتوفير ~0.3-0.4 GB في نموذج 7B. عند قياسها على llama.cpp، تضيف Q4_K_S نحو +0.11 من الحيرة (perplexity) عند 7B مقابل +0.05 لـ Q4_K_M — أي نحو 3-5% فقدان جودة إضافي. اختر Q4_K_S فقط عندما تحدد تلك المئات القليلة من الميغابايت ما إذا كان النموذج يتسع في VRAM.

لمعظم مهام المحادثة والكتابة، Q4_K_M هي المفاضلة الأفضل — تستخدم ~4.5 GB لنموذج 7B مقابل ~7.7 GB لـ Q8_0، بفقدان جودة إضافي يبلغ 1-3% فقط. اختر Q8_0 (تتطلب 16+ GB من VRAM) عندما تحتاج إلى أقصى دقة للبرمجة أو الرياضيات أو استخدام الأدوات الوكيلية، حيث تتراكم الأخطاء الصغيرة. تفقد Q8_0 أقل من 0.5% مقارنةً بـ FP16؛ وتفقد Q4_K_M 1-3%. الفجوة غير ملحوظة في الاستخدام اليومي لكنها قد تهم في الاستدلال العددي الدقيق.

Q8_0 هي صيغة 8 بت القياسية في llama.cpp — كل وزن بـ 8 بت، ~7.7 GB لنموذج 7B، بفقدان أقل من 0.5% مقارنةً بـ FP16. Q8_K_XL ليست نوعاً جاهزاً في llama.cpp: إنها متغير GGUF "ديناميكي" (Dynamic) من Unsloth يحافظ على أساس 8 بت لكنه يرقّي الطبقات الأكثر حساسية (التضمينات والانتباه والمخرجات) إلى 16 بت (BF16/F16)، مقرّباً الجودة إلى FP16 الكامل بحجم ملف أكبر قليلاً. تستهدف Q8_K_XL المستخدمين الذين يريدون الجزء الأخير من النسبة المئوية من الدقة ولديهم VRAM فائض.

تختلف أحجام ملفات Q8_K_XL الدقيقة حسب النموذج وعدد الطبقات التي ترقّيها Unsloth، لذا تحقق من الحجم المعروض في أداتك (LM Studio أو Hugging Face) قبل التنزيل. لنموذج 7B-8B توقع أن يكون أعلى قليلاً من Q8_0؛ وعلى النماذج الكبيرة جداً تكون الفجوة أوسع. بما أن Q8_0 تكاد تكون عديمة الفقدان بالفعل لمعظم المستخدمين، فإن Q8_K_XL تستحق العناء فقط عندما تحتاج تحديداً إلى أقصى دقة وتكون VRAM الإضافية متاحة مجاناً.

GGUF (GPT-Generated Unified Format) هي معيار الملف الواحد لأوزان LLM المكمَّمة، يحتوي على أوزان النموذج والبيانات الوصفية والمُرمِّز — تستخدمها Ollama وLM Studio وllama.cpp. أنشأها مشروع llama.cpp وتحل محل صيغة GGML الأقدم.

يحتوي ملف GGUF على: أوزان النموذج المكمَّمة، وجميع البيانات الوصفية للنموذج (البنية، المُرمِّز، طول السياق)، ورقم إصدار الصيغة. يعني هذا التصميم المكتفي ذاتياً أن ملف `.gguf` واحد هو كل ما يلزم لتشغيل النموذج — دون ملفات مُرمِّز منفصلة، دون JSON إعداد.

اعتباراً من أغسطس 2026، GGUF هي الصيغة القياسية لـ Ollama وLM Studio وJan AI وGPT4All. عند تشغيل `ollama pull llama3.1:8b`، ينزّل Ollama داخلياً ملف GGUF. عندما يعرض LM Studio أحجام ملفات النماذج، فتلك أحجام ملفات GGUF.

مستوى التكميم جزء من اسم الملف: `Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf` هو GGUF مكمَّم بصيغة Q4_K_M من Llama 3.1 8B.

تفقد Q4_K_M 1–3% في اختبارات MMLU مقابل FP16 — غير محسوس في معظم المهام العملية. تفقد Q3_K_S 5–10% وهو ملحوظ في الرياضيات والاستدلال. يُقاس فقدان الجودة بالتكميم بمقارنة نتائج المعايير بين نسخ الدقة الكاملة والمكمَّمة. اعتباراً من أغسطس 2026، النتائج الراسخة هي:

يقلّص التكميم استخدام الذاكرة لكنه قد يدهور جودة الردود. تعوّض الموجّهات المصممة جيداً ذلك: تقنيات مثل الأمثلة قليلة اللقطات وقيود المخرجات الصريحة تساعد النماذج المكمَّمة على الحفاظ على الدقة. راجع تقنيات هندسة الموجّهات للطرق التي تعمل عند أي مستوى تكميم.

اختر حسب VRAM المتاحة لديك، وليس حسب حجم النموذج فقط. يوضّح الجدول التالي أي تكميم تختار لقيود عتاد مختلفة.

يعرض LM Studio (تطبيق سطح المكتب) نسخ التكميم المتاحة لكل تنزيل نموذج. عند البحث عن نموذج، سترى عدة خيارات GGUF: Q2_K، Q3_K_S، Q4_K_M، Q5_K_M، Q6_K، Q8_0.

الخطوة 1: افتح LM Studio ← انتقل إلى تبويب "النماذج المحلية". ابحث عن نموذج (مثلاً "Llama 3.1 8B"). الخطوة 2: يعرض كل نموذج التكميمات المتاحة. لاحظ حجم الملف لتقدير استخدام VRAM. Q4_K_M لنموذج 7B يظهر عادةً كـ ~4.5 GB. الخطوة 3: انقر أيقونة التنزيل بجانب التكميم المختار.

القيم الافتراضية الموصى بها لـ LM Studio:

• إذا كانت GPU لديك بسعة 6-8 GB من VRAM (RTX 4060، RTX 3060 Ti، RTX 4060 Ti): نزّل نسخة Q4_K_M (أصغر ملف بجودة مقبولة).

• إذا كانت GPU لديك بسعة 12-16 GB من VRAM (RTX 4070، RTX 4080): نزّل Q5_K_M أو Q6_K (جودة أفضل، لا تزال ضمن VRAM).

• إذا كانت GPU لديك بسعة 24+ GB من VRAM (RTX 4090، RTX 5090): نزّل Q8_0 أو FP16 (أقصى جودة، عقوبة سرعة ضئيلة).

خاصية "GPU offload" في LM Studio: فعّل مفتاح "استخدام GPU" في واجهة المحادثة. سينقل LM Studio تلقائياً أكبر قدر ممكن من طبقات النموذج إلى GPU، تاركاً البقية في RAM في CPU. إذا كانت RAM النظام كافية، يتيح هذا تشغيل نماذج أكبر قليلاً من VRAM في GPU (مثلاً Llama 3.3 70B Q4_K_M على RTX 4090 مع 64+ GB من RAM النظام).

عندما تمتلئ VRAM، يمكن للنماذج تفريغ (نقل) الطبقات إلى RAM النظام. يقايض التفريغ السرعة بالسعة.

السيناريو: تشغيل نموذج 70B Q4 على RTX 4090 (24 GB). يحتاج النموذج 35 GB. مع التفريغ، يعمل بسرعة ~5-10 رموز/ث (80% نحو RAM).

التفريغ ملاذ أخير — يجعل الاستدلال غير عملي. استخدمه فقط للمعالجة الدفعية دون اتصال أو للتجريب.

يمكن لمحركات الاستدلال الحديثة (vLLM، llama.cpp) تقسيم نموذج عبر عدة GPU تلقائياً. المزيد عن نماذج LLM المحلية متعددة GPU للإعدادات المتقدمة.

مثال: نموذج 70B مع 2× RTX 4090:

• دون تقسيم: مستحيل (يحتاج 40+ GB من VRAM في GPU واحدة).

• مع تقسيم: نصف أوزان النموذج في كل GPU. سرعة الاستدلال: ~100 رمز/ث (زمن التواصل ضئيل).

تقسيم الطبقات عملي لعمليات نشر الإنتاج وشفاف للمستخدم.

يقلّص تكميم KV Cache الذاكرة اللازمة لتخزين أزواج الانتباه مفتاح-قيمة أثناء الاستدلال، وهو مهم بشكل خاص عند معالجة السياقات الطويلة (32K+ رمز). بينما تكميم أوزان النموذج (Q4_K_M) هو الأكثر شيوعاً، يستهدف تكميم KV Cache اختناق ذاكرة مختلف.

أثناء الاستدلال، يحافظ النموذج على أزواج مفتاح-قيمة (KV) جارية لكل رمز في السياق. لنموذج 7B يعالج سياق 32K رمز، قد تستهلك KV cache وحدها 8–16 GB من VRAM حسب الدقة. تستخدم KV cache القياسية FP16 (2 بايت لكل قيمة)؛ تكميم KV cache إلى FP8 أو Q8 يقلّصها بنسبة 50%.

كيفية تفعيل تكميم KV Cache:

• Ollama: تلقائي في النماذج المتوافقة؛ دون حاجة لإعداد المستخدم.

• LM Studio: فعّل مفتاح "KV cache quantization" في الإعدادات (إن توفر في نسختك).

• llama.cpp: شغّل الخادم باستخدام `--cache-type-k q8_0 --cache-type-v q8_0` (الصيغة المختصرة: `-ctk q8_0 -ctv q8_0`). واستخدم `q4_0` بدل `q8_0` لتقليص ذاكرة KV إلى النصف مجددًا.

المقايضات: لتكميم KV Cache تأثير ضئيل على الجودة (<1% تدهور حتى مع تكميم عنيف) لأن أنماط الانتباه أكثر متانة عند الدقة الأقل من أوزان النموذج. موصى به للنماذج التي تعالج سياقات 16K+ على عتاد محدود.

تأتي أفضل النتائج من دمج التقنيات الثلاث. راجع دليل متطلبات VRAM للتخطيط الخاص بالعتاد.

السيناريو 1: 70B على RTX 4090 واحدة (24 GB)

• كمّم إلى Q4 (35 GB ← 18 GB)

• استخدم التفريغ للـ 6 GB المتبقية (إلى RAM النظام)

• النتيجة: ~8-10 رموز/ث (بطيء لكنه يعمل)

السيناريو 2: 70B على 2× RTX 4090

• كمّم إلى Q5 (43.75 GB)

• استخدم تقسيم الطبقات عبر 2 GPU (22 GB لكل منها)

• النتيجة: ~100 رمز/ث (عملي)

تقايض كل تقنية تقليل VRAM بعقوبات السرعة. للتكميم تأثير ضئيل؛ يسبب التفريغ تباطؤاً بـ 5–10×؛ ويضيف تقسيم الطبقات ~5% عبئاً.

يشغّل Mac Studio بمعالج M5 Ultra (يبدأ من $5,499 مع 96 GB ذاكرة موحدة، ويصل إلى 512 GB) نموذج Llama 3.3 70B بصيغة Q4 بشكل أصلي — دون تفريغ، دون تقسيم طبقات.

جدّدت Apple تشكيلة Mac Studio في 25 أغسطس 2026 بمعالجين: M5 Max ($2,499، حتى 128 GB ذاكرة موحدة، حتى 614 GB/ث وفق مواصفات Apple الرسمية) وM5 Ultra ($5,499 بدءاً من 96 GB وحتى 512 GB، بسرعة تصل إلى 1.2 TB/ث وفق مواصفات Apple). يحل الاثنان محل جيل M2 Ultra السابق (192 GB كحد أقصى، ~800 GB/ث). لا يزال التفريغ إلى RAM DDR5 النظام محدوداً بـ ~90 GB/ث -- وهذه الفجوة في عرض النطاق هي سبب تفوق الذاكرة الموحدة على التفريغ في نماذج بحجم 70B.

لا تتوفر بعد اختبارات أداء مستقلة لمعالجي M5 Max وM5 Ultra. تُطرح التشكيلات القياسية للبيع في 22 سبتمبر 2026، فيما تصل نسخة M5 Ultra بسعة 512 GB في أواخر أكتوبر 2026. لم تختبر PromptQuorum هذا العتاد -- لذلك تُحذف أرقام الرموز في الثانية للمعالجين الجديدين حتى تتوفر قياسات مستقلة.