#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) между машинами примерно сохранятся, норм.