← أحدث الأبحاث
🤖 AI

Compiler-Grounded Hierarchical Diagnosis for LLM-Based Triton Kernel Optimization

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

المؤلفون الأصليون: Dongjie Chen, Ping Zhao, Bohua Zhan, Yulong Wang, Shushu Chen, Liangjun Feng, Hao Zhou, Min Shen, Linmu Wang, Weijia Sheng, Xiangyu Wei, Weijie Ding, Jianhui Huang, Yaoqing Gao

نُشر 2026-07-28
📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

المؤلفون الأصليون: Dongjie Chen, Ping Zhao, Bohua Zhan, Yulong Wang, Shushu Chen, Liangjun Feng, Hao Zhou, Min Shen, Linmu Wang, Weijia Sheng, Xiangyu Wei, Weijie Ding, Jianhui Huang, Yaoqing Gao

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك تحاول ضبط سيارة سباق لتسير بأقصى سرعة ممكنة. في عالم علوم الحاسوب، هذه "السيارات" هي برامج صغيرة متخصصة تسمى النوى (kernels)، وهي التي تخبر الرقائق الحاسوبية القوية (مثل تلك الموجودة في هاتفك أو في الحواسيب الفائقة) كيفية إجراء العمليات الحسابية. لسنوات طويلة، كان البشر هم الميكانيكيين الذين يقومون بتعديل الكود يدوياً. ولكن مؤخراً، سلمنا هذه المهمة إلى وكلاء الذكاء الاصطناعي (AI agents)—وهي برامج حاسوبية ذكية يمكنها كتابة وإعادة كتابة الكود من تلقاء نفسها. عادة ما يعمل وكلاء الذكاء الاصطناعي هؤلاء مثل سائق يستمر فقط في الضغط على دواسة الوقود ومراقبة عداد السرعة. إذا كانت السيارة بطيئة، فإن الذكاء الاصطناعي يخمن قطعة جديدة لتركيبها، يجربها، ثم يرى ما إذا كانت أسرع. المشكلة هي أن الذكاء الاصطناعي غالباً لا يعرف لماذا كانت السيارة بطيئة. هل المشكلة في المحرك؟ أم الإطارات؟ أم أنه قانون غريب في دليل المصنع لم يخبر به أحد الذكاء الاصطناعي؟ تتناول هذه الورقة هذا الغموض، وتحديداً لنوع من الرقائق الحاسوبية يسمى وحدة المعالجة العصبية (NPU)، وهي ممتازة لتشغيل الذكاء الاصطناعي لكنها قد تكون صعبة البرمجة. يجادل المؤلفون بأنه لكي تعالج برنامجاً بطيئاً حقاً، لا يمكنك الاكتفاء بالتخمين؛ بل يجب أن تعمل كالمحقق الذي يفحص السرعة، وينظر تحت غطاء المحرك إلى الأجزاء الداخلية للمحرك، ويقرأ أخيراً دليل المصنع ليفهم لماذا يتصرف المحرك بهذا الشكل.

تقدم الورقة نظاماً جديداً يسمى التشخيص الهرمي القائم على المترجم (Compiler-Grounded Hierarchical Diagnosis). فكر في هذا النظام كأنه ميكانيكي ذكي جداً وصبور للغاية، يرفض التخمين حتى يمتلك الدليل الصحيح. بدلاً من مجرد إلقاء تغييرات عشوائية على الكود، يستخدم هذا النظام "سلماً" من التحقيق. يبدأ من الأسفل بـ فرز الأنماط (Pattern Triage)، حيث يتحقق بسرعة مما إذا كانت المشكلة تطابق حلاً معروفاً، مثل استبدال إطار مثقوب بإطار احتياطي. إذا لم ينجح ذلك، ينتقل إلى تشخيص تحليل الأداء (Profiling Diagnosis)، حيث يراقب تشغيل البرنامج ليرى بالضبط أين يتوقف أو يتعثر—مثل التحقق مما إذا كان المحرك يسخن بشكل مفرط أو إذا كانت العجلات تدور في مكانها دون حركة.

إذا لم يخبر عداد السرعة القصة كاملة، فإن الميكانيكي يتسلق درجة أعلى ليصل إلى إسناد التمثيل الوسيط (IR Attribution). هذا يشبه النظر في مخططات المحرك (المعروفة بالتمثيل الوسيط أو IR) لمعرفة ما إذا كانت الأجزاء مجمعة بطريقة غريبة تؤدي إلى إبطائها. وأخيراً، إذا كانت المخططات مربكة، يصعد النظام إلى الدرجة الأعلى: التصعيد إلى مصدر المترجم (Compiler-Source Escalation). هنا، يستشير "دليل المصنع" (قواعد المترجم) لفهم سبب بناء المحرك بهذه الطريقة وما هي التغييرات المحددة التي ستنجح بالفعل. لا يصعد النظام هذا السلم إلا عندما لا تكفي الخطوات الأدنى، مما يوفر الوقت والطاقة.

اختبر الباحثون هذا النظام على 37 برنامجاً مختلفاً (kernels) مصممة لرقائق Huawei Ascend 950. ووجدوا أنه باستخدام هذا العمل التحقيقي خطوة بخطوة، تمكنوا من جعل البرامج تعمل بشكل أسرع بكثير. في المتوسط، كانت البرامج المحسّنة أسرع بـ 4.35 مرة من النسخ الأصلية. وبالنسبة لنصف البرامج، كانت نسبة التسريع لا تقل عن 2.73 مرة. وشهدت بعض البرامج تحسينات هائلة، حيث عملت بسرعة 5 أضعاف أو أكثر، بينما لم تتغير أخرى كثيراً، مما يظهر أن النظام ليس عصا سحرية تصلح كل شيء فوراً، ولكنه أداة قوية للوظائف المناسبة.

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

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →