RunPod تقارن 4 طرق للتكميم: من FP16 إلى INT4 تنخفض الذاكرة 4 أضعاف

أصدرت RunPod، مزوّد الخدمات السحابية لوحدات GPU، مراجعة لأربع طرق لضغط النماذج قبل نشرها: التكميم بعد التدريب (PTQ)، والتدريب الواعي بالتكميم (QAT)، والدقة المختلطة، والتكميم الديناميكي. لا تتضمن المادة اختبارات أداء خاصة بها، فهي مقارنة مرجعية للمفاضلات بين هذه الطرق. لكن الموضوع من النوع الذي يحدد مباشرةً فاتورة الاستدلال. تشغل أوزان نموذج بحجم 70 مليار معامل نحو 140 غيغابايت بصيغة FP16، ونحو 70 غيغابايت بصيغة INT8، ونحو 35 غيغابايت بصيغة INT4. والفارق بين «نحتاج إلى مسرّعين بسعة 80 غيغابايت لكل منهما» و«يكفي مسرّع واحد» يتشكل من هذه الأرقام.

أربع طرق لخسارة قدر يسير من الدقة

يأخذ PTQ نموذجًا مدرَّبًا بالفعل، ويمرّر عبره مجموعة بيانات معايرة صغيرة، ثم يحوّل الأوزان، وأحيانًا التنشيطات أيضًا، إلى INT8 أو INT4. لا حاجة إلى إعادة تدريب، وتستغرق العملية دقائق أو ساعات. بهذه الطريقة تعمل أداتا GPTQ وAWQ الشائعتان. أما الثمن فهو تراجع الجودة، خصوصًا عند 4 بتات وفي النماذج الصغيرة.

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

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

مرجعيات حسب مستوى الدقة

تزداد السرعة وتنخفض الذاكرة مع انخفاض الدقة، لكن ليس بالقدر نفسه. وتفيد في التقدير بضع قيم مرجعية:

• FP16/BF16: 2 بايت لكل معامل، وهي الدقة الأساسية؛ ويتطلب نموذج 70B نحو 140 غيغابايت للأوزان وحدها.
• INT8: 1 بايت لكل معامل، والذاكرة أقل بمقدار النصف، وخسارة الجودة في معظم المهام عادةً طفيفة.
• INT4: 0,5 بايت لكل معامل، ونحو 35 غيغابايت لنموذج 70B، مع خطر ملحوظ لتراجع الأداء في الاستدلال المنطقي والبرمجة.
• الكلفة الإضافية: لا تشمل هذه الأرقام KV-cache والتنشيطات، وهي تنمو مع طول السياق وعدد الطلبات المتزامنة.
• دعم العتاد: لا يحقق تسارعًا إلا ما تستطيع نوى التنسور (tensor cores) حسابه أصلًا. وعلى H100 هذان هما FP8 وINT8، أما INT4 فتلزمه غالبًا نوى مخصصة.

أين المأزق

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

ويترتب على ذلك تسلسل عملي للخطوات. في المحاولة الأولى، اعتمدوا PTQ بصيغة INT8 أو بصيغة 8 بت يدعمها عتادكم، وقارنوا النتائج مع FP16 على بياناتكم الخاصة لا على الاختبارات العامة. إذا حافظت الجودة على مستواها، جرّبوا INT4 وانظروا إلى أسوأ الحالات لا إلى المتوسط. وإذا كان التراجع حرجًا وتوفرت ميزانية للضبط الدقيق، فانتقلوا إلى QAT. أما التكميم الديناميكي فيناسب الحالات التي لا تتوافر فيها GPU أصلًا، أو التي يلزم فيها اختبار فرضية بسرعة. واحسبوا KV-cache على حدة: فنموذج INT8 بحجم 70 غيغابايت على بطاقة سعتها 80 غيغابايت لا يترك للسياق والطلبات المتزامنة سوى نحو 10 غيغابايت، وعندها لا يتفوق INT4 بالسرعة، بل بالذاكرة الحرة.