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

PHP-экосистема всё заметнее уходит от идеи, что машинное обучение можно всерьёз строить на обычных массивах. Главный сдвиг сейчас не в новых алгоритмах, а в смене роли самого языка: PHP перестаёт быть вычислительным движком и всё чаще становится оркестратором, который запускает пайплайны, связывает библиотеки и отдаёт тяжёлую математику нативным расширениям и GPU. На этом фоне показателен поворот RubixML и связанных с ним проектов вроде Tensor и NumPower: для матричных операций разница уже измеряется не процентами, а порядками, от десятков секунд на массивах до долей секунды на нативных структурах и экспериментальных GPU-бэкендах.

Изначально путь PHP в ML выглядел вполне логично. Первые библиотеки, включая PHP-ML и ранние версии RubixML, хранили матрицы как массивы массивов и выполняли все операции прямо в интерпретаторе. Для разработчика это было удобно: ничего не нужно компилировать, код прозрачен, его легко отлаживать, а базовые алгоритмы вроде k-NN, логистической регрессии или простых классификаторов можно собрать буквально за вечер.

Такой подход до сих пор полезен в обучении и прототипировании, потому что позволяет руками пройти весь путь от скалярного произведения до прямого прохода простейшей нейросети. Но как только данные начинают расти, удобство быстро превращается в узкое место. Причина упирается не в неудачные циклы и не в плохую реализацию отдельных библиотек, а в саму внутреннюю модель PHP.

Числа здесь живут не как компактные примитивы, а как более тяжёлые структуры zval. Массивы в общем случае устроены как хеш-таблицы, а не как плотные непрерывные блоки памяти. Из-за этого каждый доступ к элементу обходится дороже, CPU-кэш используется хуже, автоматической SIMD-векторизации нет, а механизм copy-on-write может неожиданно раздувать память и добавлять лишние аллокации.

Даже полезные трюки вроде предварительного транспонирования матриц или выноса count из циклов дают лишь ограниченный выигрыш. Они делают код чуть менее медленным, но не превращают PHP в среду для эффективной линейной алгебры. Следующий этап эволюции начался тогда, когда разработчики отказались от самой идеи хранить матрицы как обычные PHP-массивы.

Так появились Rubix Tensor и NDArray, где данные лежат уже в contiguous memory, ближе к тому, как это устроено в NumPy. В случае NDArray для этого используется Rust, что позволяет поднять производительность и при этом избежать части типичных проблем ручного управления памятью. Снаружи API остаётся знакомым, но внутри меняется почти всё: исчезают zval на каждый элемент, пропадает хеш-табличная модель, а код становится ближе к математической записи.

На практических сравнениях это видно сразу: умножение матриц 500 на 500 на массивах занимает примерно 10–20 секунд, на Tensor на CPU — около 0,3–0,8 секунды, а экспериментальный GPU-путь через NumPower — уже порядка 0,05–0,2 секунды. Но и нативные структуры быстро показали новый потолок: даже хорошо оптимизированный CPU остаётся CPU. Для embeddings, нейросетей и больших матричных операций этого уже недостаточно, поэтому логичным продолжением стал разворот в сторону GPU.

Вокруг RubixML v3 и NumPower начинает формироваться новая модель, где PHP отвечает за orchestration, Tensor и NumPower берут на себя вычислительный слой, а GPU становится местом, где живёт тяжёлая математика. Это хорошо совпадает с тем, как сегодня работают более высокоуровневые инструменты вроде transformers-php, LLPhant или Neuron AI: PHP-код там описывает пайплайн, загрузку модели, вызов inference и обработку результата, но не пытается вручную считать матрицы и циклы там, где для этого уже существуют более подходящие рантаймы. Это значит, что у PHP в AI есть не столько шанс догнать Python как вычислительную среду, сколько возможность занять свою понятную нишу.

Язык остаётся сильным там, где нужно быстро встроить ML или LLM-функции в веб-приложение, SaaS, агентный сценарий или корпоративный пайплайн. Но для этого экосистеме пришлось принять неприятный, зато честный вывод: чтобы PHP участвовал в современном ML, ему не нужно считать всё самому. Его ценность всё больше в том, чтобы быть клеем между моделями, данными, инфраструктурой и интерфейсом, а не заменой GPU или низкоуровневых библиотек.