PHP e RubixML transitam de arrays para GPU: como a abordagem de ML está mudando no ecossistema

O ecossistema PHP está se afastando cada vez mais da ideia de que aprendizado de máquina pode ser construído seriamente em arrays comuns. A mudança principal agora não está em novos algoritmos, mas em uma mudança no papel da própria linguagem: PHP está deixando de ser um motor computacional e está se tornando cada vez mais um orquestrador que inicia pipelines, vincula bibliotecas e delega matemática pesada para extensões nativas e GPUs. Neste contexto, a mudança do RubixML e projetos relacionados como Tensor e NumPower é reveladora: para operações de matriz, a diferença agora é medida não em percentuais, mas em ordens de magnitude, de dezenas de segundos em arrays para frações de segundo em estruturas nativas e backends de GPU experimentais.

Inicialmente, o caminho do PHP em ML parecia bastante lógico. As primeiras bibliotecas, incluindo PHP-ML e versões iniciais do RubixML, armazenavam matrizes como arrays de arrays e executavam todas as operações diretamente no interpretador. Para desenvolvedores, isso era conveniente: nada precisava ser compilado, o código era transparente, era fácil debugar, e algoritmos básicos como k-NN, regressão logística ou classificadores simples podiam ser montados literalmente em uma noite.

Essa abordagem ainda é útil em educação e prototipagem, porque permite passar manualmente por todo o caminho do produto escalar até a propagação direta da rede neural mais simples. Mas assim que os dados começam a crescer, a conveniência rapidamente se transforma em um gargalo. A razão não está em loops malsucedidos ou em implementação ruim de bibliotecas individuais, mas no próprio modelo interno do PHP.

Os números aqui vivem não como primitivos compactos, mas como estruturas zval mais pesadas. Arrays em geral são organizados como tabelas de hash, não como blocos de memória contíguos densos. Por isso, cada acesso a um elemento custa mais, o cache da CPU é usado pior, não há vetorização SIMD automática, e o mecanismo copy-on-write pode inesperadamente inchar a memória e adicionar alocações desnecessárias.

Até truques úteis como transposição prévia de matrizes ou extração de count fora de loops dão apenas ganhos limitados. Eles tornam o código um pouco menos lento, mas não transformam PHP em um ambiente para álgebra linear eficiente. O próximo estágio da evolução começou quando os desenvolvedores abandonaram a própria ideia de armazenar matrizes como arrays PHP comuns.

É assim que Rubix Tensor e NDArray apareceram, onde os dados agora residem em memória contígua, mais próximo de como está organizado em NumPy. No caso de NDArray, Rust é usado para isso, o que permite aumentar o desempenho evitando alguns dos problemas típicos de gerenciamento manual de memória. De fora, a API permanece familiar, mas internamente quase tudo muda: zval para cada elemento desaparece, o modelo de tabela de hash some, e o código fica mais próximo da notação matemática.

Em comparações práticas, isso é visível imediatamente: multiplicar matrizes de 500 por 500 em arrays leva aproximadamente 10–20 segundos, em Tensor em CPU — cerca de 0,3–0,8 segundos, e o caminho de GPU experimental através de NumPower — já cerca de 0,05–0,2 segundos. Mas estruturas nativas rapidamente mostraram um novo teto: mesmo uma CPU bem otimizada permanece uma CPU. Para embeddings, redes neurais e grandes operações de matriz, isso já é insuficiente, então a continuação lógica foi uma mudança em direção à GPU.

Em torno de RubixML v3 e NumPower, está se formando um novo modelo, onde PHP é responsável pela orquestração, Tensor e NumPower assumem a camada computacional, e GPU se torna o lugar onde vive a matemática pesada. Isso se alinha bem com como ferramentas de nível mais alto como transformers-php, LLPhant ou Neuron AI funcionam hoje: o código PHP lá descreve o pipeline, carregamento de modelo, chamadas de inference e processamento de resultado, mas não tenta calcular manualmente matrizes e loops onde runtimes mais adequados já existem para isso. Isso significa que PHP em IA tem não tanto uma chance de acompanhar Python como um ambiente computacional, mas uma oportunidade de ocupar seu próprio nicho claro.

A linguagem permanece forte onde é necessário incorporar rapidamente funções de ML ou LLM em uma aplicação web, SaaS, um cenário de agente ou um pipeline corporativo. Mas para alcançar isso, o ecossistema teve que aceitar uma conclusão desagradável, porém honesta: para PHP participar de ML moderno, ele não precisa calcular tudo sozinho. Seu valor está cada vez mais em ser a cola entre modelos, dados, infraestrutura e interface, em vez de ser uma substituição para GPUs ou bibliotecas de baixo nível.