#hardware #mlperf #benchmark
NVIDIA снова поставила рекорды в ИИ-бенчмарке MLPerf Inference, но конкурентов у неё становится всё больше
"В целом, NVIDIA продолжает доминировать по показателям производительности, лидируя во всех категориях. Вместе с тем стартапы Neuchips и SiMa обошли NVIDIA по производительности в пересчёте на Ватт по сравнению с показателями NVIDIA H100 и Jetson AGX Orin соответственно. Ускоритель Qualcomm Cloud AI100 также показал хорошие результаты энергоэффективности в сравнении NVIDIA H100 в некоторых сценариях."
https://servernews.ru/1084751
#hardware #benchmarks #mlperf #opticloud
Постараюсь прояснить идею с либой ML бенчмарка. Зачастую непонятно, какой сервер лучше взять под конкретную ML-задачу. Если дело касается нейросетей, то вроде бы есть бенчмарки dlperf. Также при выходе новых CPU/GPU указывают производительность в Stockfish, WinZip, Pytorch/Tensorflow.
А если у вас табличные данные? Брать ли сервер на AMD Rome с 112 vcores, Xeon Gold с 80 vcores, или одна RTX 4090 их легко зарулит? А две RTX 3090? А насколько быстрее/медленнее будет одна H100? А может, вообще стоит посмотреть в сторону GPU от AMD?
У меня одного такие проблемы выбора, или отсутствие подобной информации и, как следствие, выбор наобум по принципу ХЗ всех смущает?
Может, есть какие-то сводные таблицы перформанса, которые вы смотрите и по которым принимаете решение? Или как-то пытаетесь экстраполировать результаты существующих бенчмарков?
На текущий момент у меня есть идея разработки простенькой питон либы с открытым исходным кодом, на базе, скажем, catboost, с методами
run_ml_benchmarks(tabular=True,training=True,inference=True,nreps=10)
get_ml_rankings(query='rtx 3090')
get_ml_leaderboard()
которая сможет автоопределять ваше железо, запускать несколько задач с фиксированными сидами и гиперпараметрами, прогонять nreps раз, и сохранять результат в общее облако. ну и, конечно, показывать лидерборд и результаты конкретного железа (медиану, дисперсию). При наличии такой либы все вопросы выше отвечаются pip install-ом + одним вызовом get_ml_leaderboard.
Постараюсь прояснить идею с либой ML бенчмарка. Зачастую непонятно, какой сервер лучше взять под конкретную ML-задачу. Если дело касается нейросетей, то вроде бы есть бенчмарки dlperf. Также при выходе новых CPU/GPU указывают производительность в Stockfish, WinZip, Pytorch/Tensorflow.
А если у вас табличные данные? Брать ли сервер на AMD Rome с 112 vcores, Xeon Gold с 80 vcores, или одна RTX 4090 их легко зарулит? А две RTX 3090? А насколько быстрее/медленнее будет одна H100? А может, вообще стоит посмотреть в сторону GPU от AMD?
У меня одного такие проблемы выбора, или отсутствие подобной информации и, как следствие, выбор наобум по принципу ХЗ всех смущает?
Может, есть какие-то сводные таблицы перформанса, которые вы смотрите и по которым принимаете решение? Или как-то пытаетесь экстраполировать результаты существующих бенчмарков?
На текущий момент у меня есть идея разработки простенькой питон либы с открытым исходным кодом, на базе, скажем, catboost, с методами
run_ml_benchmarks(tabular=True,training=True,inference=True,nreps=10)
get_ml_rankings(query='rtx 3090')
get_ml_leaderboard()
которая сможет автоопределять ваше железо, запускать несколько задач с фиксированными сидами и гиперпараметрами, прогонять nreps раз, и сохранять результат в общее облако. ну и, конечно, показывать лидерборд и результаты конкретного железа (медиану, дисперсию). При наличии такой либы все вопросы выше отвечаются pip install-ом + одним вызовом get_ml_leaderboard.
#mlperf #aws #opticloud
Итак, планируем архитектуру скрипта с открытым исходным кодом, делающего замеры производительности железа в ML-задачах и сохранение результатов в облако.
Очень заманчиво позволить скрипту напрямую писать результаты в облачную базу данных, но с таким подходом есть риск, что кто-то заспамит базу поддельными записями, и вся работа сообщества пойдёт насмарку.
Не вижу другого выхода как сделать отправку результатов аутентифицированной, т.е., запускающему бенчмарк потребуется логиниться в свой аккаунт, скажем, гугл, чтобы информация о тестере сохранялась и можно было потом результаты спамеров отсеять.
Также придётся реализовать какой-то механизм ratelimiting, чтобы даже аутентифицированный пользователь не мог завалить базу миллионами записей.
Мне захотелось реализовать сервис mlperf в облаке AWS, так что пока архитектура выглядит как API Gateway->Lambda->ElastiCache/Redis->DocumentDB:
0) пользователь, желающий внести вклад в тестирование железа, запускает скрипт mlperf в командной строке или делает вызов benchmark(...) из питон-кода.
1) пользователь вводит код аутентификации от гугл (перейдя в браузере по ссылке, напечатанной скриптом)
2) скрипт выполняет тестирование и передаёт полезную инфу+код в json по https на url приложения mlperf.
3) запускается lambda-функция, проверяющая размеры переданной информации, извлекающая емэйл пользователя из auth кода.
4) попадание в рэйтлимиты проверяется с помощью развёрнутого ElastiCache/Redis (INCR/EXPIRE)
5) если проверки пройдены, инфа сохраняется в основную таблицу DocumentDB.
6) клиенту возвращается статус операции.
7) некий демон (Максвелла?) в виде очередной Lambda периодически отбрасывает аномалии и аггрегирует все результаты в лидерборд.
Предложения/замечания?
Итак, планируем архитектуру скрипта с открытым исходным кодом, делающего замеры производительности железа в ML-задачах и сохранение результатов в облако.
Очень заманчиво позволить скрипту напрямую писать результаты в облачную базу данных, но с таким подходом есть риск, что кто-то заспамит базу поддельными записями, и вся работа сообщества пойдёт насмарку.
Не вижу другого выхода как сделать отправку результатов аутентифицированной, т.е., запускающему бенчмарк потребуется логиниться в свой аккаунт, скажем, гугл, чтобы информация о тестере сохранялась и можно было потом результаты спамеров отсеять.
Также придётся реализовать какой-то механизм ratelimiting, чтобы даже аутентифицированный пользователь не мог завалить базу миллионами записей.
Мне захотелось реализовать сервис mlperf в облаке AWS, так что пока архитектура выглядит как API Gateway->Lambda->ElastiCache/Redis->DocumentDB:
0) пользователь, желающий внести вклад в тестирование железа, запускает скрипт mlperf в командной строке или делает вызов benchmark(...) из питон-кода.
1) пользователь вводит код аутентификации от гугл (перейдя в браузере по ссылке, напечатанной скриптом)
2) скрипт выполняет тестирование и передаёт полезную инфу+код в json по https на url приложения mlperf.
3) запускается lambda-функция, проверяющая размеры переданной информации, извлекающая емэйл пользователя из auth кода.
4) попадание в рэйтлимиты проверяется с помощью развёрнутого ElastiCache/Redis (INCR/EXPIRE)
5) если проверки пройдены, инфа сохраняется в основную таблицу DocumentDB.
6) клиенту возвращается статус операции.
7) некий демон (Максвелла?) в виде очередной Lambda периодически отбрасывает аномалии и аггрегирует все результаты в лидерборд.
Предложения/замечания?
#mlperf #aws #opticloud
Что конкретно тестировать?
Основная идея была в тестировании 3 современных библиотек градиентного бустинга - CatBoost, LightGBM, XGBoost, причём только на задаче обучения и на одном датасете с фиксированным размером, гиперпараметрами и сидами. Даже нет, не 3 бустингов, а 1 - катбуста, т.к. казалось, что сравнительные результаты 2 остальных не будут отличаться.
Потом появилось понимание, что между библиотеками/реализациями могут быть нюансы. К примеру, катбуст может из коробки использовать несколько GPU. LightGBM вообще самый проблемный в плане использования GPU, там на *nix надо танцевать с бубнами.
В случае катбуста и мульти GPU пересылка данных может стоить слишком дорого и даже ухудшать результаты по сравнению с 1 GPU, так что, похоже, надо предусмотреть несколько вариантов размера данных. И при multigpu делать тесты начиная с одного устройства и далее 2, 4, 8...
Также пришла идея замерять инференс (возможно, опционально с интеловским ускорением). Опять же, некоторые либы поддерживают инференс на GPU (XGBoost точно).
Нужен ли RAPIDS, им кто-то вообще пользуется?
DL бенчмарки по идее можно раскопать, и я не думал их добавлять, но всё же... Надо ли кому-то? Скажем, Pytorch Lightning на CPU/GPU, с разными стратегиями шардирования и точностями (float 64/32/16 etc)? если добавлять нейросети, то тогда нужен тест архитектуры со свёртками, т.к. для свёрток сильно докидывают тензорные ядра.
Еще не совсем ясно, что делать, если у пользователя на момент запуска бенчмарка уже загружены некоторые ядра/видеокарты. Морду кирпичом и гнать тесты? Не запускать тесты, пока все не освободятся? Запускать, но с уменьшенным количеством ресурсов?
По поводу инфы о железе: думаю собирать полную, т.е. не только названия моделей CPU/GPU/RAM, но и частоты, характеристики.
С частотами неясно, как их лучше мониторить. Если замерять до запуска скрипта, на машинах с энергосбережением они ведь окажутся заниженными. Получается, надо в отдельном потоке как-то собирать каждую секунду и потом брать средние за время работы скрипта? Возможно, то же самое придётся делать с показателями nvidia-smi.
По софтовой части, обязательно фиксировать версии бустингов, cuda, runtime (python), os, opencl (?).
Что конкретно тестировать?
Основная идея была в тестировании 3 современных библиотек градиентного бустинга - CatBoost, LightGBM, XGBoost, причём только на задаче обучения и на одном датасете с фиксированным размером, гиперпараметрами и сидами. Даже нет, не 3 бустингов, а 1 - катбуста, т.к. казалось, что сравнительные результаты 2 остальных не будут отличаться.
Потом появилось понимание, что между библиотеками/реализациями могут быть нюансы. К примеру, катбуст может из коробки использовать несколько GPU. LightGBM вообще самый проблемный в плане использования GPU, там на *nix надо танцевать с бубнами.
В случае катбуста и мульти GPU пересылка данных может стоить слишком дорого и даже ухудшать результаты по сравнению с 1 GPU, так что, похоже, надо предусмотреть несколько вариантов размера данных. И при multigpu делать тесты начиная с одного устройства и далее 2, 4, 8...
Также пришла идея замерять инференс (возможно, опционально с интеловским ускорением). Опять же, некоторые либы поддерживают инференс на GPU (XGBoost точно).
Нужен ли RAPIDS, им кто-то вообще пользуется?
DL бенчмарки по идее можно раскопать, и я не думал их добавлять, но всё же... Надо ли кому-то? Скажем, Pytorch Lightning на CPU/GPU, с разными стратегиями шардирования и точностями (float 64/32/16 etc)? если добавлять нейросети, то тогда нужен тест архитектуры со свёртками, т.к. для свёрток сильно докидывают тензорные ядра.
Еще не совсем ясно, что делать, если у пользователя на момент запуска бенчмарка уже загружены некоторые ядра/видеокарты. Морду кирпичом и гнать тесты? Не запускать тесты, пока все не освободятся? Запускать, но с уменьшенным количеством ресурсов?
По поводу инфы о железе: думаю собирать полную, т.е. не только названия моделей CPU/GPU/RAM, но и частоты, характеристики.
С частотами неясно, как их лучше мониторить. Если замерять до запуска скрипта, на машинах с энергосбережением они ведь окажутся заниженными. Получается, надо в отдельном потоке как-то собирать каждую секунду и потом брать средние за время работы скрипта? Возможно, то же самое придётся делать с показателями nvidia-smi.
По софтовой части, обязательно фиксировать версии бустингов, cuda, runtime (python), os, opencl (?).
Intel
Faster XGBoost, LightGBM, and CatBoost Inference on the CPU
Accelerate your XGBoost, LightGBM, and CatBoost inference workloads with Intel oneAPI Data Analytics Library. Find updates on changes and improvements since our last article on accelerated inference.
#opticloud #mlperf #tabularml
Немного новостей по грядущей утилитке tabular ml benchmark.
Закончил написание сборщиков информации о системе, CPU, GPU для Windows и Linux. MacOS пока не поддерживается.
Собирается очень много информации: все флаги способностей центрального процессора (спасибо cpuinfo), детальные cuda capabilities каждого GPU (спасибо numba.cuda).
Еще больше детализированной информации (RAM, Board, Bios, Cache, OS) собирается через os-специфичные способы доступа: wmi для Windows, dmidecode для Linux.
Завершил тестирование мониторинга загрузки железа. Эта штука запускается в отдельном потоке, ждёт 1 секунду и начинает каждую секунду замерять загрузку процессора, памяти, и выбранных GPU.
По прекращении теста данные усредняются. Пример выдачи (без реальной нагрузки):
Average hardware Utilization: {'cpu_utilizaton_percent': 2.725, 'cpu_clocks_mhz': 2601.0, 'own_ram_used_gb': 0.164, 'total_ram_used_gb': 17.538, 'total_ram_free_gb': 110.409, 'gpu_ram_free_gb': 7.61, 'gpu_ram_used_gb': 0.231, 'gpu_clocks_mhz': 82.25, 'gpu_utilizaton_percent': 12.75, 'gpu_power_draw_watt': 7.83, 'gpu_temp_celsius': 39.0}
Думаю об эффективном хранении результатов тестов. Пока идея такая: юзер запускает скрипт, скрипт фиксирует железо и передаёт полную опись в облако. Железо попадает в табличку user_sessions, обратно отдаётся session_uuid. Скрипт начинает прогонять различные тесты, каждые N секунд сбрасывая в облако накопленные результаты со своим session_uuid. Тем самым обеспечивается компактность таблицы результатов (и хотя бы частичная сохранность данных в случае какого-то железного крэша).
Как планирую хранить инфу о железе: описание каждого CPU/GPU имеет сотни полей. Думаю при получении новой записи сортировать словарь и считать хэш от его текстового представления (удалив переменные поля типа name). Если такого хэша в таблице hw_info ещё нет - добавлять запись. В таблице же user_sessions хранить массивы hw_hashes. Помимо очевидной экономии места, это позволит распознавать процессоры, для которых не указана модель (в контейнерах и инженерных образцах и не такое встречается).
По поводу архитектуры - возможно, добавлю еще слой SQS, куда будут быстро складироваться результаты тестов (а потом уже пакетно забираться в базу).
Перехожу к обновлению ассортимента ML-тестов. Решил добавлять все 3 градиентных бустинга в CPU и GPU режиме. lightgbm в GPU режиме работает через opencl, в cuda-режиме мне его скомпилировать не удалось.
XGBoost хочу ещё попробовать в Dask-версии.
Возможно, еще добавлю что-то из Rapids/cuml - лес и опорные вектора?
Ах да, и будет pytorch-lightning.
Немного новостей по грядущей утилитке tabular ml benchmark.
Закончил написание сборщиков информации о системе, CPU, GPU для Windows и Linux. MacOS пока не поддерживается.
Собирается очень много информации: все флаги способностей центрального процессора (спасибо cpuinfo), детальные cuda capabilities каждого GPU (спасибо numba.cuda).
Еще больше детализированной информации (RAM, Board, Bios, Cache, OS) собирается через os-специфичные способы доступа: wmi для Windows, dmidecode для Linux.
Завершил тестирование мониторинга загрузки железа. Эта штука запускается в отдельном потоке, ждёт 1 секунду и начинает каждую секунду замерять загрузку процессора, памяти, и выбранных GPU.
По прекращении теста данные усредняются. Пример выдачи (без реальной нагрузки):
Average hardware Utilization: {'cpu_utilizaton_percent': 2.725, 'cpu_clocks_mhz': 2601.0, 'own_ram_used_gb': 0.164, 'total_ram_used_gb': 17.538, 'total_ram_free_gb': 110.409, 'gpu_ram_free_gb': 7.61, 'gpu_ram_used_gb': 0.231, 'gpu_clocks_mhz': 82.25, 'gpu_utilizaton_percent': 12.75, 'gpu_power_draw_watt': 7.83, 'gpu_temp_celsius': 39.0}
Думаю об эффективном хранении результатов тестов. Пока идея такая: юзер запускает скрипт, скрипт фиксирует железо и передаёт полную опись в облако. Железо попадает в табличку user_sessions, обратно отдаётся session_uuid. Скрипт начинает прогонять различные тесты, каждые N секунд сбрасывая в облако накопленные результаты со своим session_uuid. Тем самым обеспечивается компактность таблицы результатов (и хотя бы частичная сохранность данных в случае какого-то железного крэша).
Как планирую хранить инфу о железе: описание каждого CPU/GPU имеет сотни полей. Думаю при получении новой записи сортировать словарь и считать хэш от его текстового представления (удалив переменные поля типа name). Если такого хэша в таблице hw_info ещё нет - добавлять запись. В таблице же user_sessions хранить массивы hw_hashes. Помимо очевидной экономии места, это позволит распознавать процессоры, для которых не указана модель (в контейнерах и инженерных образцах и не такое встречается).
По поводу архитектуры - возможно, добавлю еще слой SQS, куда будут быстро складироваться результаты тестов (а потом уже пакетно забираться в базу).
Перехожу к обновлению ассортимента ML-тестов. Решил добавлять все 3 градиентных бустинга в CPU и GPU режиме. lightgbm в GPU режиме работает через opencl, в cuda-режиме мне его скомпилировать не удалось.
XGBoost хочу ещё попробовать в Dask-версии.
Возможно, еще добавлю что-то из Rapids/cuml - лес и опорные вектора?
Ах да, и будет pytorch-lightning.
#opticloud #mlperf #tabularml
Новости по проекту. Немного затормозил с оптимизированным сохранением результатов инвентаризации системы в базу, но в итоге всё работает как и планировалось - данные быстро дедуплицируются и эффективно хранятся, используется кэш "железной" детализации.
Улучшил парсинг dmidecode и lscpu. Добавил сохранение battery_info, power_plan, large_pages_support (всё кросс-платформенно).
Начал крутить тесты, и тут вылезли интересные детали. Как меня и предупреждали, тайминги обучения модели (даже относительные, например, катбуст CPU vs катбуст GPU) оказались сильно зависимы не только от типа задачи (к примеру, регрессия vs мультирегрессия), но и от размера датасета (разница от 2 до 5 раз).
(Кстати, пришлось некоторые гиперпараметры жёстко прописать, типа border_count= 128,learning_rate=0.1 для катбуста, если этого не сделать, по умолчанию в CPU-режиме border_count будет назначен вдвое выше, и будет казаться, что CPU-версия еще медленнее, чем она есть. а learning_rate при её неуказывании вообще подбирается адаптивно и во многом случайно.)
Скорее всего, обнаружатся такие гиперпараметры, которые будут сильно сдвигать соотношения таймингов CPU vs GPU, но тут ничего не сделать, кроме как запускать тест в 3 вариантах (small, medium, big) и, возможно, в нескольких наиболее часто используемых конфигах (но каких?).
Главное, чтобы соотношения таймингов не сдвигались по железу. Попытаюсь это проверить, думаю сгенерить какую-то детерминированную россыпь гиперпараметров и по ней пройтись на нескольких разных машинах. Если соотношения (в разбивке по HP) между машинами примерно сохранятся, норм.
Новости по проекту. Немного затормозил с оптимизированным сохранением результатов инвентаризации системы в базу, но в итоге всё работает как и планировалось - данные быстро дедуплицируются и эффективно хранятся, используется кэш "железной" детализации.
Улучшил парсинг dmidecode и lscpu. Добавил сохранение battery_info, power_plan, large_pages_support (всё кросс-платформенно).
Начал крутить тесты, и тут вылезли интересные детали. Как меня и предупреждали, тайминги обучения модели (даже относительные, например, катбуст CPU vs катбуст GPU) оказались сильно зависимы не только от типа задачи (к примеру, регрессия vs мультирегрессия), но и от размера датасета (разница от 2 до 5 раз).
(Кстати, пришлось некоторые гиперпараметры жёстко прописать, типа border_count= 128,learning_rate=0.1 для катбуста, если этого не сделать, по умолчанию в CPU-режиме border_count будет назначен вдвое выше, и будет казаться, что CPU-версия еще медленнее, чем она есть. а learning_rate при её неуказывании вообще подбирается адаптивно и во многом случайно.)
Скорее всего, обнаружатся такие гиперпараметры, которые будут сильно сдвигать соотношения таймингов CPU vs GPU, но тут ничего не сделать, кроме как запускать тест в 3 вариантах (small, medium, big) и, возможно, в нескольких наиболее часто используемых конфигах (но каких?).
Главное, чтобы соотношения таймингов не сдвигались по железу. Попытаюсь это проверить, думаю сгенерить какую-то детерминированную россыпь гиперпараметров и по ней пройтись на нескольких разных машинах. Если соотношения (в разбивке по HP) между машинами примерно сохранятся, норм.