PHP y RubixML transitan de arrays a GPU: cómo está cambiando el enfoque de ML en el ecosistema

El ecosistema PHP se está alejando cada vez más de la idea de que el aprendizaje automático puede construirse seriamente en arrays ordinarios. El cambio principal ahora no está en nuevos algoritmos, sino en un cambio en el papel del propio lenguaje: PHP está dejando de ser un motor computacional y se está convirtiendo cada vez más en un orquestrador que lanza pipelines, vincula bibliotecas y delega las matemáticas pesadas a extensiones nativas y GPUs. En este contexto, el giro de RubixML y proyectos relacionados como Tensor y NumPower es revelador: para operaciones de matriz, la diferencia ahora se mide no en porcentajes sino en órdenes de magnitud, de decenas de segundos en arrays a fracciones de segundo en estructuras nativas y backends de GPU experimentales.

Inicialmente, el camino de PHP en ML parecía bastante lógico. Las primeras bibliotecas, incluidas PHP-ML y versiones tempranas de RubixML, almacenaban matrices como arrays de arrays y ejecutaban todas las operaciones directamente en el intérprete. Para los desarrolladores, esto era conveniente: nada necesitaba compilarse, el código era transparente, era fácil de depurar, y algoritmos básicos como k-NN, regresión logística o clasificadores simples podían armarse literalmente en una noche.

Este enfoque sigue siendo útil en educación y prototipado, porque permite trabajar manualmente a través de todo el camino desde el producto escalar hasta la propagación directa de la red neuronal más simple. Pero tan pronto como los datos comienzan a crecer, la conveniencia se convierte rápidamente en un cuello de botella. La razón no está en bucles fallidos o en la mala implementación de bibliotecas individuales, sino en el modelo interno del propio PHP.

Los números aquí viven no como primitivos compactos, sino como estructuras zval más pesadas. Los arrays en general están organizados como tablas hash, no como bloques de memoria continuos densos. Debido a esto, cada acceso a un elemento cuesta más, el caché de CPU se utiliza peor, no hay vectorización SIMD automática, y el mecanismo de copia en escritura puede inesperadamente hinchar la memoria y agregar asignaciones innecesarias.

Incluso trucos útiles como transposición previa de matrices o extracción de count fuera de bucles dan solo ganancias limitadas. Hacen el código algo menos lento, pero no transforman PHP en un entorno para álgebra lineal eficiente. La siguiente etapa de evolución comenzó cuando los desarrolladores abandonaron la idea misma de almacenar matrices como arrays PHP ordinarios.

Así aparecieron Rubix Tensor y NDArray, donde los datos ahora residen en memoria contígua, más cerca de cómo está organizado en NumPy. En el caso de NDArray, Rust se utiliza para esto, lo que permite aumentar el rendimiento evitando algunos de los problemas típicos de la gestión manual de memoria. Desde el exterior, la API sigue siendo familiar, pero internamente casi todo cambia: zval para cada elemento desaparece, el modelo de tabla hash desvanece, y el código se acerca más a la notación matemática.

En comparaciones prácticas, esto es visible inmediatamente: multiplicar matrices de 500 por 500 en arrays toma aproximadamente 10–20 segundos, en Tensor en CPU — aproximadamente 0,3–0,8 segundos, y la ruta de GPU experimental a través de NumPower — ya alrededor de 0,05–0,2 segundos. Pero las estructuras nativas rápidamente mostraron un nuevo techo: incluso una CPU bien optimizada sigue siendo una CPU. Para embeddings, redes neuronales y operaciones de matriz grandes, esto ya es insuficiente, por lo que la continuación lógica fue un cambio hacia GPU.

Alrededor de RubixML v3 y NumPower, se está formando un nuevo modelo, donde PHP es responsable de la orquestación, Tensor y NumPower asumen la capa computacional, y GPU se convierte en el lugar donde vive las matemáticas pesadas. Esto se alinea bien con cómo funcionan hoy las herramientas de nivel más alto como transformers-php, LLPhant o Neuron AI: el código PHP allí describe el pipeline, carga de modelo, llamadas de inference y procesamiento de resultados, pero no intenta calcular manualmente matrices y bucles donde ya existen runtimes más apropiados para eso. Esto significa que PHP en IA tiene no tanto una oportunidad de ponerse al día con Python como entorno computacional, sino una oportunidad de ocupar su propio nicho claro.

El lenguaje sigue siendo fuerte donde es necesario incrustar rápidamente funciones de ML o LLM en una aplicación web, SaaS, un escenario de agente o un pipeline corporativo. Pero para lograr esto, el ecosistema tuvo que aceptar una conclusión desagradable, pero honesta: para que PHP participe en ML moderno, no necesita calcular todo por sí mismo. Su valor está cada vez más en ser el pegamento entre modelos, datos, infraestructura e interfaz, en lugar de ser un reemplazo para GPUs o bibliotecas de bajo nivel.