PHP y RubixML pasan de los arrays a la GPU: así cambia el enfoque del ML en el ecosistema

El ecosistema PHP se aleja cada vez más de la idea de que el aprendizaje automático pueda construirse en serio sobre arrays corrientes. El cambio principal no está en nuevos algoritmos, sino en el papel del propio lenguaje: PHP deja de ser un motor de cálculo y se convierte, cada vez más, en un orquestador que lanza pipelines, conecta bibliotecas y delega las matemáticas pesadas a extensiones nativas y GPU. En este contexto resulta revelador el giro de RubixML y de proyectos relacionados como Tensor y NumPower: en operaciones matriciales la diferencia ya no se mide en porcentajes, sino en órdenes de magnitud, desde decenas de segundos con arrays hasta fracciones de segundo con estructuras nativas y backends de GPU experimentales.

Al principio, el camino de PHP hacia el ML parecía bastante lógico. Las primeras bibliotecas, entre ellas PHP-ML y las primeras versiones de RubixML, guardaban las matrices como arrays de arrays y ejecutaban todas las operaciones dentro del intérprete. Para el desarrollador era cómodo: no hay que compilar nada, el código es transparente y fácil de depurar, y algoritmos básicos como k-NN, regresión logística o clasificadores sencillos se pueden montar literalmente en una tarde. Este enfoque sigue siendo útil para aprender y crear prototipos, porque permite recorrer a mano todo el camino desde el producto escalar hasta el paso hacia delante de una red neuronal simple.

Pero en cuanto los datos crecen, esa comodidad se convierte rápidamente en un cuello de botella. La causa no está en bucles mal escritos ni en la mala implementación de bibliotecas concretas, sino en el propio modelo interno de PHP. Aquí los números no viven como primitivas compactas, sino como estructuras zval, más pesadas.

Los arrays, por lo general, son tablas hash y no bloques de memoria densos y contiguos. Por eso cada acceso a un elemento sale más caro, la caché de la CPU se aprovecha peor, no hay vectorización SIMD automática y el mecanismo de copy-on-write puede inflar la memoria de forma inesperada y añadir asignaciones innecesarias. Incluso trucos útiles, como transponer las matrices de antemano o sacar count de los bucles, aportan solo una mejora limitada.

Hacen el código algo menos lento, pero no convierten PHP en un entorno para álgebra lineal eficiente.

La siguiente etapa de la evolución llegó cuando los desarrolladores renunciaron a guardar las matrices como arrays normales de PHP. Así surgieron Rubix Tensor y NDArray, donde los datos están en memoria contigua, más cerca de cómo funciona NumPy. En el caso de NDArray se usa Rust, lo que eleva el rendimiento y evita parte de los problemas típicos de la gestión manual de memoria.

Por fuera la API resulta familiar, pero por dentro cambia casi todo: desaparece el zval por elemento, se abandona el modelo de tabla hash y el código se acerca a la notación matemática. En comparativas prácticas se ve de inmediato: multiplicar matrices de 500 por 500 con arrays tarda aproximadamente entre 10 y 20 segundos; con Tensor en CPU, alrededor de 0,3–0,8 segundos; y la vía experimental de GPU con NumPower, del orden de 0,05–0,2 segundos.

Pero las estructuras nativas también toparon pronto con un nuevo techo: incluso una CPU bien optimizada sigue siendo una CPU. Para embeddings, redes neuronales y grandes operaciones matriciales ya no basta, así que el giro hacia la GPU fue la continuación lógica. En torno a RubixML v3 y NumPower empieza a formarse un nuevo modelo en el que PHP se encarga de la orquestación, Tensor y NumPower asumen la capa de cálculo y la GPU pasa a ser el lugar donde vive la matemática pesada.

Esto encaja bien con el funcionamiento actual de herramientas de más alto nivel como transformers-php, LLPhant o Neuron AI: allí el código PHP describe el pipeline, la carga del modelo, la llamada de inferencia y el tratamiento del resultado, pero no intenta calcular a mano matrices y bucles cuando ya existen entornos de ejecución más adecuados.

Esto significa que, para PHP, la oportunidad en IA no está tanto en alcanzar a Python como entorno de cálculo como en ocupar un nicho propio y claro. El lenguaje sigue siendo fuerte cuando hay que integrar rápido funciones de ML o LLM en una aplicación web, un SaaS, un escenario de agentes o un pipeline corporativo. Pero para ello el ecosistema ha tenido que aceptar una conclusión incómoda, aunque honesta: para que PHP participe en el ML moderno, no necesita calcularlo todo por sí mismo. Su valor está cada vez más en ser el pegamento entre modelos, datos, infraestructura e interfaz, y no un sustituto de la GPU ni de las bibliotecas de bajo nivel.