PHP et RubixML passent des tableaux à GPU : comment l'approche du ML évolue dans l'écosystème

L'écosystème PHP s'éloigne de plus en plus de l'idée que l'apprentissage automatique peut être construit sérieusement sur des tableaux ordinaires. Le principal changement n'est pas dans les nouveaux algorithmes, mais dans une modification du rôle du langage lui-même : PHP cesse d'être un moteur de calcul et devient de plus en plus un orchestrateur qui lance des pipelines, lie des bibliothèques et délègue les mathématiques lourdes aux extensions natives et aux GPUs. Sur ce fond, le tournant de RubixML et des projets connexes comme Tensor et NumPower est révélateur : pour les opérations matricielles, la différence se mesure désormais non en pourcentages mais en ordres de grandeur, passant de dizaines de secondes sur des tableaux à des fractions de seconde sur des structures natives et des backends GPU expérimentaux.

Initialement, la trajectoire de PHP dans le ML semblait assez logique. Les premières bibliothèques, y compris PHP-ML et les versions précoces de RubixML, stockaient les matrices sous forme de tableaux de tableaux et effectuaient toutes les opérations directement dans l'interpréteur. Pour les développeurs, c'était pratique : rien n'avait besoin d'être compilé, le code était transparent, il était facile à déboguer, et des algorithmes de base comme k-NN, la régression logistique ou de simples classificateurs pouvaient être assemblés littéralement en une soirée.

Cette approche reste utile dans l'éducation et le prototypage, car elle permet de parcourir manuellement tout le chemin du produit scalaire à la propagation avant du plus simple réseau de neurones. Mais dès que les données commencent à croître, la commodité se transforme rapidement en goulot d'étranglement. La raison n'est pas dans les boucles inefficaces ou dans une mauvaise implémentation de bibliothèques individuelles, mais dans le modèle interne de PHP lui-même.

Les nombres ici existent non comme des primitives compactes, mais comme des structures zval plus lourdes. Les tableaux en général sont organisés comme des tables de hachage, et non comme des blocs de mémoire contiguës denses. De ce fait, chaque accès à un élément coûte plus cher, le cache CPU est utilisé moins bien, il n'y a pas de vectorisation SIMD automatique, et le mécanisme copy-on-write peut inopinément gonfler la mémoire et ajouter des allocations inutiles.

Même les astuces utiles comme la transposition préalable des matrices ou l'extraction de count en dehors des boucles n'apportent que des gains limités. Elles rendent le code un peu moins lent, mais ne transforment pas PHP en un environnement pour l'algèbre linéaire efficace. La prochaine étape de l'évolution a commencé quand les développeurs ont abandonné l'idée même de stocker les matrices comme des tableaux PHP ordinaires.

C'est ainsi que Rubix Tensor et NDArray ont vu le jour, où les données résident maintenant en mémoire contiguë, plus proche de la façon dont c'est organisé dans NumPy. Dans le cas de NDArray, Rust est utilisé pour cela, ce qui permet d'augmenter les performances tout en évitant une partie des problèmes typiques de la gestion manuelle de la mémoire. De l'extérieur, l'API reste familière, mais en interne, presque tout change : zval pour chaque élément disparaît, le modèle de table de hachage s'efface, et le code devient plus proche de la notation mathématique.

Dans les comparaisons pratiques, cela se voit immédiatement : multiplier des matrices de 500 par 500 sur des tableaux prend environ 10–20 secondes, sur Tensor sur CPU — environ 0,3–0,8 secondes, et le chemin GPU expérimental via NumPower — déjà autour de 0,05–0,2 secondes. Mais les structures natives ont rapidement montré un nouveau plafond : même un CPU bien optimisé reste un CPU. Pour les embeddings, les réseaux de neurones et les grandes opérations matricielles, c'est déjà insuffisant, de sorte que la continuation logique a été un basculement vers les GPU.

Autour de RubixML v3 et NumPower, un nouveau modèle se dessine, où PHP est responsable de l'orchestration, Tensor et NumPower prennent en charge la couche computationnelle, et GPU devient le lieu où vivent les mathématiques lourdes. Cela s'aligne bien avec la façon dont les outils de plus haut niveau comme transformers-php, LLPhant ou Neuron AI fonctionnent aujourd'hui : le code PHP décrit le pipeline, le chargement du modèle, les appels d'inférence et le traitement des résultats, mais ne tente pas de calculer manuellement les matrices et les boucles où des runtimes plus appropriés existent déjà. Cela signifie que PHP en IA n'a pas tant une chance de rattraper Python en tant qu'environnement de calcul, mais plutôt une opportunité d'occuper sa propre niche claire.

Le langage reste fort là où il est nécessaire d'intégrer rapidement des fonctionnalités de ML ou LLM dans une application web, une SaaS, un scénario d'agent ou un pipeline d'entreprise. Mais pour y parvenir, l'écosystème a dû accepter une conclusion désagréable, mais honnête : pour que PHP participe au ML moderne, il n'a pas besoin de tout calculer lui-même. Sa valeur réside de plus en plus dans le fait d'être la colle entre les modèles, les données, l'infrastructure et l'interface, plutôt que d'être un remplacement pour les GPU ou les bibliothèques bas niveau.