REAP20 تسرّع Qwen محليًا بنسبة 42% من دون خسارة الدقة في DS1000

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

تكمن القيمة العملية للقصة تحديدًا في هذه الأخطاء. فقد اختبر الكاتب عائلة Qwen على بطاقة RTX 4070 Ti Super بذاكرة فيديو سعتها 16 غيغابايت، مستخدمًا DS1000، وهي مجموعة من ألف مهمة في Pandas وNumPy وSciPy وScikit-learn وMatplotlib وPyTorch وTensorFlow. كانت شيفرة النموذج تُدرج في قالب ثم تُنفّذ، وتُقارن النتيجة بالإجابة المرجعية. وهذا أقرب إلى العمل الحقيقي لمتخصص بيانات من اختبار آخر لإنشاء صفحة هبوط أو لعبة تعمل في المتصفح.

الجولة الأولى: السرعة من دون تفكير مطوّل

في الاختبار الأولي، كان الاستدلال معطّلًا. وتصدرت REAP20-28B وQwen3.6-35B-A3B من حيث عدد المهام المحلولة. وكان أداء REAP20 لافتًا على وجه الخصوص: فمع دقة مماثلة، ولّدت الإجابة بسرعة تزيد 42% على النموذج الأصلي، رغم حذف 20% من أوزانها.

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

لكن لا يجوز تحويل النتيجة إلى ترتيب عالمي. صدر DS1000 في عام 2023، وربما دخلت بعض مهامه في بيانات تدريب النماذج الأحدث. ولا تكشف جولة واحدة تشتت النتائج، كما تزيد أساليب التكميم وإعدادات فك الترميز المختلفة صعوبة إجراء مقارنة عادلة. وأخيرًا، ينبغي أن يعكس اختيار المكتبات طبيعة العمل الفعلي: كانت NumPy وSciPy وScikit-learn وPyTorch مهمة للكاتب، ولذلك قلّص المجموعة لاحقًا من 1,000 إلى 509 مهام.

حد التوكنات أفسد التجربة الثانية

في الجولة الثانية، فعّل الكاتب وضع thinking، لكنه خصص 4,096 توكن فقط للاستدلال. قلب هذا القرار جدول النتائج. فقد تراجعت دقة REAP20 بأكثر من النصف، بينما لم تتغير نتيجة النسخة الكاملة من النموذج نفسه تقريبًا. وكان السبب بسيطًا: في نحو حالتين من كل ثلاث، كانت REAP20 تصطدم بالسقف قبل أن تتمكن من إنهاء الإجابة.

إليكم مثالًا بسيطًا. يعرف النموذج كيفية كتابة حل باستخدام Scikit-learn، ويضع خطة صحيحة، لكن إجابته تنقطع قبل الوصول إلى الشيفرة النهائية. يمنحه نظام التقييم صفرًا، تمامًا كما يفعل مع إجابة خاطئة بالكامل. وإذا نظرنا إلى الدقة النهائية وحدها، فقد نستنتج أن النموذج أصبح أسوأ. لكن الخلل في الحقيقة أصاب منظومة القياس.

وهذا درس مهم لأي benchmark داخلي: احفظوا سبب انتهاء الإجابة، وعدد التوكنات المستخدمة، وزمن التوليد، ونسبة الإجابات المنقطعة. ويجب تحليل النتائج التي تحمل finish_reason=length بصورة منفصلة، وإلا فسيظهر قيد البنية التحتية وكأنه ضعف في النموذج.

النتائج بعد التصحيح

بدأ الكاتب برفع الحد تدريجيًا واستكمال عمليات الاستدلال المنقطعة. وفي وضع الجهد الأقصى، حلّت Qwen3.8-27B في النهاية 252 مهمة من أصل 509، مقارنة بـ173 مهمة في البداية. وبلغت الزيادة 79 حلًا، لكن التكلفة كانت مزعجة: استغرقت سلسلة جولات التكرار نحو 153 ساعة. أما من حيث الدقة النهائية، فلم يفعل النموذج سوى الاقتراب من Qwen3.6-MoE الأسرع التي عملت من دون استدلال.

على بطاقة RTX 6000 Pro الاحترافية، حقق نموذج Qwen3.8-Flash-Next-NVFP4 نسبة 58.1% على مجموعة DS1000 الكاملة خلال 8.5 دقائق. لكن لا يمكن نقل هذه النتيجة إلى بطاقة رسوميات مخصصة للألعاب: فالعتاد وصيغة الأوزان والإعدادات مختلفة، ما يغيّر اقتصاديات التشغيل.

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