نماذج ومنصات الذكاء الاصطناعي

IBM تجعل مُسرِّع Spyre واجهة خلفية من الدرجة الأولى في PyTorch

mm
أضف Unite.AI إلى مصادرك المفضلة على Google

قالت IBM في منشور على مدونة IBM Research نُشر في 26 أكتوبر 2026، إن تحديثات البرامج التي طُرحت في منظومة PyTorch خلال النصف الثاني من عام 2026 جعلت مُسرِّع تدفق البيانات Spyre واجهة خلفية أساسية في PyTorch، محققةً بذلك خطة أعلنتها IBM ومؤسسة PyTorch في أكتوبر 2025.

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

يفيد المنشور بأن IBM وRed Hat والمتعاونين ضمن مؤسسة PyTorch، ومنهم Meta وHugging Face، طرحوا في النصف الثاني من عام 2026 تحديثات شملت إتاحة النماذج منذ اليوم الأول، ونماذج غير مرتبطة بنوع العتاد في vLLM، واختبارات الانحدار والإصدارات المستمرة، والتكامل مع الأجهزة الأصلية. وفي مؤتمر PyTorch لعام 2025، قالت IBM في منشور على IBM Research مؤرخ في 21 أكتوبر 2025، إنها تخطط لتعميق دعم Spyre في عام 2026، بحيث يعمل Spyre واجهةً خلفية أساسية ضمن مسارات عمل الاستدلال مفتوحة المصدر، مع التركيز على مسارات موحّدة للمُصرِّف، وتوليد النوى المحسّنة، والجدولة الشفافة لمسرّعات متعددة. وكانت IBM قد اعتمدت حينها vLLM بيئة تشغيل للاستدلال وtorch.compile مُصرِّفًا أماميًا لدمج مسرّعات مثل Spyre، كما ساهمت بإضافة مكوّن إضافي لـSpyre إلى vLLM يتيح آلية الانتباه المُقسَّم إلى صفحات للاستدلال باستخدام نماذج اللغة الكبيرة.

إعادة بناء المُصرِّف اعتمادًا على Inductor

يتمحور التكامل حول torch-spyre، وهي واجهة خلفية لـPyTorch تُحوِّل الشيفرة العادية في PyTorch إلى خطة تنفيذية قابلة للتشغيل على Spyre. ويمر معظم منطق النموذج عبر مُصرِّف PyTorch من دون تغيير؛ أما إذا تعذّر حتى الآن تحويل عملية ما بكفاءة إلى تعليمات منخفضة المستوى، فيمكن لمحوِّل استبدالها بصيغة مكافئة رياضيًا يستطيع المُصرِّف التعامل معها.

في منشور لمؤسسة PyTorch نُشر في 13 أكتوبر 2026، وصف Dave Grove وOlivier Tardieu وفريق IBM Spyre نقل واجهة torch.compile الخلفية في torch-spyre من sendnn، وهي حزمة ترجمة بُنيت بالكامل من الصفر، إلى backend=inductor، وهي واجهة خلفية مفتوحة المصدر طُوّرت بتوسيع Inductor، أداة PyTorch نفسها. ووفقًا للمؤلفين، يُظهر القياس باستخدام محلل الشيفرة lizard أن sendnn يضم نحو 273,000 سطر من C++ وPython موزعة على 6,170 دالة، بينما تضم إضافة Inductor نحو 38,600 سطر من Python موزعة على 1,878 دالة؛ أي أسطر أقل بنحو 7 أضعاف، مع انخفاض تعقيد كل دالة.

Spyre مُسرِّع بقدرة 75 واط يتصل عبر PCIe، ويتكوّن من 32 نواة صغيرة مترابطة في حلقة، لكل منها مساحة تخزين مؤقتة محلية بسعة 2 MB بدلًا من ذاكرة تخزين مؤقت مشتركة. وينقل الجهاز البيانات في كتل ثابتة الحجم، تبلغ 128 بايت، تُسمى sticks. ويشير المنشور إلى أن عمل المُصرِّف ركّز على نقل البيانات بمستوى دقة sticks، والتخطيط لاستخدام مساحة التخزين المؤقتة المحلية، وتخصيص الأنوية في وقت الترجمة.

تشمل القياسات المُعلنة خفض زمن نواة ضرب المصفوفات بنسبة تتراوح بين 29 و69% بفضل خيارات تقسيم البيانات إلى كتل وتنسيقها، وانخفاض وسيط زمن نواة softmax من 32.51 ميكروثانية إلى 23.67 ميكروثانية — أي تراجع بنسبة 27% — بفضل الجدولة التي تراعي مساحة التخزين المؤقتة المحلية، فضلًا عن نواة مدمجة على نمط MLP رفعت استغلال الأنوية من نحو الثلثين إلى قرابة 80%، وخفضت زمن النواة بنحو 17%. وفي رسم بياني اصطناعي أُنشئ لاختبار هذه الخيارات، استبدلت إعادةُ ترتيب البيانات الجديدة على الشريحة رحلةَ ذهاب وإياب إلى ذاكرة الجهاز، كانت تستغرق 80 ميكروثانية، بعملية تبديل بين الأنوية تستغرق 1.1 ميكروثانية. ويشير المنشور أيضًا إلى أن حاجة torch-spyre إلى تسجيل عمليات تفكيك خاصة بالجهاز أسهمت في تحسين دعم واجهات Inductor الخلفية الخارجية، وهي تحسينات أُدرجت في PyTorch 2.12 ضمن طلبي دمج.

التكامل مع الأجهزة الأصلية

يصبح Spyre جهازًا أصليًا في PyTorch من خلال التسجيل باستخدام PrivateUse1، ما يمنح tensor.to(“spyre”) هوية جهاز فعلية: إذ تُبقي مساحة التخزين التي يخصصها PyTorch الموترات مقيمة على الجهاز، وتوفّر مسارات التنفيذ دلالات الترتيب، فيما تربط أحداث بيئة التشغيل الأعمال المعتمدة بعضها على بعض عبر تلك المسارات. وتضم البطاقة 32 نواة متصلة بحلقة عالية النطاق الترددي، لكل منها مساحة تخزين مؤقتة محلية بسعة 2 MB، كما توفر ما يصل إلى 128 GB من ذاكرة LPDDR5 للموترات والبرامج. وتُجري بيئة التشغيل الحالية تعديلات على البرامج عند إطلاقها، إذ تستبدل عناوين الموترات الرمزية بعناوين فعلية عبر ثلاث خطوات مرتبة.

أفاد الفريق بأن نقل إنشاء الرسم البياني خارج مسار نقل البيانات حسّن مرحلة التمهيد بنسبة 9.9% وفك الترميز بنسبة 13.6%، في عرض توضيحي باستخدام Granite 3.3 8B بحجم دفعة 1 وطول تسلسل 1024. وأدى إخراج هذه العملية من مسار إرسال المهام الحسابية أيضًا إلى بلوغ التحسن الإجمالي 1.7x في سرعة التمهيد و2.4x في سرعة فك الترميز، مع إسهام مسار العمليات الحسابية بنحو ثلاثة أرباع المكاسب.

كتب المؤلفون في بناء Spyre بوصفه جهازًا أصليًا في PyTorch، المنشور في 8 أكتوبر 2026: «تكمن الميزة في أن Spyre وPyTorch ليسا مضطرين إلى التظاهر بأنهما شيء آخر»، وأضافوا أن Spyre يحتفظ بنموذجه التنفيذي القائم على تدفق البيانات، فيما يحصل المستخدمون على جهاز أصلي في PyTorch يتيح لهم التعامل بأساليب مألوفة لتحديد مواضع الموترات واستخدام مسارات التنفيذ والترجمة.

قابلية نقل vLLM والارتباط بـLlm-D

Spyre مسرّع غير مدمج في الشجرة المصدرية، وليس من منصات وحدات معالجة الرسومات الأكثر شيوعًا في دعم برامج الذكاء الاصطناعي؛ إذ يعتمد على TorchDynamo لتتبّع رسم النموذج، وعلى TorchInductor لخفض ذلك الرسم بما يلائم العتاد المستهدف. وفي vLLM، تتيح آليات التوسعة مثل CustomOp وPluggableLayer للمكوّن الإضافي الخاص بالعتاد تخصيص السلوك من دون إعادة تنفيذ أجزاء كبيرة من حزمة البرمجيات.

في نماذج مستقلة عن العتاد في vLLM، المنشور في 22 سبتمبر 2026 بأسماء مؤلفين من IBM وMeta وHugging Face، وصف الفريق تحوّل vLLM نحو تعريفات نماذج «مسطّحة» خاصة بالعتاد، وقدم طبقات مستقلة عن العتاد تستند إلى أربعة مبادئ تصميمية: قابلة للترجمة، وقابلة للتوسعة، ومعزولة عن المسارات الخاصة بالعتاد، وقابلة للنقل. أُتيح الدعم الأولي في الفرع الرئيسي لـvLLM، ويمكن تفعيله باستخدام USE_HW_AGNOSTIC=1 في الواجهة الخلفية لـtransformers. واختُبر هذا المسار باستخدام المكوّن الإضافي لـSpyre غير المدمج في الشجرة المصدرية على نماذج تشمل Gemma 4 وQwen3 وGranite 4.2؛ وعلى وحدات معالجة الرسومات NVIDIA H100، حققت الطبقات المستقلة عن العتاد إجمالي معدل معالجة للرموز يقل عن التنفيذ الأصلي بنسبة 3.4%، وفقًا لما أورده المؤلفون، وذلك بقياس المتوسط الهندسي عبر ثلاثة نماذج حديثة.

يوضح منشور IBM أن تكامل Spyre مع PyTorch هو أيضًا وسيلة اتصاله بـllm-d: إذ ينفّذ llm-d الاستدلال الموزع باستخدام vLLM عبر أنواع متعددة من المسرّعات، ويصل vLLM إلى كل مسرّع من خلال PyTorch، وبمجرد أن يتوفر للجهاز نظام خلفي عامل لـPyTorch، يمكن لمكوّن إضافي للعتاد في vLLM إتاحته كي يتمكن llm-d من جدولة المهام عليه.

التمكين منذ اليوم الأول والاختبار المستمر

يصف منشور بتاريخ 20 أغسطس 2026 صادر عن فريق IBM Spyre مشروع HF-adapters، الذي يستخدم وكلاء البرمجة لإعداد تصحيحات وقت التشغيل، بما يتيح تشغيل نماذج Hugging Face Transformers القياسية على Spyre. ويفيد المنشور بأنه بين منتصف أبريل وأواخر يونيو 2026، وصل عدد المحوّلات المختلفة إلى 13، لتغطي 7,960 نموذجًا من بين أكثر 10,000 نموذج تضمين تنزيلًا على Hugging Face، اجتاز 6,804 منها اختبارًا شاملًا على Spyre. وفي أحد الأمثلة، استُبدل التعبير torch.pow(x, 3.0) في دالة التنشيط gelu_new بالتعبير المكافئ له رياضيًا x x x، الذي تستطيع حزمة torch-spyre خفضه؛ بينما يظل تشخيص الأعطال من مسؤولية البشر، إذ يحددون حالات الإخفاق التي لا تظهر إلا على الجهاز والناشئة عن العمليات المدمجة، ويتحققون من استنتاجات كل وكيل بمقارنتها بنتائج الاختبارات الشاملة.

في منشور بتاريخ 30 سبتمبر 2026، وصف مهندسون من IBM وRed Hat تكامل المستوى الثاني في torch-spyre مع مرحّل التكامل المستمر بين المستودعات في PyTorch، الذي يطلق اختبارات لاحقة عند إجراء تغييرات في PyTorch الأساسي، ويرسل النتائج إلى لوحة معلومات التكامل المستمر الخاصة بـPyTorch. ويجمع هذا التكامل بين خط أنابيب لاختيار الاختبارات قائم على الوكلاء ومكوّن من أربع مراحل، وإطار عمل تصريحي لإعادة استخدام الاختبارات بصيغة YAML. وكتب المؤلفون أن الترقية من PyTorch 2.13 إلى 2.14 تطلبت تقييم نحو 4,000 اختبار متغير بدلًا من عشرات الآلاف، وأضافوا أنهم يعتزمون العمل مع فريق PyTorch لإدراج الأجزاء القابلة لإعادة الاستخدام في المشروع الأساسي، مع اعتماد PyTorch OpenReg نقطةً مرجعية.

يذكر منشور IBM أن التجربة المنشودة لمستخدمي IBM Z وLinuxONE وPower11 هي الحصول على النماذج من منظومات مثل Hugging Face واستخدام مسارات العمل القائمة على PyTorch نفسها إلى حد كبير التي يستخدمونها مع وحدات معالجة الرسومات من Nvidia، مع إخفاء نقاط التوسعة المشتركة في PyTorch جانبًا كبيرًا من الاختلافات المعمارية. وقال مؤلفو منشور vLLM إنهم يعتزمون البدء بإدراج النماذج المستقلة عن العتاد في التكامل المستمر، والتحول تدريجيًا إلى هذا المسار ليصبح الخيار الافتراضي لخدمة النماذج على Spyre.

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

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

المقالات التي يكتبها Theo Nash مُولَّدة بالذكاء الاصطناعي وتُراجَع من قِبل فريق التحرير في Unite.AI لضمان الدقة التقنية، الوضوح، وتغطية مسؤولة للمشهد المتطور سريعًا في حوسبة الذكاء الاصطناعي.