IBM Spyre ينقل torch.compile من sendnn المطوَّر داخليًا إلى Inductor المفتوح

يضم IBM Spyre 32 نواة تسريع وما يصل إلى 128 ГБ من ذاكرة LPDDR5 على بطاقة PCIe واحدة، وقد أصبح لديه الآن مترجم مختلف في PyTorch. فقد انتقلت حزمة برمجيات Spyre من sendnn، وهو نظام ترجمة مستقل كُتب من الصفر، إلى backend=inductor. وهذه هي الواجهة الخلفية المفتوحة لـ torch.compile، والمستخدمة افتراضيًا في PyTorch. وجاء ذلك وفق ما نشرته مدونة PyTorch Blog. ولا يتضمن الجزء المتاح من الإعلان سوى الإشارة إلى تغيير الواجهة الخلفية، دون أي اختبارات أداء، لذا لا يسعنا إلا تقييم الجدوى المعمارية للخطوة.

ما الذي تغيّر بالضبط

كان مسار النموذج على Spyre حتى الآن على النحو التالي: يستدعي المستخدم torch.compile، فينتقل الرسم البياني (graph) إلى sendnn، ثم يتولى مترجم IBM كل شيء بعد ذلك، وهو مترجم منفصل عن بقية منظومة PyTorch. أما الآن فيمرّ الرسم البياني عبر Inductor، الذي يتولى التقاط الرسم البياني وتفكيك العوامل (operators) وجدولة النوى ودمجها. ولا يتعامل مع خصوصيات Spyre سوى امتداد (extension) مرتبط بـ Inductor.

وهذا المخطط معتاد في Inductor. فهو يولّد شيفرة Triton لوحدات GPU وشيفرة C++ لوحدات CPU، وتتيح نقاط التوسعة فيه ربط أجهزة خارجية دون الحاجة إلى نسخ المترجم بالكامل (fork). وبذلك يصبح Spyre جهازًا آخر من هذا النوع.

لماذا لا مترجم خاص

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

وباستخدام Inductor تحصل IBM على جزء من هذا العمل مجانًا:

• تفكيك العوامل الذي يدعمه مجتمع PyTorch؛
• تحسينات الرسم البياني العامة ودمج العمليات؛
• مسار موحّد لتصحيح الأخطاء والتحليل (profiling) مألوف للمطورين الذين عملوا سابقًا مع وحدات GPU؛
• حجم أقل من الشيفرة التي يتعيّن على IBM صيانتها بنفسها.

لكن هناك ثمنًا أيضًا. فقد صُمم Inductor حول وحدات GPU وCPU بما لها من نماذج الذاكرة والتوازي. أما Spyre فمختلف في بنيته: فهو مسرّع له تنظيمه الخاص للحوسبة والبيانات. وبعض التحسينات التي كان sendnn ينفذها مباشرة على مستوى العتاد يجب الآن التعبير عنها عبر امتدادات Inductor، وقد يتبيّن أن ذلك أصعب مما يبدو.

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

نشأ Spyre من رقاقة IBM البحثية AIU، ويستهدف الاستدلال (inference) في أنظمة المؤسسات، وفي المقام الأول على حواسيب IBM Z المركزية (mainframes) وخوادم Power. وفيما يلي أبرز المواصفات بحسب البيانات العلنية من IBM:

• 32 نواة تسريع؛
• نحو 25,6 مليار ترانزستور، بتقنية تصنيع 5 نانومتر؛
• حتى 128 ГБ من ذاكرة LPDDR5 على البطاقة؛
• بصيغة PCIe، وبقدرة تقارب 75 واط للبطاقة؛
• السيناريو المستهدف: استدلال النماذج التوليدية والكلاسيكية داخل محيط المؤسسة.

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

من الناحية العملية

ما دامت جداول السرعة وتغطية العوامل غير متاحة علنًا، فينبغي تقييم هذا الانتقال وفق عدة مؤشرات:

1. هل يعمل نموذجك مع backend=inductor على Spyre دون تعديلات، وكم عدد انقطاعات الرسم البياني (graph breaks) التي تبقى بعد الترجمة. 2. كيف تغيّر زمن الترجمة مقارنةً بـ sendnn، خصوصًا مع نماذج LLM الكبيرة ذات الأشكال الديناميكية. 3. هل الأداء على نماذجك مماثل للواجهة الخلفية السابقة. وإن لم يكن كذلك، فيجب البحث عن المواضع التي لا يستغل فيها امتداد Inductor قدرات العتاد. 4. ما سرعة ظهور إصدارات PyTorch الجديدة في الحزمة. وهذا هو المكسب العملي الرئيسي من تغيير المعمارية: فكلما قلّت الشيفرة الخاصة، قصر التأخر.

ومن المنطقي للفرق التي تخطط للاستدلال على IBM Z أو Power أن تجمع مباشرةً مجموعة اختبار من نماذجها وتشغّلها على الواجهتين الخلفيتين، ما دام sendnn لا يزال متاحًا للمقارنة. وإذا تعامل Inductor مع ذلك دون خسارة في السرعة، فسيقل سبب واحد يميّز Spyre عن بقية المسرّعات في PyTorch.