ميتا تسرّع نواة GPU بأربعة أضعاف باستخدام TLX، امتداد للغة Triton

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

وصفت ميتا TLX، وهو امتداد لـ Triton لإدارة العمل المشترك بين مجموعات خيوط GPU. وفي أحد الأمثلة الخاصة بأنظمة التوصية، تعلن الشركة عن تسريع نواة منفردة بمقدار 4 أضعاف على H100 بعد سلسلة من التحسينات. هذه نتيجة هندسية مفيدة، لكن لا يجوز تعميم هذا الرقم على الخدمة بأكملها.

كيف يعيق تحميل البيانات الحساب

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

والتشبيه المناسب هو المطبخ. فبينما يحضر موظف الدفعة التالية من المكونات، يطهو آخر ما وصل بالفعل. أما إذا اضطر الطباخ إلى الذهاب بنفسه إلى المخزن في كل مرة، فلن تنقذه أفضل موقد من فترات التوقف. وفي GPU تُعالَج مشكلة مشابهة بتداخل نقل البيانات مع الحساب.

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

والسؤال العملي هنا بسيط: هل تصل الدفعة التالية من البيانات في الوقت الذي تلزم فيه؟ إذا كان الجواب نعم، تقلّ دواعي توقف الجزء الحسابي. وإذا كان لا، فينبغي مراجعة حجم الدفعات والمخازن المؤقتة والتبعيات.

ماذا يعني التسريع بأربعة أضعاف

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

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

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

من أين يبدأ فريقكم

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

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

وثمة حدّ آخر للتوقعات: الحصول التلقائي على نوى TLX عبر torch.compile تصفه ميتا بأنه اتجاه عمل. ولذلك ينبغي التخطيط للتبنّي بناءً على الإمكانات المتاحة وعلى تجربتكم الخاصة.

الخلاصة العملية: يستحق TLX اهتمام الفرق التي تحسّن نوى GPU بالفعل وتعرف اختناقاتها. أما بالنسبة إلى المؤسس، فالخطوة الأولى أقل كلفة: معرفة أي حصة من فاتورة البنية التحتية ترتبط بحسابات يمكن تسريعها فعلًا.

المصدر: Meta Engineering.