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

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

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

لكن بمجرد أن تبدأ البيانات في النمو، تتحول هذه الراحة سريعًا إلى عنق زجاجة. والسبب لا يعود إلى حلقات تكرارية سيئة ولا إلى ضعف تنفيذ مكتبات بعينها، بل إلى النموذج الداخلي لـPHP نفسه. فالأرقام هنا لا تُخزَّن كأنواع بدائية مدمجة، بل كهياكل zval أثقل. والمصفوفات مبنية في الحالة العامة كجداول تجزئة (hash tables)، لا ككتل ذاكرة كثيفة متصلة. ولذلك يصبح الوصول إلى كل عنصر أغلى، ويُستخدم كاش المعالج بصورة أسوأ، ولا توجد تجهيهات SIMD تلقائية، وقد تؤدي آلية copy-on-write إلى تضخم مفاجئ في الذاكرة وتخصيصات إضافية. وحتى الحيل المفيدة، مثل تبديل مصفوفات مسبقًا (transposition) أو إخراج count من الحلقات، لا تعطي سوى مكسب محدود. فهي تجعل الشيفرة أقل بطئًا قليلًا، لكنها لا تحوّل PHP إلى بيئة للجبر الخطي الفعّال.

بدأت المرحلة التالية من التطور حين تخلّى المطوّرون عن فكرة تخزين المصفوفات كمصفوفات PHP عادية. هكذا ظهرت Rubix Tensor وNDArray، حيث تُخزَّن البيانات في ذاكرة متصلة (contiguous memory)، أقرب إلى بنية NumPy. وفي حالة NDArray تُستخدم Rust لهذا الغرض، مما يرفع الأداء ويجنّب في الوقت نفسه جزءًا من المشكلات المعتادة في إدارة الذاكرة يدويًا. من الخارج تبقى واجهة API مألوفة، لكن الداخل يتغير تقريبًا بالكامل: يختفي zval لكل عنصر، وينتهي نموذج جداول التجزئة، وتقترب الشيفرة من الصياغة الرياضية. وتظهر النتيجة فورًا في المقارنات العملية: ضرب مصفوفتين بحجم 500 في 500 على المصفوفات يستغرق نحو 10–20 ثانية، وعلى Tensor باستخدام CPU نحو 0,3–0,8 ثانية، أما المسار التجريبي عبر GPU باستخدام NumPower فيستغرق نحو 0,05–0,2 ثانية.

غير أن الهياكل الأصلية سرعان ما كشفت عن سقف جديد: فحتى المعالج المركزي المحسَّن جيدًا يبقى معالجًا مركزيًا. وهذا لا يكفي لـembeddings والشبكات العصبية والعمليات المصفوفية الكبيرة، ولذلك كان التوجه نحو GPU امتدادًا منطقيًا. وحول RubixML v3 وNumPower يبدأ تشكّل نموذج جديد: تتولى PHP مهمة orchestration، وتتحمل Tensor وNumPower طبقة الحوسبة، ويصبح GPU المكان الذي تجري فيه الحسابات الثقيلة. ويتوافق ذلك مع طريقة عمل الأدوات الأعلى مستوى اليوم، مثل transformers-php وLLPhant وNeuron AI: فشيفرة PHP هناك تصف خط المعالجة وتحميل النموذج واستدعاء inference ومعالجة النتيجة، لكنها لا تحاول حساب المصفوفات والحلقات يدويًا حيث توجد بيئات تشغيل أنسب لذلك.

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