Key Takeaways
- يحوّل التكميم أوزان النموذج من 16 بت إلى 4 أو 8 بت، مقلِّصاً RAM بنسبة 50–75%.
- Q4_K_M هو المستوى القياسي الموصى به — أفضل توازن بين الجودة وRAM للعتاد الاستهلاكي.
- نموذج 7B بصيغة FP16 = ~14 GB من RAM. بصيغة Q4_K_M = ~4.5 GB. بصيغة Q8_0 = ~7 GB.
- فقدان الجودة في Q4_K_M يبلغ 1–3% في اختبارات MMLU مقابل FP16 — غير محسوس في معظم المهام العملية.
- GGUF هي صيغة الملف التي تخزّن النماذج المكمَّمة لـ llama.cpp وOllama وLM Studio.
ما هو تكميم LLM ولماذا يهم؟
يحوّل التكميم أوزان النموذج من 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؟
Q4_K_M هي صيغة تكميم GGUF بـ 4 بت تُستخدم في llama.cpp وOllama. الحرف "K" يعني أنها تستخدم K-quants (دقة مختلطة)، و"M" = متوسط — توازن بين حجم النموذج والسرعة وفقدان الجودة. تخزّن Q4_K_M معظم الأوزان بـ 4 بت لكنها تستخدم 6 بت للطبقات الأكثر حساسية، مما يمنحها نسبة جودة/حجم أفضل من Q4_0 الخالص بـ 4 بت.
- تستخدم Q4_K_M ~4.5 GB من RAM لنموذج 7B — أقل بنسبة 70% من FP16 — بفقدان جودة 1–3% فقط
- تطبّق K-quants دقة مختلفة على مجموعات أوزان مختلفة حسب حساسيتها (الأوزان المهمة تحصل على بتات أكثر)
- النسخة "M" هي النسخة القياسية الموصى بها (توجد أيضاً النسخة الأخف "S" والأثقل "L")
- Q4_K_M هي الخيار الافتراضي للعتاد الاستهلاكي بـ 6–16 GB من VRAM
- تعمل مع Ollama (`ollama run model:q4_k_m`) وLM Studio وllama.cpp
كيف تختلف Q4_K_M وQ5_K_M وQ8_0 والمستويات الأخرى؟
Q4_K_M بـ 4 بت هي التوصية القياسية — نحو 4.5 GB من RAM لنموذج 7B بفقدان جودة 1–3% فقط مقابل FP16. تتبع أسماء التكميم نمطاً: Q{بتات}_{نسخة}. عدد البتات هو دقة الأوزان؛ والنسخة تؤثر على كيفية تطبيق التكميم:
| المستوى | البتات | RAM (7B) | فقدان الجودة | متى تستخدم |
|---|---|---|---|---|
| Q2_K | 2 | ~2.7 GB | مرتفع | RAM < 4 GB، يقبل تدهور الجودة |
| Q3_K_S | 3 | ~3.3 GB | متوسط | RAM 4-5 GB |
| Q4_K_M | 4 | ~4.5 GB | منخفض (1-3%) | افتراضي لمعظم المستخدمين |
| Q5_K_M | 5 | ~5.7 GB | ضئيل (<1%) | 16 GB من RAM، جودة أفضل |
| Q6_K | 6 | ~6.6 GB | شبه معدوم | 16 GB من RAM، مهام البرمجة/الرياضيات |
| Q8_0 | 8 | ~7.7 GB | لا يُذكر | 16+ GB من RAM، أقصى جودة |
ما هو تكميم Q8_0؟
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 بت تحفظ بالفعل تقريباً كل المعلومات.
- تستخدم Q8_0 نحو 7.7 GB من RAM لنموذج 7B — أقل بنحو 45% من FP16 — مع فقدان جودة لا يُذكر
- الخيار الأفضل عند توفر 16+ GB من VRAM والرغبة في أقصى دقة (البرمجة، الرياضيات، الوكلاء)
- فائدة قابلة للقياس ضئيلة مقارنةً بـ Q6_K للمحادثة العامة، لكنها الخيار الأكثر أماناً عندما تكون الجودة هي الأهم
- شغّلها بـ `ollama run model:q8_0`، أو اختر ملف Q8_0 GGUF في LM Studio
Q4_0 مقابل Q4_K_M: أي صيغة 4 بت أفضل؟
اختر 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.
| الصيغة | الطريقة | RAM (7B) | الجودة | متى تختار |
|---|---|---|---|---|
| Q4_0 | 4 بت موحد (قديم) | ~4.0 GB | أسوأ بنحو 5-8% من Q4_K_M | فقط إذا لم تتوفر Q4_K_M |
| Q4_K_M | K-Quant، 4/6 بت مختلط | ~4.5 GB | فقدان 1-3% مقارنةً بـ FP16 | الافتراضي لمعظم المستخدمين |
Q4_K_M مقابل Q4_K_S: K-Quant متوسط مقابل صغير
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.
| الصيغة | المتغير | RAM (7B) | فقدان الجودة | متى تختار |
|---|---|---|---|---|
| Q4_K_S | صغير | ~4.1 GB | ~4-6% (صغير لكنه حقيقي) | تحتاج ~0.4 GB ليتسع في VRAM |
| Q4_K_M | متوسط | ~4.5 GB | 1-3% (متوازن) | الافتراضي — جودة أفضل مقابل ~0.4 GB إضافية |
Q8_0 مقابل Q4_K_M: هل تستحق 8 بت ضعف 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%. الفجوة غير ملحوظة في الاستخدام اليومي لكنها قد تهم في الاستدلال العددي الدقيق.
| الصيغة | البتات | RAM (7B) | فقدان الجودة | الأفضل لـ |
|---|---|---|---|---|
| Q4_K_M | ~4 | ~4.5 GB | 1-3% | 6-16 GB من VRAM، استخدام عام |
| Q8_0 | 8 | ~7.7 GB | <0.5% | 16+ GB من VRAM، برمجة/رياضيات/وكلاء |
Q8_0 مقابل Q8_K_XL: 8 بت قياسي مقابل ترقية ديناميكية
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 الإضافية متاحة مجاناً.
| الصيغة | النوع | الدقة | الجودة | متى تختار |
|---|---|---|---|---|
| Q8_0 | llama.cpp قياسي | 8 بت موحد | فقدان <0.5% مقابل FP16 | أقصى جودة، أدوات قياسية |
| Q8_K_XL | Unsloth Dynamic GGUF | 8 بت + ترقية الطبقات الرئيسية إلى 16 بت | شبه عديمة الفقدان (أكبر خيار 8 بت) | تريد آخر 0.5% من الدقة، VRAM فائض |
ما هي صيغة GGUF وكيف ترتبط بالتكميم؟
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.3 8B.
كم RAM يوفّر التكميم لأحجام نماذج مختلفة؟
| حجم النموذج | FP16 | Q8_0 | Q4_K_M | Q3_K_S |
|---|---|---|---|---|
| 3B | ~6 GB | ~3.8 GB | ~2 GB | ~1.6 GB |
| 7B | ~14 GB | ~7.7 GB | ~4.5 GB | ~3.3 GB |
| 13B | ~26 GB | ~14 GB | ~8.5 GB | ~6 GB |
| 34B | ~68 GB | ~36 GB | ~22 GB | ~16 GB |
| 70B | ~140 GB | ~70 GB | ~40 GB | ~30 GB |
كم من الجودة يُفقَد فعلاً مع التكميم؟
تفقد Q4_K_M 1–3% في اختبارات MMLU مقابل FP16 — غير محسوس في معظم المهام العملية. تفقد Q3_K_S 5–10% وهو ملحوظ في الرياضيات والاستدلال. يُقاس فقدان الجودة بالتكميم بمقارنة نتائج المعايير بين نسخ الدقة الكاملة والمكمَّمة. اعتباراً من أبريل 2026، النتائج الراسخة هي:
يقلّص التكميم استخدام الذاكرة لكنه قد يدهور جودة الردود. تعوّض الموجّهات المصممة جيداً ذلك: تقنيات مثل الأمثلة قليلة اللقطات وقيود المخرجات الصريحة تساعد النماذج المكمَّمة على الحفاظ على الدقة. راجع تقنيات هندسة الموجّهات للطرق التي تعمل عند أي مستوى تكميم.
- Q4_K_M مقابل FP16: تدهور 1–3% في MMLU. في نموذج 7B يحقق 73% في FP16، تحقق Q4_K_M 71–72%. في المهام العملية، هذا الفرق غير محسوس.
- Q3_K_S مقابل FP16: تدهور 5–10%. ملحوظ في الاستدلال المعقد والمهام الرياضية. نموذج يحل مسألة رياضية بشكل صحيح في FP16 قد يفشل في Q3_K_S.
- Q2_K مقابل FP16: تدهور 15–25%. فقدان جودة كبير في جميع أنواع المهام. استخدم فقط عندما يكون قيد RAM مطلقاً.
- Q8_0 مقابل FP16: تدهور أقل من 0.5% — مطابق أساساً لجميع الأغراض العملية.
- تستخدم نسخ K_M (K-Quant Medium) نهج دقة مختلطة يحافظ على الجودة أفضل من تكميم Q4_0 القديم بنفس عدد البتات. فضّل دائماً Q4_K_M على Q4_0 عند توفر كليهما.
أي تكميم يجب أن تستخدم؟ (شجرة قرار سريعة)
اختر حسب VRAM المتاحة لديك، وليس حسب حجم النموذج فقط. يوضّح الجدول التالي أي تكميم تختار لقيود عتاد مختلفة.
- لـ 6 GB من RAM (الأكثر شيوعاً في اللابتوب/الحاسوب المكتبي): استخدم Q4_K_M. نموذج 7B مكمَّم بصيغة Q4_K_M هو ~4.5 GB، تاركاً 1.5 GB لنظام التشغيل والمتصفح.
- لمهام البرمجة أو الرياضيات: استخدم Q5_K_M أو أعلى حتى لو كانت لديك ميزانية لـ Q4_K_M. تأثيرات التكميم (فقدان 1–3%) أكثر وضوحاً في الاستدلال الرقمي الدقيق. لإعداد برمجة معزول من طرف إلى طرف يدمج Q5_K_M Qwen3-Coder مع التشغيل دون إنترنت، راجع LLM برمجة محلي دون إنترنت.
- مقايضة التكميم + درجة الحرارة: نموذج Q4_K_M عند درجة حرارة 0.3 ينتج مخرجات أكثر حتمية من نموذج بدقة كاملة (FP16) عند درجة حرارة 1.0. للضبط المستقل، راجع درجة الحرارة وtop-p: تحكّم في إبداع الذكاء الاصطناعي.
- للمنزل الذكي والأجهزة الطرفية: Q4_K_M (4–8 GB من VRAM) هو النقطة المثالية للذكاء الاصطناعي المنزلي دائم التشغيل على حاسوب مصغر. راجع أفضل نماذج LLM المحلية للمنزل الذكي →.
| VRAM لديك | أفضل تكميم | حجم النموذج | الجودة |
|---|---|---|---|
| 4–6 GB | Q3_K_S أو Q4_K_M | 3B، 7B (Q4) | 7B (Q3) | فقدان 5–10% (Q3) | 1–3% (Q4) |
| 6–8 GB | Q4_K_M (موصى به) | 7B أصلي | فقدان 1–3% (غير محسوس) |
| 12–16 GB | Q5_K_M | 7B، 13B أصلي | فقدان <1% (ضئيل) |
| 24 GB (RTX 4090) | Q5_K_M أو Q6_K | 13B، 32B أصلي | Q4 + تفريغ لـ 70B | لا يُذكر <0.5% |
| 32 GB (RTX 5090) | Q5_K_M، Q6_K أو Q8_0 | 70B بصيغة Q4 (35 GB)، Q5 (43 GB) | فقدان 0–2% |
| 48+ GB (2× RTX 4090) | Q5_K_M أو Q8_0 | 70B أصلي بتقسيم الطبقات | لا يُذكر <0.5% |
LM Studio: كيفية اختيار التكميم في الواجهة
يعرض LM Studio (تطبيق سطح المكتب) نسخ التكميم المتاحة لكل تنزيل نموذج. عند البحث عن نموذج، سترى عدة خيارات GGUF: Q2_K، Q3_K_S، Q4_K_M، Q5_K_M، Q6_K، Q8_0.
الخطوة 1: افتح LM Studio ← انتقل إلى تبويب "النماذج المحلية". ابحث عن نموذج (مثلاً "Llama 3.3 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 النظام).
التفريغ: RAM في CPU كفائض
عندما تمتلئ VRAM، يمكن للنماذج تفريغ (نقل) الطبقات إلى RAM النظام. يقايض التفريغ السرعة بالسعة.
السيناريو: تشغيل نموذج 70B Q4 على RTX 4090 (24 GB). يحتاج النموذج 35 GB. مع التفريغ، يعمل بسرعة ~5-10 رموز/ث (80% نحو RAM).
التفريغ ملاذ أخير — يجعل الاستدلال غير عملي. استخدمه فقط للمعالجة الدفعية دون اتصال أو للتجريب.
# Ollama: enable offloading
export OLLAMA_NUM_GPU=0 # Disable GPU (force CPU)
ollama run llama3.3:70b
# vLLM: enable CPU offload (partial)
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--gpu-memory-utilization 0.7 \
--cpu-offload-gb 10 # Offload 10GB to RAMتقسيم الطبقات: التوزيع عبر عدة GPU
يمكن لمحركات الاستدلال الحديثة (vLLM، llama.cpp) تقسيم نموذج عبر عدة GPU تلقائياً. المزيد عن نماذج LLM المحلية متعددة GPU للإعدادات المتقدمة.
مثال: نموذج 70B مع 2× RTX 4090:
- دون تقسيم: مستحيل (يحتاج 40+ GB من VRAM في GPU واحدة).
- مع تقسيم: نصف أوزان النموذج في كل GPU. سرعة الاستدلال: ~100 رمز/ث (زمن التواصل ضئيل).
تقسيم الطبقات عملي لعمليات نشر الإنتاج وشفاف للمستخدم.
# vLLM: automatic tensor parallelism
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 2 # Split across 2 GPUs
# llama.cpp: multi-GPU support
ollama run llama3.3:70b # Auto-detects and splits across GPUsتكميم KV Cache: تقليل عبء ذاكرة السياق
يقلّص تكميم 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-q8_0` أو `--cache-type-f8` عند بدء الخادم.
المقايضات: لتكميم 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% عبئاً.
| التقنية | VRAM موفّرة | تأثير السرعة | تأثير الجودة |
|---|---|---|---|
| التكميم (Q4) | 50% | لا يوجد (±5%) | طفيف |
| التفريغ (RAM في CPU) | 60-80% | أبطأ بـ 5-10× | لا يوجد |
| تقسيم الطبقات (2 GPU) | غير متاح (يتيح نماذج أكبر) | أبطأ بـ 5-10% | لا يوجد |
| التكميم + التفريغ | 75-90% | أبطأ بـ 3-5× | طفيف |
Mac Studio M2 Ultra: 70B أصلي دون تفريغ
يشغّل Mac Studio M2 Ultra بذاكرة موحدة 192 GB نموذج Llama 3.3 70B بصيغة Q4 بشكل أصلي — دون تفريغ، دون تقسيم طبقات.
عرض نطاق الذاكرة الموحدة: يصل Mac Studio M2 Ultra إلى ذاكرة CPU وGPU بسرعة ~800 GB/ث. التفريغ إلى RAM DDR5 النظام محدود بـ ~90 GB/ث. تلغي هذه الميزة البالغة 9× عقوبة السرعة التي تجعل التفريغ غير عملي.
| الإعداد | النموذج | السرعة | التعقيد |
|---|---|---|---|
| 1× RTX 4090 + تفريغ | Llama 3.3 70B Q4 | 5–10 رموز/ث | متوسط |
| 2× RTX 4090 تقسيم طبقات | Llama 3.3 70B Q5 | ~100 رمز/ث | مرتفع |
| 1× RTX 5090 (32 GB) | Llama 3.3 70B Q4 | 10–12 رمز/ث | منخفض |
| Mac Studio M2 Ultra | Llama 3.3 70B Q4 | 35 رمز/ث | منخفض (توصيل وتشغيل) |
تكميم LLM: السياق الإقليمي
- الاتحاد الأوروبي (GDPR، المادة 44) — تتطلب عمليات نقل بيانات الذكاء الاصطناعي عبر الحدود قرارات كفاية أو بنوداً تعاقدية قياسية. يتيح تكميم Q4_K_M تشغيل نماذج 7B على أجهزة طرفية بسعة 8 GB، ملغياً تماماً استدعاءات واجهات السحابة من أطراف ثالثة. توصي AEPD الإسبانية وCNIL الفرنسية بالاستدلال المحلي لمعالجة الذكاء الاصطناعي عالية الخطورة بموجب المادة 22 من GDPR. نماذج Mistral وLlama المكمَّمة هي الخيارات المهيمنة في عمليات النشر المؤسسية في الاتحاد الأوروبي لهذا السبب.
- اليابان (إرشادات حوكمة الذكاء الاصطناعي من METI 2024) — تتطلب وزارة الاقتصاد والتجارة والصناعة اليابانية توثيق حوكمة الذكاء الاصطناعي لعمليات النشر المؤسسية. النماذج المكمَّمة على بنية تحتية محلية تلبّي متطلبات "القابلية للتحكم" من METI — تبقى أوزان النموذج في الموقع. يجعل تكميم Q4_K_M نماذج 13B-32B قابلة للتطبيق على خوادم الشركات بسعة 16-32 GB دون عناقيد GPU. Qwen3 وLlama 3 هما العائلتان الأكثر نشراً في البيئات المؤسسية اليابانية.
- الصين (لوائح الذكاء الاصطناعي التوليدي من CAC 2023) — تتطلب إدارة الفضاء السيبراني الصينية تقييمات أمان للذكاء الاصطناعي المنشور علناً وتوطين البيانات لبيانات المستخدمين. النماذج الصينية الأصلية المكمَّمة (Qwen3، Baichuan2، Yi) تعمل بالكامل على عتاد محلي، ملبيةً متطلبات التوطين من CAC. يقلّص تكميم Q4_K_M وQ5_K_M تكاليف العتاد بنسبة 60-70% مقابل FP16، مما يجعل الامتثال لـ CAC في الموقع قابلاً للتطبيق اقتصادياً للشركات المتوسطة.
ما الأخطاء الشائعة مع تكميم LLM؟
- تنزيل Q4_0 بدلاً من Q4_K_M — Q4_0 طريقة تكميم أقدم دون تحسينات K-Quant. Q4_K_M أفضل بنسبة 5-8% في الجودة بنفس استخدام RAM. عند توفر كليهما، اختر دائماً Q4_K_M.
- افتراض أن تكميماً أعلى يعني دائماً جودة أسوأ — رقم Q أعلى = بتات أكثر = جودة أفضل. Q8_0 أفضل من Q4_K_M. Q5_K_M أفضل من Q4_K_M. نموذج Q4_K_M بحجم 70B سيتفوق على نموذج Q8_0 بحجم 7B في معظم المهام.
- عدم التحقق من مساحة RAM الحرة قبل تحميل نموذج — حجم النموذج ليس المستهلك الوحيد لـ RAM. نظام التشغيل والمتصفح والتطبيقات الأخرى تستخدم RAM أيضاً. على جهاز بسعة 8 GB، نموذج 7B Q4_K_M بحجم 4.5 GB يترك 3.5 GB فقط لكل شيء آخر. القاعدة: حجم ملف النموذج + 2 GB عبء نظام التشغيل + 1 GB هامش = الحد الأدنى المطلوب من RAM.
الخطوات التالية
- كم سعة VRAM أحتاج؟ — طبّق معرفتك بالتحديد الدقيق على ميزانية VRAM →
- أفضل نماذج LLM بالمعالج فقط — أفضل النماذج المُدقَّقة للاستدلال على المعالج →
- أفضل النماذج مفتوحة المصدر على Ollama — الآن بعد أن فهمت مستويات التحديد، اختر نموذجاً →
الأسئلة الشائعة حول تكميم LLM
هل يستخدم Ollama أفضل تكميم تلقائياً؟
نعم — عند تشغيل `ollama pull llama3.1:8b`، ينزّل Ollama نسخة Q4_K_M افتراضياً. للحصول على تكميم محدد، أضف الوسم: `ollama pull llama3.1:8b-instruct-q5_K_M`. وسوم التكميم المتاحة لكل نموذج مدرجة في صفحة النموذج على ollama.com/library.
هل يمكنني تكميم نموذج بنفسي بدلاً من تنزيل نسخة مكمَّمة مسبقاً؟
نعم — يتضمن llama.cpp ثنائي `quantize` يحوّل ملفات GGUF إلى أي مستوى تكميم مدعوم. تستغرق العملية 5-30 دقيقة حسب حجم النموذج. ينبغي لمعظم المستخدمين تنزيل ملفات GGUF مكمَّمة مسبقاً من Hugging Face بدلاً من التكميم بأنفسهم، إذ تكون النتائج متكافئة.
هل يؤثر التكميم على نافذة سياق النموذج؟
لا — يؤثر التكميم فقط على دقة أوزان النموذج، وليس طول السياق. يدعم نموذج Llama 3.3 8B 128K رمز سواء كان مكمَّماً بصيغة Q4_K_M أو يعمل بـ FP16. مع ذلك، تتطلب معالجة سياقات أطول RAM أكثر بصرف النظر عن التكميم — معالجة سياق 64K رمز بنموذج 7B Q4_K_M قد تتطلب 10+ GB من RAM.
ما الفرق بين تكميم GGUF وGPTQ؟
GGUF (صيغة llama.cpp) وGPTQ نهجان مختلفان للتكميم. تستخدم GGUF K-Quants وتعمل على CPU وGPU. GPTQ لـ GPU فقط ويتطلب PyTorch. للاستدلال المحلي بـ Ollama أو LM Studio أو Jan AI، GGUF هي الصيغة الصحيحة. يُستخدم GPTQ مع أطر استدلال موجهة لـ GPU مثل AutoGPTQ وvLLM.
هل هناك فرق جودة بين نماذج Q4_K_M من مزوّدين مختلفين على Hugging Face؟
خوارزمية التكميم موحّدة في llama.cpp، لذا فإن تكميمات Q4_K_M من نفس النموذج الأساسي تكون شبه متطابقة بصرف النظر عمّن أنشأ ملف GGUF. مع ذلك، يطبّق بعض المزوّدين تعديلات إضافية (تكميم imatrix) تحسّن الجودة. الملفات الموصوفة كمكمَّمة بـ "imat" أو "importance matrix" عادةً أعلى جودة بنفس عدد البتات.
ما هو تكميم imatrix؟
يستخدم تكميم imatrix (مصفوفة الأهمية) بيانات معايرة لتخصيص مستويات دقة مختلفة لأوزان مختلفة حسب أهميتها لمخرجات النموذج. الأوزان التي تؤثر أكثر على التنبؤات تُكمَّم ببتات أكثر؛ والأقل أهمية تستخدم بتات أقل. النتيجة: جودة أفضل بنفس عدد البتات مقارنةً بالتكميم الموحد. تكميمات imatrix لـ Qwen3 أفضل بنسبة 2-4% من Q4_K_M القياسي.
ما الفرق بين Q4_K_M وQ4_K_S؟
كلاهما تكميم بـ 4 بت، لكن K_M (متوسط) وK_S (صغير) يختلفان في تخصيص الذاكرة لكل كتلة تكميم. تستخدم Q4_K_M بيانات وصفية أكثر لإعادة بناء جودة أفضل — عادةً 4.5-5 GB لنموذج 7B. Q4_K_S أكثر عنفاً — توفّر 300-400 MB مقارنةً بـ K_M لكن بفقدان جودة 3-5%. استخدم Q4_K_M ما لم تكن على عتاد محدود للغاية (< 4 GB من RAM).
ما الفرق بين Q8_0 وQ8_K_XL؟
Q8_0 هي صيغة 8 بت القياسية في llama.cpp — كل وزن بـ 8 بت، نحو 7.7 GB لنموذج 7B، بفقدان جودة أقل من 0.5% مقارنةً بـ FP16. Q8_K_XL ليست نوعاً جاهزاً في llama.cpp؛ إنها متغير GGUF "ديناميكي" (Dynamic) من Unsloth يحافظ على أساس 8 بت لكنه يرقّي الطبقات الأكثر حساسية (التضمينات والانتباه والمخرجات) إلى 16 بت، مقرّباً الجودة إلى FP16 الكامل بحجم ملف أكبر قليلاً. Q8_0 تكاد تكون عديمة الفقدان بالفعل لمعظم المستخدمين، لذا فإن Q8_K_XL تفيد فقط إذا كنت تحتاج إلى الجزء الأخير من النسبة المئوية من الدقة ولديك VRAM فائض. تختلف أحجام الملفات حسب النموذج — تحقق من الحجم في LM Studio أو على Hugging Face قبل التنزيل.
هل يمكنني التبديل بين مستويات التكميم دون إعادة تنزيل النموذج؟
لا — يتطلب التبديل بين مستويات التكميم تنزيل ملف GGUF مختلف أو إعادة تكميم النموذج الأساسي بنفسك. بمجرد تكميم نموذج إلى Q4_K_M، لا يمكنك تحويله مرة أخرى إلى Q5_K_M دون نموذج FP16 الأصلي. ينزّل معظم المستخدمين ملفات GGUF مكمَّمة مسبقاً من Hugging Face لمستوى التكميم المرغوب.
كيف يؤثر التكميم على سرعة الاستدلال؟
يزيد التكميم عادةً سرعة الاستدلال بنسبة 10-40% لأن تحميل ومعالجة أوزان 4 بت أسرع من الأعداد العشرية بـ 16 بت. يعمل نموذج 7B Q4_K_M بسرعة ~8-12 رمز/ث على CPU استهلاكي؛ نفس النموذج بـ FP16 يعمل بسرعة ~1-2 رمز/ث. مكاسب أداء GPU من التكميم أقل (أسرع بـ 5-15%) لأن وحدات GPU محسّنة بالفعل لحساب النقطة العائمة.
أي مستوى تكميم يستخدمه Ollama افتراضياً؟
يستخدم Ollama Q4_K_M افتراضياً لجميع النماذج في مكتبته. عند تشغيل `ollama pull llama3.1:8b`، تنزّل نسخة Q4_K_M. يوازن هذا الافتراضي جيداً بين الجودة ومتطلبات RAM لمعظم المستخدمين. للحصول على تكميم مختلف، أضف الوسم: `ollama pull llama3.1:8b:q5_k_m` أو `ollama pull llama3.1:8b:q8_0`.
هل يمكنني تشغيل Llama 3.3 70B على RTX 4090 واحدة؟
نعم، لكن ببطء. كمّم إلى Q4 (35 GB)، فرّغ 11 GB إلى RAM النظام. توقع 5-10 رموز/ث — بطيء جداً للمحادثة في الوقت الفعلي، جيد للمعالجة الدفعية. للاستدلال العملي لـ 70B: 2× RTX 4090 بتقسيم الطبقات (~100 رمز/ث) أو Mac Studio M2 Ultra (35 رمز/ث أصلي).
ما الفرق بين التكميم والتفريغ؟
يقلّص التكميم دقة أوزان النموذج بشكل دائم (FP16 ← Q4)، مقلِّصاً ملف النموذج. ينقل التفريغ طبقات النموذج من VRAM إلى RAM النظام أثناء التشغيل. للتكميم تأثير ضئيل على الجودة (±5%)؛ يسبب التفريغ تدهور سرعة بـ 5–10×. استخدم التكميم أولاً، والتفريغ كملاذ أخير.
هل يحتاج Mac Studio M2 Ultra إلى تكميم لنماذج 70B؟
تكميم خفيف فقط. تحتوي 192 GB من الذاكرة الموحدة على Llama 3.3 70B بصيغة Q4 (35 GB) بشكل أصلي — دون تفريغ أو تقسيم طبقات. بصيغة Q5، لا يزال 70B يتسع (44 GB). FP16 70B (140 GB) يتسع أيضاً لكنه يعمل أبطأ. Q4 هو النقطة المثالية لسير عمل 70B على Mac Studio.
أي مزيج من التقنيات أفضل لعتادي؟
RTX 4090 واحدة (24 GB): Q4 + تفريغ لـ 70B (بطيء). Q5 أصلي لـ 32B (سريع). 2× RTX 4090 (48 GB): Q5 + تقسيم طبقات لـ 70B (100 رمز/ث). RTX 5090 (32 GB): Q4 أصلي لـ 70B (10-12 رمز/ث). Mac Studio M2 Ultra (192 GB): Q4 أصلي لـ 70B (35 رمز/ث).
المصادر
- توثيق تكميم llama.cpp
- نقاش تقني حول K-Quants — PR الأصلي لـ K-Quant
- مواصفات صيغة GGUF
- Open LLM Leaderboard — اختبارات التكميم
سجل التحديثات
- 2026-05-17: تحديث العنوان ليعكس نية موجهة للقرار؛ المحتوى دون تغيير.