PHP و RubixML ينتقلان من المصفوفات إلى GPU: كيف يتغير نهج التعلم الآلي في النظام البيئي

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

في البداية، بدا مسار PHP نحو التعلم الآلي منطقيًا تمامًا. احتفظت المكتبات الأولى، بما في ذلك PHP-ML والإصدارات المبكرة من RubixML، بالمصفوفات كمصفوفات من المصفوفات وقامت بتنفيذ جميع العمليات مباشرة في المُفسّر. بالنسبة للمطورين، كان هذا مريحًا: لا شيء يحتاج إلى ترجمة، كان الكود شفافًا، كان سهلاً تصحيح الأخطاء، والخوارزميات الأساسية مثل k-NN والانحدار اللوجستي أو المصنفات البسيطة يمكن تجميعها حرفيًا في فترة مسائية.

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

الأرقام هنا لا توجد كمبتدئات مدمجة، بل كهياكل zval أثقل. يتم تنظيم المصفوفات بشكل عام كجداول التجزئة، وليس كتكتلات ذاكرة متجاورة كثيفة. لهذا السبب، يكلف كل وصول إلى عنصر أكثر، يتم استخدام ذاكرة تخزين مؤقت CPU بشكل أسوأ، لا توجد متجهة SIMD تلقائية، ويمكن لآلية النسخ عند الكتابة أن تنتفخ الذاكرة بشكل غير متوقع وتضيف عمليات تخصيص غير ضرورية.

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

وهكذا ظهر Rubix Tensor و NDArray، حيث تقيم البيانات الآن في ذاكرة متجاورة، أقرب إلى كيفية تنظيمها في NumPy. في حالة NDArray، يتم استخدام Rust لهذا، مما يسمح بزيادة الأداء مع تجنب بعض المشاكل النموذجية لإدارة الذاكرة اليدوية. من الخارج، تبقى واجهة البرمجة الموحدة مألوفة، لكن من الداخل يتغير كل شيء تقريبًا: يختفي zval لكل عنصر، يتلاشى نموذج جدول التجزئة، والكود يصبح أقرب إلى الترميز الرياضي.

في المقارنات العملية، هذا واضح على الفور: ضرب مصفوفات 500 في 500 على المصفوفات يستغرق حوالي 10-20 ثانية، على Tensor على CPU — حوالي 0.3-0.8 ثانية، ومسار GPU التجريبي من خلال NumPower — بالفعل حوالي 0.

05-0.2 ثانية. لكن الهياكل الأصلية أظهرت بسرعة سقفًا جديدًا: حتى وحدة المعالجة المركزية المحسنة جيدًا تبقى وحدة معالجة مركزية.

بالنسبة للتضمينات والشبكات العصبية وعمليات المصفوفة الكبيرة، هذا غير كافٍ بالفعل، وبالتالي فإن الاستمرار المنطقي كان التحول نحو وحدات معالجة الرسوميات. حول RubixML v3 و NumPower، يتشكل نموذج جديد، حيث تتحمل PHP مسؤولية التنسيق، وتتولى Tensor و NumPower الطبقة الحسابية، وتصبح وحدة معالجة الرسوميات المكان الذي تعيش فيه الرياضيات الثقيلة. هذا يتوافق جيدًا مع كيفية عمل الأدوات عالية المستوى مثل transformers-php و LLPhant أو Neuron AI اليوم: يصف كود PHP هناك خط الأنابيب وتحميل النموذج واستدعاءات الاستدلال ومعالجة النتائج، لكنه لا يحاول حساب المصفوفات والحلقات يدويًا حيث توجد وقتات تشغيل أكثر ملاءمة بالفعل.

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

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