Комментарии 10
Если вы предпочитаете работать с Python скриптами, использовать Git, инструменты и библиотеки от разных вендоров, и вообще работать из своей любимой IDE, вы можете найти MLOps платформы скорее контрпродуктивными.
Очень точно подмечено!
Для батчевой обработки данных - возможно.
А что делать, когда модель требуется для онлайн-использования (кмк большинство MLOps имплементаций связаны именно с онлайн-процессами)?
Каковы дополнительные расходы ресурсов? Не получится ли что выигрыш получается только при +- крупных задачах? Тогда как при условно небольших проще 1 раз поднять машину и не тратить на это ресурсы.
Прямо сейчас dstack поддерживает запуск скриптов для "разработки": это обработка данных, тренировка моделей, и запуск приложений в целях отладки.
Над развертыванием моделей в продакшн мы пока серьезно не думали. Хотя, как мне лично кажется, все что написано выше применимо и к развертыванию моделей.
> Не получится ли что выигрыш получается только при +- крупных задачах?
Иногда действительно может быть удобно 1 раз поднять машину и в интерактивном режиме выполнить задачу. Собственно, это делается с помощью dstack одной командой: https://docs.dstack.ai/examples/devs/. Зато в поднятой машине уже развернута среда разработки, выкачан код, настроены зависимости. В этом плане dstack вполне себе альтернатива SSH.
В любом случае, учитывая, что dstack бесплатный и опенсорсный, можно проверить и отписаться. Буду очень рад обратной связи!
Понятно. Просто имхо применимость MLops к разработке мне в последнее время все больше и больше кажется весьма спорной. А вот к деплою - совсем другой разговор.
По поводу интерактивного режима - и в чем тогда плюс в сравнении с SSH? Кроме дополнительного инструмента?
В том, что не нужно вручную создавать и настраивать машину.
Плюс, dstack помогает в версионировании артифактов (например датасетов или моделей). Вот тут немного про то, как команда dstack tags работает: https://docs.dstack.ai/reference/cli/tags/
Это очень простая (в этом и ее ценность) альтернатива DVC.
Спасибо за статью, интересный подход, наверно будем пробовать. Может есть смысл кроме этого поста сделать более развернутый tutorial с разбором пары примеров и неочевидными вещами.
Если вы тащите в образ конду и стараетесь ускорить запуск, то логично было бы добавить сахара для использования conda pack.
Дизайнил-евангелистил в Озоне штуку которая пересекается по философии и функциональности. Правда собственно до adhoc-запускалки при мне мы не дошли, там было больше про поддерживаемость кода, воспроизводимость и удобный запуск airflow-пайплайнов с вычислениями на hadoop yarn кластерах.
О, интересно. Про conda pack до этого не слышал. Обязательно посмотрю.
Уже сейчас можно сохранять conda environment в качестве артифакта и подключать его к workflow.
Если получится глянуть dstack, буду очень признателен за фидбек!
Кстати, потенциально поддержка распределенных workflow тоже в плане.
Кстати, по поводу conda pack, а это действительно влияет на скорость развертывания conda environment. По сравнениею с хранением в незаархивированном виде.
Запуск ML скриптов в облаке с помощью dstack. Бонус – про запуск open-source проектов