惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Microsoft Security Blog
Microsoft Security Blog
J
Java Code Geeks
GbyAI
GbyAI
aimingoo的专栏
aimingoo的专栏
L
LangChain Blog
I
InfoQ
D
Docker
F
Fortinet All Blogs
Y
Y Combinator Blog
Martin Fowler
Martin Fowler
月光博客
月光博客
B
Blog
Engineering at Meta
Engineering at Meta
T
Tailwind CSS Blog
罗磊的独立博客
博客园_首页
G
Google Developers Blog
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
D
DataBreaches.Net
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
B
Blog RSS Feed
IT之家
IT之家
V
V2EX

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Масштабируемость ML-алгоритмов при увеличении вычислитель...
slwr66 · 2026-06-01 · via Все публикации подряд на Хабре

Простой

5 мин

6.6K

Говоря о машинном обучении, нейронных сетях и тому подобному, у многих появляется ассоциация с мощным железом, огромными вычислительными мощностями и невероятным количеством денег. На практике — многие ML (и не только) алгоритмы завязаны далеко не на тупой мощи вычислительной машины. Часть из них действительно ускоряется (и даже в разы) при добавлении ресурсов, другие — не реагируют, а некоторые могут даже создать лишние расходы и потерять в скорости.

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

Выбор алгоритмов

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

  • Ridge — выбран как базовый ориентир: классическая линейная модель с аналитическим решением, которая не итерируется и не строит деревьев.

  • XGBoost — де‑факто стандарт среди бустингов на табличных данных, библиотека с многолетней историей оптимизации под скорость и многопоточность.

  • LightGBM взят как прямой конкурент XGBoost, заявляющий ещё более агрессивную оптимизацию скорости за счёт гистограммного подхода к построению деревьев.

  • CatBoost интересен тем, что разработчики особо акцентируют поддержку параллельного и GPU‑обучения.

  • HistGradientBoosting из sklearn закрывает картину как представитель того же семейства бустингов, но реализованный в библиотеке общего назначения, где скорость никогда не была приоритетом.

Методика эксперимента

Каждый алгоритм обучался в двух режимах: с использованием всех доступных ядер (4 ядра) и с ограничением до одного. Обучающая выборка составила 144 305 семплов. Задача финальной модели — предсказать выручку магазина на несколько будущих месяцев. Поскольку у разных алгоритмов разные критерии остановки, итоговое качество намеренно приведено к единому уровню с помощью метрики MAPE — нормализованное среднее отклонение от правильного ответа, ну или просто, на сколько процентов в среднем ошибается модель.

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

Полученные данные

Для работы в многопоточном режиме (4 потока) были получены следующие результаты

Алгоритм

MAPE,%

Время обучения, сек

CatBoost

5.5855

65.444

LightGBM

3.3126

4.893

XGBoost

3.1375

6.677

HistGradientBoosting

3.8312

9.071

Ridge

14.1482

0.166

Для работы в однопоточном режиме

Алгоритм

MAPE,%

Время обучения, сек

CatBoost

5.5855

93.203

LightGBM

3.3126

5.644

XGBoost

3.1375

8.599

HistGradientBoosting

3.8312

4.526

Ridge

14.1482

0.051

Для наглядности (к сожалению Ridge не видно, а умножать на 100 не захотел для сохранения масштаба) приведём гистограмму:

Наглядное сравнение скоростей обучения на 1 и 4 потоках (меньше - лучше)

Наглядное сравнение скоростей обучения на 1 и 4 потоках (меньше — лучше)

 % изменения времени обучения при переходе с 1 к 4 потокам

изменения времени обучения при переходе с 1 к 4 потокам

Результаты оказались неоднозначными: три алгоритма действительно выиграли от добавления ядер: CatBoost ускорился на 29.8%, XGBoost на 22.4%, LightGBM на 13.3%. Все они изначально проектировались с расчётом на параллельное выполнение, поэтому результат предсказуем.

Куда интереснее ведут себя HistGradientBoosting и Ridge. Первый при переходе на 4 ядра стал медленнее вдвое (+100.4%), второй же замедлился более чем в три раза (+225.5%). Это произошло так как у обоих алгоритмов нет архитектурного фундамента для эффективной параллелизации. В случае Ridge задача решается одним матричным уравнением и дополнительные ядра только добавляют накладные расходы на координацию потоков. HistGradientBoosting из sklearn демонстрирует схожую картину — библиотека не оптимизировалась под скорость, и при многопоточности эти издержки явно заметны.

Теоретическая база и закон Амдала

В 1967 году Джин Амдал сформулировал закон о максимальном ускорении системы при распараллеливании.

закон Амдала

закон Амдала

S(n) — теоретическое ускорение при n ядрах, n — кол‑во ядер, p — доля задачи которая поддаётся параллелизации от нуля до единицы включительно, соответственно (1-p) — доля задачи которую невозможно параллелизовать (строго последовательная часть).

При стремлении n к бесконечности ускорение упирается в потолок 1 разделить на (1 - p). Если последовательная часть составляет хотя бы 10% задачи, никакое количество ядер не даст ускорения больше чем в 10 раз.

расчёты для наших алгоритмов

расчёты для наших алгоритмов

Алгоритмы принципиально различаются по тому, насколько велика их последовательная часть:

  • Ridge — уникальный случай, задача сводится к решению системы нормальных уравнений аналитически, через одно матричное разложение. Параллельная доля p приблизительно равная 0, потолок ускорения равен единице, а накладные расходы на запуск потоков и синхронизацию только ухудшают картину.

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

  • XGBoost, LightGBM и CatBoost, напротив, распределяют построение деревьев по ядрам на уровне гистограмм и сплитов — это и есть та самая параллельная доля p, которая у них достаточно велика, чтобы ускорение было ощутимым даже при скромных четырёх ядрах. Ограничения тут другие: CatBoost использует аналитические алгоритмы оптимизации и проводит преобразования категориальных признаков — это последовательные операции, которые и не дают ему приблизиться к теоретическому максимуму.

Практические рекомендации

Если требуется оптимизация по скорости при распараллеливании задач, то стоит взять что‑то из адаптивных моделей (в нашем случае XGBoost, LightGBM).

Если данные содержат много категориальных признаков, CatBoost оправдывает своё место несмотря на высокое абсолютное время: он берёт на себя кодирование категорий автоматически и при этом выдаёт конкурентное качество без ручного feature engineering.

HistGradientBoosting из sklearn имеет право на жизнь в одном сценарии: прототипирование и быстрые эксперименты в среде, где уже есть sklearn и нет желания тащить дополнительные зависимости. Масштабировать его под многоядерность — контрпродуктивно, что наш эксперимент наглядно подтвердил.

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

Заключение

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