Fudan وHuawei Xiaoyi تدرّبان وكيل ذكاء اصطناعي على كتابة مشغّلات لمعالجات Ascend NPU بنسبة نجاح 95.5%

رفع فريق من جامعة فودان، بالتعاون مع Huawei Xiaoyi، نسبة المشغّلات (operators) المولَّدة بنجاح لمعالجات Ascend NPU إلى 95.5%. ويتعلق الأمر بوكيل برمجة يكتب شيفرة منخفضة المستوى لمنصة عتادية لا تعرفها النماذج اللغوية جيدًا، ثم يجمّعها ويشغّلها بنفسه ويعيد صياغتها حتى تعمل بالشكل المطلوب.

أين تضيع السرعة بعد النشر

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

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

وكيل على منصة لم يتدرّب عليها

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

أما مع Ascend فالأمر أصعب. فمعظم الشيفرة المفتوحة مكتوب لمنصات أخرى، ومعرفة النموذج بدقائق برمجة معالجات NPU أقل. وطرح الباحثون السؤال على النحو التالي: ماذا يفعل الوكيل إذا كان عليه أن يجمّع الشيفرة ويصحّح أخطاءها ويحسّنها على منصة قاعدة المعرفة عنها غير كافية؟ وجاء جواب فريقي Fudan وHuawei Xiaoyi: تعليمه الاعتماد على التغذية الراجعة من المنصة نفسها، أي على نتائج التجميع والتشغيل.

المؤشر النهائي للمشروع هو 95.5% من المشغّلات المولَّدة بنجاح.

ما المعروف عن المشروع

• المشاركون: جامعة فودان وفريق Huawei Xiaoyi.
• المنصة المستهدفة: معالجات Ascend NPU.
• نوع النظام: وكيل برمجة يستدعي الأدوات ويجمّع الشيفرة ويشغّلها ويحسّنها تكراريًا.
• المشكلة: الاستخدام الفعّال للعتاد بعد تثبيت المنطق الحسابي للنموذج.
• ما يؤثر في السرعة: تقسيم البيانات إلى كتل، ونقلها، والتوازي، والمزامنة.
• النتيجة الرئيسية: 95.5% من المشغّلات المولَّدة بنجاح.

لماذا يهم هذا منظومة Ascend

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

كما يمكن تطبيق هذا النهج على نطاق أوسع. فكل شركة مصنِّعة للمسرّعات تواجه مشكلة أن النماذج لا تعرف منصتها البرمجية جيدًا. أما المخطط الذي يتعلم فيه الوكيل من ردود المترجم وأداة التحليل (profiler) فيمكن نقله إلى معالجات NPU وGPU أخرى.

ما الذي ينبغي أن يراقبه فريق يعمل مع Ascend

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

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