دليل تكميم نماذج LLM: مقارنة بين 7 طرق (مع أرقام القياس الفعلية)

دليل تكميم نماذج LLM: مقارنة بين 7 طرق (مع أرقام القياس الفعلية)

نموذج Llama 3.3 70B بصيغة FP16 يحتاج 140 GB للأوزان وحدها. أي بطاقتَي H100. وعند مستوى Q4_K_M يتسع النموذج نفسه في نحو 42 GB، أي بطاقة RTX A6000 مستعملة واحدة تشتريها من eBay. هذه الفجوة هي السبب الكامل لوجود تكميم LLM، واختيار الطريقة الخاطئة سيكلّفك إما جودة تلاحظها بعينك، أو ذاكرة VRAM لا تملكها.

يقارن دليل تكميم LLM هذا بين الطرق السبع التي تهمّك في 2026، وكل رقم فيه يعود إلى مصدر منشور يمكن تتبّعه.

أهم الخلاصات

• التكميم يستبدل الذاكرة وعرض النطاق بتراجع في الجودة قابل للقياس، وصغير في العادة.
• GPTQ وAWQ موجّهتان لوحدة GPU أولًا، بينما GGUF هو التنسيق الذي يعمل على CPU أيضًا.
• Q4_K_M يصل فعليًا إلى نحو 4.8 بت لكل وزن، لا 4. التسمية تُخفي هذه الحمولة الزائدة.
• تكميم 6-bit يبقى في حدود 0.1% تقريبًا من حيرة FP16، وفق طلب الدمج الخاص بـk-quants في llama.cpp.

ما الذي يفعله تكميم LLM بنموذجك فعليًا؟

يخزّن تكميم LLM أوزان النموذج بدقة رقمية أدنى، فيقلّص الذاكرة وعرض النطاق مقابل خطأ تقريب. نموذج بسبعين مليار معلمة يهبط من 140 GB بصيغة FP16 إلى نحو 42 GB عند 4-bit. الذكاء يبقى، وعلامات العشرية هي التي تذهب. وكل طريقة في هذا الدليل هي تنويعة على هذه المقايضة نفسها.

سلّم الدقة تهبط درجاته هكذا: FP32 (32 بت)، ثم FP16 وBF16 (16 بت لكل منهما)، ثم INT8، ثم INT4. وكل درجة تنصّف عدد البايتات لكل معلمة. تحدد معيارية IEEE 754 صيغ الأعداد العشرية، وأظهرت ورقة Mark Horowitz عام 2014 بعنوان "Computing's Energy Problem" لماذا يهيمن نقل هذه البايتات، لا العمليات الحسابية عليها، على كلفة الطاقة. وهذا هو السبب الفيزيائي الذي يجعل التكميم يسرّع الاستدلال.

معلمتان تجعل التكميم يعمل: معامل القياس (مضاعف يعيد مجال الأعداد الصحيحة إلى القيم الحقيقية) ونقطة الصفر (العدد الصحيح الذي يمثّل القيمة 0.0). التكميم المتماثل يجعل منتصف المجال عند الصفر ويتخلى عن نقطة الصفر، أما التكميم غير المتماثل فيُزيح المجال ليستغل كامل نطاق الأعداد الصحيحة حين تتجمع الأوزان بعيدًا عن الصفر.

الأوزان تُكمَّم بسلاسة لأنها ثابتة وموزعة توزيعًا طبيعيًا. أما التنشيطات فلا. القيم الشاذة في التنشيطات، التي قد تبلغ 100 ضعف الوسيط أحيانًا، تفجّر خطأ التقريب إن كمّمتها بسذاجة. وهذا عدم التماثل هو سبب اكتفاء معظم الطرق هنا بتكميم الأوزان فقط (W4A16) وترك التنشيطات بصيغة FP16.

التكميم بعد التدريب (PTQ) يحوّل نموذجًا مكتملًا بعد انتهاء التدريب. أما التدريب الواعي بالتكميم (QAT) فيحاكي التقريب أثناء التدريب حتى يتكيّف النموذج. كل ما في هذا المقال هو PTQ. أما QAT فيكلّف حوسبة أكثر ويتطلب جولة تدريب، وهو قرار منفصل.

صفّا INT4 وNF4 يمثّلان تكميم 4-bit النقي النظري: 4 بت لكل وزن ولا شيء سواها. لكن صيغ 4-bit الحقيقية تحمل فوق ذلك مقاييس كتل وحدودًا دنيا، فترتفع قليلًا. نموذج 70B عند Q4_K_M يبلغ نحو 42 GB لا 35. وجدول VRAM في الأسفل يستخدم المعدلات الفعلية بدلًا من ذلك.

التكميم لا يصغّر ذكاء النموذج. إنه يصغّر عدد المنازل العشرية التي يخزّن هذا الذكاء فيها. وإن كنت تدفع لكل توكن مقابل استدلال عبر API، فإن خفض فاتورة LLM API الخاصة بك يبدأ غالبًا بتشغيل نموذج مُكمَّم بنفسك.

طرق التكميم السبع جنبًا إلى جنب

الطرق السبع أدناه تغطي كل مسار إنتاجي لتكميم نماذج LLM في 2026. اثنتان حصريتان لوحدة GPU (GPTQ وAWQ)، وواحدة تعمل في أي مكان (GGUF)، وواحدة تكمّم عند التحميل (BitsandBytes)، واثنتان تستهدفان التقديم عالي الإنتاجية (SmoothQuant وFP8)، وواحدة أصلية في PyTorch (TorchAO). والخيار الصحيح يتوقف على عتادك، لا على الطريقة التي تسجّل أعلى نتيجة في لوحة صدارة.

تكمّم GPTQ طبقة تلو الأخرى مستخدمةً معكوس مصفوفة هيس لإعادة توزيع خطأ التقريب على الأوزان المتبقية. تحتاج مجموعة معايرة ووحدة GPU. وتفيد ورقة GPTQ بأنها كمّمت نموذج 175B إلى 3-4 بت في نحو 4 ساعات GPU.

تحدّد AWQ نحو 1% من الأوزان الأكثر أهمية (الأوزان البارزة، المكتشفة من مقادير التنشيط) وتُقيسها لحمايتها من التقريب. وتفيد ورقة AWQ (أفضل ورقة في MLSys 2024) بتسريع يفوق 3x مقارنةً بتنفيذ HuggingFace بصيغة FP16، على وحدات GPU المكتبية والمحمولة معًا.

GGUF تنسيق ملف، لا خوارزمية. الخوارزمية في داخله هي مخطط كتل k-quant من طلب الدمج رقم 1684 في llama.cpp. وهي الطريقة الوحيدة هنا التي تعمل على CPU، ما يجعلها الخيار الافتراضي للاستدلال المحلي. راجع نماذج الأوزان المفتوحة التي تستحق التكميم لتعرف ماذا تُطعمها.

تكمّم BitsandBytes عند التحميل لا مقدَّمًا. وصيغتها المميزة هي NF4 (‏4-bit NormalFloat)، وهي العمود الفقري للضبط الدقيق QLoRA. ولا تحتاج مجموعة معايرة.

تنقل SmoothQuant القيم الشاذة في التنشيطات إلى الأوزان حتى يعمل الاثنان بصيغة INT8. وتفيد الورقة بتسريع حتى 1.56x وخفض الذاكرة إلى النصف، وتستهدف الإنتاجية في التقديم بدفعات كبيرة حيث تهدر طرق W4A16 جزءًا من الأداء.

FP8 (W8A8) هي المسار الأصلي على وحدتَي GPU ‏H100 وB200. شبه عديمة الفقد عند 8-bit، وبلا صداع معايرة، وvLLM تدعمها مباشرة.

TorchAO هي مكتبة التكميم الخاصة بـPyTorch، المصممة للعمل مع torch.compile. إن كان خط أنابيبك مبنيًا على PyTorch أصلًا، فهي المسار الأقل احتكاكًا.

ثمّة سؤالان حقيقيان فقط: هل يشغّلها عتادك، وهل تقبل كلفة الجودة التي تفرضها؟

ماذا تُظهر أرقام القياس المنشورة فعليًا؟

تقول أرقام القياس المنشورة إن تكميم 4-bit يكلّف 1-2% من الحيرة على نموذج 7B، وإن 6-bit يكلّف أقل من 0.1%. هذه الأرقام مصدرها طلب الدمج رقم 1684 في llama.cpp (2023)، وقاسها مشرفو مشروع llama.cpp على نموذج 7B واحد على بطاقة RTX 4080. إنها الأرقام الأكثر استشهادًا في مجال التكميم، وهي حقيقية. لكنها أيضًا تجربة واحدة (n = 1).

المصدر: طلب الدمج رقم 1684 في llama.cpp (2023). نموذج 7B على RTX 4080، بقياس مشرفي مشروع llama.cpp. نموذج واحد فقط (n = 1).

ملاحظة حول عمود بت/وزن: تلك هي المعدلات الاسمية لنوع k-quant الأساسي، وخلطات _K ترفع المعدل الفعلي. وQ2_K مثال صارخ على ذلك. طبّق معادلة هذا المقال نفسها على الرقم الاسمي 2.5625 وعلى نموذج بعدد معلمات 6.74B فتحصل على نحو 2.0 GB، لكن الصف يذكر ملفًا بحجم 2.67 GB، وبحساب عكسي يعادل نحو 3.4 بت لكل وزن. وبقية هذا المقال تستخدم المعدلات الفعلية المشتقة من أحجام الملفات هذه.

أرقام طرق GPU تأتي من الأوراق البحثية مباشرة. تفيد GPTQ بتسريع استدلال شامل مقابل FP16 بنحو 3.25x على A100 ونحو 4.5x على A6000، مع تكميم نموذج 175B إلى 3-4 بت في نحو 4 ساعات GPU. وتفيد AWQ بـ"تسريع يفوق 3x مقارنةً بتنفيذ Huggingface بصيغة FP16 على وحدات GPU المكتبية والمحمولة معًا"، إضافةً إلى أول نشر لنموذج Llama-2 بحجم 70B على GPU محمول عبر TinyChat. ونحن نقتبس صياغة الورقة بدل إعادة صياغة الرقم بدقة زائفة.

الإسهام الأصلي هنا هو حساب بسيط. ذاكرة الأوزان تتبع المعادلة: weights (GB) ≈ params (B) × bits per weight ÷ 8. والمطبّ هو أي رقم بت/وزن تُدخله فيها. ينشر طلب الدمج رقم 1684 معدل نوع k-quant الأساسي (‏Q4_K = 4.5)، وخلطات _S/_M/_L تعلو فوق ذلك المعدل الأساسي لأنها تمنح بتات إضافية لموترات الانتباه والتغذية الأمامية. لذا اشتققنا المعدلات الفعلية من أحجام الملفات التي ينشرها طلب الدمج نفسه، على نموذج 7B يبلغ في الحقيقة 6.74B معلمة: Q2_K بحجم 2.67 GB يعادل حسابيًا نحو 3.4 بت/وزن، وQ4_K_S بحجم 3.56 GB نحو 4.5، وQ6_K بحجم 5.15 GB نحو 6.6. ويصل Q4_K_M إلى نحو 4.8.

وهذا يغيّر الرقم الرئيسي. نموذج 70B عند Q4_K_M: ‏70 × 4.8 ÷ 8 = 42 GB. معظم المقالات تقول 35 GB. إنها تستخدم 4.0 بت/وزن وتتجاوز حمولة مقاييس الكتل بالكامل. والتحقق المتقاطع لا يحتاج أكثر من نقرة: ملف Llama-3.3-70B-Instruct-Q4_K_M.gguf يُنشر بحجم 42.5 GB على HuggingFace، في مستودعات bartowski وlmstudio-community وsecond-state على السواء. وقد أعدنا حساب كل خلية في جدول VRAM أدناه على هذا الأساس.

قراءتنا لهذه الأرقام: فجوة الحيرة بين Q6_K (‏5.9110) وF16 (‏5.9066) هي 0.0044، وهي أصغر من الفجوة بين ضبطَين دقيقَين مختلفَين لنموذج أساسي واحد. لهذا السبب تبقى نصيحة "استخدم Q4_K_M أو Q5_K_M وحسب" صامدة عند ملامسة العتاد الحقيقي. وعمود مللي ثانية/توكن يُظهر أيضًا أن Q2_K لا يشتري أي سرعة إضافية على Q4_K_S (كلاهما 15.5 مللي ثانية/توكن) بينما يكلّف 0.75 من الحيرة. ‏Q2_K هو أسوأ صفقة في الجدول.

ما لا تقوله لك الأرقام: حيرة wikitext ليست الشيء نفسه كجودة المخرجات على أوامرك أنت. نموذج واحد على GPU واحد يعني n = 1. وأرقام السرعة تتوقف على حجم الدفعة. تعامل معها كمؤشرات اتجاه، لا كحقائق عامة.

تكميم 6-bit يهبط في حدود 0.1% تقريبًا من حيرة النموذج كامل الدقة. الضغط شبه مجاني عند ذلك المستوى.

GPTQ مقابل AWQ: الاختيار بين طريقتَي GPU

كلتا GPTQ وAWQ تنتج نقاط تفتيش 4-bit لوحدة GPU من مجموعة معايرة، وكلتاهما مدعومة جيدًا في vLLM. الفرق هو في كيفية التعامل مع خطأ التقريب. تعيد GPTQ توزيعه على الأوزان المتبقية باستخدام معكوس مصفوفة هيس. وتحمي AWQ نسبة 1% من الأوزان التي تصفها التنشيطات بالمهمة. كلتاهما تعمل. والخيار يتوقف على نمط التقديم لديك.

تعمل GPTQ طبقة تلو الأخرى. فهي تكمّم في كل طبقة وزنًا واحدًا في المرة، ثم تعدّل الأوزان المتبقية في تلك الطبقة لتعويض التقريب الذي أجرته للتو. ويستخدم التعديل معلومات من الدرجة الثانية من مصفوفة هيس، ولهذا تحتاج مجموعة معايرة لحسابه. والنتيجة قوية في الاستدلال بالدفعات حيث تهمّ الإنتاجية أكثر من زمن الاستجابة لكل توكن.

تأخذ AWQ زاوية مختلفة. فهي تحدّد الأوزان البارزة بالنظر إلى مقادير التنشيط عبر مجموعة المعايرة، أي نحو أعلى 1% من القنوات. وتحصل تلك الأوزان على معامل قياس لكل قناة يُبقيها في نطاق دقة أعلى أثناء التقريب. ويمكن لمجموعة المعايرة أن تكون أصغر من مجموعة GPTQ، كما أن AWQ تفرط في التخصيص لها بدرجة أقل لأنها تحمي سمات بنيوية بدلًا من مطابقة مدخلات بعينها. وتفيد الورقة بنتائج قوية في التقديم الحساس لزمن الاستجابة.

اختر GPTQ إذا: كنت تجري استدلالًا بالدفعات على GPU، وتملك مجموعة معايرة جيدة تطابق مجالك، وكانت الإنتاجية هي المقياس.

اختر AWQ إذا: كنت تقدّم طلبات مستخدم واحد بزمن استجابة منخفض، أو تريد مجموعة معايرة أصغر، أو تنشر على وحدات GPU طرفية/محمولة.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

وإن كنت تختار بين محركات التقديم أيضًا، فمقال vLLM مقابل SGLang تغطي ذلك القرار على حدة.

GGUF وK-Quants: ماذا يعني Q4_K_M فعليًا؟

‏GGUF تنسيق ملف، لا خوارزمية تكميم. تحدّد مواصفة GGUF حاوية لأوزان النموذج وبياناته الوصفية وبيانات المُرمِّز. وخوارزمية التكميم داخل ملف GGUF هي مخطط كتل k-quant (أو i-quant) من طلب الدمج رقم 1684 في llama.cpp. والخلط بين الحاوية والخوارزمية هو الخطأ الأشيع في هذا المجال، وهو يفضي إلى أسئلة من قبيل "أيهما أفضل، GGUF أم GPTQ؟" وهي أسئلة لا تستقيم أصلًا.

تُفك شيفرة التسمية على النحو التالي. الحرف Q تعني مخطط كتل k-quant، وIQ تعني i-quant بمصفوفة الأهمية (تنويعة أحدث تستخدم مصفوفة أهمية لجودة أفضل عند عمق البت نفسه). والرقم هو عمق البت الاسمي. واللاحقة _K تميّز عائلة k-quant عن الصيغ القديمة مثل Q4_0. أما _S و_M و_L فتتحكم في أي مجموعات الموترات تنال بتات إضافية: صغيرة، متوسطة، كبيرة. واللاحقة الأعلى تعني بتات أكثر مخصَّصة لموترات الانتباه والتغذية الأمامية، وهي الأهم.

معدلات فعلية، محسوبة عكسيًا من أحجام ملفات نموذج 7B (‏6.74B معلمة) المنشورة في طلب الدمج رقم 1684، لا من أرقام النوع الأساسي. وصفّا الصيغ القديمة دقيقان بحكم البنية: كتلة Q4_0 هي 32 وزنًا عند 4 بت يضاف إليها مقياس FP16 واحد، أي 4.5 بت لكل وزن، وQ8_0 هي 32 وزنًا عند 8 بت يضاف إليها مقياس FP16، أي 8.5. ويؤيد طلب الدمج ذلك، إذ يسرد ملفَّي Q4_0 وQ4_K_S لنموذج 7B بالحجم نفسه 3.56 GB.

‏Q4_K_M ليس 4 بت لكل وزن. إنه نحو 4.8. فمقاييس الكتلة والحدود الدنيا يجب أن تسكن مكانًا ما، ثم تنفق خلطة _M بعد ذلك بتات إضافية على موترات الانتباه والتغذية الأمامية، وهذا بالضبط سبب علوّ Q4_K_M فوق Q4_K_S وعلوّ Q3_K_M فوق Q3_K_S بدل مطابقته.

لماذا يعمل GGUF حيث تعجز GPTQ: لأنه يدعم الاستدلال على CPU وترحيل الطبقات بين ذاكرة GPU VRAM وذاكرة النظام RAM. فنموذج 32B لا يتسع كاملًا على وحدتك يمكن أن يعمل بنصف طبقاته مُرحَّلًا، ببطء لكنه يعمل. أما GPTQ فليس لها مسار CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

جديد على النماذج المحلية؟ ابدأ بـتشغيل أول نموذج محلي لك قبل أن تكمّم أي شيء. وإن أردت واجهة متصفح، فإعداد Open WebUI فوق Ollama يستغرق نحو عشر دقائق. وتشرح وثائق GGUF على HuggingFace كيف يعرض Hub تسميات أنواع التكميم.

BitsandBytes وMarlin وSmoothQuant وTorchAO

هذه الأربعة تغطي مسارات الإنتاج المتبقية. وليس أي منها "نسخة أفضل من GPTQ". إنها تحل مشكلات مختلفة.

تكمّم BitsandBytes عند التحميل، لا مقدَّمًا. توجّهها إلى نقطة تفتيش FP16 فتحوّلها فورًا إلى NF4 أو FP4. بلا مجموعة معايرة، وبلا خطوة غير متصلة. وأشهر ما يميّزها هو QLoRA: نموذج أساسي مجمَّد عند 4-bit مع محوّلات LoRA تُدرَّب فوقه، ما يجعل الضبط الدقيق لنموذج 65B على GPU واحد ممكنًا بذاكرة 48 GB. وQLoRA تقنية تدريب لا تقنية استدلال، لكنها السبب الذي يجعل معظم الناس يصطدمون بـBitsandBytes أول مرة.

Marlin ليست طريقة تكميم. إنها نواة GEMM مختلطة الدقة INT4xFP16 تجعل نقاط تفتيش 4-bit القائمة أسرع عند أحجام دفعات متوسطة. وتفيد ورقة Marlin بتسريعات على A100 وH100. وإن كانت منظومة التقديم لديك تدعمها، فستفعّلها على نموذج مُكمَّم سلفًا. أنت لا "تكمّم بـMarlin".

تُزيح SmoothQuant القيم الشاذة في التنشيطات إلى الأوزان عبر معامل قياس لكل قناة، ما يجعل صيغة W8A8 (الأوزان والتنشيطات معًا عند INT8) قابلة للتطبيق. وتستهدف الورقة التقديم بدفعات كبيرة حيث تهدر طرق W4A16 جزءًا من الإنتاجية. إن كنت تقدّم مئات الطلبات المتزامنة، فهذا هو خيارك.

TorchAO هي تكميم أصلي في PyTorch يعمل مع torch.compile. بلا تبعيات خارجية، وبلا تحويل صيغ. إن كان خط أنابيب الاستدلال لديك مبنيًا على PyTorch أصلًا، فهي الخيار الأقل احتكاكًا. ولأجل تشغيل نماذج التضمين محليًا، يكون مسار Ollama أبسط في العادة، لكن TorchAO تناسب منظومات PyTorch المخصّصة.

كم من VRAM يحتاج النموذج المُكمَّم؟

المعادلة هي weights (GB) ≈ params (B) × bits per weight ÷ 8. نموذج 70B عند Q4_K_M: ‏70 × 4.8 ÷ 8 = 42.0 GB. والمعدلات أدناه فعلية، محسوبة عكسيًا من أحجام الملفات التي ينشرها طلب الدمج رقم 1684 في llama.cpp لا من أرقام النوع الأساسي، لأن خلطات _M تعمل دائمًا فوق معدل k-quant الأساسي الخاص بها. لقد أعدنا الحساب بدل نسخ الاختصار المعتاد القائم على 4.0 بت/وزن.

محسوبة من معدلات فعلية للبت/وزن: ‏Q8_0 = 8.5، وQ6_K = 6.56، وQ5_K_M = 5.7، وQ4_K_M = 4.8، وQ3_K_M = 3.9. مشتقة من أحجام ملفات نموذج 7B (‏6.74B معلمة) في طلب الدمج رقم 1684، ثم تحققنا منها مقابل نسخة 70B منشورة: ملف Llama-3.3-70B-Instruct-Q4_K_M.gguf يبلغ 42.5 GB على HuggingFace، مقابل 42.0 GB تتنبأ بها حساباتنا هنا.

التنبيه الصادق: هذه أوزان فقط. فذاكرة KV cache وطول السياق والحمل الزائد للإطار تُضاف فوقها. ويتضخم KV cache مع طول السياق وحجم الدفعة. وجلسة بسياق 32k على نموذج 70B قد تضيف عدة GB. وجدول الأوزان هو الحد الأدنى، لا الميزانية. ونافذة سياقك تستأجر VRAM أيضًا. وللصورة الكاملة، راجع متطلبات VRAM لكل نموذج بالتفصيل.

أي طريقة تكميم ينبغي أن تستخدم؟

عتادك يقرّر قبل تفضيلاتك. فالطريقة التي لا تعمل على وحدتك ليست خيارًا، إنها أمنية. والجدول أدناه يربط الإعدادات الشائعة بالطريقة التي تعمل لها فعليًا، استنادًا إلى قيود العتاد ومقايضات الجودة التي غطّيناها أعلاه.

لمعظم القراء على العتاد الاستهلاكي، ملف GGUF مُكمَّم مسبقًا بصيغة Q4_K_M أو Q5_K_M هو الإجابة الصحيحة. اسحبه من HuggingFace، وشغّله في Ollama أو llama.cpp، وتوقّف عن التحسين. فالفرق في الجودة بين Q4_K_M وQ5_K_M أصغر من أن تبني عليه قرارًا، والأولى أن تختار بحسب ما إذا كان الملف يتّسع، لا بحسب جدول حيرة. وكل ما بعد ذلك تحسين من أجل التحسين، ولا يستحق العناء إلا بعد أن تتأكد أن النموذج يحل مشكلتك فعلًا عند Q4.

ويغطي دليل الأدوات التي تشغّل هذه النماذج محليًا فعلًا جانب التقديم بعد أن تستقر على مستوى التكميم.

خمس طرق يفشل بها التكميم

إخفاقات التكميم هي تقريبًا دائمًا مشكلات إعداد، لا مشكلات في الطريقة. وهذه الخمسة تظهر باستمرار.

1. مجموعة المعايرة لا تطابق مجالك. كلتا GPTQ وAWQ تُضبطان وفق بيانات المعايرة. إن عايرت على Wikipedia ونشرت على محاضر طبية، فسيتراجع أداء النموذج المُكمَّم على التوكنات التي لم يرها قط. الحل: استخدم مجموعة معايرة مأخوذة من توزيع مدخلاتك الفعلي، فحتى 128 عينة تفيد.

2. حجم المجموعة مضبوط على قيمة كبيرة جدًا. يتحكم حجم المجموعة في GPTQ في عدد الأوزان التي تتشارك معامل قياس واحد. و128 هي القيمة المعيارية. أما 256 أو 512 فتوفّر حوسبة أثناء التكميم لكنها تصطدم بحافة جودة حادة في النماذج الأصغر. الحل: ابقَ عند 128 ما لم تتأكد أن الجودة تصمد على أوامرك.

3. توقّع أن يكون Q2_K صالحًا للاستخدام. وفق بيانات طلب الدمج رقم 1684، يكلّف Q2_K نحو 0.87 من الحيرة مقابل F16 ولا يشتري أي سرعة على Q4_K_S (كلاهما 15.5 مللي ثانية/توكن على قياس 7B). تحصل على ملف أصغر ومخرجات أسوأ بلا أي كسب في زمن الاستجابة. الحل: ‏Q4_K_S هو الحد الأدنى ما لم يكن حجم الملف قيدًا صارمًا.

4. القياس على حيرة wikitext بدلًا من أوامرك أنت. الحيرة مقياس لنمذجة اللغة. إنها لا تقيس ما إذا كان النموذج يتّبع أمر النظام الخاص بك، أو يصيغ JSON صياغة صحيحة، أو يتقن مفردات مجالك. الحل: مرّر 20-30 من أوامرك الحقيقية على النموذج المُكمَّم وغير المُكمَّم وقارن المخرجات.

5. الخلط بين GGUF الحاوية وخوارزمية التكميم داخلها. وهذا يفضي إلى مقارنة "GGUF مقابل GPTQ" كأنهما من الفئة نفسها. وليستا كذلك. ‏GGUF تنسيق ملف. ومخطط k-quant في داخله هو الخوارزمية. الحل: قارن مستويات k-quant (‏Q4_K_M مقابل Q5_K_M)، لا صيغ الملفات.

الأسئلة الشائعة

ما هو تكميم LLM؟

تكميم LLM يخفض الدقة الرقمية لأوزان النموذج، من الفاصلة العائمة 16-bit عادةً إلى أعداد صحيحة 4-bit أو 8-bit. وهذا يقلّص استهلاك الذاكرة ويسرّع الاستدلال بخفض عرض النطاق. نموذج 70B يهبط من 140 GB إلى نحو 42 GB عند 4-bit. وكلفة الجودة تكون عادةً 1-2% من الحيرة عند 4-bit، وأقل عند 6-bit.

هل يقلل التكميم من دقة النموذج؟

نعم، لكن أقل مما يتوقعه معظم الناس. وفق قياسات طلب الدمج رقم 1684 في llama.cpp، يكلّف Q4_K_S على نموذج 7B نحو 2% من الحيرة مقابل F16، ويكلّف Q6_K أقل من 0.1%. والأثر العملي على الأوامر الحقيقية أصغر غالبًا مما يوحي به رقم الحيرة، خصوصًا عند Q4_K_M فما فوق.

أيهما أفضل: GPTQ أم AWQ؟

لا توجد أفضلية مطلقة لأي منهما. تستخدم GPTQ إعادة توزيع الخطأ بمعكوس هيس وتناسب استدلال الدفعات على GPU. وتحمي AWQ الأوزان البارزة عبر قياس واعٍ بالتنشيط وتناسب التقديم الحساس لزمن الاستجابة. وتحتاج AWQ مجموعة معايرة أصغر وتفرط في التخصيص لها بدرجة أقل. إن كنت تقدّم طلبات مستخدم واحد بزمن استجابة منخفض، فابدأ بـAWQ.

ماذا يعني Q4_K_M؟

‏Q4_K_M مستوى تكميم k-quant بصيغة GGUF. الحروف "Q4" تعني عمقًا اسميًا 4-bit، و"K" تميّز مخطط كتل k-quant (مقابل Q4_0 القديم)، و"M" تعني متوسطًا: موترات الانتباه والتغذية الأمامية تنال بتات إضافية. والبتات الفعلية لكل وزن نحو 4.8 لا 4.0، لأن مقاييس الكتلة والحدود الدنيا تضيف حمولة، والخلطة المتوسطة تنفق فوق ذلك المزيد.

هل يمكن تشغيل نموذج مُكمَّم على CPU؟

نعم، لكن عبر GGUF فقط. صيغتا GPTQ وAWQ حصريتان لوحدة GPU. أما نماذج k-quant بصيغة GGUF فتعمل على CPU عبر llama.cpp أو Ollama، وتدعم ترحيل الطبقات بين ذاكرة GPU VRAM وذاكرة النظام RAM. وQ4_K_M هو مستوى التكميم المعياري على CPU. توقّع توليد توكنات أبطأ من GPU، لكن باستدلال يعمل.

ما الفرق بين GGUF وGGML؟

‏GGML هي مكتبة الموترات وتنسيق الملفات الأقدم الذي استخدمته llama.cpp في الأصل. واستبدلتها GGUF في أغسطس 2023 بصيغة حاوية أكثر مرونة ودعمًا أفضل للبيانات الوصفية. وملفات GGUF هي ما تحمّله من HuggingFace اليوم. أما ملفات GGML فقديمة ونادرًا ما تُوزَّع بعد الآن.

هل أكمّم النموذج بنفسي أم أحمّل نسخة مُكمَّمة مسبقًا؟

حمّل نسخة مُكمَّمة مسبقًا أولًا. فقد كمّمت مجتمعات llama.cpp وHuggingFace معظم النماذج الشائعة عند كل المستويات سلفًا. والتكميم بنفسك لا يكون منطقيًا إلا إذا احتجت مجموعة معايرة محددة لمجالك، أو لم توجد نسخة مُكمَّمة مسبقًا لنموذجك.

متى أستخدم التكميم بدلًا من نموذج أصغر؟

استخدم التكميم حين تحتاج قدرات النموذج الأكبر لكنك لا تستطيع احتواءه في الذاكرة. فنموذج 70B مُكمَّم يتفوق عمومًا على نموذج 13B غير مُكمَّم في مهام الاستدلال المعقدة. واستخدم نموذجًا أصغر بدلًا من ذلك حين يكون زمن الاستجابة هو القيد، لأن النماذج الأصغر تولّد التوكنات أسرع بغضّ النظر عن التكميم.

ما الفرق بين التكميم والتقطير؟

التكميم يخفض الدقة الرقمية لأوزان نموذج قائم. أما التقطير فيدرّب نموذجًا أصغر على محاكاة نموذج أكبر، لينتج معمارية مختلفة (أصغر) حقًا. والتكميم يحافظ على معمارية النموذج الأصلي وهو قابل للعكس من حيث المبدأ. أما التقطير فينشئ نموذجًا جديدًا ويتطلب جولة تدريب.

النسخة المختصرة: التكميم هو الطريقة التي تُسكن بها نموذجًا تريده في عتاد تملكه. ولمعظم الناس على وحدات GPU الاستهلاكية أو Apple Silicon، ملف GGUF مُكمَّم مسبقًا بصيغة Q4_K_M مسحوب من HuggingFace هو الحل كاملًا. وGPTQ وAWQ هما إجابتا التقديم على GPU. وFP8 وSmoothQuant هما إجابتا الإنتاجية في الإنتاج. وكل ما عدا ذلك تحسين بعد أن تتأكد أن النموذج يعمل.

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