خمس طرق لضبط نماذج اللغة الكبيرة دون عنقود حوسبة باهظ: LoRA وQLoRA وUnsloth وDPO واختيار وحدة GPU

قصة مألوفة: يقرر فريق ضبط نموذج مفتوح المصدر لمهمته الخاصة، فيطّلع على أسعار وحدات GPU السحابية ويؤجّل الفكرة إلى وقت أفضل. وهذا خطأ. فمعظم الفاتورة لا ينبع من حاجة حقيقية، بل من عادة فعل كل شيء «على الطريقة الكاملة»: تحديث جميع الأوزان، والاحتفاظ بالنموذج بدقة كاملة، واستئجار أقوى بطاقة متاحة. وقد حلّل KDnuggets خمس تقنيات تكسر هذه العادة. إليكم ما وراءها وكيفية تطبيقها.

من أين تأتي الفاتورة

في الضبط الكامل لا يقيم في الذاكرة النموذج وحده. فبجانبه التدرجات وحالة المُحسِّن (في Adam هما رقمان إضافيان لكل معامل). وفي تقدير تقريبي، يحتاج نموذج بسبعة مليارات معامل إلى أكثر من 100 غيغابايت من ذاكرة الفيديو. وهذا يعني عدة بطاقات باهظة لا بطاقة واحدة.

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

خمس تقنيات بالترتيب

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

2. QLoRA. هي LoRA نفسها، لكن النموذج الأساسي المجمَّد مضغوط إلى 4 بتات، بينما تُدرَّب المحوّلات بدقة أعلى. وهذه الحيلة هي التي أتاحت ضبط النماذج على بطاقة واحدة استهلاكية أو خادمية رخيصة. الثمن: خطوة تدريب أبطأ قليلًا، وخطر طفيف بفقدان الجودة، لذا ينبغي مقارنة النتيجة على مجموعة التحقق الخاصة بكم.

3. Unsloth. ليست خوارزمية جديدة، بل تنفيذ مُحسَّن: نوى مُعاد كتابتها وتعامل أكثر اقتصادًا مع الذاكرة. والمهم للممارس أنها تعمل فوق الحزمة المألوفة (Hugging Face وPEFT وTRL) وتمنح مكسبًا في السرعة وVRAM دون تغيير الطريقة. وهي أرخص خطوة من حيث الجهد: غيّروا الاستيراد وقيسوا.

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

5. الحجم الصحيح لوحدة GPU. أكثر البنود مللًا وأكثرها توفيرًا للمال. ففي QLoRA على نموذج من فئة 7–8B تكفي غالبًا بطاقة بسعة 24 غيغابايت، أما استئجار أقوى مسرّع «تحسبًا» فيعني دفع أضعاف الثمن مقابل ذاكرة عاطلة. قيسوا أولًا ذروة استهلاك الذاكرة على دفعة صغيرة، ثم اختاروا البطاقة. ويساعد في ذلك gradient checkpointing وتراكم التدرجات والسياقات القصيرة في أمثلة التدريب.

القيود وما يجب فعله

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

والترتيب العملي للخطوات كالتالي:

• ابدؤوا بـ QLoRA على نموذج صغير وبطاقة واحدة، وفعّلوا Unsloth إن كان يدعم بنيتكم.
• أنشئوا فورًا مجموعة تحقق على مهامكم، وقارنوا مع النموذج الأساسي ومع الـ prompting: أحيانًا لا حاجة إلى الضبط أصلًا.
• إن لزم تعديل أسلوب الإجابات، فأضيفوا DPO فوق المحوّل المدرَّب.
• اختاروا GPU وفق الذاكرة المقيسة لا وفق قائمة أسعار المزوّد.

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