#cloudcomputing #dask #business #opticloud
Облачные вычисления с Dask требуют знания цен (особенно на спотовые инстансы), думаю начать регулярный сбор цен основных провайдеров (AWS, GCP, Azure) в базу. Возможно, в последующем сделаю какой-то сервис поиска лучшей площадки и инстансов для заданной нагрузки (с учётом прогнозной доступности и цены на заданную длительность вычислений). Например, клиент делает сабмит 1 блока своей задачи, сервис прогоняет его на нескольких инстансах, с помощью ML рассчитывает время выполнения на всех возможных инстансах всех облачных провайдеров (они же отличаются по железу). Согласно указанному клиентом объёму блоков в день, датам начала/завершения работ, система рассчитывает, в каких именно облаках и на каких конкретно инстансах нужно создавать кластер, чтобы минимизировать стоимость/время расчётов.
Производительность железа распадается на несколько блоков: CPU, GPU, RAM, Storage (HDD/SSD), Network.
Также у клиента могут быть задачи разного типа: ML Training, ML inference, Finance/Physics/Bio simulations, Video Encoding.
В голове крутится прогон подобных бенчмарков на каждом уникальном по соответствующему железу типу инстанса (например: модель процессора, тип и частота памяти, тип СХД, пропускная способность сети).
Тогда пользователь сервиса (в первом приближении) говорит: мне надо обучать sklearn-овскую модель. минимум памяти на ядро 8Гб, где сейчас это лучше сделать? Сервис отвечает: в AWS, регион us-west-2, зона 2b, инстанс такой-то, спот цена такая-то., индекс производительности такой-то. А если клиент указывает фреймворк tensorflow, в сравнении участвуют уже и GPU, TPU, Trainium инстансы, и получается другой ответ, к примеру, GCP, регион такой-то, TPU v3 spot, цена такая-то, индекс производительности такой-то.
В идеале можно будет свою задачу на минималках отправить на тестирование, и тогда уже система точно рассчитает производительность на каждом инстансе. Но для начала можно будет ориентироваться хотя бы на какие-то общие бенчмарки.
Облачные вычисления с Dask требуют знания цен (особенно на спотовые инстансы), думаю начать регулярный сбор цен основных провайдеров (AWS, GCP, Azure) в базу. Возможно, в последующем сделаю какой-то сервис поиска лучшей площадки и инстансов для заданной нагрузки (с учётом прогнозной доступности и цены на заданную длительность вычислений). Например, клиент делает сабмит 1 блока своей задачи, сервис прогоняет его на нескольких инстансах, с помощью ML рассчитывает время выполнения на всех возможных инстансах всех облачных провайдеров (они же отличаются по железу). Согласно указанному клиентом объёму блоков в день, датам начала/завершения работ, система рассчитывает, в каких именно облаках и на каких конкретно инстансах нужно создавать кластер, чтобы минимизировать стоимость/время расчётов.
Производительность железа распадается на несколько блоков: CPU, GPU, RAM, Storage (HDD/SSD), Network.
Также у клиента могут быть задачи разного типа: ML Training, ML inference, Finance/Physics/Bio simulations, Video Encoding.
В голове крутится прогон подобных бенчмарков на каждом уникальном по соответствующему железу типу инстанса (например: модель процессора, тип и частота памяти, тип СХД, пропускная способность сети).
Тогда пользователь сервиса (в первом приближении) говорит: мне надо обучать sklearn-овскую модель. минимум памяти на ядро 8Гб, где сейчас это лучше сделать? Сервис отвечает: в AWS, регион us-west-2, зона 2b, инстанс такой-то, спот цена такая-то., индекс производительности такой-то. А если клиент указывает фреймворк tensorflow, в сравнении участвуют уже и GPU, TPU, Trainium инстансы, и получается другой ответ, к примеру, GCP, регион такой-то, TPU v3 spot, цена такая-то, индекс производительности такой-то.
В идеале можно будет свою задачу на минималках отправить на тестирование, и тогда уже система точно рассчитает производительность на каждом инстансе. Но для начала можно будет ориентироваться хотя бы на какие-то общие бенчмарки.
#opticloud
Итак, первый шаг к сервису поиска оптимального облака под коротко- и среднесрочные расчёты сделан. Пока только для AWS, начат сбор спотовых цен на EC2 с высокой гранулярностью и для всех 27 публичных регионов. Уже, кстати, видно, что некоторые регионы проводят активное ценообразование, другие же спотовые цены почти не меняют. Сегодня добавляю сбор цен ondemand и заполнение таблицы "железных" характеристик инстансов. В будущем эта информация дополнится унифицированными листингами железа, снятыми непосредственно агентом внутри ВМ, и целым набором бенчмарков из разных областей. В течение недели поиск TOP N регионов/инстансов по соотношению производительность/цена на 1 vCore/Гб RAM/Тб HDD станет доступен в виде платного API.
Ещё планируются:
1) включение GCP и Azure
2) на более дорогом уровне: выдача не просто инстансов оптимальных СЕЙЧАС, а (с помощью ML) оптимальных в течение времени, нужного клиенту для вычислений. Например, банк проводит вычисления длительностью в 3 часа в 15-00 каждый день, где ему лучше запускаться сегодня, чтобы суммарная ожидаемая стоимость была минимальной? А завтра?
О ценообразовании:
Логичным кажется получение % от экономии, достигнутой с помощью сервиса, на какой-то стандартной нагрузке. Скажем, под фильтр клиента попадают N валидных комбинаций инстансов/регионов/зон. Тогда экономия составит mean(SportPrices(N))-min(SportPrices(N)) на инстанс в час.
Итак, первый шаг к сервису поиска оптимального облака под коротко- и среднесрочные расчёты сделан. Пока только для AWS, начат сбор спотовых цен на EC2 с высокой гранулярностью и для всех 27 публичных регионов. Уже, кстати, видно, что некоторые регионы проводят активное ценообразование, другие же спотовые цены почти не меняют. Сегодня добавляю сбор цен ondemand и заполнение таблицы "железных" характеристик инстансов. В будущем эта информация дополнится унифицированными листингами железа, снятыми непосредственно агентом внутри ВМ, и целым набором бенчмарков из разных областей. В течение недели поиск TOP N регионов/инстансов по соотношению производительность/цена на 1 vCore/Гб RAM/Тб HDD станет доступен в виде платного API.
Ещё планируются:
1) включение GCP и Azure
2) на более дорогом уровне: выдача не просто инстансов оптимальных СЕЙЧАС, а (с помощью ML) оптимальных в течение времени, нужного клиенту для вычислений. Например, банк проводит вычисления длительностью в 3 часа в 15-00 каждый день, где ему лучше запускаться сегодня, чтобы суммарная ожидаемая стоимость была минимальной? А завтра?
О ценообразовании:
Логичным кажется получение % от экономии, достигнутой с помощью сервиса, на какой-то стандартной нагрузке. Скажем, под фильтр клиента попадают N валидных комбинаций инстансов/регионов/зон. Тогда экономия составит mean(SportPrices(N))-min(SportPrices(N)) на инстанс в час.
#opticloud
В общем, всё оказалось не так просто. И наличие инстансов в определённом облачном регионе/зоне надо как-то оценивать (цена не имеет смысла, если мало или совсем нет товара), и об экономном расходовании места в базе думать, и код отрефакторить, чтоб был красивым, и мониторинг задач настроить.
В общем, всё оказалось не так просто. И наличие инстансов в определённом облачном регионе/зоне надо как-то оценивать (цена не имеет смысла, если мало или совсем нет товара), и об экономном расходовании места в базе думать, и код отрефакторить, чтоб был красивым, и мониторинг задач настроить.
#opticloud
Новости о моём проекте рекомендации лучших облачных серверов для расчётов: совершенно неожиданно обнаружилась возможность косвенно оценивать доступность инстансов в определённых регионах AWS, и я 3 дня провел, реализуя парсинг и регулярное сохранение такой, как я считаю, ценной информации. Это несколько сбивает сроки выкатки API, хотя всё же постараюсь опубликовать в воскресенье пусть и с пока небольшой функциональностью, но целостное решение.
Пока оно позволит клиентам получить ответ на вопрос вида "где сейчас взять 20 самых дешёвых воркеров Intel с 2 Гб RAM на ядро для моего Dask кластера".
Я видел несколько сайтов с похожей инфой, но:
1) нигде не учитывается текущая доступность инстансов, т.к. AWS полностью не раскрывает эту инфу
2) нет либо деталей архитектуры, либо кросс-регионного сравнения цен. надо вручную выписывать варианты в табличку.
Таким образом, уже бета-версия моего сервиса может быть полезной.
Следующим шагом собираюсь прикрутить в API (по модели процессора) общедоступные бенчмарки, чтобы можно было искать серверы с "железом, самым дешёвым на единицу производительности для Linpack/ Stockfish/CL/CUDA etc".
Потом кастомные реальные бенчмарки, другие облака, ML для предсказания долгосрочной доступности и цен, но это всё, конечно, если появятся клиенты.
Новости о моём проекте рекомендации лучших облачных серверов для расчётов: совершенно неожиданно обнаружилась возможность косвенно оценивать доступность инстансов в определённых регионах AWS, и я 3 дня провел, реализуя парсинг и регулярное сохранение такой, как я считаю, ценной информации. Это несколько сбивает сроки выкатки API, хотя всё же постараюсь опубликовать в воскресенье пусть и с пока небольшой функциональностью, но целостное решение.
Пока оно позволит клиентам получить ответ на вопрос вида "где сейчас взять 20 самых дешёвых воркеров Intel с 2 Гб RAM на ядро для моего Dask кластера".
Я видел несколько сайтов с похожей инфой, но:
1) нигде не учитывается текущая доступность инстансов, т.к. AWS полностью не раскрывает эту инфу
2) нет либо деталей архитектуры, либо кросс-регионного сравнения цен. надо вручную выписывать варианты в табличку.
Таким образом, уже бета-версия моего сервиса может быть полезной.
Следующим шагом собираюсь прикрутить в API (по модели процессора) общедоступные бенчмарки, чтобы можно было искать серверы с "железом, самым дешёвым на единицу производительности для Linpack/ Stockfish/CL/CUDA etc".
Потом кастомные реальные бенчмарки, другие облака, ML для предсказания долгосрочной доступности и цен, но это всё, конечно, если появятся клиенты.
#business #opticloud
А между тем, наконец-то полностью организован сбор ценовых данных и оценок доступности для AWS. Потрачен месяц вместо недели.
Работаю над API. Напоминаю, основная цель сервиса - быстро найти самые дешёвые сервера для облачных вычислений в достаточном количестве.
Раздумываю, как этим сервисом будут пользоваться вообще. Вот взять ML. Обычно мои задачи сводились к поиску серверов с достаточным объёмом RAM/VRAM на машину (чтобы хотя бы загрузился датасет), ядер чтоб побольше, и затем выбору инстанса с наименьшей спот-ценой. Ну, может, при обработке картинок еще был важен размер и тип локального диска.
Понятно, что в серьёзных кластерных вычислениях помимо цены надо ориентироваться ещё и на производительность на ядро CPU или GPU (+- с учетом архитектуры) для нагрузки конкретного типа.
Пока вырисовывается основной метод API:
который находит, скажем, топ-3 комбинации инстанса/облака/региона/зоны, удовлетворяющих критериям клиента по железу, доступности, и имеющих самое лучшее отношение производительность/цена для указанного типа нагрузки.
Пример вызова, чтобы подешевле посчитать тюнинг катбуста на табличке в миллион примеров с 300 фичами, на процессоре нового поколения, чтоб каждый сервер имел как минимум 20Gb RAM для открытия датасета, считать думаем на 500 ядрах около 2 часов, начать хотим сейчас:
Что ещё нужно учесть? Пишите в комменты советы и пожелания.
А между тем, наконец-то полностью организован сбор ценовых данных и оценок доступности для AWS. Потрачен месяц вместо недели.
Работаю над API. Напоминаю, основная цель сервиса - быстро найти самые дешёвые сервера для облачных вычислений в достаточном количестве.
Раздумываю, как этим сервисом будут пользоваться вообще. Вот взять ML. Обычно мои задачи сводились к поиску серверов с достаточным объёмом RAM/VRAM на машину (чтобы хотя бы загрузился датасет), ядер чтоб побольше, и затем выбору инстанса с наименьшей спот-ценой. Ну, может, при обработке картинок еще был важен размер и тип локального диска.
Понятно, что в серьёзных кластерных вычислениях помимо цены надо ориентироваться ещё и на производительность на ядро CPU или GPU (+- с учетом архитектуры) для нагрузки конкретного типа.
Пока вырисовывается основной метод API:
find_best_servers(
workload="ml|finance|physics|rendering|integer|floating",
capacity={vcores,gpus,tpus},
hardware_requirements={cpu,gpu,tpu,ram,hdd,network},
schedule_requirements={start_time, duration_hours},
optimize_for="efficiency|price|performance|availability",
cloud_providers="any|aws|gcp|azure|ali|sber|etc",
lease_type="any|spot|ondemand"
) , который находит, скажем, топ-3 комбинации инстанса/облака/региона/зоны, удовлетворяющих критериям клиента по железу, доступности, и имеющих самое лучшее отношение производительность/цена для указанного типа нагрузки.
Пример вызова, чтобы подешевле посчитать тюнинг катбуста на табличке в миллион примеров с 300 фичами, на процессоре нового поколения, чтоб каждый сервер имел как минимум 20Gb RAM для открытия датасета, считать думаем на 500 ядрах около 2 часов, начать хотим сейчас:
find_best_servers(Пример ответа:
workload={"type":"ml","framework":"catboost","dataset":{"nrows":1e6,"ncols":300},"hpt":True},
capacity={"vcores":500},
hardware_requirements={"ram":{"node_min_size":"20GB"},"cpu":{"features":"avx2"}},
schedule_requirements={"start_time":"now", "duration_hours":2},
optimize_for="efficiency",
cloud_providers="any",
lease_type="spot"
)
{'n_suitable_servers': 158,
'best_servers': [{'cloud_provider': 'aws',
'region': 'us-east-2',
'zone': 'az3',
'instance_type': 'r6idn.4xlarge',
'lease_type': 'spot',
'hardware_info': {...},
'n_required_instances': 62,
'expected_runtime_hours': 2,
'fulfillment_probability': 0.85,
'interruption_probability': 0.07,
'expected_instance_hourly_price': {'usd':0.3569},
'expected_workload_total_cost': {'usd':44.26},
'expected_average_savings': {'usd':7.11},
'workload_performance_rating':"15/1000",
}, ... ]}
Возможно, что данные будут грузиться из хранилища S3 некоторого региона, и будет удобно дать возможность указать, откуда и сколько данных потребуется загружать. Это позволит автоматически учесть стоимость трансфера в сервера "других регионов", чтобы потом не оказалось, что самый дешевый по железу сервер обошелся дорого из-за копирования данных.Что ещё нужно учесть? Пишите в комменты советы и пожелания.
#milestones #plans #2023
Итоги моего 2023-го года.
Бизнес-проекты
К сожалению, у меня трудности с доведением замыслов до готового продукта, даже если технически всё реализовать я могу - теряется как-то быстро интерес, что ли. В 2023-м я "технически сделал" 1 такой продукт/сервис для поиска подходящих облачных серверов, #opticloud, но никуда в паблик пока не вывел. Также за этот год появились идеи как минимум 6 интересных стартапов (от знакомств и обучения языкам до оптимизации СУБД), над некоторыми я даже неплохо поработал и добился начального прогресса. Благодаря неожиданно вышедшему на связь старому товарищу поработал над ML в оценке недвижимости. В планах на 2024-й продолжить работу над этими проектами, и, самое важное, зарелизить как минимум 1 общедоступный цифровой продукт.
Совместная работа
В очередной раз убедился, что люди неактивны, равнодушны, ничего не хотят делать. Была надежда, что в команде получится работать гораздо продуктивнее, но не получилось никого найти )
ML
За год удалось вернуться к многим своим старым идеям о взаимной информации и отборе признаков, переписать свою старую библиотечку с visual basic на python с многопроцессорностью и gpu, сформулировать идеи экспериментов и сравнений, которые надо провести. Начал писать свою FS-либу #diogenes, сейчас она включает в себя на 95% готовые модули filters и wrappers с кастомной реализацией SelectBest и #RFECV и превосходит по функциональности и качеству всё то, что я знаю из общедоступных решений. В планах на 2024-й её доведение до ума и интеграция со своей библиотекой оптимизации гиперпараметров.
Обучение
В основном я прокачивал знания в ML, просматривая/прослушивая ютуб-ролики, на эту тему (эффективного усваивания подобного материала) появились идеи ещё нескольких стартапов )
Соревнования
В очередной раз подтвердилось моё понимание, что ML-соревы - это бесполезная трата времени. Насколько я был воодушевлён, решив поучаствовать в #watersupply, настолько же оказался разочарован, увидев, какие тупые искусственные ограничения туда добавили организаторы. Ещё более меня разочаровали 350+ дата сайентистов, которые слова не сказали против таких правил, позволяющих пилить оверфитнутые решения, бессмысленные с точки зрения практики. В итоге, после препирания (моего и ещё 1 неравнодушного участника) с админами площадки, незадолго от дедлайна пришло уведомление, что идиотские ограничения убраны, что ещё более усилило, как это модно говорить, чувство кринжа.
Правда, в начале года я выиграл мини-сореву по предсказанию цен на электричество #electricity, но там каждому участнику была гарантирована компенсация в $2k независимо от места, и я ничего не терял. С тех пор, кстати, я сильно прокачал модуль генерации признаков для временных рядов, использованный в сореве.
Публицистика
Написал несколько статей на medium. Площадка - говно, но и хабр не лучше, а куда-то писать надо было.
Трейдинг
Это одна из тем, к которой я регулярно возвращаюсь со времён университета, и отступаю из-за нехватки знаний. В этот раз уже знаний, кажется, хватает, но завяз в тонкостях реализации. Проделана большая работа в нескольких поднаправлениях, в частности, сделано хорошее логирование экспериментов в MFlow, с ансамблями и стекнгом. Ожидается существенный прогресс от интеграции с Диогеном. Надо, как всегда, побыстрее делать простое работающее решение, и постепенно улучшать. В этом плане я решил попробвать сначала поработать с трейдером, предоставив ему информационную поддержку в виде веб-панельки с прогнозами, какие активы имеют высокую вероятность роста/падения в ближайшее время, посмотрим, будет ли она полезной. В планах на 2024-й, безусловно, полностью автоматизированная торговля на основе ML моделей.
Итоги моего 2023-го года.
Бизнес-проекты
К сожалению, у меня трудности с доведением замыслов до готового продукта, даже если технически всё реализовать я могу - теряется как-то быстро интерес, что ли. В 2023-м я "технически сделал" 1 такой продукт/сервис для поиска подходящих облачных серверов, #opticloud, но никуда в паблик пока не вывел. Также за этот год появились идеи как минимум 6 интересных стартапов (от знакомств и обучения языкам до оптимизации СУБД), над некоторыми я даже неплохо поработал и добился начального прогресса. Благодаря неожиданно вышедшему на связь старому товарищу поработал над ML в оценке недвижимости. В планах на 2024-й продолжить работу над этими проектами, и, самое важное, зарелизить как минимум 1 общедоступный цифровой продукт.
Совместная работа
В очередной раз убедился, что люди неактивны, равнодушны, ничего не хотят делать. Была надежда, что в команде получится работать гораздо продуктивнее, но не получилось никого найти )
ML
За год удалось вернуться к многим своим старым идеям о взаимной информации и отборе признаков, переписать свою старую библиотечку с visual basic на python с многопроцессорностью и gpu, сформулировать идеи экспериментов и сравнений, которые надо провести. Начал писать свою FS-либу #diogenes, сейчас она включает в себя на 95% готовые модули filters и wrappers с кастомной реализацией SelectBest и #RFECV и превосходит по функциональности и качеству всё то, что я знаю из общедоступных решений. В планах на 2024-й её доведение до ума и интеграция со своей библиотекой оптимизации гиперпараметров.
Обучение
В основном я прокачивал знания в ML, просматривая/прослушивая ютуб-ролики, на эту тему (эффективного усваивания подобного материала) появились идеи ещё нескольких стартапов )
Соревнования
В очередной раз подтвердилось моё понимание, что ML-соревы - это бесполезная трата времени. Насколько я был воодушевлён, решив поучаствовать в #watersupply, настолько же оказался разочарован, увидев, какие тупые искусственные ограничения туда добавили организаторы. Ещё более меня разочаровали 350+ дата сайентистов, которые слова не сказали против таких правил, позволяющих пилить оверфитнутые решения, бессмысленные с точки зрения практики. В итоге, после препирания (моего и ещё 1 неравнодушного участника) с админами площадки, незадолго от дедлайна пришло уведомление, что идиотские ограничения убраны, что ещё более усилило, как это модно говорить, чувство кринжа.
Правда, в начале года я выиграл мини-сореву по предсказанию цен на электричество #electricity, но там каждому участнику была гарантирована компенсация в $2k независимо от места, и я ничего не терял. С тех пор, кстати, я сильно прокачал модуль генерации признаков для временных рядов, использованный в сореве.
Публицистика
Написал несколько статей на medium. Площадка - говно, но и хабр не лучше, а куда-то писать надо было.
Трейдинг
Это одна из тем, к которой я регулярно возвращаюсь со времён университета, и отступаю из-за нехватки знаний. В этот раз уже знаний, кажется, хватает, но завяз в тонкостях реализации. Проделана большая работа в нескольких поднаправлениях, в частности, сделано хорошее логирование экспериментов в MFlow, с ансамблями и стекнгом. Ожидается существенный прогресс от интеграции с Диогеном. Надо, как всегда, побыстрее делать простое работающее решение, и постепенно улучшать. В этом плане я решил попробвать сначала поработать с трейдером, предоставив ему информационную поддержку в виде веб-панельки с прогнозами, какие активы имеют высокую вероятность роста/падения в ближайшее время, посмотрим, будет ли она полезной. В планах на 2024-й, безусловно, полностью автоматизированная торговля на основе ML моделей.
#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) между машинами примерно сохранятся, норм.