#dask #coiled

Экспериментирую с Dask и Coiled. Первые впечатления - всё смешалось, кони, люди. Кластеру coiled при старте передаётся параметр n_workers=int, который в обычном dask значит то ли число узлов (компьютеров, виртуальных машин), то ли число процессов на узле, в зависимости от настроек. Я попробовал заказать n_workers=8 на AWS c compute_purchase_option="spot", он мне бахнул 8 инстансов t3.xlarge (4 vCPU, 16Gb RAM), надеюсь, спотовых, +1 scheduler, если верить доке, шедулер всегда не-спотовый. Но через пару секунд всё это добро удалилось тк coiled не смог восстановить окружение моего ноута: "ClusterCreationError: Cluster status is error (reason: Scheduler Stopped -> Software build failed -> Conda package install failed with the following errors: package anaconda-2022.10-py310_0 requires pip 22.2.2 py310h06a4308_0, but none of the providers can be installed) (cluster_id: 194588)."
Придётся сначала создавать софтовое окружение явно, как я и думал. Но уже видно, что, несмотря на огромную проделанную работу, coiled не довели её до совершенства. При работе с облаком всегда актуален вопрос стоимости, а тут никаких тебе оптимизаций цен. Максимум они могут "посоветовать" регион с высокими шансами получить машины. Можно указать перечень допустимых инстансов и регион, но цены на них ты должен вызнавать самостоятельно. И никак не регламентировано, как создаются гетерогенные кластера с инстансами разных типов. Такое ощущение, что coiled просто насыпает каких-то рандомных или же дефолтных инстансов, какие может получить от облачного провайдера.

#dask #coiled

Ещё что интересно, coiled поддерживает dask-овые ресурсы, но аннотировать рабочие узлы ресурсами нужно самостоятельно, что крайне странно. Ну неужели нельзя было нормально сделать, чтобы железо аннотировалось автоматически?

#dask #coiled

Ураа, после пары часов танцев удалось запустить вычисления на кластере AWS через coiled. Уже хотел отказаться от этой затеи, т.к. постоянно выкидывало ошибку что не установлен мой модуль, хотя я его копировал на узлы с помощью client.upload_file. Уже было расстроился, что не получается сделать прозрачную замену локального dask на распределённый, но оказалось, в той функции, что требуется запустить на кластере, надо сделать импорт из нужного модуля, и тогда всё заработает. Это нигде не документировано и в поисковике не находится, не удивлюсь, если многие до этой проблемы дошли и бросили. Ну ладно, все проблемы решены, получается? Нет, конечно.

Замерил использование CPU на воркере, похоже, всегда загружено только 1 ядро, что за чёрт? Запостил вопрос на их гитхабе (другой поддержки там не предусмотрено).
Похоже, стартап с US$ 21M финансированием, цель которого демократизировать кластерные вычисления питонистов в облаках... решил, что поддерживать многопроцессовость vs многопотоковость, которая нужна для чистого питон-кода, не умеющего обходить GIL, (и которая уже была в dask) не надо, и так сойдёт. Как говорится, что это, глупость или предательство?

Пока что мне подсказали использовать много машинок не более чем с 2 vCPU. По результатам теста, действительно, это позволяет извлечь максимум из железа: 1 ядро по-любому подсунут виртуальное (HT), и оно даёт +15% к производительнсти, даже с учётом того, что dask от coiled на потоках (не знаю, как это получается). Но при добавлении ещё одного реального и виртуального ядра это масштабирается ещё на 15% вместо 50%, что уже невыгодно. Конечно, создавать каждый раз вирутальный сервер со своим полноразмерным образом диска ради 2 потоков глупо, ну а что делать.

Что-то мне уже кажется, что проще самому написать поднятие контейнера с установленным dask для воркеров и шедулера, присоединение к кластеру, отработку задач и удаление кластера, чем убеждать команду coiled из 30 человек добавить функциональность многопроцессовости, раз уж они за несколько лет не захотели/не смогли/не догадались это сделать. Ну как так можно работать, тупо штаны протирать годами. Я за 1 день столько проблем увидел, требующих решения, а у них там и конь не валялся, хотя в штате 30 высококлассных спецов и это платный сервис, т.е. они должны быть заинтересованы в развитии продукта. Самая очевидная проблема в подборе инстансов, регионов и облаков оптимальных по цене/скорости работы для данной клиентской нагрузки. А они в доке уныло бубнят, мол, мы не знаем, какой инстанс будет лучше для вашей задачи, попробуйте сами несколько.. Так блять сделайте удбную фишку для клиента, чтобы его нагрузка бенчилась автоматом на нескольких инстансах,и потом ему предлагалась лучшая конфигурация, возьмите за это больше денег.. Добавьте ML чтобы предсказывать производительнось, не гоняя нагрузку на всех 100500 возможных инстансах... Да нет, нахер надо.

А, так у них ещё и конский ценник.

10,000 CPU-hours free every month
$0.05 per CPU-hour thereafter
Bulk discounts starting at $10,000
(Costs are in addition to your AWS or Google Cloud costs, which we work to help you minimize.)

Эти 10k CPU-часов пролетят незаметно, за сутки работы 200 мелких машинок с 2 ядрами. А потом надо будет платить coiled по сути БОЛЬШЕ, чем за сами сервера облачному провайдеру, потому что на спот-рынке даже не самые мелкие 2 vCPU сервера стоят $0.0134/hr. А Coiled за такой будет брать уже 0.05*2=$0.1/hr, фига себе, в 10 раз больше.

#ml #applied #dyakonov #pzad

Интересные схемы взвешивания наблюдений, с оптимизацией кэфов на CV

https://www.youtube.com/watch?v=8DdHctyl6t0&list=PLaRUeIuewv8CMFox0oEjlyePUhUmo-x0h&index=5&ab_channel=AlexanderD%27yakonov

#ml #applied #dyakonov #pzad #anscombe

Продолжаем разбор прогнозирования дня визита и суммы покупок. Крутая идея с доминошками.

https://www.youtube.com/watch?v=6xRqHGkfc6Y&list=PLaRUeIuewv8CMFox0oEjlyePUhUmo-x0h&index=4&ab_channel=AlexanderD%27yakonov

#ml #metrics #brier

Как известно, оценка Бриера (Брайера?) для бинарного классификатора представляет собой по сути среднеквадратическую ошибку между реальными исходами и предсказанными вероятностями. В теории это число между 0 и 1, где 0 означает идеальную калибрацию (из всех событий, предсказанных с вероятностью 25%, реализовались точно 25%, и тд). Я на эту метрику в работе часто смотрю, т.к. откалиброванность модельки очень важна, особенно когда бизнес-решения принимаются на вероятностях. И вот сегодня узнал нечто новое. Задумался, а чего вообще можно ожидать от модели, идеально предсказывающей вероятности, в терминах оценки Бриера. Давайте для этого скрафтим реализации миллиона событий, следующие заранее известным вероятностям:

probs = np.random.uniform(size=1000_000)
realizations = np.random.uniform(size=len(probs))
realizations = (realizations < probs).astype(np.int8)

В теории, у нас теперь есть массив единичек и нулей realizations, порождённый "истинными" вероятностями probs. Если ситуацию перевернуть, рассмотреть probs как вероятности, предсказанные моделью машинного обучения, а realizations как то, что мы реально пронаблюдали в жизни, то подобная точность должна быть мечтой любого ML-щика!