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

L'écosystème PHP s'éloigne nettement de l'idée qu'on puisse bâtir sérieusement du machine learning sur de simples tableaux. Le principal changement ne tient pas à de nouveaux algorithmes, mais au 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, relie des bibliothèques et confie les mathématiques lourdes à des extensions natives et aux GPU. Dans ce contexte, le virage de RubixML et de projets associés comme Tensor et NumPower est révélateur : pour les opérations matricielles, l'écart ne se mesure plus en pourcentages, mais en ordres de grandeur, de dizaines de secondes avec des tableaux à des fractions de seconde avec des structures natives et des backends GPU expérimentaux.

Au départ, la voie de PHP vers le ML paraissait tout à fait logique. Les premières bibliothèques, dont PHP-ML et les premières versions de RubixML, stockaient les matrices sous forme de tableaux de tableaux et exécutaient toutes les opérations dans l'interpréteur. C'était pratique pour le développeur : rien à compiler, un code transparent et facile à déboguer, et des algorithmes de base comme k-NN, la régression logistique ou de simples classifieurs pouvaient être assemblés littéralement en une soirée. Cette approche reste utile pour l'apprentissage et le prototypage, car elle permet de parcourir à la main tout le chemin, du produit scalaire à la passe avant d'un réseau de neurones élémentaire.

Mais dès que les données grossissent, cette commodité devient vite un goulot d'étranglement. La cause n'est ni des boucles mal écrites ni la mauvaise implémentation de telle ou telle bibliothèque, mais le modèle interne même de PHP. Ici, les nombres ne vivent pas comme des primitives compactes, mais comme des structures zval plus lourdes.

Les tableaux sont, en général, des tables de hachage et non des blocs de mémoire denses et contigus. Résultat : chaque accès à un élément coûte plus cher, le cache du CPU est moins bien exploité, il n'y a pas de vectorisation SIMD automatique, et le mécanisme de copy-on-write peut gonfler la mémoire de façon inattendue et ajouter des allocations superflues. Même des astuces utiles, comme transposer les matrices à l'avance ou sortir count des boucles, n'apportent qu'un gain limité.

Elles rendent le code un peu moins lent, mais ne font pas de PHP un environnement adapté à l'algèbre linéaire efficace.

L'étape suivante de l'évolution a commencé quand les développeurs ont renoncé à stocker les matrices comme de simples tableaux PHP. C'est ainsi que sont apparus Rubix Tensor et NDArray, où les données résident en mémoire contiguë, plus proche du fonctionnement de NumPy. Pour NDArray, on utilise Rust, ce qui améliore 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 à l'intérieur presque tout change : le zval par élément disparaît, le modèle de table de hachage s'efface, et le code se rapproche de la notation mathématique. Dans les comparaisons pratiques, cela saute aux yeux : multiplier des matrices de 500 par 500 prend environ 10 à 20 secondes avec des tableaux, autour de 0,3 à 0,8 seconde avec Tensor sur CPU, et la voie GPU expérimentale via NumPower de l'ordre de 0,05 à 0,2 seconde.

Mais les structures natives ont elles aussi rapidement atteint un nouveau plafond : même un CPU bien optimisé reste un CPU. Pour les embeddings, les réseaux de neurones et les grosses opérations matricielles, cela ne suffit plus, et le virage vers le GPU s'est imposé comme la suite logique. Autour de RubixML v3 et de NumPower, un nouveau modèle commence à se dessiner : PHP gère l'orchestration, Tensor et NumPower prennent en charge la couche de calcul, et le GPU devient l'endroit où vivent les mathématiques lourdes.

Cela correspond bien au fonctionnement actuel d'outils de plus haut niveau comme transformers-php, LLPhant ou Neuron AI : le code PHP y décrit le pipeline, le chargement du modèle, l'appel d'inférence et le traitement du résultat, mais n'essaie pas de calculer à la main matrices et boucles là où existent déjà des environnements d'exécution plus adaptés.

Autrement dit, pour PHP, l'enjeu en IA n'est pas tant de rattraper Python comme environnement de calcul que d'occuper une niche claire qui lui soit propre. Le langage reste solide quand il faut intégrer rapidement des fonctions de ML ou de LLM dans une application web, un SaaS, un scénario d'agents ou un pipeline d'entreprise. Mais pour cela, 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 tient de plus en plus à son rôle de liant entre modèles, données, infrastructure et interface, et non de remplaçant du GPU ou des bibliothèques de bas niveau.