InfraestruturaHabr AI→ original

PHP e RubixML saem dos arrays e vão para a GPU: como muda a abordagem de ML no ecossistema

No ecossistema PHP, a própria arquitetura do ML está mudando. Antes, tentava-se calcular a matemática em arrays; agora o foco passa para Tensor, NDArray e backends de GPU como o NumPower no RubixML v3. O motivo é simples: as limitações de zval, tabelas hash e copy-on-write tornam o PHP puro prático para experimentos, mas caro demais para cálculo matricial sério. Com isso, a linguagem passa a atuar cada vez mais como orquestradora, e não como núcleo de computação.

Processado por IA de Habr AI; editado por Hamidun News
PHP e RubixML saem dos arrays e vão para a GPU: como muda a abordagem de ML no ecossistema
Fonte: Habr AI. Colagem: Hamidun News.
Ouvir artigo

O ecossistema PHP se afasta cada vez mais da ideia de que o aprendizado de máquina possa ser construído para valer sobre arrays comuns. A principal mudança não está em novos algoritmos, mas no papel da própria linguagem: o PHP deixa de ser um motor de cálculo e, cada vez mais, vira um orquestrador que dispara pipelines, conecta bibliotecas e entrega a matemática pesada a extensões nativas e GPUs. Nesse contexto, a virada do RubixML e de projetos relacionados, como Tensor e NumPower, é reveladora: em operações matriciais, a diferença já não se mede em percentuais, mas em ordens de grandeza, de dezenas de segundos com arrays a frações de segundo com estruturas nativas e backends de GPU experimentais.

No início, o caminho do PHP no ML parecia bastante lógico. As primeiras bibliotecas, incluindo o PHP-ML e as versões iniciais do RubixML, guardavam matrizes como arrays de arrays e executavam todas as operações dentro do interpretador. Para o desenvolvedor, isso era cômodo: não é preciso compilar nada, o código é transparente e fácil de depurar, e algoritmos básicos como k-NN, regressão logística ou classificadores simples podem ser montados literalmente em uma noite. Essa abordagem continua útil no ensino e na prototipagem, porque permite percorrer manualmente todo o caminho, do produto escalar até o forward pass de uma rede neural simples.

Mas, assim que os dados começam a crescer, a comodidade vira rapidamente um gargalo. A causa não está em loops mal escritos nem na má implementação de bibliotecas específicas, e sim no próprio modelo interno do PHP. Aqui, os números não vivem como primitivos compactos, mas como estruturas zval, mais pesadas.

Os arrays, em geral, são tabelas hash, e não blocos de memória densos e contíguos. Por isso, cada acesso a um elemento custa mais, o cache da CPU é pior aproveitado, não há vetorização SIMD automática, e o mecanismo de copy-on-write pode inflar a memória de forma inesperada e gerar alocações extras. Até truques úteis, como transpor as matrizes antecipadamente ou tirar o count dos loops, trazem ganhos limitados.

Deixam o código um pouco menos lento, mas não transformam o PHP em um ambiente para álgebra linear eficiente.

A etapa seguinte da evolução começou quando os desenvolvedores abandonaram a ideia de guardar matrizes como arrays comuns do PHP. Assim surgiram o Rubix Tensor e o NDArray, em que os dados ficam em memória contígua, mais perto de como funciona o NumPy. No caso do NDArray, usa-se Rust, o que eleva o desempenho e evita parte dos problemas típicos do gerenciamento manual de memória.

Por fora, a API continua familiar, mas por dentro muda quase tudo: some o zval por elemento, desaparece o modelo de tabela hash e o código fica mais próximo da notação matemática. Nas comparações práticas, isso aparece de imediato: multiplicar matrizes de 500 por 500 com arrays leva cerca de 10–20 segundos; com Tensor na CPU, aproximadamente 0,3–0,8 segundo; e o caminho experimental de GPU via NumPower, algo na faixa de 0,05–0,2 segundo.

Mas as estruturas nativas também esbarraram rápido em um novo teto: mesmo uma CPU bem otimizada continua sendo CPU. Para embeddings, redes neurais e grandes operações matriciais, isso já não basta, e a virada para a GPU foi a continuação lógica. Em torno do RubixML v3 e do NumPower começa a se formar um novo modelo, em que o PHP cuida da orquestração, Tensor e NumPower assumem a camada de cálculo e a GPU se torna o lugar onde vive a matemática pesada.

Isso combina bem com o funcionamento atual de ferramentas de nível mais alto, como transformers-php, LLPhant ou Neuron AI: lá, o código PHP descreve o pipeline, o carregamento do modelo, a chamada de inferência e o tratamento do resultado, mas não tenta calcular matrizes e loops à mão onde já existem runtimes mais adequados.

Isso significa que, para o PHP, a oportunidade em IA não está tanto em alcançar o Python como ambiente de cálculo, mas em ocupar um nicho próprio e bem definido. A linguagem continua forte quando é preciso embutir rapidamente recursos de ML ou LLM em uma aplicação web, um SaaS, um cenário de agentes ou um pipeline corporativo. Mas, para isso, o ecossistema teve de aceitar uma conclusão desagradável, porém honesta: para o PHP participar do 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, e não um substituto para a GPU ou para bibliotecas de baixo nível.

ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
O que você acha?
Carregando comentários…