Почему PHP-массивы плохо подходят для математики, как появились Tensor и NDArray, и зачем RubixML в итоге решил пойти в сторону GPU.

1. Введение: а можно ли вообще делать ML в PHP?

Реакция на тему «машинное обучение на PHP» обычно предсказуема: усмешки, ссылки на Python или минусы. Вывод — это не та задача для этого языка.

В этом есть доля правды. PHP никогда не проектировался как платформа для численных вычислений. У него нет встроенной поддержки векторных операций, контроля над памятью или доступа к low-level оптимизациям, привычным в scientific computing.

Но машинное обучение в PHP существует. И не как эксперимент, а как часть реальных систем:

• inference прямо в веб-приложениях
• обработка данных внутри SaaS
• автоматизация и встроенная аналитика

И с каждым месяцем его использование растёт. Экосистема ML в PHP не шумная, но зрелая. Она состоит из четырёх слоёв:

• библиотеки классического ML
• математический фундамент
• инструменты интеграции с современными ML-системами
• интеграция с внешними ML-сервисами

В этой статье мы сосредоточимся на первых двух слоях.

Развитие экосистемы шло не благодаря языку, а вопреки его ограничениям — благодаря энтузиазму отдельных разработчиков.

Проблема не в алгоритмах, а в том, как устроена сама среда выполнения.

Сначала матрицы реализовывались как обычные массивы. Потом появились попытки оптимизации, затем — нативные структуры на C и Rust. И стало ясно: даже этого недостаточно.

Следующий шаг был неизбежен — вынос вычислений на GPU.

Мы пройдём этот путь: от наивных реализаций до современных решений вроде Tensor, NDArray и GPU-бэкендов в RubixML. И увидим, как менялось не только API, но и само понимание: где заканчивается PHP — и начинается настоящая вычислительная система.

Это не история о том, как делать ML в PHP. Это история о том, почему его пришлось делать по-другому.

2. Первая попытка: когда матрица — это просто массив

Матрица — это таблица чисел. А в PHP есть массивы. Значит, можно представить матрицу как массив массивов.

На этой идее строились первые библиотеки ML:

• PHP-ML — от Arkadiusz Kondas
• ранние версии RubixML — от Andrew DalPino
• и другие

Всё делалось в чистом PHP, без расширений и нативного кода. Вычисления выполнялись интерпретатором.

Для разработчика это было удобно: не нужно компилировать, можно дебажить привычными инструментами, код прозрачен.

Как это выглядело в коде

Операции вроде умножения матриц реализовывались «в лоб» — тремя вложенными циклами.

Скалярное произведение, прямой проход в нейросети — всё писалось вручную, без библиотек.

Этот подход всё ещё используется — в учебных целях, чтобы понять, как работают алгоритмы «под капотом».

Например, реализация forward pass одного слоя нейросети на чистом PHP показывает, что:

• подход остаётся понятным
• он полезен для обучения и экспериментов

Но при росте данных и в продакшене его ограничения становятся очевидны.

Почему это было удобно

Главное преимущество — простота. За вечер можно реализовать:

• k-NN
• линейную регрессию
• базовый классификатор

И всё — в рамках PHP. На маленьких данных это работает нормально. Для прототипов и обучения — более чем достаточно.

3. Почему это перестаёт работать

Сначала всё выглядит нормально. Потом данные растут — и код тормозит. Сначала чуть, потом в разы, а затем становится непригодным.

Первая мысль — «надо оптимизировать циклы». Но проблема не в коде. Она глубже — в устройстве самого PHP.

Число — это не просто число

В PHP число — это не примитив, а структура zval, которая хранит тип, значение и служебную информацию (например, счётчик ссылок).

Вместо 8 байт, как в C, каждый элемент занимает значительно больше. Миллион элементов — миллион структур zval.

Массив — это хеш-таблица

PHP-массив — это не непрерывная память, а хеш-таблица. Элементы не лежат подряд.

Каждый доступ включает:

• поиск ключа
• проход по внутренним структурам
• извлечение zval

Это серия операций, а не прямой доступ к памяти.

Из-за этого:

• хуже работает CPU cache
• доступ к данным дороже
• невозможна векторизация

Для численных вычислений это критично.

Copy-on-write

PHP может неявно копировать массивы при изменении. Мы не всегда контролируем, когда это происходит.

В задачах с матрицами это приводит к:

• резкому росту потребления памяти
• лишним аллокациям

Нет векторизации

Все операции выполняются через циклы. В NumPy та же операция — одна инструкция на уровне C с SIMD (Single Instruction, Multiple Data).

Алгоритм правильный, код простой — но каждая операция стоит слишком дорого.

Как это выглядит на практике

Сравним умножение матриц 500x500:

• PHP-массивы — ~10–20 сек
• Tensor (CPU) — ~0.3–0.8 сек
• GPU (NumPower) — ~0.05–0.2 сек

Цифры зависят от железа, но разница — на порядки.

Главное не абсолютные значения, а разница на порядки!

Дело не в том, что PHP «медленный». Дело в том, что он решает задачу не тем инструментом.

4. Попытки оптимизировать — и почему они не спасают

Можно оптимизировать циклы: вызывать count() один раз, использовать локальные переменные, минимизировать обращения к массивам.

Это даёт небольшой прирост, но быстро упирается в предел. Это оптимизация «на уровне синтаксиса».

Фундаментальные ограничения остаются:

• нет контроля над памятью
• нет contiguous storage
• нет SIMD
• нет BLAS

Узкое место — модель памяти PHP, а не реализация цикла.

Оптимизация: транспонирование

Один из трюков — предварительное транспонирование матрицы.

Проблема: при умножении $a[$i][$k] — это строка, а $b[$k][$j] — столбец. Доступ к столбцу в PHP неэффективен.

Решение: заранее транспонировать вторую матрицу. Теперь все обращения — к строкам.

Почему это быстрее:

• меньше «прыжков» по памяти
• лучше используется CPU cache
• доступ предсказуем

На практике это даёт заметный прирост даже в чистом PHP.

Но есть нюанс: мы всё ещё:

• работаем с zval
• используем хеш-таблицу
• остаёмся в интерпретаторе

Мы делаем вычисления чуть менее плохими, но не по-настоящему эффективными.

Даже продвинутые трюки на уровне PHP не заменят нормальную модель данных.

PHP просто не предназначен для численных вычислений.

Оптимизация: CPU-кэш

В C и NumPy важна cache locality — данные лежат подряд, CPU читает их блоками (cache lines).

Попытка оптимизации в PHP: писать код, идущий по памяти последовательно, избегая «прыжков».

Но в PHP это почти не работает. Даже «плоский» массив — это:

• не последовательность float-ов
• а массив zval
• внутри — всё ещё хеш-таблица

Результат:

• данные не лежат компактно
• между ними — служебные структуры
• CPU не может эффективно использовать cache

Мы пишем код так, как будто оптимизируем cache — но реальной выгоды почти нет.

Оптимизация: packed arrays

В PHP 7+ появились packed arrays — более компактное хранение для простых массивов.

Это ускоряет работу, но в задачах с матрицами почти не помогает. При вложенности:

• массив массивов
• непрерывность теряется
• каждый элемент — всё ещё zval
• contiguous memory нет

К тому же packed array легко «сломать» — например, удалением элемента. После этого PHP возвращается к хеш-таблице.

В ML-задачах такие операции — постоянны: фильтрация, reshaping, работа с индексами.

Мы можем немного ускорить код — но не можем изменить фундамент!

Проблема не в циклах — проблема в том, как данные представлены в памяти.

Неприметный аспект

Многие библиотеки того периода просто перестали развиваться. Интернет завален заброшенными PHP-проектами по ML.

Не потому что идея была плохой. А потому что разработчики упирались в один и тот же потолок.

Можно было переписать внутренности, добавить оптимизаций, улучшить API. Но кардинального прироста не было.

Сколько бы ни оптимизировали PHP-массивы, они не превратятся в структуру, подходящую для численных вычислений.

Оставалось два пути:

• переписывать на C / Rust
• потерять мотивацию

Часто происходило второе. Энтузиазм угасал, потому что каждый шаг давал всё меньший результат.

Дело было не в библиотеках — дело было в самой модели.

5. Поворот: когда матрицы перестают быть массивами

Следующий этап — отказ от идеи, что матрица должна быть PHP-массивом.

Появились библиотеки, хранящие данные в contiguous memory, как в NumPy:

• Rubix Tensor — от Andrew DalPino
• NDArray — реализация на Rust от Kyrian Obikwelu

Теперь:

• нет zval на каждый элемент
• нет хеш-таблицы
• данные лежат плотно
• CPU работает с ними эффективно

Код остаётся похожим, но внутри — совсем другое.

Интересно, что Rust используется как способ получить производительность без проблем C с памятью. Это пример того, как PHP делегирует тяжёлую работу другим языкам.

Ускорение — в разы. Но и этого оказывается недостаточно.

Как изменилась архитектура

Эволюция:

• раньше: PHP занимался вычислениями
• теперь: PHP управляет процессом (orchestration)

Код становится менее «PHP-шным» и ближе к математической модели.

Более сложные операции

Сложение, нормализация — теперь выглядят как математические формулы, а не набор циклов.

Но остаётся ощущение, что чего-то не хватает. API всё ещё «объектный», а не математический.

NumPower и новый уровень абстракции

Проект NumPower от Henrique Borba идёт дальше. Он не только ускоряет вычисления, но и меняет способ их записи.

Теперь можно писать:

• $a + $b * $c
• sin($x) ** 2

Это очень близко к NumPy. Это не синтаксический сахар — это попытка сделать математические выражения нативными для языка.

6. Новый потолок: когда CPU уже не справляется

Даже с идеальными структурами данных и нативным кодом CPU ограничен: мало ядер, низкая пропускная способность.

ML — это огромные матричные операции. Embedding-векторы, нейросети — быстро упираются в объёмы, где CPU сдаёт.

Следующий шаг — неизбежен.

7. Почему всё пришло к GPU

GPU заточен под параллельные вычисления. Тысячи потоков, высокая пропускная способность памяти — идеально для линейной алгебры.

Выжимать максимум из CPU — тупик. Нужно менять архитектуру.

Сейчас RubixML v3 движется в сторону GPU через проекты вроде NumPower.

Это смена парадигмы:

• PHP → orchestration
• Tensor / NumPower → вычисления
• GPU → heavy math

Проект в стадии активной разработки. Это момент, когда можно подключиться.

Это не просто «ускорим вычисления». Это переход на другую модель: PHP больше не считает — он управляет.

8. Что в итоге произошло

PHP использовался как вычислительная среда. Потом стало ясно: он для этого не подходит. Вычисления начали выноситься — сначала в нативные структуры, потом в расширения, теперь — на GPU.

Сегодня PHP в ML — это orchestration layer. Он:

• связывает компоненты
• управляет процессом
• обрабатывает данные

А тяжёлая математика — в других местах:

• GPU
• Rust
• нативные библиотеки

Пример — Transformers PHP от Kyrian Obikwelu. Это доступ к современным моделям в контексте PHP. Но под капотом:

• PHP управляет пайплайном
• загружает модели
• обрабатывает результаты

Вычисления — вне PHP: через нативные библиотеки или внешние рантаймы.

Похожую роль играет LLPhant — для LLM-сценариев:

• генерация текста
• embeddings
• retrieval (RAG)
• чат-интерфейсы

Код остаётся прикладным. Мы больше не думаем:

• о матрицах
• о циклах
• о памяти

Мы думаем:

• о данных
• о запросах
• о поведении системы

Появляются и более высокоуровневые инструменты. Например, Neuron AI — не про матрицы и модели, а про построение AI-приложений:

• агенты
• цепочки (chains)
• интеграции с LLM

Код ещё дальше от «низкого уровня».

Роль PHP изменилась:

• раньше — реализовывали математику
• потом — выносили её в нативные структуры
• теперь — описываем поведение системы

Весь путь:

• умножаем матрицы в массивах
• оптимизируем — упираемся в потолок
• выносим в нативные структуры
• в C / Rust
• и, наконец, на GPU

PHP не становится быстрее в ML. Он просто перестаёт считать.

Он больше не вычислительный движок — он диспетчер, оркестратор, клей между компонентами.

И, возможно, именно это и есть его шанс выжить в большой игре.

Но тогда остаётся вопрос: игра ещё идёт? Или PHP уже давно играет не в ту игру?

Почему PHP-массивы плохо подходят для математики, как появились Tensor и NDArray, и зачем RubixML в итоге решил пойти в сторону GPU.Это четвёртая часть проекта.Часть 4:Практическое использование TransformersPHPЧасть 3:Практика без Python и data scienceЧасть 2:Собираем простейшую RAG-систему на PHP с Neuron AI за вечерЧасть 1:Как я пытался подружить PHP с NER — драма в 5 актах

1. Введение: а можно ли вообще делать ML в PHP?

Когда я разговариваю с кем-то или пишу статью на тему "машинное обучение на PHP", то реакция большинства обычно предсказуема: в ответ мне либо усмехаются, либо тычут в лицо Python-ом, либо минусуют (за исключением тех, кто искренне интересуется этой темой).

Но в целом вывод такой - это просто не та задача для этого языка.

И я честно признаю – в этом есть доля правды. Но…

Вот уже несколько лет я занимаюсь тем, что пытаюсь делать всё возможное в деле продвижения "ML в PHP". Почему? Точно не знаю, если честно. Я сам не раз задавал себе этот вопрос и точного ответа на него у меня нет (даже для самого себя).

Друзья, я не сумасшедший и не повёрнутый на некой идее "фикс" психопат.

Я обычный программист, который любит программировать PHP.

Этот язык кормил меня долгие годы (да и сейчас продолжает кормить). Он не идеален, но в целом мне нравится как он растёт и куда развивается.

В общем, кажется что просто сама постановка задачи "ML в PHP" звучит для меня неким вызовом, что заставляет сидеть по ночам, пытаясь самому разбираться в математических формулах или реализовать алгоритм очередной ML модели на PHP. И если честно – мне это в кайф!

Конечно, PHP никогда не проектировался как платформа для численных вычислений. У него нет встроенной поддержки векторных операций, контроля над памятью или доступа к low-level оптимизациям, которые считаются нормой в мире scientific computing.

И всё же – машинное обучение в PHP существует.

Причём не как эксперимент, а как часть реальных систем:

• inference прямо в веб-приложениях
• обработка данных внутри SaaS
• автоматизация и встроенная аналитика

и с каждымгодоммесяцем использование ML в PHP продолжает расти.

Если вы сомневаетесь, то гляньте сюда:

👉https://github.com/apphp/awesome-php-ml

Это наиболее полный тщательно подобранный список библиотек для машинного обучения, искусственного интеллекта, обработки естественного языка, LLM и анализа данных для PHP. Этот, далеко не полный список, содержит ссылки на более чем 140 ресурсов. Экосистема ML в PHP не шумная, но довольно зрелая. Она состоит из четырёх слоев:

• библиотеки классического ML
• математический фундамент
• инструменты интеграции с современными ML-системами
• интеграция с внешними ML-сервисами

В этой статье мы затронем первые два слоя, два других коснёмся чисто условно.

Итак, несмотря на то, что экосистема ML в PHP живёт и процветает, если посмотреть глубже, то станет понятно: развивалась она не благодаря, авопреки ограничениям языкаис помощью его отдельных фанатов-энтузиастов(постараюсь в статье упомянуть всех, кого я знаю).

В очередной раз скажу банальность - эта статья не про обзор библиотек и не попытка сравнить PHP с Python.

Это история того, как PHP-сообщество шаг за шагом приближалось к одному и тому же выводу:

проблема не в алгоритмах, а в том,как устроена сама среда выполнения

Сначала векторы и матрицы реализовывались как обычные PHP-массивы. Потом появились попытки оптимизации. Затем – нативные структуры, написанные на C и Rust. И в какой-то момент стало очевидно: даже этого недостаточно.

Следующий шаг оказался неизбежным –вынос вычислений на GPU.

Мы с вами попробуем пройти этот путь последовательно: от наивных реализаций до современных решений вроде Tensor, NDArray и GPU-бэкендов в RubixML.

И по ходу увидим, как менялось не только API, но и само понимание: где заканчивается PHP – и начинается настоящая вычислительная система или оркестрация.

Если коротко: это история не про то, как делать ML в PHP, а про то, почему его пришлось делать по-другому.

2. Первая попытка: когда матрица – это просто массив

Если отбросить теорию, матрица – это просто таблица чисел. А раз в PHP уже есть массивы – значит, можно представить матрицу как массив массивов:

Именно на этой идее и были построены первые библиотеки машинного обучения в PHP:

• PHP-ML –https://github.com/jorgecasas/php-ml(от Arkadiusz Kondas)
• ранние версии RubixML –https://github.com/RubixML/RubixML(от Andrew DalPino)
• и несколько прочих

Всё делалось в чистом PHP – без расширений и нативного кода (то есть все вычисления выполнялись самим интерпретатором, без низкоуровневых оптимизаций).

С точки зрения простого разработчика это было максимально удобно: не нужно ничего компилировать, можно дебажить привычными инструментами и код полностью прозрачен.

Как это выглядело в коде

Даже такие операции, как умножение матриц, реализовывались буквально "в лоб" – с помощью трёх вложенных циклов (triple loop)

Или, например, скалярное произведение матриц:

С точки зрения алгоритмов – всё корректно.С точки зрения PHP – тоже всё "по учебнику".

Для человека – всё очень чётко и понятно. И, что важно, это действительно работает.

На самом деле – этот подход никуда не делся.

Даже сейчас появляются новые разборы и реализации, где матрицы нейросети пишутся на чистом PHP – без внешних библиотек и расширений. Обычно это делается не для продакшена, а в учебных целях: чтобы лучше понять, как всё работает "под капотом" и из каких базовых операций складываются более сложные алгоритмы.

Например (реализация прямого прохода (forward pass) одного слоя нейросети "вручную", без библиотек):

И это важный момент.

С одной стороны, это показывает, что:

• подход всё ещё понятен
• он по-прежнему используется для обучения и экспериментов

С другой – очень быстро становится видно его ограничения, когда речь заходит о масштабировании или о продакшен-среде.

Если вам интересно заглянуть немного вперёд, то рекомендую посмотреть относительно свежий доклад Алексея Нечаева (обещаю - вы получите море удовольствие от просмотра этого видео):

👉https://www.youtube.com/watch?v=AMNKVwDT_xg

В нём шаг за шагом разбирается реализация нейронной сети прямо на PHP – с теми же идеями: массивы, циклы, базовые математические операции.

Почему это было удобно

Главное преимущество – простота.

Если вы загорелись идеей, то можно буквально за вечер реализовать:

• k-NN
• простую линейную регрессию
• базовый классификатор
• и т.д.

И всё это – не выходя за пределы PHP.

Например, кусок логистической регрессии:

Как говорится – "И все так чинно, благородно, по старому" (с).

На маленьких данных это работает вполне нормально.Для обучения, экспериментов и прототипов – более чем достаточно.

Проблемы начинаются чуть позже.

3. Почему это перестаёт работать

Проблемы появляются не сразу.

Сначала всё выглядит нормально. Потом данные растут – и код начинает тормозить. Сначала чуть-чуть, затем в разы, а потом становится просто непригодным.

Первая мысль – "надо оптимизировать циклы". Но довольно быстро становится понятно: дело не в алгоритмах и не в конкретном коде и даже оптимизация циклов не помогает.

Проблема глубже – в том, как PHP устроен внутри.

Число – это не просто число

В PHP число – это не примитив, а структураzval, которая хранит:

• тип
• значение
• служебную информацию (например, счётчик ссылок)

То есть вместо компактных 8 байт, как в C, каждый элемент занимает значительно больше памяти.

Если у вам миллион элементов – это миллион таких структур.

Массив – это хеш-таблица

PHP-массив – это не contiguous memory, а хеш-таблица (hash table).

Это значит, что элементы не лежат подряд в памяти. Каждый доступ – это не просто "взять по индексу", а кое-что побольше:

• поиск ключа
• проход по внутренним структурам
• извлечение zval

под капотом – это серия операций, а не прямой доступ к памяти.

И это сразу бьёт по нескольким вещам:

• хуже работает CPU cache
• доступ к данным становится дороже
• невозможна нормальная векторизация

В численных вычислениях это критично.

Copy-on-write

Есть ещё менее очевидная проблема –copy-on-write.

PHP может неявно копировать массивы при изменении:

И мы не всегда можем контролировать, когда именно произойдёт копирование.

Всё это значит, что в задачах с матрицами это может:

• резко увеличится потребление памяти
• добавятся лишние аллокации и т.п.

Нет векторизации

Все операции выполняются через циклы:

В то время как в NumPy это одна операция, выполняемая на уровне C с использованиемSIMD (Single Instruction, Multiple Data).

В итоге получается странная ситуация: алгоритм правильный, код простой – но каждая операция стоит слишком дорого.

И именно поэтому всё "вдруг" перестаёт работать при росте данных.

Как это выглядит на практике

Чтобы не быть голословным, давайте сравним простую операцию – умножение матриц. Как говорится – "Практика – критерий истины" (с).

Вариант 1: чистый PHP

Вариант 2: Tensor(этоhttps://github.com/RubixML/Tensor)

Вариант 3: NumPower (потенциально GPU)(этоhttps://github.com/RubixML/numpower)

Результаты (примерные, но показательные)

Время (500x500)

PHP массивы

~10–20 сек

Tensor (CPU)

~0.3–0.8 сек

GPU (NumPower)

~0.05–0.2 сек

Цифры могут отличаться в зависимости от железа, но порядок остаётся тем же.

Главное здесь не абсолютные значения, а разница на порядки!

И именно в этот момент становится понятно: дело не в том, что PHP "медленный" или "плохой", а в том,что он решает задачу не тем инструментом.

4. Попытки оптимизировать – и почему они не спасают

Например, можно убрать лишние вызовыcount()из условия цикла и сократить количество обращений к массивам:

• вызываемcount()один раз вместо выполнения его на каждой итерации
• уменьшаем количество обращений к массивам
• работаем с локальными переменными, что быстрее, чем повторно читать значения из массива

Это действительно может дать небольшой прирост производительности, особенно в больших циклах. Однако выигрыш обычно умеренный и сильно зависит от конкретного кода и версии PHP – говорить о каком-то серьёзном приросте производительности не приходится.

Но довольно быстро упираешься в предел таких микрооптимизаций.

Главная проблема в том, что это оптимизация "на уровне синтаксиса".

Фундаментальных ограничениях PHP остаются как и прежде:

• нет контроля над памятью
• нетcontiguous storage
• нетSIMD
• нетBLAS

Узкое место – это не реализация цикла, а сама модель памяти PHP.

Но тем не менее, на этом оптимизации не заканчиваются. Давайте посмотрим, что можно сделать ещё.

Оптимизация: транспонирование

Один из интереснейших трюков, который довольно быстро появляется в таких реализациях – этопредварительное транспонирование матрицы.

Проблема классического умножения матриц в PHP в том, что мы постоянно обращаемся к элементам столбцов:

Для$a[$i][$k]всё более-менее нормально – мы идём по строке.А вот$b[$k][$j]– это уже доступ к столбцу, который в PHP-массиве реализован максимально неэффективно.

В итоге мы постоянно прыгаем по памяти.

В качестве приятного времяпровождения настоятельно рекомендую посмотреть видео с выступлением Andrew DalPino (автором библиотеки RubixML):

👉https://www.youtube.com/watch?v=5YtNugpMhyQ

Решение тут убийственно простое – заранее развернуть (транспонировать) вторую матрицу:

И дальше работать уже с ней:

Теперь вместо доступа к столбцу мы всегда работаем со строками:

Почему это быстрее

• уменьшается количество "прыжков" по памяти
• лучше используется CPU cache
• доступ становится более предсказуемым

На практике это может дать заметный прирост производительности даже в чистом PHP.

Но тут, как говорится – "есть нюанс" (с)

Это хорошая оптимизация, но она не решает основную проблему.

Мы всё ещё:

• работаем с zval
• используем хеш-таблицу
• остаёмся в интерпретаторе

То есть мы делаем вычислениячуть менее плохими, но не делаем их по-настоящему эффективными.

И в какой-то момент приходится признать неприятный, но важный факт: даже продвинутые трюки на уровне PHP (продвинутые, Карл!), не заменят нормальную модель данных. Ну вот… я это произнёс.

PHP просто не предназначен для численных вычислений.

Оптимизация: CPU-кэш

Ещё одна идея, которая кажется очевидной, – это попытаться "подружиться" с CPU-кэшем.

В низкоуровневых языках (C, C++, NumPy) огромное значение имеетcache locality– то, насколько близко друг к другу лежат данные в памяти.

Если данные лежат подряд, процессор может читать их блоками (cache lines), и такие операции:

в C работает очень быстро не потому, что он простой, а потому что:

• данные лежат подряд
• CPU читает их блоками (cache lines)
• доступ предсказуем

Поэтому естественная попытка оптимизации выглядит так: будем писать код, который идёт по памяти последовательно и будем избегать "прыжков" по массивам.

• использовать строки вместо столбцов (через transpose)
• минимизировать случайный доступ
• работать с линейными структурами

Где это ломается в PHP

Проблема в том, что в PHP такая оптимизация почти не работает.

Даже если у нас есть "плоский" массив:

в памяти это:

• не последовательность float-ов
• а массив zval
• плюс внутренняя структура всё ещё хеш-таблица

И в результате:

• данные не лежат компактно
• между ними есть служебные структуры
• CPU не может эффективно использовать cache

В общем, у нас получается парадокс:

мы пишем код так, как будто оптимизируем cache но реальной выгоды почти нет

Оптимизация: packed arrays

А как же packed arrays, спросил внимательный читатель? Отличный вопрос!

В PHP 7+ появились так называемыеpacked arrays– оптимизация для "простых" массивов.

Такой массив PHP может хранить данные более компактно – без полноценной хеш-таблицы.

И это действительно ускоряет работу.

Но… в контексте работы с матрицами это почти не помогает.

Как только появляется вложенность:

мы снова получаем:

• массив массивов
• сложную структуру
• непрерывность данных теряется

• каждый элемент всё ещё zval
• настоящего contiguous memory нет

Более того, packed array легко "сломать":

Упс… и после этого PHP возвращается к обычной хеш-таблице.

В ML-задачах это происходит постоянно:

• фильтрация
• reshaping
• работа с индексами

Если собрать всё вместе – транспонирование, попытки учитывать cache locality, использование packed arrays – становится видно одну и ту же картину:

мы можем немного ускорить код – но не можем изменить фундамент!

И тут мы снова приходим к ключевому пониманию:

проблема не в том, как мы пишем циклы –проблема в том, как данные представлены в памяти

Неприметный аспект

И здесь есть ещё один аспект, о котором редко говорят напрямую и который я хотел бы упомянуть.

Многие библиотеки того периода просто переставали развиваться. Интернет завален заброшенными PHP пет-проектами по машинному обучению.

Не потому что идея была плохой – наоборот, она была логичной. А потому что разработчики довольно быстро упирались в один и тот же потолок.

Можно было:

• переписать внутренности
• добавить ещё оптимизаций
• улучшить API

Но кардинального прироста это не давало.

В какой-то момент авторам библиотек становилось понятно:

сколько бы они ни оптимизировали PHP-массивы, они не превратятся в структуру, подходящую для численных вычислений

И дальше оставалось два варианта:

• либо переписывать всё на C / Rust
• либо терять мотивацию

Часто происходило второе.

Энтузиазм угасал, потому что каждый следующий шаг давал всё меньший результат, а фундаментальная проблема оставалась.

И это, пожалуй, один из самых показательных сигналов:

дело было не в конкретных библиотекахдело было в самой модели

5. Поворот: когда матрицы перестают быть массивами

Следующим этапом эволюции – был отказ от идеи, что матрица должна быть PHP-массивом. Как просто, да?

Появились библиотеки и расширения, которые хранят данные уже не в PHP-структурах, а в более подходящем виде.

• Rubix Tensor (от уже известного нам Andrew DalPino) –https://github.com/RubixML/Tensor
• NDArray (реализация с использованием Rust от Kyrian Obikwelu) –https://github.com/phpmlkit/ndarray

Теперь данные лежат в contiguous memory, как в NumPy. Это уже совсем другой уровень.

Код при этом остаётся похожим:

Но внутри происходит совсем другое.

Нет zval на каждый элемент, нет хеш-таблицы, данные лежат плотно, и CPU может работать с ними гораздо эффективнее.

Интересно, как здесь в игру зашёл Rust. В том же NDArray он используется как способ получить производительность и при этом не словить типичные проблемы C с памятью. Это хороший пример того, как PHP начинает делегировать тяжёлую работу другим языкам.

И это уже работает. Ускорение может быть в разы.

Хотя даже этого оказывается недостаточно.

Как изменилась архитектура

Если упростить, вся эволюция до этого момента выглядит так:

Если посмотреть чуть шире – это не просто смена инструментов, а смена ролей:

• раньше: PHP занимался вычислениями
• теперь: PHP управляет процессом (orchestration)

Самое интересное, что на каждом этапе код становился не просто быстрее – он становится менее "PHP-шным" и всё больше напоминает нормальную математическую модель.

Что же дальше?

Более сложные операции

Например, сложение:

Или нормализация:

Код становится гораздо ближе к математике – читаешь его почти как формулу, а не как набор низкоуровневых операций.

И тут происходит интересный момент

Даже после перехода на нативные структуры остаётся ощущение, что чего-то не хватает.

API всё ещё "объектный", а не математический.

Поэтому здесь появляется следующий шаг эволюции.

NumPower и новый уровень абстракции

Проект NumPower, изначально созданый Henrique Borba (https://github.com/RubixML/numpower) идёт ещё дальше.

Он не только ускоряет вычисления, но и меняет сам способ их записи.

Теперь можно писать так:

А можно даже и так:

Это уже очень близко к тому, как выглядит код в NumPy.

Ещё пример:

Это не просто синтаксический сахар. Это попытка сделать математические выражениянативными для языка.

6. Новый потолок: когда CPU уже не справляется

Однако с ростом задач становится ясно, что проблема не только в PHP.

Даже если у нас идеальные структуры данных и быстрый нативный код, CPU остаётся CPU. У него ограниченное количество ядер и ограниченная пропускная способность.

А задачи машинного обучения – это, по сути, огромные матричные операции.

Например, работа с embedding-векторами или нейросетями быстро упирается в объёмы, где даже хорошо оптимизированный CPU начинает сдавать.

Соответственно мы переходим к следующему логичному шагу.

7. Почему всё пришло к GPU

GPU изначально заточен под параллельные вычисления. Тысячи потоков, высокая пропускная способность памяти – всё это идеально подходит для линейной алгебры.

На сегодняшний момент очевидно уже всем: пытаться выжать максимум из CPU – это тупиковая ветка.

Нужно менять не реализацию, а архитектуру.

Что происходит сейчас.

Сейчас появляется следующий уровень.

В RubixML v3 появляется движение в сторону GPU через такие проекты, как numpower:

👉https://github.com/RubixML/numpower

Это смена парадигмы:

• PHP → orchestration
• Tensor / NumPower → вычисления
• GPU → heavy math

Работа ведётся энтузиастами, и проект всё ещё находится в стадии активного развития.

Если вам это интересно – это как раз тот момент, когда можно подключиться:

👉.https://github.com/RubixML/ML/tree/3.0

Это уже не просто "ускорим вычисления". Это переход на другую модель: PHP больше не считает, он управляет.

8. Что в итоге произошло

Если окинуть взлядом всю вышеописанную эволюцию, то картина получается довольно логичная.

Сначала PHP использовался как вычислительная среда. Потом стало понятно, что он для этого не подходит. После этого вычисления начали постепенно выноситься: сперва в нативные структуры, потом в расширения, а теперь – на GPU.

Сегодня PHP в ML – это скорее orchestration layer. Он связывает компоненты, управляет процессом, обрабатывает данные, но тяжёлая математика живёт в других местах:

• в GPU
• в Rust
• в нативных библиотеках

И это, пожалуй, главный вывод всей этой истории.

Хороший пример того, как это выглядит на практике сегодня:

У нас есть проекты вроде:

👉https://github.com/CodeWithKyrian/transformers-php(от Kyrian Obikwelu)

Это библиотека, которая даёт доступ к современным моделям (в духе Hugging Face / transformers), но уже в контексте PHP.

При этом важно понимать, что происходит под капотом: PHP здесь не занимается тяжёлыми вычислениями.

• управляет пайплайном (pipeline)
• загружает модели
• обрабатывает результаты

А сами вычисления выполняются вне PHP – через нативные библиотеки или внешние рантаймы.

Пример использования может выглядеть довольно "нативно":

И это, пожалуй, лучший показатель того, как изменилась роль PHP:

Похожую роль играют и библиотеки вроде:

👉https://github.com/llphant/llphant(от Franco Lombardo, Fabrizio Balliano и других)

LLPhant – это уже следующий шаг: работа не просто с моделями, а с полноценными LLM-сценариями.

• генерация текста
• embeddings
• retrieval (RAG)
• чат-интерфейсы
• и т.д.

Код при этом остаётся максимально "прикладным":

Или, например, работа с embeddings:

Всё это – уже совершенно другой уровень абстракции.

Мы больше не думаем:

• о матрицах
• о циклах
• о памяти

Мы думаем:

• о данных
• о запросах
• о поведении системы

Но и на этом трансформация не заканчивается.

Появляются и более высокоуровневые инструменты, где PHP используется уже не просто как "обёртка" над моделями, а как среда для построения AI-логики.

👉https://github.com/neuron-core/neuron-ai(от Valerio Barbera)

Neuron AI – это уже не про матрицы и даже не про сами модели.Это про построение AI-приложений:

• агентов
• цепочек (chains)
• интеграции с LLM

Пример использования выглядит ещё дальше от "низкого уровня":

Здесь особенно хорошо видно, как изменилась роль PHP:

• раньше мы реализовывалиматематику
• потом – выносили её внативные структуры
• теперь – мы описываемповедение системы

Если посмотреть на весь пройденный путь, становится очевидно: это не просто эволюция инструментов – это постепенное вытеснение PHP из вычислений.

Сначала мы честно умножаем матрицы в массивах.Потом начинаем оптимизировать и упираемся в потолок.Дальше – выносим всё в нативные структуры.Потом – в C / Rust.И в конце концов… уходим на GPU.

И здесь у меня напрашивается не самый утешительный вывод:

PHP не становится быстрее в ML.Он просто перестаёт считать.

Он больше не вычислительный движок – он диспетчер, оркестратор, клей между компонентами.

И, возможно, именно это и есть его шанс выжить в большой игре.

Но тогда вопрос остаётся открытым:

Is the game still going on?Или PHP уже давно играет не в ту игру?

Если вам интересна эта тема, можно глубже погрузиться в неё в моей бесплатной книге:https://apphp.gitbook.io/ai-for-php-developers/

А также посмотреть и поиграться с онлайн-примерами:https://aiwithphp.org/books/ai-for-php-developers/examples/